Tails signing key can't be imported from Seahorse with the default key files filter
Tails signing key as we propose to download it (https://tails.boum.org/tails-signing.key) can’t be imported in Seahorse without changing its extension to “.asc”
It seems to be a Seahorse issue (same behavior in Debian Sid), since .key is supposed to be a valid mime type.
Related to Tails -
Related to Tails -
|Blocks Tails - Feature #16209: Core work: Foundations Team||Confirmed|
#3 Updated by intrigeri 2018-02-08 07:55:26
- Assignee changed from intrigeri to goupille
- Target version set to Tails_3.6
- QA Check set to Info Needed
- this works fine for me in Tails 3.5 (thanks to the fix we applied 2 years ago in
config/chroot_local-includes/etc/skel/.local/share/applications/mimeapps.list); goupille, can you reproduce this problem on Tails?
- no update on the upstream bug (https://bugs.freedesktop.org/show_bug.cgi?id=93656) which explains why the problem still exists outside of Tails.
Now, I suspect our reasons for using the
.key extension are obsolete: IIRC we did that so the web server would set the correct MIME type, so when clicking on the link the user would be proposed to import the key with
- in current Tails this is irrelevant as we never propose the user to open files downloaded with Tor Browser using an external app
- on current Debian sid, Chromium proposes me to save the key to disk, not to open it
- on current Debian sid, Firefox proposes me to open the key with “Import key” (i.e.
- I didn’t test with Tor Browser in a less constrained environment, where opening downloads with an external app is allowed.
Once goupille confirms this bug does not affect current Tails, let’s reassign to our tech writers so they can test what happens if we renamed the file to
.asc and decide what to do. Another option could be to configure the web server to force the correct MIME type for these files, regardless of their extension; I don’t know if this will override the file association used by Chromium, Firefox or Tor Browser outside of Tails.
#5 Updated by goupille 2018-02-08 13:00:20
With tails 3.5, in a sense, I’m still affected by this bug : in nautilus the file is seen as a libreoffice file, and when I open seahorse>file>import the file is not listed by default. I need to switch “All key files” to “All files” to see it, then I can import it. I think it was the case also with previous versions.
so the signing key can be imported into seahorse, but not as easily as it should imo.
anonym told me that the .key extension was maybe chosen over .asc to make it explicit it was not a signature file.
#8 Updated by sajolida 2018-05-04 18:43:18
- Assignee changed from sajolida to intrigeri
- QA Check set to Info Needed
Adding to what goupille described: in Tails tails-signing.key is displayed as a LibreOffice presentation but, when I double-click on it, it gets imported by Seahorse. Still, I confirm that it is not listed in Seahorse when doing File → Import…
I think the “.key” extension was chosen to both explicit that the file is a key (with GnuPG “.asc” can mean pretty much anything). Maybe also to help our web server assigning to correct MIME/Type.
Shall I switch to using “.asc”?
#10 Updated by intrigeri 2018-05-07 12:18:23
- Subject changed from Tails signing key can't be imported into Seahorse to Tails signing key can't be imported from Seahorse with the default key files filter
- Target version changed from Tails_3.8 to Tails_3.9
- QA Check deleted (
- Type of work changed from Research to Communicate
> Still, I confirm that it is not listed in Seahorse when doing File → Import…
FTR this is because of https://bugs.freedesktop.org/show_bug.cgi?id=93656 that I’ve mentioned above (corresponding Seahorse source code. A patch was proposed upstream a month ago. I’ve juste pinged on the bug report.
> I think the “.key” extension was chosen to both explicit that the file is a key (with GnuPG “.asc” can mean pretty much anything).
> Shall I switch to using “.asc”?
tl;dr: not yet (and hopefully never).
It’s not obvious to me that the usability improvement we would get from this change compensates the usability regression it would cause. Regardless, given there’s a patch proposed upstream that fixes the root cause of this problem, I’d rather work on fixing that root cause there instead of seeing us spend time on workarounds that might become unneeded in a year (and then if we keep these workarounds in place, we’ll still have the usability regression but it won’t be justified anymore with another improvement).
#12 Updated by intrigeri 2018-06-27 08:02:15
- Type of work changed from Communicate to Code
Upstream has reviewed the patch and requested changes. The author of the patch proposed upstream wrote “I’m probably not going to follow up beyond this”. So let’s take it over and try to get the patch into a shape that can be applied upstream, released and packaged in time for the Buster freeze. This is a good candidate for our new FT members so let’s reassign it during our meeting tomorrow.
#15 Updated by lamby 2018-07-27 12:01:44
Updated patch https://bugs.freedesktop.org/show_bug.cgi?id=93656#c5
#19 Updated by lamby 2018-08-17 14:30:40
- Assignee changed from lamby to intrigeri
After a ping earlier today, this was just marked as “WONTFIX”:
Advice on how to proceed?
#20 Updated by intrigeri 2018-08-17 15:47:52
- Assignee changed from intrigeri to lamby
> After a ping earlier today, this was just marked as “WONTFIX”:
Wrong URL or wrong ticket?
#21 Updated by lamby 2018-08-17 15:59:43
Wrong ticket! I pinged another tails-related bug on freedesktop.org a few hours ago and, when this one came through, I naturally assumed it was this one.. especially after receiving no response for weeks…
To clarify, https://bugs.freedesktop.org/show_bug.cgi?id=93656#c7 remains the latest status (keeping hold of this one)
#26 Updated by lamby 2018-10-18 20:41:17
This was recently “closed” upstream due to freedesktop.org moving to GitLab. I have thus re-created the patch and submitted a merge request:
#27 Updated by lamby 2018-10-19 19:22:59
Upstream have replied.
I have responded.
#28 Updated by lamby 2018-10-20 00:52:20
This has now been merged upstream:
I will request a release in ~10 days.
#29 Updated by intrigeri 2018-10-21 08:44:31
- Target version changed from Tails_3.10.1 to Tails_4.0
> This has now been merged upstream:
Given Buster is getting close on the horizon, nobody ever reported this bug in Debian, and it affects only a small minority of our users, IMO it’s not worth us proposing this as a Stretch update or even patching
shared-mime-info in Tails. So I think the best course of action is:
- Get this released upstream (which you’re already on :)
- Ensure this is released with Buster
- Drop the corresponding workarounds in
#30 Updated by lamby 2018-10-29 14:53:46
Pinged upstream for a release: https://gitlab.freedesktop.org/xdg/shared-mime-info/merge_requests/5#note_53422
#31 Updated by lamby 2018-11-02 08:44:43
Pinged upstream for release: https://gitlab.freedesktop.org/xdg/shared-mime-info/merge_requests/5#note_54359
#32 Updated by lamby 2018-11-12 08:51:53
Upstream say they don’t have time to do a release: https://gitlab.freedesktop.org/xdg/shared-mime-info/merge_requests/5#note_76365
I’ve therefore filed it in Debian here: https://bugs.debian.org/913550
#43 Updated by segfault 2019-04-20 09:14:32
- Assignee deleted (
- % Done changed from 50 to 60
- QA Check set to Ready for QA
- Feature Branch set to bugfix/15213-signing-key-cant-be-imported-from-seahorse
In an image built from the feature branch, when I download the
- In Nautilus, it has as an icon like a text file
- On double click, it is opened via seahorse (but the import fails because it’s already imported)
- It is shown in the seahorse “Import Key” file chooser dialog
I think that’s all the expected behavior, so marking for ready for QA.
#45 Updated by segfault 2019-04-20 23:16:49
- Feature Branch changed from bugfix/15213-signing-key-cant-be-imported-from-seahorse to bugfix/15213-signing-key-cant-be-imported-from-seahorse+force-all-tests
> (We still have to wait for and check Jenkins test results)
The PGP related scenarios were not run, retrying with
#48 Updated by intrigeri 2019-04-26 12:32:20
- QA Check changed from Ready for QA to Pass
> In an image built from the feature branch, when I download the
> * In Nautilus, it has as an icon like a text file
> * On double click, it is opened via seahorse (but the import fails because it’s already imported)
The import also fails after deleting the key from the keyring: I see a notification that says “keys were found but not imported”. And indeed the key is not in the keyring. Same if I run
seahorse-tool --import tails-signing.key by hand so I think that’s another issue, revealed by fixing the problem this ticket is about. Same when trying to import my own key so it’s not specific to the Tails signing key. I’m not going to bother trying to reproduce on sid nor ensuring this is known upstream: Seahorse is basically unmaintained and I doubt this will lead anywhere.
> * It is shown in the seahorse “Import Key” file chooser dialog
Confirmed, works fine.
#53 Updated by segfault 2019-04-28 15:34:51
- Status changed from In Progress to Fix committed
> @segfault, it would be sweet if you merged devel into feature/buster and made this new patch apply cleanly at build time: it currently makes feature/buster FTBFS. Feel free to push the resulting fix straight to feature/buster. Thanks in advance!