Would it be possible to get those interfaces autoconnected?
Thanks!
(edit, removing request for
AFAIK thunderbird uses its own internal gpg keys storage so gpg-keys permission would make sense only at first start to do the migration.
It still needs to access the actual key files on disk though…
Yes but those key files are stored in TB config where it doesn’t need access permission.
it needs read access to the files of the non-snap thunderbird install if you want to migrate settings and config at snap installation time (not sure why this actually needs to be discussed here)…
Migrating keys and migrating config are orthogonal. Keep in mind that migrating keys is relevant only when the old installation was on 68.x version.
It’s not only migration though, to be able to decrypt email whatever the software stack used it needs to be able to access your existing gpg private key right? so new configs also need to be able to read or import the key
Removing the request for removable-media since the snap uses gtk portals now so that’s not needed anymore
It’s not only migration though, to be able to decrypt email whatever the software stack used it needs to be able to access your existing gpg private key right? so new configs also need to be able to read or import the key
Well, this is the part you don’t understand, TB has its own key storage, not in .gnupg but inside its own config. It also doesn’t call gpg binary to encrypt and decrypt messages but uses something called rnp. It may need this permission only when upgrading from 68.x to copy the keys from old dir to the new one (but snap is already on 78.x) and only once:
https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_where-does-thunderbird-store-openpgp-keys
There is also hidden option to use external gpg which make it work the old way but it’s not default and it doesn’t make sense to use auto-connect for interface for something that user needs to explicitly switch on anyway. It’s sufficient to have this interface as an opt-in.
how would users of the/a deb that switch to the snap know about having to connect that interface then, to get their old key imported ? would you expect the snap maintainer to sit down and develop a GUI to tell them (instead of simply having the interface connected which doesnt do any harm) ?
You quoted my sentence out of context. It was tied to external gpg use case.
I myself repeated over and over that auto-connect gpg-keys permission is needed at migration time but it was you who insisted it is needed for normal usage too. In order to cast vote you must understand why and when this permission is needed while you clearly didn’t.
If this interface doesn’t cause any harm then why it’s not automatically connected? What’s the point if voting this if there is no downside?
there is no dynamic connecting of interfaces “just for migartion purposes”. an interface is either connected or not, this is a permanent setting for auto-connections in the store that can be granted ot revoked per snap, not “per action”.
to not leave former deb users that have enabled gpg stand in the rain during upgrade to the snap this interface needs to be connected or a UI needs to be crafted that tells them about manually connecting (the latter is unlikely to happen so an auto-connection is the way to go) … note also that neither you nor I can “vote” here, we just can express opinions, voting is done by the dedicaed reviewers team.
Expressing opinion is something different than describing why an app need particular permission which is basically stating the fact and reviewers team shouldn’t be misled about facts while doing the voting. If you could just fix gpg-keys permission request description instead of doubling down on incorrect statements there would be nothing to discuss here.
i’m not sure where you see incorrect statements, the request says that FF 78 supports gpg and it would be good to have the interface available without providing a reason, the further discussion showed that it is useful to for migration purposes (which i’m sure the reviewers are fully aware of anyway).
i think all points have been discussed enough to give the reviewers enough info to make their decision, lets leave it to them to cast their vote … there is no reason to go on talking about it just for the purpose of talking. it just makes the topic more complex and adds noise …
1:
2:
Really all reviewers know about openpgp implementation details in thunderbird while even some maintainers as shown above don’t?
I really didn’t expect to make more than one comment here and was only correcting above misleading statements which negated what I said before. I also didn’t thought my every comment requires your answer especially if you are against the noise in discussion. Feel free to not answer for this one.
We probably are talking about different workflow, what I was describing is
Thunderbird is going to need to be able to read that existing key to add it to its store and encrypt your email… but it could be that’s part of what you call ‘migration’ where I use that wording only for a 68->78 transition.
On-demand import key from single file should work with gtk portals similar to what you described in removable-media case. This needs to be confirmed though.
Right, the fileselector portal is used which allows to pick a key without the interface. Thanks for the comments, in that context I’m unsure it would be useful for anything out of the migration now, I will let the reviewers decide if they believe that’s an usecase worth granting autoconnect for or not.
@reviewers did this request get lost in the noise of the discussion here ?
I would suggest, after a discussion, to narrow down the definitive list of interfaces required, and then we can also have the security team provide their feedback. I’ll tag @emitorino for visibility.
