Fixed by https://dev.gnupg.org/rGPGPASS7587429ed4da7b5002cdbb35c4d1e7e649c2bac5

(ignore the last commit, I assigned the wrong task to it)

Fixed with https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgpass.git;a=commit;h=51a227de27d53626ff87151b3cd619efd19b1804

Done with https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgpass.git;a=commit;h=6e5d0ef58fff0277cb072b46b56080eb3f130ad9 and https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgpass.git;a=commit;h=5ecb1e2e8eb0d4608be1e7fe04f6327b84753fcf

This is now implemented

Well, my hope for this was some kind of Format where we keep the keys + the signature together with encrypted files. Because I think it is an extremely common usecase to decrypt a file, modify it and then to reencrypt it to the recipients that it was encrypted to before and I think it would be a good usability improvement if after decryption, when a file is then encrypted again Kleopatra would have the recipient dialog prefilled with the original recipients. T6564: Kleopatra: Re-encrypt an encrypted folder to the original recpients And for Gpgpass this could be used in exactly the same manner just with a diffrent UI and focused on folders with multiple files.

I am not sure I like every aspect of passtore.sh (e.g. the YAML configuration files and yet another group concept where we probably could reuse Kleopatra groups), but it's good to know that there is already a solution for this issue :)

Using signed files would have been my suggestion, too. For me I would say that "allowed to sign" depends on the ownertrust of the signature certificate. If the ownertrust of the certificate is Ultimate then you can accept the recipient list. Ultimate ownertrust is given for your own keys or for the ones marked with trusted-key in the GnuPG configuration.

Is a solution to this problem by an organization using pass for a log time with quite some users.

I am a bit wary about making this configurable, mostly because this means quite a bit more complexity in the code as the view need to handle two different modes.

I am a bit wary about making this configurable, mostly because this means quite a bit more complexity in the code as the view need to handle two different modes. For the basic usecase of having only one profile/password store, we probably should not show the store name.

I like the idea, but others might not.
Maybe the behavior could be made configurable?

I created a merge request here https://invent.kde.org/carlschwan/gpgpass/-/merge_requests/3

I and most users don't read what software says and just click where I think I reach my goal fastest. If there are only instructions to do something I am unable to continue.

No I don't think we should support that. I just meant that at first start we have to expect that the user does not have a secret key yet. And offer an easy way out of this by generating one.

If you want to use gpgpass without a secret key, the most I would offer, if at all, is the option to use a symmetric key instead.
Maybe like this:

Yeah this task is a bit bad as it does not really split this up into actionable tasks. But I found it obviously "ugly" (Since QWizards are ugly) and from a user experience standpoint outdated that I thought a general task would be enough to say that this must be changed and improved. The first start is the most important one and to be greeted by a wizard which I still am apparently where I don't really understand what the software wants from me is strange.

Gpgpass already installs a desktop file I just overlooked it.

File dialogs
Code does use the standard Qt File dialog, but I_think I should redo it to use the static methods instead because that let the backend take over.

First start wizard

There is lot of separate things in here. I'll do a couple of different comments per thing