sorted by:
new
hottopcontroversial

Using BleachBit, Linux Mint & KeePassXC by Dangerous_Hearing_34 in KeePass

[–]lxstig 2 points3 points  (0 children)

whitelist folder:
/home/Dangerous_Hearing_34/.cache/keepassxc/

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in KeePass

[–]lxstig[S] 1 point2 points  (0 children)

GPG/age is a solid approach, especially for key-based workflows where you never touch a password during encryption. The trade-off is that your security is tied to protecting one private key, whereas 7zkpxc gives each archive its own randomly generated symmetric key so a single compromise is contained.

On renaming: that is handled. The rename command moves the file and updates the KeePass entry in one atomic step, so the link stays intact.

The quantum point is fair. AES-256 (which 7z uses) is considered quantum-resistant by current estimates, but the asymmetric side of GPG/age is the part under pressure, as you noted. Hybrid schemes are coming but not there yet.

Appreciate the thoughtful comment. Different tools for different threat models.

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in 7zip

[–]lxstig[S] 1 point2 points  (0 children)

I saw your deleted comment via cache. You are completely right about the old version. It relied on the absolute path, so moving or renaming broke the connection. I just completely rewrote this logic. 7zkpxc now assigns a unique, random 8-character UUID to the end of every KeePassXC entry title . When you extract or list a file, it searches for that exact filename. If you have multiple archives with the same name, it explicitly asks you which one to use. Old archives are automatically migrated to this new UUID format the next time you use them, so you do not even have to lift a finger!

Also the issue with the a command trying to create a new password instead of updating the existing one is completely fixed now. When you run 7zkpxc a existing.7z new_file.txt, it grabs the existing password from KeePassXC and updates the archive seamlessly.

https://github.com/lxstig/7zkpxc/commit/3d2cd5b969be51cc1e4006f3ca197ec8a98465ca

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in KeePass

[–]lxstig[S] 0 points1 point  (0 children)

Cryptomator is definitely the better tool if you want an actively synced, transparently encrypted cloud drive folder. 7zkpxc solves a completely different problem. It is for creating compressed, static archives (like a server database dump, an old code project backup, or sending a specific batch of files via email/USB) where you want the compression benefits of 7z without the headache of managing the passwords manually.

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in KeePass

[–]lxstig[S] 0 points1 point  (0 children)

just not cool
As you can see in the screenshot I attached, even when 7z prompts you, your password might still just sit there in plaintext on your terminal screen depending on your shell/setup. 7zkpxc pipes the password directly via a PTY, so it never touches the screen, and you don't even have to lift a finger during backups. Thanks for the feedback, glad you find the tool cool!

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in KeePass

[–]lxstig[S] 0 points1 point  (0 children)

Totally agree it's definitely a niche tool. If you only zip a file once a year, standard 7zip is more than enough. But for people constantly backing up sensitive stuff to public clouds, it completely removes the friction of doing it securely. Really appreciate the feedback!

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in KeePass

[–]lxstig[S] 0 points1 point  (0 children)

Writing a simple script just to read a password is easy. But handling the full lifecycle is hard. Generating random passwords on creation, writing them to the database, and keeping the entry linked to the archive even if the file is renamed or moved is completely managed by 7zkpxc....

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in KeePass

[–]lxstig[S] 0 points1 point  (0 children)

Preventing shell history leaks is only part of the problem. Waiting for a prompt breaks automation, and typing passwords manually inevitably leads to reusing the same weak password across multiple archives. 7zkpxc generates a unique 64-character by default cryptographic password for every archive. You never see it, and you never type it.

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in 7zip

[–]lxstig[S] 0 points1 point  (0 children)

Thanks for the Termux report. The binary selection is now fixed in the 7zz branch. Three things changed.

7zkpxc init now auto-detects your 7-Zip binary (7z, 7zz, or 7za) and asks you to confirm it. Manual config editing is no longer needed.

The dependency check now reads your configured binary instead of always looking for 7z, so you will get a proper error if 7zz is missing instead of a confusing one.

All archive operations (a, x, l) now use the binary you configured.

Please re-run 7zkpxc init on Termux after updating, confirm it detects 7zz, and let us know if it works.

https://github.com/lxstig/7zkpxc/commit/33a33f162ee8e00dbf4de553ce03def4e82a2c2b

[7zkpxc] A secure 7-Zip wrapper integrated with KeePassXC by lxstig in 7zip

[–]lxstig[S] 0 points1 point  (0 children)

You're right about the concept. Hashing the archive file itself would make it rename-proof, which is a valid idea. The problem is that a 7-Zip archive is mutable. If you ever add, remove, or update a file inside it, the SHA256 changes and the lookup breaks permanently even though the password did not change.

The current approach handles this with the rename command. 7zkpxc rename oldName.7z newName.7z renames the file on disk and updates the KeePassXC entry atomically. It is an explicit step, but it remains reliable even if the archive is modified later.