Pacc: A Better Unix Password Manager(jlucas.codeberg.page)
jlucas.codeberg.page
Pacc: A Better Unix Password Manager
https://jlucas.codeberg.page/posts/20260101-pacc.html
4 comments
Thanks for the feedback.
That is a valid concern, but I believe it doesn't justify exposing entry names, as the effect would be the same if the file names were encrypted. Also rewriting only modified entries leaks which/how many are changed/unchanged/added/removed. My db looks entirely different on each write as it is encrypted as a whole with a random IV each time, and with compression you can't tell with certainty how many entries it has.
I'll look into fixing it the "rewrite to temp file then atomically rename" way, or perhaps rename the old one first and keep it around as a backup (which would also allow undoing mistakes).
I can't tell if you're suggesting SQLite as a solution to the same corruption problem or something unrelated, but either way, I'd prefer keeping it simple overall instead of depending on a more complex one-size-fits-all. Thanks for suggesting anyway.
That is a valid concern, but I believe it doesn't justify exposing entry names, as the effect would be the same if the file names were encrypted. Also rewriting only modified entries leaks which/how many are changed/unchanged/added/removed. My db looks entirely different on each write as it is encrypted as a whole with a random IV each time, and with compression you can't tell with certainty how many entries it has.
I'll look into fixing it the "rewrite to temp file then atomically rename" way, or perhaps rename the old one first and keep it around as a backup (which would also allow undoing mistakes).
I can't tell if you're suggesting SQLite as a solution to the same corruption problem or something unrelated, but either way, I'd prefer keeping it simple overall instead of depending on a more complex one-size-fits-all. Thanks for suggesting anyway.
Why are you rolling out your own crypto? Timing attacks, unvalidated inputs and no bounds checking.
> I am not a cryptographer. ... However I am fairly confident that this is at least safer than pass. Feel free to prove me wrong.
Translation: I have no experience in safe cooking. Please use my garlic oil, and my chicken salad. Feel free to prove me wrong - from the ER ward.
> I am not a cryptographer. ... However I am fairly confident that this is at least safer than pass. Feel free to prove me wrong.
Translation: I have no experience in safe cooking. Please use my garlic oil, and my chicken salad. Feel free to prove me wrong - from the ER ward.
It's not like I'm writing the algorithms from scratch, OpenSSL is doing all of the heavy lifting. I'm aiming for actual simplicity, and so my vault format is harder to get wrong than parsing PGP packets (sure, that's handled by GPG in the case of pass, but it is still needless complexity for a password manager).
As for the "safer than pass" thing, pass does not encrypt entry names, so yes encrypting my way is safer than not encrypting at all in that aspect at least. Plus the whole KDF + symmetric only thing, though if you don't trust the way I handle it I have nothing to add here.
And I wouldn't translate "use it at your own risk" to "please use it". More like "you may use it if you choose so". You are free to back me up or tear it apart, or do nothing and go about your day. The software is not production-ready, though any help to change that is welcome.
Thank you for your attention.
As for the "safer than pass" thing, pass does not encrypt entry names, so yes encrypting my way is safer than not encrypting at all in that aspect at least. Plus the whole KDF + symmetric only thing, though if you don't trust the way I handle it I have nothing to add here.
And I wouldn't translate "use it at your own risk" to "please use it". More like "you may use it if you choose so". You are free to back me up or tear it apart, or do nothing and go about your day. The software is not production-ready, though any help to change that is welcome.
Thank you for your attention.
> a simple custom vault format.
I understand what you're saying about password-store's directory structure exposing website names as plain text filenames...but, the upside of that design is that it tends to be very resilient.
imagine that you're updating an entry in your vault, and right as you save it you lose power, resulting in file corruption.
with password-store's design, the blast radius of the corruption is limited to that one single entry.
with your design, the potential blast radius of corruption could be my entire password vault.
in particular, looking at your file-management code [0, 1] it looks like it does a complete rewrite of the vault file on every save, without doing "rewrite to temp file then atomically rename" or any similar tricks meant to handle partial file writes.
if you haven't seen it before, I'd suggest reading "SQLite As An Application File Format" [2] and consider using SQLite as the storage backend.
0: https://codeberg.org/jlucas/pacc/src/branch/master/src/db.c
1: https://codeberg.org/jlucas/pacc/src/branch/master/src/vault...
2: https://sqlite.org/appfileformat.html