From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Cc: Graham Rhodes <graham.rhodes@rockwellcollins.com>,
Vadim Kochan <vadim4j@gmail.com>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] package/frr: security bump to version 8.5.4
Date: Sun, 28 Jan 2024 18:27:30 +0100 [thread overview]
Message-ID: <ZbaOgl5f8WJnvJCS@landeda> (raw)
In-Reply-To: <20240127225657.2427657-1-fontaine.fabrice@gmail.com>
Fabrice, All,
+Graham, see below for input.
On 2024-01-27 23:56 +0100, Fabrice Fontaine spake thusly:
> Fix CVE-2023-38802, CVE-2023-41360, CVE-2023-46752, CVE-2023-46753,
> CVE-2023-47234 and CVE-2023-47235
>
> https://frrouting.org/security/
> https://frrouting.org/release/8.5.4/
>
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Applied to master, thanks.
Since frr is a fork from quagga [0], it would not be too surprising that
some of the CVEs against frr were valid back in the quagga era. Also,
Quagga is no longer maintained (as their website is no longer
available). At least, there are three open CVEs:
CVE-2016-4049
CVE-2017-3224
CVE-2021-44038
CVE-2021-44038 was reported after the last quagga release, and that the
two others were not fixed then, but are fixed in frr.
The sole package we have that uses quagga is olsr. Support for quagga
was added in 2013 with commit 9b48690efb59 (olsr: bump to version 0.6.4)
stating "Doesn't really need quagga but not very useful without it", yet
it is still really only optional.
The upstream olsr repository has not had a quagga-related commit since
2019 (commit 385321522335), and the actual last code commit was even
earlier, in 2016, to fix a warning (ac80336d56e5).
Finally, the olsr documentation still mentions old quagga versions that
need to be patched with patches bundled in olsr. Since the upstream
quagga has disapeared, it is not trivial to find whether those patches
were ever upstreamed.
And now that I wrote all the above, it turns out that quagga is not even
a build dependency of olsr at all, so propbably just an optional runtime
dependency.
Which leaves us with just our commit 1e3cd85e7a6d (package/quagga:
install quagga to staging) from Graham, but we have no such in-tree
user, so we can't really assess whether our quagga package is even
installing its dev files properly...
Would it make sense that we now drop Quagga altogether?
If quagga support in olsr is till required, or if third-party code needs
quagga dev files, can that be provided by frr instead?
[0] https://www.linux.com/news/welcoming-frrouting-linux-foundation/
Regards,
Yann E. MORIN.
> ---
> package/frr/frr.hash | 2 +-
> package/frr/frr.mk | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/package/frr/frr.hash b/package/frr/frr.hash
> index 836f130b93..4a61084bae 100644
> --- a/package/frr/frr.hash
> +++ b/package/frr/frr.hash
> @@ -1,3 +1,3 @@
> # Locally calculated
> -sha256 8a6b0e0fa1e89493ba84cf176674e55c7a814821fd02a7188095b76c37c3935f frr-8.4.2.tar.gz
> +sha256 7ae9d8bafc65bb5d0f21061ac61dbc6cf93b2b05a5dae9e5eec72ed42388551e frr-8.5.4.tar.gz
> sha256 8177f97513213526df2cf6184d8ff986c675afb514d4e68a404010521b880643 COPYING
> diff --git a/package/frr/frr.mk b/package/frr/frr.mk
> index abae784c40..19f346fd7b 100644
> --- a/package/frr/frr.mk
> +++ b/package/frr/frr.mk
> @@ -4,7 +4,7 @@
> #
> ################################################################################
>
> -FRR_VERSION = 8.4.2
> +FRR_VERSION = 8.5.4
> FRR_SITE = $(call github,FRRouting,frr,frr-$(FRR_VERSION))
> FRR_LICENSE = GPL-2.0
> FRR_LICENSE_FILES = COPYING
> --
> 2.43.0
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2024-01-28 17:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-27 22:56 [Buildroot] [PATCH 1/1] package/frr: security bump to version 8.5.4 Fabrice Fontaine
2024-01-28 17:27 ` Yann E. MORIN [this message]
2024-01-30 22:09 ` Peter Korsgaard
2024-02-28 17:35 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZbaOgl5f8WJnvJCS@landeda \
--to=yann.morin.1998@free.fr \
--cc=buildroot@buildroot.org \
--cc=fontaine.fabrice@gmail.com \
--cc=graham.rhodes@rockwellcollins.com \
--cc=vadim4j@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox