Project structure

[nyov]

(To not discuss this in #3 )
I though on how to continue with this or refactor it, taking both decoding and encoding into mind.
First I'd like to ask about renaming and shortening the module. mozilla_passwords or mozpassword would be my take. This is also for consideration of #2 (packaging).

For the module structure, after some thought, I would go with a few classes: a database/file representation (loader), a login/password/site representation and a wrapper class for the NSS functionality:

My first thought was to go with a Decryptor and Encryptor class, but then it makes sense to combine this in a "NssPK11Password" (or something) class with both decryption and encryption methods which takes care of setup and teardown of NSS for use in both decrypting and encrypting (and keeping it around).

After that I'd think to go with another class for the Mozilla Logins (Moz[illa]Password or Moz[illa]Login comes to mind -- "Site" would feel wrong for e.g. Thunderbird logins, and any "Site" could have multiple login forms), which handles the data structure derived from the signons database (or, optionally, later also support for the signons.txt Netscape Communicator Key Database Format). I have gone with the namedtuple for this now, but it would probably extend to some custom class methods later.

Then the loader class to represent a file storage (sqlite db or signons.txt) would handle loading and saving entries -- return MozillaLogin objects and store/update passed-in objects, and do NSS login/logout for password protected databases.
This class would pull in the sqlite dependencies when inspecting a signons db, or something else for the netscape text format.

This is a layout I think would feel natural to me, unless you maybe have reason to go with a more functional approach and less mutable datastructures.

[hartwork]

mozpassword would be okay to me for a Python package name. But I would not want to rename it before we have encoding/encryption in there, too.

For the decrypting and encrypting class, master password support should come first, in my eyes.
I'm also not sure, if that class should take care of NSS init/deinit itself.

I could imagine to go a more data centric way: to have two kinds of instances:

• encrypted log-in instances with a method .decrypt(..) to produce a new plaintext instance from it and
• plaintext instances with a method .encrypt(..) to produce encrypted instances.

About signons.txt I don't object, but I won't be able to test it live so there will need to be automated regression test cases for it.