Allow the use of user's PGP keyring
Categories
(MailNews Core :: Security: OpenPGP, enhancement)
Tracking
(Not tracked)
People
(Reporter: gharbeia, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
Enigmail utilised the user's OpenPGP keyring, which is the generally recommended practice, because it facilitates the central management of keys. The benefits of this is streamlined backup, updating, and availability to other tools and applications of a single key ring, unless the user decides to avail different keyrings to different applications.
Since the implementation of OpenPGP functionality within the core of Thunderbird, however, it is now only possible to import keys into a separate key ring managed by Thunderbird which is not available to other applications.
|
||
Comment 1•3 years ago
|
||
Generally we don't want to share access to application private files. There are many problems that could result from that (data loss or corruption, other unforeseen issues). The file format is also not standardized + the trust model we use is different.
|
Reporter | |
Comment 2•3 years ago
|
||
I think it's premature to close this as wontfix before a reasonable discussion, Magnus.
Breaking the integration of the users' experience is not to be taken lightly, specially in applications where users usually have several dependencies around an important datastore like the OpenPGP keyring which is called "keyring" specifically for this reason.
I, personally, in so many years of using PGP with Enigmail and other applications of OpenPGP have never witnessed data corruption in the keyring, which is mostly accessed for reading.
The file format is a de facto standard set by the GPG implementation, and has been used without a hickup, that I know of, for the past 15 years.
Is there evidence on the above issues cited as rationale, that you would like to share with us?
I'd also like to know more about the differences in the trust model in Thunderbird, since this is something in the core of how PGP is used. Any documentation on that?
I understand that it may not be your priority as a developer, but others may be interested in submitting a patch perhaps. So leaving the feature request open until further discussion takes place is the right way, in my opinion.
|
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 3•3 years ago
|
||
It would introduce a huge technical complexity to allow parallel access to Thunderbird's private storage. Currently, we simply read all information at startup, keep all information in memory, and write to disk every time a change is made.
Allowing others to access the raw storage would currently lead to direct overwriting of changes made by others every time Thunderbird makes a change.
Allowing access without corruption would require us to either use locking and re-reading all information from key storage every time we need it, resulting in a noticeable slowdown.
There are other issues, like additional information that Thunderbird may manage separately from the key files.
I think we shouldn't do it.
We shouldn't directly use the GnuPG keyring file, because the file format is controlled by the GnuPG project, it could change at any time, and for licensing reasons we cannot bundle the GnuPG software.
I agree with wontfix.
|
|
Reporter | |
Comment 4•3 years ago
|
||
I understand where you prefer to avoid increasing the complexity. However, there are middle ground solutions that would make the basic functionality available, yet allow for more advanced use. The integration of PGP functionality within Thunderbird should not be at the expense of reducing its usefulness to the class of users, individuals and groups, who have been dependent on it, whose use-cases constitute the prevailing ones.
Such middle ground solutions include allowing optional use of GnuPGP. After all, many applications solve the undistributability of components by providing links and instructions and/or facilitating user-initiated action to grab them.
The file ring format could change anytime, indeed. But so does everything else in every system we use and developed, correct? But how often does this happen in the case at hand? It's not like frequent, random sudden breaking changes. At least not in a piece of software like GnuPG.
While I haven't done any empirical measurements, my impression of using GnuPG's external keyring with Enigmail is that it didn't cause noticeable delay, and I have had sizable keyring (100+ entries). Have any such measurements been done?
Extra information about contacts managed by thunderbird can be updated with information obtained from their master sources, preserving the functionality specific to Thunderbird, while not breaking anything else. I'm not saying it is effortless.
|
||
Comment 5•3 years ago
|
||
This can be resolved in other way, by writing some custom daemon (or even shell script, which is run by cron), which would check Thunderbird's pubring for modification time/hash, and if it was changed - run GnuPG and import pubring. In an opposite way it may alert that something new was added to the GnuPG and export changed things so they may be imported manually to the Thunderbird.
This omits secret keys as they are not changed often and can be updated manually.
|
|
Reporter | |
Comment 6•3 years ago
|
||
(In reply to Nickolay Olshevsky from comment #5)
This can be resolved in other way, by writing some custom daemon (or even shell script, which is run by cron), which would check Thunderbird's pubring for modification time/hash, and if it was changed - run GnuPG and import pubring. In an opposite way it may alert that something new was added to the GnuPG and export changed things so they may be imported manually to the Thunderbird.
It can be solved this way. This assumes either:
There's a formal way to export keys from Thunderbird's repository, and requires having a running Thunderbird process to do the job.
OR
A tool provided with thunderbird that can do this, to interact with.
OR
The specification of the Thunderbird's key store is well documented and stabilized, and a tool be written to read/write it.
Moreover, I do not know what capabilities Windows has in regard to running cron jobs, but in general I find having a constantly running process to monitor a change that is not likely to happen that frequently to be an overkill. Don't you agree?
|
|
||
Comment 7•3 years ago
|
||
Thunderbird (on trunk/beta) is now also shipping the rnp command line tools. I'm not sure about the exact commands, but I'd assume using these there would exist a semi-easy way to script this import/export using that, if someone so desires.
|
|
||
Comment 8•3 years ago
|
||
(In reply to Ahmad Gharbeia from comment #6)
(In reply to Nickolay Olshevsky from comment #5)
It can be solved this way. This assumes either:
There's a formal way to export keys from Thunderbird's repository, and requires having a running Thunderbird process to do the job.
Right now public keyring (pubring.gpg) conforms to OpenPGP transferable keys format and may be imported to gpg and other implementations as easy as gpg --import pubring.gpg or rnpkeys --import pubring.gpg. This would not import key trust flags, but anyway any implementation has own format for that.
A tool provided with thunderbird that can do this, to interact with.
The specification of the Thunderbird's key store is well documented and stabilized, and a tool be written to read/write it.
It is documented in RFC and I don't see reasons to change this in future. But that's up to developers.
Moreover, I do not know what capabilities Windows has in regard to running cron jobs, but in general I find having a constantly running process to monitor a change that is not likely to happen that frequently to be an overkill. Don't you agree?
I didn't code for Windows for a while, but there definitely should be some API to monitor changes to the filesystem and get callback in case of changes.
|
|
Reporter | |
Comment 9•3 years ago
|
||
(In reply to Nickolay Olshevsky from comment #8)
It is documented in RFC and I don't see reasons to change this in future. But that's up to developers.
Well, my comment was in response to the proposition that the keyring format is controlled by the OpenPGP implementation and could be changed at anytime, and citing this as justification for not using the OpenPGP keyring.
Description
•