Talk:KeePass

Transferring secrets to and from providers

When migrating from a secrets provider to another, you will obviously want to transfer the secrets.

I've found a method, but 1) it's perfectible, and 2) where should it be documented?

What I've used is:

1. Use lssecret to extract all secrets,
2. systemctl --user stop gnome-keyring.service,
3. Start KeePassXC's Secret Service integration,
4. Use an ad-hoc script to parse its output into secret-tool store invocations.

...this is problematic because KeePassXC (at least) adds a lot of (perhaps harmless) key/value pairs, and also lssecret is not able to extract from locked collections. (secret-tool is, but it doesn't have ls-like capabilities. Augh!)

ISSOtm (talk) 18:57, 17 September 2023 (UTC)

From what I understand, I think the most suited to document it would be for you to create either a blog post or a GitHub repository, containing:

1. Complete description of the steps to perform the transfer.
2. Ad-hoc script that should be use by the user (potentially after some tweaks) to perform the transfer.

Finally, this post / repository could be linked in a Tips and Tricks section on the Wiki (or in the subsection related to the Secret Service of KeePass). Drack (talk) 09:28, 30 June 2025 (UTC)

Cleanup the wiki entry and maybe split into KeePass and KeePassXC

KeePass and KeePassXC are entirely different applications and currently their configurations and features are mixed together into one big confusing block. I'd suggest either splitting both into individual pages or restructuring this page to separate them.

e.g. KeePassXC doesn't have plugin support. It only provides what is built into it where as KeePass can load plugins at runtime. Agowa338 (talk) 14:19, 23 June 2024 (UTC)

Well the page introduces the topic as "KeePass is an encrypted password database format." But making a KeePassXC page at this point would be a good idea. — Lahwaacz (talk) 13:43, 24 June 2024 (UTC)

Agree with this! I may give it a shot one day. Drack (talk) 09:25, 30 June 2025 (UTC)

Hi,

is splitting up really necessary, when the article refers first to the Keepass as the database format?

Wouldn't it be enough to give the article a new structure? F.ex. (1) introduction, (2) overview of software clients to using the database format, (3) Different Clients, (3.1) Keepass 1 vs 2 with the Plugin integration, (3.2) KeePassXC, and so on

What do you think? @Drack @Lahwaacz @Agowa338

YaH (talk) 19:35, 7 August 2025 (UTC)

Hey there,

here is an approach, how I would try to cleanup the entry.

User:YaH/cleanupKP

Best regards

YaH (talk) 21:22, 8 August 2025 (UTC)

The intro of the page is somewhat misleading as the page focuses on applications rather than the database format. It can be changed easily and I don't think it is related to the splitting.

The main reason for splitting is the organization of all sections related to a specific implementation – search e.g. for "keepassxc" in the page.

— Lahwaacz (talk) 17:20, 12 August 2025 (UTC)

Delete section Conflict with GNOME Keyring

As stated in the article, this section is considered to be removed. I agree with this, since this may break the system and tickets are opened upstream. I think the best option to suggest in the wiki is to simply remove `gnome-keyring` if the user want to stop using it completely (this is the case on my system). But the solution currently proposed seems fragile. What do you think? Should we proceed to removal? Drack (talk) 09:23, 30 June 2025 (UTC)

Hm,

I wouldn't remove it. Or at least another workaround need to be described in full, which wouldn't be less complex, as far I can tell. F.ex. the package "gnome-session" is depending on "gnome-keyring". As far as I understand the dependencies' you could run >>pacman -Rdd gnome-keyring<<, but wouldn't you have also to alter /etc/pacman.conf as well to ignore the package in the future?

I lack knowledge and experience to be sure.

YaH (talk) 22:22, 7 August 2025 (UTC)