Thunderbird caches and does not automatically refresh the content of pubring.pgp
Categories
(MailNews Core :: Security: OpenPGP, defect)
Tracking
(Not tracked)
People
(Reporter: neal, Unassigned)
References
Details
(Whiteboard: tb-crypto-downstream-request)
The first time an OpenPGP function is used, Thunderbird scans the content of the pubring.gpg and secring.gpg files and caches the results. Thunderbird only updates the cache if the user goes into the OpenPGP Keyring Manager and selects File and then Reload Key Cache. This is annoying if an external program updates pubring.gpg in order to synchronize the public keyring across different computers.
It would be nice if Thunderbird would either drop the cache and just let RNP worry about managing the keyring, or if Thunderbird would watch the files (e.g., on Linux using inotify) and then reload them as required.
|
||
Comment 1•3 years ago
•
|
||
In general we don't support letting external applications poke the Thunderbird internal files, which I think these should be considered to be. So this might be wontfix.
Is there any API available to modify the keyring? I understand from the Mailfence and Thunderbird partnership announcement that functionality like this will be added:
Thunderbird, will benefit from an automatic sync with all of the Mailfence tools: email, calendar, contacts, and encryption keys.
(my emphasis)
Currently, the Octopus implements a Parcimonie-like service. If a key has been superseded, Sequoia may find it (e.g., in WKD). Unfortunately, the user will only notice when they restart Thunderbird. Even if Thunderbird doesn't want to support the Octopus, Parcimonie-type of functionality could be added to RNP, and then something like this would be needed.
Finally, people are doing this anyway so it would be good to support them.
|
|
||
Comment 3•3 years ago
|
||
There's no API for something like that.
|
||
Comment 4•2 years ago
|
||
I'd like to avoid having to watch the external file for automatic changes. It would introduce additional complexity into the application code. The files on disk are supposed to be a private property of the application, and should never get modified by directly by other applications. And we should avoid support burdens, we shouldn't give any guarantee that the storage format is stable.
Any refreshing of keys should be implemented at the Thunderbird application layer.
|
|
||
Comment 5•8 months ago
|
||
I think Thunderbird should implement automatic refreshing of public keys from public sources.
The reason why it doesn't yet is that I'm worried about the user's privacy, as a network observer could learn about a user's contacts with OpenPGP keys.
I think that refreshing should use a mechanism that hides that information from a network observer.
It has been mentioned that keys could be refreshed through Tor, as implemented by Parcimonie, which was mentioned above.
Unfortunately Tor may not be accessible for many users. I think Thunderbird's default refreshing mechanism shouldn't depend on Tor, and still offer some privacy.
I'd like to investigate if we could OHAI (Oblivious HTTP).
Or maybe we could use a camouflage-mixing approach?
I've described the idea on the KOO mailing list and I'll be curious to hear feedback, see here:
https://lists.hostpoint.ch/archives/list/koo-voting@enigmail.net/thread/MRLXF4STUA5MCUUJ7KC2C7MXKEQTFXH6/
|
|
||
Comment 6•4 months ago
|
||
I would like to mark this particular bug as wontfix.
This bug here requests that Thunderbird allows its private configuration file to be externally modified.
This creates challenges for synchronnization. The current implementation will cache data in memory, and simply flush it to disk, but doesn't expect that it would have to synchronize with modified data on disk.
I prefer to avoid this complexity.
I think Thunderbird needs to implement key refreshing itself.
I will file a separate bug for that.
Description
•