Request autoconnect of interfaces for thunderbird

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

1 Like

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:

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 …



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

  • install a computer with Ubuntu, create a gpg key using gupnp because you need it for e.g Debian uploads
  • install thunderbird from the snap
  • try to encrypt an email using your existing gpg key

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.

1 Like

@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.

@seb128 - can you confirm if gpg-keys is needed at all with portals support? If not, this reduces down to just cups-control from what I can see. The current process for auto-connect of cups-control is limited to printing and design applications where printing is part of the expected workflow. As such, Thunderbird does not strictly fit this definition as it is not a printing / design application. However, I tend to agree that printing of emails is a pretty common operation (similar to say printing of web-pages as we grant for chromium) - and so I vote +1 for auto-connect of cups-control for thunderbird myself.

gpg-keys is needed only for the automatic migration from old profiles which used enigmail or for the gpg configuration dialog to be able to list existing keys (which isn’t mandatory since it’s easier to pick from a list than go pick a file on disk from the portal)

@seb128 so the issue I have is that gpg-keys is pretty sensitive and so I don’t feel that it should be auto-connected - is there a way we could have thunderbird first try and detect whether gpg-keys is connected (snapctl is-connected gpg-keys) just before showing the dialog to list existing keys, and if not ask the user to connect it? This would provide a good UX IMO and allow this to be manually connected still.

It would make things easier if ubuntu LTS update debs to 78.x which will make migration case ignorable as virtually all users will be past it then.

AFAIK every other distro already did update including debian oldstable and it’s surprising ubuntu didn’t considering there are dozens of unfixed CVE in old release.

@alexmurray right, I’ve edited the request to remove the gpg-keys item which let the cups-control one. The 'import dialog" is not going to list existing keys in the main view but it’s possible to go and pick an individual file which should be enough. We can still try to do something as you suggested also for migration

@Reynolds5 the update is being worked but isn’t trivial, see for details. The 78.5.0 update is in focal-proposed now (to get extra testing before going to securite)

Hopefully with those questions sorted out we can get another vote on the printing interface autoconnect

+1 to auto-connect cups-control since it is expected that an email client be able to print emails. Ideally this would use the printing portal, but the snap doesn’t do this yet.

2 votes for, 0 against for auto-connection of cups-control. Granting auto-connection. This is now live.