[MIR]: frr
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| frr (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Bug Description
[Availability]
The package frr is already in Ubuntu universe.
The package builds for the architectures it is designed to work on.
It currently builds and works for architetcures: amd64, arm64, armhf, ppc64el, s390x, riscv64
Link to package: https:/
[Rationale]
frr is a fork and replacement for quagga, which is what we have in main but is unmaintained by upstream.
About quagga:
- we have been carrying the same version since bionic
- upstream's git repo is gone (http://
- git mirror at https:/
- mailing lists have crickets (https:/
The proposal is to demote quagga, and promote ffr, for jammy.
[Security]
http://
4 CVEs in older versions (jammy has 8.1)
CVE-2017-15865 - information leak
CVE-2017-5495 - DoS due to memleak
CVE-2019-5892 - DoS
CVE-2020-12831 - (disputed) info leak via an initially empty world readable config file
site:www.
0 hits (the single hit was for the "frr" string in a pgp signature)
Ubuntu:
https:/
https:/
https:/
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package installs services:
/lib/systemd/
Right after installation, one daemon runs as root, the other two as "frr":
root 32148 0.0 0.0 7960 2892 ? Ss 14:02 0:00 /usr/lib/
frr 32161 0.0 0.0 242848 7000 ? Ssl 14:02 0:00 /usr/lib/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000
frr 32166 0.0 0.0 9256 3608 ? Ss 14:02 0:00 /usr/lib/
Many more can be run depending on configuration, though. Default list in /etc/frr/daemons:
bgpd=no
ospfd=no
ospf6d=no
ripd=no
ripngd=no
isisd=no
pimd=no
ldpd=no
nhrpd=no
eigrpd=no
babeld=no
sharpd=no
pbrd=no
bfdd=no
fabricd=no
vrrpd=no
pathd=no
If all are enabled, we get this by default:
frr 1033 0.0 0.0 1722872 9648 ? Ssl 14:42 0:00 /usr/lib/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000
frr 1038 0.0 0.0 173100 9108 ? Ssl 14:42 0:00 /usr/lib/frr/bgpd -d -F traditional -A 127.0.0.1
frr 1045 0.0 0.0 9916 4192 ? Ss 14:42 0:00 /usr/lib/frr/ripd -d -F traditional -A 127.0.0.1
frr 1048 0.0 0.0 9660 3832 ? Ss 14:42 0:00 /usr/lib/frr/ripngd -d -F traditional -A ::1
frr 1051 0.0 0.0 11852 4900 ? Ss 14:42 0:00 /usr/lib/frr/ospfd -d -F traditional -A 127.0.0.1
frr 1054 0.0 0.0 10828 4632 ? Ss 14:42 0:00 /usr/lib/frr/ospf6d -d -F traditional -A ::1
frr 1057 0.0 0.0 11540 4884 ? Ss 14:42 0:00 /usr/lib/frr/isisd -d -F traditional -A 127.0.0.1
frr 1060 0.0 0.0 9388 3532 ? Ss 14:42 0:00 /usr/lib/frr/babeld -d -F traditional -A 127.0.0.1
frr 1063 0.0 0.0 11540 5088 ? Ss 14:42 0:00 /usr/lib/frr/pimd -d -F traditional -A 127.0.0.1
frr 1071 0.0 0.0 9692 5380 ? S 14:42 0:00 /usr/lib/frr/ldpd -L -u frr -g frr
frr 1072 0.0 0.0 9520 5376 ? S 14:42 0:00 /usr/lib/frr/ldpd -E -u frr -g frr
frr 1074 0.0 0.0 10288 3652 ? Ss 14:42 0:00 /usr/lib/frr/ldpd -d -F traditional -A 127.0.0.1
frr 1078 0.0 0.0 9968 3652 ? Ss 14:42 0:00 /usr/lib/frr/nhrpd -d -F traditional -A 127.0.0.1
frr 1082 0.0 0.0 9812 4000 ? Ss 14:42 0:00 /usr/lib/frr/eigrpd -d -F traditional -A 127.0.0.1
frr 1085 0.0 0.0 9232 3376 ? Ss 14:42 0:00 /usr/lib/frr/pbrd -d -F traditional -A 127.0.0.1
frr 1088 0.0 0.0 9204 3136 ? Ss 14:42 0:00 /usr/lib/
frr 1091 0.0 0.0 9496 3596 ? Ss 14:42 0:00 /usr/lib/frr/bfdd -d -F traditional -A 127.0.0.1
frr 1094 0.0 0.0 10460 4052 ? Ss 14:42 0:00 /usr/lib/
frr 1097 0.0 0.0 9256 3472 ? Ss 14:42 0:00 /usr/lib/frr/vrrpd -d -F traditional -A 127.0.0.1
frr 1101 0.0 0.0 9600 3728 ? Ss 14:42 0:00 /usr/lib/frr/pathd -d -F traditional -A 127.0.0.1
- Packages does not open privileged ports (ports < 1024)
The above daemons all listen on unprivileged high ports for the vty interface, but might open privileged ports once configured properly. For example, the RIP routing protocol uses 520/UDP.
- Packages does not contain extensions to security-sensitive software
No. But one could argue that routing is security sensitive.
[Quality assurance - function/usage]
- The package works well right after install
That being said, routing is very site specific. While all the daemons start and run if so requested, definitely some configuration will be needed for them to be useful.
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many and long term critical bugs open
There are just two open bugs in Ubuntu, filed by me: https:/
- one is this MIR
- the other is LP: #1958162, which I found after trying the package out. I think this one must be fixed, because logging is important.
- Debian https:/
I would like to highlight this one: https:/
The current 8.1-1 upload has a build-depends on libpcre2-dev, replacing libpcre3-dev, so maybe it was fixed. Needs to be checked, as I tried some apt-cache show grepping for pcre and couldn't find any.
- Upstream: https:/
Many open and closed bugs, as expected from a busy project. I tried looking for serious ones, but didn't find obvious ones in the first few pages. Going through labels, there wasn't any indicating severity. Using the "security" label returned just one open issue, which might be a corner case and has some technical discussion:
https:/
[Quality assurance - testing]
- The package runs a test suite on build time, if it fails
it makes the build fail, link to build log <TBD>
The build runs a test suite. Last build in jammy:
=======
platform linux -- Python 3.9.8, pytest-6.2.5, py-1.10.0, pluggy-0.13.0 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /<<PKGBUILDDIR>
collecting ... collected 440 items
bgpd/test_
bgpd/test_
bgpd/test_
bgpd/test_
bgpd/test_
bgpd/test_
(...)
Link: https:/
There is no dh_auto_test override. I patched a random test to fail, and the build fail accordingly:
self = <test_aspath.
line = 'basic 4-byte as-path'
okfail = re.compile(
def _okfail(self, line, okfail=re_okfail):
m = okfail.
if m is None:
raise MultiTestFailur
self.output = self.output[m.end() :]
if m.group("ret") != "OK".encode(
> raise MultiTestFailur
E frrtest.
helpers/
---- generated xml file: /home/ubuntu/
=======
FAILED bgpd/test_
FAILED bgpd/test_
================== 2 failed, 433 passed, 5 skipped in 16.40s ===================
make[1]: *** [Makefile:15534: tests/tests.xml] Error 1
make[1]: Leaving directory '/home/
dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
make: *** [debian/rules:33: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
The package runs autopkgtests, and is currently passing on all arches but i386, where it's not available: https:/
[Quality assurance - packaging]
- debian/watch is present and works
lintian is a bit noisy, mostly about documentation issues:
$ lintian -I --pedantic
E: frr changes: bad-distributio
W: frr-doc: embedded-
W: frr-doc: embedded-
W: frr-doc: embedded-
W: frr: groff-message usr/share/
W: frr: groff-message usr/share/
W: frr: groff-message usr/share/
W: frr: groff-message ... use --no-tag-
W: frr-doc: info-document-
W: frr-doc: info-document-
W: frr-doc: info-document-
W: frr-doc: info-document-
W: frr: mismatched-override spelling-
W: frr source: possible-
I: frr: acute-accent-
I: frr: acute-accent-
I: frr: acute-accent-
I: frr: acute-accent-
I: frr: hardening-
I: frr source: out-of-
I: frr: spelling-
I: frr: spelling-
I: frr: spelling-
I: frr: spelling-
I: frr: systemd-
I: frr: typo-in-manual-page usr/share/
I: frr-rpki-rtrlib: unused-override hardening-
P: frr: executable-
P: frr: executable-
P: frr: executable-
P: frr: executable-
P: frr-pythontools: executable-
P: frr-pythontools: executable-
P: frr source: package-
P: frr source: package-
P: frr: renamed-tag manpage-
P: frr source: silent-
N: 24 hints overridden (24 info); 2 unused overrides
The existing overrides are well documented. Example:
$ cat debian/
# function names & co.
frr binary: spelling-
frr binary: spelling-
frr binary: spelling-
frr binary: spelling-
frr binary: spelling-
frr binary: spelling-
# prefixed man pages for off-PATH daemons
manpage-
# personal name
spelling-
- This package does not rely on obsolete or about to be demoted packages.
There is an open question about PCRE3. The latest upload changed the build-dep on libpcre3-dev to libpcre2-dev, which is what we want since PCRE3 is obsolete. I don't see evidence in the build logs, nor in the final package deps, that PCRE2 was used, though. The configure script checks for "pcreposix", which is part of PCRE3, and it is not found (because we installed libpcre2-dev):
Resulting config.h:
/* Define to 1 if you have the `pcreposix' library (-lpcreposix). */
/* #undef HAVE_LIBPCREPOSIX */
It's only checked for if ./configure is given --enable-pcreposix, which d/rules doesn't:
if test "$enable_pcreposix" = "yes"; then
{ printf "%s\n" "$as_me:
$ grep -i pcre debian/control debian/rules config.log
debian/control: libpcre2-dev,
config.
- This package has no python2 or GTK2 dependencies
- The package will not be installed by default
- Packaging and build is easy: https:/
[UI standards]
There are no translations.
It's a server service with sysadmin oriented commands, config file and shell interface (vtysh).
[Dependencies]
There are two, or maybe just one, extra dependencies for which we will need MIRs:
libyang2: https:/
librtr: https:/
[Standards compliance]
This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
Team is already subscribed to the package
This does not use static builds
[Background information]
RULE: - The package descriptions should explain the general purpose and context
RULE: of the package. Additional explanations/
RULE: the MIR report.
RULE: - If the package was renamed recently, or has a different upstream name,
RULE: this needs to be explained in the MIR report.
The Package description explains the package well
Upstream Name is Free Range Routing (frr)
Link to upstream project https:/
This is a fork and replacement for quagga, which is in main already for quite some time. Unfortunately upstream development stopped, and we should not keep quagga in main anymore. Ubuntu has been shipping the same build for many releases already:
quagga | 1.2.4-1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
quagga | 1.2.4-4build1 | focal | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
quagga | 1.2.4-4ubuntu1 | hirsute | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
quagga | 1.2.4-4ubuntu2 | impish | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
quagga | 1.2.4-4ubuntu2 | jammy | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
Related branches
- Robie Basak: Approve
- Canonical Server: Pending requested
- Canonical Server Core Reviewers: Pending requested
-
Diff: 12 lines (+1/-1)1 file modifiedsupported-misc-servers (+1/-1)
| Changed in frr (Ubuntu): | |
| status: | Triaged → In Progress |
| Changed in frr (Ubuntu): | |
| milestone: | none → ubuntu-22.01 |
| tags: | added: server-todo |
| description: | updated |
| Changed in frr (Ubuntu): | |
| assignee: | Andreas Hasenack (ahasenack) → nobody |
| status: | In Progress → New |
| description: | updated |
| Changed in frr (Ubuntu): | |
| assignee: | nobody → Didier Roche (didrocks) |
| Didier Roche-Tolomelli (didrocks) wrote | #1 |
| Changed in frr (Ubuntu): | |
| status: | New → Incomplete |
| Andreas Hasenack (ahasenack) wrote | #2 |
| Andreas Hasenack (ahasenack) wrote | #3 |
| Andreas Hasenack (ahasenack) wrote | #4 |
| Andreas Hasenack (ahasenack) wrote | #5 |
| Didier Roche-Tolomelli (didrocks) wrote | #6 |
| Andreas Hasenack (ahasenack) wrote | #7 |
| Christian Ehrhardt (paelzer) wrote | #8 |
| Changed in frr (Ubuntu): | |
| milestone: | ubuntu-22.01 → ubuntu-22.04-feature-freeze |
| importance: | Undecided → Critical |
| Christian Ehrhardt (paelzer) wrote | #9 |
| Christian Ehrhardt (paelzer) wrote | #10 |
| Changed in frr (Ubuntu): | |
| assignee: | Didier Roche (didrocks) → nobody |
| status: | Incomplete → In Progress |
| Andreas Hasenack (ahasenack) wrote | #11 |
| Andreas Hasenack (ahasenack) wrote | #12 |
| Steve Langasek (vorlon) wrote | #13 |
| Changed in frr (Ubuntu): | |
| status: | In Progress → Fix Released |
[Summary]
Thanks a lot Andreas for the detailed and high quality MIR, with relevant researches and background information.
I was first tempted to diff between quagga and frr to do a quick assessement. However, there are too many differences to avoid doing a full package checks. Here are my findings:
I can’t give a definitive ack right now until those questions are answered and some few fixes:
Notes/required TODOs:
* does it need a security review in your opinon? Like, since the first MIR security assessment, a lot of time have passed. Is this the opportunity to benefit from another review or do you think the overall diff from the first MIR in term of security handling is small enough to not justify having a new one?
* can you give the exact list of binary packages to promote? You mentioned for instance to keep frr-rpki-rtrlib in universe to avoid pulling librtr to main. I think the definitive will help on the AA side.
* It is on the lto-disabled list. Fix, or the work-around should be directly in the package.
* There are some compiler warning in the build logs. This is maybe the right time to get them fixed?
* finally, once this is promoted, how do we explicitely demote quagga? I don’t find it in the seed. What is going to be uploaded to switch to frr?
[Duplication]
Fork of quagga, will replace it and the first one will be demoted.
[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems:
- new dependencies in main, libyang2: https:/
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
[Security]
OK:
- history of CVEs is expected for this kind of daemon and usage, It does not look concerning
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
Problems:
- one run a daemon as root, as explained in the description
[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error from the MIR description. Note that the summary mentions "TOTAL: 0"
- does have a non-trivial test suite that runs as autopkgtest
- no new python2 dependency
[Packaging red flags]
OK:
Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings (rather pendantic ones)
- d/rules is rather clean
Problems:
- It is on the lto-disabled list. Fix, or the work-around should be directly in the pack...