<robimarko>
And yes, the whole clock parenting is crap
<robimarko>
We had to fix it multiple times so far
<f00b4r0>
CVE-2024-3094 - ouch very much
<f00b4r0>
compromised upstream xz-utils tarballs.
<mrnuke>
robimarko: the gcc-ipq9574 tries to solve that by taking in the uniphy clocks from devicetree. Of course, that's not useful with qca-ssdk, as it doesn't esport the clocks in a dt -firendly manner
<zorun>
reading the openwall post, the code injection seems to specifically target debian/rpm builds, so hopefully it doesn't trigger in our buildroot
<dwfreed>
yeah, most likely does not
<PaulFertser>
Just wow. Is that the first case with malicious upstream for a very essential very common project?
<dwfreed>
fortunately only snapshot is affected
<dwfreed>
version wise
<dwfreed>
but as far as whether the backdoor actually happens, I don't think it does
<PaulFertser>
robimarko: probably that's an operation by China agencies, I assume they could have easily taken over control if the maintainer is under their powers.
<f00b4r0>
zorun: seems you're right. However now that the version is known to be compromised, people will freak out if we keep it around
<f00b4r0>
i'd suggest downgrading, just for that reason.
<zorun>
f00b4r0: yeah, it definitely needs to be reverted/updated/whatever
<robimarko>
f00b4r0: I think its better if we quickly revert the recent update
<dwfreed>
note that there is tools/xz in openwrt.git as well as the version in packages.git
<f00b4r0>
robimarko: ack. Problem is revert won't be enough for systems where the newer package has been installed
<dwfreed>
fortunately it's only snapshot :)
<f00b4r0>
we need a fake higher version like debian did
<f00b4r0>
ynezz: we are "technically" unaffected (see backlog), but from an end-user perspective we should most likely "updowngrade": provide a newer package that reverts to an older version
<f00b4r0>
not sure how to handle that with opkg
<stintel>
hmm, tools/xz is still at 5.4.6, so that should be ok
<f00b4r0>
stintel: no, robimarko just reverted that
<f00b4r0>
ynezz: I think we need to do the same thing Debian did: release a higher version number that packages older source. It will require hacking the Makefile though I believe
<Znevna>
ah and so it begins
<Znevna>
[19:31:39] <Sora> How much did the chinese government pay Jia Tan for this backdoor?
<Habbie>
what's #tukaani?
<Habbie>
oh nevermind
<ynezz>
f00b4r0: -ENOTIME, patches welcome :P
<dwfreed>
Znevna: the reality is the chinese government probably paid them with "the privilege to still be breathing"
<Znevna>
plot twist
<Znevna>
Jia Tan IS the chinese government
<ynezz>
ind -name liblzma_5.6.1* | wc -l
<ynezz>
33
<ynezz>
oh, there is a lot more packages
<ynezz>
so should we simply delete all those packages having 5.6.1 in the filename?
<jakllsch>
that sounds like it could hit entirely unrelated packages.
<f00b4r0>
the guy is thorough, you'd have to give him that
<aparcar>
ynezz: cache purged
goliath has joined #openwrt-devel
<hauke>
should we prefer git commits and tags over tar files in the future?
<hauke>
The git was mostly fine in this case and it is easier to review
<Habbie>
i was discussing this on two other channels
<Habbie>
a generated ./configure, and many other similar things, are basically a gap in reproducible builds
<hauke>
I read about similar problems with chome extensions, some people took over maintainership and then released backdoored versions in the chrome extension marketplace, but the git staied fine
<f00b4r0>
hauke: given the implication of the upstream author, it would have been fairly trivial for them to backdoor the source
<f00b4r0>
I don't think using git vs tar should give us a false sense of security. The fact is that our collective asses were saved by one guy who cared enough to go down the rabbit hole
<f00b4r0>
(imho)
<dwfreed>
and not being a mainstream distro
<hauke>
f00b4r0: I do not think using git sources would have prevented it
<f00b4r0>
dwfreed: I was speaking more generally. It's very lucky that Andres Freund caught this early enough that it didn't trickle down into distro releases.
<hauke>
but it would make it harder to hide stuff
<dwfreed>
yeah
<f00b4r0>
hauke: only if someone cares enough to review
<f00b4r0>
fact is, that almost never happens.
<f00b4r0>
especially when upstream is "trusted"
<f00b4r0>
and even then, see how they were able to get stuff into google/oss-fuzz
<f00b4r0>
that's sad, yet not entirely surprising.
<PaulFertser>
And if the exploit was just a little bit better and didn't introduce that delay that human noticed it would remain hidden for much longer.
<f00b4r0>
yeah they almost got away with murder. *sigh*
<Mangix>
aparcar: original argument was better unpack speed and compatibility with older tarballs.
<jow>
f00b4r0: that wiki page is not an autharitative source for uci syntax rules
<f00b4r0>
aparcar: I only glazed over them, the most obvious thing is they'd prod users to update sooner.
<f00b4r0>
jow: I get that now. I understand we have no such thing :)
<dwfreed>
one should exist, though
<aparcar>
jow: do you mind me adding bwrap aka bubblewrap to the build system? It wouldn't work on systems other than linux (i.e. no macos) but would harden the buildbots quite a bit
<f00b4r0>
(assuming the versioning is seen as "newer" by opkg)
<aparcar>
Mangix: I rebased it via the github UI to see the ci running through, I'll merge it (fingers crossed no backdoor in that meson version)
<Mangix>
aparcar: LOL, I don't think meson is managed the same as xz.
<schmars[m]>
i see, it's already a meme
<f00b4r0>
jow: thanks to your help and based on the util.c checks I think I now have a "compliant" parser, at least for 99.99% of cases (it only handles implicit concatenation for values, because I'm lazy)
<Mangix>
f00b4r0: horrible idea: switch to decompressing xz archives with 7zip.
<f00b4r0>
Mangix: you're missing the point.
<jow>
better idea: go back to .tar.gz :)
<f00b4r0>
the backdoor targets ssh
<f00b4r0>
(and I should say, systemd-friendly-patched-ssh - further hinting that systemd is pure evil ;P)
<f00b4r0>
Mangix: the purpose of the patch I linked above is to "cure" existing installs, which will not by default install an older package over 5.6.1
<aparcar>
yea an evil package can freely patch openssh-server.ipk to it's liking, image checksums/signing happen at the very end anyway
<jow>
so you're passing the staging directory as readonly mount to the container?
<f00b4r0>
aparcar: the correct way to fix that is to have a build system that only builds the intended package on incremental updates
<f00b4r0>
of course that's easier said than done
<aparcar>
f00b4r0: well please feel free to join the eternal fun of openwrt build system
<f00b4r0>
pass. Been there, done that, lost interest.
<aparcar>
jow: not only that, but mount it so only ./output-<package>/ is writeable and let it only store packages there. Check if none of the files already exists in the global ./output/ folder and only then copy things
<jow>
okay, but you can still ship a uci-defaults file which simply alters arbitrary executables
<Mangix>
alright. time to figure out why util-linux is not using meson
<aparcar>
jow: agree
<aparcar>
I didn't think of that
<f00b4r0>
doesn't have to be uci-defaults anyway ;P
<aparcar>
however that evil package would than have to be installed actively
<aparcar>
right now a single infected package can affect all other packages by simply being compiled
<jow>
that's true
<jow>
but tbh I consider the current buildsystem to be essentailyl unmaintainable already
<aparcar>
I got my hands deep in the package building anyway due to the APK stuff so adding some bubblewrap shouldn't be to much extra time...
<jow>
not sure if such an invasive feature addition is the proepr course of action
<aparcar>
jow: I'm happy to follow your proper course of action ideas 🙂
<aparcar>
my suggestion is still to drop our packages and use the APK build system but that's likely an unpopular opinion right now
lynxis has joined #openwrt-devel
<aparcar>
Mangix: I updated meson but it still break APK if I don't specifically define the lib path