Bug 259127

Summary: net/libyang: Update to 2.0.97 and multiple CVE fixes
Product: Ports & Packages Reporter: Daniel Engberg <diizzy>
Component: Individual Port(s)Assignee: Olivier Cochard <olivier>
Status: New ---    
Severity: Affects Many People CC: john
Priority: --- Flags: bugzilla: maintainer-feedback? (olivier)
Version: Latest   
Hardware: Any   
OS: Any   
URL: https://github.com/CESNET/libyang/releases/tag/v2.0.97
Description Flags
Patch for libyang
Patch for libyang v2 none

Description Daniel Engberg freebsd_committer 2021-10-13 06:22:30 UTC
Created attachment 228647 [details]
Patch for libyang

Fixes mutiple CVEs however there's no support in FRR v7.x for libyang 2.x
Connect unit testing to port

1.x branch is also deprecated by upstream as of 1.0.240, there's a tagged 1.0.255 release in repo but it's not listed on as a release on upstream's website


Comment 1 Daniel Engberg freebsd_committer 2021-10-13 06:36:51 UTC
Created attachment 228648 [details]
Patch for libyang v2

Do not hardcode -O2 optimization
Comment 2 Olivier Cochard freebsd_committer 2021-10-13 08:33:51 UTC

because FRR7 only support libyang 1.x, my idea was:
1. Upgrading net/libyang to 1.0.240
2. Adding new net/libyang2, that will be used by FRR 8

What are your thoughts about that ?

I have a local FRR8 and net/libyang2 since weeks but still not committed because I meet strange bug with FRR8 on my side.
Comment 3 Daniel Engberg freebsd_committer 2021-10-13 08:55:12 UTC
Due to the CVEs I highly think that you at least should move to 240 if you want to have frr 7.x and 8.x in tree at the same time. Since frr is the only user I don't see it being much of an issue but in general my personal opinion is that we should avoid having parallel versions of libraries in tree if possible since it complicates and causes issues (conflicts).

Please try to connect upstream's test suites (as in this patch) if possible as it makes regression testing easier.

I'm not a user of frr (I just noticed the CVEs regarding libyang) so I can't help much but are you seeing similar issues https://elegantnetwork.github.io/posts/followup-measuring-BGP-stacks/ or is it something else? Have you submitted a bug report upstream?

Best regards,
Comment 4 commit-hook freebsd_committer 2021-10-13 12:56:53 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=7a6696ab2619c2661b8af49f1ee6eb4d1d9caf46

commit 7a6696ab2619c2661b8af49f1ee6eb4d1d9caf46
Author:     Olivier Cochard <olivier@FreeBSD.org>
AuthorDate: 2021-10-13 12:43:05 +0000
Commit:     Olivier Cochard <olivier@FreeBSD.org>
CommitDate: 2021-10-13 12:55:58 +0000

    net/libyang: Fixes mutiple CVEs and connect upstream's test suite

    CVEs: CVE-2021-28902, CVE-2021-28903, CVE-2021-28904, CVE-2021-28905,

    PR:             259127
    Reported by:    diizzy

 net/libyang/Makefile  | 9 ++++++++-
 net/libyang/distinfo  | 6 +++---
 net/libyang/pkg-plist | 2 +-
 3 files changed, 12 insertions(+), 5 deletions(-)
Comment 5 John W. O'Brien 2021-10-24 14:34:57 UTC
Thanks to both of you for your work on this. Please let me know if there is an opportunity for me to help.

(In reply to Olivier Cochard from comment #2)
In general, my preference is for the unqualified port name to always refer to the most recent, full release (i.e. non dev, beta, RC, etc), and for previous major released to be available under the qualified name. Under that model, 1.x would become net/libyang1, and net/libyang would be upgraded to 2.x. Clearly, another consideration would be consistency with past precedent of a port or between a port and its closely related ports (e.g. net/frr7).