The public key is available at
/usr/share/keyrings as installed by
https://apt.syncthing.net/. However, after upgrade to Ubuntu 22.04 the key is not available and an error follows
sudo apt update.
If the key is moved/copied to
/etc/apt/trusted.gpg.d no error is shown and the update completes successfully.
sudo curl -s -o /usr/share/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg needs to include both locations.
It’s too bad there isn’t a standardized tool or script to add APT keys to the right place. Could have called it
apt-key or something.
Do you have the correct entry in sources.list? That points to the
/usr/... path and is required, while the one in
/etc/... is global:
echo “deb [signed-by=/usr/share/keyrings/Syncthing-archive-keyring.gpg] https://apt.syncthing.net/ Syncthing stable” | sudo tee /etc/apt/sources.list.d/Syncthing.list
apt-key because it does the wrong thing instead of adapting it to to the right thing was definitily a super bad decision.
I remove the key file from
/etc/apt/trusted.gpg.d and amended the
/etc/apt/sources.list.d Syncthing.list file to
deb [signed-by=/usr/share/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing candidate #Syncthing and sudo apt update works again.
Interesting though, other keys for trusted apt repos (KeepassXC) are in
/etc/apt/trusted.gpg.d. And Syncthing no longer appears in the ‘Other Software’ section under Synaptic repositories.
Yeah well, that’s the thing: Both approaches are equivally valid. One of them is more and one a less restrictive. Probably whoever updated the apt.syncthing.net likes the restrictive approach. And it looks like Synaptic has some integration with the
/etc/ one but not the other option.
If this is likely to be a greater problem for users with
apt-key deprecated, is it worth amending apt.syncthing.net
sudo curl -s -o /usr/share/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg to install the key in both /etc/apt/trusted.gpg.d and /usr/share/keyrings/ ? Just to cover all bases.
The key MUST be downloaded over a secure mechanism like HTTPS to a location only writable by root, which SHOULD be
/usr/share/keyrings. The key MUST NOT be placed in
/etc/apt/trusted.gpg.d or loaded by
I think we’re following best practices.
Thanks @bt90 but the problem arose because, although the key was in
/usr/share/keyrings, it was not available to apt and prevented Syncthing from updating in Ubuntu 22.04. This only happened after I upgraded, from the previous version 21.10, which, like earlier Ubuntu version, could read the key in /usr/share/keyrings…
If Debian is so definitive about the location, why is /etc/apt/trusted.gpg.d created and used by ppa repos, such as Mozillateam for Thunderbird and Libreoffice? BTW, these apps upgraded successfully, with only Syncthing’s public key causing an issue. Both locations are only writable with root privileges.
I’m talking about the new instructions on apt.syncthing.net which already come with the
Well, it’s already been established that the upgrade problem were because of a discrepancy between the key location (
/usr/...) and the apt-list-entry (missing signed-by option). The instructions on apt.syncthing.net do work as is.
That PPAs and other 3rd party repos don’t follow what debian postulates isn’t that surprising - PPAs aren’t a debian thing, and many 3rd parties target ubuntu (no idea what their policies are).
Thanks both. I appreciate that the new instructions on apt.syncthing.net are correct. I posted my experience to help others who might have had an old entry in /etc/apt/sources.list.d which does not point to /usr/share/keyrings.
I installed Syncthing years ago (thanks devs) which might be why Syncthing.list does not refer to /usr/share/keyrings.
Taking @imsodin advice, I move the key back to that location and amended the Syncthing.list file.
Out of interest, the Syncthing key is the only non-Debian/Ubuntu key in /usr/share/keyrings, so maybe Syncthing devs are the only ones doing the right thing!
I guess what happened is that you (and many other users) needed to replace they key as it expired. So you followed the instructions on apt.syncthing.net for obtaining the key, but understandably didn’t do the apt-list part again. Thus you ended up with an old apt-list entry and a key in the new location, which isn’t compatible.
I don’t know about “right”. The right thing to do concerning debian is not adding third party repos. Given the above realistic scenario, we might as well use the more permissive
/etc/... approach. The security risk seems minimal, it just guards against anyone that obtains our private key (not going to happen ) being able to use it to sign any package that’s not in the Syncthing repo. However that doesn’t seem to achieve much to me: If they managed to compromise us that far (keys are well protected), they are more likely to be able to also compromise our repos where our key works, than any other 3rd party repo.
@imsodin Thanks for your patience and explanation. I now understand a little better how keys work to protect third-party software. As you say, the more permissive /etc/apt seems to carry very little risk. Cheers
Can we add a pinned post? This topic will come up a lot in the coming days and especially after the first patch release for 22.04.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.