existing .gpg-id is ignored for user selection dialog in a subfolder

[Alixerid]

The root of my passwordstore has a .gpg-id with 5 keys ids in it, say id1, id2, id3, id4 and id5. I created a subfolder and used the button to give access to that folder only to 3 of these 5 ids, say id1, id3 and id4. With the new re-encryption introduced with 1.1.4 the passwords are encrypted with these 3 keys correctly. Also, the .gpg-id file in the subfolder shows only the 3 keys. However, when I click the button for the user selection dialog for that subfolder again, I see all 5 entries for keys id1 though id5 checked! (The issue also occurs when I select more keys than are selected in the root .gpg-id.)

It seems that checkmarks for the key selection dialog in subfolders are only filled in according to the .gpg-id file in the root folder.

In my opinion the behavior should be: Check if there is a local .gpg-id in the currently selected folder. If so, display checkmarks only for these key ids. If not, fall back to the folder one level above and look for .gpg-id there. Iterate all the way up to root folder if necessary until you find a .gpg-id.

[annejan]

I've just tried to reproduce this behaviour, on my MacOS (work) machine, but it behaves as intended for me.

@Alixerid, could you tell me what version you are running and more important on which OS?

[Alixerid]

Thanks for trying to reproduce. I am using Windows 7 and QtPass 1.1.4 (have not tried other OSes)

[annejan]

I'll download a Windows 7 image from modern.ie and test.

To be honest I've automated the whole Windows building and packaging of QtPass, since I haven't owned a Windows machine in years. Actual testing on Windows is minimal . .

[annejan]

I can indeed confirm your issue, thanks for notifying us!

I hope to find some time to fix this over the weekend.

[EdoaLive]

Hi!
Same problem here with QtPass 1.1.6
In addition, i found that the "users" per-folder context-menu can be used to creates per-folder .gpg-id, but when (re-)opened always read the .gpg-id in main folder.

Edit: sorry, found out that my "addition" was already stated by OP.

[kafferejsarn]

This is still an issue with the 1.2.0 version in windows.
I'm running with native pass support on a local repository, not using external pass command or git.
I have a subdirectory where I want to use less secure keys but only the keys present in .gpg-id in the root directory are used.

[EdoaLive]

Pull #22 should have made it, I still didn't try 1.2.0 but I remember I worked this around manually editing .gpg-id files

[kafferejsarn]

EDIT: My problem is not that the .gpg-id is not updated by qtpass but that qtpass don't use the gpg-id i the sub directory when encrypting and possibly not when dectypting.

I'm not using 1.2.0 anymore since I learned about the quite serious debug password clear text leak which seam not to have been fixed in an official release yet... I noticed the problem in 1.2.0, that's why I started search the issues sections in github.
In Windows I don't seam to have the option to run native pass as it seam not ported in a good way to windows so I'm stuck with qtpass own implementation of pass-like behavior. Or am I wrong?
I would really like this feature to work as I want some of my keys to be protected using a hardware token and some to more easily accessible without use of extra hardware.
I store my key-directory on a NextCloud library. Maybe it is some kind of strange access settings problem? I cannot see any difference in access rights when comparing .gpg-id in root or in my sub directory though...

[EdoaLive]

I'm trying 1.2.0 now, I see the UI does not look at the .gpg-id at all (using button Users on selected folder).
Btw, how do you check access rights on crypted files? I thought the only way was to try to decode them with the right private key, is there another way?
I'm using the internal implementation too.

[kafferejsarn]

I mean access rights to gpg-id file. If the program is not allowed to read the file for some reason it obviously will not be used :)
The expected behavior for qtpass should be to use the content of .gpg-id but it ignores every instance of .gpg-id except for the file in the root. Or so it seams.
I'm now on 1.1.6 until 1.2.1 is released with a fix for the information leak.

[annejan]

Will get on it as soon as I have had some sleep (after new-year)

[kafferejsarn]

Great!
Not sure what you will get on, but both the .gpg-id issue and the info leak are, from my point of view, important... where the leak is a worse problem...

Have a really good new years eve!
(and a good sleep after that :)