Control: tags -1 pending On Friday, 30 October 2026, Helmut Grohne wrote:
> Hi Sergio, Hi Helmut, > 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. Oh, you're right. I don't know I missed that. > 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. Fair enough. I will leave a comment on the upstream issue with this update. >> > 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? I don't vehemently disagree with you, but if upstream chose to keep -Werror in the release then I tend to follow their lead here. For example, OSCAR has this snippet in their .pro file: --8<---------------cut here---------------start------------->8--- # Always treat warnings as errors, even (especially!) in release QMAKE_CFLAGS += -Werror QMAKE_CXXFLAGS += -Werror --8<---------------cut here---------------end--------------->8--- So using -Werror in the release build was intentional. I understand we may see FTBFSes due to that, but I'm personally willing to go through the trouble of reporting problems upstream in this case. Having said that, I noticed that my last upload did build correctly on s390x: https://buildd.debian.org/status/fetch.php?pkg=oscar&arch=s390x&ver=2.1.0-2&stamp=1793330527&raw=0 So maybe the problem is fixed? Although you did say you were trying to cross build the package, and I've seen difference in error reporting between the same GCC version running on different hosts/targets. > 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. Ah, right. I thought this was a problem with OSCAR itself. In this case, let's keep things in this bug. >> 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. So, I have very limited time for Debian these days (baby reasons), but I was able to sit down for some minutes and adjust OSCAR to use botan3. It wasn't as hard as I was thinking, although TBH I haven't checked if upstream is patching their amalgamation of botan (I don't think so). I've just uploaded the package to experimental; feel free to take a look at the patch and let me know. I will probably give it a week before uploading to unstable, unless upstream agrees with my changes. Oh, I haven't unvendored the existing botan either. We can do that later. Cheers, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
signature.asc
Description: PGP signature
