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.
Perhaps sudo curl -s -o /usr/share/keyrings/syncthing-archive-keyring.gpg https://syncthing.net/release-key.gpg needs to include both locations.
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.netsudo 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 apt-key add.
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.
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