search

hartwork / mozilla-password-decrypt

:unlock: Decrypt passwords stored by Firefox, Thunderbird, Iceweasel, Icedove using libnss3.so
7 stars 4 forks source link

Support master password (volunteers wanted) #3

Open hartwork opened 9 years ago

hartwork commented 9 years ago

Since I don't know any way of contacting you directly: @nyov, here's a re-write of the Firefox password decryptor with proper licensing. If you feel like adding and testing master password support, that would rock the house.

nyov commented 9 years ago

Thanks for the notify, nice work. Before committing to anything, I have to question some choices first, though.

Any reason for having both GPL2.0 and LGPL2.1 in the license? I don't quite see the point. Though I also believe the LGPL has the option "built-in" to rerelease / migrate any LGPL code under the stricter GPL anyway.

And do you have a specific reason for choosing to go with another ctypes wrapper project? Or would you consider cffi instead?

Personally, I wanted to clean up the codebases I had there and then move on to doing an alternate implementation on top using the python-nss lib bindings. But I see the wisdom in not depending on the whole python-nss lib for this relatively simple job.

Also, I'd prefer to not get hung up on "decrypting" passwords, rather what I had this code in mind for should work bidirectionally, also allowing to add entries to a database, maybe even create one.

nyov commented 9 years ago

Ah I see my first question is answered by the license header in https://github.com/mozilla-services/services-central-legacy/blob/master/security/nss/cmd/pwdecrypt/pwdecrypt.c. The current version I was looking at didn't have that, seems to be MPL2 only: https://hg.mozilla.org/projects/nss/file/9c25253f6d3c/cmd/pwdecrypt/pwdecrypt.c

hartwork commented 9 years ago

Hi!

And do you have a specific reason for choosing to go with another ctypes wrapper project? Or would you consider cffi instead?

I had not heard about CFFI before. I have little motivation to do that transition myself, but I do not object to a transition to CFFI.

Personally, I wanted to clean up the codebases I had there and then move on to doing an alternate implementation on top using the python-nss lib bindings. But I see the wisdom in not depending on the whole python-nss lib for this relatively simple job.

I would not mind a dependency on python-nss. I did play with python-nss before going to ctypes. It does not seem provide the functions called by pwdecrypt, i.e. grepping for "PK11SDR_Decrypt" in 0.16 code did not give any matches. If python-nss helps, which functions to call would need to be found out.

Also, I'd prefer to not get hung up on "decrypting" passwords, rather what I had this code in mind for should work bidirectionally, also allowing to add entries to a database, maybe even create one.

No objections, I just would not write the code myself. If that happens, the project could use a rename, I guess.

The current version I was looking at didn't have that, seems to be MPL2 only

I remember seeing a re-licensing commit on that file somewhere but I fail to reproduce it right now, maybe later. If the re-licensing was allowed to take place, could be an interesting question by the way. Personally, I would be happy with MPL 2, too.

Best, Sebastian

nyov commented 9 years ago

Awesome, I think I can work with that.

Regarding cffi, it seems to be the up-and coming thing to use if one wants to support pypy, and I also like the option of potentially linking to C libs on the API level versus just dlopen'ing. I'll look into doing a conversion. I also haven't looked too deeply into python-nss yet, possibly after, if I can.

Finally, on licensing, I just re-read the MPL2 here https://hg.mozilla.org/projects/nss/file/9c25253f6d3c/COPYING, which allows linking to GPL/LGPL code, if one provides a potentially modified nss lib under the MPL. This leads me to think it would be simplest to just provide this under one license, say LGPL. But that's your prerogative, I don't mind either way.

nyov commented 9 years ago

I'm sitting on this basic cffi converted version for the last two days now, with added master password checking and pypy/python3 support.

But the way this currently works is rather horrible, doing the whole NSS_Init/NSS_Shutdown procedure, and then PK11 login/logout in between, for every single password. So there is some refactoring work still to be done before I feel like pushing this.

hartwork commented 9 years ago

I named decrypt_single the way I did, because I knew we would need something better for a number of consecutive calls. Maybe a class? decrypt_single could then be turned into a wrapper using that class. Maybe let's get the open pull request sorted first. After, simplified, make this as many single commits as possible, please.