Closed jnvsor closed 6 years ago
Looks like this is not conflicting with changes introduced by #25. Could you resolve those conflicts? Also, I'd appreciate if you could split up the clean-ups into multiple commits. It would be much easier to review.
Here's a branch that will merge - I'm going to start working on splitting it up now
That should do it. Almost all of it was removing the user input parsing and refactoring related boilerplate
LGTM
You may want to rewrite the salt generation commands in README.md
Honestly at this point I think we're better off using fscrypt since that seems to have a large userbase and more features.
The only features it's missing that are blocking me from using it is the (planned) ability to backup keys and to store pam keys on a separate home partition.
I do agree with @jnvsor: fscrypt is far better maintained and has more features. Still, I'll keep maintaining this module in the future. As for the pace... well by know you probably can tell that my maintainership of this module is rather lacking.
I'll do some updates to the README during the next few days, including a reference to fscrypt.
Yeah that's probably true. But pam_e4crypt works with a simple setup. And I'll need some investments to migrate to fscrypt (aka works for me now, I'll check that in the far future ^^)
Breaking change: Now takes the file contents verbatim. You don't need the 's:' prefix any more, and the file can contain binary data such as \0
You can simply remove the s: prefix from your salt file to get the same decryption key after this patch.
Depends on #25 (I "cleaned up" the code mtab depended on)