A discussion in the Go security bug #33940 raised the issue that Go binaries (among other languages) are statically-linked and therefore need to be recompiled after their build dependencies, including the compiler, are updated for security updates. This affects all or some packages written in Rust, Java, Go and OCaml (and probably a few other languages). I did some basic regex matching to come up with the following lists, so there may be some issues missing. It's probably worthwhile for the security team to do a more thorough check, especially for Java. I count 8 security and bugfix advisories in mga9 for Go packages (all on the compiler itself): 32622 32898 33068 33197 33269 33380 33526 33940 I count 3 security and bugfix advisories in mga9 for Rust packages: 32585 33713 33826 I count no security or bugfix advisories in mga9 for OCaml packages. There is no standard naming practice for Java packages, so a simple regex search doesn't work to find updated Java dependencies. But, there have been at minimum 10 security and bugfix advisories: 30368 30882 32203 32413 32521 32545 32724 33117 33413 33648 In the absence of suitable infrastructure to provide a more accurate list, all applications written in these languages must be recompiled to ensure they pick up those security fixes. This has likely already occurred for a few packages. I've started a page discussing a long-term solution for handling these kinds of updates at https://wiki.mageia.org/en/Vendored_dependencies
Thank you Dan for this alert. "This affects all or some packages written in Rust, Java, Go and OCaml" $ urpmq --whatrequires rust cargo clippy All th following are in the rust SRPM: rust rust-std-static rust-std-static-i686-pc-windows-gnu rust-std-static-wasm32-unknown-unknown rust-std-static-wasm32-wasi rust-std-static-x86_64-pc-windows-gnu rust-std-static-x86_64-unknown-none rust-std-static-x86_64-unknown-uefi rustfmt Does Go = golang? Alas, there are hundreds of packages with 'golang' in their name, and they all seem to be individual SRPMs. How to tell whether they have golang binaries? For Mageia 9 at least: java-1.8.0-openjdk java-11-openjdk java-17-openjdk java-latest-openjdk Again, there are hundreds of packages with 'java' in their name. But I wonder about them having java binaries. $ urpmq --whatrequires ocaml ocaml syntastic-ocaml --------------- CC'ing NicolasS, packagers, Java group for their comments.
CC: (none) => java, nicolas.salguero, pkg-bugsComponent: RPM Packages => SecurityQA Contact: (none) => security
Java isn't a compiled language and shouldn't be affected by an issue like what you raised with golang.
Java is definitely compiled, but into bytecode instead of object code. That bytecode ends up in .jar files packaged with applications, which ends up being effectively the same as static linking. For example, jitsi-2.10.5550-11.mga9 contains /usr/share/java/jitsi/lib/bundle/log4j.jar which looks very similar to the file /usr/share/java/log4j/log4j-1.2-api.jar from the log4j package. Does that embedded copy of log4j make jitsi vulnerable to the notorious CVE-2021-44228? Who knows? But because it's using its own copy of log4j and not the files in our log4j package, it's possible. (It actually appears in this case that the embedded log4j version is earlier than the vulnerable one so we're probably safe in this specific example.) I don't know if this is a unusual case and only a matter of jitsi vendoring log4j or if it's widespread in our java packages, but it's certainly affecting Java.
> $ urpmq --whatrequires rust Since rust is a compiled language, this command will show packages that require the rust compiler. urpmq doesn't show you .srpms, so it's going to be a short list. > Does Go = golang? Yes. > Alas, there are hundreds of packages with 'golang' in their name, and they all seem to be individual SRPMs. How to tell whether they have golang binaries? *Most* golang-* packages just contain golang packages (a.k.a. source code in .go files) but I suppose they could contain binaries instead/as well. I don't know if we forbid that in our packaging standards or not. You can run "go version /usr/bin/executable" to see if an executable is a go binary or not. > But I wonder about them having java binaries. Java "binaries" can probably roughly be considered as .jar files. To run a java application you execute "java -jar path/to/file.jar" which runs the Java interpreter on the bytecode in the .jar file. But, some .jar files are equivalent to libraries and trying to run those just gives you an error. You can consider .jar file as analagous to ELF binaries, which can be either executable binaries (like those in /usr/bin/) or shared libraries (which are usually named libSOMETHING.so.0). .class files are the equivalent of .o files (Java object files outside a .jar) and we have some packages with those as well.
The issue you described for Java is entirely different from the golang issue. The golang issue is because it's compiled and the affected libraries are statically built into binaries. The Java issue you described is due to unfortunate bundling. The fact that it's byte compiled isn't the issue, and rebuilding packages won't fix it. Either the affected libraries need to be unbundled or updated.
If this is a simple matter of vendored Java packages then it's a relief. But, there are lots of packages doing this and the fix for that is even more annoying.
Yes, I believe the reason it's so common in Java is it's more sensitive to library versions as far as compatibility goes. For an application to be able to work with the system versions of libraries, it's more likely that they would need to be patched than C applications, for instance. Also, since Red Hat mostly stopped funding the Java packaging team, Fedora stopped providing a lot of the Java library packages that they used to, and we followed suit, that necessitated more bundling (and also nobody is doing the unbundling work, even where it's still possible). Anyway, that is a fundamentally different issue, so it's not a part of this bug.
Here is a list of mga9 Java packages I found (with a bit of scripting and some manual sanity checking) that likely contain bundled Java jar files, along with their registered maintainers: aladin joequant atnt neoclust carmetal neoclust docbook5-style-xsl neoclust dogtag-ldapjdk nobody ecj nobody euclide nobody freecol nobody geometria nobody guava nobody jakarta-mail neoclust jakarta-saaj daviddavid jakarta-xml-rpc daviddavid jaxb-api daviddavid jorbis neoclust kojo nobody mariadb-bench mokraemer maven-surefire neoclust maven-surefire-provider-junit neoclust pmb neoclust soprano-plugin-sesame2 speed-dreams eatdirt texlive-collection-basic mokraemer texlive-doc mokraemer tilitin nobody tvbrowser nobody virtuoso-opensource-jars nobody vstar joequant webmin nobody wsdl4j nobody xalan-j2 nobody xerces-j2 nobody xml-commons-apis neoclust
The following mga9 packages have "-static" in their names and contain static binaries, or I happened to notice they contain statically-linked binaries (i.e. there are probably more). These need to be rebuilt to ensure they get any glibc security updates: audit nobody busybox-static nobody dash-static nobody docker bcornec docker-containerd bcornec qemu-user-static tv qemu-user-static-aarch64 tv qemu-user-static-alpha tv qemu-user-static-arm tv qemu-user-static-cris tv qemu-user-static-hexagon tv qemu-user-static-hppa tv qemu-user-static-loongarch64 tv qemu-user-static-m68k tv qemu-user-static-microblaze tv qemu-user-static-mips tv qemu-user-static-nios2 tv qemu-user-static-or1k tv qemu-user-static-ppc tv qemu-user-static-riscv tv qemu-user-static-s390x tv qemu-user-static-sh4 tv qemu-user-static-sparc tv qemu-user-static-x86 tv qemu-user-static-xtensa tv sash nobody syft ? valgrind tv
Further to the bug description, I count 8 security and bugfix advisories in mga9 on glibc packages: 32292 32328 32357 32796 33118 33185 33346 33953 These will require a recompile of static C/C++ binaries (comment #9) in order to take effect in those packages.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=34078
(In reply to Dan Fandrich from comment #0) > I count 3 security and bugfix advisories in mga9 for Rust packages: > 32585 33713 33826 As rust was "recently" updated to 1.78.0, latest mesa, firefox and thunderbird were built with that rust version