Integrate with git support

[mdellweg]

Secrets, as well as metadata should be subject to git operation if configured.

[3nprob]

Could you elaborate on this issue - how would it work in difference compared to how it's working today?

Does it refer to the password-store folder being a git repo? Just like for pass/gopass, that should already work fine, managed outside of pass_secret_service. What is the requirement for this feature to be considered done?

[mdellweg]

This tool creates supplemental file to the usual pass operation (.aliases; *.properties). We need to ensure that these are part of git commits created by pypass for the corresponding password entries.

[3nprob]

Ah, right. Would the below be an accurate description of desired behavior?

When pass_secret_service adds a new file to the password store, or makes changes to an existing file, invoke pypass git add $FILE, followed by pypass git commit. This behavior should be optional and opt-in through configuration.

[mdellweg]

It should be autodetected based on the password store in use being "git aware".

[Thaodan]

This tool creates supplemental file to the usual pass operation (.aliases; *.properties). We need to ensure that these are part of git commits created by pypass for the corresponding password entries.

Should those go into the password metadata? Similar things were done for browser extensions.

[michaelk83]

Aliases are not associated with any particular password, so can't go there. Properties, assuming he means Secret Service's lookup attributes, may fit into metadata, but they're usually not meant to be encrypted (I'm not sure if metadata is or not). They're primarily intended for password lookups.
https://specifications.freedesktop.org/secret-service/latest/ch04.html
https://specifications.freedesktop.org/secret-service/latest/ch05.html

[Thaodan]

Aliases are not associated with any particular password, so can't go there. Properties, assuming he means Secret Service's lookup attributes, may fit into metadata, but they're usually not meant to be encrypted (I'm not sure if metadata is or not). They're primarily intended for password lookups. https://specifications.freedesktop.org/secret-service/latest/ch04.html https://specifications.freedesktop.org/secret-service/latest/ch05.html

Hm I'm not exactly sure but was such meta data not resolved via the filesystem path to the key file. Even aliases are usually just symlinks to the password file.

[michaelk83]

The Secret Service API allows an arbitrary set of lookup attributes to be associated with each password, where each attribute is a key-value pair. So I don't think the filesystem path is enough for this. But this begins to enter implementation details specific to this particular adapter service, which I'm less familiar with. Keep in mind that client applications talking to the Secret Service API are not aware which backend is being used, or how it works. They only know the API specification.