frr icon indicating copy to clipboard operation
frr copied to clipboard

FRR Debian repo - instructions not inline with Debian best-practice

Open udf2457 opened this issue 3 years ago • 5 comments

Re: https://deb.frrouting.org/

As per https://wiki.debian.org/DebianRepository/UseThirdParty

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.

A sources.list entry SHOULD have the signed-by option set. The signed-by entry MUST point to a file, and not a fingerprint.

Should you require further background beyond the above Debian wiki link, see also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861695 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877012

udf2457 avatar Aug 06 '21 09:08 udf2457

I don't think this is a high priority for us but thank you for pointing it out.

@eqvinox any thoughts here?

qlyoung avatar Aug 06 '21 15:08 qlyoung

Based on a copy/paste from instructions on your site, this is the sort of thing (untested, you will probably need to quote the echo because of [ !)

curl https://deb.frrouting.org/frr/keys.asc | gpg --dearmor > /usr/share/keyrings/org.frrouting.frr.gpg
FRRVER="frr-stable"
echo deb  [signed-by=/usr/share/keyrings/org.frrouting.frr.gpg] https://deb.frrouting.org/frr $(lsb_release -s -c) $FRRVER | sudo tee -a /etc/apt/sources.list.d/frr.list
sudo apt update && sudo apt install frr frr-pythontools

N.B. Ideally, as per the Debian standards ("The reason why we avoid ASCII-armored files is that they cannot be used directly by SecureApt.") , you should be publishing the binary gpg on your server. If you want to publish an ascii armored version alongside it, that's up to you, but the gpg should really be there

$ cat /etc/apt/sources.list.d/org.frrouting.frr.list 
deb [signed-by=/usr/share/keyrings/org.frrouting.frr.gpg] https://deb.frrouting.org/frr buster frr-stable
$ gpg --list-packets /usr/share/keyrings/org.frrouting.frr.gpg  | head
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
        version 4, algo 1, created 1540465594, expires 0
        pkey[0]: [4096 bits]
        pkey[1]: [17 bits]
        keyid: 1FD5839895F57FDA
# off=528 ctb=b4 tag=13 hlen=2 plen=43
:user ID packet: "David Lamparter <[email protected]>"
# off=573 ctb=89 tag=2 hlen=3 plen=590
:signature packet: algo 1, keyid 1FD5839895F57FDA

udf2457 avatar Aug 06 '21 16:08 udf2457

From Ubuntu 22.04 LTS, man apt-key

Recommended: Instead of placing keys into the /etc/apt/trusted.gpg.d directory, you can place them anywhere on your filesystem by using the Signed-By option in your sources.list and pointing to the filename of the key. See sources.list(5) for details. Since APT 2.4, /etc/apt/keyrings is provided as the recommended location for keys not managed by packages. When using a deb822-style sources.list, and with apt version >= 2.4, the Signed-By option can also be used to include the full ASCII armored keyring directly in the sources.list without an additional file.

https://manpages.ubuntu.com/manpages/jammy/man8/apt-key.8.html#deprecation

If I use the instructions provided at https://deb.frrouting.org/, it results in the following warning when running apt update|upgrade.
W: https://deb.frrouting.org/frr/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

netravnen avatar Jul 22 '22 13:07 netravnen

Storing the key 1:1 as /etc/apt/keyrings/frr.asc (root:root, 0644), and the source file as

curl -s https://deb.frrouting.org/frr/keys.asc | \
  sudo tee /etc/apt/keyrings/frr.asc
FRRVER="frr-stable"
echo "deb [signed-by=/etc/apt/keyrings/frr.asc] https://deb.frrouting.org/frr $(lsb_release -s -c) $FRRVER" | \
  sudo tee /etc/apt/sources.list.d/frr.list

Gets rid of the apt warning message mentioned above.

% cat /etc/apt/sources.list.d/frr.list 
deb [signed-by=/etc/apt/keyrings/frr.asc] https://deb.frrouting.org/frr jammy frr-stable

netravnen avatar Jul 22 '22 13:07 netravnen

I don't think this is a high priority for us but thank you for pointing it out.

@eqvinox any thoughts here?

@qlyoung Personally, I think the installation instructions should be updated, as the minimal level of effort, to avoid user inquiries regarding the warning message.

netravnen avatar Jul 22 '22 13:07 netravnen

Updated/fixed on package host.

eqvinox avatar Jan 02 '23 12:01 eqvinox