Hi Sergio, On Thu, Oct 29, 2026 at 08:52:40PM -0400, Sergio Durigan Junior wrote: > Control: forwarded -1 https://gitlab.com/Seeker4/OSCAR-code/-/work_items/360 > > On Tuesday, 27 October 2026, Helmut Grohne wrote: > > > oscar builds a vendor copy of botan. This is problematic on several > > levels. The Debian policy discourages embedded code copies and this > > makes it a normal bug. A vulnerability in botan (which is a crypto > > library after all) has to be fixed several times. Worse, one has to > > figure out which packages include such a copy. Therefore, we keep a > > record at > > https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies. > > Notably, oscar is not listed here. The botan version included in oscar > > is very old. It is very likely affected by a number of vulnerabilities > > fixed in newer versions, see > > https://security-tracker.debian.org/tracker/source-package/botan. > > Thank you for the heads up. > > I noticed that botan has been removed from the archive and is only > available on stable, so it seems like replacing it with the system copy > isn't feasible for unstable.
botan issued a major version a while ago. The botan source package remained with 2.x while a new source package botan3 provided the new version. It is only the 2.x series that has been removed from unstable. Likely switching to botan3 involves some porting effort, but at this time I expect 3.x to have stabilized. I don't think anyone is doing security support for 2.x anymore. > I've just filed an upstream issue letting them know about the situation > with botan; let's see how it goes. Thank you! > > Beyond this, I attempted to cross build oscar and found that when > > building it for s390x, it would fail with "error: writing 1 byte into a > > region of size 0 [-Werror=stringop-overflow=]". This likely is due to > > compiling with -Werror and gcc-16 having gained precision in warnings > > (or false positives). I cannot reproduce this on amd64. > > Do you want to file another bug for this? I see two possible subproblems here. One is compilation using -Werror. As Debian packages newer compilers, -Werror is very likely to cause frequent FTBFS. We are seeing this in other packages already. Therefore, -Werror (as well as running shellcheck during build) is something that I and others discourage. This is not trying to devalue these tools. In your own CI, they are very valuable. For instance, your salsa-ci builds may export DEB_CFLAGS_APPEND=-Werror so you get to see those problems sooner while not having the urgency to fix them right away. Whether this is a bug is in the eye of the beholder. Some maintainers vehemently disagree with turning off -Werror by default. Do you see it as a bug? The other aspect is that this happens while building botan 2.x. I don't think it makes much sense to invest into the particular problem as it has become clear that this code is being changed. > I believe the reason for OSCAR to vendor botan is the fact that botan > isn't available in Debian unstable/testing anymore. I will wait for > upstream's reply to the issue before I decide what to do here. I checked older versions and didn't find any that actually dependend on botan. Could it be that it rather is a convenience copy? It also looks like oscar only uses a small fraction of botan. >From a process point of view, I'd like to get this bug out of the RC state asap. I'm not sure how to get there though. A relatively time intensive option is evaluating applicability of botan vulnerabilities against oscar (hopefully figuring that none of them apply), recording the embedding (against botan3 even though the 2.x version is used) and downgrading it beyond rc. Another time intensive option is porting oscar to botan3 (and also recording the embedding unless it can be unvendored). The latter has more unknowns but likely is the better long-term investment. Regarding unembedding, I can already tell that it is not trivial as oscar uses an amalgamation. At the very least #include directives change a lot when using a system copy. Also consider whether upstream may want to keep the embedding as a convenience for non-Debian users that wish to avoid building a separate botan. Possibly, supporting both a vendored and a system botan will be necessary. I wish it was easier. Helmut
