Untitled

[20:20:49] <Traneptora> I've literally spoken to him in 2010 about the algorithms behind xz and lzma2
[20:20:55] *** Joins: Guest30 (~Guest30@070-126-159-142.res.spectrum.com)
[20:21:00] * sam_ nods
[20:21:11] <Guest45> heh I wonder if the guys at traficom NCSC is trying to reach Lasse
[20:21:25] <Noisytoot> Snetry: How do you know that Jia's computer wasn't compromised (rather than Jia actually being responsible)?
[20:21:38] <sam_> let's try to leave out the guessing about Jia or pseudo-Jia or what
[20:21:45] <sam_> jess called it a rhetorical device earlier and i think this is a useful way of thinking about it
[20:21:54] <sam_> we are where we are, the feds are working on who did what
[20:21:59] <fullstop> Anyone here know Lasse?  Is he okay?
[20:22:01] <Traneptora> in either case sam_ do you have write access to the github repo?
[20:22:03] <Traneptora> https://github.com/tukaani-project/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c
[20:22:03] <Snetry> we don't know if they were compromised or not
[20:22:08] <Traneptora> please lock comments on this commit as there's lots of spam
[20:22:12] <Snetry> however, this has been a thing in the making for a long time
[20:22:14] <sam_> i do not - only Lasse and Jia do
[20:22:18] <Traneptora> rip
[20:22:40] <Celelibi> Yeah, I noticed people tend to spam the comments of the commits involved.
[20:22:48] <sam_> I don't have an out of band way to contact Lasse, I have an idea which might work but I haven't done it because I suspect others are trying far better methods (including feds)
[20:22:56] <sam_> I don't want to harass the guy
[20:23:01] *** Joins: waldalaskansalmo (~gavtroy@2a04:52c0:106:bcac::1)
[20:23:02] <billchenchina-> Noisytoot: i dont believe Jia can really publish two releases while his computer got compromised
[20:23:04] <Snetry> Even if the real Jia is not responsible for this, the Jia account still is and we need to talk about the actor behind it somehow
[20:23:14] <sam_> yes, I just mean talking about computer or not isn't useful imo
[20:23:17] <Guest45> I assume Lasse is in FInland and most people here are offline due to easter
[20:23:30] <Snetry> billchenchina-: if they have access to the github account they can add arbitrary pgp keys, sign stuff, etc.
[20:23:32] *** Quits: PA17532 (~PA17532@067-011-240-216.res.spectrum.com) (Quit: Client closed)
[20:23:40] <Snetry> and with the account being in the org, they can modify the xz project website
[20:24:01] <tnt> If he's truely offline for easter, he'll have one hell of a Monday ... on Tuesday.
[20:24:15] <fullstop> Surely he will find out before then.
[20:24:19] <billchenchina-> Snetry: i dont mean the ability, but the possibility
[20:24:21] <sam_> he's going to need a steady dose of beers, we can say that much
[20:24:29] <billchenchina-> the test case is so properly crafted
[20:24:29] <st3fan> If you are an active maintainer and your account has been compromised then you probably notice that when commits appear over this timespan. It is more likely that this person was "corrupt" all the time, or was turned recently, or they have been "replaced" by a state agent. Meaning not just the account was compromised but the actual person. All speculation! 
[20:24:30] <Guest45> I assume https://www.traficom.fi/en/national-cyber-security-centre have been notifed?
[20:24:42] *** Joins: bal-e (55025205b6@2a03:6000:1812:100::1224)
[20:25:01] *** Quits: Guest12345 (~Guest1234@c-24-3-31-206.hsd1.pa.comcast.net) (Quit: Client closed)
[20:25:03] <st3fan> Whatever happened here on a personal level is very serious
[20:25:13] <Snetry> st3fan: we don't and can't know what happened
[20:25:19] <fooo_> tnt: https://www.timeanddate.com/holidays/finland/easter-monday
[20:25:23] <Snetry> for all we know the real person behind the account left to do wood working
[20:25:26] *** Parts: tdebrouw (~tdebrouw@178-118-65-79.access.telenet.be) ()
[20:25:29] <billchenchina-> Lasse is in +0200 / +0300
[20:25:34] <Snetry> lets not jumble into conspiracy theories here
[20:25:39] <billchenchina-> is it possible to be in Finland?
[20:25:40] <st3fan> Has anyone found a GitHub account for Hans Jansen?
[20:25:53] <Guest45> afaik lasse is a Finn so of course
[20:26:10] <dostoyevsky2> st3fan: https://github.com/hansjans162
[20:26:24] <A_Dragon> Lets be a bit wary about links please
[20:26:29] <billchenchina-> finland seems true
[20:26:49] <jess> why are we trying to find the countries people live in
[20:27:11] *** Joins: Guest78 (~Guest78@ip72-204-13-218.fv.ks.cox.net)
[20:27:15] *** Quits: iyanmv_ (~iyan@193.32.127.239) (Quit: Konversation terminated!)
[20:27:19] <sam_> ^^
[20:27:21] <Guest45> yes somewhat irrelevant
[20:27:22] <billchenchina-> ^^ cyber-security-centre
[20:27:34] <sam_> i am confident the feds are working on contacting him
[20:27:41] <sam_> if they need help they have people they can ask at distros
[20:27:43] <boud> sam_ 's FAQ links to an analysis that suggests that Jia (whoever/wherever s/he is/was) did suspicious commits since 2021: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[20:27:53] <Snetry> For Lasse it is useful to know so we can guess when an official response will be released
[20:27:56] <sam_> to be clear I'm not pointing to that, just someone commented it, not read that yet
[20:28:01] <Snetry> for anyone else its irrelvant where they are from
[20:28:02] <sam_> (it may or may not be accurate, no idea yet)
[20:28:06] *** sam_ changes topic to 'FAQ: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27&apos;
[20:28:17] <jess> i have a feeling even Lasse won't know exactly what's going on
[20:28:22] *** Joins: leonic (~leonic@user/leonic)
[20:28:27] <sam_> I think he's going to be absolutely bamboozled by this and I feel so bad for him
[20:28:37] *** Joins: bret (~bret@user/bret)
[20:28:41] <boud> s/links to/is commented on with/
[20:28:42] <jess> i hope he's in a shed somewhere without internet having a nice time
[20:28:45] *** Joins: jtbx (31bb539f50@2a03:6000:1812:100::1328)
[20:29:00] <sam_> god i wish that were me
[20:29:04] <Guest45> my point was that "the feds" in finland is traficom nscs-fi and they have an advantage when investigating servers that are here
[20:29:17] <sam_> i'm saying feds deliberately because i know the US feds are actually involved
[20:29:19] <sam_> even though i am british :p
[20:29:22] <balrog> from one of the posts linked from that page: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html
[20:29:30] *** Quits: Guest39 (~Guest54@2a0c:5a80:3911:100:1a31:bfff:fe69:9604) (Quit: Client closed)
[20:29:32] <balrog> unpaid hobby project... which everything ends up depending on
[20:29:52] <boud> The irony here is that "Jia" probably proposed shifting the maintenance to github in order to have something closer to 24/24 7/7 responsiveness.
[20:29:59] * boud guessing
[20:30:02] <sam_> boud: correct...
[20:30:20] <jess> rule britannia!!! :v :v :v
[20:30:43] <sam_> i actually don't think all of it is consistent if you think Jia is a malicious actor. doesn't mean he is, or isn't, but it's way more complicated than "he did some trivial commits then got access and did something naughty". 
[20:31:24] <Habbie> sam_, https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
[20:31:32] *** Joins: Guest17 (~Guest17@047-013-081-116.res.spectrum.com)
[20:31:32] <Guest45> I don't think it was a coincidence to pull this thing off right before a four day holiday
[20:31:33] <Habbie> seems to be a decent summary that deserves to be in the gist or a comment
[20:31:37] *** Joins: hannula (~hannula@2001:999:504:3f89:7e5f:c8f:68d7:ffb0)
[20:31:45] <Habbie> Guest45, it was not pulled off today - it was fixed today
[20:31:48] *** Joins: Guest28 (~Guest28@tug-swl-230-11.tugraz.at)
[20:31:49] <sam_> ^
[20:31:51] <sam_> Habbie: thanks, checking it out
[20:31:56] <sam_> also
[20:32:02] <sam_> quick question
[20:32:11] <sam_> in the oss-security post, a commit is linked which references me
[20:32:12] <cjwatson> right, the attacker was in fact _unlucky_ that Andres did quite such heroic debugging
[20:32:14] *** Joins: Guest49 (~Guest49@h-94-254-64-68.A465.priv.bahnhof.se)
[20:32:18] <sam_> I didn't write it, but the commit is actually 100% right
[20:32:21] <sam_> (even now)
[20:32:26] <Guest45> okay but the debian part was pulled off like two days ago
[20:32:35] <sam_> I'm not sure if I should mention it in the gist but I feel like I sort of need to defend myself a little bit as not papering over a problem
[20:32:47] *** Joins: Guest42 (~Guest42@167.224.214.200)
[20:32:51] <Habbie> sam_, which commit is that?
[20:32:55] <sam_> sec
[20:33:06] <Mopman_> sam_: re: wishing you were in a hut, passive lurkers keeping one eye out for info appreciate the patient work, have a beer/tea though :D
[20:33:15] <Mopman_> what a pita weekend for it though
[20:33:15] <sam_> https://github.com/tukaani-project/xz/commit/72d2933bfae514e0dbb123488e9f1eb7cf64175f
[20:33:21] <Habbie> sam_, you did eat meanwhile, right?
[20:33:25] <sam_> I did! thank you :)
[20:33:26] <boud> sam_ I agree: from my few weeks' experience working with Lasse (me reporting, him working), I can't believe that Lasse would have accepted to transfer "power" without good evidence that Jia was reliable.
[20:33:28] <Habbie> sam_, very good
[20:33:39] <sam_> the commit is totally right and it turns out IFUNC really did have a bug in gcc where it could instrument a resolver wrongly
[20:34:00] <Habbie> as for your commit, and actually everything, i'm sure there will be a ton of investigative journalism
[20:34:00] <sam_> I DID mess up in that I should have looked into more why Fedora hit another IFUNC issue and we did not in Gentoo, but that is separate
[20:34:06] <Habbie> yeah
[20:34:08] <sam_> I want to avoid my own post-mortem here for now though
[20:34:22] <Habbie> in hindsight, already now, many people missed many somewhat reddish flags
[20:34:25] *** Quits: Guest23 (~Guest23@bras-base-ktnron0814w-grc-01-184-146-159-136.dsl.bell.ca) (Ping timeout: 250 seconds)
[20:34:26] <sam_> yeah
[20:34:27] <Habbie> which is so easy to say now
[20:34:38] <Habbie> and i at least do not mean any blame in that
[20:34:39] <sam_> I think there'll be a lot of interesting discussion afterwards
[20:34:52] <Habbie> yes
[20:34:53] *** Quits: dsilva (~dsilva@177.55.224.239) (Remote host closed the connection)
[20:34:55] <Habbie> maybe even a movie!
[20:34:56] <sam_> boud: that matches my feeling too.
[20:34:58] <Guest45> much to learn!
[20:35:00] <Habbie> (i'm kidding, but who knows)
[20:35:13] *** Joins: dsilva (~dsilva@177.55.224.239)
[20:35:25] <tk> sam_: I mean, the whole "working with the maintainers to get things fixed" thing just added to the credibility of the whole operation. I think it's worth mentioning that during the last 2 years, the infiltrator has worked with maintainers to fix problems with xz packaging which has included problems which were directly caused by the payload and that as of right now, there's no evidence that any of
[20:35:27] <tk> those people were involved in this infiltration.
[20:35:39] <sam_> tk: right
[20:35:40] <tk> s/and/but/
[20:35:58] <Habbie> tk, the infiltrator, or whoever took their place, or .....
[20:35:59] *** Joins: mdehling (~mdehling@076-088-053-132.res.spectrum.com)
[20:36:07] *** Joins: Guest98 (~Guest20@91-156-196-82.elisa-laajakaista.fi)
[20:36:07] <Habbie> we don't even know that
[20:36:27] <tk> Whatever, the threat actor.
[20:36:41] <tk> Oh I see what you mean.
[20:36:47] <tk> Yeah sure, you can add that distinction too.
[20:36:47] <Habbie> the threat actor may not be the person working so hard for a few years
[20:36:49] <Habbie> or they can be
[20:37:01] *** Joins: Guest65 (~Guest49@h-94-254-64-68.A465.priv.bahnhof.se)
[20:37:11] <Habbie> and the first and the second might know each other, or not
[20:37:26] <Habbie> we can formulate many questions but we know very little
[20:37:29] <i860> except wasn't a lot of that "hard work" actually in support of getting the foundations for this exploit implemented?
[20:38:24] <tk> Anyway, sam_, my point is, I think it's more than fair to clarify that nobody knows how far back the impact stretches but at some point this person did abuse their trust relationship with maintainers to work together on issues which were caused by inclusion of the payload. But, despite the fact that effectively these people collaborated with the threat actor to help get the payload working, that
[20:38:26] <tk> any of those people did so knowingly.
[20:38:49] <tk> s/that/there's no evidence &/
[20:39:20] *** Joins: rusteh (~rusteh@176.29.170.47)
[20:39:22] <i860> I don't even think they just turned, I think the entire thing was an op from the start.
[20:39:33] <tk> I think so too, but I agree we don't know that yet.
[20:39:37] *** Quits: dsilva (~dsilva@177.55.224.239) (Ping timeout: 250 seconds)
[20:39:44] <Guest30> They probably have many ops going like this at all times
[20:39:55] <Guest30> Some succeed some are exposed/fail
[20:39:56] *** Quits: Guest85 (~Guest85@modemcable154.4-162-184.mc.videotron.ca) (Quit: Client closed)
[20:40:49] *** Joins: mxz (~mxz@user/mxz)
[20:41:12] <Guest45> well, if you think how much effort is spent for much less significant goals. this type of backdoor can be very valuable even
[20:41:21] *** Quits: Guest49 (~Guest49@h-94-254-64-68.A465.priv.bahnhof.se) (Ping timeout: 250 seconds)
[20:41:29] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Ping timeout: 256 seconds)
[20:41:32] <i860> Yes, this is a massive vector here
[20:41:38] *** Quits: flyingbrick (~air2017@178-222-187-207.dynamic.isp.telekom.rs) (Quit: WeeChat 4.2.1)
[20:41:57] <i860> Hence why targeting various archive libraries would be so lucrative
[20:42:04] *** Joins: Guest1 (~Guest54@2a0c:5a80:3911:100:1a31:bfff:fe69:9604)
[20:42:31] <jess> if we're guessing that this was a chinese government thing then China is known to go to GREAT lengths https://blog.cloudflare.com/thanksgiving-2023-security-incident
[20:42:45] <Guest45> get something like this in glibc...or the kernel
[20:43:07] *** Joins: dsilva (~dsilva@177.55.224.239)
[20:43:21] <Habbie> https://lore.kernel.org/lkml/20240320183846.19475-1-lasse.collin@tukaani.org/t/#m1f559f130e6d463f83ea0960a1ec3da600341576 says it very well
[20:43:31] <Habbie> "or at least credentials associated with Jia Tan"
[20:43:58] *** Quits: Guest45 (~Guest45@dkw8pzyyyyyyyyyyybd3y-3.rev.dnainternet.fi) (Quit: Client closed)
[20:44:25] *** Joins: aaabbb (~aaabbb@user/aaabbb)
[20:45:02] *** Joins: Guest45 (~Guest45@dkw8pzyyyyyyyyyyybd3y-3.rev.dnainternet.fi)
[20:45:05] *** Joins: leapfog_ (~leapfog@p5080faa9.dip0.t-ipconnect.de)
[20:45:26] *** Joins: Guest56 (~Guest56@cpc76910-dals22-2-0-cust247.20-2.cable.virginm.net)
[20:46:53] *** Quits: Guest56 (~Guest56@cpc76910-dals22-2-0-cust247.20-2.cable.virginm.net) (Client Quit)
[20:46:56] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[20:48:18] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Remote host closed the connection)
[20:49:19] <Guest74> "I haven't lost interest but my ability to care has been fairly limited
[20:49:19] *** Quits: Guest1 (~Guest54@2a0c:5a80:3911:100:1a31:bfff:fe69:9604) (Quit: Client closed)
[20:49:19] <Guest74> mostly due to longterm mental health issues" - Reading this from Lasse Collin just makes me so sad. I hope this thing isn't going to hit him too hard
[20:49:38] *** Joins: val (~val@limnoria/val)
[20:49:56] *** Quits: larry_ (~larry@2a02:810d:ae3f:ed2b:872c:56e4:cf90:3024) (Remote host closed the connection)
[20:50:16] *** Joins: hmw[at] (~hmwat]@84-113-100-7.cable.dynamic.surfer.at)
[20:50:20] <sam_> it has been on my mind
[20:50:32] <jess> this does drive home why i'm keen to avoid people digging into the maintainers too hard. i really dont want any potentially innocent party to suffer
[20:50:36] <sam_> yes
[20:50:47] *** Joins: GeDaMo (~GeDaMo@user/gedamo)
[20:50:58] *** Quits: dsilva (~dsilva@177.55.224.239) (Remote host closed the connection)
[20:51:08] <aaabbb> whatever the threat actor may have targeted that project because the maintainership was in a fragile position
[20:51:15] *** Joins: dsilva (~dsilva@177.55.224.239)
[20:51:47] *** Joins: Haaninjo (~anders@fsf/member/Haaninjo)
[20:51:52] <Snetry> people are gonna dig into him regardless because OSS consumers are notoriously entitled 
[20:52:07] <jess> of course, but we dont need to affirm that sort of behaviour here
[20:52:11] *** Quits: Guest17 (~Guest17@047-013-081-116.res.spectrum.com) (Ping timeout: 250 seconds)
[20:52:13] *** Joins: Guest29 (~Guest29@65-130-223-35.slkc.qwest.net)
[20:52:23] *** Joins: Guest58 (~Guest58@2.53.191.11)
[20:52:33] <aaabbb> Snetry: i doubt anyone will dig into lasse
[20:52:38] <aaabbb> he's clearly the innocent party
[20:52:51] <Guest45> yes, somebody could try to reach him by phone, but otoh let the poor guy enjoy his easter offline
[20:52:55] <Guest58> who is innocent
[20:52:59] <jess> me
[20:53:07] <A_Dragon> I am!
[20:53:07] <aaabbb> there's no way he could have known that the other maintainer was doing this
[20:53:08] <q3k> not me
[20:53:21] <Snetry> yeah but I can already envision someone at some company blaming him for the threat actor becoming a maintainer
[20:53:24] <Guest58> whos the muffin that snuck the backdoor
[20:53:26] <Guest74> man and to think this was a hobby project for him. F me... i'm crying.
[20:53:34] <Paistin> how about let officials take care of contacting people. they surely will do their part
[20:53:37] <Guest58> tan guy?
[20:53:41] <i860> I 100% guarantee you that every major government (including the US), and obviously China, has mapped out every single vector in all major linux distros, what libraries are involved, what maintainers are involved with those libraries, who they are, what they do, etc. and how difficult it would be to slip something in. Associated threat actors will
[20:53:41] <i860> spend literal years trying to get something past both library and distro maintainers as well because the gain from having a dormant exploit like this is very high.
[20:53:50] <Traneptora> I can imagine that Jia offered to take up more work because Lasse had been struggling and he welcomed the extra help. rip Lasse, this has gotta be really hard for him
[20:54:09] <sam_> https://github.com/google/oss-fuzz/issues/11760#issuecomment-2027738588 sigh
[20:54:13] <Guest58> spend years to be discovered in a day
[20:54:22] <aaabbb> i860: eh, at this time they'll still be in the process of doing that
[20:54:26] <s1gyn> Assuming the other maintainer didn't just have their system compromised. But this wasn't just one commit soooooo
[20:54:29] <sam_> lots of people reading into things and getting it totally wrong
[20:54:40] <sam_> "all made accounts around the same time" well, yes, lasse wasn't big on github, he was an old school guy
[20:54:45] <sam_> context matters
[20:54:55] *** Joins: Rounin (~david@cinera/Rounin)
[20:54:58] <tipsfedoraa> yeah noticed that too
[20:55:01] <Rounin> Is this where the party is, then
[20:55:03] <aaabbb> but the real damage isn't the people hit by the backdoor, but by all the potential backdoors that could have been added into build infrastructure, etc
[20:55:11] <Guest58> are the maintainers or the org issued some official statements?
[20:55:22] *** Joins: blasphemy (~kvirc@83-85-136-198.cable.dynamic.v4.ziggo.nl)
[20:55:32] <Guest58> why the bd isnt reverted and a new version is published?
[20:55:48] <sam_> please see FAQ
[20:56:08] <Habbie> (linked in the topic)
[20:56:27] <i860> @aaabbb no doubt, it's likely similar stuff already exists in the wild right now and we just don't know where it is.. and the implementers won't exactly be using it all the time because just a single use could burn it
[20:56:31] *** Quits: Guest29 (~Guest29@65-130-223-35.slkc.qwest.net) (Client Quit)
[20:56:32] <aaabbb> imagine how many gcc committers may have used the compromised xz...
[20:56:33] <Snetry> this hasn't been known about for a day, there can't be an official statement on this yet
[20:56:43] *** Joins: Guest29 (~Guest29@65-130-223-35.slkc.qwest.net)
[20:56:48] <tipsfedoraa> sam_: https://github.com/tukaani-project/xz/issues/92#issuecomment-2027737316 sigh
[20:56:56] <Habbie> Snetry, that is not the reason there is no statement though
[20:57:01] *** Quits: Guest29 (~Guest29@65-130-223-35.slkc.qwest.net) (Client Quit)
[20:57:25] <sam_> tipsfedoraa: :/
[20:57:32] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[20:57:34] <aaabbb> i860: that's true, but the nice thing about open source is that it's hard to hide forever, and when things are found, it's possilbe to find exactly when it was introduced, and exactly what it does (assuming no execution guardrails + Secondary downloaded payload)
[20:58:52] *** Joins: erk (~erk@85.10.149.145)
[20:58:56] <mspo> isn't 'Jia Chan' a chinese woman's name? why does everyone keep saying "him"?
[20:59:04] <Celelibi> Such a discovery would have likely been harder in closed source software.
[20:59:06] <Guest74> I have the feeling this kind of agression is only just beginning and we need a whole other model to deal with versioning and trust in OSS
[20:59:09] <A_Dragon> Lets not, mspo 
[20:59:09] *** Joins: ba (~ba@2a02:8012:ee0:0:b826:e020:d455:3449)
[20:59:13] <Snetry> Habbie: correct, we don't know the exact reason. We don't even know if anyone with maintainer access to the project is aware of this
[20:59:21] *** Guest58 is now known as im0b
[20:59:25] <mspo> A_Dragon: ?
[20:59:28] *** Parts: im0b (~Guest58@2.53.191.11) ()
[20:59:42] <adrien> we can't even tell if only one person is involved; gendering is not going to be easy
[20:59:48] <Snetry> however, due this being very recent we can assume that whoever could do something probably has something better to do
[20:59:48] <Habbie> Snetry, i don't like speculation at all but it currently does smell a lot like somebody with maintainer access might be in on this. but i am not certain about anything
[20:59:52] *** adrien sets mode: -o adrien
[20:59:54] <blasty_> is anyone doing static analysis of the backdoored liblzma_la_crc64_fast.o ?
[21:00:00] <mspo> yeah so if it was "Susan Smith" would you still say 'he'?
[21:00:06] <Habbie> adrien, all these identities that seem suspect could be one person or 20 persons, yes
[21:00:08] *** Joins: Guest99 (~Guest30@2001:b07:5d2a:626b:a935:b56a:dce2:6b71)
[21:00:08] <orkim> hehehe.. keeping that heat off ya
[21:00:10] <orkim> ;D
[21:00:10] <sam_> jia is a male afaik
[21:00:13] <sam_> like actually is
[21:00:13] <i860> i don't even think the name matters, the name might as well be AI generated at this point
[21:00:14] <Habbie> adrien, 'they' seems more fitting than ever
[21:00:15] <sam_> ont just assuming
[21:00:17] <aaabbb> adrien: "it", since the account could easily be run by a team :p
[21:00:18] *** Quits: blasphemy (~kvirc@83-85-136-198.cable.dynamic.v4.ziggo.nl) (Ping timeout: 268 seconds)
[21:00:20] <bret> Guest45 "I haven't lost interest but my ability to care has been fairly limited" where are you reading this?
[21:00:20] <sam_> or that ;)
[21:00:45] <Guest74> bret: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html
[21:00:51] <q3k> blasty_: i am/was
[21:01:01] <q3k> blasty_: it's a mess :)
[21:01:01] <dostoyevsky2> blasty_: https://hybrid-analysis.com/sample/b418bfd34aa246b2e7b5cb5d263a640e5d080810f767370c4d2c24662a274963?environmentId=310
[21:01:11] <blasty_> its not immediately obvious how this thing works lol. I can see the tampered get_cpuid routine and what I believe is the backdoor entrypoint at 0xA750(?) .. it has a lot of symbols that sound like legitimate liblzma symbols but are actually not?
[21:01:15] <dostoyevsky2> blasty_: https://dogbolt.org/?id=f784e46b-dae6-4ab5-9bf1-180e3e25da2b
[21:01:22] *** Quits: Guest30 (~Guest30@070-126-159-142.res.spectrum.com) (Quit: Client closed)
[21:01:34] <Rounin> Oh, I thought Jia was the surname
[21:01:36] *** Joins: dutch (~DutchIngr@user/dutch)
[21:01:46] <mspo> I think evil state hackers are allowed to be female
[21:02:20] <blasty_> in typical fashion I kind of expect it to actually unpack a next stage with some embedded xz data blob ;>
[21:02:21] <Snetry> for all we know it could also be an account takeover
[21:02:23] <ba> Is this suspicious? PR author is followed by JiaT75: https://github.com/microsoft/vcpkg/issues/37197
[21:02:24] <Snetry> its best to not make assumptions
[21:02:31] *** Joins: blasphemy (~kvirc@185.65.134.244)
[21:02:39] <Snetry> ba: no, people follow others for many reasons
[21:02:51] <Snetry> there are also dozens of spam accounts on github following random people to appear legit
[21:02:54] <aaabbb> Snetry: you know what they say about assumptions. they make an assum out of pt and ion
[21:02:55] <q3k> blasty_: i've sent you what i've discovered via static analysis over in a DM
[21:02:56] <orkim> so the maintainer account that added to debian is only a week old account.. seems like really bad timing
[21:03:00] *** virtuous-sloth77 is now known as virtuous-sloth
[21:03:17] <ba> Snetry: sure, but the PR also upgrades liblzma to 5.6.0
[21:03:45] <Celelibi> Lasse called Jia "he".
[21:03:49] <Snetry> ba: yeah, and?
[21:03:57] <katia> q3k, i'm curious what you found 
[21:04:02] <ba> Snetry: OK sorry, just thought it might be important, my bad.
[21:04:13] <Snetry> up until now people have believed that liblzma had no backdoor
[21:04:17] *** Joins: kennethm (~kennethm@193.90.196.121)
[21:04:30] <q3k> katia: not much, just getting into the analysis of this is difficult
[21:04:33] <q3k> it's a very complex payload
[21:04:41] <q3k> difficult to even find it's logic by pure static analysis
[21:04:56] *** Joins: DPA (~DPA@75-128-16-94.static.cable.qlnet.ch)
[21:05:12] <Guest45> doesn't sound like a job by one script kiddie just for fun, does it
[21:05:37] *** Quits: rekrul (~rekrul@82-116-240-132.dynamic.lounea.fi) (Ping timeout: 250 seconds)
[21:06:05] <q3k> not at all
[21:06:24] <Guest45> this is just the kind of supply chain backdoor scenario I've been dreaming of for years, but I never tought it would happen to a project where most original contributors are finns (like me)
[21:06:24] <aaabbb> it's the beginning of Coding Machines all over again...
[21:06:25] <Celelibi> Right now I'm a bit worried about the future of the project. Lasse may have little energy to spend to build trust with someone else to become a maintainer.
[21:06:27] <Guest74> Getting stuxnet vibes
[21:06:46] <Fingel> This is sad :( https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html
[21:06:47] <fullstop> Has anyone tried poking around in the object file with ghidra yet?
[21:06:49] <q3k> https://social.hackerspace.pl/@q3k/112180756691632744 my conjecture on this so far
[21:06:57] <q3k> fullstop: yes, that's what i've been doing for a few hours now
[21:07:19] <fullstop> thanks for the link, q3k
[21:07:30] <q3k> best way to analyze this is in liblzma.so in situ, as the unlinked elf is even more difficult to analyze
[21:07:34] *** Joins: Guest30 (~Guest30@070-126-159-142.res.spectrum.com)
[21:07:52] <q3k> i've been analyzing https://koji.fedoraproject.org/koji/buildinfo?buildID=2417414 stage2 is at 0x00121e10 (per ghidra loading the ELF at 0x0010_0000) 
[21:08:09] <q3k> i really haven't gotten far though. i'm also not very good at this.
[21:08:11] <katia> thank you q3k 
[21:08:40] <Guest45> fingel, yes the way people are pushing Lasse for more results is just terrible. Like they are his boss or something
[21:08:45] *** Quits: Guest42 (~Guest42@167.224.214.200) (Quit: Client closed)
[21:09:29] <Fingel> Guest45:  what's even more disturbing is if this "Jia Tan" specifically took advantage of that
[21:09:45] <Fingel> It's like developer catfishing
[21:09:58] *** Joins: ids1024 (~ids1024@rh1.ids1024.com)
[21:10:04] <tk> I mean, is it disturbing? Have you read about anything governments have been up to in the last 1000 years?
[21:10:10] *** Joins: Guest42 (~Guest42@167.224.214.200)
[21:10:22] <Snetry> Welcome to OSS, you'll find dozens of people happily using your work and demanding constant work on it
[21:10:28] <Snetry> and even if you do it all, they will still give you shit
[21:10:36] <tk> Seems like an average day in the life of state sponsored cyber warfare.
[21:10:37] <DeepThoughts> I realize that peoples paranoia is running high at the moment but isn't this just plain wrong? https://github.com/google/oss-fuzz/issues/11760#issuecomment-2027731068 As far as I can tell the hansjans162 was created in 2023 and the tukaani project in 2022? (That the organization and the maintainer has the same creation date seems like the biggest
[21:10:37] <DeepThoughts> non-issue there is.)
[21:10:48] <sam_> yes it is wrong iirc
[21:10:51] <Guest45> all the TLAs are masters of psyops..
[21:10:53] <fullstop> q3k: I have used ghidra in the past to pick apart ip camera firmware and make minor changes
[21:10:58] *** Quits: Guest30 (~Guest30@070-126-159-142.res.spectrum.com) (Client Quit)
[21:11:08] <q3k> fullstop: well, take a look at it then, i'm not stopping you :)
[21:11:28] <fullstop> q3k: lol
[21:11:34] <katia> :D
[21:11:39] <bret> How many threat actors are in this rom right now!?
[21:11:55] <susi> o/
[21:12:00] <jess> o3o3
[21:12:02] <jess> o3o
[21:12:03] * jess peeks in
[21:12:07] <tk> I'm a paid threat actor except it's my day off today.
[21:12:16] *** Quits: GeDaMo (~GeDaMo@user/gedamo) (Quit: That's it, you people have stood in my way long enough! I'm going to clown college!)
[21:12:17] <Guest45> deep throat actor
[21:12:20] <aaabbb> i'm an unpaid threat actor but i'm not very threatening
[21:12:23] *** Joins: Guest66 (~Guest66@2a01:e0a:467:a5e0:94fd:1071:b699:ca9a)
[21:12:23] <tk> Only a threat actor from 9am to 5:30pm and only if you pay me.
[21:12:37] <DPA> I'm just here to see the fire.
[21:12:41] <tk> (to be fair, I don't do redteaming)
[21:12:44] *** Joins: khzn (~khzn@2603-7001-c200-0001-3c5b-f93d-abdf-3a31.res6.spectrum.com)
[21:12:51] <katia> i'm just here to roast the marshmallows on the fire
[21:13:19] <aaabbb> i'm just here to eat the marshmallows
[21:13:22] <dostoyevsky2> q3k: all you'd need to do in that manipulated liblzma_la-crc64-fast.o is to introduce a buffer overflow...
[21:13:46] <Snetry> I'm a paid actor, though I don't know if I am considered a threat
[21:14:18] *** Joins: gnom (~gnom@user/mong)
[21:14:32] *** Joins: xzipped (~xzipped@193.69.100.76)
[21:14:34] *** Quits: billchenchina- (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Ping timeout: 255 seconds)
[21:14:36] *** Quits: _annoyed (uid31791@id-31791.lymington.irccloud.com) (Quit: Connection closed for inactivity)
[21:14:59] *** Joins: Guest96 (~Guest80@mobile-user-c1d2e7-200.dhcp.inet.fi)
[21:15:00] <susi> so is Chuck Norris
[21:15:47] <Guest74> I would like to live in the universe where tomorrow it is found out that Jia Tan is Satashi Nakamoto
[21:15:51] *** Joins: xzcurious (~xzcurious@c-24-17-57-6.hsd1.wa.comcast.net)
[21:17:15] <aaabbb> imagine if all of this is a sophisticated attempt to get a perpetual backdoor into compilers by compromising compiler devs machines, to break the supply chains so far that the nsa is completely compromised, for the sole purpose of replacing all sipr terminals with rickroll videos
[21:17:38] *** Joins: woo2 (~paul@136.25.84.123)
[21:17:38] <s1gyn> https://lwn.net/Articles/967247/ <-- this is a good point
[21:18:01] <Paistin> Guest74: that would not make even the slightest of sense in a canon or shared universe. people are namedropping satoshi like he is some celebrity, when it was just a pseudonym to drop algorithm into a working concept that had worked on math papers since the 90's.
[21:18:05] <Guest45> good ol' Trusting Trust
[21:18:06] <i860> q3k: Since we're all speculating on which state actor it is, based on the multi-year long con-job, taking advantage of the trust of a long-time maintaining dev who didn't have the energy for it anymore, while also juxtaposed with a curious sloppy technical execution (but at the same time quite well hidden execution [that seems intentional]), of
[21:18:07] <i860> course I'm going with the CCP.
[21:18:37] *** Quits: Guest80 (~Guest80@mobile-user-c1d2e7-200.dhcp.inet.fi) (Ping timeout: 250 seconds)
[21:18:38] *** Quits: tipsfedoraa (~tipsfedor@216.243.40.138) (Quit: Client closed)
[21:18:44] *** Quits: Guest28 (~Guest28@tug-swl-230-11.tugraz.at) (Quit: Client closed)
[21:19:11] <q3k> i think the belgians did it
[21:19:11] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:6cb8:d0b1:8a05:5e09)
[21:19:14] <aaabbb> i860: what about the fact that the usa explicitly has a policy to mimic the mo of other state actors?
[21:19:17] *** Joins: tipsfedoraa (~tipsfedor@216.243.40.138)
[21:19:29] *** Joins: imyxh (~imyxh@user/imyxh)
[21:19:57] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:6cb8:d0b1:8a05:5e09) (Client Quit)
[21:20:21] *** Quits: Guest43 (~Guest43@2001:1838:200d:2:46c7:85d0:3a81:45a6) (Ping timeout: 250 seconds)
[21:20:21] <i860> aaabbb: Yeah, I also don't doubt that the NSA itself could be behind it as well, except why be sloppy about it when the gain of the actual exploit is significantly higher than the gain of making it appear like another state actor (although there could be political gamery involved there as well).
[21:20:56] <aaabbb> i860: if it works, it works. their end goal may have been to get into a specific group's machines and stealthily compromise the firmware
[21:21:09] <aaabbb> while everyone is clamoring to see if they're infected, the real victims blend in
[21:21:16] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:6cb8:d0b1:8a05:5e09)
[21:21:21] <Guest74> Paistin: I never claimed it would make sense. I would just like to live in that universe.
[21:21:22] <jess> their end goals may have been literally anything. is it genuinely helpful to speculate
[21:21:32] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:6cb8:d0b1:8a05:5e09) (Client Quit)
[21:21:37] <orkim> not?
[21:21:40] <Paistin> Guest74: I'd like to live in the universe where the plaintiff is Sam Hyde
[21:21:40] <katia> cisa alert: https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094
[21:21:48] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:6cb8:d0b1:8a05:5e09)
[21:21:56] <jess> lol sam hyde
[21:22:19] <sam_> i am begging u to avoid 'sam'
[21:22:25] <Paistin> sorry
[21:22:31] <i860> jess: I don't see the problem with speculating.. as long as it's semi-reasonable. it garners useful brain-storming and it's not like anyone is taking explicit direction from us on the next steps.
[21:22:37] <Guest74> Paistin: are you insinuating you have definite proof Sam Hyde is not Satoshi?
[21:23:06] <q3k> i mean we all seem to agree that the belgians did it, what's the point in speculating
[21:23:33] *** Quits: virtuous-sloth (~virtuous-@2604:3d09:385:3200:3bcf:8fca:97bb:27c4) (Quit: Client closed)
[21:23:34] <Guest42> +1 for Jia Tan = Sam Hyde
[21:23:34] <Guest45> https://www.kyberturvallisuuskeskus.fi/fi/haavoittuvuus_10/2024
[21:23:47] <i860> I bet Jia Tan never joins this channel again
[21:23:49] *** Quits: Guest66 (~Guest66@2a01:e0a:467:a5e0:94fd:1071:b699:ca9a) (Ping timeout: 250 seconds)
[21:23:51] <Guest45> There you go traficom, I was dissapointed it took this long
[21:23:57] <aaabbb> q3k: i thought it was agreed that it was scotlan
[21:24:18] <aaabbb> d
[21:24:25] <tk> i860: no but I wouldn't be surprised if someone related to whatever state sponsored activity resulted in this compromise is in this channel monitoring it
[21:24:42] <fullstop> if I build from the source tarball on x64, will liblzma_la-crc64_fast.o be the one with the backdoor?
[21:24:56] <mspo> is it still published?
[21:25:00] <tk> fullstop: no, there's more checks than just x86
[21:25:05] *** Quits: xzcurious (~xzcurious@c-24-17-57-6.hsd1.wa.comcast.net) (Ping timeout: 252 seconds)
[21:25:07] <orkim> deb/rpm checks too
[21:25:21] <q3k> yeah, check the injected.txt code from original post
[21:25:33] <susi> i860: what was their nick?
[21:25:35] <fullstop> ah, ok.  I will try to load the tainted object file again
[21:25:38] <q3k> https://www.openwall.com/lists/oss-security/2024/03/29/4/1
[21:25:42] <fullstop> ghidra didn't do so well with it
[21:25:58] <q3k> fullstop: load a liblzma.so instead, eg. from fedora builds
[21:26:05] <fullstop> good idea.
[21:26:08] <q3k> loading the .o elf isn't worth it
[21:26:22] *** Joins: Guest53 (~Guest53@188.27.254.149)
[21:26:28] <q3k> i use this build https://koji.fedoraproject.org/koji/buildinfo?buildID=2417414
[21:26:29] <fullstop> the elf from a 5.6.1 build decompiles fairly well
[21:26:33] *** Joins: Guest12 (~Guest57@2a00-12d0-ae02-f201-7271-7b1a-5d1c-78a4.ip.tng.de)
[21:26:40] <q3k> now go to _get_cpuinfo
[21:26:42] <q3k> and enjoy the pain
[21:26:46] <aaabbb> does lzip link against liblzma?
[21:26:49] <Guest74> instead of decompilng the binary wouldn't it be possble to isolate it in some kind of contained environment and study how it behaves?
[21:26:50] <q3k> sorry, _get_cpuid
[21:27:16] <q3k> Guest74: yes, that's called dynamic analysis, it's probably the best way to go about this
[21:27:27] *** Joins: ponky (ponky@shardi.fi)
[21:27:43] <q3k> plain static analysis seems like a waste of time here the longer i look at it
[21:27:44] <dostoyevsky2> q3k: isn't the _get_cpuid part of the ifunc? 
[21:27:48] *** Joins: Guest89 (~Guest89@70.110.183.70)
[21:28:00] <i860> tk: oh yeah, no doubt they're here
[21:28:08] <q3k> the _get_cpuid function is what gets overloaded at build/link time if the payload is compiled in
[21:28:15] *** Joins: virtuous-sloth (~virtuous-@2604:3d09:385:3200:3bcf:8fca:97bb:27c4)
[21:28:26] <q3k> _get_cpuinfo is a symbol coming from the prebuilt .so, the injection script forces a call to it through source code patches
[21:28:47] <q3k> sorry, cpuid, not cpuinfo, argh
[21:28:57] <q3k> https://www.openwall.com/lists/oss-security/2024/03/29/4/1 C-f _get_cpuid
[21:30:10] <Paistin> Guest74: I think we have his picture, from CISA right now at this moment was faxed to my office https://i.imgur.com/SkoeomY.png
[21:30:23] <Paistin> how can he keep getting away with it
[21:30:57] *** Joins: f_ (~AUGESOUND@fases/developer/funderscore)
[21:31:39] <jess> https://infosec.exchange/@mainframed767/112180749990584294
[21:31:40] <jess> lol
[21:31:58] <A_Dragon> hahahahahaha
[21:31:58] <Habbie> nice.
[21:32:09] *** Quits: Fingel (~Fingel@user/fingel) (Quit: Fingel)
[21:32:36] <Guest74> Paistin =)
[21:32:50] <tk> I think a good thing to investigate would be if it would be possible to downgrade xz until before any contributions to it were made by Jia Tan
[21:33:01] <f_> hm?
[21:33:10] <orkim> i don't normally time my ssh sessions either... i wonder how that was even discovered
[21:33:10] <Guest74> that account name cracked me up Soldier of Fortran
[21:33:15] <Habbie> tk, that's a thing many distributions did today
[21:33:20] <jess> CISA seems to suggest downgrading to 5.4.6 is fine, i'd trust them
[21:33:20] <Celelibi> jess, boy, that escalated quickly.
[21:33:33] <s1gyn> he's been on the project for like 2.5 years
[21:33:37] *** Joins: roote (~roote@2001:818:e95a:3b00:7127:4bfa:df2a:f26c)
[21:33:41] <tk> Habbie: many distributions downgraded to 5.4.6, but that release was made by Jia Tan
[21:33:44] <Habbie> orkim, https://mastodon.social/@AndresFreundTec/112180406142695845
[21:33:50] <orkim> ty
[21:33:53] <Habbie> tk, yes, so it is suspect, and i'm sure people will dig deeper
[21:34:03] <sam_> tk: yeah, I'm considering going further but I don't know yet.
[21:34:25] <tk> Yeah sure, I was just curious what the implications would be. How much work would be required to get a pre-Jia Tan version working just in case.
[21:34:33] <Guest45> the more emails etc from Jia Tan you read, the more difficult it is to believe that (s)he would be the actual eprson behind this.  too appropriate and nice and decent
[21:34:55] <Guest45> I mean, can't blame anyone from trusting him after acting this way for years
[21:34:58] <sam_> tk: I plan on testing it as the next big thing to do today
[21:35:03] <tk> thanks sam_
[21:35:03] <sam_> for gentoo anyway
[21:35:08] <sam_> but ofc i will share what i find
[21:35:08] <sam_> np
[21:35:10] <tk> you're my favorite gentoo maintainer although I don't use gentoo
[21:35:14] <Celelibi> Yeah, how unbelievable that people could be nice and appropriate and decent. xD
[21:35:14] <sam_> <3
[21:35:24] *** Quits: fooo_ (~jiatan_@2001:8a0:606a:100:5f5e:b41f:79f5:1e95) (Quit: Client closed)
[21:35:24] <f_> :P
[21:35:30] <aaabbb> Guest45: nations state threat actors always act like that
[21:35:33] <tk> the fact that you're the only gentoo maintainer I know of isn't important either
[21:35:41] <sam_> hahaha
[21:35:47] <benjaminl> listen if I was gonna try to backdoor openssh, I would write nice and appropriate and decent emails
[21:35:50] <benjaminl> to improve my chances of success
[21:36:01] <jess> i will say sam_ is viewed quite favourably by Libera Chat itself :)
[21:36:08] <tipsfedoraa> Guest45: yes, it's called social engineering. not a new concept
[21:36:18] <Snetry> genoo
[21:36:19] <tk> I vote sam_ for gentoo maintainer of the year.
[21:36:24] <Celelibi> benjaminl, some people do it anyway because that's who they are.
[21:36:48] *** Joins: sauce (~sauce@free.and.open.sauce.icu)
[21:36:57] *** Joins: idar (~idar@user/idar)
[21:37:33] <Guest45> not only emails but nice git commits with good commit messages etc
[21:37:53] <i860> straight ahead confidence scam
[21:38:03] <q3k> it's almost as if people working for three later agencies are nice and competent people :^)
[21:38:16] *** Quits: tipsfedoraa (~tipsfedor@216.243.40.138) (Quit: Client closed)
[21:38:17] <aaabbb> *pretending to be nice
[21:38:19] <Guest45> I mean looks like solid work for me. but definedly not chinese, I know lots of chinese people and you can spot their english
[21:38:24] <Celelibi> Ah? Too bad I work for a 4 letter agency, then.
[21:38:35] *** Joins: tipsfedoraa (~tipsfedor@216.243.40.138)
[21:38:37] <f_> Being nice doesn't mean you can't backdoor xz..
[21:38:52] <aaabbb> Guest45: they won't be hiring the communications guy from a pool that doesn't have good english
[21:39:21] <Guest74> hiding in plain sight : https://chinese.yabla.com/chinese-english-pinyin-dictionary.php?define=tan+jia  meaning 'trip home'
[21:39:23] <aaabbb> Guest45: a threat actor trying to get into a project with emails like "heya fukin losers! y'alls code is shit, lemme fix it for ya" is not going to engender the kind of reactiosn tht they want
[21:40:01] <Guest45> but think about it, how can any project defend them agains this?  it is very difficult to never trust anyobe
[21:40:11] <Celelibi> Depends who you target with your social engineering. Some people might be more susceptible if you show more character than a flat emotionless persona.
[21:40:19] *** Guest74 is now known as rsut
[21:40:57] <q3k> you don't even need to social engineer most oss maintainers out there
[21:41:21] <f_> q3k: yeah
[21:41:38] <q3k> most of us would be more than happy that someone else, anyone else is actively looking to help
[21:41:49] <Guest45> well github even have the YOLO badge for blindly merging PRs
[21:41:51] <dostoyevsky2> q3k: interesting how the original liblzma_la-crc64_fast.o doesn't actually have many symbols: https://termbin.com/m3sa vs the injected one: https://termbin.com/phrl
[21:41:55] <f_> Just try to be some kind of trusted contributor with push access and there you are.
[21:41:56] <i860> q3k: yep, and they know that
[21:42:18] <Celelibi> f_, then you need the skills to sneak in your backdoor.
[21:42:25] *** Joins: Guest23 (~Guest23@bras-base-ktnron0814w-grc-01-184-146-159-136.dsl.bell.ca)
[21:42:31] <q3k> dostoyevsky2: all these symbols from the injected one are fanfiction, btw
[21:42:33] <f_> Celelibi: yup
[21:42:35] <Celelibi> But that's arguably the easy part.
[21:42:40] <q3k> they have nething to do with liblzma functionality
[21:42:41] *** Quits: Guest23 (~Guest23@bras-base-ktnron0814w-grc-01-184-146-159-136.dsl.bell.ca) (Client Quit)
[21:42:51] *** Quits: Guest99 (~Guest30@2001:b07:5d2a:626b:a935:b56a:dce2:6b71) (Quit: Client closed)
[21:42:55] <q3k> the only callbacks to liblzma i've seen are lzma_alloc/free and a no-op lzma_check_init
[21:42:55] *** Quits: Guest89 (~Guest89@70.110.183.70) (Quit: Client closed)
[21:42:56] <rsut> did y'all miss my comment about 'Jia Tan' literaly translating to "Home Trip"? i mean thats crazy no?
[21:43:03] <f_> It's possible they've been planning to do this for a while
[21:43:06] <aaabbb> rsut: not crazy at all
[21:43:12] <f_> but I think that was already mentioned
[21:43:15] <jess> names usually mean things, shockingly
[21:43:17] <aaabbb> i wonder if any nation state threat actor in the history of ever has apropriately set the rfc 3514 evil bit
[21:43:17] <Rounin> rsut: Mandarin has tons of homonyms, though... It could mean a zillion things
[21:43:35] <Snetry> if you threw the name into a translator its not worth thinking about
[21:43:53] <aaabbb> no threat actor is gonna think "hehehe i'm gonna hide my true intentions in my name"
[21:43:57] <aaabbb> they'll pick a generic name
[21:44:01] *** Joins: Guest3 (~Guest45@p4fd7f5a8.dip0.t-ipconnect.de)
[21:44:03] <Rounin> Before I kill you, Mr. Bond... :D
[21:44:03] <q3k> that's borderline typing stuff into windings and then going 'omg it matches!!!!'
[21:44:16] <f_> :P
[21:44:16] <Celelibi> aaabbb, they do in stories for children.
[21:44:29] <rsut> Seems like a big coincidence to me
[21:44:36] <tk> I mean, I don't think it can be ruled out that someone malicious might do something like that. It just seems too obvious in this case.
[21:44:36] <Snetry> I'm gonna contribute a patch to the Linux kernel with my email not-a-backdoor@example.com
[21:44:54] <aaabbb> rsut: how? it's "home trip", it's not like it translated to "backdoor developer"
[21:44:55] <f_> how is 'home trip' related to xz or the backdoor
[21:45:02] <Celelibi> Reminds me @no_a_cop on twitter. xD
[21:45:26] <blingbling> for now on I'm only going to trust projects with rude maintainers
[21:45:38] <Snetry> Linus Torvalds?
[21:45:45] <hmw[at]> ,.
[21:45:49] <hmw[at]> lol
[21:45:55] <katia> he's not rude
[21:46:00] <Celelibi> lol
[21:46:02] *** Quits: Guest3 (~Guest45@p4fd7f5a8.dip0.t-ipconnect.de) (Client Quit)
[21:46:05] <katia> anymore
[21:46:14] <aaabbb> he is, just not as blatantly
[21:46:17] <hmw[at]> I miss the rude Linus
[21:46:19] <Celelibi> Incidentally, I love how Torvalds designed Linux. ^^
[21:46:21] *** Quits: corn7890 (~corn7890@2601:441:4280:8ab0:529:cc85:341e:7b11) (Ping timeout: 250 seconds)
[21:46:22] <aaabbb> me too
[21:46:27] <tk> He was a bit rude recently relating inodes to someone from google(?)
[21:46:46] *** Quits: syu (~syu@user/syu) (Quit: WeeChat 4.1.2)
[21:46:49] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:6cb8:d0b1:8a05:5e09) (Quit: nyaa~)
[21:46:54] <tk> To be fair, I try to play devil's advocate in these cases but I can't see torvald's perspective on that one. I don't think the person deserved that amount of moaning
[21:47:08] *** Joins: syu (~syu@user/syu)
[21:47:15] <aaabbb> but he's just famous. tdr (of openbsd), gkh (of linux), lennart poettering (of systemd) are all assholes
[21:47:23] <tk> https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04127.html
[21:47:34] <tk> it's a very interesting thread to read anyway
[21:47:38] <Celelibi> gkh is an asshole?
[21:47:39] *** Quits: khzn (~khzn@2603-7001-c200-0001-3c5b-f93d-abdf-3a31.res6.spectrum.com) (Quit: Client closed)
[21:47:54] <f_> tdr?
[21:47:59] <tk> theo de raadt
[21:48:06] <f_> yes I know
[21:48:08] <Celelibi> I've only seen gkh in on stage, but he seems like a nice guy.
[21:48:15] <Celelibi> -in
[21:48:15] <aaabbb> Celelibi: at times, he makes linus seem like a nice guy
[21:48:17] <rsut> hans reiser
[21:48:25] <Celelibi> My favorite!
[21:48:29] <ba> the nice filesystem man?
[21:48:29] <aaabbb> rsut: well that's a whole 'nother level of insane :p
[21:48:29] <f_> lol
[21:48:32] <tk> And I don't think greg is an asshole, he sent me a definitely-not-canned email one year asking me who I was and who was paying me to contribute to linux.
[21:48:44] <s1gyn> Jia Tan is Hans Reiser
[21:48:49] <aaabbb> "the nice filesystem man?" fucking loled
[21:48:50] <hmw[at]> lol
[21:48:54] *** Joins: Guest51 (~Guest61@host-194-22.calaw27p.losangeles.ca.us.clients.pavlovmedia.net)
[21:49:09] <f_> s1gyn: nice, now find proof confirming that.
[21:49:28] <aaabbb> f_: jia tan did a bad thing. hans reiser did a bad thing. QED
[21:49:55] <f_> many people did bad things
[21:50:08] <f_> does it mean they all are the same person?
[21:50:12] *** Joins: Guest93 (~Guest93@2600:4041:539c:f700:9c69:f85b:71c3:dc06)
[21:50:14] *** Quits: blasphemy (~kvirc@185.65.134.244) (Ping timeout: 268 seconds)
[21:50:23] <aaabbb> "jia tan" translates to "home trip", "hans", "home", both 4 letters that start with h. coincidence?!?!?
[21:50:35] *** Quits: Guest45 (~Guest45@dkw8pzyyyyyyyyyyybd3y-3.rev.dnainternet.fi) (Quit: Client closed)
[21:50:44] <hmw[at]> Reminds me on the idea, that all electrons and positrons are in fact just one object, bouncing forward and backwards through time
[21:50:56] <jess> han shot first
[21:50:59] <aaabbb> hmw[at]: the one-electron-theory, but that was debunked a long time ago
[21:50:59] <rsut> there's a good scifi story about that. called the egg or something
[21:51:10] <f_> aaabbb: cool
[21:51:23] <Rounin> I mean, "jia" can mean "vacation", and "Reise" can mean travel
[21:51:30] <hmw[at]> Not aware of a debunking, also it might be impossible to debunk. But physicists can be really weird, so who knows.
[21:51:41] <hmw[at]> Reiser is not related to Reise tho
[21:51:46] <rsut> https://galactanet.com/oneoff/theegg_mod.html pretty short to read
[21:51:48] <aaabbb> https://en.wikipedia.org/wiki/One-electron_universe
[21:51:58] <hmw[at]> Grammatically it translates to "one who travels", but it is not a German word.
[21:52:04] <hmw[at]> That would be Reisender
[21:52:04] <f_> aaabbb: now find more proof
[21:52:08] <Rounin> hmw[at]: That's what they want you to believe
[21:53:12] <aaabbb> f_: reiser wrote code in c. jia tan wrote code in c. "coincidence" starts with a c! coincidence!? i think not!
[21:53:33] <A_Dragon> ~coincidence 
[21:53:33] <f_> MOAR proof!
[21:53:51] *** Joins: rolf (~rolf@188.89.99.81)
[21:54:02] <Rounin> It is settled
[21:54:17] <aaabbb> both jia tan and hans reiser are named hans reiser, except jia tan
[21:54:20] <f_> I also wrote code in C, coincidence!?
[21:54:31] <hmw[at]> f_: Oh, that was you?
[21:54:45] <f_> of course (not)
[21:54:56] *** Joins: Guest47 (~Guest91@2a01:5d00:100c:8d00:b8f9:2e12:9637:920)
[21:55:05] <Celelibi> C must be the language of evil, then.
[21:55:21] <A_Dragon> 🦀
[21:55:22] <Noisytoot> "of course" also contains a C, coincidence‽
[21:55:24] <Celelibi> Well, for some of my students, it is.
[21:55:26] <aaabbb> Celelibi: they do say that undefined behavior can cause the summoning of nasal demons...
[21:55:34] <f_> I think not!!?
[21:55:54] <f_> Celelibi: Celelibi starts with C, coincidence?
[21:56:01] *** Quits: Guest53 (~Guest53@188.27.254.149) (Quit: Client closed)
[21:56:27] <f_> A_Dragon: What a rusty crab
[21:56:28] <Celelibi> C is the third letter of the alphabet. Like the trinity.
[21:56:40] <Celelibi> C is the biblically accurate language.
[21:56:40] <rolf> Coincidence has 3 C's in it. 666 also has 3 digits... coincidence ??!?
[21:56:48] <f_> crab starts with c, coincidence????????
[21:56:54] <hmw[at]> biblically accurate lol
[21:56:58] <DPA> You may not believe me this, but I write good C code.
[21:57:01] *** Joins: Guest30 (~Guest30@2001:b07:5d2a:626b:a935:b56a:dce2:6b71)
[21:57:05] *** Quits: syu (~syu@user/syu) (Quit: WeeChat 4.2.1)
[21:57:11] <Celelibi> DPA, just like Hans Reiser!
[21:57:17] <i860> I don't mind Linus being "rude." There needs to be more hard core rude types safeguarding this massively important set of code honestly. People being "nice" gets other people killed. That doesn't mean being a jerk when it's unwarranted of course, but most of the rude stuff I've seen from Linus has been involved with contributors continuously trying
[21:57:17] <i860> to push for something that just shouldn't be there in the first place and someone finally having to step in to put their foot down. He could probably temper the drama a bit, but only just a bit.
[21:57:18] <ba> "Known for: ReiserFS, murder" this wikipedia infobox shouldn't be so funny
[21:57:28] <aaabbb> ba: lmfao
[21:58:19] <Snetry> i860: on the other hand we can't be on this earth forever, so if you want your projects to continue you best be nice to those who could run continue them 
[21:58:25] *** Joins: Guest39 (~Guest30@79.184.230.86.ipv4.supernova.orange.pl)
[21:58:29] <mikolajw> https://www.mail-archive.com/search?l=xz-devel@tukaani.org&q=from:%22Jigar+Kumar%22
[21:58:44] <f_> I wonder
[21:58:50] <Celelibi> i860, yeah, but "code like this make me want to run naked with a chainsaw" is funny, but uncalled for.
[21:58:55] <mikolajw> Could this person, Jigar Kumar, be related to Jia Tan?
[21:59:13] *** Quits: blingbling (~bling@89.125.87.194) (Quit: Client closed)
[21:59:14] <f_> A_Dragon: looks like some flags were set here 4 hours ago :P
[21:59:21] <sam_> mikolajw: why do you think that?
[21:59:27] <i860> snetry: on the other hand, being overly nice almost guarantees those projects get turned into a trash heap much quicker than people expect. There's something to be said for healthy protectionism and gatekeeping of multi-decade-old very important code.
[21:59:43] <aaabbb> mikolajw: yeah they're related. about 99.98% of their dna matches
[21:59:47] <Snetry> mikolajw: unless you have direct evidence that ties them to this, lets not drag people into this
[21:59:50] <sam_> ^^
[21:59:55] <Snetry> i860: not really, no
[21:59:56] <mikolajw> My apologies
[21:59:57] *** Quits: Guest12 (~Guest57@2a00-12d0-ae02-f201-7271-7b1a-5d1c-78a4.ip.tng.de) (Quit: Ping timeout (120 seconds))
[22:00:00] *** Joins: ndesaulniers (sid510531@id-510531.lymington.irccloud.com)
[22:00:04] <Rounin> There is interestingly a person who did help Jia Tan with some of the commits... His name was Hans
[22:00:12] <Snetry> Even Linus has turned nicer when he realized being a constant asshole isn't helping anyone or improving the state of things
[22:00:17] <Snetry> it just made people not want to contribute
[22:00:23] *** Joins: luca0N (~luca0N@nautilus.luca0n.com)
[22:00:23] <ba> mikolajw: it's pretty suspect that he pressures for a change of maintainer and then disappears, but not conclusive
[22:00:28] <orkim> hans jansen?
[22:00:31] <aaabbb> Rounin: tht proves it!
[22:00:32] <Celelibi> i860, being a gatekeeper isn't mutually exclusive with being nice.
[22:00:33] <Rounin> Yeah :D
[22:00:37] <tk> i860: there's a difference in general between having a firm stance on what is allowed inside a project, and being unnecessarily rude
[22:01:06] <i860> Yes, that's why I was saying he could temper the drama a bit. I think he gets a bit too over the top in his response, I agree with that.
[22:01:11] <tk> i860: you can successfully run a project where below-the-bar patches simply don't get accepted without wasting everyone's time without also needing to shout at people all the itme
[22:01:15] <orkim> i saw that account submitted the update to debian, but is only 1 week old.. /shrug
[22:01:18] <i860> He could simply assert "here's why this isn't going to happen" and not make it personal
[22:01:30] <Snetry> thats what he does now
[22:01:33] <f_> I wonder if some forks of xz would emerge..
[22:01:45] <aaabbb> f_: there's already lzip
[22:01:49] <Rounin> Short for Hans Jia Nakamoto Satoshi unh... Ignore the En
[22:01:53] <aaabbb> which is a superior format (an also lzma)
[22:01:55] <hmw[at]> afaik that's what he does the first 2 or 3 times. He only gets angry, when people refuse to listen
[22:02:00] <Guest93> hmw[at]: f_ thats the "joke". OSS is a thankless job. if forks were to emerge, those people would already be contributors
[22:02:01] <Guest93> lol
[22:02:18] <Rounin> Or they could switch to Zstandard I suppose... We don't know what'll happen with that, but it's maintained
[22:02:25] <Rounin> Perhaps there's some kind of patent trap in there
[22:02:34] <Snetry> no
[22:02:36] <hmw[at]> I'd consider this type of so called "rude" behaviour simply an idiot filter
[22:02:44] <aaabbb> zstd compression ratio is crap compared to lzma
[22:02:45] <orkim> thats it.. back to telnet..
[22:02:49] <i860> I guess what I'm somewhat describing here are people merging crap in under the guise of "well the contributor put a lot of effort into this" type stuff.. I even see people do this type of thing at work.
[22:02:50] *** Joins: syu (~syu@user/syu)
[22:02:56] <Snetry> zstandard was made by facebook and is intentionally widely available
[22:02:56] <Rounin> aaabbb: Even zstd -19?
[22:02:59] <Celelibi> About the future of xz, I think we'll just let the dust settle, wait for a stance of Lasse and see what happen.
[22:03:02] <aaabbb> Rounin: yes
[22:03:02] <Snetry> its even in the Linux kernel
[22:03:13] *** Quits: rsut (~Guest74@2001:1c02:2f15:8e00:52e5:5cc2:d131:b561) (Quit: Client closed)
[22:03:15] <f_> Celelibi: yeah maybe
[22:03:18] <Noisytoot> aaabbb: I don't think lzip is a fork of xz
[22:03:26] <Snetry> alternatively
[22:03:27] <aaabbb> Noisytoot: no but it's a viable replacement
[22:03:28] <Snetry> just let it die
[22:03:29] <sam_> I just want to say that Jia's contributions were not junk and Lasse didn't Just Add Him
[22:03:36] <i860> I don't think people need to stop using xz, that's absurd. I think the repo needs to be rolled back to some x point in time.
[22:03:37] <sam_> it's not like he just bruteforced his way in via nagging
[22:03:43] <DPA> Why does a compression library need progress? It's one algorithm, and has 1 job. The one thing it's really needed for is not going to change.
[22:03:51] <Celelibi> Snetry, some successful fork will naturally emerge.
[22:03:54] <sam_> is persistence/helping someone desperate part of it, maybe, but his contributions were non-trivial
[22:04:06] <f_> sam_: Social engineering I guess
[22:04:07] <Celelibi> DPA, it does change.
[22:04:08] <sam_> right
[22:04:11] *** Joins: tomreyn (tomreyn@megaglest/team/tomreyn)
[22:04:29] *** Joins: bling (~bling@89.125.87.194)
[22:04:30] *** Joins: cryptonix (~name@user/cryptonix)
[22:04:37] *** bling is now known as blingbling
[22:04:47] <Celelibi> I don't know the details of LZMA, but most likely, only the decompressing algorithm is set in stone.
[22:04:52] <Snetry> what do you *mean* things change and nothing is ever complete?
[22:05:04] *** Joins: Guest46 (~Guest13@c-67-187-148-183.hsd1.ca.comcast.net)
[22:05:06] <sam_> i think this is a bit of naive, sorry
[22:05:11] <hmw[at]> That's what the kids nowadays say
[22:05:16] <sam_> s/of//
[22:05:21] <sam_> new filters for example are something xz has gained
[22:05:24] <cjwatson> and performance work isn't a silly thing to spend time on
[22:05:27] <sam_> parallel compression and decompression..
[22:05:33] <hmw[at]> Remember that exponentially increasing bounty for people finding a bug in TEX?
[22:05:39] <i860> 1. Identify important library that other important code is reliant on. 2. Determine if maintainers are otherwise not actively maintaining it or looking to take a break/move on/etc. 3. Start contributing to said project with what looks like useful changes and earn the trust of the maintainer. 4. Become the new maintainer. 5. Backdoor everyone.
[22:05:39] <hmw[at]> It must be in the billions by now
[22:05:50] <sam_> i860: indeed.
[22:05:58] <Snetry> Man
[22:06:14] *** Quits: Guest47 (~Guest91@2a01:5d00:100c:8d00:b8f9:2e12:9637:920) (Quit: Client closed)
[22:06:32] <Snetry> I would love if it I opened an archive viewing program and it was just stuck frozen while xz twiddled its thumbs in the background
[22:06:41] <Snetry> surely all xz does is compress and decompress
[22:06:50] <Guest93> https://xkcd.com/2347/
[22:06:52] <Guest93> always applies.
[22:07:01] <cjwatson> hmw[at]: Knuth froze it at $327.68
[22:07:13] <hmw[at]> oh? lol ok
[22:07:16] <Snetry> why that specific number
[22:07:16] <Celelibi> Guest93 Yeah, I was thinking of that exactly. :)
[22:07:29] <cjwatson> 2^15 cents, shrug
[22:07:33] <Snetry> surely you can just bump it to $330
[22:07:40] <aaabbb> 327.68, i assume next was $655.36?
[22:07:50] <Celelibi> Has to be a power of two. It's a Knuth thing.
[22:07:51] <Snetry> cjwatson.... is that really it
[22:07:53] <hmw[at]> iirc it would double every year
[22:07:53] <DPA> We should've just stayed with gzip and deflate.
[22:08:02] <Celelibi> Just like the version of TeX slowly converge to pi.
[22:08:13] <Snetry> the max int16_t value
[22:08:16] <Snetry> god
[22:08:18] <cjwatson> Snetry: I dunno, I'm just going by wikipedia
[22:08:28] <cjwatson> but they were certainly powers of two
[22:08:43] <cjwatson> https://en.wikipedia.org/wiki/TeX#Development
[22:09:24] *** Quits: Guest42 (~Guest42@167.224.214.200) (Quit: Client closed)
[22:09:27] <xx> to everyone running the detection script, or `ldd` directly, I hope you read the manpage of ldd
[22:09:35] <xx> "you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code."
[22:09:38] <Guest93> lol
[22:09:50] *** Joins: Guest43 (~Guest43@2001:1838:200d:2:46c7:85d0:3a81:45a6)
[22:09:55] <Guest93> linux, where the scissors stab you
[22:09:55] <xx> I'd definitely call it an untrusted executable...
[22:10:20] <xx> sam_: might want to mention that in the gist, just so that more people learn this fact about ldd
[22:10:22] <blingbling> i860: there could be some project monitoring for important dependencies or libraries at risk of this but I'm not sure the best way to do it. Like if you were to look at xz a year ago you might say oh Lasse has become less active but Jia has taken up the mantle, everything is fine!
[22:10:30] *** Quits: Guest62 (~Guest62@nmal-25-b2-v4wan-166401-cust115.vm24.cable.virginm.net) (Quit: Connection closed)
[22:10:32] <sam_> xx: excellent point
[22:10:37] <xx> https://jmmv.dev/2023/07/ldd-untrusted-binaries.html lists alternatives
[22:10:38] <sam_> xx: let me get some tea then I will put that in
[22:10:44] <sam_> (we even maintain one of them ;))
[22:10:52] <sam_> not listed there tho
[22:10:52] <aaabbb> there are alternatives
[22:11:02] <Celelibi> readelf and objdump come to mind.
[22:11:09] <DPA> Running ldd is just a shortcut for setting a certain environment variable before starting the executable.
[22:11:10] <xx> libtree is pretty
[22:11:14] <aaabbb> Celelibi: i wouldn't trust those with untrusted executablese either...
[22:11:18] <sam_> yes please dont
[22:11:23] <sam_> i have a reference to give but i will find it post-tea 
[22:11:24] <sam_> brb
[22:11:36] <tk> if you have an untrusted executable, best put it on a VM on a dedicated machine before you poke it
[22:11:39] <aaabbb> any alternative shouldn't use libbfd or whatever and should use a tight seccomp
[22:11:50] <DPA> LD_TRACE_LOADED_OBJECTS=1 ls
[22:11:53] <tk> I mean, there are other tools but still
[22:12:05] <aaabbb> DPA: that's pretty much what ldd does
[22:12:18] <DPA> I know.
[22:12:22] *** Joins: dedz (sid498551@user/dedz)
[22:12:36] <virtuous-sloth> Interesting, targeting Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417
[22:13:22] <Celelibi> Yeah, he's been trying to push the new version to distros.
[22:13:29] <Celelibi> Not just ubuntu.
[22:13:36] <ba> Larhzu: if your handlers decide you no longer need your internal organs can I have them pls
[22:14:06] <q3k> ba: what the fuck
[22:14:07] <Guest93> interesting fedora report
[22:14:09] <Guest93> "port.  This is how it actually happened:
[22:14:10] <Guest93> (1) We built 5.6.0 for Fedora 40 & 41.  Jia Tan was very insistent in
[22:14:10] <Guest93> emails that we should update."
[22:14:21] <aaabbb> ba: Larhzu is not the bad guy
[22:14:26] <f_> hmm
[22:14:40] <aaabbb> he was (presumably) an innocent victim
[22:16:14] *** Quits: Guest78 (~Guest78@ip72-204-13-218.fv.ks.cox.net) (Ping timeout: 250 seconds)
[22:16:17] <i860> I find it curious how interested this "maintainer" is in ensuring all the distros are using the latest and greatest version of xz-utils all driven by a desire to fix a _valgrind error_  "This could break build scripts and test
[22:16:17] <i860> pipelines that expect specific output from Valgrind in order to pass." Now I'm not saying that devs who care about their project and proactively let other dependent projects know about bugfixes is unheard of or anything, but there's a certain artificial urgency to these requests. Most of the time this type of thing would be handled by distro
[22:16:18] <i860> maintainers noticing and either rolling back or looking for the updated version on their own rather than library maintainers contacting every distro to update things.
[22:16:30] *** Joins: Guest16 (~Guest16@2601:500:8082:16cc:f08f:d890:1dfe:daaf)
[22:17:39] *** Quits: Guest16 (~Guest16@2601:500:8082:16cc:f08f:d890:1dfe:daaf) (Client Quit)
[22:17:43] *** Joins: Guest84 (~Guest84@p57a84bae.dip0.t-ipconnect.de)
[22:17:52] <f_> I think work should be done to mitigate this backdoor and audit all of Jia's contributions.
[22:18:03] <f_> As to find other backdoors..
[22:18:20] *** Quits: Guest39 (~Guest30@79.184.230.86.ipv4.supernova.orange.pl) (Quit: Client closed)
[22:18:25] <i860> And anything else that Hans Jensen account might've been involved with.
[22:18:42] *** Quits: Guest20 (~Guest91@p5b34e3b8.dip0.t-ipconnect.de) (Quit: Client closed)
[22:18:49] *** Joins: blasphemy (~kvirc@185.65.134.244)
[22:19:01] <ba> Larhzu: oh right sorry about that, please keep your organs
[22:19:10] <susi> I think Hans Jensen is a funny name
[22:19:32] *** Joins: Guest85 (~Guest85@modemcable154.4-162-184.mc.videotron.ca)
[22:19:35] <f_> i860: yeah
[22:19:39] <dostoyevsky2> q3k: `*(void (__fastcall **)(_QWORD))(v2 + 24)' I keep seeing code like that in the decompilation... that's an odd style for c code...  and then IDA is complaining that some of those variables used in the call indirection seem to be undefined
[22:19:42] <f_> Perhaps audit all of xz
[22:20:11] <q3k> are you loading the .o or the .so?
[22:20:24] * hmw[at] fetches his C64 from the shelf. No weird updates in 30+ years.
[22:20:34] <dedz> Well, yeah. But this got discovered due to performance issues that it caused. If performance issues were not present, it would've most likely not have been found at all. there should be other compromised software like xz but not found yet
[22:20:34] *** Quits: tipsfedoraa (~tipsfedor@216.243.40.138) (Ping timeout: 250 seconds)
[22:20:43] <aaabbb> hmw[at]: careful of KERNAL exploits!
[22:20:48] <hmw[at]> hehe
[22:21:02] *** Joins: Guest43636 (~Guest4363@p5b34e3b8.dip0.t-ipconnect.de)
[22:21:14] <dostoyevsky2> q3k: the .o file attached here: https://www.openwall.com/lists/oss-security/2024/03/29/4
[22:21:20] <Celelibi> Beware of carnal exploits, tho.
[22:21:21] <q3k> load a prebuilt .so, eg from fedora
[22:21:43] *** Joins: Guest94 (~Guest94@143.58.136.206)
[22:21:47] *** Joins: Guest82 (~Guest82@78-57-169-35.static.zebra.lt)
[22:21:48] <q3k> the .o is weird to analyze because it attempts to poke at .got/.plt which is not present in the .o
[22:21:56] <q3k> as the thing is not linked/relocated fully
[22:22:55] *** Joins: Yogurt (~Yogurt@158.51.82.203)
[22:23:41] *** Joins: kit_ty_kate (~kit_ty_ka@46.23.94.234)
[22:24:02] *** Quits: Guest85 (~Guest85@modemcable154.4-162-184.mc.videotron.ca) (Ping timeout: 250 seconds)
[22:24:14] <dostoyevsky2> q3k: like the indirection might be a side-effect of -fPIC?
[22:25:53] <st3fan> did someone post a full disassembly / reverse of the code?
[22:26:25] *** Joins: Guest62 (~Guest62@99-145-82-98.lightspeed.brhmal.sbcglobal.net)
[22:26:26] <st3fan> dostoyevsky2: maybe it is written in a different language
[22:26:36] <dostoyevsky2> st3fan: I posted some links to a decompiled version a couple of times
[22:28:07] <dostoyevsky2> q3k: can you upload the version that decompiles better to https://dogbolt.org?
[22:28:17] *** Joins: Guest4 (~Guest4@2a01:e34:ec58:3c10:d627:402a:b0a8:1bd)
[22:29:45] *** Joins: Guest10 (~Guest57@2a00-12d0-ae02-f201-7271-7b1a-5d1c-78a4.ip.tng.de)
[22:29:46] *** Quits: Guest62 (~Guest62@99-145-82-98.lightspeed.brhmal.sbcglobal.net) (Client Quit)
[22:30:19] *** Quits: Guest10 (~Guest57@2a00-12d0-ae02-f201-7271-7b1a-5d1c-78a4.ip.tng.de) (Client Quit)
[22:30:31] *** Joins: timetraveler___ (sid527600@id-527600.lymington.irccloud.com)
[22:30:36] *** Joins: Guest40 (~Guest91@2a01:5d00:100c:8d00:b8f9:2e12:9637:920)
[22:31:08] *** Joins: Guest67 (~Guest61@91.122.183.146)
[22:31:44] *** Quits: Guest40 (~Guest91@2a01:5d00:100c:8d00:b8f9:2e12:9637:920) (Client Quit)
[22:31:54] *** Joins: Guest33 (~Guest63@2601:647:6400:e66c:a850:a3fb:a6c8:a7fa)
[22:32:55] *** Quits: Guest67 (~Guest61@91.122.183.146) (Client Quit)
[22:33:29] *** Joins: tipsfedoraa (~tipsfedor@216.243.40.138)
[22:36:16] *** Joins: Guest60 (~Guest60@185.237.223.100)
[22:38:25] *** Parts: dedz (sid498551@user/dedz) ()
[22:39:06] *** Joins: crabbedhaloablut (~crabbedha@user/crabbedhaloablut)
[22:40:39] <Guest46> is it over
[22:40:55] *** Joins: Ahnberg (ahnberg@ahnberg.pp.se)
[22:41:01] *** Quits: Guest84 (~Guest84@p57a84bae.dip0.t-ipconnect.de) (Quit: Client closed)
[22:41:03] <Celelibi> Looks like the chaos is settling.
[22:41:04] *** Joins: bt__ (~bt__@user/bt/x-8819368)
[22:41:06] *** Joins: Lena_ (~Lena@2001-4dd6-c873-1-6cd4-b2c3-95f9-377e.ipv6dyn.netcologne.de)
[22:45:29] <i860> sam_: seems like there were indications of something up, even in here? https://bugs.gentoo.org/925415
[22:45:35] <sam_> eh
[22:45:37] <sam_> the problem is
[22:45:44] <sam_> *that part* was totally legitimate, like
[22:45:49] <boud> The chaos is not quite settled: debian is thinking of downgrading to pre-JiaT75 and considering 5.3.1, but that could break some key packages that depend on newer symbols ...
[22:45:52] <sam_> gcc clearly gets this wrong
[22:45:58] <sam_> BUT
[22:46:09] <sam_> the redhat/fedora bug where they had valgrind issues i should've looked more into
[22:46:27] <sam_> boud: gentoo is going down to 5.4.2 as the last release Lasse signed, as a compromise for now
[22:46:37] <sam_> I couldn't justify going further without evidence, because of breakage
[22:46:48] <orkim> both accounts suspended on github now.. i didn't see that mentioned in here
[22:47:08] <sam_> how can you tell?
[22:47:11] <Guest93> i wonder if Lasse got doppelgangered
[22:47:15] <i860> sam_: ah, yeah I see what you mean.. this is the legitimate ifunc issue
[22:47:17] <boud> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024 /me forgot the link
[22:47:35] <Guest93> Lasse shares control with Jia
[22:47:36] <sam_> i860: and I feel kind of dumb because it sort of intimidated me/made me feel at ease with "well, maybe there's other issues"
[22:47:39] <orkim> https://github.com/tukaani-project   <-- look at both accounts followers
[22:47:41] <sam_> i860: because ifunc *is* super brittle, for real
[22:47:42] <Guest93> maybe fades out because he is burnt out
[22:47:50] <orkim> they follow each other.. they both show the other as suspended
[22:47:51] <sam_> i860: so I just figured "well ok it's another one of those, whatever, and i cant repro on gentoo"
[22:47:57] <Guest93> and Jia takes control because tukanni.org was given to him
[22:48:02] <Guest93> and lasse used it for his email
[22:48:06] <sam_> i860: instead I should have tried to look at why fedora hit it and i couldn't, as it would've shown it :/
[22:48:15] <sam_> kicking myself
[22:48:49] <orkim> https://github.com/JiaT75?tab=followers   <-- scroll down toward the bottom.. you'll see the suspended icon
[22:48:52] *** Joins: Guest81 (~Guest68@2001:9e8:58c4:ca00:f160:f847:bec8:592)
[22:48:52] <sam_> thanks
[22:49:03] <ba> tbf you were _this_ close to spotting a very sophisticated operation, don't feel too bad.
[22:49:03] <Snetry> github likely suspended them until things get cleared up
[22:49:07] <orkim> and here https://github.com/Larhzu?tab=followers
[22:49:12] <Snetry> which on one end is a bit of an overreach
[22:49:17] <Snetry> and on the other end is reasonable
[22:50:05] <Guest93> gotta wonder what Jia's punishment by his superiors will be
[22:50:07] <Guest93> for fucking up
[22:50:12] <Guest93> lolol
[22:50:13] <sam_> ba: <3
[22:50:14] <ids1024> Odd that Github shows suspended there, but not on someone's profile
[22:50:21] <Guest93> the backdoor is just a little too buggy
[22:50:36] <ids1024> Probably both accounts have been reported by a bunch of people to Github today.
[22:50:36] *** Joins: Guest45 (~Guest45@75.164.92.136)
[22:50:39] <orkim> ya.. not sure why its just on follower lists
[22:50:40] <i860> sam_: you may not have figured it out right then but if you had a gut feeling something was off but just couldn't put your finger on it, that isn't meaningless either
[22:50:49] <orkim> thats weird.. maybe cached.. and it will show up later?
[22:52:33] *** Joins: mathis (~mathis@2605:a601:a9b2:e300:a01b:89c0:d32c:ad6f)
[22:52:36] *** Quits: mathis (~mathis@2605:a601:a9b2:e300:a01b:89c0:d32c:ad6f) (Client Quit)
[22:52:58] *** Joins: mathis123325234 (~mathis123@2605:a601:a9b2:e300:a01b:89c0:d32c:ad6f)
[22:54:45] <boud> sam_: there's a /usr/bin/sshd vs /usr/sbin/sshd comment for you on the Fediverse: https://toot.mirbsd.org/@mirabilos/statuses/01HT65R4K7Z35SQHN9SX9VTXY3
[22:54:52] <sam_> thanks!
[22:55:03] <boud> for the FAQ
[22:55:08] <sam_> i860: thank you
[22:55:09] *** Quits: blasphemy (~kvirc@185.65.134.244) (Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/)
[22:55:36] *** Quits: the-pete (~peter@user/the-pete) (Ping timeout: 268 seconds)
[22:55:57] <Guest60> isn't it funny how the backdoor existed for close to a month now but only 10 days ago JIA and Lasse added as maintainers https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.collin@tukaani.org/
[22:56:10] *** Quits: Guest33 (~Guest63@2601:647:6400:e66c:a850:a3fb:a6c8:a7fa) (Quit: Client closed)
[22:56:12] <sam_> not really because thats the kernel
[22:56:13] <sam_> not xz-utils
[22:56:24] <Guest60> more funny about the JIA tbh
[22:56:25] <Guest93> yea, the kernel has its own xz port embedded, rpobably not the most maintained
[22:56:28] <sam_> not that surprising, as they wer turning attention to the kernel side after wrapping up most work on xz-utils-5.6.x
[22:56:31] <sam_> oh yeah that part is kind of odd
[22:56:36] <Guest93> but it is possible that Jia stole control of tukaani.org
[22:56:39] <sam_> but i think it was because the kernel side hadnt got much love recently
[22:56:40] <Guest93> and is now pretending to be Lasse
[22:56:43] <Snetry> Web based IRC clients were a mistake
[22:56:48] <Guest93> hence the push to get 5.6.1 into the kernel in linux
[22:57:07] <st3fan> I would be very suspicious of that kernel patch after today's events
[22:57:16] <sam_> lasse had expressed his intention to give the kernel side some love just because it was next on his list
[22:57:23] <sam_> but yes ofc people shouldn't merge stuff for now
[22:57:24] <Guest93> but _was_ it lasse
[22:57:30] <sam_> i suspect it was, but dunno of course
[22:57:32] <Guest93> or was it jia pretending to be lasse
[22:57:36] <Guest93> we dont know who controls the domain now
[22:57:43] <Guest93> because the malicious tarballs were served from the domain
[22:57:46] <sam_> from what lasse told me i think lasse still controls tukaani.org, but i cannot be certain
[22:57:51] <Snetry> please no theories here
[22:57:54] <sam_> right
[22:58:05] *** Joins: Guest85 (~Guest85@modemcable154.4-162-184.mc.videotron.ca)
[22:58:16] *** Quits: Guest81 (~Guest68@2001:9e8:58c4:ca00:f160:f847:bec8:592) (Ping timeout: 250 seconds)
[22:59:47] *** Joins: johnny_ (~johnny@static.96.196.216.95.clients.your-server.de)
[22:59:57] *** Joins: Guest1 (~Guest82@h209-169-222-202.hbbsnm.dedicated.static.tds.net)
[23:01:00] <orkim> was tukaani.org really registered in 1985?
[23:01:16] <Guest93> it used to be a linux distro
[23:01:32] <orkim> so.. that would date it to 1990 maybe?
[23:01:40] <Guest93> https://ftp.uni-bayreuth.de/packages/tools/lzma/tukaani.org/
[23:01:55] <Guest93> >Tukaani is a project with multiple goals. The main goal is to make a Slackware-based Linux distribution that fits on one CD-ROM. But because we know that only few people are nowadays interested in "new" Linux distributions, we try our best that our work would benefit users of more common distributions, especially the users of Slackware® Linux.
[23:02:15] <orkim> whois db is showing creation date of 01-01-1985
[23:02:25] <orkim> maybe i'm pulling form a bad whois db tho
[23:02:26] <dostoyevsky2> sam_: thanks for all your work for the gentoo project!   I doubt many people would have managed to spot that attack 
[23:02:41] <Guest85> I see 2005-07-21 on whois
[23:02:52] *** Quits: Guest94 (~Guest94@143.58.136.206) (Quit: Connection closed)
[23:02:56] *** Joins: rocks22 (~rocks22@h209-169-222-202.hbbsnm.dedicated.static.tds.net)
[23:03:00] <orkim> ok.. must just be me.  jan 1 seems a bit like default time anywayys
[23:03:53] <Guest60> 1985 was when .org started, I would guess your db had it as the default start date
[23:04:00] <st3fan> orkim: 2005-07-21T18:54:03Z
[23:04:00] <orkim> yup.. i see 2005 now
[23:04:09] <orkim> weird.. but ok.. :)
[23:04:20] *** Quits: Guest1 (~Guest82@h209-169-222-202.hbbsnm.dedicated.static.tds.net) (Ping timeout: 250 seconds)
[23:04:34] *** Joins: Guest3 (~Guest69@2a09:bac2:5a81:13e1::1fb:6b)
[23:05:27] <orkim> ya.. last update was in june of 23
[23:05:35] <Rounin> You know a LInux distro is hardcore when it started 9 years before Linux
[23:05:42] <orkim> lol
[23:05:48] *** Quits: Guest3 (~Guest69@2a09:bac2:5a81:13e1::1fb:6b) (Client Quit)
[23:05:55] <sam_> ok I just remembered I forgot the ldd stuff
[23:06:00] <sam_> I will do that now and also dig up the ML post I promised you
[23:06:13] <bt__> Jia is completely silent about it, isn't he/
[23:06:52] <Rounin> It would take a pretty good story to explain this one
[23:07:13] <Rounin> "Oh, we just really like SSH and wanted to make sure our LZMA library contributes to the optimal login experience"
[23:07:36] <Rounin> "especially by making it slower to prevent brute-forcing... Yeah, that's it"
[23:07:41] <Guest93> its more so, openssh was modified to accept systemd notifications and libsystemd links to lzma
[23:07:51] <Guest93> and the ifuncs feature of glibc lets you hijack other parts of an executable
[23:08:06] *** Joins: PA17532 (~PA17532@067-011-240-216.res.spectrum.com)
[23:08:11] <rolf> or maybe "the Dear Leader said he would spare my family if I got this merged in the Linux Kernel"
[23:08:18] *** Joins: Guest52 (~Guest52@ppp141237220038.access.hol.gr)
[23:08:33] <Snetry> this is not a productive conversation
[23:08:47] <Guest93> kinda funny how glibc created ifuncs to compete with Microsoft Detours...but made it 100 times easier to obfuscate and hide. Meanwhile Microsoft Detours are obvious code.
[23:08:54] *** Quits: xzipped (~xzipped@193.69.100.76) (Quit: Client closed)
[23:08:57] <dostoyevsky2> Guest93: like interposing with LD_PRELOAD  ...
[23:09:00] *** Joins: bitripper (~bitripper@2601:646:8080:7daa:f88c:f6f8:cfea:81d4)
[23:09:03] <Lena_> Has the backdoor been deobfuscated / reverse engineered completely yet? I only see some performance measurements in oss-security.
[23:09:13] <abby> no
[23:09:15] <Guest60> I mean he is probably in panic mode and very mad with making the login slowed down resulting in people investigating what was going on
[23:09:32] *** Quits: tipsfedoraa (~tipsfedor@216.243.40.138) (Ping timeout: 250 seconds)
[23:09:37] *** Quits: Guest79 (~Guest79@2607:c000:8108:b700:3734:13b6:26cf:2cfb) (Quit: Client closed)
[23:09:52] <Guest93> never annoy nerds with performance lag
[23:10:00] <Guest93> they'll break out the perf tools
[23:10:06] <dostoyevsky2> Lena_: https://bpa.st/27AQ
[23:10:33] <dostoyevsky2> from here https://www.openwall.com/lists/oss-security/2024/03/29/4
[23:10:44] <Lena_> thanks dostoyevsky2 
[23:10:59] <st3fan> Guest93: so any application that links to lzma could potentially be modified at runtime through this backdoor? it was not ssh specific? or maybe we don't know that yet since the code hasn't been fully reversed?
[23:11:08] <bret> Tans silence is telling
[23:11:16] *** Quits: Guest30 (~Guest30@2001:b07:5d2a:626b:a935:b56a:dce2:6b71) (Ping timeout: 250 seconds)
[23:11:21] *** Quits: Guest60 (~Guest60@185.237.223.100) (Quit: Client closed)
[23:11:36] <Snetry> st3fan: potentially any program could be modified at runtime, though at this time only sshd is known to be targeted
[23:11:46] *** Joins: Guest60 (~Guest60@185.237.223.100)
[23:11:52] <Guest93> yes that
[23:11:55] <Celelibi> Silence tells nothing.
[23:11:59] <Snetry> and seemingly only on x86_64 linux glibc targets 
[23:12:04] <f_> Wait Jia's GH got suspended?
[23:12:06] <Snetry> and seemingly only in rpm or debian packages
[23:12:15] <Guest93> any program will run the exploit code, however it looks for the "RSA_public_decrypt" symbol
[23:12:18] <Celelibi> Don't try to read between the lines. There's nothing.
[23:12:27] <st3fan> i think "known to be targeted" is the wrong explanation .. "where this backdoor was discovered" is probably better 
[23:13:13] <st3fan> ah yes RSA_public_decrypt .. would that impact browsers too or do Firefox and Chrome not link to this library?
[23:13:37] <st3fan> i guess they both have their own crypto libs so maybe maybe 
[23:13:52] <Snetry> haven't checked the code myself because I am lazy, but it is said that it checks if the running program has an argv[0] of /usr/sbin/sshd
[23:13:53] <Guest93> anything using openssl really
[23:13:56] <orkim> f_: both accounts got suspended
[23:14:06] <dostoyevsky2> q3k: it seems like the indirection in the code stems from it replacing the dlopen() et al functions... so it's a symbol loader and when it detects RSA_public_decrypt it returns one of its own functions that just return success
[23:14:16] <Guest93> i guess the real implication is, openssh was the affected target, however, anything using openssl would be the primary target
[23:14:29] <f_> orkim: ah so Larhzu's GH also got suspended..
[23:14:35] <orkim> yes
[23:14:43] <sam_> ok i can't find the ML post I was thinking of, although I'm pretty sure it exists
[23:14:43] *** Joins: Guest39 (~Guest98@142.147.89.219)
[23:14:48] <sam_> anyway I'll just add the note about being careful w/ ldd
[23:14:50] <st3fan> that may mean that authorities are involved now 
[23:15:25] *** woo2 is now known as woo2_
[23:15:47] *** Joins: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491)
[23:15:50] *** Joins: dumbgardener1983 (~dumbgarde@c-73-223-63-64.hsd1.ca.comcast.net)
[23:15:59] <Guest60> debian sure is a little bit more weird to be targeted but the x86_64 is a valid option, you single out all the ARM machines, either you don't care about raspberries or you don't want to target big corporations that they run their own CPU arch, like amazon and such, that's what I get from his target pool
[23:16:00] *** woo2_ is now known as woo2
[23:16:12] *** woo2 is now known as woo2_
[23:16:47] <Snetry> it checks for the architecture because it links against an object file that was hidden in test data
[23:16:59] *** Parts: Guest52 (~Guest52@ppp141237220038.access.hol.gr) ()
[23:17:08] <Guest93> funny enough, he may have wanted to target arm64
[23:17:15] <orkim> sam_:  "The payload only activates if the running program has the process name /usr/sbin/sshd. This means that systems that put sshd in /usr/sbin or another folder..."   Was that second path meant to read /usr/bin/ (seems to contradict itself there)
[23:17:18] <Guest93> if you look at jia's commits in xz, he was experimenting with ifuncs on arm64
[23:17:23] <Guest93> but must have been struggling for some reason
[23:17:38] <st3fan> orkim: ah! missed that part. sounds like a clear target :)
[23:18:01] <Snetry> Guest93: the core xz code started using ifuncs, he may have struggled with them not working as intended on arm64 thus breaking the library
[23:18:04] <jess> i've done my meme duty https://chaos.social/@jesopo/112181577693744198
[23:18:13] <Snetry> its unclear what exactly happened, lets not ryhme something into this
[23:18:37] <orkim> standing on the shoulders of giants.. ;)
[23:18:38] <ids1024> I'm guessing it's intentional that the release was made with just enough time to make it into Ubuntu LTS. (Though that was not successful.)
[23:18:59] <st3fan> jess: no i think it is spot on .. this is the world we live in now
[23:19:09] <Guest93> ids1024 he seemed to be trying to push into my releases
[23:19:13] <Guest93> into many releases*
[23:19:20] <Guest93> he even snuck into debian testing
[23:19:30] <Guest93> so i dont think it was any particular distro targetted
[23:19:34] <Guest93> he went for broke
[23:19:34] *** Joins: mirppc (~mirppc@openSUSE/member/mir-ppc)
[23:19:57] <ids1024> Getting it merged into Debian was a prerequisite for having Ubuntu pull the package update from Sid.
[23:20:18] <st3fan> How did it end up in Fedora 41?
[23:20:26] <Celelibi> I didn't know about ifunc. They look pretty fun.
[23:20:43] <Guest60> wasn't debian mentioned in the first stage of the payload?
[23:20:47] <Snetry> While no particular distro may have been targeted, it was limited to x86_64 glibc and the build time configuration checked if a deb or rpm package setup was found
[23:20:49] <Guest60> or am I mistaken ?
[23:20:51] *** Joins: Guest17 (~Guest17@2804:14d:8084:8bad::bfd5)
[23:21:07] *** Parts: Guest17 (~Guest17@2804:14d:8084:8bad::bfd5) ()
[23:21:10] <Celelibi> They're like a callback to delegate the automatic dlsym that happen to populate the GOT.
[23:21:11] <ids1024> If you want to attack servers, I assume you want to get the malicious code into Ubuntu LTS and RHEL. Not sure what the release cycle for RHEL is like.
[23:21:38] <Guest93> st3fan https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YTOGJVBNOSW7FSEE7B35GETS25KFPKBO/
[23:21:39] <Yogurt> RHEL 10 forked off fedora 40
[23:21:41] <Guest93> the fedora history
[23:21:44] <Guest93> of what happened
[23:21:50] <Guest93> it actually ended up in Fedora 40
[23:22:07] <Guest93> but because of the valgrind bug, the exploit got disabled silently by fedora maintainers who were oblivious
[23:22:12] *** Quits: Guest98 (~Guest20@91-156-196-82.elisa-laajakaista.fi) (Quit: Client closed)
[23:22:13] <dostoyevsky2> Celelibi: so ifuncs are a bit different to a LD_PRELOAD?
[23:22:28] <Snetry> yes
[23:22:41] <Snetry> ifuncs and preloading are two completely different things
[23:22:56] <sam_> orkim: looking
[23:23:18] <Snetry> also, ifuncs are not necessary, just simplify things a lot
[23:23:23] <sam_> orkim: absolutely yes, sorry, I overcorrected in a hurry. my bad
[23:23:35] <orkim> np.. just trying to help with accuracy.. :)
[23:23:36] <sam_> ifunc just makes this super convenient, yeah
[23:24:17] <Guest60> it would be interested to see what public key was allowed access through the backdoor, was it a specific one, a sequence that would allow multiple keys to be authenticated? this weekend is gonna be interesting
[23:24:29] <A_Dragon> sam_: they a function pointer wrapper type thing?
[23:24:31] *** Joins: Guest50 (~Guest50@164.250.218.133.dy.bbexcite.jp)
[23:24:34] <dostoyevsky2> Snetry: Well, it seems similar in that if you can do LD_PRELOAD=/my-crypto.so sshd you can let people login without any passwords checks... and xz being linked into systemd with ifuncs seems to work the same way
[23:24:37] <dumbgardener1983> From https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27: "This is not a fault of sshd, systemd, or glibc, that is just how it was made exploitable." Didn't systemd's patching of sshd make this even possible?
[23:24:45] *** Joins: panorain (~panorain@user/panorain)
[23:24:54] <sam_> A_Dragon: pretty much -- they're run *super* early in process startup
[23:24:55] <Guest93> systemd didnt patch sshd per-say
[23:25:04] <A_Dragon> s/ay/se
[23:25:07] <Guest93> distros that wanted to integrate systemd with openssh did
[23:25:10] <A_Dragon> sorry, say/se
[23:25:12] <Celelibi> dostoyevsky2, a bit. ifuncs happen later and the order of loading isn't changed compared to LD_PRELOAD.
[23:25:20] <sam_> it's close enough in terms of helping people understand the idea of it
[23:25:36] *** Joins: acidsys (~crameleon@openSUSE/member/crameleon)
[23:25:38] *** Joins: lukas (~lukas@ip-193-53-104-44.changeis.iunxi.net)
[23:25:43] <sam_> dumbgardener1983: something to keep in mind is that if a distribution has some path for sshd to include liblzma, they will be in trouble too.
[23:25:49] <dumbgardener1983> Sure, that's a more accurate description
[23:25:50] *** Quits: Lena_ (~Lena@2001-4dd6-c873-1-6cd4-b2c3-95f9-377e.ipv6dyn.netcologne.de) (Ping timeout: 256 seconds)
[23:25:54] <sam_> dumbgardener1983: lennart on HN mentioned libselinux but i do not see how it can happen right now
[23:26:05] <sam_> (I quickly grepped lzma in libselinux + we do not depend on xz-utils in our libselinux ebuild, not looked harder)
[23:26:08] <Snetry> dostoyevsky2: yes, however there are a ton of semantic differences
[23:26:08] <sam_> but you get the idea
[23:26:19] <dumbgardener1983> (y)
[23:26:50] <cjwatson> openssh upstream is currently (very surprisingly to me!) working on inline systemd notification without libsystemd, so we'll be able to drop that patch from Debian
[23:26:55] <cjwatson> and I'd guess also Fedora
[23:27:05] <Snetry> preloading a library is intended to get it in ahead of the chain and have it serve any symbols your program needs. There are limitations to what is loaded where and when
[23:27:11] *** Quits: waleee (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.2)
[23:27:16] *** Quits: Guest60 (~Guest60@185.237.223.100) (Quit: Client closed)
[23:27:24] <Snetry> ifuncs (or to call them by their full name indirect functions) allow you to switch function implementation at runtime using a resolver
[23:27:29] <sam_> cjwatson: oh they are? fantastic
[23:27:37] <sam_> cjwatson: (I assume you saw the PR got closed for libsystemd integration)
[23:27:38] <cjwatson> sam_: https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c13
[23:28:01] <Celelibi> Snetry, you can choose at runtime. But only once.
[23:28:05] <sam_> tbh I think a good project would be to go around seeing if we could cull libsystemd use if it's purely for notify, just to reduce proc space size
[23:28:08] <sam_> cjwatson: fab, thank you
[23:28:27] <cjwatson> Debian will need to do a bit of extra work because we also call sd_listen_fds, but that's easier
[23:29:23] <dumbgardener1983> Anyways this makes one wonder what the real attack surface of everything becomes post systemd integration
[23:29:47] *** Joins: waleee (~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
[23:30:10] *** Quits: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491) (Quit: grmll)
[23:30:11] <cjwatson> I mostly don't see this as a big hardening thing since if you can attack systemd it's game over anyway.  But definitely nice to reduce our patch load
[23:30:21] <sam_> oh yeah for sure
[23:30:40] <sam_> it's more like if someone had a lot of free time i'd say maybe go do it
[23:30:57] <cjwatson> that mythical object
[23:31:03] <sam_> :D
[23:31:23] *** Quits: Guest93 (~Guest93@2600:4041:539c:f700:9c69:f85b:71c3:dc06) (Quit: Client closed)
[23:31:55] <dostoyevsky2> Snetry: And it seems like they made this whole PR and the Q&A between Hans and Jia in order to justify the usage of ifuncs (look how much faster it is if we could dynamically switch implementations) https://github.com/tukaani-project/xz/pull/64
[23:31:55] *** Joins: yasin (~yasin@130.204.92.64)
[23:32:09] <sam_> the sad thing is
[23:32:15] <sam_> lasse was really really sceptical about ifunc
[23:32:28] <sam_> and he wanted to turn it off after the valgrind+pgo nonsense
[23:32:29] <sam_> :(
[23:32:42] <Snetry> I mean
[23:33:00] <Celelibi> I wonder if the ifunc resolver gets called several times if we define LD_BIND_NOT.
[23:33:14] <Snetry> ifuncs would be a good choice when choosing between a SIMD and a generic implementation
[23:33:30] *** Joins: FireFly (~firefly@glowbum/gluehwuermchen/firefly)
[23:34:00] <Guest50> It's not me it's just my "Hans"
[23:34:19] <Celelibi> That's what I say to girls.
[23:34:24] <f_> Short jokes are usually the funniest ones.
[23:34:49] <f_> (repeating the same joke over and over tends to make it not really funny anymore)
[23:34:57] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Quit: peace)
[23:35:10] <Guest46> alright fellas im gonna take a nap, someone wake me up if this backdoor causes planes to fall out of the sky
[23:35:24] <dumbgardener1983> We don't need backdoors for that
[23:35:42] <dumbgardener1983> Just negligence will do nicely
[23:36:06] <dostoyevsky2> sam_: sometimes you are just happy that others keep on working on that project you created and worked on so many years, and you can enjoy your free time again a bit more
[23:36:17] <sam_> yes
[23:36:25] <sam_> you don't have to tell me :)
[23:38:10] *** Joins: dnsmcbr (sid136206@id-136206.uxbridge.irccloud.com)
[23:38:42] *** Joins: bhaible (~bruno@2a02:908:193:6800:3128:ab45:6103:663a)
[23:39:26] *** Joins: man84 (~weechat@2001:19f0:5c01:cbf:5400:4ff:feab:2a4f)
[23:40:42] *** Quits: Guest85 (~Guest85@modemcable154.4-162-184.mc.videotron.ca) (Quit: Client closed)
[23:43:21] *** Quits: Guest96 (~Guest80@mobile-user-c1d2e7-200.dhcp.inet.fi) (Quit: Client closed)
[23:43:54] *** Quits: dumbgardener1983 (~dumbgarde@c-73-223-63-64.hsd1.ca.comcast.net) (Quit: Client closed)
[23:44:10] *** Quits: waleee (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds)
[23:44:41] *** lukas is now known as luccc
[23:46:18] <rolf> Unless I am mistaken, it's only been introduced in a few bleeding edge / rolling releases, like Fedora Rawhide to which I switched from fc39 just 2 weeks ago ... ( go figure ) , -AND- it affects SSH Server, which you must be running, and have open to public access (won't work behind NAT if you didn't portforward SSH) - AND from what I read you must be targeted, there is no phone-home or anything
[23:46:20] <rolf> which has been found.
[23:46:30] *** Quits: Guest46 (~Guest13@c-67-187-148-183.hsd1.ca.comcast.net) (Quit: Client closed)
[23:48:22] <Celelibi> Reachable sshds are pretty common.
[23:48:27] <dostoyevsky2> sam_: gentoo used to always compile code for the given architecture... which wouldn't make ifuncs necessary to switch between implementations, but I guess they changed that
[23:48:31] <rolf> So very bad stuff could have happened if uncaught, hence why the malicious actor tried to push it to mainstream. If only he wasn't caugt because his code caused a few milliseconds extra latency on SSH. So it doesn't look like much harm could have been done, although this was a very ingenious elaborate attempt 
[23:48:36] *** Joins: gkpm (~gkpm@2a01:11:8c20:5fb0:f4cf:da15:dfc0:2dbc)
[23:48:44] <Celelibi> Bleeding edge versions on servers, less so.
[23:49:01] <sam_> dostoyevsky2: no, we just didn't turn the option off either (perhaps we should have in hindsight, but then we'r also using a less-tested codepath..)
[23:49:57] <rolf> @Celelibi , yes reachable sshds are common but not so much bleeding edge. I doubt there's many open sshd's running Arch, Fedora Rawhide or Tumbleweed. Except for the odd hobbyist who runs a $5 VPS
[23:50:21] *** Joins: arawat (~arawat@host-243-228.ilcmijsm.champaign.il.us.clients.pavlovmedia.net)
[23:50:24] <Yogurt> rhel 10 and ubuntu lts 24 were both targeted with patches
[23:50:51] <rolf> Tried buy failed, by happy coincidence thank god
[23:50:55] <Celelibi> Dynamic choice of implementation can be used for more than just best-for-cpu.
[23:50:55] <rolf> *but
[23:51:40] <Celelibi> AFAIK, OpenBLAS has its ocn mechabism for that.
[23:51:48] <Celelibi> -b+n
[23:52:05] *** Quits: bitripper (~bitripper@2601:646:8080:7daa:f88c:f6f8:cfea:81d4) (Quit: Client closed)
[23:52:09] <Celelibi> own* (can't spell on smartphone)
[23:54:13] <Celelibi> rolf, once you have access to a machine on a LAN, whichever machine in the same LAN has an sshd is reachable as well. All it takes is one compromised machine.
[23:54:53] *** Quits: blingbling (~bling@89.125.87.194) (Quit: Client closed)
[23:55:03] <Celelibi> Most organisations won't disallow internal ssh connections. That would be very annoying.
[23:55:15] <cjwatson> it's harder work and you might have some.hope of detecting it in that case
[23:55:35] *** Quits: gkpm (~gkpm@2a01:11:8c20:5fb0:f4cf:da15:dfc0:2dbc) (Remote host closed the connection)
[23:56:06] *** Joins: gkpm (~gkpm@2a01:11:8c20:5fb0:f4cf:da15:dfc0:2dbc)
[23:56:09] *** Quits: gkpm (~gkpm@2a01:11:8c20:5fb0:f4cf:da15:dfc0:2dbc) (Remote host closed the connection)
[23:56:28] *** Quits: Guest39 (~Guest98@142.147.89.219) (Quit: Client closed)
[23:57:16] <Celelibi> Like right now, I'm on the toilet from my smartphone. Using ssh + vnc to my computer. How would I do that otherwise? xD
[23:57:29] *** Quits: PA17532 (~PA17532@067-011-240-216.res.spectrum.com) (Quit: Client closed)
[23:58:15] <Yogurt> rolf: Yup. Dodged one hell of a bullet
[23:58:52] *** Quits: Guest45 (~Guest45@75.164.92.136) (Quit: Client closed)
[23:58:53] *** Joins: junon (~junon@user/junon)
[23:58:56] *** Joins: Guest80 (~Guest13@2a01:4f8:1c1e:a0e0::1)
[23:59:21] *** Joins: chopstick (~chopstick@104.28.222.157)
[23:59:48] <Celelibi> Let's not forget the netlink double free issue in Linux this week.
[00:00:03] <Celelibi> With a full working exploit.
[00:01:26] *** Joins: Guest62 (~Guest62@72.22.161.10)
[00:01:53] <rolf> true true, this xz exploit is a scary scenario , but all in all probably didn't do any harm (yet)
[00:02:36] *** Joins: Guest81 (~Guest81@71.19.251.144)
[00:02:47] *** Quits: Guest62 (~Guest62@72.22.161.10) (Client Quit)
[00:02:51] <junon> We got lucky though.
[00:03:23] *** Joins: Guest24 (~Guest24@2001-1ae9-158-5400-4008-30be-db44-7d4d.ip6.tmcz.cz)
[00:03:23] <Guest24> someone here?
[00:03:23] <junon> Hugops to Lasse :\
[00:03:42] *** Quits: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
[00:03:42] <Guest24> oh, i see
[00:04:27] <Yogurt> Celelibi: don't think I saw that one
[00:05:05] *** Quits: Guest24 (~Guest24@2001-1ae9-158-5400-4008-30be-db44-7d4d.ip6.tmcz.cz) (Client Quit)
[00:05:20] *** Joins: Speedy11CZ (~Speedy11C@2001-1ae9-158-5400-4008-30be-db44-7d4d.ip6.tmcz.cz)
[00:05:42] *** Joins: bdrewery (~bryan@user/bdrewery)
[00:05:44] *** Quits: pera (~pera@user/pera) (Quit: leaving)
[00:05:53] <chopstick> hello everyone, i wanna know bout how to check was i exploited on macOS, how to detect it? cuz i saw there's no liblzma in `otool -L $(which sshd) /usr/sbin/sshd`
[00:06:21] <man84> Holy crap a new backdoor in gzip just flew over my house!
[00:06:44] <sam_> haha
[00:07:05] <rolf> Does anyone have links to where the malicous tarballs would have been hosted, outside of github?
[00:07:17] <rolf> I read they may have been hosted on the website tukaani.org
[00:07:41] <Celelibi> Yogurt, it's netfilter, not netlink: https://www.youtube.com/watch?v=ixn5OygxBY4
[00:08:08] <junon> chopstick: for sshd specifically, you're probably not affected on macos. It appears to be linked to systemd. It is not present on anything other than x86_64.
[00:08:19] *** Joins: Guest32 (~Guest32@74.14.152.40)
[00:08:19] <Celelibi> Skip half the video if you're familiar with the kernel and vulnerability exploitation.
[00:08:21] <dostoyevsky2> chopstick: shouldn't be a problem, but if you want to be 100% sure, do a reinstall of your os from an installer disk... that should reset everything to how it has been
[00:08:22] <junon> rolf: the tarballs were part of the tests, committed as binaries.
[00:08:45] <dostoyevsky2> (and usually you still keep your data, just the os part is reset)
[00:08:49] <Speedy11CZ> rolf https://xz.tukaani.org/xz-utils/#releases
[00:09:14] <Speedy11CZ> you mean this?
[00:09:41] <junon> Oh sorry, I misunderstood your question rolf. ^ that's the answer. They might have also been infected in the .xz versions of the tarballs added manually to the releases. I still haven't gotten a clear answer on that.
[00:09:42] <rolf> This is a bit above my paygrade junon :) Where would they come from before ending up in the tests?
[00:09:54] <rolf> Yes I think so Speedy11CZ, thank you!!
[00:10:09] <Speedy11CZ> no problem
[00:10:16] <dostoyevsky2> chopstick: https://support.apple.com/en-us/102655
[00:10:43] <rolf> specifically, these ones are the naughty code: 
[00:10:45] <rolf> https://git.tukaani.org/?p=xz.git;a=commit;h=6e636819e8f070330d835fce46289a3ff72a7b89
[00:10:52] <rolf> thanks junon and Speedy11CZ
[00:11:13] <Speedy11CZ> chopstick maybe try `xz --version`
[00:11:23] <Guest32> D:
[00:12:06] *** Joins: Garen (~Garen@50.52.127.145)
[00:12:31] <chopstick> i mean my version is vulnerable but there seems no liblzma showed in sshd's library list
[00:12:38] *** Joins: kroot (~locutus@of.the-b.org)
[00:13:14] <sam_> chopstick: what distribution are you on?
[00:13:39] <Speedy11CZ> chopstick is possible that your sshd is not vulnerable, but I would still recommend a downgrade
[00:13:40] <chopstick> macOS haha
[00:13:49] <sam_> you are probably fine, afaik nothing gets injected there
[00:13:51] <sam_> i mean it's not a promise
[00:13:58] <sam_> but the build process doesn't seem to inject the payload on macOS either
[00:13:58] <chopstick> okay
[00:14:03] <sam_> i would still downgrade to be safe but i would not panic, personally
[00:14:08] <Speedy11CZ> chopstick you installed it with brew, did you?
[00:14:18] <Yogurt> Celelibi: thanks
[00:14:21] <chopstick> yep
[00:14:26] <Celelibi> I wouldn't recommend to anyone to panic. xD
[00:14:36] <Celelibi> Just haste yourself to downgrade.
[00:14:45] <Speedy11CZ> brew update should currently downgrade xz version
[00:15:09] <rolf> TEchnically, downgrade gets rid of the exploit but you don't know if it wasn't abused already
[00:15:16] <rolf> though... thats a very very far stretch
[00:15:34] <dostoyevsky2> chopstick: on linux sshd doesn't use liblzma either, it's injected via systemd which uses liblzma and then starts sshd
[00:15:43] <dnsmcbr> Do macs even expose ssh in normal use?
[00:15:57] <Yogurt> off by default iirc
[00:16:04] <dostoyevsky2> dnsmcbr: Nope, needs to be activated in System Settings
[00:16:23] <junon> Most distros have pushed security updates already, btw.
[00:16:24] <Speedy11CZ> it is quite unlikely that macOS would suffer from this backdoor, but I would definitely do the downgrade
[00:16:40] <Celelibi> As of right now, we have no word of an automated large scale attack. If there were any, they were targeted. So unless you have some high profile domain name, it's unlikely you've been compromised.
[00:16:40] *** Quits: Guest32 (~Guest32@74.14.152.40) (Quit: Client closed)
[00:16:46] <dnsmcbr> You'd have to a) expose it, b) do some funky stuff to get it to depend on liblzma and c) have a computer connected directly to the net, or otherwise allowing access to the ssh port
[00:16:48] <rolf> Fedora Rawhide doesn't have an update yet junon ;)
[00:16:53] *** Joins: Guest67 (~Guest67@pool-72-79-122-157.nwrknj.east.verizon.net)
[00:16:54] <junon> Though some still list Jia's public key.
[00:16:55] <sam_> it does
[00:17:01] <rolf> Tumbleweed has indeed receive an update, to downgrade, as did Arch 
[00:17:03] <sam_> it was fixed already in rawhide 
[00:17:08] <sam_> https://src.fedoraproject.org/rpms/xz/commits/rawhide
[00:17:23] <rolf> oh good, i'll run dnf again then :)
[00:17:23] <rocks22> if i downgrade to 5.4.2 should i be good? afaik from reading, the only supposed affected versions are 5.6.0 and 5.6.1 no?
[00:17:36] *** Joins: Guest32 (~Guest32@bras-base-toroon2733w-grc-40-74-14-152-40.dsl.bell.ca)
[00:17:36] <rocks22> well "good"
[00:17:36] <Celelibi> rocks22, indeed.
[00:17:41] <rocks22> okay bet
[00:17:57] <sam_> there can be no promises but issues have only been found in 5.6.0 and 5.6.1. some older versions were signed by the person who signed the newer bad ones though.
[00:18:04] <dnsmcbr> poor british security teams
[00:18:10] <dnsmcbr> bank holiday = ruined
[00:18:21] <Mopman_> :[
[00:18:22] <rocks22> fair but better than being on the most recent versions
[00:18:48] <Celelibi> Why do these these security issues get released on week-ends ?
[00:18:48] <chopstick> thanks guys, i have downgraded it already
[00:19:01] <dnsmcbr> A_Dragon: 👀
[00:19:02] <Speedy11CZ> version 5.4.2 is definitely better than 5.6.0 and 5.6.1, but in the current situation it is not possible to say for sure whether older versions also have some kind of backdoor
[00:19:06] *** Quits: Guest4 (~Guest4@2a01:e34:ec58:3c10:d627:402a:b0a8:1bd) (Quit: Client closed)
[00:19:32] <rolf> not in repo yet for rawhide if I dnf upgrade --refresh ... but looks like it was on 5.6.1 for 20 days so I guess a few more can't hurt ^^ 
[00:20:44] <rolf> Indeed Speedy11CZ, I'd think anythin that has been touched by Jia should be under scrutiny
[00:21:42] *** Quits: Guest32 (~Guest32@bras-base-toroon2733w-grc-40-74-14-152-40.dsl.bell.ca) (Client Quit)
[00:21:48] *** Quits: arawat (~arawat@host-243-228.ilcmijsm.champaign.il.us.clients.pavlovmedia.net) (Quit: Konversation terminated!)
[00:21:51] <Speedy11CZ> there were also some suspicions about Larzhu
[00:22:08] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[00:22:08] *** Joins: Guest44 (~Guest44@c-71-202-28-71.hsd1.ca.comcast.net)
[00:22:46] <aaabbb> Speedy11CZ: what suspicions?
[00:22:47] <rolf> Just because he was to original maintainer , or other reasons as well ? 
[00:23:03] *** Quits: ba (~ba@2a02:8012:ee0:0:b826:e020:d455:3449) (Ping timeout: 240 seconds)
[00:23:39] *** Quits: Guest81 (~Guest81@71.19.251.144) (Quit: Client closed)
[00:23:50] <rolf> Bc from what I read, he was involved for a long time and stepped back a bit recently  , Jia got him to trust him and gained access to xz that way
[00:24:00] <junon> Either way his account's been suspended, which is pretty SOP for github when it comes to some of these things.
[00:24:22] *** Quits: chopstick (~chopstick@104.28.222.157) (Remote host closed the connection)
[00:24:23] *** Joins: ba (~ba@2a02:8012:ee0:0:e48a:f514:61e:3284)
[00:24:31] <junon> Also, there's a lot of messages showing that a lot of Jias actions were pushed pretty hard by accounts that look like sockpuppets. Let's not speculate, this can't be a fun time for him.
[00:24:33] <Speedy11CZ> I read somewhere that there were some suspicions in his behaviour, e.g. he started to put himself in cc in emails, but it could be just a coincidence, I don't want to spread misinformation
[00:25:10] <rolf> That seems precautionary , especially if you don't know who had access , Github also want's to / has to act fast so they could very well have suspended " just in case "
[00:25:26] *** Quits: ba (~ba@2a02:8012:ee0:0:e48a:f514:61e:3284) (Killed (NickServ (GHOST command used by ba_!~ba@2a02:8012:ee0:0:ac08:6635:25a5:76c1)))
[00:25:39] *** Joins: ba (~ba@2a02:8012:ee0:0:ac08:6635:25a5:76c1)
[00:26:07] <Guest67> Does any real person exist by the name "Jia Cheong Tan"?
[00:26:17] <junon> Where did you get Cheong from?
[00:26:37] <Guest67> Leaked data associated with the email
[00:26:54] *** Joins: jghali (~jghali@185.208.60.131)
[00:26:56] <Guest67> When i google search that name with quotes there is some aws hit too
[00:27:05] *** Joins: Guest12 (~Guest43@port-83-236-48-237.dynamic.as20676.net)
[00:27:08] *** Joins: Manis (01a66df340@77-56-188-94.dclient.hispeed.ch)
[00:27:20] <aaabbb> if it's a purpose made account (which it probably is), then you won't find any relevant hits. any you do would be red herrings
[00:28:03] <Guest67> https://amazon-source-code-downloads.s3.amazonaws.com/eero/eero-embedded/eero-oss-attribution-latest.txt
[00:28:04] <rolf> I'm pretty knew to FOSS and Linux , but from I've read tonight Larzhu has maintained xc for a long time, and to then see someone betray you and besmudge your 'child' project - that must really suck. I think that by itself warrant some objectivism
[00:28:27] <Rounin> Kind of a strange name... "Jia Tan" is a very Mandarin name, whereas "Cheong" is Cantonese or Korean
[00:28:38] <Rounin> But perhaps they all coexist in the Shanghai dialect or something
[00:28:42] *** Joins: Guest59 (~Guest59@bras-base-otwaon0906w-grc-15-142-126-188-20.dsl.bell.ca)
[00:28:58] <Rounin> Or perhaps whoever thought "Fa Mulan" was a good idea invented Jia Cheong Tan as well
[00:29:00] <Guest67> So i dunno what an "eero" is but jia's name is in the source code credits list for that
[00:29:01] <aaabbb> rolf: he's probably going to have a very stressful next few weeks
[00:29:41] *** Joins: Guest81 (~Guest81@71.19.251.144)
[00:29:42] <Guest67> Overall there isnt much of any footprint associated with this person
[00:29:52] <rolf> man this is genious "backdoor" ... finding a project you can wedge yourself into, being "good enough" to gain trust and change code, and then the code itself and the way it's hidden in open source .... I know this is very much speculative but doesn't this smell like some nation (*ugh* nk *ugh*) might have tried to do something?
[00:29:56] <Guest67> At least associated to that email address
[00:30:08] *** Joins: chopstick (~chopstick@104.28.222.157)
[00:30:14] <aaabbb> rolf: no way to determine what nation it is at this point
[00:30:40] <dnsmcbr> I'd caution everyone to *not* witchhunt it to death. Don't want to be like reddit during the whole boston thing.
[00:30:58] <Guest81> Hello, I am having an issue with XZ lib. I usually contact jiatan about this, but he does not seem to be in the channel anymore. What happened?
[00:30:59] <rolf> Indeed aaabbb , I sympathize with him. 
[00:31:11] <rolf> lol Guest81
[00:31:14] <aaabbb> Guest81: nice try lmao
[00:31:28] *** Joins: Guest14 (~Guest14@2601:601:d00:54:bd91:5f4:58ca:be1e)
[00:31:36] <Guest67> This is probably the only way to get paid for maintaining open source projects. Go work for some nation state and subtly introduce backdoors while pretending to fix bugs. Bet "Jia" got paid way more than the original maintainers ever made.
[00:32:01] <rolf> Depends on which nation (if any) 
[00:32:18] <Rounin> Hmm... Perhaps that's how we get the funding... As long as the backdoors are bad enough or cancel each other out, we should be good
[00:32:24] <Guest67> You could probably sell it on open 0day markets if you wanted to freelance it
[00:32:40] <dnsmcbr> Guest67: now that's illegal!
[00:33:00] *** Joins: LegacyAbb (~LegacyAbb@188.95.54.46)
[00:33:01] *** Quits: ba (~ba@2a02:8012:ee0:0:ac08:6635:25a5:76c1) (Ping timeout: 268 seconds)
[00:33:08] <Guest67> People dont get arrested for ransomware... there are no consequences for anything nowadays
[00:33:22] <aaabbb> yeah they do
[00:33:30] <aaabbb> international manhunts happen for ransomware
[00:33:40] <Guest67> Not if they live in china or russia lol
[00:33:47] <aaabbb> even if they live in china or russia
[00:33:49] *** Quits: Yogurt (~Yogurt@158.51.82.203) (Quit: My MacBook has gone to sleep. ZZZzzz…)
[00:34:01] <Guest67> Only a tiny percentage ever get arrested
[00:34:02] <aaabbb> well idk about china but russia takes that kind of crime very seriously especially if international scope
[00:34:11] <Guest67> Ur kidding
[00:34:19] <ponky> Guest67: eero is a company which makes consumer wifi mesh systems, they were acquired by amazon
[00:34:43] <Guest67> Ah ponky i guess they need to update their firmware distro...
[00:34:56] *** Quits: LegacyAbb (~LegacyAbb@188.95.54.46) (Client Quit)
[00:35:50] *** Joins: ba (~ba@51.155.219.169)
[00:36:31] <Noisytoot> Guest81: if you actually have an issue, say it
[00:36:36] *** Joins: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net)
[00:37:07] <boud> Guest81: Please read through https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 .
[00:37:08] *** Joins: Guest30 (~Guest30@070-126-159-142.res.spectrum.com)
[00:38:00] <junon> Did anyone manage to get a /whowas of jiatan?
[00:38:00] *** Quits: Guest81 (~Guest81@71.19.251.144) (Quit: Client closed)
[00:38:14] <sam_> yes, I did
[00:38:24] <Guest67> Pls share
[00:38:30] <junon> would you be willing to /query me with it?
[00:38:32] <Snetry> why??
[00:38:39] <Noisytoot> I did too
[00:38:53] <junon> same request noisytoot
[00:38:56] <junon> :)
[00:39:09] <sam_> i don't think i should apart from with e.g. network staff or similar
[00:39:31] <sam_> it is not allowed to dox people on libera
[00:39:36] <aaabbb> it's not doxing
[00:39:43] <aaabbb> it's information that was public 
[00:39:53] <sam_> i don't know and i don't really care at the moment
[00:39:53] <boud> sort of semi-public
[00:39:57] <aaabbb> was the ip a proxy/vpn?
[00:40:00] <sam_> i can check in a bit
[00:40:04] <sam_> just got a bunch more to do
[00:40:12] <jess> make sure you get some sort of sleep in at some point
[00:40:12] <sam_> i shouldn't have answered :p
[00:40:13] <boud> Safer to avoid the risk of doxing.
[00:40:23] <sam_> thanks jess, i will 
[00:40:27] <Snetry> no one should disclose this information
[00:40:32] <rolf> thank you for sharing that link boud!
[00:40:38] <Snetry> I can't see how it would benefit anyone 
[00:40:42] <junon> I'm looking into it on behalf of an osint investigation is why I ask, but that's understandable.
[00:40:50] <aaabbb> boud: it's most certainly not doxing because it is information provided by libera in public. however it's also sam_'s right to respect jintan's privacy if he wishes
[00:41:29] *** Quits: Guest14 (~Guest14@2601:601:d00:54:bd91:5f4:58ca:be1e) (Quit: Client closed)
[00:41:59] <Guest67> Yeah im also here for work purposes. And on the side of not respecting the privacy of malware uploaders
[00:42:41] <Snetry> ok
[00:42:52] <aaabbb> Guest67: i'm sure it will be public eventually
[00:43:10] <rolf> for what's it worth ... /whois and /whowas info is indeed public , anyone can do /whois <nick> and get that info 
[00:43:17] <boud> rolf: aaabbb: making jokes among people who are already up-to-date with a discussion seems within the norms of Libera Chat, but mocking someone - Guest81 - for not being already aware and not immediately thinking of reading the /topic doesn't seem to me to be reasonable.
[00:43:34] <aaabbb> boud: he was clearly joking
[00:44:13] <boud> hmmmm ....
[00:44:44] <rolf> I don't even understand what boud is refering, I only know that I thanked boud for sharing a link with good info
[00:45:09] <jess> Guest67: you need to understand that we can't be judge, jury, and executioners
[00:45:39] <aaabbb> rolf: was this -> "Hello, I am having an issue with XZ lib. I usually contact jiatan about this, but he does not seem to be in the channel anymore. What happened?"
[00:45:52] <Guest67> Jess no one is executing anyone
[00:46:08] <jess> you do not have all the facts. you don't know everything that happened. you can't decide someone isn't deserving of privacy because you have decided the body of evidence is sufficient
[00:46:22] * aaabbb quietly puts down executioner's axe and hopes no one notices
[00:46:35] <Guest67> aaabbb yeah there are so many eyes on this that eventually someone will write a blog post about whoever "jia" is that might even be slightly accurate
[00:46:49] <syu> The IP was from a VPS in the past 2 years, so it doesn't tell you anything, it might just be used to run an IRC client like many of IRC users
[00:46:55] *** Joins: tipsfedoraa (~tipsfedor@216.243.40.138)
[00:47:15] <aaabbb> syu: exactly how nation states operate
[00:47:21] <rolf> oooooh, I presumed Guest81 was joking , which is why I said 'lol' 
[00:47:36] <tipsfedoraa> all the tukaani-project repos just got bonked
[00:47:37] <tipsfedoraa> "This repository has been disabled.
[00:47:37] <tipsfedoraa> Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service. If you are the owner of the repository, you may reach out to GitHub Support for more information. "
[00:47:52] <Speedy11CZ> yep
[00:47:52] *** Quits: ba (~ba@51.155.219.169) (Read error: Connection reset by peer)
[00:47:56] <mirppc> whhoa
[00:47:59] <aaabbb> tipsfedoraa: i assume 1000x people have already git clone
[00:48:11] <mirppc> that happened
[00:48:12] <tipsfedoraa> oh for sure
[00:48:14] *** Quits: Guest44 (~Guest44@c-71-202-28-71.hsd1.ca.comcast.net) (Quit: Client closed)
[00:48:34] <jess> also makes sense given the issues were unmoderated and going off the rails
[00:48:40] <mirppc> i was expecting something to pop up in security both on the site and github about the CVE
[00:48:51] <Guest67> Syu can you say which VPS provider and if the ips were consistent, or hopped around like a VPN provider?
[00:48:59] *** Joins: Guest33 (~Guest33@074-071-073-113.res.spectrum.com)
[00:49:02] *** Quits: boud (~boud@user/boud) (Ping timeout: 260 seconds)
[00:49:20] <Noisytoot> it's still on https://git.tukaani.org/?p=xz.git;a=summary
[00:49:20] <Guest33> yo
[00:49:35] <aaabbb> Guest67: APTs have this down to a framework. with click of a button, they can purchase and spin up a small number of vpses, proxy through them, then shut them down
[00:49:37] <i860> aaabbb: yep, i cloned every single one of the jia repos some hours ago, even random forks (didn't bother checking for diffs)
[00:49:41] <Speedy11CZ> github page xz.tukaani.org also down
[00:49:57] <aaabbb> could be down due to slashdot effect
[00:50:02] <aaabbb> the small server
[00:50:07] <Snetry> no, the xz.tukaani site was hosted on github
[00:50:15] <aaabbb> oh
[00:50:34] *** Joins: Guest81 (~Guest81@2a02:810b:4840:6ea0:20c4:ccc3:5513:b368)
[00:50:42] <Speedy11CZ> yeah
[00:50:54] <Noisytoot> although the one on git.tukaani.org seems to be slightly outdated
[00:51:05] <syu> Guest67: M247 LTD Singapore Infrastructure, and consistent
[00:51:14] <Guest67> Interesting
[00:51:20] *** Joins: Guest17567 (~Guest1756@23.94.74.107)
[00:51:45] <dnsmcbr> Guest67: Not reallu
[00:51:47] <Guest33> how did he add the malicious bins without showing in the git release?
[00:51:51] <bt__> M247 sounds like mullvad to me
[00:51:58] <Guest67> Is there any way the people who have the whowas info, can you preserve it and make it available if some known authority asks you for it?
[00:52:01] <Noisytoot> Is there an up-to-date mirror of xz?
[00:52:13] <tipsfedoraa> Guest33: they were disguised as test files
[00:52:16] <jess> M247 is a server provider that is commonly used by commercial VPN providers
[00:52:23] <jess> among other things
[00:52:24] <Snetry> Guesat33: the added malicious bits were included in the distribution tarballs
[00:52:29] <Guest67> If the ip was consistent over 2 years thats interesting, even if its m247
[00:52:35] *** Joins: Guest89 (~Guest41@2a11:3:500::d101)
[00:53:00] <Guest67> I know m247 is often a vpn provider but vpn users on there hop around
[00:53:24] <Guest67> Same ip for 2 years is v interesting
[00:53:36] *** Joins: tirnanog (~tirnanog@user/tirnanog)
[00:53:39] *** Quits: rocks22 (~rocks22@h209-169-222-202.hbbsnm.dedicated.static.tds.net) (Quit: Client closed)
[00:54:03] <Guest33> Snetry they added the tarballs to the GitHub release
[00:54:04] <Guest33> ?
[00:54:13] <Snetry> correct
[00:54:22] <balrog> https://github.com/tukaani-project/tukaani-project.github.io
[00:54:23] <Guest33> can you do that silently ?
[00:54:27] <balrog> disabled due ot TOS violation?
[00:54:35] <Snetry> Maintainers can add arbitrary files to releases, yes
[00:54:43] <Snetry> github also automatically adds generated tarballs
[00:54:44] <Guest33> would that show in the GitHub logs anywher
[00:54:45] <balrog> all the repos in the org are disabled
[00:54:45] <Guest33> e?
[00:54:47] <sam_> i've not seen any evidence of tarballs changing btw
[00:54:49] <syu> bt__: M247 is a large DC operator in many places, so there's nothing suspicious about it.
[00:54:54] <sam_> like theyre the same as day 1 from releases in our manifests
[00:55:09] *** Joins: ciro (~ciro@user/ciro)
[00:55:21] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Read error: Connection reset by peer)
[00:55:21] <aaabbb> the gentoo manifest?
[00:55:25] *** Joins: chadmed_ (~james@2403-580a-80ed-0-4835-5a07-49e7-f115.ip6.aussiebb.net)
[00:55:25] <Guest33> Snetry would there be any logs in the commits or releases that would show the file was added or different hash?
[00:55:31] <Guest67> I just want the guy's ip, which was publicly available and not even a violation of his privacy if someone shares it
[00:55:48] <aaabbb> Guest67: the ip seems to be a vps
[00:55:48] <jess> i think it would be unideal for people to share it
[00:55:53] <aaabbb> so it won't be helpful
[00:56:10] <junon> I also checked the tukaani git mirror and at least for xz-embedded nothing's changed
[00:56:12] <Guest67> Aaabbb you are making assumptions
[00:56:13] <rolf> aaabbb maybe Guest67 has something he want's to cross check it with
[00:56:13] <Snetry> Guest33: not really
[00:56:25] <Guest67> Rolf yes
[00:56:28] <aaabbb> Guest67: i was just told it was a vps
[00:56:30] <Snetry> however, the bit that is only in the dist tarball is only a small part
[00:56:40] <chadmed_> can the backdoor defeat non-PKA libpam modules? i require an OTP to log in to any web-exposed box
[00:56:54] *** Joins: rx80 (~quassel@user/rx80)
[00:56:54] <aaabbb> rolf: true and personally i would not hide the ip, but i also don't think it would be useful unless the threat actor's brain is smoother than glass
[00:57:00] <balrog> chadmed_: I don't know if the backdoor has been fully RE'd yet
[00:57:03] <Snetry> other segments which are part of this backdoor, such as the ifunc migration, payload diguised as test, etc. is all included in the git repo
[00:57:13] <aaabbb> balrog: it has not afaik
[00:57:14] <chadmed_> ack, masking and downgrading then 
[00:57:23] *** Quits: Speedy11CZ (~Speedy11C@2001-1ae9-158-5400-4008-30be-db44-7d4d.ip6.tmcz.cz) (Quit: Client closed)
[00:57:43] *** Joins: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz)
[00:57:45] <aaabbb> chadmed_: (if on gentoo) --update then it should be masked already afaik
[00:57:46] <Guest67> I only want to know from people who have the old whowas info. That stuff was public info, same as the github repos were public info.
[00:57:57] <chadmed_> yeah just saw sam's commit, ezpz
[00:58:05] <rolf> aaabbb, maybe there's things you are not considering or are not aware of , so try to not say " it wont matter "
[00:58:11] *** Joins: zoneroyadmin (~zoneroyad@178-251-151-7.ftth.kajonet.fi)
[00:58:16] <aaabbb> rolf: well i did say "i don't think"
[00:58:23] <aaabbb> because that is always a possibility
[00:58:26] <rolf> true, I stand corrected :)
[00:59:05] <aaabbb> i personally think that it is futile to try to find the person based on their info, or at least, that it is better to put efforts into uncovering the scope, impact, and reach of the backdoor first
[00:59:31] <rolf> Maybe it's not about finding the person, perhaps it's about wanting to check his own logs against that IP
[00:59:39] *** Quits: Guest30 (~Guest30@070-126-159-142.res.spectrum.com) (Quit: Client closed)
[00:59:44] <Guest67> aaabbb you dont know what other efforts are happening rn so please stop speculating about what isnt productive
[00:59:47] <dostoyevsky2> Snetry: imho they also should have checked in the actualy exploit...
[00:59:55] <dostoyevsky2> (the source that is)
[01:00:15] <Guest67> Ips are public in this server. I just checked a couple random users in here and i can see their ips
[01:00:24] <jess> i will say libera chat has policies against doxing and anything that looks even vaguely like it will be cracked down upon
[01:00:25] <Snetry> Yes, however
[01:00:30] <Guest67> So it shouldnt be a big deal to share jias ips
[01:00:32] <Snetry> what is the benefit of sharing that IP
[01:00:34] <aaabbb> Guest67: we're all speculating at this moment, except the people doing the actual work with reverse sengneering
[01:00:38] <Snetry> what would we gain
[01:00:47] <aaabbb> jess: well, public info is certainly not doxable
[01:00:47] *** Joins: pabs3 (~pabs3@user/pabs3)
[01:00:50] <Guest67> Finding other code this person touched
[01:00:53] *** Quits: Guest33 (~Guest33@074-071-073-113.res.spectrum.com) (Ping timeout: 250 seconds)
[01:00:59] <Guest67> Like that amazon wifi device
[01:01:00] <Snetry> and you do that via an ip?
[01:01:04] <aaabbb> i assume the ip was gotten with /whowas and not via an ip logger?
[01:01:07] <Guest67> That i found cause of his name
[01:01:08] <Guest59> aaabbb that's not true - people get doxed from unintentionally-public information all the time
[01:01:12] <jess> ^
[01:01:22] <aaabbb> Guest59: i mean in the context of libera, which shows ips in public
[01:01:28] <dostoyevsky2> Snetry: so you can find a random person that is using that ip right now and punish them for something they have no idea about and themn say "we did it!"
[01:02:01] <Guest67> Christ what kind of punishment do you think im going to do at an ip
[01:02:07] <Snetry> on my way to DDOS some random IP because someone that may have done something used it once
[01:02:17] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[01:02:21] <Guest67> Please stop making stupid speculations
[01:02:23] <aaabbb> Snetry: i'm gonna ddos 127.0.0.1, that guy is a total troll...
[01:02:31] <jess> please stop begging for jia's IP
[01:02:57] <Snetry> aaabbb: I'mma target 127.0.0.2
[01:02:59] <Guest67> The information is relevant to finding what other code bases were potentially compromised
[01:03:07] <jess> nonsense
[01:03:24] <aaabbb> guys! i narrowed down his ip. i am a 1337 h4x0r. his ip is in the range 0.0.0.0/0
[01:03:33] <rolf> It's maybe not about using the IP , rather to cross check ones own server logs for whatever reason (someone may or may not want to disclose right now)
[01:03:40] <Guest67> Any reference to the full name "Jia Cheong Tan" should also be checked for backdoor code. Thats my contribution to this channel, the full name.
[01:03:54] <Snetry> I absolutely cannot see how you can figure out contributions from an IP
[01:03:54] <aaabbb> Guest67: how do you know that's the full name?
[01:03:59] *** Joins: marblood (~marblood@45.134.213.216)
[01:04:07] <Snetry> Alternatively
[01:04:08] <Guest59> That name's shown up in a few places
[01:04:10] <rolf> It's not up to us to decide if the information may or may not be useful. It was public info, as is most other IP's of people in here
[01:04:13] <Snetry> how do you know they don't use a different name
[01:04:17] <Snetry> how do you know thats their real name
[01:04:18] *** Joins: Guest30 (~Guest30@070-126-159-142.res.spectrum.com)
[01:04:22] <Guest59> You don't
[01:04:22] <Snetry> how do you know they aren't a ghost?
[01:04:22] *** Joins: Yogurt (~Yogurt@158.51.82.203)
[01:04:26] <syu> Guest67: where is that name come from?
[01:04:37] <balrog> Guest67: a few commits were under that name
[01:04:41] <Guest67> Im not engaging in stupid conversations and pointless speculations happening in this channel
[01:04:44] <balrog> one commit*
[01:04:53] <Snetry> Hey, you are the one asking for an IP
[01:05:01] <Guest59> Guest67, cool your jets. I get that you want the IP but quit lashing out at everyone lol
[01:05:03] <Guest67> Syu that full name came from leaked data associated with jias email
[01:05:03] <Snetry> you just have to reasonably justify why you want it
[01:05:20] <Rounin> I wrote a GUI in Visual Basic to track his IP to the host 127.0.0.1
[01:05:21] <balrog> leaked data? no, commit 799ead162de63b8400733603d3abcd2e1977bdca in the repo
[01:05:28] <Guest67> This email jiat0218@gmail.com
[01:05:36] <aaabbb> Rounin: but can it track in real time?
[01:05:37] <Snetry> yeah that isn't rocket science
[01:05:40] <bt__> who would sneak something like this in while having their real name on the commits lol
[01:05:45] <bt__> its probably a fake alias
[01:05:59] *** Quits: Guest67 (~Guest67@pool-72-79-122-157.nwrknj.east.verizon.net) (K-Lined)
[01:06:03] <Rounin> aaabbb: ... No :( It's only VB5
[01:06:04] <Guest59> Nice
[01:06:08] <aaabbb> oof haha
[01:06:11] <cuma> https://github.com/tukaani-project/xz is gone
[01:06:21] <st3fan> all repos in that org
[01:06:21] <aaabbb> unlike his ip, the email is probably not public :p
[01:06:23] *** Parts: tirnanog (~tirnanog@user/tirnanog) (= "")
[01:06:24] <junon> Yeah github just nuked them a few minutes ago.
[01:06:24] <Snetry> cuma: yep
[01:06:28] <jess> not having it. no doxing
[01:06:42] <aaabbb> actually... is it doxing if it's already public info that he provided willingly in commits?
[01:06:43] <Snetry> this is going to negatively affect anyone relying on github for tarballs
[01:06:45] <cuma> still works for me: https://github.com/tukaani-project/.github
[01:06:50] <jess> 01:18:53 < Guest67> Syu that full name came from leaked data associated with jias email
[01:07:11] <aaabbb> oh leaked data
[01:07:15] <balrog> jess: that's false afaict, it's in the git history for the xz repo
[01:07:25] <Guest51> no leak https://fossies.org/linux/xz/ChangeLog
[01:07:38] <aaabbb> Guest51: tht has his email?
[01:07:45] <Guest59> That was a bold move by Guest67 - being told they're not allowed to dox, so they're like "here's a thing I allegedly doxed"
[01:07:54] <sam_> i think we're getting borderline if we're gathering known aliases etc from people though
[01:07:57] <jess> i dont care if it's false, if he believed that to be the case yet still put the information here, he believed he was disclosing leaked information, after being warned against it
[01:07:59] <sam_> id prefer to focus on the technical stuff in here
[01:08:00] <aaabbb> Guest59: i mean it depens on if it's spublic info or not
[01:08:02] <sam_> that too
[01:08:11] <rolf> Guys, this is rather "big" news , so don't rule out someone from for example Github (just an example) came here to find out some more info they can use to cross check their logs with. 
[01:08:16] <Guest59> Like I said before aaabbb, just because it's public doesn't mean referring to it isn't doxing
[01:08:18] <Snetry> I still don't understand how you can find contributions from an IP
[01:08:31] <syu> hmmmm, CJK does not have middle name = =
[01:08:38] <junon> Snetry: you can't.
[01:08:40] <Snetry> either I am living under a rock or there is a magic IP tool that lets you look up connections at any point in time
[01:08:41] <Guest59> Sometimes it's not doxing, but that's not a guarantee
[01:08:50] <aaabbb> Guest59: if i post my real name and email in a commit message, how is it doxing?
[01:08:55] <Snetry> junon: yeah I know, but apparently they are a magician 
[01:09:07] <cuma> And you cann see the time zone of the commits ( +0800)
[01:09:26] <Rounin> syu: Also his middle name is in a different dialect or language
[01:09:27] <Guest59> It's not doxing, but if you post it by mistake and remove it, but I managed to capture it before you did, it would 100% be doxing if I posted it here
[01:09:29] <Manis> Because time zones are absolutely not fakeable.
[01:09:33] *** Joins: HotSwap` (~hotswap@2607:5300:60:2b9b::1)
[01:09:47] <cuma> like names -.-
[01:09:52] <Rounin> syu: But you never know... People in Hong Kong have all kinds of names, for instance
[01:09:53] <aaabbb> like if someone digs through my twitter to find when i said my email once then yeah that's doxing but if all my commits are aaabbb@cccddd.com ...
[01:10:20] <cuma> jiatan used 2 gmail addressed
[01:10:21] <Manis> cuma: and Git commit emails. Anyone sent an email to that Gmail already? 
[01:10:22] <Snetry> not me faking the edit date on a file with touch(1) 
[01:10:24] <Snetry> not me at all
[01:10:36] <Snetry> Manis: don't give people bad ideas
[01:10:48] <rolf> Snetry, there's this thing called logs. Lot's of servers have them. No magic there, all you need is an IP and then you can simply use 'grep' to search for all occurances of that IP in the logs
[01:11:02] <Snetry> good for you
[01:11:04] *** Joins: boud (~boud@user/boud)
[01:11:21] <Guest59> I understand where sam_'s coming from with regards to the IP - it's *probably* not doxing, but there's enough uncertainty that it's not worth it. On top of the fact that they've probably been dealing with this for a lot longer than I've been paying attention to this
[01:11:21] <Snetry> If someone from github wants to know the IP of the user
[01:11:23] <Snetry> they can contact Libera
[01:11:27] <Manis> Snetry: I once had to touch mtime in university to meet a deadline ;-)
[01:11:27] <Snetry> and not some random users in a chat
[01:11:29] <Guest59> I only know about this because Arch sent an email
[01:11:30] <Guest80> JiaT75 real ip leak coming
[01:11:31] *** Quits: Guest30 (~Guest30@070-126-159-142.res.spectrum.com) (Quit: Client closed)
[01:11:38] <sam_> it's also that I wish I hadn't said anything and I just want to focus on doing something productive
[01:11:41] <rolf> Snetry , how is your Versatel connection working out for you?
[01:11:48] <sam_> like the huge amount of stuff i have to do today for this 
[01:11:49] <Guest80> 124.232.185.122
[01:11:50] <dnsmcbr> A mod should probably amend the topic with some stuff about no speculation/nonesenseness.
[01:11:54] <aaabbb> Guest59: it's 100% not doxing if it's from libera directly, but even if it's not, it's also 100% up to sthe person who knows it not to post it
[01:11:54] <i860> maybe they want the ip to see if there's an exploitable ssh server listening on it... Jia, is that you?
[01:11:56] <Snetry> rolf: I don't use Versatel, nice try
[01:12:01] <cuma> let me guess , it start with 127. ?
[01:12:04] <rolf> [Snetry] actually using host 87.122.105.236
[01:12:18] <sam_> (I am a real human who is a bit stressed and maybe didn't make the best judgement with saying i'd run whowas earlier)
[01:12:18] *** Joins: Guest30 (~Guest30@070-126-159-142.res.spectrum.com)
[01:12:24] <Snetry> yes, however due to a complicated routing situation I am transferred through a foreign ISP 
[01:12:33] *** Joins: ba (~ba@2a02:8012:ee0:0:e958:15b9:d3ec:2278)
[01:12:34] <dnsmcbr> and or quiet the guests
[01:12:41] <aaabbb> Guest80: wht's that?
[01:12:45] *** Joins: Guest62 (~Guest62@c-24-17-57-6.hsd1.wa.comcast.net)
[01:13:05] <Snetry> I pray for the moment Guests can't speak 
[01:13:07] *** Joins: aa_aa (~aa_aa@75-46-137-14.lightspeed.frokca.sbcglobal.net)
[01:13:08] <rolf> Sure, you can also use a bouncer, or vps or whatever. Point is, the info which is being asked is simply that public info which you can lookup for any user in here
[01:13:21] *** Quits: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz) (Quit: Client closed)
[01:13:29] <Snetry> yes but its not on me to share this information with you
[01:13:51] <Guest51> getting his vps's ip is useless, let ppl focus on reversing please
[01:13:53] <Snetry> if someone from github or osint wants the IP, ask the proper people 
[01:13:59] <Guest59> sam_: godspeed - no complaints from me
[01:14:02] <rolf> Well.... I just posted your info in here, how do you feel about that?
[01:14:03] <Guest30> Maybe people who talk about jia's identity in here should be pointed to another channel so this can remain focused on technical discussion
[01:14:14] *** Joins: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz)
[01:14:24] <jess> people wishing to talk about jia's identity ought to go somewhere that isn't libera chat
[01:14:30] <Guest59> +1
[01:14:41] <Speedy11CZ> +1
[01:14:48] <Snetry> rolf: I find it quite rude of you
[01:14:49] <rolf> +1.86
[01:14:58] <cuma> only facebook users in here?
[01:15:23] <Snetry> next you are gonna post my real name and home address :(
[01:15:34] <Snetry> :^)
[01:15:38] <Yogurt> -3.86
[01:15:52] <Yogurt> jia is clearly satoshi nakamodo
[01:16:05] <Guest59> I realize I'm also a guest (don't want to use an identifiable name) but I kinda agree with Snetry's muting guests idea (I also don't have anything useful to say, and just wanted to follow technical discussion)
[01:16:08] <aaabbb> Yogurt: no we confirmed he was hans reiser not too long ago
[01:16:18] <Yogurt> did you?
[01:16:28] <Yogurt> ed my b
[01:16:29] <dostoyevsky2> aaabbb: HR has internet in jail?  
[01:16:41] *** Quits: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz) (Client Quit)
[01:16:51] <i860> sam_: "However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma" <-- please tell me we don't and won't do this for gentoo
[01:16:53] <aaabbb> dostoyevsky2: he was able to sneak out by writing a filesystem that could rapidly unallocate the walls
[01:16:58] <Guest30> #tukaaninontechnical?
[01:16:59] <sam_> i860: wont happen
[01:17:05] <Manis> I was looking through Git but didn't find sth: was build-to-host.m4 ever in Git?
[01:17:11] <sam_> i860: AND good news, cjwatson informed us earlier that upstream are working on this properly (without libsystemd)
[01:17:11] *** Joins: StefanCristian (~quassel@redcorelinux/brrc/stefancristian)
[01:17:18] <sam_> Manis: no
[01:17:20] <Snetry> Manis: its in the dist tarballs
[01:17:24] *** HotSwap` is now known as Hotswap
[01:17:25] <sam_> Manis: but this is normal for autoconf, unfortunately...
[01:17:34] <Snetry> most specifically
[01:17:35] *** Quits: chadmed_ (~james@2403-580a-80ed-0-4835-5a07-49e7-f115.ip6.aussiebb.net) (Remote host closed the connection)
[01:17:42] <Manis> Is it a standard m4 module of autotools?
[01:17:43] <Guest59> Who is upstream, in that case? openssh?
[01:17:47] *** Joins: Tuvix (~Tuvix@gateway/tor-sasl/tuvix)
[01:17:48] <i860> awesome.. the less unnecessary coupling, the better
[01:17:51] <Snetry> the built-to-host included in the tarball was modified from the original
[01:17:56] <sam_> Manis: it's from gnulib so kind of 
[01:18:03] <sam_> Manis: not totally but it's a well known module i recognised the name of
[01:18:07] <sam_> guest59: yes
[01:18:07] *** Quits: Guest62 (~Guest62@c-24-17-57-6.hsd1.wa.comcast.net) (Quit: Connection closed)
[01:18:11] <balrog> sam_: is there any plan to make all the test data files generatable? This is what irked me -- opaque blob test files
[01:18:25] <Guest59> Cool, I'm glad they're going that direction
[01:18:27] <sam_> balrog: i can't say but it's something i think that we should discuss when we're out of the storm 
[01:18:30] <Manis> sam_: OK this explains the long list in m4/.gitignore
[01:18:32] <Yogurt> I would guess the tests are benign
[01:18:33] <sam_> definitely a good idea
[01:18:39] <Yogurt> but ya someone should
[01:18:47] <dostoyevsky2> can one generally check if tar files only contain files that are also in git?
[01:18:56] <sam_> balrog: that said, I wish I'd spotted (just as a contributor) that the tests weren't wired up to anything. I noticed the change but I assumed there was some magic glob or something :|
[01:18:58] *** Joins: Guest27 (~Guest61@136.158.1.98)
[01:19:01] <boud> rolf: I meant "lol Guest81" - maybe you and aaabbb are right that that was meant as a joke - deadpanned. Sometimes it can be hard to read between the lines...
[01:19:03] <dostoyevsky2> Not sure if that would make sense
[01:19:11] *** Joins: Guest62 (~Guest62@c-24-17-57-6.hsd1.wa.comcast.net)
[01:19:19] <Yogurt> sam_: hindsight is 20/20
[01:19:21] *** Quits: Guest30 (~Guest30@070-126-159-142.res.spectrum.com) (Quit: Client closed)
[01:19:24] <sam_> too right
[01:19:36] *** Joins: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz)
[01:19:42] <balrog> sam_: that's the weird bit, they are wired up to stuff but are especially insidious because the backdoored files are both valid tests and with some manipulation, extract to the backdoor data
[01:19:53] <sam_> yep
[01:19:56] <Manis> dostoyevsky2: I also had this idea. You have the problem that in some cases the differences are totally unproblematic like a pre-compiled configure script.
[01:20:04] <Guest59> dostoyevsky2 I have a feeling (or at least hope) people take from this experience and bolster defenses against this happening in the future - as far as I can tell, this is all fairly novel in the FOSS world
[01:20:09] <sam_> I think what could maybe be done is having generated tests in the main repo, and then separate tests (maybe from e.g. fuzzing and such) with binaries in another repo
[01:20:14] <sam_> this is just me talking out of my ass
[01:20:16] *** Quits: Guest12 (~Guest43@port-83-236-48-237.dynamic.as20676.net) (Quit: Client closed)
[01:20:16] <sam_> but you get the idea
[01:20:36] *** Joins: Guest87 (~Guest87@d72-38-17-41.commercial1.cgocable.net)
[01:20:38] <balrog> I'm saying I should be able to regenerate the tests from scratch based on known, readable/understandable patterns etc
[01:20:46] <sam_> yes
[01:20:49] <Manis> Guest59: its not. Malicious distfiles did bite people already before. But more in the JS world.
[01:20:51] *** Joins: bbera97 (uid644095@id-644095.helmsley.irccloud.com)
[01:20:52] *** Joins: Guest33 (~Guest33@074-071-073-113.res.spectrum.com)
[01:20:54] <balrog> but yeah something to deal with down the road
[01:20:56] <Guest59> So e.g. people managing distros would likely want binary data to be "nothing-up-my-sleeve"
[01:21:03] *** Quits: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz) (Client Quit)
[01:21:04] <sam_> balrog: i'm just saying that as a compromise, if people say "we really need to have fuzzed weird binaries too", they could go separately in a repo 
[01:21:31] <balrog> I'm reminded of that whole thing with Serde in rust
[01:21:31] <Yogurt> can you measure if the files are accessed during the test?
[01:21:37] *** Joins: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz)
[01:21:44] *** Quits: io_default (~io_defaul@user/io-default/x-3141089) (Ping timeout: 268 seconds)
[01:21:45] <dostoyevsky2> Manis: but I guess for configure you could just force people to not include it...  as it would then be created by your local autoconf
[01:22:06] <bbera97> is there any history of this irc chat anywhere?
[01:22:10] <Manis> dostoyevsky2: I think the way to go would be reproducible dist files
[01:22:26] <Manis> Can I generate the dist files from Git with a set of commands
[01:22:44] <Manis> If these commands include autoreconf and I get the same tarball, fine by me.
[01:22:46] <sam_> ./autogen.sh && ./configure && make dist
[01:22:47] <Guest59> balrog you mean when dtolnay shipped the precompiled binaries to speed up compilation?
[01:22:55] *** Quits: Speedy11CZ (~Speedy11C@adela.node.speedy11.cz) (Client Quit)
[01:23:09] <balrog> mhmm
[01:23:15] <Guest59> Yeah, as much as I trust dtolnay, I'm glad that got removed in the end
[01:23:25] <Snetry> autoconf makes me miserable
[01:23:34] <sam_> i think its making us all miserable today
[01:23:50] <dostoyevsky2> Manis: well, then you have something like a nix recipe... because if you don't have the same autoconf as was used for the tar, then it won't be reproducible... but not sure if Nix is realistic atm, it's a lot of work
[01:23:52] <Snetry> obviously we need to move forwards with VS Solutions
[01:23:56] <Manis> How is this autoconf's fault?
[01:24:02] *** Joins: nbadal1 (~nbadal@75-46-137-14.lightspeed.frokca.sbcglobal.net)
[01:24:11] *** Quits: aa_aa (~aa_aa@75-46-137-14.lightspeed.frokca.sbcglobal.net) (Quit: Client closed)
[01:24:16] <sam_> because the way this project worked is normal for autoconf, and autoconf also generates gunk which lets you hide evil stuff inside without people noticing
[01:24:27] <Snetry> Mantis: I don't think anyone is blaming autoconf, however its... obtuse nature didn't really help
[01:24:40] <Manis> dostoyevsky2: well you could use a specific autoconf version.
[01:24:40] <Yogurt> bbera97: probably
[01:24:41] *** Quits: chopstick (~chopstick@104.28.222.157) (Remote host closed the connection)
[01:24:45] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:45b1:dc9c:11cf:8e56)
[01:24:52] *** nbadal1 is now known as nbadal
[01:25:00] *** Quits: Haaninjo (~anders@fsf/member/Haaninjo) (Quit: Ex-Chat)
[01:25:07] *** Joins: chopstick (~chopstick@104.28.222.157)
[01:25:16] <balrog> autoconf expects you to ship various scripts together with releases (that are generated by autoreconf)
[01:25:29] <balrog> autoconf also is cumbersome and obtuse in general
[01:25:30] <Snetry> you have some files to reconfigure, the generated configure script (which may be different from whatever you end up generating), some m4 files which are used all along, some resulting Makefile
[01:25:41] <Manis> sam_: the dot in the landlock detection check is also in CMake, so I'm not sure if that problem is only autotools. 
[01:25:47] <balrog> the main thing that it has going for itself is that it does support a lot of legacy platforms
[01:26:09] <sam_> Manis: show me? eating atm
[01:26:12] *** Quits: Guest81 (~Guest81@2a02:810b:4840:6ea0:20c4:ccc3:5513:b368) (Quit: Client closed)
[01:26:14] <Snetry> balrog: Are people still running seventh edition unix?
[01:26:34] <dostoyevsky2> Snetry: I stopped at sysV
[01:26:43] <Guest51> re: upstream patch https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c13
[01:26:43] <Noisytoot> guix always rebuilds autoconf files even if they're included in the tarball. why don't other distros do the same?
[01:26:54] <balrog> Snetry: not widely
[01:26:59] <Snetry> so uhhh, wait
[01:27:08] <Snetry> xz switched to github full time
[01:27:13] <dostoyevsky2> Noisytoot: Yeah, it's a bit like including .o files along with your c files... the way autconf is often including the configure
[01:27:15] <Snetry> the website was hosted on github
[01:27:16] <balrog> there are still some deployed legacy systems but those usually don't update software
[01:27:20] <sam_> Noisytoot it wouldnt fix this 
[01:27:24] <uniq_> i maintain a repo for very old iOS versions and i love autoconf, cmake works but i have to do some weird stuff with the rpath of shared libraries and have to pass way more config options
[01:27:25] <sam_> bc bad .m4
[01:27:26] <Snetry> and now with the repo suspended, every package is broken
[01:27:27] *** Quits: chopstick (~chopstick@104.28.222.157) (Remote host closed the connection)
[01:27:27] <balrog> and then you have the handful of retrocomputing enthusiasts
[01:27:48] <balrog> uniq_: cmake has improved rpath handling over time but yeah
[01:28:01] <Snetry> cmake also likes to avoid rpath because rpath is yuck
[01:28:08] <Manis> sam_: https://git.tukaani.org/?p=xz.git;a=blob;f=CMakeLists.txt;hb=0b99783d63f27606936bb79a16c52d0d70c0b56f#l1004
[01:28:39] <sam_> nice spot
[01:28:48] <Guest33> Was this lib used alot within these various linux images
[01:28:49] <Guest33> ?
[01:29:30] *** Joins: JTL (~jtl@user/jtl)
[01:29:52] <Snetry> yeah, xz is still used in a lot of places
[01:30:21] *** Quits: Guest87 (~Guest87@d72-38-17-41.commercial1.cgocable.net) (Quit: Client closed)
[01:30:28] <uniq_> yea cmake building shared libs, at least for iOS 3, sets the install_name (darwin equivelent of soname) to the cmake build folder, apperently theres a config option that makes it not do that and always set to <prefix>/lib/libwhatever.dylib, but that config option doesnt work for some reason
[01:30:29] <Manis> For me the main advantage of autotools is exactly that the result is a huge shell script which contains everything which is necessary and I don't need to build a huuge CMake or Python for meson.
[01:31:22] <Manis> Snetry: still?
[01:31:26] <dostoyevsky2> Manis: one could check in the configure script as well, if it's in the tar
[01:31:51] <Manis> dostoyevsky2: one could but it's discouraged.
[01:31:52] <Snetry> Manis: Its not as widely used as it had been, but its never gonna fully disappear
[01:31:52] <rolf> No, only very very new (bleeding edge and rolling releases) got this lib, and only if the system as been recently updated. But if you mean "is xz used often" then yes, Snetry is correct: it is used in a lot of places. Although this backdoor focusses specifically on specific conditions and has so far only been found in a very new version which is only used in very, very up-to-date systems. 
[01:32:05] <Snetry> also
[01:32:07] <Snetry> I looked into /usr/bin/autoreconf and the first thing it does is exec 
[01:32:15] <Snetry> exec perl
[01:32:23] <Manis> Snetry: the sad thing is it was (is?) still my favourite.
[01:32:52] <uniq_> i will say though, debugging configure scripts is hell, for one thing if i open the script in neovim, neovim tries to run shellcheck a lot, which can crash my machine if it gets run enough times, shellcheck wasnt designed for files that big
[01:32:59] *** Quits: tipsfedoraa (~tipsfedor@216.243.40.138) (Quit: Client closed)
[01:33:19] <i860> Seen on ycomb: "Overall the only safe action would IMHO to establish a new upstream from an assumed good state, then fully audit it. At that point we should probably just abandon it and use zstd instead." <-- i hate this kind of take
[01:33:25] <jess> i am informed that homebrew had 5.6.1 but has since been downgraded
[01:33:36] <uniq_> yea homebrew downgraded to 5.4.6
[01:33:53] <Manis> dostoyevsky2: if you just want to ensure there is no code sneaked in you could just regenerate the configure script with a given version of autoconf and gnulib. Just like with reproducible builds you need to use the same compiler.
[01:34:10] <i860> yes, let's totally abandon it over this rather than simply rolling back! irrational and absurd
[01:34:18] *** Joins: Guest48 (~Guest69@2a09:bac2:383d:d2d::150:4)
[01:34:23] <Yogurt> or revert then audit back the commits one by one
[01:34:25] <Snetry> yknow
[01:34:29] *** Joins: io_default (~io_defaul@user/io-default/x-3141089)
[01:34:29] <Yogurt> commits/PRs
[01:34:38] <uniq_> nobody is abandoning the whole compression method lul its too popular
[01:34:41] <Snetry> I do wonder why the pattern with autoconf is shipping a generated configure script instead of having everyone generate their own
[01:34:56] *** Quits: Guest33 (~Guest33@074-071-073-113.res.spectrum.com) (Quit: Client closed)
[01:35:03] <dostoyevsky2> uniq_: Sometimes I wonder if vim/nvim are still usable editors these days... they also crash on me when I open 100k json files that have one line
[01:35:05] <uniq_> its so people dont have to have autoconf installed to build it
[01:35:05] <Manis> i860: fortunately I don't have any xz archives which I may want to unpack, lol
[01:35:28] <aaabbb> uniq_: aww we aren't going back to compress(1)?
[01:35:30] <sam_> none of this is really specific to xz, even if people want it to be
[01:35:31] *** Quits: Guest62 (~Guest62@c-24-17-57-6.hsd1.wa.comcast.net) (Ping timeout: 255 seconds)
[01:35:36] <sam_> this could happen to any FOSS project
[01:35:53] <Manis> Snetry: because it's self-contained.
[01:35:58] <i860> so that people can type ./configure --whatever with all the auto* stuff being needed (which can be its own can of worms)
[01:36:01] <JTL> I'm old enough to remember when UnrealIRCd had the eval backdoor :P
[01:36:05] <Yogurt> sam_: known vs unknown
[01:36:15] <sam_> JTL: lol
[01:36:23] <sam_> I was chatting about it the other day with an unrealircd developer
[01:36:39] *** Joins: PA17532 (~PA17532@067-011-240-216.res.spectrum.com)
[01:36:47] <aaabbb> JTL: i'm old enough to remember when xz had that back door. remember that guys?
[01:36:52] <i860> sam_: right, which is i why i dislike the angling of "let's use my preferred thing instead"
[01:37:05] <JTL> aaabbb: we'll be saying that in 15 years :D
[01:37:06] <Manis> Log4shell
[01:37:14] <uniq_> dostoyevsky2: its really the fault of the linter plugin for not killing old shellcheck processes before spawning new ones, and not having a file size limit for linting, but if i really need something super small theres an editor called nextvi i use, its like 250k, doesnt even require ncurses, i put it whereever neovim or vim cant run
[01:37:16] <sam_> i860: yep
[01:37:57] *** Joins: Bahhumbug (jrd@libera/staff/jrd)
[01:38:06] *** Quits: leonic (~leonic@user/leonic) (Quit: Konversation terminated!)
[01:38:07] <i860> >super small
[01:38:07] <i860> >250k
[01:38:19] <i860> i remember the 4k demo scene!
[01:38:45] <aaabbb> here i am thinking 48k demo scene was small
[01:38:59] <uniq_> i challenge you to find a smaller interactive console editor that only depends on libc
[01:39:23] <uniq_> ive gotten it as low as like 170k with a -Os static musl link
[01:39:25] <Manis> uniq_: nextvi looks interesting at first glance. Thank you.
[01:39:47] <i860> you got me with "interactive" as i was about to type "cat"
[01:39:52] <rolf> same, bookmarked for later , thank you for mentioning nextvi
[01:40:27] <uniq_> nextvi is also the only other non-vim vi clone i know of with syntax highlighting
[01:40:29] <Manis> Maybe I can finally replace busybox vi.
[01:40:54] <Manis> i860: ed is the standard.
[01:41:08] <dostoyevsky2> uniq_: you could try gzexe or upx... could probably be quite small
[01:41:56] <dostoyevsky2> linux executuables tend to be quite bloated, e.g. for demand paging and the like... saves you swap space
[01:42:51] <uniq_> if you do use nextvi, check out the patches branch for optional patches that provide extra features, default build is a bit too small for my liking
[01:43:07] <sam_> didn't we learn a lesson today about random patches 
[01:43:14] <sam_> (both to openssh and.. well)
[01:43:33] <uniq_> they're small enough you can just read the whole patch easily
[01:43:41] <sam_> just joking :p
[01:43:45] <JTL> uniq_: That was going to be my next question :P
[01:44:00] <Manis> TIL systemd is bad :-)
[01:44:06] <dostoyevsky2> sam_: I think the lesson is that when you sign up for an account we need to have a mandatory "[ ] State Actor" checkbox
[01:44:19] <rolf> roflmao
[01:44:19] <Manis> dostoyevsky2: lol
[01:44:21] <sam_> ✅ 
[01:44:23] <sam_> WAIT
[01:44:24] <sam_> NO
[01:44:36] <sam_> ❌❌
[01:44:38] *** Joins: tail (uid27590@id-27590.ilkley.irccloud.com)
[01:44:44] <aaabbb> dostoyevsky2: no need for that, just make a requirement for them to properly set the evil bit
[01:45:14] *** Joins: femto113 (~femto113@198.244.100.102)
[01:45:42] <Manis> Is that what the t in the mode stands for? Tampered?
[01:45:52] *** Joins: DarkOK (~DarkOK@cpc155839-brmb12-2-0-cust434.1-3.cable.virginm.net)
[01:45:59] <Manis> :-)
[01:46:13] *** Quits: junon (~junon@user/junon) (Remote host closed the connection)
[01:46:56] *** Joins: Guest8 (~Guest41@a89-152-157-153.cpe.netcabo.pt)
[01:47:39] *** Joins: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net)
[01:48:53] <i860> looks like the random 1password guy explained his PR against the xz/cgo repo: https://github.com/jamespfennell/xz/pull/2#issuecomment-2027836356
[01:48:56] <balrog> Manis: heh it's more complicated there, no reason they needed to link against libsystemd to implement such a simple protocol
[01:49:25] <sam_> i860: all roads lead to gentoo
[01:49:26] <Snetry> correct however
[01:49:43] <Snetry> as a distro its easier to just link something than to add a completely new piece of code
[01:52:46] <ciro> Relevant commits:
[01:52:48] <ciro> https://git.tukaani.org/?p=xz.git;a=commit;h=cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0
[01:52:49] <ciro> https://git.tukaani.org/?p=xz.git;a=commit;h=e5faaebbcf02ea880cfc56edc702d4f7298788ad
[01:52:51] <ciro> https://git.tukaani.org/?p=xz.git;a=commit;h=72d2933bfae514e0dbb123488e9f1eb7cf64175f
[01:52:52] <ciro> https://git.tukaani.org/?p=xz.git;a=commit;h=82ecc538193b380a21622aea02b0ba078e7ade92
[01:52:54] <ciro> https://git.tukaani.org/?p=xz.git;a=commit;h=6e636819e8f070330d835fce46289a3ff72a7b89
[01:52:54] <sam_> you're a bit behind 
[01:53:01] <sam_> please read the linked FAQ in /topic and so on
[01:53:32] *** Quits: PA17532 (~PA17532@067-011-240-216.res.spectrum.com) (Quit: Client closed)
[01:53:37] <i860> sam_: it's been my personal distro of choice for close to 20 years
[01:53:43] *** Quits: roote (~roote@2001:818:e95a:3b00:7127:4bfa:df2a:f26c) (Quit: Client closed)
[01:53:49] <sam_> i860: :)
[01:58:53] <Yogurt> gentoo taught me ctrl+c was a thing
[01:59:07] <Manis> Yogurt: how come?
[01:59:40] <Yogurt> it was when I was trying to install it way back in the day
[02:00:18] <Yogurt> I had no idea what I was doing and basically stumbling through the menus. Each time I messed something up I rebooted instead of ctrl+c cancel and try again
[02:00:50] <Yogurt> I eventually got it going, asked about that on a forum and then learned about ctrl+c
[02:00:52] <uniq_> only time ive been able to use gentoo was in WSL, I can't for a whole desktop
[02:01:08] <Manis> balrog: I don't know systemd-notify but I think OpenRC has something similar.
[02:01:18] <uniq_> for my desktop im using opensuse currently
[02:01:48] *** Joins: Ninpo (~Ninpo@user/ninpo)
[02:01:49] <Manis> Yogurt: nice. Were you a DOS user back in the day?
[02:01:56] <Yogurt> windows xp
[02:01:59] <Ninpo> hey sam_ 
[02:02:02] <Yogurt> but also pretty young
[02:02:45] *** Quits: luccc (~lukas@ip-193-53-104-44.changeis.iunxi.net) (Ping timeout: 260 seconds)
[02:02:53] <Manis> Hmm, ok I just thought that could be because DOS has no way I know of to do job control. Which is totally annoying.
[02:03:11] <Yogurt> you are giving me far to much credit there
[02:04:50] *** Quits: Guest80 (~Guest13@2a01:4f8:1c1e:a0e0::1) (Quit: Client closed)
[02:05:11] *** Quits: jghali (~jghali@185.208.60.131) (Read error: Connection reset by peer)
[02:05:35] *** Quits: Guest59 (~Guest59@bras-base-otwaon0906w-grc-15-142-126-188-20.dsl.bell.ca) (Quit: Client closed)
[02:06:36] *** Joins: Guest54 (~Guest68@dsl-tkubng11-54f8b6-0.dhcp.inet.fi)
[02:07:20] *** Joins: bortolotto (~bortolott@177.133.255.225)
[02:07:45] *** Joins: radek (~igloo@109-81-89-137.rct.o2.cz)
[02:09:03] <dnsmcbr> Compression really suffers from xkcd 927
[02:09:56] *** Joins: Guest14 (~Guest57@181.29.16.10)
[02:11:32] *** Joins: Conjuro (~Conjuro@pg.conjuro.net)
[02:12:26] <bortolotto> Hi! Just noticed that github blocked tukaani's xz repo. Someone know if tukaani's original repo is now safe to clone?
[02:13:17] <bdrewery> welcome to the party
[02:13:25] <bortolotto> *by safe I mean 'fixed'. :)
[02:15:32] <bortolotto> Hi bdrewery :) I'm still trying to understand what happened. Totally shocked by that CVE.
[02:15:58] <Celelibi> No.
[02:16:16] <Celelibi> Use an older version. Not 5.6.0 or 5.6.1
[02:16:27] *** Quits: radek (~igloo@109-81-89-137.rct.o2.cz) (Ping timeout: 255 seconds)
[02:16:37] <Celelibi> They're not guaranteed safe, but are not guaranteed backdoored. :)
[02:16:39] <uniq_> I'm pretty sure theres people auditing the maintainers full commit history and we can't say anything is safe until every commit has been checked
[02:16:59] <bdrewery> bortolotto: see topic URL
[02:17:15] <uniq_> they'll be done eventually and we'll get a patched version of 5.6.1 that's safe probobly
[02:17:16] <bortolotto> oh tks!
[02:17:34] *** Joins: Guest53 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi)
[02:18:42] <uniq_> if you just need to extract xz files and dont need to link liblzma in particular you could use 7zip/p7zip
[02:18:53] *** Joins: mroszko (~mroszko@2600:4041:539c:f700:9c69:f85b:71c3:dc06)
[02:18:55] <uniq_> that has its own implementation
[02:19:03] <mroszko> uh so github nuked the repo
[02:19:10] <uniq_> indeed
[02:19:10] <mroszko> this is a problem for many build systems
[02:19:17] <mroszko> github is staffed by morons isnt it
[02:19:31] <mroszko> absolute morons*
[02:19:33] <StefanCristian> mroszko: horrible take, yes
[02:19:46] <aaabbb> mroszko: well yes but their action in suspending it was not moronic at all
[02:19:46] <uniq_> i just pull down the 5.4.6 tarball from the tukaani site
[02:19:54] <mroszko> the repo should have been frozen
[02:20:13] <mroszko> if they want , they should announce they will nuke it
[02:20:14] *** Joins: Guest93 (~Guest41@p508b71ad.dip0.t-ipconnect.de)
[02:20:16] <StefanCristian> aaabbb: they could have just 403 deny on code fetch & releases
[02:20:17] <StefanCristian> and tags
[02:20:18] <mroszko> but everyone else is scrambling to revert currently
[02:20:27] <mroszko> libxz is not a small time dependency
[02:20:40] <mroszko> its got enough things using it, it cant just be replaced like leftpad that the smoothbrains at github use
[02:20:43] <aaabbb> StefanCristian: possibly but i'm sure they have a policy to follow
[02:21:12] <StefanCristian> aaabbb: they don't. they don't have any procedure of disabling read/fetch acess in such cases
[02:21:27] <aaabbb> i mean their policy is to suspend the repo
[02:21:37] <StefanCristian> that's the terrible part
[02:21:52] <mroszko> basically, what github is about to have, is multiple libxz repos with no fork history
[02:21:53] <StefanCristian> we're talking about letting discussions open
[02:21:53] *** Joins: Lena_ (~Lena@2001-4dd6-cc6b-0-10a3-521b-acd5-f5ed.ipv6dyn.netcologne.de)
[02:22:06] <aaabbb> ah
[02:22:12] <mroszko> because everyone is going to try and quickly restore the git repo
[02:22:16] <mroszko> so they can restore the build systems
[02:22:19] <StefanCristian> absolutely
[02:22:37] <uniq_> mroszko: *liblzma, there is no libxz
[02:22:40] <aaabbb> i wonder how many companies are going to say "We have to get this running, i don't care i fit's backdoored"
[02:22:44] *** Quits: DarkOK (~DarkOK@cpc155839-brmb12-2-0-cust434.1-3.cable.virginm.net) (Quit: buh bye)
[02:22:47] <StefanCristian> absolute horror take
[02:22:49] <acidsys> to restore build systems one can just point at the upstream git 
[02:23:04] *** Joins: Sadale (~Sadale@user/sadale)
[02:23:44] <StefanCristian> acidsys: yes, many have such links, but it's not the actual problem. it's Github's approach to open discussions, knowledge share, reporting and possibly solutions fix on a compromised repository
[02:24:09] <mirppc> oh hey acidsys 
[02:24:10] <StefanCristian> automation isn't the main issue for now
[02:24:14] <aaabbb> hopefully they will open it back up very soon with pull request etc disabled
[02:24:23] <mroszko> if you havent noticed in general, github's cve system can't even handle non-webjunk software packages
[02:24:30] <StefanCristian> pull requests can be possible, but merge can be blocked
[02:24:31] <mroszko> so the ui is half incomplete for anything that isnt webjunk
[02:24:41] <StefanCristian> mroszko: true
[02:24:45] <mroszko> because it wont let you fill in a package name for something that isnt NPM or pypi
[02:24:46] <mroszko> lol
[02:26:08] <StefanCristian> they need to have a security procedure for security issues like this, as: deny code fetch, deny release & tags fetch, deny pull request merge, but open pull requests (to have patches from abroad centralized), & open discussion for reporting and recommendations
[02:26:34] *** Joins: corn7890 (~corn7890@2601:441:4280:8ab0:529:cc85:341e:7b11)
[02:26:35] <StefanCristian> a simple "you cannot download the application right now because it contains a severe vulnerability" or something
[02:26:38] *** Quits: Lena_ (~Lena@2001-4dd6-cc6b-0-10a3-521b-acd5-f5ed.ipv6dyn.netcologne.de) (Ping timeout: 272 seconds)
[02:26:43] <StefanCristian> not nuking everything, lol
[02:26:45] <StefanCristian> just horrible GH
[02:26:53] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Read error: Connection reset by peer)
[02:27:01] <aaabbb> i agree, i didn't even think of how it killed discussion
[02:27:20] <StefanCristian> it killed all discussions, reports, everything
[02:27:31] <aaabbb> it also means the links to the relevant commits are goe
[02:27:33] <dnsmcbr> Killing discussion was probably partially the point
[02:27:33] <aaabbb> gone
[02:27:41] <StefanCristian> people were legitimately showing comments on-code what was wrong
[02:27:41] <dnsmcbr> It’s also not gone
[02:28:04] *** Quits: Guest54 (~Guest68@dsl-tkubng11-54f8b6-0.dhcp.inet.fi) (Quit: Client closed)
[02:28:05] <aaabbb> dnsmcbr: i mean the direct link is gone, 90% of people will not look elsewhere from it when they come from lwn
[02:28:08] <StefanCristian> comments on commits, links, everything temporary disabled
[02:28:10] <st3fan> It is just disabled. Not gone.
[02:28:11] <StefanCristian> since it's not completely gone
[02:28:13] <StefanCristian> yeah
[02:28:35] <st3fan> I have a full copy of the repo that I can upload tomorrow if that helps people
[02:28:38] <aaabbb> it's not lost, but the number of people who will see it are severely reduced
[02:28:39] <mroszko> it could also be github got a subpoena because the feds apparently were involved
[02:28:45] <StefanCristian> st3fan: it's on their tukaani main git
[02:28:47] <mroszko> st3fan https://git.tukaani.org/xz.git
[02:28:53] <aaabbb> mroszko: apparently were? source?
[02:28:58] <StefanCristian> ^ link above
[02:29:04] <mroszko> it was mentioned in the openwall mailing list
[02:29:09] *** Joins: Guest49 (~Guest49@88-114-248-56.elisa-laajakaista.fi)
[02:29:10] *** Joins: Guest56 (~Guest56@185.89.39.31)
[02:29:14] <st3fan> It is the right thing to do during an investigation so that nobody can change things
[02:29:18] <dnsmcbr> I don’t think anyone actually cares about the source really except maintainers
[02:29:40] <aaabbb> dnsmcbr: people want to see the malicious comments linked in the original openwall post
[02:29:41] <StefanCristian> dnsmcbr: some distros have their main code fetched from main repo
[02:29:43] <st3fan> I also exported repo and user events with the GitHub api
[02:29:58] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:45b1:dc9c:11cf:8e56) (Quit: nyaa~)
[02:30:22] <mroszko> supposedly CISA was trying to reach out to Lasse
[02:30:26] <mroszko> Lasse is apparently in Finland
[02:30:29] <st3fan> And archived the releases and meta data. Let me know if useful to analyze.
[02:30:30] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:491f:dcb2:3d48:9951)
[02:30:45] <dnsmcbr> None of us (exceptions for the distro maintainers here) lot are going to be impacted or able to action anything on the repo or otherwise
[02:31:05] <dnsmcbr> God knows where the cisa thing came from
[02:31:11] <JTL> > 02:44 <mroszko> supposedly CISA was trying to reach out to Lasse
[02:31:12] <JTL> do we know when?
[02:31:25] <mroszko> nope
[02:31:28] <mroszko> just "
[02:31:28] <mroszko> > 3. We were aware of concurrent coordination efforts by other groups
[02:31:29] <mroszko> > (CERT/CC, CISA) and we didn't want to interfere with their plans."
[02:31:37] <JTL> ah okay
[02:31:39] <aaabbb> he's in this room, found him! /s
[02:31:43] <mroszko> but apparently openwall has known about this for a few days?
[02:31:52] <acidsys> aaabbb: the links from the original post can be found through archive.org. for example https://web.archive.org/web/20240330001400/https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0
[02:31:53] <mroszko> or rather oss-security
[02:31:56] <mroszko> i keep saying openwall lol
[02:31:59] <mroszko> better name honestly
[02:31:59] <mroszko> haha
[02:32:01] *** Joins: Hunter (~hunter@107-223-197-199.lightspeed.tukrga.sbcglobal.net)
[02:32:15] <aaabbb> acidsys: but not all the hilarious comments
[02:32:15] <Hunter> Why you putting backdoors in your software
[02:32:21] <Hunter> nigga that wrong
[02:32:36] <aaabbb> Hunter: we all decided together that it would be a good april fools's joke
[02:32:41] <mroszko> anyway i just imported the liblzma repo back to github :3
[02:32:45] <mroszko> because i need it.
[02:32:51] <Hunter> its march
[02:33:07] <dnsmcbr> Hunter: some bellend Postgres dev got too nosy
[02:33:19] <dnsmcbr> Ruined the surprise >:(
[02:33:20] <aaabbb> Hunter: the early bird catches the worm
[02:33:28] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[02:34:58] *** Joins: uniq__ (~uniq_@2605:a601:9190:3900:491f:dcb2:3d48:9951)
[02:35:09] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:491f:dcb2:3d48:9951) (Remote host closed the connection)
[02:35:17] *** Quits: uniq__ (~uniq_@2605:a601:9190:3900:491f:dcb2:3d48:9951) (Client Quit)
[02:35:39] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:491f:dcb2:3d48:9951)
[02:36:31] <Guest93> In the end it might turn out that this was just an elaborate prank to get more ppl interested in compression to get more maintainers :)
[02:36:42] *** Parts: Sadale (~Sadale@user/sadale) (Leaving)
[02:36:53] <mroszko> backdoored openssh - just a prank bro
[02:37:22] <aaabbb> inb4 lzip author is responsible
[02:37:25] <Hunter> lets kill the traitors!!!
[02:37:34] <Hunter> lets rile up and start a rebillion!
[02:37:37] *** Joins: Guest46 (~Guest46@pool-173-76-234-218.bstnma.fios.verizon.net)
[02:37:43] <Hunter> lets create open source ww3
[02:37:49] *** Quits: Guest49 (~Guest49@88-114-248-56.elisa-laajakaista.fi) (Quit: Client closed)
[02:38:04] <Hunter> @A_dragon 
[02:38:07] <jess> Hunter would you like to calm down a little bit
[02:38:13] <mirppc> ^
[02:38:20] <jess> especially on the racial invective
[02:38:23] *** Quits: Guest89 (~Guest41@2a11:3:500::d101) (Ping timeout: 250 seconds)
[02:38:32] <mirppc> i would listen to a GLOP
[02:38:37] <aaabbb> racial?
[02:38:42] <Hunter>  but I thought we were gonna go in and start ww3
[02:38:51] <mroszko> are you like 10 years old
[02:38:52] <Hunter> aginst the traitor devs
[02:38:59] <Hunter> 17
[02:39:01] <aaabbb> Hunter: it's not a traitor, it was an attack
[02:39:07] <Hunter> an attack?
[02:39:14] <aaabbb> most likely by a nation state
[02:39:16] <mroszko> my dude, you are being cringe
[02:39:18] <mroszko> get off the internet
[02:39:19] <aaabbb> eg usa, israel, china, russia
[02:39:21] <Hunter> oh
[02:39:28] <Hunter> I thought some dev put it in
[02:39:29] <Hunter> sorry
[02:39:35] *** Joins: Your_Dog (sid616837@user/your-dog/x-2874336)
[02:39:43] <aaabbb> i mean it was a dev, but the dev was (most likely) a plant
[02:40:15] <uniq_> how do we know they were a fed?
[02:40:17] <aaabbb> who came in, took over a project from the previous overworked maintainer who was happy to pass the buck, then spend 2 years gaining good reputation before adding a backdoor
[02:40:36] <aaabbb> uniq_: it was an advanced supply chain attack. whatever it was came from a sophisticated apt
[02:40:53] <aaabbb> this does not show the marks of a crypto theft or ransomware scheme
[02:41:05] *** Quits: Guest53 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi) (Quit: Client closed)
[02:41:07] <Bahhumbug> Or someone had a gun put to their head of that of one of their children.
[02:41:30] <aaabbb> Bahhumbug: possibly but the perp appeared out of nowhere
[02:41:40] <uniq_> also how do we know theyre some master manipulator they could just be a guy who got bored one day and wanted to see what they could get away with
[02:41:41] <Bahhumbug> Doesn't change my statement.
[02:41:52] <Bahhumbug> Or that.
[02:42:02] <Bahhumbug> Or any number of other possible reasons.
[02:42:04] <aaabbb> uniq_: that's also possible, but everything is pointing to something a lot more sophisticated
[02:42:09] <aaabbb> we don't know for sure. read the gist
[02:42:14] <Bahhumbug> Bored people are bored and trying to make sense of this.
[02:42:26] <Hunter> man i hate trying to find torrents
[02:42:31] *** Quits: corn7890 (~corn7890@2601:441:4280:8ab0:529:cc85:341e:7b11) (Remote host closed the connection)
[02:42:35] <Hunter> does anyone want to play gta with my later
[02:42:37] <aaabbb> i'm just repeating security analyst opinions. i am not one myself
[02:42:46] <aaabbb> Hunter: you don't need a torrent for xz utils
[02:43:02] <uniq_> i think they wanted a torrent for gta
[02:43:07] <aaabbb> oh
[02:43:07] <Hunter> nah Ive been trying to play gta 4 all day
[02:43:22] <aaabbb> well this is not a channel (or network) for that. up your google-fu bruh
[02:43:22] <Hunter> but cant find a good torrent because the old version has been taken down
[02:43:29] <Tuvix> is there a more up to date mirror than git.tukaani.org? latest git master does not include af071ef which is referenced elsewhere
[02:45:50] <Guest93> regarding identifying this mysterious person, is there a graph that maybe shows a contributor who suddenly stopped coding for the project?
[02:46:02] *** Quits: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net) (Quit: Client closed)
[02:46:08] <aaabbb> Guest93: the original maintainer just got gradually busier
[02:46:45] <Yogurt> yo are torrents back in fashion?
[02:46:52] *** Quits: Guest56 (~Guest56@185.89.39.31) (Quit: Client closed)
[02:47:46] <Guest93> no, i mean one does not develop all the knowledge from nothing, i'm pretty sure that JiaT75 commited in that repository before to kinda "test the waters"
[02:48:11] <uniq_> any pirate born after 2006 doesnt know how to torrent
[02:48:13] <Your_Dog> what if he is a CCP spy
[02:48:20] <aaabbb> Guest93: sure, he slowly built up benign commits
[02:48:27] <aaabbb> Your_Dog: no way of attributing to a particular country yet
[02:48:43] *** Quits: Guest43636 (~Guest4363@p5b34e3b8.dip0.t-ipconnect.de) (Quit: Client closed)
[02:49:00] <Yogurt> I wonder if copilot can regurgitate xz
[02:49:18] <aaabbb> heh well it was probably trained on it
[02:49:42] <Yogurt> I guess you lose the commit data though
[02:49:45] <aaabbb> interesting possibility, poisoning github with intentional memory corruption vulns to train copilot to be more likely to insert vulnerabilities
[02:49:59] <uniq_> so what if hes a CCP spy who cares? what difference does it make if its a government agent who manipulated the maintainer for years or a guy who got bored one day?
[02:50:15] <Guest93> is there a site where one can see who commited to the repository in the past?
[02:50:20] <bdrewery> aaabbb: certainly
[02:50:40] <Yogurt> something like https://github.com/advisories/GHSA-q84m-rmw3-4382 ?
[02:50:41] *** Joins: chadmed_ (~james@2403-580a-80ed-0-4835-5a07-49e7-f115.ip6.aussiebb.net)
[02:50:42] <bt__> Tuvix: i don't think so, but the last commit on the gh repo was an update to SECURITY.MD by Jia
[02:50:56] <bt__> which seems to be missing from the tukaani.org 
[02:50:59] <Tuvix> bt__: exactly, but that is not present in a clone from the project site
[02:51:00] <Tuvix> yea
[02:51:29] <acidsys> the website states that the mirrors come with a delay
[02:53:12] <Your_Dog> crafty little rat
[02:54:09] <Guest93> https://github.com/tukaani-project/xz got disabled, is there a backup that still includes all the bad stuff?
[02:54:38] <bdrewery> Guest93: https://git.tukaani.org/?p=xz.git;a=summary
[02:54:39] <pabs3> git.tukaani.org is still up
[02:54:50] *** Joins: Guest94 (~Guest70@2600:1700:dad0:6d60:251b:689b:1114:f703)
[02:54:58] <Tuvix> the tarballs can also be accessed from their old github.com links at archive.org
[02:55:35] *** Quits: Guest14 (~Guest57@181.29.16.10) (Quit: Client closed)
[02:56:36] <ciro> aaabbb: what are you saying about lzip's author? I was thinking about publishing my tarballs in .lz too
[02:57:32] <aaabbb> ciro: it was a joke. he's written scathing (but really good) criticisms of xz and why it sucks so ba
[02:57:36] <aaabbb> bad
[02:57:48] <ciro> ah, yep, I know he hates xz
[02:58:30] <ciro> now I'm starting to think that he was (or is) right
[03:00:08] <aaabbb> he hates it for good reason, but tbh he hates it for the design flaws
[03:00:29] <aaabbb> problems in the very design itself that would not go away even if it was fully rewritten in rust with every line carefully audited
[03:02:39] *** Quits: Guest94 (~Guest70@2600:1700:dad0:6d60:251b:689b:1114:f703) (Ping timeout: 250 seconds)
[03:03:24] *** Joins: nullvalue (~0x0@user/nullvalue)
[03:03:36] <uniq_> oh fuck someone is totally gonna rewrite it in rust now
[03:04:05] <ciro> it's cheaper to just switch to lzip
[03:04:20] * nullvalue greets all
[03:04:28] <uniq_> true but i still need to extract old xz archives
[03:04:44] <uniq_> ill probobly use zstd for new stuff
[03:06:29] *** Joins: krushia (~krushia@h134-215-110-193.cntcnh.broadband.dynamic.tds.net)
[03:06:38] <aaabbb> why zstd?
[03:06:51] <uniq_> more common to find then lzip
[03:07:49] <jtbx> weird, my server has the latest backdoored version of xz installed and its sshd is taking much longer to log in to as detailed in the initial report, but I don't see any mention of liblzma in ldd or objdump
[03:08:17] <aaabbb> jtbx: try lddtree?
[03:08:25] <ciro> I've I've done a few quick and not very rigorous tests and it seems that lzip compresses more than CCP's xz
[03:08:43] <uniq_> isnt running ldd on comprimized binaries a bad idea?
[03:08:46] *** Joins: InPhase (~InPhase@openscad/inphase)
[03:08:48] <aaabbb> ciro: it may compress slightly more due to using lzma1 instead of lzma2, i think?
[03:09:00] <ciro> I have no idea
[03:09:04] <jtbx> aaabbb: haven't heard of that one before, will give it a try
[03:09:09] <aaabbb> uniq_: yes, but if the binary is already running as root....
[03:09:22] <uniq_> true
[03:09:24] <aaabbb> jtbx: lddtree will also check the dependencies of dependencies
[03:09:36] <jtbx> ah that makes sense...
[03:10:22] <uniq_> does lzip have multitthreading?
[03:10:27] <aaabbb> jtbx: btw if you still can't find liblzma, might be worth shutting down your server in case it is a new attack vector that is not yet known
[03:10:33] *** Joins: Guest15 (~Guest70@2600:1700:dad0:6d60:c578:e7a4:e5a1:3fc2)
[03:10:46] <JTL> jtbx: waht distro?
[03:11:02] <jtbx> aaabbb: oh okay I was considering that
[03:11:10] <jtbx> JTL: NixOS running nixpkgs unstable
[03:11:28] *** Joins: Affliction (affliction@idlerpg/player/affliction)
[03:11:44] <JTL> Affliction: \o
[03:11:50] <Affliction> o/
[03:11:51] <ciro> uniq_: its man page doesn't say anything about threads
[03:12:01] <Guest51> uniq_: plzip is the threaded impl
[03:12:24] *** Joins: Guest19 (~Guest19@218.34.249.5.rev.vodafone.pt)
[03:12:24] <JTL> jtbx: i.e, the Arch advisory implies the opeenssh backdoor doesn't work with their openssh package due to being compiled without lzma support. But it also implies that might not be the only way it could be exploited.
[03:12:31] *** Joins: \\ (~\0x5c@miaow/the-0x5c)
[03:12:33] *** Joins: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net)
[03:12:35] <JTL> jtbx: I wouldn't be surprised if NixOS unstable was similar
[03:12:45] *** Joins: Guest17 (~Guest17@108-238-20-83.lightspeed.sndgca.sbcglobal.net)
[03:13:45] *** Quits: Guest17 (~Guest17@108-238-20-83.lightspeed.sndgca.sbcglobal.net) (Client Quit)
[03:14:14] <jtbx> ah okay thanks. I'm pretty sure the NixOS package doesn't use lzma
[03:14:23] <pabs3> also according to the oss-sec writeup the backdoor is only activated on deb/rpm builds
[03:14:35] *** Quits: nullvalue (~0x0@user/nullvalue) (Ping timeout: 268 seconds)
[03:14:43] <jtbx> how would that even be detected?
[03:14:55] <JTL> jtbx: that being said. I'd be curious about the latter point
[03:14:57] <JTL> > However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.
[03:14:59] <JTL> (ref: https://archlinux.org/news/the-xz-package-has-been-backdoored/)
[03:15:27] <pabs3> jtbx: IIRC it checks for debian/rules or an RPM env var
[03:16:43] *** Quits: Guest51 (~Guest61@host-194-22.calaw27p.losangeles.ca.us.clients.pavlovmedia.net) (Quit: Client closed)
[03:16:45] <ciro> btw, I don't know it this has been posted yet, but... well, take a look at it: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[03:17:17] <ciro> *it/if
[03:17:22] <jtbx> JTL: same here, putting the backdoor in sshd through lzma is pretty nasty
[03:18:23] *** Joins: leapfog (~leapfog@p57bcf7ac.dip0.t-ipconnect.de)
[03:18:30] <jtbx> pabs3: that's very smart, the way the whole "operation" was executed was just impressive
[03:18:55] <ciro> this is a state actor
[03:19:00] <jtbx> how do you know?
[03:19:57] <krushia> its a miracle this was discovered imho. very well hidden.
[03:20:28] <ciro> the time taken to introduce the backdoor, at least 3 years, that patience and premeditation indicates a plan and a long-term goal, something rare in a lone hacker or even in a hacking group not backed by a state or a powerful actor
[03:20:54] *** Quits: leapfog_ (~leapfog@p5080faa9.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
[03:21:17] <bt__> it probably wouldn't have been found if they didn't fuck it up
[03:21:25] <uniq_> krushia: there are probobly a million other backdoors in your computer right now that were just hidden better
[03:22:26] <bt__> took one person who noticed that sshd was too slow and valgrind errors
[03:23:24] <uniq_> i feel like ive learned enough today to make a backdoor that wont be found for decades
[03:23:37] <bt__> yep don't fuck it up
[03:24:24] <uniq_> im gonna mine so much crypto
[03:24:43] <pabs3> jtbx: not just sshd through lzma, but sshd through lzma through systemd
[03:24:54] <jtbx> ouch, yeah
[03:25:14] <jtbx> weird thing is that I'm experiencing the symptoms Andres described but I can't find any linking to liblzma
[03:25:37] *** Quits: Guest15 (~Guest70@2600:1700:dad0:6d60:c578:e7a4:e5a1:3fc2) (Ping timeout: 250 seconds)
[03:25:45] <pabs3> one hilarious thing was the attacker while making the attack more stealthy got a legitimate bug in GCC fixed :)
[03:26:12] <pabs3> which distro?
[03:26:31] <jtbx> NixOS using nixpkgs unstable
[03:27:37] <pabs3> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
[03:29:00] <jtbx> segfault? must have been some strange shit going on in those binary blobs
[03:29:38] <StefanCristian> https://bugs.gentoo.org/925415 this is slightly related
[03:30:26] <StefanCristian> with the names and versions, rather
[03:30:55] *** Quits: Guest93 (~Guest41@p508b71ad.dip0.t-ipconnect.de) (Quit: Client closed)
[03:31:59] <StefanCristian> it's specified indeed in the gcc.gnu ticket above
[03:32:45] <StefanCristian> but this is something else than current security topic
[03:32:54] <StefanCristian> sam will explain most probably in a different post
[03:34:20] *** Joins: FenderQ (~fenderq@user/fenderq)
[03:41:30] *** Joins: ficus (fc@207.6.131.77)
[03:48:24] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:491f:dcb2:3d48:9951) (Quit: nyaa~)
[03:48:49] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:c42e:e0cd:8e72:b1fb)
[03:53:50] *** Quits: panorain (~panorain@user/panorain) (Quit: Konversation terminated!)
[04:01:24] *** Quits: ori (~ori@wikimedia/ATDT) (Quit: ori)
[04:01:59] *** Joins: ori (~ori@wikimedia/ATDT)
[04:07:40] *** Joins: ThePotato (~ThePotato@63.135.76.182)
[04:12:01] *** Quits: Guest48 (~Guest69@2a09:bac2:383d:d2d::150:4) (Quit: Client closed)
[04:13:16] *** Quits: mathis123325234 (~mathis123@2605:a601:a9b2:e300:a01b:89c0:d32c:ad6f) (Ping timeout: 250 seconds)
[04:14:41] *** Parts: Yogurt (~Yogurt@158.51.82.203) (Textual IRC Client: www.textualapp.com)
[04:16:21] <krushia> fyi, libarchive was backdoored as well. the single commit there from 2021 allows filenames in tarballs to inject terminal escapes
[04:18:08] *** Joins: ponycat (sid524992@smol/hors)
[04:18:25] *** Quits: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net) (Quit: Client closed)
[04:18:37] <Your_Dog> damn
[04:18:46] <aaabbb> krushia: holy shit
[04:18:55] <aaabbb> what is libarchive used by?
[04:19:42] <JTL> bsdtar I think?
[04:19:45] <JTL> AAAAAAAAA
[04:20:08] *** Joins: ntk (ntk@rie.sdf.org)
[04:20:25] <ntk> what'd I miss?
[04:21:02] <aaabbb> JTL: it looks like gnome uses it
[04:21:05] <aaabbb> so all gnome systems may be vulnerable?
[04:21:17] <ntk> no.
[04:22:03] <aaabbb> not libarchive13?
[04:22:07] <aaabbb> in ebian
[04:23:46] *** Joins: jwerner (~jwerner@104.132.210.70)
[04:24:02] <aaabbb> oh terminal escapes
[04:24:17] <aaabbb> so it would only be what... unar or something? so things like ark which are gui would not be vulnerable
[04:24:31] *** Joins: abrik1 (dc8af6e570@2a03:6000:1812:100::1340)
[04:26:54] <krushia> depends how they handle i/o. the commit specifically targets an executable, /usr/bin/bsdtar
[04:27:27] <aaabbb> is it a backdoor (malicious code) or bugdoor (intentional security vulnerability)?
[04:28:22] <ntk> unless you're running a bleeding edge RPM or .deb based distro on x86_64 you should be unaffected by the disclosed backdoor.
[04:28:27] <krushia> it could allow arbitrary shell code to execute if used in a script too
[04:29:35] <ntk> no stable server/desktop distros have xz 5.6, it was only released last month
[04:30:27] *** Joins: Guest80 (~Guest80@2a02-8434-66e4-6f01-a00e-4b6f-d92c-3f63.rev.sfr.net)
[04:30:30] <ntk> and if you run bleeding edge open source you are asking for this sort of thing.
[04:31:34] <aaabbb> ntk: 2021 is not bleeding edge
[04:32:07] <aaabbb> ntk: and arguably, the opposite is true too. you're more likely to have (innocent) security vulnerabilities by using older versions, since not everything is backported right
[04:33:01] <Tuvix> libarchive's f27c173 didn't change the safe_printf call for the entry but the error string and strerror calls
[04:33:13] <Tuvix> https://github.com/libarchive/libarchive/pull/1609/files
[04:33:23] *** Joins: Guest53 (~Guest53@203-12-13-81.dyn.launtel.net.au)
[04:33:55] *** Quits: Guest80 (~Guest80@2a02-8434-66e4-6f01-a00e-4b6f-d92c-3f63.rev.sfr.net) (Client Quit)
[04:34:08] <ntk> aaabbb: what CVE are you referring to that dates to 2021?
[04:34:10] <aaabbb> krushia: did you discover this yourself or is it widely known by now?
[04:34:16] <aaabbb> ntk: < krushia> fyi, libarchive was backdoored as well. the single commit there from 2021 allows filenames in tarballs to inject terminal escapes
[04:34:33] <krushia> its known, they reverted it
[04:34:36] <ntk> hm
[04:34:46] <aaabbb> krushia: just now? or it was discovered earlier?
[04:34:54] <Tuvix> it does not do what the claimant here claims it does
[04:35:17] <aaabbb> what does it do? i got 0 sleep last night and am in no mood to read code right now
[04:37:30] *** Quits: mxz (~mxz@user/mxz) (Ping timeout: 268 seconds)
[04:38:15] <ntk> yeah, that's not a CVE and it's not what everyone's on about right now
[04:39:21] <aaabbb> ntk: i know, i was talking about krushia's statement
[04:39:28] <ntk> i see
[04:40:41] <ntk> hopefully everyone generating xzips will move to lzip/bz2/gz and that will be the end of it. use xz embedded for decompression
[04:41:10] <aaabbb> ^
[04:41:15] <aaabbb> there's a bzip3 that is underrated
[04:41:32] <ntk> we really don't need more formats rn
[04:41:36] <aaabbb> not very well designed code (segaults with certain flag combos lol) but great algorithm, much faster and uses arithmetic coding
[04:41:45] <aaabbb> ntk: but moar standards = moar gooder
[04:41:54] *** Joins: Guest14 (~Guest14@70-226-117-142.lightspeed.austtx.sbcglobal.net)
[04:41:54] <ntk> last thing we need is not very well designed code in this space
[04:42:14] <aaabbb> the algorithm is what's good haha not the code
[04:43:14] *** Quits: mroszko (~mroszko@2600:4041:539c:f700:9c69:f85b:71c3:dc06) (Quit: Client closed)
[04:46:12] *** Quits: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
[04:50:36] *** Joins: Square2 (~Square@user/square)
[04:55:40] *** Joins: Guest94 (~Guest94@99-161-81-51.lightspeed.stlsmo.sbcglobal.net)
[04:56:22] <krushia> Tuvix: the error string contains the filename
[04:57:05] *** Quits: Guest14 (~Guest14@70-226-117-142.lightspeed.austtx.sbcglobal.net) (Quit: Client closed)
[04:57:12] <ntk> has "lasse collin" made any comment, assuming optimistically he's not in concert with "jia tan"?
[04:57:29] <Tuvix> a shell that is calling eval or similar on the stderr stream is just broken
[04:57:37] *** Quits: Mooncairn (~mooncairn@user/mooncairn) (Quit: Leaving)
[04:59:37] <Tuvix> i don't think that part actually contains the filename either since it was printed a line earlier
[05:00:22] <Tuvix> if it did that would mean it would be printed twice on the same line which would be quite silly
[05:00:47] <Tuvix> this seems to be the reason why abuse is mentioned as so unlikely in the fix: https://github.com/libarchive/libarchive/pull/2101#issuecomment-2027899455
[05:01:36] <aaabbb> ntk: CISA is still trying to get in contact with him i think
[05:01:53] *** Joins: Guest26 (~Guest70@2600:1700:dad0:6d60:c578:e7a4:e5a1:3fc2)
[05:02:22] <aaabbb> https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[05:02:24] <aaabbb> talks about libarhive ^
[05:02:55] <ficus> if he was burnt out and taking time off before...
[05:03:06] *** Quits: Guest27 (~Guest61@136.158.1.98) (Ping timeout: 250 seconds)
[05:04:50] *** Quits: Guest94 (~Guest94@99-161-81-51.lightspeed.stlsmo.sbcglobal.net) (Ping timeout: 250 seconds)
[05:08:58] <ficus> https://xkcd.com/2347/
[05:10:58] <Tuvix> krushia: let me be more blunt. if you know more about this issue than you have explained here you should tell it to THAT project because your claim that it can be used to inject shell code is far more serious than the discussion on the libarchive issue
[05:11:24] <Tuvix> if you just heard this elsewhere i would advise caution on spreading that information without actual confirmation. note that the filename print still uses the safe_fprintf call
[05:18:21] *** Joins: Guest51 (~Guest51@2600:4040:2acb:1400::100e)
[05:19:08] <ntk> yeah that's maybe not a great commit and can be assumed malicious but executing random stderr output would be the bigger issue there.
[05:19:49] <Tuvix> digging only briefly into libarchive source that would require the `struct archive` to which the archive_error_string() passes a poitner to would have to contain a malicious error member and on a casual skimming that is controled by libarchive itself and not the archived file contents
[05:20:08] <Tuvix> but indeed if a shell author executes ANY untrusted input that should be a sign the shell coder doesn't really know what they're doing
[05:20:46] <ntk> i doubt most programmers dumb enough to do that would even be redirecting stderr in the first place
[05:21:32] <ntk> without misunderestimating the shitty and compromised bodies of open source code out there to be sure
[05:24:09] *** Quits: Guest51 (~Guest51@2600:4040:2acb:1400::100e) (Quit: Client closed)
[05:24:19] <Tuvix> looks like the recent commit also changes from errno to archive_errno using that same struct so it's not a revert so much as cleaning up the original contribution
[05:24:40] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:c42e:e0cd:8e72:b1fb) (Quit: nyaa~)
[05:31:19] *** Quits: Guest8 (~Guest41@a89-152-157-153.cpe.netcabo.pt) (Quit: Client closed)
[05:32:34] *** Quits: Guest26 (~Guest70@2600:1700:dad0:6d60:c578:e7a4:e5a1:3fc2) (Ping timeout: 250 seconds)
[05:34:19] *** Quits: ntk (ntk@rie.sdf.org) (Quit: quit)
[05:41:12] *** Joins: ryzenda (~ryzenda@pool-173-75-43-112.pitbpa.fios.verizon.net)
[05:41:13] *** Joins: asurati (~asurati@103.249.233.183)
[05:41:21] *** Joins: randyr (~randyr@154.57.12.44)
[05:42:13] <randyr> where all my chink spies at
[05:42:41] <ryzenda> lol rip! i'm 12 hours late, but 10 minutes ago I saw https://youtu.be/jqjtNDtbDNI and then quickly found out Archlinux is safe and reading through https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2 I see GitHub repo is disabled
[05:43:20] *** Quits: bortolotto (~bortolott@177.133.255.225) (Ping timeout: 252 seconds)
[05:44:21] <Bahhumbug> randyr: Please check the racial invective at the door when you enter our network.
[05:45:08] *** Quits: Guest53 (~Guest53@203-12-13-81.dyn.launtel.net.au) (Ping timeout: 250 seconds)
[05:45:27] *** Joins: bortolotto (~bortolott@191.249.108.116)
[05:45:33] *** Quits: femto113 (~femto113@198.244.100.102) (Quit: Client closed)
[05:48:07] <randyr> would me saying "amerilard spies" prompt the same response from you though?
[05:48:39] <Bahhumbug> Now that I am aware of it, yes.
[05:48:49] <Bahhumbug> This isn't a debate.  Just stop it.
[05:50:47] <randyr> my comment did not point to a race though it pointed to a state actor. also "Now that I am aware of it" means that if the word was "amerilard" at the first place you wouldnt budge
[05:50:54] <randyr> anyway have fun
[05:50:57] *** Parts: randyr (~randyr@154.57.12.44) (WeeChat 2.8)
[05:57:34] *** Parts: tristan957 (8a107acde4@user/tristan957) ()
[05:59:34] *** Quits: ciro (~ciro@user/ciro) (Quit: Konversation terminated!)
[06:09:59] *** Joins: ciro (~ciro@user/ciro)
[06:16:20] *** Joins: asafniv (~asafniv@46.121.34.188)
[06:19:06] *** Joins: PA17532 (~PA17532@067-011-240-216.res.spectrum.com)
[06:19:44] *** Quits: asafniv (~asafniv@46.121.34.188) (Client Quit)
[06:20:46] *** Joins: Werner (werner@armbian/staff/Werner)
[06:28:56] *** Quits: asurati (~asurati@103.249.233.183) (Remote host closed the connection)
[06:30:15] <ryzenda> Reading the faq I see "Lasse regularly has internet breaks and is on one at the moment, started before this all kicked off. We believe CISA may be trying to get in contact with him." and I remember seeing something about CISA not too long ago, first time I ever noticed or learned about CISA too
[06:30:35] <ryzenda> and I found what I saw, which was https://youtu.be/l8NsfTEjD6c
[06:32:04] <ryzenda> lol, tinfoil, but maybe CISA is retaliating by deploying this and utilizing some sort of vector of attack, but that's just my crazy speculation lol
[06:39:03] <ciro> what I find incredible is that such an important package does not have enough contributors from the major technology companies
[06:41:43] <ficus> was Jia active here recently?
[06:42:53] *** Joins: particles (~particles@2600:1700:83b0:e1b1:30ae:9c0f:d5d4:eade)
[06:43:21] *** Joins: mxz (~mxz@user/mxz)
[06:50:48] <ryzenda> ciro, I am noticing that too, also the Microsoft locking the repo, but I see a mirror, but one comment in https://old.reddit.com/r/github/comments/1br5x2e/mixed_feelings_after_github_took_down_xzutils/ says
[06:50:52] <ryzenda> "Github actively stopped a patch from being delivered in useful time to the whole world, while completely blocking knowledge share from developers abroad."
[06:52:13] <ryzenda> lol Microsoft doing Microsoft things, and I was saying elsewhere, 25+ years ago I exited all the Microsoft shit and 100% Linux for decades, but here we are, and they hijack everything with their ftd failure to deliver infinite money glitch financial terrorism hostagings or however to explain 
[06:52:50] <abby> but there was no patch being delivered via github....
[06:53:07] <ryzenda> or however to explain: https://youtu.be/FID0BLkZXuY?t=2058s 34:24 "Markets are efficient because of active managers setting the prices of securities, firms like Citadel, firms like Fidel.....lity (Fidelity) [...] trying to drive the value of companies towards where we think they should be valued."
[06:53:45] <ryzenda> public company Microsoft is valued not because of supply and demand, nope, never was, it's because of the financial institutions and market makers and hedgefunds that control everything!
[06:55:17] <ryzenda> abby, I don't know what happened, cuz I started digging 12 hours late
[06:56:05] <abby> then i suggest reading the gist in the topic and the oss-security mailing list post linked therein
[06:56:07] *** Joins: asurati (~asurati@103.249.233.183)
[06:56:36] <abby> the current fix is simply "downgrade to an unaffected version"
[06:56:57] <ryzenda> but, what I do know, is, if there is any propaganda lying by omission and creatine fake false narratives, to hijack and exploit far more egregiously where this vulnerability exploit is possibly a red herring to a much larger attack vector, then......  I'm prepared to avoid that too!
[06:57:18] *** Quits: kennethm (~kennethm@193.90.196.121) (Quit: Client closed)
[06:57:47] *** Quits: Garen (~Garen@50.52.127.145) (Ping timeout: 268 seconds)
[06:59:55] *** Quits: asurati (~asurati@103.249.233.183) (Remote host closed the connection)
[07:00:24] *** Quits: woo2_ (~paul@136.25.84.123) (Quit: Lost terminal)
[07:00:25] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Read error: Connection reset by peer)
[07:00:45] *** Quits: gnom (~gnom@user/mong) (Quit: Leaving)
[07:01:16] *** Joins: Guest5 (~Guest91@host-194-22.calaw27p.losangeles.ca.us.clients.pavlovmedia.net)
[07:08:36] <ciro> sam_: Jia Tan's OpenPGP key is still in portage, are you guys going to remove it? sec-keys/openpgp-keys-jiatan
[07:09:44] <ryzenda> hmm what's this? legit or deception? https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5005971#gistcomment-5005971 / https://news.ycombinator.com/item?id=39865810#39866275
[07:11:44] <aaabbb> ciro: maybe ask in #gentoo
[07:12:22] *** Quits: PA17532 (~PA17532@067-011-240-216.res.spectrum.com) (Quit: Client closed)
[07:14:30] <ryzenda> hmm, what's it called when a guilty person waits 2+ years before going rogue and sabotaging trust and whatnot? Maybe that's what happened, and maybe with throwaway identity? Is that maybe characterization of what has happened? I'm just guessing. https://lwn.net/Articles/967216/ mentions it's a pseudonym
[07:14:30] <ciro> ryzenda: sam_ was the first follower of tukaani-project, so it makes sense that the fucking spy followed sam_: https://web.archive.org/web/20240330001532/https://github.com/orgs/tukaani-project/followers
[07:15:16] <ryzenda> > "shall all his past commits be analyzed?" YES! Lol, of course!
[07:18:02] <ryzenda> I'm not saying that it's funded by infinite money glitch hedgefund and market maker financial terrorists, but even if it's not, if it is funded by infinite stolen moneys, then the people need to defend and survive that, cuz even Kenneth Cordelle Griffin of Citadel Securities lying under oath and consistently for 3+ years now, and because his company has SEC and other regulatory exemptions that no other financial institution 
[07:18:02] <ryzenda> is exempt from reporting, that any other institution to do what Citadel Securities does would be instant red flags everywhere all at once, but since no reporting necessary, there are no red flags yet, yet... keyword, yet, lol, but anyway, I'm not saying this situation is funded by any of the tens to hundreds of thousands of ftd failure to deliver infinite money thieves, but I would not be surprised if it is
[07:19:25] *** Joins: oldfashionedcow (~Cow@user/oldfashionedcow)
[07:19:49] <ryzenda> correction: ten to hundreds of thousands of hedgefunds, each which has multiple staff/employees, so I have no idea how many individual people all over the world there are
[07:21:15] <ryzenda> lol  maybe it's another Satoshi Nakamoto phenomena, but in this case, malicious intention ;(
[07:23:04] <Guest5> i also dislike citadel but they have nothing to do w/ this - best to stay on topic instead of digressing about details you learned during the $gme fiasco
[07:23:05] *** Joins: larry (~larry@2a02:810d:ae3f:ed2b:872c:56e4:cf90:3024)
[07:25:15] *** Quits: ciro (~ciro@user/ciro) (Quit: Konversation terminated!)
[07:29:33] *** Joins: konimex (konimex@artix/konimex)
[07:30:52] *** Quits: Guest50 (~Guest50@164.250.218.133.dy.bbexcite.jp) (Quit: Client closed)
[07:36:38] *** Quits: larry (~larry@2a02:810d:ae3f:ed2b:872c:56e4:cf90:3024) (Remote host closed the connection)
[07:39:09] *** Joins: Guest28 (~Guest28@103.211.17.244)
[07:40:10] *** Joins: Guest71 (~Guest71@83.139.24.99)
[07:40:25] <ryzenda> Guest5, sure, I agree, however, in terms of a few solicitations to pass on maintaining of the repo, I personally would be skeptical and like go for a walk take a breather, relax, figure out what's going on, don't make any rushed decisions, and try to resolve the matter when calm and clearminded, and also if 100% trust is lost, then the project will be forked
[07:40:46] <oldfashionedcow> Indeed. It is best not to speculate at this time and to simply remain calm.
[07:40:59] <oldfashionedcow> And make sure to look at the FAQ in the topic if you have not yet as it clears a lot up.
[07:41:19] <ryzenda> yep, I read, and reading more searching and whatnot
[07:50:18] *** Joins: Guest92 (~Guest70@116.88.182.199)
[07:51:40] <ryzenda> mm I see that https://github.com/Larhzu and https://github.com/JiaT75 are both suspended. 
[07:53:56] *** Quits: rolf (~rolf@188.89.99.81) (Ping timeout: 255 seconds)
[07:55:01] <oldfashionedcow> They are, and the repository is currently closed by github.
[07:56:02] <ryzenda> also looking for cache I see January 2023 "Larhzu doesn't have any public repositories yet." https://cc.bingj.com/cache.aspx?q=https%3a%2f%2fgithub.com%2fLarhzu%3ftab%3drepositories+cache&d=4598312620738571&mkt=en-US&setlang=en-US&w=hcSJFx57GyorEmUGBFcxwHJLkYnM8YQs 
[07:56:19] <ryzenda> I don't know the history of when the GitHub repo was created, but thought i'd mention that
[07:56:53] <abby> probably just means lasse didn't use github much outside of the org xz was in
[07:56:57] <oldfashionedcow> Gentoo bug 928134 (https://bugs.gentoo.org/928134) has more details
[07:57:03] <oldfashionedcow> "Github has disabled the XZ repository entirely as of 1:29 AM UTC"
[07:58:50] *** Joins: Guest13 (~Guest13@2001:44c8:4111:2c93:b153:c68e:6ff4:de9f)
[07:59:26] *** Joins: radek (~igloo@109-81-89-137.rct.o2.cz)
[07:59:42] <ponycat> huh
[07:59:47] <Guest13> Why?
[08:00:11] <Paistin> good evidence sharing was being done in the comments
[08:00:18] <Paistin> microsoft doesn't like that
[08:00:21] <ryzenda> hmm, I faintly remember before XZ existed, and how it was an amazing improvement on speed for compression/decompression, and it had substantial influence to migrate from bzip2, iirc.
[08:00:29] *** Quits: Guest13 (~Guest13@2001:44c8:4111:2c93:b153:c68e:6ff4:de9f) (Client Quit)
[08:00:47] <ryzenda> Also reading https://nongnu.org/lzip/xz_inadequate.html I see "The fact that the xz reference tool (xz-utils) has had more bugs than bzip2 and lzip combined is mainly a consequence of the complexity and bad design of the xz format."
[08:01:22] *** Joins: Guest13 (~Guest13@49.230.235.93)
[08:01:44] *** Joins: Guest15 (~Guest34@ecs-119-8-242-171.compute.hwclouds-dns.com)
[08:01:46] *** Joins: satanist (~satanist@shell.bureaucracy.de)
[08:01:58] <ryzenda> Paistin, haha, yeah, blah, whatever, I've been using IRC for 84 years, so I'm glad it still exists!
[08:02:11] <Paistin> tru!
[08:03:08] *** Quits: Guest13 (~Guest13@49.230.235.93) (Client Quit)
[08:03:11] <oldfashionedcow> Lets please not speculate as it is not helpful. It is likely that Microsoft disabled the repositories to stop the spread of this, and incase the software is anymore backdoored.
[08:03:22] *** Joins: Guest62 (~Guest62@nmal-25-b2-v4wan-166401-cust115.vm24.cable.virginm.net)
[08:03:53] <Larhzu> Hello!
[08:04:12] <Guest5> good morning!
[08:04:12] <Larhzu> I have read the openwall.com post.
[08:04:23] *** Quits: radek (~igloo@109-81-89-137.rct.o2.cz) (Ping timeout: 260 seconds)
[08:05:41] <Larhzu> I have been on holiday and happened to check email. I've spent time with friends and they are at my place at the moment too but I thought I have to spend some time on this since I happened to check the emails.
[08:06:15] *** Joins: mathis123325234 (~mathis123@2605:a601:a9b2:e300:9c06:1299:243b:cb8b)
[08:06:35] <Larhzu> sam_, jess: Thanks to you and perhaps others you have kept the channel sane. I didn't read the backlog for now.
[08:07:25] <Larhzu> I'm really tired but I suppose I should do something right now.
[08:07:56] *** Joins: fireonlive (fire@user/fireonlive)
[08:07:58] <Guest5> Thanks for taking the time to sort this out despite your holiday w/ friends
[08:07:59] <Larhzu> Longer investigation by me likely can only start on Monday or Tuesday.
[08:08:07] <Larhzu> This sounded too serious to ignore.
[08:08:23] <supakeen> Larhzu: Most of it seems to have been handled by downstreams at this point so just a statement that you are on holidays or such is probably enough in my opinion.
[08:08:41] <Larhzu> No need to make a new release?
[08:08:59] <Larhzu> I'm too tired though at the moment to make a release, risk of errors is too high.
[08:09:08] <hsiangkao> Larhzu: hi! you should reply to the kernel mailing list too, honestly...
[08:09:14] <pabs3> GitHub has suspended things, so a release there wouldn't be possible too
[08:09:15] *** Joins: Guest11 (~Guest19@ti0027a400-0966.bb.online.no)
[08:09:20] <abby> Larhzu: most/all of us distros have been downgrading to 5.4.x
[08:09:23] <Larhzu> hsiangkao: Yes, that email seemed more important than most.
[08:09:23] <hsiangkao> very sorry to hear such news
[08:09:26] <hsiangkao> yeah
[08:09:38] *** Joins: gamer191 (~gamer191@124.168.216.118)
[08:09:40] <supakeen> I don't think you should do a new release nor can you, just a place with a little statement that you are aware and away for the weekend is enough for at least me :)
[08:10:00] <hsiangkao> otherwise the project may not be trusted
[08:10:01] <Larhzu> Downgrade is fine as those releases are still fine in terms of other kinds of bugs than this.
[08:10:02] <supakeen> That can be an email somewhere public as well, of course.
[08:10:18] *** Joins: JAA (~JAA@user/jaa)
[08:10:43] <hsiangkao> yes, the new commits are need to be audited. I just heard the news on my phone, so check the IRC...
[08:10:47] <oldfashionedcow> Hey Larhzu
[08:10:52] <oldfashionedcow> Nice one finding the vunerability, thanks
[08:10:53] <Larhzu> GitHub Pages is down at least (xz.tukaani.org) so that helps, I guess.
[08:11:03] <oldfashionedcow> Larhzu: Github has disabled a lot of repos - "Github has disabled the XZ repository entirely as of 1:29 AM UTC"     
[08:11:10] <oldfashionedcow> Gentoo bug 928134 (https://bugs.gentoo.org/928134) has more details
[08:11:15] <supakeen> Yea, the fallout has been mostly handled and you'll probably need time to regain any control.
[08:11:21] *** Joins: asldkasdfasdfoi (~asldkasdf@178.165.165.191.wireless.dyn.drei.com)
[08:11:58] <Larhzu> I really like that people found this channel instead of filling my email inbox more. :-)
[08:12:16] *** Joins: larry (~larry@ip4d148e9b.dynamic.kabel-deutschland.de)
[08:12:21] <supakeen> I'd suggest you skip the backlog which is full of wild stuff, sam_ made a nice summary which is in the /topic.
[08:12:27] <Larhzu> Jia first contacted me in early 2022.
[08:12:30] *** Joins: Barto (~barto@user/barto)
[08:12:31] <ryzenda> haha, yay! IRC for the win! I used IRC way before email so yeah. 
[08:12:35] <Tuvix> at some point reaching out to GitHub about the repo being pulled might be good, but by all means prioritize your own needs after a short statement that you're around, on holiday, and will begin to evaluate the situation more fully at <date of your choosing>
[08:12:48] <Guest72> Larhzu: hey, more than a new release, I think it would be useful to have a timeline of events from your point of view -- to understand where Jia came from and how they managed to get this far, maybe some of the private communication
[08:12:53] <sauce> you should go have fun with your friends instead of wading into this shitstorm
[08:12:56] <gamer191> I just joined. I assume Larhzu is aware of the situation. If you're interested, here's a nice summary, which I didn't write: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[08:13:01] <Tuvix> no point in making commitments that tax you too far, especially on holiday
[08:13:20] <hsiangkao> :) anyway, that is a very bad news, he is just an anonymous person on the internet. who knows..
[08:13:49] <Larhzu> gamer191: Thanks, I need to collect the links. :)
[08:14:17] <Larhzu> I should write a timeline, yes, what I remember at least.
[08:14:29] <supakeen> Sure, but after your holidays.
[08:14:41] <hsiangkao> maybe a formal email to the kernel mailing list too
[08:15:06] <Larhzu> The start wasn't the easiest as I'm so picky about what I accept to be committed, including good commit messages etc.
[08:15:16] <hsiangkao> https://lore.kernel.org/all/14dc0bca-e5c7-40a4-88ae-b08b3680058c@incomsystems.biz/
[08:15:26] <Larhzu> hsiangkao: Kernel email I will reply.
[08:15:36] <hsiangkao> yeah
[08:15:57] *** Joins: pera (~pera@user/pera)
[08:15:59] <supakeen> Larhzu: FWIW how these things were introduced in the repository would be something I think most of us would miss in any reviews anyhow.
[08:16:22] <Larhzu> hsiangkao: This is the last one I've received so I thought replying to this: https://lore.kernel.org/all/20240329195602.382cb1c99bb70e3d8c6093ae@linux-foundation.org/
[08:16:32] <hsiangkao> I even don't know if his real name is that
[08:16:58] <gamer191> Larhzu how accurate is that timeline? I think you should reach out to the Mastodon user who wrote it (https://social.coop/@eb), but use a different mastodon instance (such as mastodon.social) so you don't have to wait for your account to be accepted
[08:17:12] *** Joins: leme (leME@has.a.kernel.breakpoint.cc)
[08:17:23] <hsiangkao> Yes, I think reply to akpm and Kees Cook
[08:17:38] <hsiangkao> Kees Cook is a security person
[08:17:55] <Larhzu> I don't have Mastodon account (or Twitter or Facebook or Instagram or Whatsapp). I had a GitHub account because I got convinced that it was a good idea.
[08:18:03] <Larhzu> gamer191: I have to read later.
[08:18:28] <supakeen> Yea, just go with the sign of life on lkml and that is sufficient.
[08:18:46] <gamer191> Larhzu if I'm still online I can screenshot your messages and post them
[08:18:53] *** Joins: genr8eofl_ (~genr8eofl@user/genr8eofl)
[08:18:58] *** Quits: genr8eofl (~genr8eofl@user/genr8eofl) (Read error: Connection reset by peer)
[08:19:59] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[08:21:41] <Larhzu> gamer191: Not today
[08:21:46] <gamer191> > I have to read later.
[08:21:46] <gamer191> Fair enough, I'm sure this situation is very stressful for you :(
[08:21:47] <gamer191> Feel free to ask any questions on this IRC, the internet has researched this extremely thoroughly
[08:21:49] *** Quits: pera (~pera@user/pera) (Ping timeout: 240 seconds)
[08:22:01] *** Joins: Irenes (~ireneista@user/ireneista)
[08:22:20] <Larhzu> I will be more active on Monday or Tuesday, I need to have slept well.
[08:23:06] <Larhzu> It's a curious thing how most things I have reviewed at least to some extent.
[08:23:13] *** Joins: yan12125 (~yen@user/yan12125)
[08:23:24] <supakeen> Don't feel too obligated.
[08:24:05] *** Joins: pipedrea1 (~pipedream@ns1.aims.ac.za)
[08:24:09] <Larhzu> What I didn't: .github/, some of tests got only a light review, the recent (past few months) test files didn't get any review except the RISC-V test files which were updated a few times to catch more corner cases.
[08:24:19] <Larhzu> I did check that the updates improved corner case catching.
[08:24:22] <supakeen> Like I said this 'was done' by someone well familiar with downstream and upstream review processes. Hiding the object file in some corrupted archives that are part of test cases and then hiding the autoconf only in the release tarball is interesting.
[08:24:42] <hsiangkao> yes, don't be so stressful :) just making folks think this project can still be trusted.
[08:24:53] <Larhzu> Yes, it's interesting. But it has to have taken time to find out thw holes which I don't review.
[08:24:54] <supakeen> If I were to review anything like that I'd probably only say 'Id like to not commit the artifacts but only the script that generates them' and then approve.
[08:25:48] <gamer191> My understanding is that part of it was hidden in the test files, and part of it was manually injected into the release tarballs
[08:26:05] <Larhzu> The old test files by me were mostly created in a hexeditor. The tests/files/README says that. But the recent few files were from Jia and I know some were created with a generator
[08:26:16] *** Joins: Guest40 (~Guest40@240f:77:357e:1:f5bc:f6f9:9edd:786f)
[08:26:19] <supakeen> The object file was in the test files, obfuscated, the actual inclusion of that file was in the autoconf scripts which are only in release tarballs.
[08:26:33] <Larhzu> I wasn't happy about it because I wanted to have the source code that is the preferred form for modifications.
[08:26:51] *** pipedrea1 is now known as pipedream
[08:27:12] <Guest72> BTW, I feel this needs to be said: this was extremely sophisticated on several levels (technical, social). it was easy to miss. we ALL missed it. this is our collective responsibility
[08:27:23] *** Joins: x544B (~x544B@84.254.40.50)
[08:27:34] <Bahhumbug> ^
[08:28:08] <gamer191> The problematic tests were added in commit cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0, and updated in commit 6e636819e8f070330d835fce46289a3ff72a7b89 (apparently the first version of the backdoor caused some issue with valgrind)
[08:28:19] *** Quits: mxz (~mxz@user/mxz) (Ping timeout: 252 seconds)
[08:28:28] <supakeen> Yep, this 'should' have been caught by distros that have a review process; but again, it was set up in such a way that that is unlikely.
[08:28:48] <Larhzu> The last things I didn't review were the final ifunc changes.
[08:29:18] <Larhzu> It's surprisingly little that has gone into the Git repo without any kind of review by me. But these changes were such.
[08:29:41] <Larhzu> And unlike the openwall.com post says, the test files are used by test_files.sh via a glob.
[08:30:10] <supakeen> If a contributor that has consistently done good things makes a PR to my repository I'll sometimes, especially when I have little time, merge it with only a cursory look.
[08:30:21] <supakeen> So nothing out of the ordinary :)
[08:30:43] <Larhzu> Let's not dwell on the wrong things, I find it curious that the biggest holes in my process were big enough.
[08:31:53] <Larhzu> While other C code changes by Jia should be reviewed, I'm slightly less worried as most things (which *isn't* all) I have look at somewhat closely at least.
[08:32:08] <gamer191> Apparently the ifunc changes also did something, according to the boehs post
[08:32:08] <gamer191> There's also speculation that "Hans Jansen" was Jia's alt
[08:33:22] <Larhzu> The ifunc stuff had had some trouble (real bugs) and I was fifty-fifty if all ifunc should be ripped out just because it didn't feel worth it in this project.
[08:34:14] <gamer191> Apparently also `328c52da8a2bbb81307644efdb58db2c422d9ba7` contained a blank line with just a . which was intended to prevent the landlock sandboxing feature from compiling
[08:34:25] <adrien> Larhzu: hey, an important part is that nobody checks test data, especially when it's supposed from the beginning to be corrupted!
[08:34:37] *** Joins: boklm (~b@mx0.mars-attacks.org)
[08:34:47] <Larhzu> It took almost two years until Jia got ability to make releases without me doing anything. I wanted changes to happen slowly, and I didn't like the quality he produced at first. But he improved a lot.
[08:34:48] <gamer191> (I'm just repeating everything I've seen today, let me know if I should stop)
[08:35:10] <Larhzu> adrien: Yes but in normal times I would have checked it a bit more.
[08:35:34] <gamer191> Was 5.6 the first release he created?
[08:35:39] <Larhzu> adrien: Remember how I called 5.6.0 "rush stable" here because I found the schedule too tight to do proper quality control?
[08:35:49] <adrien> Larhzu: also, I think the "urgent" stuff has been dealt with by downstreams and this was actually found pretty early and the distribution was very limited
[08:35:55] *** Quits: oldfashionedcow (~Cow@user/oldfashionedcow) (Remote host closed the connection)
[08:36:05] <Larhzu> gamer191: No. Releases signed by him were created by him. I haven't signed any tarballs created by someone else.
[08:36:09] <adrien> Larhzu: yeah, I remember you were also in favor of waiting more
[08:36:21] <aaabbb> adrien: the distribution may have been limited, but the impact may be vast, if he's managed to compromise dev machines/build infra
[08:36:21] <adrien> I think many of us have been coned
[08:36:25] <adrien> (is that the right word? :D )
[08:36:31] <aaabbb> conned
[08:36:36] <aaabbb> coned would mean turning into a cone :p
[08:36:37] <gamer191> Larhzu oh, right
[08:36:51] <adrien> ah, I got it wrong withVLC ;-) 
[08:37:10] <adrien> aaabbb: ubuntu mass rebuilds, I think debian does too; I guess RH-side it's the same
[08:37:14] <Larhzu> When he wanted to make releases, I requested a demo tarball and compared with diff -Narup to what I made.
[08:37:35] <aaabbb> adrien: but how many eg gcc committers had their own computers compromised?
[08:37:38] <Larhzu> A few releases I wasn't happy at all because he had too old Autotools. He thought it was fine, I simply refused it.
[08:38:30] <adrien> aaabbb: I don't know how actually installable it was in ubuntu due to a large-scale (y2038) migration in progress but don't take my word on it, many people are spending actual time assessing the impact
[08:38:34] <Larhzu> Tue Mar 26 2024 < Larhzu> It's been over two weeks without new ifunc bugs.
[08:38:38] <Larhzu> ^ That comment didn't age well.
[08:38:43] *** Joins: oldfashionedcow (~Cow@user/oldfashionedcow)
[08:38:57] <abby> haha
[08:38:57] <aaabbb> well, they're not bugs, they're working as the developer intended...
[08:39:00] <adrien> debian, probably more but also the payload is quite known
[08:39:48] <aaabbb> adrien: this has been running and compromising machines for quite some time. the amount of lateral movement that can be done in 3+ months is significant
[08:39:51] <gamer191> Larhzu here's another link, since you said you're collecting them: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
[08:39:52] <Larhzu> aaabbb: Perhaps but ifunc is not simple to use completely correctly.
[08:39:56] *** Joins: steering (~steering@enceladus.whatbox.ca)
[08:39:58] <adrien> Larhzu: I think I see several things: autotools/m4 is a good place to hide things especially if you control tarball generation, ifunc is quite obscure, nobody checks test data for such things
[08:40:21] <Larhzu> gamer191: Thanks, it's in the /topic
[08:40:23] <adrien> aaabbb: right, but it wasn't picked in debian until a month ago
[08:41:49] <gamer191> larhzu oh, right
[08:42:16] *** Joins: fedev (~fedev@121.123.48.38)
[08:42:42] <supakeen> Larhzu: "Releases signed by him were created by him. I haven't signed any tarballs created by someone else." is an important bit of information to put in the email I feel.
[08:43:07] <gamer191> When you respond to everything tomorrow, you might want to respond to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024, which is about how far Debian should downgrade
[08:44:08] <gamer191> they're taking a very conservative approach though, Alpine and Arch just switched to Github's tarballs (instead of the official ones)
[08:44:15] <Larhzu> If the known backdoor is cleaned up, is 5.4.x much safer if one is afraid of Jia's commits?
[08:44:23] *** Joins: tomkap (~thomas@user/tomkap)
[08:44:39] <adrien> some people are questioning that indeed
[08:44:54] <supakeen> I suggested to revert to the last release signed by you in Fedora at least.
[08:45:39] <gamer191> > If the known backdoor is cleaned up, is 5.4.x much safer if one is afraid of Jia's commits?
[08:45:39] <gamer191> No, hence why Debian are considering going down all the way to 5.3.1 (and then porting the security patch)
[08:45:50] <Larhzu> If one turns paranoia to max, then it's not obvious. One might wish to go much further.
[08:45:57] *** Parts: Guest40 (~Guest40@240f:77:357e:1:f5bc:f6f9:9edd:786f) ()
[08:48:11] *** Guest28 is now known as nick_wick
[08:49:29] <Rounin> It's kind of the SeLinux / AES / Insert technology here problem. If some 3-letter agency has touched it, the colour of the bits changes even if the content is the same.
[08:49:57] *** Joins: guest31 (~guest16@2600:4040:2acb:1400::100e)
[08:50:21] *** Quits: x544B (~x544B@84.254.40.50) (Quit: Client closed)
[08:51:29] <aaabbb> aes was not touched by a 3 letter agency. it was made by two belgian cryptographers and selected by a tla
[08:51:30] *** Joins: Whistler (uid479003@user/whistler)
[08:51:35] <aaabbb> well a 4-la
[08:52:10] *** Joins: fetzenfisch (~fetzenfis@user/fetzenfisch)
[08:52:32] <Rounin> aaabbb: Yes, the selection process was carried out by some official organ, so they could have selected candidates based on other things than merit, but I don't doubt the researchers
[08:53:00] <aaabbb> perhaps but all the other teams agreed with the open selection process
[08:54:01] *** Quits: DeepThoughts (~DeepThoug@h-158-174-239-245.A160.priv.bahnhof.se) (Ping timeout: 268 seconds)
[08:54:17] <Rounin> Fair enough... And I'm not against using AES... I've even implemented it once, in beautiful Perl
[08:54:42] <aaabbb> it sounds painful to implement in perl lol
[08:54:57] <Rounin> It was, haha... But not as painful as it would be to read :D
[08:55:48] <Manis> Rounin: that's Perl :D
[08:55:50] <aaabbb> $hey @i %like &sigils [assaulting] {my} (senses)
[08:56:19] <Manis> 80% of /dev/random is valid Perl syntax.
[08:56:47] <Rounin> :D
[08:56:53] <aaabbb> lmao
[08:57:38] *** Quits: guest31 (~guest16@2600:4040:2acb:1400::100e) (Quit: Client closed)
[08:58:03] *** Quits: nick_wick (~Guest28@103.211.17.244) (Quit: Client closed)
[08:59:35] *** Joins: wb9688 (~wb9688@user/wb9688)
[08:59:37] <ryzenda> I have not seen a single mention anywhere endorsing and applauding Microsoft for their disabling the GitHub repo nor suspending Larhzu's GitHub account. Maybe I missed it, but what's up with that? Was there any reason provided about what tos violation occurred or something?
[09:00:10] <supakeen> Probably a knee-jerk reaction.
[09:00:18] <Larhzu> "account violates our Acceptable Use Policy"
[09:00:38] *** Joins: dprevot (~dprevot@monitoring.evolix.net)
[09:00:42] <Larhzu> Suspending the account has pros and cons. If compromised account was suspected then it's good to do.
[09:00:52] <Larhzu> But it also takes away one way of communication.
[09:01:05] <adrien> GH terms are very very broad and they can do anything based on them; I think it was a good thing to do short-term
[09:01:11] <aaabbb> preventing people from viewing the commits (as easily) or commentin is a bier eal
[09:01:16] <aaabbb> bigger deal*
[09:01:20] <Larhzu> So I'm glad I insisted on keeping the rest of Tukaani on my own website and domain.
[09:01:29] <Larhzu> git.tukaani.org
[09:01:37] <adrien> it caused issues with GH-repos trying to revert the commit though :P 
[09:01:37] <Larhzu> That one never went away.
[09:02:28] <Larhzu> adrien: You remember how "happy" I was to get a GH account so if tons of stuff breaks because <big platform> does big things I get mixed feelings.
[09:02:44] <adrien> definitely!
[09:02:50] *** Joins: taffit (~taffit@carotte.tilapin.org)
[09:04:01] <Larhzu> boehs.org link -- Jigar I heard quite recently, wasn't happy about 0BSD change, thinking that public domain meant a patent grant as well (perhaps it does but LZMA was thought to be free of patents in 2006).
[09:04:09] <ryzenda> "If the known backdoor is cleaned up, is 5.4.x much safer if one is afraid of Jia's commits?" My thoughts as an outsider coming in, I personally would remove 100% of all their commits, and redo anything that might have any value, but even if it does, other humans can reproduce that value and take the credit as long as it doesn't reintroduce vulnerability. That way even the craziest tinfoil persons won't boycott xz 
[09:04:09] <ryzenda> specifically related to trust concerns for any of the commits
[09:05:16] <Larhzu> ryzenda: I understand that and review has to be done. What outsiders cannot know is the effort I put in reviewing most commits.
[09:05:33] <Larhzu> ryzenda: In the end, that review had a few holes like the test files and creation of release tarballs.
[09:05:48] *** Joins: Guest85 (~Guest85@142.147.89.207)
[09:05:53] <ryzenda> haha, I knew zero things, but I appreciate the hard work that I have not paid attention to for over a decade! Thanks very much! Definitely much appreciated!
[09:06:54] <Larhzu> Jia got a permission *and* ability to make release tarballs without my filtering only this year. But his old tarballs have to be reviewed still. A few I did with diff -Narup against my test tarball.
[09:07:05] *** Joins: Guest4 (~Guest4@199.red-79-154-210.dynamicip.rima-tde.net)
[09:07:13] <Larhzu> ryzenda: Thanks!
[09:07:52] <Larhzu> The C code in this project had no CVEs in over a decade. The CVEs were to the scripts that were adapted from gzip (plus one obviously bogus CVE).
[09:08:12] <Larhzu> It's just one small error away from a CVE in most commits.
[09:08:51] *** Quits: dostoyevsky2 (~sck@user/dostoyevsky2) (Quit: leaving)
[09:08:56] *** Joins: amdj (aaron@libera/staff/amdj)
[09:09:05] <gamer191> > boehs.org link -- Jigar I heard quite recently, wasn't happy about 0BSD change, thinking that public domain meant a patent grant as well (perhaps it does but LZMA was thought to be free of patents in 2006).
[09:09:06] <gamer191> Do you want us to share that message?
[09:09:18] *** Joins: dostoyevsky2 (~sck@user/dostoyevsky2)
[09:09:42] <Larhzu> In general I think private emails from others aren't mean to be shared.
[09:09:52] *** Quits: oldfashionedcow (~Cow@user/oldfashionedcow) (Remote host closed the connection)
[09:09:56] *** Joins: radek (~igloo@109-81-89-137.rct.o2.cz)
[09:10:17] <Larhzu> Those emails were useless.
[09:10:31] <gamer191> > In general I think private emails from others aren't mean to be shared.
[09:10:32] <gamer191> Wait, what?
[09:10:50] <Larhzu> If someone sends an email to me, I'm not supposed to post it in public. It's not polite in general.
[09:11:23] <Larhzu> It's legal but not polite. In this case I don't see what those emails would add to this. Jigar's tone was similar to the emails on xz-devel.
[09:11:32] <mikolajw> I think gamer191's question was about the chat message you made here about Jigar (Kumar, i assume)
[09:11:47] <Guest5> no need to post those publicly - CISA may request a copy of your correspondences tho
[09:11:59] *** Joins: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491)
[09:12:00] <gamer191> > I think gamer191's question was about the chat message you made here about Jigar (Kumar, i assume)
[09:12:01] <gamer191> Yeah
[09:12:24] <Larhzu> Oh
[09:12:27] <Larhzu> Sorry
[09:12:38] <gamer191> All g👍
[09:12:46] <Larhzu> I guess I already did in front of 200 people but I don't think it's good to put on web.
[09:12:48] *** Joins: luccc (~lukas@ip-193-53-104-44.changeis.iunxi.net)
[09:12:56] <Larhzu> I don't think it has any relevance.
[09:13:02] <gamer191> ok
[09:13:17] <Larhzu> The crazy thing is how much Jia helped.
[09:13:38] *** Joins: oldfashionedcow (~Cow@user/oldfashionedcow)
[09:13:47] <ryzenda> yeah, I can agree with that. Subjective opinion things may be misinterpreted and give wrong impression. It's like reading opinion articles and treating opinion as fact
[09:13:58] <supakeen> It'd be very hard to determine if they were after this from the onset or if they got pressured into doing this later on, etc.
[09:14:08] <Larhzu> I still need to get more facts to exclude that it wasn't his account being compromised etc. although evidence I've read is heavily tilted already.
[09:14:28] <Larhzu> I don't think Jigar had anything to do with this.
[09:14:31] *** Quits: radek (~igloo@109-81-89-137.rct.o2.cz) (Ping timeout: 252 seconds)
[09:14:41] <gamer191> Do you think Jia was a state-actor (or was compromised by one)?
[09:14:42] <sauce> I would be going over the tukaani.org infrastructure with a fine tooth comb also
[09:14:59] *** Joins: pajlada (~pajlada@user/pajlada)
[09:15:05] <Larhzu> It's on a webhotel and tukaani.org is purely static files. git.tukaani.org isn't static though.
[09:15:29] <Larhzu> The huge question is "is there something else to know".
[09:15:41] <ryzenda> gamer191, referring back to what I was saying a couple hours ago, there are much larger issues than any state-actors of any country, but that is kinda offtopic too
[09:16:50] <wb9688> You can't really trust anyone anymore these days
[09:16:58] <gamer191> > It'd be very hard to determine if they were after this from the onset or if they got pressured into doing this later on, etc.
[09:17:00] <gamer191> https://github.com/google/oss-fuzz/pull/10667 is apparently quite suspicious though, and that's from last year
[09:17:20] <ryzenda> oh, but I see I said the things before you joined, so... yeah lol nevermind
[09:17:51] <gamer191> ryzenda are you talking about commercial spyware vendors that sell spyware to the government (such as Pegasus)?
[09:17:54] <Larhzu> https://sourceware.org/glibc/wiki/GNU_IFUNC "The resolver must not be compiled with -fstack-protector-all or any similar protections e.g. asan"
[09:18:22] *** Joins: dasbjo (m-6dppuj@mail.schafweide.org)
[09:18:25] <Larhzu> I approved that ifunc PR based on the wiki.
[09:19:04] <Larhzu> And it crashed on when I built from Git repo thus no malicious configure.
[09:19:10] *** Joins: Guest96 (~Guest96@89-78-179-85.dynamic.chello.pl)
[09:19:15] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[09:19:57] <Larhzu> One thing is to remember that the bad guys read this channel too.
[09:20:01] *** Quits: fedev (~fedev@121.123.48.38) (Ping timeout: 252 seconds)
[09:20:17] *** Quits: oldfashionedcow (~Cow@user/oldfashionedcow) (Remote host closed the connection)
[09:20:21] <gamer191> > One thing is to remember that the bad guys read this channel too.
[09:20:21] <gamer191> Does that matter?
[09:20:40] <Larhzu> Mostly no
[09:20:44] *** Joins: fedev (~fedev@113.211.114.224)
[09:20:54] <ryzenda> gamer191, https://imgur.com/a/NdEQfVD
[09:21:23] *** Quits: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491) (Quit: grmll)
[09:21:55] *** Joins: Guest32 (~Guest68@181.214.173.151)
[09:22:38] <Larhzu> Has anyone gone through the old Jia-signed tarballs already?
[09:24:12] <Larhzu> A bit too forward-thinking but I might have a problem once this is sorted out: Jia helped *a lot*.
[09:24:13] *** Guest72 is now known as vegard
[09:24:18] *** vegard is now known as vegard_no
[09:24:28] *** Joins: GeDaMo (~GeDaMo@user/gedamo)
[09:25:26] <Larhzu> Like handling translations which can be tedious. In the last months I didn't review those commits either, thinking "it's not code" and that Jia had learned to make a good job.
[09:25:49] <ryzenda> Larhzu, Again coming from an outsider not paying attention to last 10+ years history, given how much attention is on this situation, I am certain that any help that was provided by any quantity of persons through that one single account, there are so many humans that can reproduce all of that help 1,000 times more help just as well
[09:26:13] <Larhzu> Boardgames that have hidden traitor can be fun to me and often the thing is to play properly except a few times. And that's how it has gone here too.
[09:26:14] <supakeen> The question is if people will; and the scrutiny will be immense.
[09:26:57] *** Joins: Nick111 (~Nick111@144.202.173.133)
[09:27:08] <Larhzu> ryzenda: It's better to have a few humans to review those commits instead of rewriting them. Many are very interdependent on what I've committed.
[09:27:18] <vegard_no> I am really worried about this use of eval $(xz --robot --version) in the kernel xz wrapper script.
[09:27:27] <Larhzu> ryzenda: A real clean slate restart is not realistic.
[09:27:39] <vtorri_> Larhzu, kill the autotools, use cmake or meson
[09:28:25] <ryzenda> Sure. I'm just offering my feedback. I'm not in position to contribute myself, but I'm sure there will be a lot of persons that will be available to fix anything (maybe some bad actors, but that's easy to be safe to not be recompromised again)
[09:28:32] <vtorri_> Larhzu, the philosophy of meson is : what is in git should go to the dist
[09:28:38] <gamer191> > there are so many humans that can reproduce all of that help
[09:28:38] <gamer191> tbh I feel like at least one of those humans will be Jia's alt
[09:28:45] <vtorri_> a tarball is not even required
[09:28:48] <vtorri_> just a tag
[09:28:49] <Larhzu> vegard_no: I wondered if I should do it that way or not. :-| I wrote it.
[09:29:57] *** Joins: DeepThoughts (~DeepThoug@h-158-174-239-245.A160.priv.bahnhof.se)
[09:30:01] *** Quits: Guest32 (~Guest68@181.214.173.151) (Ping timeout: 250 seconds)
[09:30:21] <Larhzu> vtorri_: Keeping Autotools for old platforms is nice though. It's not that long ago I got emails about SCO OpenServer 5.0.7 with GCC 3 or 4.
[09:30:38] <Larhzu> vtorri_: Or many other obscure systems which Autotools still support.
[09:30:44] <vtorri_> Larhzu, do they have python 3?
[09:30:53] <vtorri_> Larhzu, or providea basic Makefile
[09:31:04] <Larhzu> I don't know but I've heard Meson has C99 version too.
[09:31:13] <abby> vtorri_: there's a cmake definition in the xz repo
[09:31:20] *** Joins: noone (~noone@178.255.168.249)
[09:31:27] <Larhzu> I have basic Makefile for DOS/DJGPP. For the rest it's no fun.
[09:31:31] <vtorri_> Larhzu, i'm working on a port of meson in c99, named muon
[09:31:43] <vtorri_> well, i'm contributing to that tool
[09:31:55] <vtorri_> (for the windows port)
[09:32:03] *** Quits: marblood (~marblood@45.134.213.216) (Quit: Leaving)
[09:32:09] <Larhzu> CMake support is quite far now, Jia helped with that too. That's the thing, Jia has touched a lot of things but a lot I've already reviewed before merging.
[09:32:19] <vtorri_> so no need for meson and python if you use muon
[09:32:48] <Larhzu> vtorri_: I remember you suggesting Meson years ago. Some people wanted CMake because reasons.
[09:32:57] <gamer191> I'm logging off now, bye
[09:33:00] <Larhzu> Bye
[09:33:00] <vtorri_> muon has even its own compiler written in c99, so no need for ninja
[09:33:08] *** Quits: gamer191 (~gamer191@124.168.216.118) (Quit: Client closed)
[09:33:33] <vtorri_> Larhzu, reasons ? 99.99% of *users* are using package managers
[09:33:52] <vtorri_> there reste, well, they can learn
[09:33:58] <Larhzu> CMake was originally added for Windows builds.
[09:34:21] <Larhzu> Sure and CMake's language has, umm, it's oddities.
[09:34:28] <vtorri_> and you can assume that the other people are developpers and have sufficient experience to build xz with meson or cmake
[09:34:40] <vtorri_> meson is clean
[09:34:42] <Larhzu> CMake needs a C++ compiler.
[09:34:56] <vtorri_> and you have a pure c99 path to build it with meson.build files
[09:35:19] <ryzenda> hmmm, Jia Jia Jia, sorry if I may seem rude, but, as far as I am concerned, from what I have read, the 1, 2, or however many humans used the Jia Tan account/alias/pseudonym, and I would not be surprised if it literally was more than 1 person, like organized crime intentional malice, planned this entire time, socially engineered, that even stockholm syndrome comes to mind, e.g. https://i.imgur.com/CPqFCbj.png 
[09:35:23] <Larhzu> I need a new co-maintainer if Jia was a bad guy.
[09:35:27] <hsiangkao> IMHO, if maintainers can have a real meetup or new maintainer has more wider public contribution, that could much better.
[09:36:01] <Larhzu> I know Stockholm syndrome, this is not it, luckily. :-)
[09:36:08] <ryzenda> alright, cool, lol
[09:36:18] <dasbjo> ryzenda: Like the other people trying to push 5.6.1 everywhere?
[09:36:25] <Larhzu> ryzenda: And I appreciate direct but respectful talk, you aren't rude at all.
[09:36:35] <vtorri_> Larhzu, maintainer == reviewing pathces ?
[09:36:48] <vtorri_> or doing the tarballs ?
[09:37:04] <Larhzu> Reviewing is a big thing, yes. But I got so much help with janitorial stuff too.
[09:37:09] <ryzenda> dasbjo, I don't know about the larger picture too much. I only use Archlinux on all my computers, and I was curious earlier how many distributions are affected, but I didn't even get to find that information specifically. 
[09:37:42] <Larhzu> My desktop runs Archlinux.
[09:38:13] *** Joins: dxrt (~dxrt@user/dxrt)
[09:38:25] <supakeen> Larhzu: I think if you were to include a bit about needing comaintainership on a critical library when you do your planned post later next week you might find some people interested in that. Many eyes on the project for better or worse :)
[09:38:55] <f_> Larhzu: as for repos, what will be done?
[09:39:03] <f_> They're gone AFAIK
[09:39:04] <vtorri_> Larhzu, as i said, do like google : don't provide tarballs : just a tag and make an annouce
[09:39:29] <hsiangkao> I think an opensource project with anonymous contribution is fine, as long as they were carefully reviewed. In the past, the kernel project also had an issue from UMN: https://lore.kernel.org/all/20210503115736.2104747-1-gregkh@linuxfoundation.org/
[09:39:33] <vtorri_> libaom, pdfium, etc ... have no tarballs
[09:40:33] *** Quits: yasin (~yasin@130.204.92.64) (Quit: Leaving.)
[09:40:56] *** Parts: GeDaMo (~GeDaMo@user/gedamo) (Huh. So that's what the /part command does.)
[09:42:26] <Larhzu> vtorri_: That works well for GNU/Linux and *BSDs, I guess, Windows too. There are pros and cons and over the years the pros of your preference have grown a lot bigger but I think it's not without cons still.
[09:42:51] <Larhzu> f_: What do you mean?
[09:43:21] <Larhzu> supakeen: It took years to get the current one. Maybe now there is more visibility.
[09:43:21] <tk> Larhzu: f_ means that github has taken down the repos, but really that's a Monday job by the sounds of it
[09:43:30] <hsiangkao> also https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
[09:43:32] <tk> the repos are just hidden
[09:43:40] <f_> fwiw
[09:43:45] <Larhzu> https://git.tukaani.org/ This was never gone.
[09:44:01] <f_> Larhzu: But it looks outdated
[09:44:05] <Larhzu> It's fast.
[09:44:05] <f_> doesn't it?
[09:44:09] <f_> I mean
[09:44:11] <f_> The repo
[09:44:29] <f_> not gitweb :)
[09:44:43] <f_> Oh nevermind
[09:44:48] <Larhzu> The three xz repos are there.
[09:45:01] <f_> Good, thanksm
[09:45:05] <f_> *thanks.
[09:45:25] <Larhzu> Regulars on the channel know how important it was to me to not rely on GH alone.
[09:45:49] <Larhzu> git.tukaani.org doesn't have the auxiliary branches, only master and v5.x branches.
[09:46:02] <ryzenda> I am not concerned about this at all personally, but it did capture my attention that I noticed reading https://nongnu.org/lzip/xz_inadequate.html "The fact that the xz reference tool (xz-utils) has had more bugs than bzip2 and lzip combined is mainly a consequence of the complexity and bad design of the xz format."
[09:46:06] <dnsmcbr> Don't envy you having your commits under the microscope
[09:46:13] *** Joins: oldfashionedcow (~Cow@user/oldfashionedcow)
[09:46:20] <f_> Larhzu: Good.
[09:46:35] <amdj> all software has bugs. newer software tends to have more bugs.
[09:46:59] <ryzenda> I don't know if that fact is correct or not, but if it is, then whatever is being implied, maybe something can be resolved for that to not be a consistent issue. Again, I'm just basing my thoughts on that statement as if it is true/correct. I haven't checked/verified.
[09:47:28] <amdj> especially when you're reimplementing the same kind of thing as something that already exists
[09:48:22] *** Parts: yan12125 (~yen@user/yan12125) (WeeChat 4.2.1)
[09:48:34] <Larhzu> ryzenda: The history with lzip's developer and me is a bit complicated. He is a fine developer. The article, at least years ago when I read it, had some points but many were a misleading, let's phrase it so.
[09:48:35] <amdj> how many compressors do we have? gzip, bzip, lzo, lz4, lzma, ... how many times have the people writing these made exactly the same kinds of mistakes as eachother (like removing the input file before writing a complete output file)
[09:48:57] <Larhzu> ryzenda: I would prefer to not mix that story here.
[09:49:02] *** Joins: pera (~pera@user/pera)
[09:49:11] <amdj> not surprised at all that the newcomer on the block (at the time) would have more bugs.
[09:49:21] <ryzenda> That makes sense. I'm not too concerned, like I said. 
[09:49:36] <Larhzu> dnsmcbr: If someone does free code review, I thank them.
[09:49:43] *** Parts: Guest85 (~Guest85@142.147.89.207) ()
[09:50:08] <ryzenda> Personally, I was excited about xz cuz it was faster, didn't even know abouit bugs, never crossed my radar, until now, lol
[09:50:08] <dnsmcbr> Free code review, sure. Free code witch hunt? ehhhhh
[09:50:14] <Larhzu> ryzenda: There are bunch of things I could have liked to do differently in .xz in hindsight but many of them aren't in his article. :)
[09:50:18] *** Joins: ultra980 (~ultra@2a02:2f0a:b308:4000:f3b3:ac45:9e24:83a6)
[09:50:42] <Larhzu> The x86-64 inline asm in 5.6.0 gave a nice 20-40 % decompression time reduction.
[09:50:54] <Larhzu> It's based on LZMA SDK's asm like many other core code things.
[09:51:56] <Larhzu> I did that work except Jia did some changes that are prerequisites.
[09:52:13] <ultra980> neat! 
[09:52:56] <f_> mm..
[09:52:59] <Larhzu> But once again those changes I did review to a decent extent. There was one off-by-one bug that was easy to spot. Was that a dishonest bug, I cannot know.
[09:53:27] <Larhzu> That off-by-one bug was fixed before commits were merged to master.
[09:53:42] <Larhzu> And then I edited the code quite a bit more. :p
[09:54:25] <Larhzu> Landlock sandbox support in 5.6.0 should help on Linux but only when using the xz tool. No help with other liblzma users. :-|
[09:55:20] <boud> Larhzu: minor issue in keeping the wider community informed: you should propose a sentence or two for sam_ to replace "Lasse regularly has internet breaks and is on one at the moment, started before this all kicked off. We believe CISA may be trying to get in contact with him." on the FAQ: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27  (and welcome to world fame, btw)
[09:55:20] *** Quits: fedev (~fedev@113.211.114.224) (Read error: Connection reset by peer)
[09:55:25] <Larhzu> I'd like to get 5.6.2 in trustable shape in sensible amount of time.
[09:55:40] <amdj> You can't really have a library sandbox itself anyway; it can't reasonably make any assumptions about the application using it or what that application is going to do
[09:55:41] <boud> or leave it unchanged, as you like
[09:55:45] *** Joins: fedev (~fedev@121.123.48.38)
[09:56:16] <Larhzu> boud: I'm on an Internet-break -break now actually. Not sure what CISA is.
[09:56:31] <abby> CISA is the USA cybersec agency
[09:56:35] <amdj> the US cybersecurity and inf-
[09:56:36] <amdj> yeah
[09:56:48] *** Joins: f_[xmpp] (fffdb90022@fases/developer/funderscore)
[09:56:50] <Larhzu> Well, Finland joined NATO so perhaps they can get here more easily now.
[09:56:58] <ryzenda> Larhzu, lol I never heard of CISA either until just a few days ago first time from https://youtu.be/l8NsfTEjD6c
[09:56:59] <Larhzu> ;-)
[09:57:01] *** Quits: f_ (~AUGESOUND@fases/developer/funderscore) (Remote host closed the connection)
[09:57:14] <abby> it's also https://www.cisa.fi :P
[09:57:33] <amdj> abby: HAH.
[09:57:44] <Larhzu> Oh, but I don't drink, no help.
[09:57:46] <supakeen> Finland has its own CISA called a NCSC: https://www.kyberturvallisuuskeskus.fi/en/homepage
[09:57:54] <supakeen> Which might, or might not, contact you.
[09:57:57] <amdj> The UK's equivalent is also called NSCS.
[09:58:01] <ryzenda> and solely because of that content/context that I heard of them in that way, and then seeing something about CISA mentioned again regarding this situation, I was like... is this a retaliation? Is CISA involved in this situation? Are they Jia Tan? lol but that's my wild speculation mind
[09:58:01] <amdj> NCSC *
[09:58:09] <Larhzu> supakeen: Makes sense
[09:58:20] *** Joins: gamer191 (~gamer191@124.168.216.118)
[09:58:37] *** Joins: Guest87 (~Guest21@host-194-21.calaw27p.losangeles.ca.us.clients.pavlovmedia.net)
[09:58:38] <Larhzu> sam_: Some concerns have been raised about the "CISA" sentence in the FAQ.
[09:58:42] <supakeen> They're often more useful if you get a bug reported in private to loop them in early so they help with coordination.
[09:59:00] <supakeen> Or, when reporting a vulnerability and the project doesn't respond so they can do the coordination as well.
[09:59:10] <Larhzu> This mess had to go full disclosure immediately, it was the only right thing.
[09:59:20] <supakeen> Agreed.
[09:59:39] <f_[xmpp]> I probably shouldn't have joined this channel :P
[09:59:42] <amdj> except when they don't help with coordination (CVE-2023-51764)
[09:59:48] <supakeen> FWIW, it was mentioned on the distros security list before the disclosure but it was only by a day or two.
[09:59:55] *** Joins: zekica (~zekica@178-220-122-192.static.isp.telekom.rs)
[10:00:40] <gamer191> Larhzu I remember you saying earlier to "remember, the bad actors are on this IRC as well". I just wanted to add that most people on IRC don't use passwords, so beware of impersonators as well
[10:00:54] <f_[xmpp]> gamer191: Well, no.
[10:01:02] <boud> Maybe instead of "We believe CISA may be trying to get in contact with him." something like "Lasse is in contact with the tukaani community that is discussing the issue."  ??
[10:01:10] <f_[xmpp]> jiatan has a nickserv account with password and nickname protection.
[10:01:28] <f_[xmpp]> So any impersonator would be forcibly renicked to a Guest nick
[10:01:34] <amdj> We (staff) put that protection on when this kicked off, to stop trolls impersonating them.
[10:01:37] <Larhzu> gamer191: A fair reminder, thank you.
[10:02:12] <Larhzu> boud: I'll leave it to sam_ to word, the info is so spread out at the moment anyway.
[10:02:25] <f_[xmpp]> amdj: Also, was there a wallops for that xz backdoor?
[10:02:28] *** Joins: Guest8 (~Guest8@174-17-163-165.phnx.qwest.net)
[10:02:30] <amdj> Yep
[10:02:34] <gamer191> > jiatan has a nickserv account with password and nickname protection.
[10:02:35] <gamer191> I'm talking about jiatan impersonating other people, not people impersonating jiatan
[10:02:42] <Larhzu> boud: A trouble is that lots of people collect info and often it's not perfectly accurate but in this situation it's acceptable.
[10:02:54] <amdj> 2024-03-29T17:45:11Z --- Wallops from kline (freedom0@libera/staff/kline): Good afternoon! A recent exploit has been identified in xz/liblzma. Libera is not affected by this vulnerability, but many other systems might be. You can read more about the incident here: https://www.openwall.com/lists/oss-security/2024/03/29/4 . Have a good weekend.
[10:03:11] <f_[xmpp]> hmm didn't receive that..
[10:03:20] <amdj> (I'm not sure "Have a good weekend" is the appropriate follow-on from that, but ... shrug)
[10:03:26] <Larhzu> f_[xmpp]: Yes and I got extra modes by Libera Chat admin, thanks.
[10:03:38] <f_[xmpp]> Extra modes?
[10:04:00] <dostoyevsky2> amdj: It was Good Friday, so seems like the appropriate adjective to use
[10:04:33] <ryzenda> gamer191, seems reasonable cuz definitely whoever that person(s) were/are, they are not gone, lol, they're somewhere, haha, but otherwise, innocent until proven guilty, and as far as I'm concerned for myself and everyone in IRC, it's just chatting, nothing too serious. All the serious formal conversations that can be prepared for and make sure to not make mistakes, that will not be here in IRC, lol. 
[10:04:33] <Larhzu> f_[xmpp]: Hiding my IP.
[10:04:33] <boud> Larhzu: OK :)
[10:04:56] <amdj> dostoyevsky2: yeah, but people who know what the message is about are certainly not going to be having a good weekend as they undertake an emergency audit of all of the infrastructure they're responsible for :P
[10:05:08] <Larhzu> boud: Many are trying to help, I cannot reply to everyone or correct every detail like I try to do with code.
[10:05:14] <f_[xmpp]> Larhzu: ah the user/ cloak
[10:05:19] <Noisytoot> Larhzu: the latest commit on the github repo was jia updating SECURITY.md, which is not on the git.tukaani.org mirror
[10:05:41] <dostoyevsky2> amdj: I was looking at the 5.6.0.deb file and then realized: oh, the tar files are also packed with xz
[10:05:46] <Larhzu> Noisytoot: OK, I hadn't pulled that commit to my system either. So I cannot fix it, I guess.
[10:05:48] <Manis> I've been wondering what the purpose of the edited SECURITY.md was.
[10:05:57] <f_[xmpp]> Noisytoot: what did jia put in SECURITY.md?
[10:06:00] <gamer191> > innocent until proven guilty
[10:06:00] <gamer191> Lol, I'm not accusing anyone, it was just something to keep in mind in future
[10:06:12] <Manis> f_[xmpp], nothing, he removed some requirements for reporting issues.
[10:06:18] <f_[xmpp]> Which ones?
[10:06:22] <Larhzu> f_[xmpp]: We simplified it although Jia kept the 90 days in it although I suggested 30.
[10:06:44] <f_[xmpp]> hm, sure
[10:06:58] <Larhzu> SECURITY.md edit was at least partly my proposal, part of editing the "new issue" and "new PR" templates which I wanted to be simplified as well.
[10:07:06] <Noisytoot> it's on softwareheritage archive
[10:07:09] *** Joins: taavi (taavi@mediawiki/taavi)
[10:07:12] <f_[xmpp]> Oh great.
[10:07:13] <Noisytoot> https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://github.com/tukaani-project/xz
[10:07:13] <Tuvix> Larhzu: if you wanted a repo mirror that has the latest commits that did not get synced to the tukaani site, there are a few mirrors, like this one: https://github.com/gastonmorixe/xz.git
[10:07:14] *** Quits: asldkasdfasdfoi (~asldkasdf@178.165.165.191.wireless.dyn.drei.com) (Remote host closed the connection)
[10:07:25] <f_[xmpp]> Thanks.
[10:07:27] <Manis> Oh, so the SECURITY.md simplification is benign?
[10:07:36] *** Quits: Guest96 (~Guest96@89-78-179-85.dynamic.chello.pl) (Quit: Client closed)
[10:07:43] <amdj> Tuvix: the point of having mirrors of it is that they're not github.
[10:08:06] <Manis> f_[xmpp], this is the diff https://github.com/gastonmorixe/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c
[10:08:27] <gamer191> > SECURITY.md edit was at least partly my proposal
[10:08:28] <gamer191> It's amazing how much the internet speculates incorrectly. Come to think of it, it wouldn't make sense for him to edit it, unless that backdoor could be mistaken for a vulnerability (I don't know enough to comment on that)
[10:09:16] *** Joins: Speedy11CZ (~Speedy11C@2001-1ae9-158-5400-4008-30be-db44-7d4d.ip6.tmcz.cz)
[10:09:38] <Larhzu> Noisytoot, Tuvix: Thanks. But how do I know it's by the "real" Jia?
[10:09:58] <kalekale> good to know youre safe Larhzu 
[10:10:00] *** Joins: aljazs (~aljazs@BSN-77-224-3.static.siol.net)
[10:10:18] *** Quits: Guest11 (~Guest19@ti0027a400-0966.bb.online.no) (Ping timeout: 250 seconds)
[10:11:02] <Larhzu> gamer191: It's editing a simple text file which doesn't go into release tarballs. The instructions are simplified a little but that's it.
[10:11:10] *** Quits: Guest4 (~Guest4@199.red-79-154-210.dynamicip.rima-tde.net) (Quit: Client closed)
[10:11:18] <Larhzu> gamer191: I get people might wonder if the text contains piece of the backdoor code...
[10:11:23] <Larhzu> People speculate too much.
[10:11:29] <f_[xmpp]> yeah
[10:11:55] <gamer191> No, people speculated that it was designed to prevent people writing meaningful reports, hence preventing you finding out about it
[10:12:03] <amdj> It wouldn't be unprecedented. I can think of at least 1 piece of malware (though I don't recall its name) where the majority of the payload was hidden inside UUID strings inside an innocuous XML file.
[10:12:06] *** Quits: Guest8 (~Guest8@174-17-163-165.phnx.qwest.net) (Quit: Client closed)
[10:12:29] <Larhzu> gamer191: How giving less instructions would *prevent* people from saying something sensible...
[10:12:39] <Larhzu> amdj: Of course
[10:12:57] <Larhzu> But a lot of commits I or Jia made were co-developed a little bit.
[10:13:13] <Larhzu> We agreed to stop thanking each other in commit messages quite early on.
[10:13:48] <Larhzu> It's interesting if Jia comes online next week.
[10:14:12] *** Quits: oldfashionedcow (~Cow@user/oldfashionedcow) (Remote host closed the connection)
[10:14:22] <Tuvix> the reality is we can't really know if this was malice, a complete compromize of account logins plus signing keys, or coercion as all are plausable to some extent
[10:14:23] <Rounin> Wow... Imagine if he's just a regular programmer owning only one of those e-mail addresses and he's as surprised as everyone else
[10:14:30] <Your_Dog> certainly, it will be interesting if he comes online next week, cant wait
[10:14:30] <Tuvix> time may reveal one of those options more likely
[10:14:40] <gamer191> > How giving less instructions would *prevent* people from saying something sensible...
[10:14:40] <gamer191> I guess it would make it harder to figure out the cause. Also, if you don't ask for affected versions, people are less likely to investigate where the vulnerability was added, and hence less likely to figure out that it was a backdoor
[10:14:42] *** Joins: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net)
[10:15:26] <Larhzu> gamer191: I find that quite far-fetched. If someone reports something, upstream tends to investigate.
[10:15:45] <Larhzu> And there's this thing of asking questions from the reporter too.
[10:16:08] <ultra980> it sucks that gh suspended the repo
[10:16:27] <gamer191> > But how do I know it's by the "real" Jia?
[10:16:28] <gamer191> If he was compromised, he should have reported it
[10:17:02] <Paistin> I'd be in contact with authorities and keep my mouth shut in that case and not report anything or come online 
[10:17:26] <gamer191> why?
[10:17:30] *** Joins: [ (2loH56eelS@sourcehut/user/noisytoot)
[10:17:30] <Tuvix> in the case of serious coersion that may not always be viable depending on possible threats involved
[10:17:42] <gamer191> brb
[10:17:44] <Paistin> gamer191: you have dozens of people trying to ask you dumb questions. When CERT and officials are the only ones you need to talk to
[10:17:55] <Larhzu> gamer191: How do I know that someone here didn't commit that in Jia's name and email and is now wanting me to pull it? Sure, I'm quite sure it's real but the impersonation question was raised a few times.
[10:18:13] <[> Larhzu: Why didn't you (or Jia) sign your commits?
[10:18:34] <Paistin> questions like this
[10:19:13] <Manis> Would signed commits help? In case it was a compromise who knows the signing key didn't also get compromised?
[10:19:21] <abby> it would not help
[10:19:37] <Larhzu> Signing would mean that then at least it was made by those who had the key.
[10:19:58] <[> Manis: it would help with what Larhzu is saying (verifying that it's actually Jia, or someone who had Jia's key, rather than someone here trying to get fake commits pulled)
[10:20:12] <abby> but the bad tarballs were also signed by that key so not much help there
[10:20:15] <Speedy11CZ> it's good to sign commits, but in this case it wouldn't have prevented the situation.
[10:20:15] <Tuvix> the releaes do in fact have signatures attached: https://web.archive.org/web/20240329182650/https://xz.tukaani.org/xz-utils/#releases
[10:20:25] <amdj> I sign all of my commits with my yubikey. however that's all for nought for my contributions to github when my PRs are merged by rebasing. a rebase has to destroy all commit signatures to work.
[10:21:03] <Larhzu> I don't like non-linear history so rebasing happens a lot.
[10:21:16] <Larhzu> Tuvix: Tags are signed.
[10:21:34] *** Joins: oldfashionedcow (~Cow@user/oldfashionedcow)
[10:21:55] <Paistin> theres a lot of incredibly suspicious shit like force pushes in the pull requests. attribution is hard, but this speaks of rushed and very coordinated timelines 
[10:22:24] <abby> how are force-pushes in PRs suspicious?
[10:22:30] <amdj> ^
[10:22:33] <Paistin> destroying history?
[10:22:33] <amdj> I force push all the time.
[10:22:54] <amdj> it just means it was a mistake I noticed after I pushed and I don't want a silly little "fix this" commit in the history after it.
[10:23:02] <f_[xmpp]> force-push is part of many workflows
[10:23:05] <supakeen> or that i rebased
[10:23:12] <f_[xmpp]> including the pmOS MR workflow
[10:23:22] <aljazs> > it just means it was a mistake I noticed after I pushed and I don't want a silly little "fix this" commit in the history after it.
[10:23:23] <aljazs> use branches and when stuff is good to go you merge.
[10:23:23] <amdj> or, yeah, if I'm rebasing to resolve a merge conflict, I'd have to force push that too.
[10:23:34] <Paistin> "it was a mistake" is a good way to hide lots of incriminating commits you have created while developing this kind of a payload
[10:23:41] <amdj> aljazs: merging the branch will merge the silly little fix it commit.
[10:23:41] <aljazs> > how are force-pushes in PRs suspicious?
[10:23:41] <Paistin> just force push everything
[10:23:41] <aljazs> To quote Paistin: "destroying history"
[10:24:02] *** Joins: [6502] (~6502]@2a01:827:11ad:5d01:d250:99ff:fe2f:f529)
[10:24:05] <f_[xmpp]> # xz --version
[10:24:05] <f_[xmpp]> xz (XZ Utils) 5.2.5
[10:24:11] <f_[xmpp]> Good thing I don't upgrade often
[10:24:26] <f_[xmpp]> $ xz --version
[10:24:26] <f_[xmpp]> xz (XZ Utils) 5.4.6
[10:24:49] <aljazs> amdj: yeah... I usually just squash when merging.
[10:24:51] <f_[xmpp]> But I wonder.
[10:24:56] <f_[xmpp]> https://security.archlinux.org/ASA-202403-1
[10:24:58] <Celelibi> You could have stayed with that 5.2
[10:25:06] <abby> aljazs: talk about destroying history
[10:25:07] <f_[xmpp]> says that the issue was fixed in 5.6.1
[10:25:16] <aljazs> abyy: yeah I am aware of the irony.
[10:25:19] *** Joins: zipace (~john@p200300ecef4b426745a580a44e90fc31.dip0.t-ipconnect.de)
[10:25:23] <f_[xmpp]> Celelibi: that 5.2 was on my server which has public ssh access
[10:25:36] <f_[xmpp]> that 5.4 was on my laptop
[10:26:08] <kalekale> do people even use rolling distros on production 
[10:26:13] <aljazs> Some do.
[10:26:17] <abby> i do
[10:26:18] <amdj> f_[xmpp]: no, that says it was fixed in 5.6.1-2, which is an arch specific patch set on top of upstream's 5.6.1 removing it.
[10:26:23] <abby> not professional prod but prod
[10:26:33] <aljazs> I used to use arch for some time until I switched to Alpine
[10:26:43] <f_[xmpp]> amdj: >The problem has been fixed upstream in version 5.6.1.
[10:27:12] <amdj> oh I didn't read that far down. you're right. that's wrong.
[10:27:29] <dasbjo> amdj: It's not an arch specific patch, it's just using git tags instead of tarballs
[10:27:38] <kalekale> well abby you maintain a rolling release distro so obviously you would.... 
[10:27:41] <Rounin> Hm... Perhaps this project would be a good candidate for reproducible builds one day... Right now there's what... Two Gits with different contents, and then tarballs with a third set of contents?
[10:27:58] <f_[xmpp]> amdj: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/7c652d0757eb139de80ae38ff02a9cf235629739
[10:28:07] <abby> kalekale: ;)
[10:28:08] <Snetry> just got on the PC, anything new happen?
[10:28:18] <A_Dragon> I woke up
[10:28:18] <Rounin> One would sort of naïvely expect that getting the Git commit for a version and building it would always yield the same application
[10:28:39] <f_[xmpp]> And then they removed Jia's pgp key from valid keys: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/504553292c6fe027ec788acc2d5f45da2cb6c1ac
[10:28:39] <A_Dragon> Rounin: not without reproducible builds it wont
[10:28:46] <gamer191> > in the case of serious coersion that may not always be viable depending on possible threats involved
[10:28:46] <gamer191> tuvix: I didn't think of that tbh
[10:28:47] <gamer191> > gamer191: How do I know that someone here didn't commit that in Jia's name and email and is now wanting me to pull it? Sure, I'm quite sure it's real but the impersonation question was raised a few times.
[10:28:47] <gamer191> larhzu: are you saying you think the person who added the backdoor now wants to remove it?
[10:28:52] <Celelibi> Anyway, it was a wild ride. Good night. ^^
[10:29:27] <A_Dragon> `123734     aljazs ╡ To quote Paistin: "destroying history"` git reflog exists
[10:29:38] <amdj> I maintain an application whose release tarballs differ quite a bit from the git tree or the source code tarballs github would generate from them. It's quite common.
[10:29:58] <A_Dragon> also squash merges are evil
[10:30:12] <A_Dragon> talk about destroying history
[10:30:13] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[10:30:19] <amdj> I've even had to go to the trouble to tell people to **NOT** click the "Source code" links on github because it gives you an unusable archive and then they come to me saying ./configure fails and the very first thing it fails about is telling you how to fetch it properly.
[10:30:48] <Snetry> alternatively tell them to figure it out on their own
[10:30:52] <Snetry> anyway, I assume nothing new happened then
[10:30:54] <aljazs> a_dragon: fair.
[10:31:03] *** Joins: thanosapollon (~thanosapo@193.32.248.149)
[10:31:06] <Paistin> any serious code review should not allow squash or force push 
[10:31:15] <A_Dragon> force push _to a branch_ is fine
[10:31:23] <Paistin> you do you
[10:31:24] <A_Dragon> it lets the developer cleanup their own branches
[10:31:31] <A_Dragon> rather than having `oops messed up`
[10:31:37] <A_Dragon> which just makes noise in PRs
[10:31:42] <amdj> or periodically rebase their branches on top of the branch they want to merge into eventually
[10:31:51] <A_Dragon> however those PRs should require reviews on the most recent push
[10:31:53] <kalekale> github should give the option to disable the default source archive 
[10:31:57] <abby> i would much rather review a pr that was cleaned up and rebased than one with a bunch of oopsie-woopsie commits
[10:31:59] <Rounin> I've worked on commits where the entire point was to change something that only happened in the main branch... Perhaps even only in production
[10:32:00] <Snetry> A_Dragon: some maintainers are really against that because it makes it unclear what they already reviewed 
[10:32:00] <A_Dragon> and yeah, rebases are your friend
[10:32:03] <amdj> kalekale: I've asked, several times.
[10:32:10] <aljazs> a_dragon: Squashing was an example that came to mind when I have too many shitty commits (mainly when working on CI stuff, because I can't really debug this shit locally... or at least I have not found a way to do it reliably yet).
[10:32:15] <Rounin> In those cases, you can either have 10 000 "please work" commits, or force push to main
[10:32:24] <abby> kalekale: you kinda can, by telling git archive to ignore everything
[10:32:40] <Rounin> Of course, those cases are (and should be) rare
[10:33:09] <A_Dragon> aljazs: I find squash PRs evil simply because now blame is just `merged so and sos pr, this is a combination of 500 commits: onelines here`
[10:33:10] <abby> echo '** export-ignore' >> .gitattributes or something
[10:33:24] <gamer191> > says that the issue was fixed in 5.6.1
[10:33:25] <gamer191> f_[xmpp]: it initially says it was fixed in 5.6.1-2, which is referring to the version when arch switched to their own tarballs: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad
[10:33:25] <gamer191> I think the comment about upstream 5.6.1 is a mistake
[10:33:33] <jess> hi Larhzu
[10:34:09] <jess> i sent you some private messages yesterday, if you get a chance to read them
[10:34:26] <gamer191> oh, that was already mentioned
[10:34:31] *** Joins: mxz (~mxz@user/mxz)
[10:34:52] <jess> nothing super important, though.
[10:35:13] *** Joins: lumidify (~lumidify@user/lumidify)
[10:35:20] <aljazs> a_dragon: I guess force-pushing to "MR branch" would be okay, but never on the main branch. So you avoid trashing the repo with shit commits, but never overwrite the history in the source of truth branch.
[10:35:33] <A_Dragon> aljazs: exactly
[10:35:49] <A_Dragon> rebase does make a mess of signed commits, but so long as the head commit is fine its ... probably finer
[10:35:53] <A_Dragon> s/er/e
[10:35:55] *** Joins: Guest26 (~Guest26@2a01cb040ceac400eff883705304d6d8.ipv6.abo.wanadoo.fr)
[10:36:20] <Snetry> I mean
[10:36:25] <aljazs> > s/er/e
[10:36:25] <aljazs> ?
[10:36:26] <Snetry> push to main if there is only 1 developer and 1 consumer
[10:36:27] <Snetry> both you
[10:36:34] *** Joins: Guest99 (~Guest99@37-48-32-161.nat.epc.tmcz.cz)
[10:36:45] <A_Dragon> mhmm
[10:36:57] <A_Dragon> aljazs: parse as sed expression over previous message
[10:36:57] <kalekale> What would be the most convenient way for project maintainers to distribute full source archives? Github actions packaging it properly on every release is the only thing I can think of 
[10:37:25] <A_Dragon> kalekale: GH already does source archives when you create releases
[10:37:27] <aljazs> > : parse as sed expression over previous message
[10:37:27] <aljazs> assumed so, was not sure.
[10:37:37] <kalekale> its useless 
[10:37:41] <kalekale> does not include the submodules 
[10:38:06] <Snetry> Add a section to your readme
[10:38:07] <f_[xmpp]> gamer191: ah ok
[10:38:10] <Snetry> How to build: figure it out yourself
[10:38:19] <abby> have continuous integration that generates a tarball from sources and attaches it to the release
[10:38:23] <jess> oh i see from scrollback you already read it. cool
[10:38:34] <abby> reproducible, public, verifiable
[10:38:41] *** Quits: Square2 (~Square@user/square) (Ping timeout: 272 seconds)
[10:39:04] <gamer191> https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad is actually a very interesting coincidence (look at the description)
[10:39:21] *** Parts: thanosapollon (~thanosapo@193.32.248.149) (ERC 5.6-git (IRC client for GNU Emacs 29.3))
[10:39:28] <abby> not a coincidence, that was a reaction to the vuln
[10:39:44] <f_[xmpp]> abby: Nope.
[10:39:56] <f_[xmpp]> It was on march 28
[10:40:11] <abby> i believe someone at arch is on distros@openwall
[10:40:15] <abby> the private list
[10:40:21] <Snetry> > improve reproducibility by running autogen.sh ourselves
[10:40:24] <abby> they got this vuln a day early
[10:40:27] <Snetry> or how it should have been done from the start
[10:40:28] <f_[xmpp]> abby: hmm ok
[10:40:50] <Snetry> I don't like the whole shtick of relying on build scripts someone else generated
[10:41:27] <jess> i'll be out of the house a lot today. abby can you help keep the channel behaving itself? *waves scary +o at*
[10:41:40] <f_[xmpp]> jess: hah
[10:41:41] <gamer191> abby: Actually yeah, according to https://www.openwall.com/lists/oss-security/2024/03/29/4:
[10:41:42] <gamer191> > Given the apparent upstream involvement I have not reported an upstream
[10:41:42] <gamer191> > bug. As I initially thought it was a debian specific issue, I sent a more
[10:41:43] <gamer191> > preliminary report to security@...ian.org.  Subsequently I reported the issue
[10:41:43] <gamer191> > to distros@. CISA was notified by a distribution.
[10:41:53] <abby> i was about to go to bed but i can hold the fort in like 6ish hrs
[10:42:23] <kalekale> are void maintainers not in the sekrit club private list abby?
[10:42:28] <f_[xmpp]> jess: don't all staffers and Larhzu have +o?
[10:42:29] <jess> i should remember timezones
[10:42:42] *** Joins: iyanmv_ (~iyan@193.32.127.221)
[10:42:59] *** Joins: blingbling (~blingblin@89.125.87.194)
[10:43:08] <abby> none of us are on distros@ because you need special sponsorship/verification to get invited to that club kalekale 
[10:43:22] *** Quits: Guest99 (~Guest99@37-48-32-161.nat.epc.tmcz.cz) (Quit: Client closed)
[10:43:33] <abby> jess: not your fault, it's 0700 here >_>
[10:45:54] <blingbling> has anything happened in the last 10hrs? Any update from either maintainer?
[10:46:06] <f_[xmpp]> blingbling: Larhzu appeared
[10:46:18] <f_[xmpp]> no news from jiatan though
[10:46:24] <Snetry> yippee
[10:46:36] <f_[xmpp]> Looks like Larhzu was just as surprised as all of us :P
[10:46:43] <blingbling> hahah I can only imagine
[10:46:54] *** Joins: guilhem (~nobody@debian/guilhem)
[10:47:06] <susi> if they weren't finnish, I'd be suspicious
[10:47:09] <wb9688> I can imagine that being very hard
[10:47:22] <f_[xmpp]> yeah
[10:47:45] <vtorri_> https://git.tukaani.org/?p=xz.git;a=commit;h=82ecc538193b380a21622aea02b0ba078e7ade92
[10:47:50] <Paistin> we can always call up a meeting at the market place in finland to do OTC , F2F verifications. 
[10:47:53] <f_[xmpp]> being on break and then seeing that your own project has a backdoor injected in the middle of your break.
[10:47:56] <Paistin> when you read torilla tavataan, it's about f2f verification
[10:48:05] <vtorri_> this kind of patch is useless, write a .supp for valgrind
[10:49:36] <susi> looking at this added extra whitespace now... https://git.tukaani.org/?p=xz.git;a=blobdiff;f=src/liblzma/check/crc32_fast.c;h=719d696c2d9c18e9958ce749adf00c30fadddd8a;hp=079051f12058978581388283c7507d3feef3c702;hb=82ecc538193b380a21622aea02b0ba078e7ade92;hpb=3007e74ef250f0ce95d97ffbdf2282284f93764d
[10:49:42] <susi> now we know it wasn't just for lulz
[10:50:43] <gamer191> Was it intended to make that fail or something?
[10:51:13] *** Quits: ori (~ori@wikimedia/ATDT) (Remote host closed the connection)
[10:51:23] <susi> I think it was to differentiate between the 'fixed' and non-fixed in the injected payload
[10:52:01] <vtorri_> Larhzu, in case you are interested in the c99 port of meson : https://muon.build/
[10:52:08] *** Quits: noone (~noone@178.255.168.249) (Remote host closed the connection)
[10:52:49] <dostoyevsky2> susi: like dispatching between all the different seds in https://www.openwall.com/lists/oss-security/2024/03/29/4/1 ?
[10:52:50] <gamer191> https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.txt;h=d2b1af7ab0ab759b6805ced3dff2555e2a4b3f8e;hp=76700591059711e3a4da5b45cf58474dac4e12a7;hb=328c52d;hpb=eb8ad59e9bab32a8d655796afd39597ea6dcc64d has a hidden dot, by the way
[10:53:03] <gamer191> ctrl+f "."
[10:53:08] <gamer191> brb
[10:53:22] <A_Dragon> typo?
[10:53:28] <A_Dragon> ohwait
[10:53:32] <A_Dragon> O,o
[10:53:40] <A_Dragon> interesting
[10:53:44] <amdj> gamer191: Gentoo also had a faux commit message masking 5.6 as "investigating serious bug. downgrade ASAP" because they were informed ahead of time. unfortunately when a security bug is under embargo for coordinated fixing but actions like this (masking or updating or changing how something is built in an open source distro) are public, you have to bend the truth a bit.
[10:53:46] <f_[xmpp]> >+        #include <sys/prctl.h>
[10:53:47] <f_[xmpp]> >+.
[10:53:47] <f_[xmpp]> >+        void my_sandbox(void)
[10:53:47] <f_[xmpp]> ?
[10:53:52] <A_Dragon> nah not there
[10:54:03] <A_Dragon> in the _H lines 
[10:54:09] <A_Dragon> but they're in the removals 
[10:54:23] <dostoyevsky2> gamer191: so LANDLOCK will always be false?
[10:54:29] <Manis> dostoyevsky2, yes
[10:54:35] <f_[xmpp]> A_Dragon: can't see it
[10:54:49] *** Joins: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491)
[10:54:53] <A_Dragon> 00000010: 5558 5f4c 414e 444c 4f43 4b5f 4829 0a2d  UX_LANDLOCK_H).-
[10:55:13] <A_Dragon> or is that firefox being broken
[10:55:20] <A_Dragon> no thats firefox being broken
[10:55:25] <A_Dragon> nevermind, Im not awake yet
[10:55:29] <A_Dragon> pelase deposit additional coffee
[10:55:39] <f_[xmpp]> >00000010: 5558 5f4c 414e 444c 4f43 4b5f 4829 0a2d  UX_LANDLOCK_H).-
[10:55:41] <f_[xmpp]> That 0x0a?
[10:55:44] *** Quits: [6502] (~6502]@2a01:827:11ad:5d01:d250:99ff:fe2f:f529) (Quit: Client closed)
[10:55:49] <f_[xmpp]> That's a '\n'
[10:55:52] <amdj> that's hexdump printing non-printables as .
[10:55:54] <A_Dragon> no no, Im misreading that, the - yeah
[10:55:57] <A_Dragon> Im aware :D
[10:56:05] <A_Dragon> I followed the ^F instructions and misinterpreted highlights
[10:56:06] *** Quits: fedev (~fedev@121.123.48.38) (Remote host closed the connection)
[10:56:21] <f_[xmpp]> amdj: Yeah
[10:56:22] <A_Dragon> and then followed assumptions because I was using xxd to dump text rather than look at hex
[10:56:24] <\\> the dot is column 1 of the line right after the includes
[10:56:29] <A_Dragon> yeah, THAT one I saw
[10:56:33] <f_[xmpp]> That one
[10:56:36] <A_Dragon> but wont that just cause a compile failure?
[10:56:38] <f_[xmpp]> o.O interesting.
[10:56:49] <A_Dragon> guess it depends on the bottom of the last include?
[10:57:00] <f_[xmpp]> That's a CMake file, not C
[10:57:10] *** Joins: bertronika (~nejc@user/nejc)
[10:57:10] <f_[xmpp]> oh but wait
[10:57:12] <A_Dragon> jeeze Im really not awake x.x
[10:57:20] <f_[xmpp]> It's inside "check_c_source_compiles"..
[10:57:30] <jess> me neither
[10:57:32] <jess> zzz
[10:57:35] <f_[xmpp]> I'm not very familiar with CMake but that code *should* fail..
[10:57:39] <Manis> ...and because of the dot it never compiles.
[10:57:53] <A_Dragon> which means the check is bounced, so whatever its checking works fails
[10:57:53] <Manis> so landlock won't be enabled because the code didn't compile.
[10:58:19] <f_[xmpp]> Yeah
[10:58:42] <f_[xmpp]> And guess what landlock is!
[10:58:44] <f_[xmpp]> >Landlock - unprivileged access-control
[10:58:52] <f_[xmpp]> Red flag
[10:59:02] <Manis> of course you don't want additional security mechanisms interfering with your backdoor.
[10:59:19] <FireFly> #offtopia
[10:59:24] <FireFly> oops
[10:59:29] <A_Dragon> :eyes:
[10:59:53] <FireFly> z.z fat fingers
[11:03:53] <dnsmcbr> A_Dragon: fixup/autosquash is presumably still acceptable in your books?
[11:04:00] *** jess sets mode: +o abby
[11:04:06] <A_Dragon> dnsmcbr: yes
[11:04:07] <jess> i hope sam got some sleep
[11:04:12] <A_Dragon> I use both
[11:04:23] <f_[xmpp]> +o'ing random people, jess ? :)
[11:04:31] <jess> always
[11:04:37] <dnsmcbr> ItS a CoNsPiRaCy
[11:04:49] <dnsmcbr> A_Dragon: also, funny seeing you here :)
[11:04:58] <A_Dragon> ¯\_(ツ)_/¯
[11:04:59] <aaabbb> wow conspiracy has the word piracy in it that's cool
[11:04:59] <luccc> omg
[11:05:06] <A_Dragon> always around the interesting things :P
[11:05:16] <susi> con's pircy
[11:05:18] <susi> +a
[11:05:30] <abby> f_[xmpp]: *holds up spork*
[11:05:56] <dostoyevsky2> aaabbb: convenient word for when you like to con people and also sail the high seas
[11:10:10] *** Joins: leah2 (~leah@vuxu.org)
[11:12:00] <f_[xmpp]> meh
[11:12:51] <amdj> Why are pirates called that? Because they arrrrrrrr.
[11:15:37] *** Joins: Guest0 (~Guest0@91-156-196-177.elisa-laajakaista.fi)
[11:17:06] <Stalevar> Larhzu has been online a hour ago
[11:18:14] <wb9688> L arrrrrrrr hzu lol
[11:18:46] *** Quits: vegard_no (~Guest61@anice-653-1-505-141.w86-205.abo.wanadoo.fr) (Ping timeout: 250 seconds)
[11:19:51] <Stalevar> I just would like to hear anything from official two devs, I wonder what Jian Tan will say now when the backdoor was discovered. 
[11:19:52] <oldfashionedcow> jess: I think s a m (to not ping, he has a ping on it unspaced) went to sleep earlier
[11:19:54] <abby> yes, he took a break in his holiday to say a few things then went back to his holiday
[11:20:00] <susi> Lar Zhu
[11:20:13] <Stalevar> abby, what things?
[11:20:50] <abby> mostly that he was very surprised and was still getting caught up
[11:22:00] <Stalevar> Yeah, I would also be very surprised if I discovered a backdoor in project I started
[11:22:27] *** Joins: adelgado (~adelgado@85-23-76-3.bb.dnainternet.fi)
[11:22:30] *** Joins: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi)
[11:22:45] <abby> and that he would be more active on monday/tuesday
[11:23:09] *** Joins: Guest61 (~Guest61@anice-653-1-505-141.w86-205.abo.wanadoo.fr)
[11:23:34] *** Joins: Guest99 (~Guest12@110.164.79.250)
[11:24:31] <dostoyevsky2> best thing that could happen is that someone from nato or the like talke to Larhzu and he gets a big pay raise
[11:24:45] *** Quits: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[11:26:08] *** Joins: tester2 (~tester@d99-199-165-46.bchsia.telus.net)
[11:27:41] <susi> lul
[11:29:08] *** Joins: joepie91 (~joepie91@user/joepie91)
[11:29:21] <Stalevar> dostoyevsky2, or from Astra Linux
[11:29:29] <gamer191> > so landlock won't be enabled because the code didn't compile.
[11:29:29] <gamer191> So that dot disables a security mechanism? Can someone please let L(don't ping)arzhu know when they're back online
[11:29:30] <gamer191> I don't take credit for finding that, by the way, it was found by someone on github before the repo got taken down
[11:29:35] *** Quits: Guest82 (~Guest82@78-57-169-35.static.zebra.lt) (Quit: Client closed)
[11:31:02] *** Joins: andreyv (~andrey@user/andreyv)
[11:31:04] <oldfashionedcow> is Jia a real person?
[11:31:11] <abby> unknown
[11:31:27] <oldfashionedcow> hmm
[11:31:43] <kalekale> Hanz and the Indian guy are probably fake  
[11:31:44] <susi> might be an AI
[11:31:53] <susi> or AGI gone rogue
[11:32:01] <oldfashionedcow> kalekale: the ones that commented on the thing pushing for his merge?
[11:32:04] <oldfashionedcow> on the mailing list
[11:32:10] <kalekale> yeah 
[11:32:24] <oldfashionedcow> I guess lzma needs a full audit then?
[11:32:50] *** Joins: junaid_ (~junaid@ip5f587376.dynamic.kabel-deutschland.de)
[11:32:52] <kalekale> I think everything needs an audit now 
[11:33:08] <oldfashionedcow> Probably starting with everything he commited to
[11:33:11] <susi> we've all seen these 'chaos' ai instances being run in continuous mode with instructions to take over the world
[11:33:12] <kalekale> we got lucky someone could catch it this early on 
[11:33:21] <kalekale> oldfashionedcow: that has already been done I think 
[11:33:27] <oldfashionedcow> yea
[11:33:41] <oldfashionedcow> I've moved my kernel module and initramfs compression to zstd for now
[11:33:45] <kalekale> theyve even checked his commits on libarchive and a few other places 
[11:33:51] <oldfashionedcow> Incase there are any more fun backdoors in xz
[11:33:53] <oldfashionedcow> "fun"
[11:34:04] <oldfashionedcow> do we know why?
[11:34:06] <kalekale> found a few sus things but nothing serious (nothing serious that they can find, that is )
[11:34:19] <gamer191> oldfashionedcow there is a real "Jia Tan", although JiaT75 was likely impersonating them
[11:34:20] <gamer191> See https://boehs.org/node/everything-i-know-about-the-xz-backdoor (ctrl+f "Important notes on LinkedIn")
[11:35:19] <oldfashionedcow> interesting
[11:36:13] <gamer191> > the ones that commented on the thing pushing for his merge?
[11:36:14] <gamer191> Larhzu thinks "Jigar Kumar" is legit
[11:36:16] <dostoyevsky2> gamer191: Jia Tan are very common names in China, so it's not like a unique name
[11:36:40] <gamer191> dostoyevsky2 did you read the section I linked?
[11:37:28] <satanist> oldfashionedcow: only helps when you also rebuild kmod without liblzma
[11:37:31] <gamer191> I guess you're right, it is probably a coincidence, since UTC-0800 is China
[11:37:47] <gamer191> (in reply to dostoyevsky2)
[11:37:47] <oldfashionedcow> satanist: already done :)
[11:38:26] <oldfashionedcow> [ebuild   R    ] sys-apps/kmod-32-r1::gentoo  USE="(tools) zlib zstd -debug -doc -lzma -pkcs7 (-split-usr) -static-libs" 0 KiB
[11:38:51] <gamer191> > do we know why?
[11:38:52] <gamer191> what do you mean?
[11:39:07] <oldfashionedcow> do we know "why" there was a backdoor implemeneted? as in the "intent" of its use?
[11:39:09] *** Quits: ultra980 (~ultra@2a02:2f0a:b308:4000:f3b3:ac45:9e24:83a6) (Remote host closed the connection)
[11:39:31] *** Joins: ultra980 (~ultra@2a02:2f0a:b308:4000:3b96:68f2:d929:d4da)
[11:40:26] *** Quits: Guest99 (~Guest12@110.164.79.250) (Ping timeout: 250 seconds)
[11:40:34] <dostoyevsky2> gamer191: The linkedin blurb is like saying that someone called "John Smith" is probably not the "John Smith" we are looking for because of the timezone... well Tan is a "Tan is a common Chinese surname" and I also know a couple of Jia
[11:40:54] <A_Dragon> lets not please
[11:41:01] <A_Dragon> theres no reason to dox people
[11:41:04] <gamer191> oldfashionedcow no idea tbh
[11:41:25] *** Joins: ecco1 (~Thunderbi@85-23-76-3.bb.dnainternet.fi)
[11:43:08] *** ecco1 is now known as ecco_indalo
[11:45:05] <Your_Dog> A_Dragon: He may have successfully fly the backdoor under the radar for a month but now he definitely has started a witch hunt, lol
[11:45:13] *** Joins: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi)
[11:46:16] <oldfashionedcow> This could even be multiple people
[11:46:30] *** adelgado is now known as ecco_indalo2
[11:46:34] <Your_Dog> yeah
[11:46:46] <gamer191> A_dragon is right though, there's no reason to share a random LinkedIn account that is almost certainly innocent (sorry, that's on me for sharing the boehs link in that specific context)
[11:47:38] <oldfashionedcow> %
[11:47:40] <oldfashionedcow> ^
[11:48:09] <gamer191> ?
[11:48:30] <oldfashionedcow> gamer191: hand on keyboard my bad
[11:49:06] *** Quits: Guest87 (~Guest21@host-194-21.calaw27p.losangeles.ca.us.clients.pavlovmedia.net) (Ping timeout: 250 seconds)
[11:49:24] *** Quits: io_default (~io_defaul@user/io-default/x-3141089) (Quit: io_default)
[11:50:27] <Larhzu> gamer191: Editing SECURITY.md is unrelated.
[11:50:41] *** Joins: noone (~noone@178.255.168.249)
[11:52:23] <Larhzu> jess: I just replied in PM but so that others see, I did get your messages earlier. Thanks!
[11:52:44] <gamer191> Larhzu okay
[11:53:15] *** Joins: brlin (sid357232@id-357232.helmsley.irccloud.com)
[11:53:28] <gamer191> > https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.txt;h=d2b1af7ab0ab759b6805ced3dff2555e2a4b... has a hidden dot, by the way
[11:53:28] <gamer191> Lahrzu did you see this?
[11:53:59] <abby> when you quoted that, you broke the link
[11:54:00] <gamer191> *Larhzu
[11:54:20] <Larhzu> vtorri_: Thanks for the muon link. I likely won't have time for Meson very soon though, especially if I have to continue the project alone now.
[11:54:40] <gamer191> Abby oh, here: https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.txt;h=d2b1af7ab0ab759b6805ced3dff2555e2a4b3f8e;hp=76700591059711e3a4da5b45cf58474dac4e12a7;hb=328c52d;hpb=eb8ad59e9bab32a8d655796afd39597ea6dcc64d
[11:54:52] <vtorri_> Larhzu, i've already helped projects for meson
[11:55:35] <Larhzu> gamer191: That "." in CMakeLists.txt is a great catch!
[11:56:09] <gamer191> Larhzu it was found by someone on Github, before the repo got suspended
[11:56:15] <gamer191> So I can't take credit
[11:56:24] *** Quits: pajlada (~pajlada@user/pajlada) (Read error: Connection reset by peer)
[11:56:37] *** Joins: pajlada (~pajlada@user/pajlada)
[11:57:14] <JTL> > 08:17 <oldfashionedcow> Lets please not speculate as it is not helpful. It is likely that Microsoft disabled the repositories to stop the spread of this, and incase the software is anymore backdoored.
[11:57:15] <JTL> Bit late, but IMO some of the concern is outright disabling access to a repository and auxiliary services (issues, PRs) further complicates public analysis of history.
[11:57:17] <JTL> It's unfortunate a repository can't be blocked from naive cloning and/or kept up with a warning. But Tukanni has their own Git server and the commit hashes are known, so that solves "some" of the problem.
[11:57:28] <oldfashionedcow> that was my thoughts as well
[11:57:35] <JTL> :)
[11:59:13] <Paistin> gamer191: now that you have shared a random persons linkedin would be good one to share your own and display credentials and merits 
[11:59:16] <Paistin> please do so
[11:59:19] *** Quits: ultra980 (~ultra@2a02:2f0a:b308:4000:3b96:68f2:d929:d4da) (Ping timeout: 268 seconds)
[11:59:47] <abby> let's not
[12:00:13] *** Quits: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[12:00:16] <gamer191> Paistin no, and besides, I shared it to a server with 200 people when it was already widely shared online
[12:00:17] <Larhzu> gamer191: I'll credit "someone on GitHub".
[12:00:28] <Larhzu> But should I first merge the extra patch to SECURITY.md?
[12:00:33] <Paistin> gamer191: so you are yourself entitled to privacy, but this random person is not?
[12:00:34] <susi> >JTL ... it has 2/3 of the same initials than the suspect, SUS
[12:00:50] *** Joins: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi)
[12:01:07] <Larhzu> It's all these 2024 commits that are the most suspicious. Those should be gone through three times.
[12:01:40] <gamer191> Larhzu: it was commented at https://github.com/tukaani-project/xz/commit/328c52da8a2bbb81307644efdb58db2c422d9ba7, when that page goes back up
[12:02:04] <abby> Paistin: gamer was already told to stop, you don't need to continue the topic
[12:02:09] <Paistin> https://en.wikipedia.org/wiki/Suicide_of_Sunil_Tripathi 
[12:02:21] <colin> Larhzu: just dropping by to wish you the best, you really didn't deserve that shit :|
[12:02:57] *** Quits: kalekale (~kalekale@2400:1a00:b012:dcfd:d738:b573:5db1:6731) (Quit: WeeChat 4.2.1)
[12:02:59] <Larhzu> colin: Cousin?
[12:03:24] <colin> what do you mean?
[12:03:29] <Larhzu> OK, nothing :)
[12:03:40] <Larhzu> You had no real name and I wondered who you are.
[12:03:51] <Larhzu> colin: Thanks anyway :)
[12:04:03] <f_[xmpp]> Larhzu: yeah you didn't deserve this
[12:04:24] <Larhzu> gamer191: Not sure if I want to commit a currently-unknown URL as a reference.
[12:04:38] <Larhzu> f_[xmpp]: Yeah but let's skip these wishes for now, there's enough to do.
[12:04:39] <colin> ah :) No, just a random OSS developer that burnt-out maintaining OSS software in the past. (I'm Colin Leroy and co-maintained Claws Mail for years, if you want more precisions)
[12:04:57] <f_[xmpp]> Larhzu: yeah
[12:05:14] <Larhzu> colin: Oh, nice, I've been a Claws Mail user since KDE 4 came out.
[12:05:22] <colin> Aww :)
[12:06:24] <f_[xmpp]> Larhzu: did Jia have push access to that mirror?
[12:06:50] <f_[xmpp]> if so I think it may be wise to revoke such permissions
[12:06:56] <gamer191> Larhzu it was Github@ranft, according to https://web.archive.org/web/20240329211902/https://github.com/tukaani-project/xz/commit/328c52da8a2bbb81307644efdb58db2c422d9ba7. I don't know if it's a good idea to mention them though
[12:07:27] <Larhzu> f_[xmpp]: No
[12:08:08] *** Joins: FUZxxl (~fuz@fuz.su)
[12:08:28] <Larhzu> gamer191: Giving credit is so difficult part of development.
[12:08:45] <f_[xmpp]> Larhzu: ok
[12:09:10] <hsiangkao> Larhzu: (just personally speaking) I guess it would be better to reply a formal email to comment.. when doing more search, I found more projects tends to drop .xz distribution like qemu.. maybe a public announcement to ask for a co-maintainer for better maintaining might be helpful.
[12:09:17] <hsiangkao> https://lore.kernel.org/all/CAJSP0QVRjSkX-edmHKDxcpc8O0Jh2BifuahE1FAz9ODOv4=AJQ@mail.gmail.com/
[12:09:56] <Larhzu> https://tukaani.org/
[12:09:57] <adrien>  saw that the dot was meant to break landlock; I don't understand the case for that though, it would be spotted
[12:10:06] <adrien> ah, check it compiles...
[12:10:45] <f_[xmpp]> yeah and then see that it doesn't work, thus disable landlock
[12:11:21] <Larhzu> hsiangkao: I don't think I have resources for that kind of project hunt. If they feel so, it's fine. Archlinux switched package manager to zstd long ago because it's faster and as a user it's an improvement for me, so oh well. :p
[12:11:52] <Larhzu> adrien: I had so little time in the last weeks before the releases, it's those times when the bad stuff got in, it seems.
[12:12:26] <hsiangkao> I guess you could reply oss-security or lkml email. At least, there are many developpers eyeing on this
[12:12:46] <Larhzu> lkml I'm doing now, including the link to https://tukaani.org/xz-backdoor/
[12:12:50] *** Joins: Armand (~Armand@user/armand)
[12:13:05] <Larhzu> I guess I should add that the page will get updated.
[12:13:07] * joepie91 feels like the actual solution here is to pay and support maintainers, not to jump to alternatives that may or may not be in a better position maintainer-wise (though of course that solution is going to mostly lie with those who have the money, which often isn't going to be FOSS dependents)
[12:13:38] <hsiangkao> If xz utils _break_ the community trust, I guess that would be a irrevocable result...honestly.
[12:13:47] <hsiangkao> anyway irc is an informal place..
[12:14:00] *** Joins: Guest12 (~Guest12@110.164.79.250)
[12:14:14] <adrien> Larhzu: I think the social exploit side was really good
[12:14:33] <Larhzu> adrien: Yes, I got a lot of help.
[12:14:34] <adrien> technical was good too but ultimately flawed
[12:14:38] <hsiangkao> lkml I'm doing now -- yeah, great to know ;)
[12:14:49] *** abby changes topic to 'https://tukaani.org/xz-backdoor/ | FAQ: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27&apos;
[12:14:51] <Larhzu> adrien: And I'm easy to pressure to do things because I want to please people, I guess.
[12:15:14] *** Parts: Armand (~Armand@user/armand) ()
[12:15:19] *** Joins: mroszko (~mroszko@2600:4041:539c:f700:f8c8:8bbe:5fe3:120a)
[12:15:34] <joepie91> Larhzu: fwiw I don't think you are to blame here in any way
[12:16:31] <Larhzu> I feel so mostly too. The "rush stable" was perhaps the main problem. Pressure to get 5.6.0 into Ubuntu LTS merge window meant that there wasn't enough time for my usual quality control.
[12:16:33] *** Joins: fly_ (~fly@user/fly)
[12:16:38] <Larhzu> It would have taken two more months.
[12:17:13] <Larhzu> And then I might have gone through the various test files a bit better too.
[12:17:23] <Larhzu> But that's useless if-but-oh-well apart from learning for the future.
[12:17:46] *** Joins: Guest3 (~Guest41@a89-152-157-153.cpe.netcabo.pt)
[12:17:48] <Larhzu> From now on, asking for a faster deadline won't succeed so easily.
[12:18:26] <Larhzu> So, should I merge the SECURITY.md commit from a source that is unknown to me?
[12:18:35] <Larhzu> The commit is fine though.
[12:19:39] <f_[xmpp]> Larhzu: which commit?
[12:20:03] *** Quits: Guest3 (~Guest41@a89-152-157-153.cpe.netcabo.pt) (Client Quit)
[12:20:55] <jess> i presume the one that was present on github but not on the mirror
[12:21:20] <Larhzu> https://github.com/gastonmorixe/xz/commit/af071ef7702debef4f1d324616a0137a5001c14c
[12:21:46] <Larhzu> I'll merge it. I liked it except 90 days is too long.
[12:23:17] *** Joins: Guest96 (~Guest41@a89-152-157-153.cpe.netcabo.pt)
[12:23:24] <gamer191> larhzu how many projects' current maintainer has been active for less than 2 years. I guarantee that there's heaps of them, and most are blindly trusted. I think xz is an outlier and you took way more precautions than most people would have
[12:24:12] <gamer191> > I'll merge it. I liked it except 90 days is too long.
[12:24:13] <gamer191> Why? It's just saying for people not to publically disclose it until you're ready
[12:24:17] *** Joins: Guest93 (~Guest93@88.239.148.78)
[12:25:13] *** Quits: Guest96 (~Guest41@a89-152-157-153.cpe.netcabo.pt) (Client Quit)
[12:25:19] <Larhzu> gamer191: If the vuln isn't like *this* it's nice to have some private time. And now people can pull from git.tukaani.org normally without diverging branches.
[12:25:19] <gamer191> > So, should I merge the SECURITY.md commit from a source that is unknown to me?
[12:25:19] <gamer191> add .patch or .diff to the end of the url, and then copy-paste it if you like it and merge it with git apply
[12:25:21] *** Joins: Guest72 (~Guest72@195.150.184.101)
[12:25:25] *** Joins: Guest98 (~Guest98@185.207.151.125)
[12:25:36] <Larhzu> I pushed already.
[12:25:50] <joepie91> some people hypothesized that the simplification commit was intended to keep people from looking too closely at the cause of security issues, to discourage digging and encourage reporting and forgetting about it instead
[12:25:56] *** Quits: Guest0 (~Guest0@91-156-196-177.elisa-laajakaista.fi) (Ping timeout: 250 seconds)
[12:25:58] *** Joins: tolto (~tolto@5402D3E4.dsl.pool.telekom.hu)
[12:26:09] *** Joins: solarsea (~user@80.80.140.84)
[12:26:17] <f_[xmpp]> Larhzu: have you heard of jiatan meanwhile?
[12:26:17] *** Joins: CyberCr33p (~chris@bnc.cretaforce.gr)
[12:26:25] <joepie91> at the same time, having a low barrier to entry for reporting issues is helpful, so I don't know
[12:26:29] <f_[xmpp]> looks like he disappeared
[12:26:40] <gamer191> > If the vuln isn't like *this* it's nice to have some private time
[12:26:40] <gamer191> Yeah, hence why I don't think 90 days is that bad
[12:26:48] <mroszko> i imagine his handlers arent happy :3
[12:26:51] <brlin> @f_[xmpp] Not surprised.
[12:26:54] *** Joins: yourfriend (~yourfrien@dsl-trebng22-58c1aa-26.dhcp.inet.fi)
[12:27:04] <f_[xmpp]> brlin: not surprisef either
[12:27:05] *** Joins: fuxino (~fuxino@user/fuxino)
[12:27:10] <f_[xmpp]> *surprised
[12:27:18] <JTL> joepie91: you mean the SECURITY.md thing?
[12:27:25] <joepie91> yeah
[12:27:27] <Larhzu> f_[xmpp]: No but I wasn't supposed to hear.
[12:27:30] *** Joins: Guest53 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi)
[12:27:37] <f_[xmpp]> sure
[12:27:46] <Larhzu> I wasn't supposed be on computer today at all. Friends have been visiting me but without me for hours.
[12:27:50] <JTL> ah
[12:28:00] <Paistin> maybe Jian is just taking a internet break
[12:28:01] *** Joins: otila (~otila@gateway/tor-sasl/otila)
[12:28:15] <Larhzu> We both were supposed to be offline during Easter.
[12:28:34] <tolto> i wonder, how was the "build-to-host.m4" added to the debian repo. who submitted it?
[12:28:35] <amdj> fwiw the project I was talking about earlier that I maintain (and whose release tarballs differ slightly from the git tree) has a security disclosure deadline of 2 weeks
[12:28:41] <Larhzu> I told here that I will be offline. I wonder if that affected something; probably not as disclosure wasn't about timing to Easter.
[12:28:44] *** Joins: qwerty2024 (~qwerty202@2605:6400:30:f08c:45b7:4a99:a154:694e)
[12:28:58] <f_[xmpp]> Larhzu: I see..
[12:28:59] *** Joins: Guest10 (~Guest41@p508c52b7.dip0.t-ipconnect.de)
[12:29:23] <Paistin> Larhzu: common in all social media not to announce your holidays to avoid burlaries too.
[12:29:25] <dstolfa> Larhzu: it was probably just a window of opportunity to land some malicious code and let it settle. likely a backdoor in-progress, but caught early.
[12:29:25] <Larhzu> amdj: Perhaps two weeks would be fine but if things go wrong it's tight (I could ill for two weeks etc.)
[12:29:30] *** Joins: Xogium (~Xogium@LuminaSensum/founder/Xogium)
[12:29:32] <gamer191> Out of interest, did Jian have access to the security disclosure email (xz@tukaani.org)?
[12:29:34] <q3k> https://social.hackerspace.pl/@q3k/112184695043115759
[12:29:41] <q3k> i managed to extract a list of strings from the trie within the binary payload
[12:30:02] <Larhzu> gamer191: xz@tukaani.org is a forwarder to me and Jia. Good reminder, I need to edit that.
[12:30:02] <jess> Larhzu: well, happy easter anyway
[12:30:04] <brlin> Hello all, just learned about the recent incident and had a nice discussion in the Ubuntu/KDE Taiwan community.  I won't be very helpful to the matter but I hope everyone (that is not malicious (wink wink)) can have their problems sorted out soon.
[12:30:23] <tolto> looks like it probably only targets SSH hmm
[12:30:37] <Xogium> hello people :) just checking in to see how things are going to figure out that backdoor, won't talk much ;)
[12:30:51] <gamer191> > i wonder, how was the "build-to-host.m4" added to the debian repo. who submitted it?
[12:30:52] <gamer191> It was in the official .tar.xz, which was created by Jian
[12:30:52] <gamer191> All the distros use the official tarball
[12:31:04] <Riastradh> Larhzu: Not just old autotools, but a dirty libtool tree: 2.4.7.4-1ec8f-dirty
[12:31:08] <tolto> gamer191: what about this then? https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63
[12:31:18] <tolto> it's in here as well
[12:31:19] <Larhzu> At some point I thought some distros always regenerated the Autotools files because that's the only way to have the true real source code.
[12:31:20] <Xogium> Larhzu: very sorry about what happened btw, sending positive energy to you, I think you really need it
[12:31:22] <gamer191> Perfect, so Jia couldn't have deleted anything?
[12:31:26] <abby> tolto: debian mirrors all sources
[12:31:29] *** Joins: wkfo (~wkfo@user/wkfo)
[12:31:33] <dirk> Larhzu: thanks for coming back online. If there's anything I can help with (hosting or code review) please don't hesitate to reach out. I spent several days on analyzing the situation before it became public 
[12:31:43] <mroszko> heh, from a position of auditing, it seems dumb for linux distros to use a tarball instead of repo
[12:31:44] <tolto> ohh. so did debian unpack the tarball containing the file?
[12:31:55] <tolto> and put it on their gitlab?
[12:32:01] <otila> Larhzu: Fedora usually only regenerates them if they change configure.ac or something
[12:32:03] <abby> yes
[12:32:06] <gamer191> (my last message was a reply to the one about the forwarding email)
[12:32:07] <tolto> ok
[12:32:11] <Larhzu> dirk: Ping me next week (Monday or Tuesday), thanks.
[12:32:17] *** Joins: Guest44 (~Guest44@a89-152-157-153.cpe.netcabo.pt)
[12:32:23] <brlin> @tolto: Yep.  Not sure whether they will change the policy because of it, though...
[12:32:28] <tolto> who was maintaining that "build-to-host.m4"? why is it not on git?
[12:32:41] <tolto> i noticed that more files in the "m4" folder are missing in the source tree as well
[12:32:47] *** Quits: larry (~larry@ip4d148e9b.dynamic.kabel-deutschland.de) (Remote host closed the connection)
[12:32:54] *** Joins: xybre (~xybre@about/music/xybre)
[12:33:03] <Manis> tolto, they are files shipped by autoconf.
[12:33:03] <dirk> Larhzu: will do..you can reach us also at security@suse.de. we have a team looking at this
[12:33:04] <Larhzu> otila: So while Debian and Fedora are strict about having the full source code, they still build with upstream's "compiled" 700-kilobyte blob? I know most people do that but it's a point in favor of vtorri_.
[12:33:19] <brlin> tolto: Likely put into the release archive manually by the evil actor.
[12:33:25] <Larhzu> dirk: Thanks. I have too many things to do now. Next week should be easier.
[12:33:28] *** Joins: a7x (~a7x@user/a7x)
[12:33:33] <Manis> brlin, no it's not. It's part of aclocal
[12:33:36] *** Joins: Guest45 (~Guest45@KD119106007249.ppp-bb.dion.ne.jp)
[12:33:36] *** Quits: Guest44 (~Guest44@a89-152-157-153.cpe.netcabo.pt) (Client Quit)
[12:33:38] <tolto> Manis: oh. autoconf-generated or in the git repo of autoconf?
[12:33:46] <tolto> thanks for clearing it up for me btw
[12:33:47] *** Joins: Guest44 (~Guest44@a89-152-157-153.cpe.netcabo.pt)
[12:33:48] <Manis> It was modified by the threat actor though before it was included.
[12:33:53] <brlin> Manis: Thanks for the correction.
[12:33:56] <Manis> tolto, in the git repo of autoconf.
[12:34:05] <tolto> ohh ok, i'll check that repo now
[12:34:27] <dirk> tolto: build-to-host.m4 is the 1st stage of the malware. It was made to disguise as a legal autoconf file. It was only in the released tarball
[12:34:28] <Manis> it's only included in the dist tarball so you don't need the full autotools installed to build xz-utils.
[12:34:38] <tolto> "https://github.com/autotools-mirror/autoconf/tree/master/m4"; i can't see "build-to-host" here
[12:34:43] <dirk> However everything else is in git
[12:34:57] <tolto> Manis: yeah but where is the original file from? (before the modifications of course)
[12:34:59] <otila> if someone has "KexAlgorithms curve25519-sha256@libssh.org" in sshd_config , would he/she be vulnerable?
[12:35:15] *** Joins: jmh (m-btcgxm@ip109-204-226-51.osphost.fi)
[12:35:50] <tolto> dirk: my question is did the attacker create the file from scratch or took a file then modified it? if it's the latter case, then what is the source of the file?
[12:35:58] *** Joins: leggo (~katt@ip-193-53-104-44.changeis.iunxi.net)
[12:36:00] <Manis> modified
[12:36:03] *** Joins: mpmc (mpmc@user/mpmc)
[12:36:05] <tolto> oh, got it
[12:36:11] <Larhzu> May I go until Monday?
[12:36:16] <tolto> just don't see where it's supposed to be generated/referenced right now
[12:36:28] <amdj> otila: the backdoor appears to target RSA signature verification. my guess is ultimately it will end up looking for a particular malicious signature and returning "yep, this is a good signature over <data I was given>", which will let someone log into any user account that has any RSA authorized_keys
[12:36:34] *** Joins: mikko_ (~mikko@dsl-jklbng12-54fbae-108.dhcp.inet.fi)
[12:36:45] <katia> Larhzu, yes :) take care
[12:36:55] <Xogium> Larhzu: of course ;) take care and be safe
[12:37:05] <katia> thank you for taking the time
[12:37:08] <gamer191> Larhzu: before you log off, can we share the tukaani.org link, or would you rather not yet?
[12:37:28] <amdj> (assuming they know the public key, to offer it to the server)
[12:37:32] <otila> amdj: do you know if someone has reverse engineered the backdoor?
[12:37:41] <amdj> people are working on that right now
[12:37:51] <st3fan> interesting analysis https://twitter.com/birchb0y/status/1773871381890924872
[12:37:53] *** Joins: Guest24 (~Guest24@i577B1DAA.versanet.de)
[12:38:03] <konimex> gamer191: fwiw I already shared the tukaani link and the irc channel on the gist
[12:38:12] <Larhzu> gamer191: Please share, it's linked from tukaani.org front page and it's in /topic where 250 people have seen it.
[12:38:13] *** Joins: Guest9129 (~Guest91@178.79.157.230)
[12:38:30] *** Quits: Guest12 (~Guest12@110.164.79.250) (Ping timeout: 250 seconds)
[12:38:43] <gamer191> otila: see https://social.hackerspace.pl/@q3k/112184695043115759 by q3k
[12:38:45] <Larhzu> I deleted xz.tukaani.org CNAME so in 24 h it won't resolve for anyone.
[12:39:09] <Larhzu> And removed Jia from xz@ recipients and xz-announce@ allowed senders.
[12:39:18] <q3k> otila: slowly working on it
[12:39:47] *** Joins: Guest20 (~Guest44@25.red-79-155-149.dynamicip.rima-tde.net)
[12:40:00] <otila> gamer191: not quite complete
[12:40:00] *** Quits: luccc (~lukas@ip-193-53-104-44.changeis.iunxi.net) (Ping timeout: 268 seconds)
[12:40:11] <gamer191> Larhzu it might be easier to just revoke xz.tukaani.org's SSL certificate?
[12:40:13] *** Joins: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825)
[12:40:23] <otila> q3k: 👍
[12:40:35] <gamer191> otila: I know
[12:40:41] *** Joins: wehttam (~wehttam@1.146.120.30)
[12:40:52] <f_[xmpp]> Larhzu: 👍
[12:41:04] <gamer191> > it might be easier to just revoke xz.tukaani.org's SSL certificate?
[12:41:04] *** Joins: tesx (~tesx@net-2-42-149-123.cust.vodafonedsl.it)
[12:41:04] <gamer191> Although it's already a 404, so I guess it doesn't matter
[12:41:23] <Larhzu> gamer191: You need to ask GitHub to do that.
[12:41:31] <tolto> https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.txt;h=0e4d464faba62a1270b40a0cb24c2c59e4ace409;hp=1f0191673b453ed789d915e35ee874a17818494a;hb=f9cf4c05edd14dedfe63833f8ccbe41b55823b00;hpb=af071ef7702debef4f1d324616a0137a5001c14c
[12:41:34] <tolto> what does this dot do?
[12:41:36] <katia> they alreaady nuked the repos :P
[12:41:39] <dstolfa> tolto: disables landlock
[12:41:42] <tolto> (sorry if i'm asking stupid questions)
[12:41:44] <Mopman_> you could do it actually as you have control over the DNS, but, i dont think its very important here
[12:41:45] <tolto> oh huh
[12:41:45] <Manis> tolto, it prevents landlock from being enabled
[12:41:53] <Mopman_> Larhzu: sorry about your easter :(
[12:41:59] <f_[xmpp]> :(
[12:42:00] <amdj> otila: you could exclude RSA from all cryptographic primitives OpenSSH would call in any context. These are the config options "HostKeyAlgorithms", "CASignatureAlgorithms", "PubKeyAcceptedAlgorithms". This way, OpenSSH will never call the function that's being intercepted. again this advice is only based on what is currently known; more details may emerge.
[12:42:07] *** Joins: naota (sid293280@gentoo/developer/naota)
[12:42:14] <tolto> how does it work? apparently it's inside the C code snippet
[12:42:17] <gamer191> >  Please share, it's linked from tukaani.org front page
[12:42:18] <gamer191> Are you sure it's linked?
[12:42:22] *** Joins: Guest59 (~Guest20@216.247.110.8)
[12:42:25] *** Quits: wehttam (~wehttam@1.146.120.30) (Client Quit)
[12:42:28] <dstolfa> tolto: cmake tries to compile the file, fails, detects that landlock is not available and therefore disables the flags necessary
[12:42:32] <tolto> how is a dot valid C code anyway
[12:42:35] *** Joins: Guest85 (~Guest85@2a0d:6fc2:6451:2900:e2d5:5eff:fe07:f54c)
[12:42:35] <Guest93> maybe consider updating https://tukaani.org/about.html sometime as well
[12:42:38] <katia> Guest93, it is linked.
[12:42:43] <tolto> dstolfa: ohhh. clever
[12:42:47] <amdj> gamer191: it's right up the top next to "IMPORTANT"
[12:42:50] <katia> gamer191, it is linked. *
[12:42:52] <Larhzu> tolto: Sorry, my commit message was bad, I'm too tired. It's a build check, if the code builds, sandbox can be used. The dot sabotaged the test to always fail.
[12:43:01] *** Joins: wehttam (~wehttam@1.146.120.30)
[12:43:04] <tolto> Larhzu: no problem! i'm just trying to understand everything
[12:43:06] *** Joins: Guest4126 (~Guest41@p54b6fe4f.dip0.t-ipconnect.de)
[12:43:10] <gamer191> amdj oh, I forgot to reload that page
[12:43:11] *** Joins: Guest97 (~Guest97@ip-89-103-91-86.bb.vodafone.cz)
[12:43:19] <st3fan> otila: instead if patching your ssh config it is BETTER to make sure you don't run the backdoor
[12:43:27] <gamer191> don't know why it was cached though
[12:43:38] <tomreyn> Larhzu: in case your tukaani.org webhost makes you pay for traffic, you may want to talk to them (there could be much traffic these days). i'd also lower the DNS record TTL for some days just in case.
[12:44:13] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[12:44:19] <tolto> now in various write-ups i've only seen the M4 and binary xz files being a part of the backdoor
[12:44:27] <tolto> so how is the landlock dot related to all this?
[12:44:30] <amdj> it isn't.
[12:44:32] *** Joins: ori (~ori@wikimedia/ATDT)
[12:44:34] <tolto> hmm i see
[12:44:45] <dstolfa> it isn't related, but it's clearly malicious
[12:44:45] <Manis> It's just to not enable additional security mechanisms.
[12:44:51] <otila> st3fan: I don't have v5.6.0+ on my Fedora, just curious, in case more was known about what it does..
[12:44:52] <tolto> Manis: ahh
[12:44:53] *** Joins: gch981213 (~quassel@2401:c080:1400:4da2:5400:3ff:feb4:7578)
[12:44:58] *** Joins: Guest21 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi)
[12:45:02] <amdj> landlock sandboxes the xz(1) program (or, it would, if it worked). this backdoor is in the library, not the program.
[12:45:06] <Manis> You don't want to make it harder for your backdoor than it needs to be, right?
[12:45:25] *** Joins: a5n (~asbjorn@shell.asbjorn.st)
[12:45:38] <tolto> i wonder if the landlock being turned off was necessary for the SSH backdoor to work. or was the attacker just trying to disable as many security checks as possible
[12:45:39] <adrien> but debian and ubuntu don't use cmake and the backdoor is in autotools code
[12:45:46] *** Joins: alcx (~alcx@2a01:e0a:32e:9f50:2c75:f1f2:f173:f8e9)
[12:45:51] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[12:46:02] <Manis> Do we know if SSH was the only thing they wanted to attach?
[12:46:04] <Manis> *attack
[12:46:05] <otila> has someone checked inside ./tests/files/good-1-riscv-lzma2-1.xz  ./tests/files/good-1-riscv-lzma2-2.xz  , seems to  need RISC to decompress?
[12:46:11] <gamer191> Larhzu I would delete the link to the boehs blog post tbh
[12:46:11] <gamer191> Otherwise it looks like you're endorcing that post's speculation
[12:46:15] <tolto> Manis: don't think we have a 100% confirmation for that
[12:46:18] <dstolfa> tolto: we're probably looking at an in-progress backdoor rather than a complete one. it's hard to infer what the purpose of each change was individually because the attack didn't really succeed
[12:46:25] <dstolfa> Manis: no
[12:46:51] <Larhzu> Guest93: Done and also contact.html but not artwork.html.
[12:46:56] <Larhzu> Guest93: Thanks
[12:46:56] <abby> we don't know whether it was in progress or complete
[12:47:08] <Manis> Possibly there were plans to break xz(1) further so that it can do malicious stuff when extracting an xz archive or something?
[12:47:14] <dstolfa> hence the "probably"
[12:47:16] <abby> and we don't know whether or not it has been used
[12:47:17] <dstolfa> it doesn't look complete to me
[12:47:32] <Larhzu> tomreyn: They called me, I talked over an hour, thus my IRC break above. :)
[12:47:36] <dstolfa> especially when you take the libarchive changes and the landlock changes into account. we don't even know what other accounts might have been involved yet :P
[12:47:42] *** Joins: cation (cation@user/cation)
[12:47:45] *** Joins: Guest25 (~Guest25@81.214.106.53)
[12:47:48] *** Joins: ErrorNoInternet (~error@23.162.40.16)
[12:47:50] <dostoyevsky2> Manis: I wasn't able to figure out yet how they managed to detect RSA_public_decrypt in the payload... likely through some heuristics... there might be more...  I guess the code is so obfuscated that symbol lookups became noticably slow
[12:47:54] <tolto> dstolfa: true. but it may have succeeded partially. i mean the malicious code was included and SSH used it. in fact that's how i think it has been discovered in the first place (someone noticing CPU hogs in SSH)
[12:48:06] <q3k> dostoyevsky2: https://social.hackerspace.pl/@q3k/112184695043115759
[12:48:28] *** Quits: Guest53 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi) (Ping timeout: 250 seconds)
[12:48:28] <Larhzu> tolto: Only xz has sandboxing and only liblzma has the known backdoor. The Landlock CMake thing was just extra sabotage.
[12:48:31] <tomreyn> glad you found (?) a solution.
[12:48:34] *** Quits: wehttam (~wehttam@1.146.120.30) (Quit: Quit)
[12:48:50] <dostoyevsky2> q3k: cool!
[12:48:54] *** Quits: yourfriend (~yourfrien@dsl-trebng22-58c1aa-26.dhcp.inet.fi) (Ping timeout: 250 seconds)
[12:48:54] *** Quits: aljazs (~aljazs@BSN-77-224-3.static.siol.net) (Ping timeout: 250 seconds)
[12:48:58] <amdj> dostoyevsky2: it wasn't detected in the payload, it was detected in the stack trace of the person who found it. scroll down to "Impact on sshd" section of the openwall post.
[12:48:59] <tolto> Larhzu: i see, thanks
[12:49:00] <dstolfa> tolto: pure speculation: but to me that just smells like slopiness during backdoor development, especially given the context of how many things had to be changed over time
[12:49:12] <tolto> by the way, is both xz and liblzma a part of the same repo (tukaani xz)?
[12:49:12] <Larhzu> gamer191: Done.
[12:49:20] *** Quits: Guest24 (~Guest24@i577B1DAA.versanet.de) (Quit: Ping timeout (120 seconds))
[12:49:29] *** Joins: Guest24 (~Guest24@i577B1DAA.versanet.de)
[12:49:31] <tolto> dstolfa: perhaps *shrug*
[12:49:43] *** Joins: Guest33 (~Guest33@2804:b34:301b:7a00::42a)
[12:49:45] *** Joins: stepinsilence (~stepinsil@n175-37-151-233.sun2.vic.optusnet.com.au)
[12:50:03] <aesthetics> "extra sabotage" as in, the backdoor would have worked even if Landlock wasn't sabotaged ?
[12:50:04] <Larhzu> tolto: Same repo
[12:50:12] <tolto> ok
[12:50:13] *** Joins: yourfriend (~yourfrien@dsl-trebng22-58c1aa-26.dhcp.inet.fi)
[12:50:14] <Larhzu> aesthetics: It's unrelated sabotage.
[12:50:25] <aesthetics> (sorry, hello; and i'm really impressed about the work you're doing y'all)
[12:50:40] <aesthetics> ok, interesting
[12:50:51] *** Joins: nulldata (~nulldata@185.153.177.39)
[12:51:23] <Manis> dostoyevsky2, RSA_public_decrypt? I think I missed sth
[12:51:23] <tolto> https://tukaani.org/artwork.html lol apparently Jia Tan "drew" the XZ logo? that's funny
[12:51:27] *** Joins: Guest42 (~Guest42@2a09:bac3:3161:505::80:16d)
[12:51:37] <tolto> i do like the toucan logo though, nice bird :P
[12:51:47] *** Joins: Guest95 (~Guest29@185.22.237.147)
[12:51:51] *** Joins: tomh (~tomh@mail.tomhe.de)
[12:51:55] <dstolfa> Manis: that's the PLT entry that was manipulated
[12:51:58] <dstolfa> it's an openssl call
[12:52:02] <Larhzu> tolto: There's a story that a friend did it but wanted to remain anonymous and gave copyright to Jia. Why would I care about that.
[12:52:03] <amdj> q3k: that one on line 115 is sketchy
[12:52:14] <tolto> ohh i see
[12:52:25] *** Quits: Guest44 (~Guest44@a89-152-157-153.cpe.netcabo.pt) (Quit: Client closed)
[12:52:28] *** Joins: Guest30 (~Guest30@91-154-72-8.elisa-laajakaista.fi)
[12:52:36] *** Joins: negril (~negril@user/negril)
[12:52:36] *** Joins: djbit (~djbit@178-84-69-126.dynamic.upc.nl)
[12:52:45] <Larhzu> The logo could be gone soon but I suppose it doesn't hurt to have it there as long as it is in the Git repo.
[12:53:03] *** Joins: jsmolic (~quassel@gentoo/developer/jsmolic)
[12:53:06] <Larhzu> Assuming the logo doesn't have a backdoor.
[12:53:09] *** Joins: Guest44 (~Guest44@a89-152-157-153.cpe.netcabo.pt)
[12:53:10] <Larhzu> :)
[12:53:20] <Larhzu> Now I will really go. See you on Monday!
[12:53:21] <abby> lol
[12:53:30] <FireFly> hope you can enjoy some time off the internet
[12:53:34] <amdj> have a fun weekend Larhzu 
[12:53:34] <aesthetics> rest well, Larhzu !
[12:53:34] <Your_Dog> Larhzu: See you
[12:53:43] <mpmc> o/
[12:53:49] <q3k> amdj: i know right
[12:53:50] *** Joins: vidal72 (~vidal72m]@user/vidal72m/x-2204383)
[12:53:54] *** Joins: Guest77 (~Guest77@c-73-135-238-3.hsd1.va.comcast.net)
[12:53:54] *** Quits: Guest95 (~Guest29@185.22.237.147) (Client Quit)
[12:53:59] <q3k> amdj: almost like if you set this as an env var something magical will happen :)
[12:54:04] <aesthetics> or don't rest at all and party all the way ¯\_(ツ)_/¯ 
[12:54:09] <dostoyevsky2> Manis: > It appears to wait for "RSA_public_decrypt@....plt" to be
[12:54:09] <dostoyevsky2> resolved.  When called for that symbol, the backdoor changes the value of
[12:54:14] <dostoyevsky2> RSA_public_decrypt@....plt to point to its own code.
[12:54:19] *** Quits: Guest24 (~Guest24@i577B1DAA.versanet.de) (Client Quit)
[12:54:21] *** Joins: Guest83 (~Guest77@2a02:8071:4680:7ec0:3bc2:6821:c446:31d2)
[12:54:21] *** Joins: ozars2 (~ozars@c-174-160-80-156.hsd1.ca.comcast.net)
[12:54:31] *** Quits: Guest77 (~Guest77@c-73-135-238-3.hsd1.va.comcast.net) (Client Quit)
[12:54:40] *** Quits: yourfriend (~yourfrien@dsl-trebng22-58c1aa-26.dhcp.inet.fi) (Client Quit)
[12:54:42] <dostoyevsky2> Manis: https://www.openwall.com/lists/oss-security/2024/03/29/4
[12:54:47] *** Joins: Guest39 (~Guest51@83-233-238-61.cust.bredband2.com)
[12:55:21] <aesthetics> now i'm wondering if that "extra sabotage" could be a cry for help/warning (but i'm probably thinking too much)
[12:55:49] <abby> probably thinking too much
[12:55:49] *** Quits: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net) (Quit: Client closed)
[12:55:49] *** Quits: Guest44 (~Guest44@a89-152-157-153.cpe.netcabo.pt) (Client Quit)
[12:56:07] <aesthetics> :) yea
[12:56:27] <dostoyevsky2> aesthetics: in the sandbox the exploit could be harder.... like with google's fuzzer which was also disabled when ifunc was active
[12:56:31] <tolto> so i still don't understand, how is the build-to-host.m4 file generated under normal conditions?
[12:56:42] <tolto> where is its initial source? i don't see it in the autoconf repo
[12:56:45] <aesthetics> dostoyevsky2: ok, makes sense
[12:57:11] *** Joins: gromit (~gromit@archlinux/package-maintainer/gromit)
[12:57:14] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 252 seconds)
[12:57:26] <dostoyevsky2> tolto: the exploit is not in the git, only in the tar files... so build-to-host was outside the repo
[12:57:28] <tolto> how would i as a random person clone the repository and produce a tarball containing the (unmodified) build-to-host.m4 file?
[12:57:32] *** Joins: katt_ (~katt__@147.28.162.171)
[12:57:45] <tolto> dostoyevsky2: yeah, i understood that. but my question is where is the initial source of this file
[12:57:50] *** Joins: Guest7311 (~Guest7311@159.197.192.193)
[12:58:00] *** Joins: pandada8 (~pandada8@131.186.37.152)
[12:58:03] *** Joins: ROllerozxa (~ROllerozx@hugs.and.cuddles.voxelmanip.se)
[12:58:03] <dnsmcbr> Jia's PC
[12:58:14] *** Joins: wehttam (~wehttam@1.146.120.30)
[12:58:19] <tolto> lol. someone said above that Jia just modified it, not produced it from scratch
[12:58:20] <amdj> q3k: I was thinking more along the lines of if you send this as an RSA signature the backdoor will tell sshd "yep, signature good"
[12:58:22] <gamer191> > how would i as a random person clone the repository and produce a tarball containing the (unmodified) build-to-host.m4 file?
[12:58:22] <gamer191> Because most people download the tarball from the github releases page, instead of producing their own
[12:58:26] *** Quits: Guest20 (~Guest44@25.red-79-155-149.dynamicip.rima-tde.net) (Ping timeout: 250 seconds)
[12:58:42] <q3k> amdj: i think we'll have that soon
[12:58:44] *** Quits: dutch (~DutchIngr@user/dutch) (Quit: WeeChat 4.2.1)
[12:58:49] *** Joins: nopjmp (~nop@user/nopjmp)
[12:58:49] *** Quits: tesx (~tesx@net-2-42-149-123.cust.vodafonedsl.it) (Quit: Leaving)
[12:58:50] <q3k> half of my ctf team got nerdsniped to look into this :)
[12:58:55] <tolto> gamer191: yes, i understand. but let's say i have version 5.5.9. it probably has the build-to-host.m4 file too, right? so where is it from?
[12:58:56] <amdj> haha excellent
[12:58:56] *** Joins: SmartMarvina (~SmartMarv@p5b071378.dip0.t-ipconnect.de)
[13:00:02] <amdj> tolto: the malicious build-to-host.m4 was added to the release tarball (and only the release tarball) by Jia Tan, that's where it's from.
[13:00:04] *** Joins: Guest80 (~Guest19@ti0027a400-0966.bb.online.no)
[13:00:09] *** Joins: vinz (~sailfish@user-5-173-182-29.play-internet.pl)
[13:00:14] *** Quits: jwerner (~jwerner@104.132.210.70) (Ping timeout: 260 seconds)
[13:00:15] <tolto> amdj: so you're saying the file wasn't there at all before 5.6.0?
[13:00:21] <tolto> i'll try to check
[13:00:24] <amdj> I'm saying it wasn't malicious before that.
[13:00:31] <tolto> ok, so where is the non-malicious file taken from?
[13:00:34] *** Joins: Apachez (~Apachez@user/apachez)
[13:00:36] <amdj> probably autoconf.
[13:00:40] <tolto> hmm...
[13:00:42] *** Quits: leggo (~katt@ip-193-53-104-44.changeis.iunxi.net) (Ping timeout: 260 seconds)
[13:00:43] *** Quits: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825) (Quit: Client closed)
[13:00:50] <gamer191> I'm logging off now
[13:00:52] <ozars2> tolto: https://www.openwall.com/lists/oss-security/2024/03/30/14
[13:00:53] <tolto> bye
[13:00:56] *** Joins: yasinbread (~yasin@130.204.92.64)
[13:01:00] *** Quits: gamer191 (~gamer191@124.168.216.118) (Quit: Client closed)
[13:01:08] <amdj> ah, gnulib.
[13:01:12] <dostoyevsky2> tolto: the older xz releases where double checked by Larhzu by creating a tarball himself and comparing it to Jia's ... and then there were no extra files
[13:01:17] <susi> >While build-to-host.m4 itself is not part of the repository, it was added to gitignore in commit 4323bc3e0c1e1d2037d5e670a3bf6633e8a3031e. The original build-to-host.m4 was taken from gnulib [5] and only a few  changes were made to inject the backdoor.
[13:01:19] <tolto> ozars2: ohh, thanks!
[13:01:21] *** Joins: s3 (~bn@user/bn)
[13:01:36] <tolto> dostoyevsky2: i'll check the older releases now
[13:01:54] *** Joins: Guest81 (~Guest81@144.48.80.16)
[13:02:33] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Quit: Client closed)
[13:02:36] <tolto> yeah it sucks that the github repo has been taken down
[13:02:42] <tolto> it makes it difficult to do an investigation
[13:02:45] <tolto> :/
[13:02:46] *** Quits: Guest81 (~Guest81@144.48.80.16) (Client Quit)
[13:02:57] *** Joins: Guest81 (~Guest81@144.48.80.16)
[13:03:07] *** Joins: Guest79 (~Guest98@m90-129-209-153.cust.tele2.se)
[13:03:35] *** Joins: sed (~sed@2a01:e0a:b7d:89b0:ad4:cff:fee2:7ba1)
[13:03:45] *** sed is now known as sedcore
[13:03:51] <solarsea> dedicated security teams have been doing investigations on their own for a while now as indicated by Dirk
[13:04:09] <amdj> those darn githubbers, protecting people and stuff. boo!
[13:04:10] *** Joins: pastapoggers (~pastapogg@147.236.229.233)
[13:04:14] *** Quits: Guest83 (~Guest77@2a02:8071:4680:7ec0:3bc2:6821:c446:31d2) (Quit: Client closed)
[13:04:19] <tolto> solarsea: sure, but it sucks that it's technically gatekeeping independent investigators away
[13:04:27] *** Joins: myrmidon (~vortex@72.46.187.81.in-addr.arpa)
[13:04:41] *** Quits: djbit (~djbit@178-84-69-126.dynamic.upc.nl) (Quit: Leaving)
[13:04:51] <a5n> tolto: you can properly recover them from the debian repo with prestine tar
[13:05:01] <pastapoggers> hey sorry if this has been asked before. i'm reversing the rsa_public_decrypt hook in the backdoor - is there a channel for people doing this or any faq about the payload itself?
[13:05:13] <tolto> a5n: yeah, good idea. i'm trying to piece everything together
[13:05:24] *** Joins: sraue (~sraue@2a00:20:4002:d4a5:acd0:91ab:c1a2:b805)
[13:05:28] *** Joins: toto_ (~toto@178-84-69-126.dynamic.upc.nl)
[13:05:31] <Guest93> pastapoggers: I was also curious about this
[13:05:43] *** Joins: Guest24 (~Guest90@2a02:908:4b48:d920:fb9a:e475:48f7:39da)
[13:05:50] *** Joins: sqrwav (~sqrwav@2a01:4f9:c010:2837::1)
[13:06:02] <a5n> tolto: https://salsa.debian.org/debian/xz-utils
[13:06:03] *** Quits: Guest81 (~Guest81@144.48.80.16) (Client Quit)
[13:06:06] *** Joins: dutch (~DutchIngr@user/dutch)
[13:06:13] *** Quits: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491) (Ping timeout: 268 seconds)
[13:06:19] <toto_> tolto: you can find the repo with the malicious commit also hosted here https://git.rootprojects.org/root/xz
[13:07:05] *** Quits: vinz (~sailfish@user-5-173-182-29.play-internet.pl) (Ping timeout: 264 seconds)
[13:07:05] <tolto> thank you. i meant more the comments and other metadata that's not on the repo itself (as well as release files, thankfully those are on the wayback machine)
[13:07:17] *** Joins: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825)
[13:07:27] *** Quits: Guest59 (~Guest20@216.247.110.8) (Quit: Client closed)
[13:07:45] *** Joins: letgamer (~letgamer@p200300e99f110b00edde1913c7f1a7ea.dip0.t-ipconnect.de)
[13:08:02] *** Quits: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825) (Client Quit)
[13:08:36] *** Quits: Guest25 (~Guest25@81.214.106.53) (Quit: Client closed)
[13:08:47] *** Joins: vinz_ (~sailfish@user-5-173-182-29.play-internet.pl)
[13:08:50] *** Quits: Guest21 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi) (Ping timeout: 250 seconds)
[13:09:04] <tolto> > if test "x$gl_am_configmake" != "x"; then
[13:09:09] <tolto> this guy really likes X's
[13:09:21] <Manis> it's normal for autotools
[13:09:21] <tolto> instead of comparing to an empty string, he compares to "x"
[13:09:21] <amdj> that's a relic of a time when it would have been a syntax error.
[13:09:26] <tolto> ohh, ok
[13:09:29] *** Joins: meson800 (~meson800@18.10.138.247)
[13:09:31] <Manis> Old versions of test failed with empty arguments.
[13:09:34] <amdj> ^
[13:09:34] *** Quits: Guest42 (~Guest42@2a09:bac3:3161:505::80:16d) (Quit: Client closed)
[13:09:35] <tolto> got it
[13:09:40] *** Joins: marauroa (~marauroa@stendhalgame.org)
[13:09:47] *** Joins: Guest76 (~Guest41@a89-152-157-153.cpe.netcabo.pt)
[13:10:13] *** Joins: Guest42 (~Guest42@2a09:bac3:3168:505::80:f2)
[13:10:22] *** Joins: filipe (~ffernand@user/ffernand)
[13:10:22] <ozars2> There is also a way to query GH events someone posted in https://news.ycombinator.com/item?id=39870048. I posted that to thesamesam's gist as well, but later took down my posts when someone with a burner account started pointing fingers frantically. Please use responsibly.
[13:10:29] *** Joins: Guest60 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi)
[13:10:50] *** Joins: Guest13 (~Guest13@093105177108.dynamic-2-waw-k-1-1-0.vectranet.pl)
[13:10:54] <tolto> ozars2: ok, nice
[13:11:08] *** Joins: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825)
[13:11:12] <a5n> tolto: https://sources.debian.org/src/xz-utils/
[13:11:19] <tolto> interesting that this clickhouse website has access to github's API
[13:11:35] *** Joins: Guest35 (~Guest24@i577B1DAA.versanet.de)
[13:11:37] <tolto> a5n: ok, let me see
[13:11:54] <tolto> 5.6.1+really5.4.5-1 vs 5.6.1-1 hmm
[13:11:59] <pastapoggers> Guest93: I'm making some progress, i found the the implementation and the fallback behavior but the function is too complex, also i can't seem to load openssl header files to IDA. but my initial understanding is that sub_79F055672730 (in my IDA) decides eventually whether to bypass rsa_public_decrypt or fallback to it
[13:12:07] <tolto> ah, i think someone tried to revert the package
[13:12:08] *** Joins: plebe (~plebe@user/plebe)
[13:12:14] <tolto> by naming 5.4.5 as "5.6.1 really"
[13:12:37] <abby> 5.6.1 (really 5.4.5)
[13:12:43] <tolto> by the way, is the malicious object file x86_64 only? or is it also for other architectures?
[13:12:47] *** Joins: dd12 (~dd12@43.225.189.171)
[13:12:49] <amdj> tolto: it's a way to convince apt that the version number is higher, so apt upgrade will install it.
[13:12:52] *** Quits: ecco_indalo2 (~adelgado@85-23-76-3.bb.dnainternet.fi) (Read error: Connection reset by peer)
[13:12:53] <abby> don't know if dpkg supports downgrades
[13:12:56] <tolto> amdj: okay
[13:13:08] *** Joins: smbd (~smbd@2804:7f0:b141:7575:f5d8:b9f6:e99d:4a8c)
[13:13:13] <toto_> tolto: afaik only x86_64
[13:13:16] <tolto> i see
[13:13:31] *** Joins: Guest32 (~Guest13@2a02:810d:b83f:e400:16a0:2f96:e202:fd52)
[13:13:33] <toto_> There is a post that investigates Jia Tan activities as well besides the xz contribution. It looks like this thing was planned long before. 
[13:13:36] *** Joins: adelgado (~adelgado@85-23-76-3.bb.dnainternet.fi)
[13:13:38] <adrien> you could downgrade but that's an explicit operation; this "+really" is ugly but I guess it works and it's uncommon enough
[13:13:43] *** Quits: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi) (Remote host closed the connection)
[13:13:46] <toto_> the post: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[13:13:49] *** Joins: nozaq (nozaq@user/nozaq)
[13:14:03] <adrien> plus, downgrades are rarely supported
[13:14:16] <adrien> you're likely to lose APIs when doing so
[13:14:19] <tolto> it may have been planned since 2 years ago. when Lasse was "bullied" (?) to accept Jia Tan as a maintainer
[13:14:22] *** Joins: mbzulu (~mbzulu@p54ac6081.dip0.t-ipconnect.de)
[13:14:41] <toto_> more like pressured by some random account from the mailing-list
[13:14:44] <tolto> "peer pressured" i guess is a better term
[13:14:48] <tolto> yeah
[13:15:00] <amdj> What I like about Gentoo is `emerge -DNu @world' tells it to bring your system to the /latest state of your ebuild trees/. This isn't necessarily the highest version of every package. So when they masked 5.6, emerge will happily downgrade xz-utils even though the option is called --update.
[13:15:04] <Rounin> If I ever happen upon a grand idea for a utility, I'm going to go for the TCC route... This project is my project, you can make your fork, but don't come here
[13:15:10] <Rounin> Unless they whip up the big $$$, anyway
[13:15:28] <tolto> Rounin: what do you mean by TCC? Tiny C Compiler?
[13:15:29] *** Quits: mbzulu (~mbzulu@p54ac6081.dip0.t-ipconnect.de) (Remote host closed the connection)
[13:15:48] *** Joins: mbzulu (~mbzulu@p54ac6081.dip0.t-ipconnect.de)
[13:15:59] <dd12> isn't cproc better than tcc?
[13:16:04] <Rounin> tolto: Yeah. There was someone back in the day complaining that it (he) didn't accept patches etc. But why should someone's fun hobby project do that?
[13:16:06] <abby> amdj: void has similar, the build system (xbps-src) uses the ports tree as a source of version truth, and the package manager (xbps) has a metadata field and logic for reverting/downgrading gracefully
[13:16:29] <tolto> https://sources.debian.org/src/xz-utils/5.6.1%2Breally5.4.5-1/m4/ hah, look. the "build-to-host" file isn't here at all
[13:16:29] <dd12> To be fair, TCC is maintained by fabrice bellrad ......
[13:16:42] *** Joins: mr_mitm (~dude@ip-046-005-209-168.um12.pools.vodafone-ip.de)
[13:16:53] *** Quits: noone (~noone@178.255.168.249) (Remote host closed the connection)
[13:16:55] *** Joins: miton (uid542385@id-542385.tinside.irccloud.com)
[13:17:20] *** Joins: Guest82 (~Guest55@node-1w7jr9y54ki7c4fvzf46uab3m.ipv6.telus.net)
[13:17:21] <fullstop> I've been giving this whole thing some thought, and I think that this back door was the root of something far larger, and it was nipped early.
[13:17:28] <susi> sur-priced?
[13:17:47] <toto_> fullstop: so a state-sponsored operation
[13:17:49] <tolto> well the backdoor probably wasn't well-tested. as it was noticed in production being a CPU hog in SSH...
[13:18:03] *** Quits: Guest60 (~Guest53@mobile-access-c1d2c1-73.dhcp.inet.fi) (Quit: Client closed)
[13:18:08] <fullstop> If it had gone undetected, 5.6.1+ would have definitely gone into production in millions of systems
[13:18:21] *** Quits: Guest39 (~Guest51@83-233-238-61.cust.bredband2.com) (Ping timeout: 250 seconds)
[13:18:25] <tolto> fullstop: does 5.6.0 have the backdoor too, btw?
[13:18:45] <fullstop> I have the release tarballs and can check
[13:18:46] <toto_> yeah i think so, at least on that version, that is when the random test files were introduced
[13:18:54] *** Quits: Guest45 (~Guest45@KD119106007249.ppp-bb.dion.ne.jp) (Quit: Client closed)
[13:18:54] <amdj> 5.6.0 had a faulty version that was causing some crashes and valgrind errors IIRC
[13:19:08] *** Joins: djanos (~djanos@101.195.31.93.rev.sfr.net)
[13:19:15] *** Joins: peb (~PEB@debian/peb)
[13:19:16] <fullstop> 5.6.0 has the build-to-host.m4
[13:19:20] *** Joins: ohad83 (~ohad83@5.29.240.61)
[13:19:38] <tolto> ohh ok
[13:19:57] <fullstop> I mean, this is a horrible event, but it could have been significantly worse.
[13:20:05] <peb> Larhzu: I'd like to extend my sympathy towards you
[13:20:09] *** Quits: mbzulu (~mbzulu@p54ac6081.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
[13:20:18] <toto_> Did Lahrzu ever meet Jin Tan IRL or even know how RL identity? I don't know if this was disccussed before but I see that Lahrzu was active before in here
[13:20:19] <peb> I'm sorry for the mess you've been placed in
[13:20:26] <fullstop> It also makes you wonder what sorts of attacks like this have succeeded in the past and which we are running right now.
[13:20:49] <dd12> 5 eyes has had backdoors for years
[13:20:52] *** Quits: vinz_ (~sailfish@user-5-173-182-29.play-internet.pl) (Ping timeout: 264 seconds)
[13:20:53] *** Quits: ozars2 (~ozars@c-174-160-80-156.hsd1.ca.comcast.net) (Quit: Client closed)
[13:21:08] <Rounin> dd12: cproc seems pretty cool, though
[13:21:14] <fullstop> peb: It's a huge mess, but look at how many people rely on liblzma.  It's quite an achievement, honestly.
[13:21:15] <Rounin> Optimizing backend and everything
[13:21:22] <Paistin> toto_: is this something that we are to know or a private matter? 
[13:21:28] *** Joins: ghavil (~ghavil@user/ghavil)
[13:21:32] *** Joins: Guest27 (~Guest51@83-233-238-61.cust.bredband2.com)
[13:21:34] <mroszko> i wonder if its possible to grep every oss project out there using ifuncs
[13:21:38] <Rounin> Plus it's good that someone maintains the knowledge of the basics... Like how to build a compiler
[13:21:39] <mroszko> to give them a onceover
[13:21:43] *** Joins: mbzulu7 (uid644159@id-644159.hampstead.irccloud.com)
[13:21:45] <dd12> https://grep.app
[13:21:47] <mroszko> it seems like an reusable attack vector at the build level
[13:22:06] <fullstop> Anything with "random" data in test cases should be inspected
[13:22:21] <fullstop> image libraries, in particular, would be good candidates
[13:22:41] *** Joins: ozars (~ozars@c-174-160-80-156.hsd1.ca.comcast.net)
[13:22:47] *** Joins: ztane (ztane@kapsi.fi)
[13:22:51] *** ozars is now known as ozars2
[13:23:14] <tolto> well that "safe_fprintf" vs "fprintf" thing is weird though. why would someone accept it?
[13:23:24] <tolto> clearly the commit was using "fprintf" instead of "safe_fprintf"
[13:23:36] <dd12> semi related: https://www.wired.com/story/jeff-bezos-phone-hack-mbs-saudi-arabia/ (it was an corrupted image)
[13:23:52] *** Joins: Guest66 (~Guest66@151.18.228.205)
[13:24:02] <mroszko> thats just standard bad input
[13:24:04] <JTL> dd12: psure that was an exploit of a known vuln, and not a backdoor like this
[13:24:05] <dstolfa> tolto: probably unaware that in a few places, archive contents are being fed into the archive error string
[13:24:06] <mroszko> tons of those kinds of vulns
[13:24:19] <dstolfa> tolto: the end result is (probably) something with ANSI escape codes
[13:24:22] *** Quits: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825) (Quit: Client closed)
[13:24:24] *** Joins: Guest28 (~Guest28@p200300f857310000b52623e5726dc438.dip0.t-ipconnect.de)
[13:24:28] <tolto> hmm
[13:24:29] <mroszko> this was a supply chain attack through long term infilitration
[13:24:29] *** Quits: Guest35 (~Guest24@i577B1DAA.versanet.de) (Quit: Client closed)
[13:24:40] <dd12> The conspiracies arising out of this are concerning: people are blaming all sorts of groups
[13:24:43] *** Joins: Guest35 (~Guest24@i577B1DAA.versanet.de)
[13:24:44] *** Quits: adelgado (~adelgado@85-23-76-3.bb.dnainternet.fi) (Read error: Connection reset by peer)
[13:24:49] <tolto> what i meant is "safe_fprintf" would have worked just as well. so why would someone accept a pull request where "fprintf" was used instead
[13:24:51] *** Joins: mbaxter (~mbax@user/mbaxter)
[13:25:03] <dstolfa> tolto: mistakes happen. FOSS is notoriously lacking reviewers
[13:25:04] <mroszko> yea its going to be hard for anyone to pin this on any particular group
[13:25:05] *** Joins: Guest49 (~Guest49@2a02:8071:b84:0:48ae:2453:7fbc:be06)
[13:25:07] <tolto> ah
[13:25:08] *** Joins: JuukaSalami978 (~JuukaSala@45.153.183.199)
[13:25:12] *** Joins: adelgado (~adelgado@85-23-76-3.bb.dnainternet.fi)
[13:25:14] *** Joins: Guest63 (~Guest36@2a02:8070:a382:efc0:44e3:31a0:227:b276)
[13:25:15] <mroszko> the feds have probably subpoenaed github already about jia
[13:25:22] <mroszko> but it'll probably just be some random vpn IPs
[13:25:24] <Rounin> Clearly it was Zelensky and Ukraine!
[13:25:25] *** Joins: schroes (~quassel@user/schroes)
[13:25:25] *** Quits: Guest66 (~Guest66@151.18.228.205) (Client Quit)
[13:25:35] <dd12> Those were on the list lol
[13:25:51] *** Quits: Guest28 (~Guest28@p200300f857310000b52623e5726dc438.dip0.t-ipconnect.de) (Client Quit)
[13:26:16] <dd12> What steps can be taken to prevent this from happening again?
[13:26:27] <mroszko> you cant
[13:26:30] <tolto> lol i just noticed something
[13:26:30] <tolto>   dnl Search for Automake-defined pkg* macros, in the order
[13:26:30] <tolto>   dnl listed in the Automake 1.10a+ documentation.
[13:26:35] <mroszko> oss distribution is built on a chain of trust
[13:26:44] <tolto> i found similar text in this file: https://github.com/tamer-hassan/mate-globalmenu/blob/master/Makefile.configmake
[13:26:45] <mroszko> basically a human element
[13:26:46] <toto_> mroszko: indeed, there was one user in a github gist post on the comments, that showed the user jintan asking in Ubuntu's IRC. This is just a comment so i am not sure how credible it is. https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006196#gistcomment-5006196
[13:26:48] <Traneptora> dd12> What steps can be taken to prevent this from happening again?
[13:26:51] <tolto> # Listed in the same order as the GNU makefile conventions.
[13:26:51] <tolto> # The Automake-defined pkg* macros are appended, in the order
[13:26:51] <tolto> # listed in the Automake 1.10a+ documentation.
[13:26:52] <Traneptora> code audits, basically
[13:26:57] <Traneptora> you just have to have more eyes on code
[13:26:57] *** Joins: Guest99 (~Guest99@90.193.71.60)
[13:26:58] *** Quits: Guest80 (~Guest19@ti0027a400-0966.bb.online.no) (Quit: Client closed)
[13:27:00] <mroszko> Traneptora NOPE
[13:27:01] <tolto> i think jiatan just cobbled up some text together to make it look "legit"
[13:27:04] <mroszko> code audits would have failed
[13:27:07] <dd12> List of things being blamed for the xz-utils backdoor: Biden, Hamas, ISIS, P. Diddy, Nickelodeon, India, former president Barack Obama, Islam, aliens, Sri Lanka, the World Economic Forum, the United Nations, Wokeness, Ukraine, foreign aid, the CIA, Jewish people, Washington State Police, Connecticut State Police, Israel, Russia, China, Iran, Covid
[13:27:07] <dd12> vaccines, DEI, immigrants, Black people, and lockdowns
[13:27:10] <Traneptora> not automated code audits
[13:27:10] <mroszko> the upstream xz code was fine at face value
[13:27:12] <tolto> i don't think the text makes any sense in the context where it was used lol
[13:27:12] <dd12> Traneptora how do you get more eyes on the code?
[13:27:13] *** Quits: alcx (~alcx@2a01:e0a:32e:9f50:2c75:f1f2:f173:f8e9) (Quit: Client closed)
[13:27:14] *** Joins: dppes (~dppes@2a02:908:1862:2d40:2a1f:8c70:f45f:5441)
[13:27:15] <fullstop> why would hunter biden do this
[13:27:17] <dd12> You need more people
[13:27:22] <mroszko> the exploit was buried in the tarball distribution
[13:27:23] <Traneptora> yea, basically
[13:27:24] *** Parts: fly_ (~fly@user/fly) ()
[13:27:27] *** Quits: pastapoggers (~pastapogg@147.236.229.233) (Ping timeout: 250 seconds)
[13:27:31] <dd12> How do you get said people
[13:27:31] *** Quits: Guest76 (~Guest41@a89-152-157-153.cpe.netcabo.pt) (Quit: Client closed)
[13:27:35] <Traneptora> that's the hard part
[13:27:40] <joepie91> I would like to caution people against trying to point fingers on this one. attribution is considered a specialized skill, and for good reason - if this really was a nation-state campaign, then it's highly likely that misleading evidence was deliberately left behind, to obscure who really did it. you are really, really unlikely to correctly identify the perpetrator if this sort of thing isn't your daily job. your time is better spent digging through
[13:27:40] <joepie91> associated commits and identities to try and find other suspicious contributions to this or related projects, and get them fixed.
[13:27:43] <dd12> compression libaries aren't exactly the most attractive piece of software
[13:27:54] <mroszko> most OSS isnt attractive
[13:27:56] *** Joins: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825)
[13:27:58] <mroszko> its all hobby projects
[13:28:19] *** Parts: Xogium (~Xogium@LuminaSensum/founder/Xogium) (leaving channel)
[13:28:23] *** Quits: Guest35 (~Guest24@i577B1DAA.versanet.de) (Client Quit)
[13:28:48] *** Joins: holgerh (~holgerh@p5ddd7672.dip0.t-ipconnect.de)
[13:29:09] <tolto> anyway i noticed that the "really 5.4.5" version still has more files in the "m4" folder than the 5.4.5 source: https://sources.debian.org/src/xz-utils/5.6.1%2Breally5.4.5-1/m4/
[13:29:12] <tolto> https://git.tukaani.org/?p=xz.git;a=tree;f=m4;h=8de6bd0e2dd4b711596b8a2a3c8a61d98906f40c;hb=49053c0a649f4c8bd2b8d97ce915f401fbc0f3d9
[13:29:21] *** Joins: Guest9034 (~user@cpe-94-253-208-181.st2.cable.xnet.hr)
[13:29:32] <dd12> The best solution, imho, is to pay people to work on these things
[13:29:49] <Traneptora> a lot of foss does this
[13:29:49] <dnsmcbr> dd12: oh nice, it's the infinite money pot guy
[13:29:52] <dd12> As is obvious few people will do the amount of work these people do for absolutely nothing in return
[13:29:56] <joepie91> Traneptora: some code auditing procedures could have caught this. almost every procedure that is applied in practice, however, could not have. a better first step is making it harder to pressure or 'buy' maintainers, and that means paying them a living wage for the work they are already doing
[13:29:58] <dd12> Google and apple should pay
[13:30:00] <mroszko> tolto because you dont know how autotools work, those are the post configure sources that are generated
[13:30:02] *** Quits: Guest42 (~Guest42@2a09:bac3:3168:505::80:f2) (Quit: Client closed)
[13:30:20] <tolto> mroszko: ahh
[13:30:24] <joepie91> like, 'burned out maintainers' is how you pull off attacks like this
[13:30:25] *** Joins: Guest09 (~Guest09@host86-173-158-86.range86-173.btcentralplus.com)
[13:30:27] <dnsmcbr> mroszko: tbf autotools is a dark daark daaaark place
[13:30:30] <joepie91> and there's no shortage of those
[13:30:37] <otila> I call it autobreak
[13:30:43] <Traneptora> I mean I'm not gonna say no to funding more foss, but some projects (e.g. linux) are already funded by the big boys
[13:30:50] *** Quits: Guest24 (~Guest90@2a02:908:4b48:d920:fb9a:e475:48f7:39da) (Quit: Client closed)
[13:30:52] <dd12> Fund the smaller projects
[13:30:52] *** Quits: Guest09 (~Guest09@host86-173-158-86.range86-173.btcentralplus.com) (Client Quit)
[13:30:55] <Traneptora> would be nice to pay a dev or two to fund crucial smaller projects
[13:30:56] <Traneptora> I agree
[13:31:21] <mroszko> the problem is even if you were paid, you'll probably get bored maintaining a package for 15 years
[13:31:28] <mroszko> with little human interaction
[13:31:34] <mroszko> because everyone just uses the package and thats it
[13:31:35] <mroszko> lol
[13:31:44] <Traneptora> idk if it was my job I'd probably think a bit differently
[13:31:44] <JTL> bug reports = human interaction /s
[13:31:44] <Paistin> facts
[13:31:48] <dd12> som one shared that he was in his early 20s when he started the project, now in his 40s
[13:31:49] <dnsmcbr> also underpaying people just opens up a new threat vector
[13:31:57] <Apachez> Traneptora: so something like this? ;) https://xkcd.com/2347/
[13:32:09] *** Joins: Guest09 (~Guest09@217.146.82.192)
[13:32:11] <Traneptora> yes that
[13:32:20] <joepie91> Traneptora: well, sort of, but not exactly. the current funding models have a bunch of issues, including a) all the focus is on maintainers of the 'end product' and not the invisible infrastructure underlying it (like dependencies and build systems), and b) usually FOSS maintainers are not actually paid for doing the work they're already doing, they're hired to do work for the company. they are subject to the company's management procedures, priorities,
[13:32:20] <joepie91> etc. - and that both reduces the time available for maintenance, *and* the willingness of maintainers to go along with this
[13:32:32] *** Joins: Xnuk (~Xnuk@2a09:bac5:473a:1a14::299:38)
[13:32:40] <amdj> JTL: hah.
[13:32:43] *** Quits: Guest32 (~Guest13@2a02:810d:b83f:e400:16a0:2f96:e202:fd52) (Quit: Client closed)
[13:32:45] <joepie91> Traneptora: what I am talking about is literally "put maintainers on payroll for the work they are doing and do not meddle with them any further"
[13:32:51] <dnsmcbr> APTs have buckets of cash, carrots and sticks to tempt the underpaid maintainer
[13:32:55] <Traneptora> I don't disagree
[13:33:01] *** Joins: Guest96 (~Guest96@194-218-34-180.customer.telia.com)
[13:33:04] *** Parts: mbaxter (~mbax@user/mbaxter) (bye!)
[13:33:15] <Traneptora> when it is your job, you don't need $dayjob to pay your rent
[13:33:18] <joepie91> what I'm suggesting, in more detail: https://social.pixie.town/@joepie91/112184128888419599
[13:33:18] <fullstop> I still want to know what the payload was
[13:33:21] <Traneptora> so burntout is a lot less problematic
[13:33:26] <joepie91> yeah
[13:33:28] <toto_> mroszko: no company is going to do that, with the current trend, companies are likely going to develop an AI model that can do the security audit 
[13:33:57] *** Quits: Guest79 (~Guest98@m90-129-209-153.cust.tele2.se) (Ping timeout: 250 seconds)
[13:33:58] <joepie91> toto_: then they get to enjoy their 'supply chain compromises', as they like to call them
[13:33:59] <dstolfa> that's totally gonna go well
[13:34:37] *** Joins: jacksonchen666 (~jackson@user/jacksonchen666)
[13:34:38] *** Quits: Guest96 (~Guest96@194-218-34-180.customer.telia.com) (Client Quit)
[13:34:38] <JTL> toto_: and I have my doubts with "AI" on it's current trajectory can do supposed audits at the level required
[13:35:01] <tolto> anyway this backdoor looks similar to how regular multi-stage malware with payloads would work
[13:35:01] *** Quits: Guest97 (~Guest97@ip-89-103-91-86.bb.vodafone.cz) (Quit: Client closed)
[13:35:06] <tolto> so it's malware techniques, but in open-source
[13:35:09] <joepie91> (the idea of developing an "AI model" to do "security audits" would be quite hilarious if it weren't so sad - the models themselves are not even resistant to misdirection, let alone whatever work they are tasked with doing, which y'know, is a pretty big part of how backdoors work)
[13:35:17] <JTL> my point
[13:35:19] <mroszko> lol, if the existing even premium AI are an example, most AI can't cope with something more advanced than boilerplate
[13:35:20] <JTL> tolto: I thought so too
[13:35:23] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[13:35:32] *** Quits: Guest26 (~Guest26@2a01cb040ceac400eff883705304d6d8.ipv6.abo.wanadoo.fr) (Quit: Client closed)
[13:35:37] *** Quits: dd12 (~dd12@43.225.189.171) (Quit: Client closed)
[13:35:49] *** Parts: djanos (~djanos@101.195.31.93.rev.sfr.net) ()
[13:36:01] *** Joins: sinbad (~sinbad@user/sinbad)
[13:36:01] *** katt_ is now known as hjalmar
[13:36:19] *** Quits: Guest29 (~Guest29@2a06:4944:18f3:4700:717e:6228:a104:5825) (Quit: Client closed)
[13:36:35] *** Quits: rx80 (~quassel@user/rx80) ()
[13:36:40] *** Joins: Guest77 (~Guest77@185.240.147.119)
[13:36:41] *** Parts: Guest49 (~Guest49@2a02:8071:b84:0:48ae:2453:7fbc:be06) ()
[13:36:51] *** Joins: wobfan (~wobfan@2a02:908:d44:5500:713c:af96:d3ba:dc2f)
[13:37:11] <mbzulu7> Is there any publicity available coordinated effort with a systematic approach to investigate this issue?
[13:37:35] *** Joins: dd12 (~dd12@static-198-44-136-44.cust.tzulo.com)
[13:37:40] <mbzulu7> I feel that a lot of bright people must be working on the as we speak
[13:37:42] *** Joins: rx80 (~quassel@user/rx80)
[13:37:51] *** Joins: zoneroyadmin20 (~zoneroyad@178-251-151-7.ftth.kajonet.fi)
[13:37:52] *** Joins: Guest4244 (~Guest4244@88.201.240.253)
[13:38:11] <tolto> mbzulu7: i've only seen various write-ups, not collaborative
[13:38:12] <Your_Dog> AI security audit is gonna open a new can of worms. It is an uncharted territory afterall. Unless we are referring to automated vulnerability dependency checks
[13:38:32] <toto_> @mbzulu7: you can find various posts online detailing progress from different teams, you may contact one of them 
[13:38:46] *** Joins: asurati (~asurati@103.249.233.183)
[13:38:59] *** Quits: Guest4244 (~Guest4244@88.201.240.253) (Client Quit)
[13:39:09] <JTL> Your_Dog: welcome to the brave new world^W^Wtrashfire of LLMs and related questionable science
[13:39:20] <joepie91> automated vuln checks have basically the same problem
[13:39:21] *** Joins: Guest35 (~Guest35@2001:9e8:cd30:cf00:a52c:16f3:4ca5:392e)
[13:39:24] *** Joins: Guest4244 (~Guest4244@88.201.240.253)
[13:39:27] <joepie91> they can work opportunistically but they will never be reliable
[13:39:34] <Your_Dog> Yes
[13:39:56] <joepie91> or to put it differently, they can only tell you that there is a problem, not that there isn't
[13:39:57] <mbzulu7> toto_: thanks, is there something like a list with these online posts, anything that you’re aware of?
[13:39:59] *** Joins: Guest25 (~Guest25@178235052213.warszawa.vectranet.pl)
[13:40:02] *** Joins: ulm (~ulm@gentoo/developer/ulm)
[13:40:16] *** Quits: Guest4244 (~Guest4244@88.201.240.253) (Remote host closed the connection)
[13:40:32] *** Joins: Ampersander (~Ampersand@dzx2k8yd04hz63s-j1jzt-3.rev.dnainternet.fi)
[13:40:32] *** Quits: Guest25 (~Guest25@178235052213.warszawa.vectranet.pl) (Client Quit)
[13:40:33] *** Joins: Guest80 (~Guest80@144.6.135.21)
[13:40:38] <a5n> mbzulu7: see topic -> https://tukaani.org/xz-backdoor/
[13:40:45] * joepie91 is really not looking forward to startup dudes using this incident to pitch their broken vuln detection tech
[13:40:56] <joepie91> (and trying to present it as The Solution)
[13:41:03] *** Joins: Guest42 (~Guest42@188.250.163.187)
[13:41:25] <luke-jr> Larhzu: IIRC, Arch was one of the distros that was vulnerable? you seem like a high-risk target in this scenario.. just a thought
[13:41:45] *** Quits: zoneroyadmin (~zoneroyad@178-251-151-7.ftth.kajonet.fi) (Ping timeout: 250 seconds)
[13:41:48] <adrien> RPM-based and deb-based AFAIK
[13:41:51] <ErrorNoInternet> Arch wasn't vulnerable, the malicious script checked for a deb/rpm environment
[13:41:54] <Snetry> what adrien said
[13:42:12] <dd12> joepie91: Everyone's gonna have their bit to say
[13:42:14] <Snetry> it explicitly checks for /debian/rules (implying deb package structure) or $RPM_ARCH (implying rpm package being build)
[13:42:36] <tolto> has anyone checked XZ Utils 5.5.2 Beta by jiatan?
[13:42:43] <tolto> is this vulnerable maybe?
[13:42:46] *** Quits: Guest98 (~Guest98@185.207.151.125) (Quit: Client closed)
[13:42:55] <negril> luke-jr: it was not
[13:43:18] <dd12> someone suggested this could be one of the elaborate and largest software marketing campaign in human history
[13:43:29] *** Quits: Guest61 (~Guest61@anice-653-1-505-141.w86-205.abo.wanadoo.fr) (Ping timeout: 250 seconds)
[13:43:59] <amdj> please don't tell me I'm going to have my mother asking what xz is
[13:44:06] <JTL> ditto
[13:44:30] *** Joins: grd (~grd@84-112-217-88.cable.dynamic.surfer.at)
[13:44:31] *** Joins: chadmed (~james@167-179-176-24.a7b3b0.bne.nbn.aussiebb.net)
[13:44:37] <dd12> If true, it is quite a successful one. Within the matter of hours the entire tech community knows what xz utils is
[13:44:48] <Paistin> amdj: your mom telling that programmers should be replaced with chatgpt could be a solution to this hacker epidemic
[13:44:49] <andreyv> ErrorNoInternet: Arch shipped the backdoored version. The sshd part is the one exploit discovered so far, it doesn't mean there aren't more.
[13:44:55] <joepie91> dd12: unfortunately opportunistic vultures trying to sell their broken security tech tend to take away all the oxygen in the room from the people actually trying to solve the problem on a systemic level
[13:45:10] *** Joins: lpt (~lpt@host-87-16-54-137.retail.telecomitalia.it)
[13:45:20] <luke-jr> has anyone confirmed whether or not pixz is impacted?
[13:45:48] <Paistin> joepie91: take the zoom calls with solution offering vultures and invite thugging telegram group into the call 
[13:45:57] <Paistin> gonna be a lot of meat going around
[13:46:02] <luke-jr> hmm, I guess it depends on liblzma, nm
[13:46:03] <dostoyevsky2> amdj: xz is when Clifford the Red Big Dog becomes a Purle Chihuahua
[13:46:13] <dostoyevsky2> Purple even
[13:46:28] <toto_> dd12: how is this a successful one? Like yeah everyone may know xz-utils, but likely not use it because of this incident even if it gets fixed. So in the end it generated bad press for the software, not the kind of publicity you want  
[13:46:30] *** Joins: hukhekhok (~hukhekhok@178.229.172.141)
[13:46:30] *** Joins: Guest21 (~Guest21@2a01cb05857a1c00fc47f12231a76da8.ipv6.abo.wanadoo.fr)
[13:46:45] <mbzulu7> joepie91: this, too much noise
[13:47:03] *** Quits: zekica (~zekica@178-220-122-192.static.isp.telekom.rs) (Quit: Client closed)
[13:47:16] <pipedream> [6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~
[13:47:23] *** Quits: wobfan (~wobfan@2a02:908:d44:5500:713c:af96:d3ba:dc2f) (Ping timeout: 250 seconds)
[13:47:24] <Mopman_> there are some of us within vuln detection companies who push against that kind of thing, yknow :>
[13:47:35] <dd12> Many things in life depend on merely a select group of people (not just FOSS)
[13:47:37] <amdj> hi yes I'd like to sell my ultimate software source code hardening tool. you run anything you like in any language through it and it is guaranteed to remove all security vulnerabilities. it's rm(1)
[13:47:37] <tolto> https://sourceforge.net/projects/lzmautils/files/
[13:47:44] <tolto> sourceforge has removed everything after 5.4.6...
[13:48:01] <Manis> amdj: how much?
[13:48:06] <amdj> TBD
[13:48:06] <gromit> Could we keep this strictly on topic please? There are enough channels for general chatter about the subject 
[13:48:17] <JTL> ^
[13:48:39] <fullstop> luke-jr: arch had the package but sshd did not link to liblzma, and their build was not targeted.  
[13:48:41] *** Joins: rj1 (~rj1@user/rj1)
[13:49:28] <amdj> yeah the malicious modification to the build system checks for either a debian or a RPM build environment, and gcc, gnu ld, and x86_64. 
[13:49:30] *** Quits: toto_ (~toto@178-84-69-126.dynamic.upc.nl) (Remote host closed the connection)
[13:49:32] *** Parts: pipedream (~pipedream@ns1.aims.ac.za) ()
[13:49:39] *** Joins: Guest53 (~Guest53@dynamic-095-118-117-104.95.118.pool.telefonica.de)
[13:49:51] *** Joins: ronfle (~ronfle@93.95.236.146)
[13:49:52] *** ChanServ sets mode: +o amdj
[13:50:02] *** Joins: toto_ (~toto@178-84-69-126.dynamic.upc.nl)
[13:50:12] *** Quits: Guest53 (~Guest53@dynamic-095-118-117-104.95.118.pool.telefonica.de) (Client Quit)
[13:50:33] <Guest09> does anyone know the context of this commit? https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00
[13:50:46] <negril> look for the dot
[13:50:50] *** Joins: ibra (~ibra@103.55.145.176)
[13:50:55] <abby> click on the diff link
[13:50:56] <negril> make the code invalid
[13:50:57] <amdj> Guest09: click "patch" at the top.
[13:50:59] <fullstop> Yeah, it was made to deliberately fail
[13:51:21] <abby> oh context, not content lol
[13:51:40] <colin> Guest09: the stray dot in the middle of the C made the test compile fail, and hence disabled Landlock 
[13:51:41] <amdj> oh I misread it the same way hah.
[13:51:43] *** Quits: Guest85 (~Guest85@2a0d:6fc2:6451:2900:e2d5:5eff:fe07:f54c) (Ping timeout: 250 seconds)
[13:52:22] *** Joins: TINYLILY (~lilydjwg@dango.archlinuxcn.org)
[13:52:22] <otila> Guest09: do "git pull"
[13:52:35] *** Joins: michaelni (~michael@178.157.4.158)
[13:52:52] <mbzulu7> Are there any suspicions of other attack vectors, besides the sshd one at build time?
[13:52:59] *** Quits: ohad83 (~ohad83@5.29.240.61) (Quit: Client closed)
[13:53:07] <amdj> not any substantive ones in this project at the moment no
[13:53:12] *** Joins: Guest44 (~Guest42@2a09:bac3:315c:505::80:111)
[13:53:19] <tolto> https://git.rootprojects.org/root/xz/commit/328c52da8a2bbb81307644efdb58db2c422d9ba7
[13:53:19] <amdj> people are still working on reverse engineering this one
[13:53:30] <tolto> lol. it looks like jiatan added all this code just to have it fail anyway
[13:53:36] <tolto> and all in one commit. sneaky
[13:54:01] *** Quits: Nick111 (~Nick111@144.202.173.133) (Quit: Client closed)
[13:54:20] <tolto> i guess nobody needed to approve this one? assuming Jiatan was the maintainer, so he could approve his own commits
[13:54:26] <amdj> and only if you're building via cmake. the autoconf check works.
[13:54:40] <tolto> yeah...
[13:54:51] <dostoyevsky2> mbzulu7: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01 <- q3k extracted this list of strings from the exploit
[13:55:01] <tolto> so basically jiatan was committing valid improvements. but ALSO backdoor weirdness
[13:55:17] <dostoyevsky2> those symbols seem mostly related to sshd
[13:55:51] <tolto> but yeah, i haven't been able to find the 5.5.2 beta tarball anywhere online
[13:56:05] <tolto> since github took it down, i can't download it :/
[13:56:13] *** Joins: ahedberg (~ahedberg@2601:189:8080:1621:55f9:a0be:9f47:37a4)
[13:56:24] <supakeen> tolto: you can still fetch it from the lookaside caches of various distributions
[13:56:25] <amdj> a good chunk of the symbols on lines 8 through 52 inclusive (but not all) are libcrypto, not openssh.
[13:56:26] *** Quits: Guest62 (~Guest62@nmal-25-b2-v4wan-166401-cust115.vm24.cable.virginm.net) (Quit: Connection closed)
[13:56:35] <tolto> supakeen: hmm ok
[13:56:46] <amdj> the openssh stuff starts in bulk on line 75.
[13:56:49] *** Quits: Guest35 (~Guest35@2001:9e8:cd30:cf00:a52c:16f3:4ca5:392e) (Quit: Client closed)
[13:56:54] <amdj> with some things at the top.
[13:57:13] <dostoyevsky2> amdj: yeah, right... I am just wondering why they don't statically link libcrypto into sshd... nothing good can come from this imho
[13:57:14] *** Joins: Guest69420 (~Guest6942@2a01cb040ceac400eff883705304d6d8.ipv6.abo.wanadoo.fr)
[13:57:22] *** Joins: r0 (~r0@a79-169-63-68.cpe.netcabo.pt)
[13:57:26] <supakeen> tolto: here are the source tarballs as used by fedora: https://src.fedoraproject.org/lookaside/pkgs/xz/
[13:57:36] *** Quits: ahedberg (~ahedberg@2601:189:8080:1621:55f9:a0be:9f47:37a4) (Remote host closed the connection)
[13:57:39] *** Joins: Guest58 (~Guest58@2a10:3781:35cc:1:a50c:4ebf:7b2:9475)
[13:57:51] *** Quits: lpt (~lpt@host-87-16-54-137.retail.telecomitalia.it) (Quit: Leaving)
[13:57:57] <tolto> supakeen: thank you! unfortunately the 5.5.2 beta isn't there. maybe some other distros have it *shrug*
[13:57:58] <amdj> well the good news is that you can build openssh without openssl at all. the bad news is that limits you to curve25519 ecdh, ed25519 public key auth, chachapoly1305 cipher.
[13:58:01] *** Joins: yoyoremote39 (~yoyoremot@2a06:4944:18f3:4700:7068:67c8:ff59:cfaf)
[13:58:02] *** Joins: Guest12 (~Guest93@5.46.117.79)
[13:58:07] *** Quits: junaid_ (~junaid@ip5f587376.dynamic.kabel-deutschland.de) (Quit: Lost terminal)
[13:58:08] <dostoyevsky2> I guess if there are problems with libcrypto you'd like to be able to update it in one go
[13:58:34] <supakeen> tolto: it feels to me like xz follows the 'uneven x in version number means unstable'
[13:58:39] <amdj> for this reason my openssh servers are still built against openssl because my yubikeys are too old to support ed25519.
[13:58:47] <dostoyevsky2> amdj: aren't those the recommended ciphers these days?  
[13:58:57] <supakeen> Eh, y.
[13:58:57] *** Quits: ronfle (~ronfle@93.95.236.146) (Remote host closed the connection)
[13:59:09] *** Quits: Guest42 (~Guest42@188.250.163.187) (Quit: Client closed)
[13:59:10] *** Joins: tobbez (tobbez@user/tobbez)
[13:59:10] *** Joins: ronfle (~ronfle@93.95.236.146)
[13:59:14] <tolto> supakeen: possibly. but yeah who knows, maybe the beta had some backdoor code too. but now we won't know because we can't access the tarball. "thanks" github :/
[13:59:18] <amdj> dostoyevsky2: there are millions of people out there using RSA keys. you need libcrypto for that. that's what this exploit targets.
[13:59:31] *** Quits: Guest93 (~Guest93@88.239.148.78) (Ping timeout: 250 seconds)
[13:59:50] <amdj> I still use RSA for SSH because my yubikey doesn't do Ed25519. I'm rethinking that right about now.
[13:59:50] *** Quits: JuukaSalami978 (~JuukaSala@45.153.183.199) (Quit: Connection closed)
[13:59:53] *** Joins: lpt (~lpt@mob-5-90-174-217.net.vodafone.it)
[14:00:10] <amdj> (it's literally just a hundred quid for 2 new yubikeys)
[14:00:41] *** Joins: Piotrek (~PiotrekD@wiktionary/piotrekd)
[14:00:58] <dostoyevsky2> amdj: I have 2 yk but never used them, because I can't extract the keys for backup... I guess I don't really understand the use cases
[14:01:00] <dstolfa> amdj: this *particular* backdoor happened to go via the PLT, but i don't see why you couldn't obfuscate a million other, differently designed backdoors. i don't think just refusing to use a library is going to save you from these kinds of attacks
[14:01:21] <amdj> dstolfa: oh I'm aware.
[14:01:24] <tolto> also i wonder why debian reverted to 5.4.5 instead of 5.4.6
[14:01:31] *** Joins: Guest17 (~Guest17@174.30.40.113)
[14:01:36] *** Quits: Guest12 (~Guest93@5.46.117.79) (Client Quit)
[14:01:46] <dostoyevsky2> amdj: so now I just use usb sticks, to unlock some vaults and then remove the stick again
[14:01:50] *** Joins: kyub (~kyub@user/kyub)
[14:02:12] *** Joins: Guest85 (~Guest85@46.121.164.212)
[14:02:25] *** Quits: Guest44 (~Guest42@2a09:bac3:315c:505::80:111) (Quit: Client closed)
[14:02:33] *** Quits: particles (~particles@2600:1700:83b0:e1b1:30ae:9c0f:d5d4:eade) (Ping timeout: 250 seconds)
[14:02:40] <amdj> dstolfa: I'm more talking along the lines of, if I had gotten off my ass and upgraded my yubikeys by now already, I wouldn't have had to care about *this* exploit at all, because I wouldn't have openssh built against openssl.
[14:02:44] *** Joins: kalekale (~kalekale@2400:1a00:b012:2d:c8a3:5bab:58f2:1721)
[14:02:45] *** Joins: Guest38 (~Guest74@185.6.98.20)
[14:02:49] *** Quits: Guest38 (~Guest74@185.6.98.20) (Client Quit)
[14:03:05] *** Joins: linusd (~linusd@185.6.98.20)
[14:03:05] *** Quits: linusd (~linusd@185.6.98.20) (Client Quit)
[14:03:19] *** Joins: linusd (~linusd@185.6.98.20)
[14:03:30] <amdj> dostoyevsky2: you can generate a PGP authentication subkey on an airgapped offline device, take an encrypted backup of it for disaster recovery, and then put that onto the yubikey. you're right that you can't get it back off of it, but you have that backup if you need to replace the hardware token.
[14:03:33] *** Joins: Totoposto (~Totoposto@197.153.79.137)
[14:03:54] *** Joins: alexl (~alexl@2a0a-a543-5d23-0-c574-d6cd-1a44-566.ipv6dyn.netcologne.de)
[14:03:58] *** Parts: Guest21 (~Guest21@2a01cb05857a1c00fc47f12231a76da8.ipv6.abo.wanadoo.fr) ()
[14:04:05] <adrien> 5.5.2beta-1 as imported in debian doesn't have the responsible files
[14:04:08] <dstolfa> amdj: gotcha. all my systems are unaffected by this particular issue (either freebsd or debian stable), but i'm not too confident that we've seen the end of it yet
[14:04:09] <fullstop> tolto: the url changed from https://tukaani.org/xz/ to https://xz.tukaani.org/xz/ between 5.4.5 and 5.4.6
[14:04:18] *** Joins: wobfan (~wobfan@2a02:908:d44:5500:713c:af96:d3ba:dc2f)
[14:04:20] <tolto> fullstop: interesting
[14:04:58] *** Quits: linusd (~linusd@185.6.98.20) (Client Quit)
[14:06:02] *** Quits: vidal72 (~vidal72m]@user/vidal72m/x-2204383) (Ping timeout: 255 seconds)
[14:06:20] <fullstop> There's also some interesting changes around the french translation
[14:06:25] *** Joins: Guest67 (~Guest41@a89-152-157-153.cpe.netcabo.pt)
[14:06:27] *** Joins: netx_ (uid408642@user/telnetx)
[14:07:28] <tolto> has anyone possibly noticed any kind of C&C server communication in the object file payload?
[14:07:30] *** Joins: Guest435678 (~Guest4356@148.252.141.105)
[14:07:41] *** Quits: toto_ (~toto@178-84-69-126.dynamic.upc.nl) (Quit: Leaving)
[14:08:04] <mbzulu7> “Jia Tan only had access to things hosted on GitHub, including xz.tukaani.org subdomain (and only that subdomain).”
[14:08:08] *** Joins: linkfanel (linkfanel@82-64-25-168.subs.proxad.net)
[14:08:34] *** Joins: JuukaSalami978 (~JuukaSala@45.153.183.199)
[14:08:52] <dostoyevsky2> tolto: I didn't see anything... that also would raise awareness quickly
[14:08:57] <tolto> ok
[14:09:19] *** Joins: Guest94 (~Guest94@pool-100-6-61-204.pitbpa.fios.verizon.net)
[14:09:37] *** Joins: v0idpwn (sid483136@id-483136.helmsley.irccloud.com)
[14:09:49] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[14:10:20] *** Quits: ronfle (~ronfle@93.95.236.146) (Remote host closed the connection)
[14:11:09] *** Parts: Guest94 (~Guest94@pool-100-6-61-204.pitbpa.fios.verizon.net) ()
[14:12:07] *** Quits: Guest82 (~Guest55@node-1w7jr9y54ki7c4fvzf46uab3m.ipv6.telus.net) (Quit: Client closed)
[14:12:45] *** Joins: ferryman (~teemu@posti.tmu.fi)
[14:13:25] *** Joins: vincejv (~vincejv@user/vincejv)
[14:13:48] *** Joins: Guest53 (~Guest53@p1618002-ipoe.ipoe.ocn.ne.jp)
[14:14:14] *** Joins: Guest97 (~Guest58@p200300fe170e3404a90d150182af0c4d.dip0.t-ipconnect.de)
[14:14:27] *** Quits: Guest30 (~Guest30@91-154-72-8.elisa-laajakaista.fi) (Quit: Client closed)
[14:15:04] *** Quits: Guest4126 (~Guest41@p54b6fe4f.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
[14:15:33] *** Joins: iNomad (~iNomad@user/iNomad)
[14:17:25] *** Quits: wehttam (~wehttam@1.146.120.30) (Remote host closed the connection)
[14:17:44] *** Joins: plat0 (~plato@90-227-104-117-no2380.tbcn.telia.com)
[14:17:46] *** Joins: NotNite (~quassel@96.241.239.7)
[14:17:51] *** Joins: pastapoggers (~pastapogg@147.236.229.233)
[14:18:08] *** Quits: Guest65 (~Guest49@h-94-254-64-68.A465.priv.bahnhof.se) (Quit: Client closed)
[14:18:14] *** Joins: Guest84 (~Guest54@host-87-27-173-117.business.telecomitalia.it)
[14:19:34] *** Joins: aloisw (~aloisw@user/aloisw)
[14:19:44] *** Joins: wehttam (~wehttam@1.146.120.30)
[14:19:45] <mbzulu7> https://www.irccloud.com/pastebin/ZDW3mWV9
[14:20:23] *** Quits: asurati (~asurati@103.249.233.183) (Remote host closed the connection)
[14:20:32] <amdj> mbzulu7: yes. specifically, the exploit scans the symbol table when patching the PLT, and that's the cause of the slowdown.
[14:21:02] *** Quits: Xnuk (~Xnuk@2a09:bac5:473a:1a14::299:38) (Quit: Client closed)
[14:21:23] *** Joins: Guest96 (~Guest96@194-218-34-180.customer.telia.com)
[14:21:45] *** Joins: Guest52 (~Guest52@bras-base-ktnron0814w-grc-01-184-146-159-136.dsl.bell.ca)
[14:21:47] *** Quits: Guest96 (~Guest96@194-218-34-180.customer.telia.com) (Client Quit)
[14:21:51] <amdj> sshd forks and execs itself on every new connection (so you don't have to restart sshd after upgrading it), which means it does this every time someone connects to it.
[14:23:15] *** Joins: Renfield (~Renfield@209.6.121.12)
[14:23:16] *** Joins: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi)
[14:23:22] <amdj> so I imagine the discovery was something along the lines of "wait, why am I seeing a lot of cumulative CPU time in the sshd service cgroup..."
[14:23:46] <negril> no, the connection init was slower then before
[14:23:56] <amdj> yes because of what I just said.
[14:24:15] *** Joins: rafael (~rafael@user/rafael)
[14:24:18] *** Joins: DasBrain (weechat@user/dasbrain)
[14:24:19] <negril> The last sentence is what is incorrect
[14:24:48] <amdj> oh it wasn't discovered by looking at CPU time but rather by timing how long ssh login attempts take?
[14:24:54] <negril> yep
[14:25:19] <mbzulu7> So no advertising is known? The reason I ask again is, is that this was supposedly to be a testing environment, was it connected to the internet with ssh port open?
[14:25:24] <Riastradh> amdj: yep, by 0.5sec
[14:25:24] *** Joins: stunned0256 (~stunned02@2a01:599:b25:b03b:4e59:d1b8:93e:318e)
[14:25:31] *** Parts: holgerh (~holgerh@p5ddd7672.dip0.t-ipconnect.de) (Konversation terminated!)
[14:25:33] *** Joins: Guest36 (~Guest36@2601:246:5c02:ea3:197e:b6cb:31a2:a9f9)
[14:25:37] <amdj> it's just the post I read says it was noticed by CPU time 
[14:25:41] <amdj> https://mastodon.social/@AndresFreundTec/112180083704606941
[14:25:45] <adrien> it was found because it introduced noise in a micro-benchmark
[14:25:48] <Riastradh> amdj: See `With the backdoored liblzma installed, logins via ssh become a lot slower.'  https://www.openwall.com/lists/oss-security/2024/03/29/4
[14:25:55] *** Quits: Guest67 (~Guest41@a89-152-157-153.cpe.netcabo.pt) (Quit: Client closed)
[14:26:21] <ozars2> Realizing that any upstream dependency linking to openssh is capable of changing what functions like RSA_public_decrypt does through PLT made me uncomfortable lol. I wish there was some binary level encapsulation enforced on what dynamic linking can and cannot do.
[14:26:25] <Riastradh> (That said, I don't know what originally tipped off the reporter -- the real time or the CPU time.)
[14:26:27] <aesthetics> dang, i only have slow machines where a ssh connections might take like around 3 secs to establish
[14:26:46] *** Joins: Guest21 (~Guest34@i577B1DAA.versanet.de)
[14:26:57] <aesthetics> i'm glad 0.5secs delay isn't something some people would accept
[14:27:15] *** Quits: Totoposto (~Totoposto@197.153.79.137) (Ping timeout: 250 seconds)
[14:27:19] <plat0> i mean do keep in mind reading from the mail, its to @...alhost, so localhost?
[14:27:25] <plat0> would make sense to worry about such latency
[14:27:31] <amdj> > I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. 
[14:27:31] <DasBrain> From their mastodon, it seems they wanted to have a "silent" machine to do some postgres performance testing: https://mastodon.social/@AndresFreundTec/112180083704606941
[14:27:37] *** Quits: ozars2 (~ozars@c-174-160-80-156.hsd1.ca.comcast.net) (Quit: Client closed)
[14:27:44] *** Quits: stunned0256 (~stunned02@2a01:599:b25:b03b:4e59:d1b8:93e:318e) (Client Quit)
[14:27:50] *** Joins: ozars (~ozars@c-174-160-80-156.hsd1.ca.comcast.net)
[14:27:50] *** ozars is now known as ozars2
[14:27:52] *** Joins: Nick111 (~Nick111@144.202.173.133)
[14:27:54] <adrien> ozars2: there are limits but they can't be applied during library loading during application startup
[14:28:14] <negril> amdj: I was going of the email to openwall
[14:28:21] *** Joins: Totoposto (~Totoposto@197.153.79.137)
[14:29:15] <mbzulu7> “Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc” How could these logins be explained? Open ssh port towards internet?
[14:29:17] *** Joins: laanwj2 (~laanwj2@2a10:3781:26a2:fc:fc4a:8f47:7697:631c)
[14:29:22] <tolto> i wonder why is the attacking payload so slow. does it really take long to check the public key and short-circuit to "authorization correct"?
[14:29:23] <DasBrain> Looks like there has been a new commit to the xy git (not the github one, the previous mirror): https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00
[14:29:30] <amdj> mbzulu7: yes. if you have sshd open to the world, you will be hit by thousands of bots every day.
[14:29:40] <DasBrain> I do not want to be in Lasse Collin's shoes right now.
[14:29:47] *** Quits: Hunter (~hunter@107-223-197-199.lightspeed.tukrga.sbcglobal.net) (Quit: Hunter)
[14:30:02] <negril> Doubt he is wearing shoes in his sauna :)
[14:30:16] <NotNite> DasBrain: what does this commit even do? it looks like a blank change
[14:30:24] <negril> it fixes the check
[14:30:30] <NotNite> ah
[14:30:38] <tolto> NotNite: there's an extra dot which made the C source not compile before, thus disabling extra security
[14:30:38] <DasBrain> NotNite: Beats me. Build systems are black magic for me.
[14:30:50] <mbzulu7> amdj: it’s very odd to expose a test system like this to the internet, especially when you try to quiet it down, but could indeed happen.
[14:30:59] *** Quits: Guest36 (~Guest36@2601:246:5c02:ea3:197e:b6cb:31a2:a9f9) (Quit: Client closed)
[14:31:12] *** Joins: breakgimme (~breakgimm@m169.class146.petrotel.pl)
[14:31:18] *** Joins: achtagon (~achtagon@2601:246:5c02:ea3:197e:b6cb:31a2:a9f9)
[14:31:46] *** Joins: neves (~neves@145.224.115.206)
[14:31:46] *** Joins: Guest9 (~Guest54@159.140.252.98)
[14:31:47] <Guest69420> anyone know where to get the infected tarballs for study/RE it ?
[14:31:51] *** mbzulu7 is now known as marius_zulu7
[14:32:05] <ozars2> adrien: Is it something related to the order of loading for libraries? What I was alluding to is some encapsulation on symbol names and enforcement of that encapsulation by runtime, maybe adding library local prefix to symbol names and preventing linker to allow overriding those from other libraries.
[14:32:05] <plat0> tolto: re "why so slow"; https://social.hackerspace.pl/@q3k/112184695043115759 could this explain it?
[14:32:18] <NotNite> I would be interested if anyone has the object file, presume the safest way to get it is mimic the extraction command manually?
[14:32:23] <DasBrain> Honestly, renting a box with some guaranteed hardware specs is easier than to have one locally, with all kinds of different architectures, configurations...
[14:32:52] *** Joins: Mooncairn (~mooncairn@user/mooncairn)
[14:33:06] *** Quits: breakgimme (~breakgimm@m169.class146.petrotel.pl) (Changing host)
[14:33:06] *** Joins: breakgimme (~breakgimm@user/breakgimme)
[14:33:17] *** Quits: breakgimme (~breakgimm@user/breakgimme) (Remote host closed the connection)
[14:33:31] *** Joins: ronfle (~ronfle@93.95.236.146)
[14:33:46] *** Joins: breakgimme (~breakgimm@user/breakgimme)
[14:34:01] *** Joins: Guest522234235 (~Guest5222@68.65.160.9)
[14:34:13] <tolto> plat0: ohh ok, makes sense
[14:34:41] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Quit: Client closed)
[14:34:56] *** Joins: Guest51 (~Guest76@n219078183117.netvigator.com)
[14:35:26] <laanwj2> NotNite: the extracted object file is attached to the openwall post https://www.openwall.com/lists/oss-security/2024/03/29/4
[14:35:49] <NotNite> thanks
[14:36:39] <negril> that's the 5.6.0 version though
[14:36:42] *** Quits: Guest69420 (~Guest6942@2a01cb040ceac400eff883705304d6d8.ipv6.abo.wanadoo.fr) (Quit: Client closed)
[14:37:04] <vincejv> feel bad for the projects pulling and building the xz code from github, only to find out their CI is failing cuz it was taken down by github
[14:37:24] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[14:37:29] *** Joins: Guest56 (~Guest15@2001-1a81-32a5-8d00-4a0b-ca00-4dd8-689.dynamic6.as20676.net)
[14:37:52] *** Joins: q66 (~q66@q66.moe)
[14:38:26] *** Joins: jan64 (~jan64@82.223.104.16)
[14:38:53] <tolto> i put the object file into IDA. the file is very small
[14:39:03] *** Joins: Guest82 (~Guest82@ec2-13-234-113-77.ap-south-1.compute.amazonaws.com)
[14:39:13] *** Quits: grd (~grd@84-112-217-88.cable.dynamic.surfer.at) (Remote host closed the connection)
[14:39:23] *** Quits: wobfan (~wobfan@2a02:908:d44:5500:713c:af96:d3ba:dc2f) (Ping timeout: 250 seconds)
[14:39:27] *** Parts: st3fan (sid43079@id-43079.lymington.irccloud.com) ()
[14:39:34] *** Joins: MPThLee (~MPThLee@user/MPThLee)
[14:39:39] *** Quits: ozars2 (~ozars@c-174-160-80-156.hsd1.ca.comcast.net) (Quit: Client closed)
[14:39:44] *** Joins: beaver55 (~beaver@113.163.178.101)
[14:39:44] <marius_zulu7> This is an interesting fix (CMake: Fix sabotaged Landlock sandbox check): https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00
[14:40:02] *** Joins: ozars (~ozars@c-174-160-80-156.hsd1.ca.comcast.net)
[14:40:02] *** ozars is now known as ozars2
[14:40:19] *** Parts: Guest56 (~Guest15@2001-1a81-32a5-8d00-4a0b-ca00-4dd8-689.dynamic6.as20676.net) ()
[14:40:20] *** Joins: Guest42 (~Guest4@199.red-79-154-210.dynamicip.rima-tde.net)
[14:40:26] *** Parts: Guest42 (~Guest4@199.red-79-154-210.dynamicip.rima-tde.net) ()
[14:40:34] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Quit: peace)
[14:40:44] <amdj> now I'm wondering whether there's a homoglyph of e.g. < or # that you could shove on a preprocessor include line so that it would look absolutely fine to a human but choke a compiler 
[14:40:47] *** Joins: Guest439173 (~Guest4391@199.red-79-154-210.dynamicip.rima-tde.net)
[14:41:12] <amdj> the dot is obvious in retrospect. unless someone is actually *checking the output of the compiler*, you won't know if just removing the dot makes it work.
[14:41:27] *** Quits: Guest439173 (~Guest4391@199.red-79-154-210.dynamicip.rima-tde.net) (Client Quit)
[14:41:48] *** Joins: Guest23 (~Guest58@2a02:768:6208:8136:7ca6:1add:963e:2f9d)
[14:41:53] <tolto> yeah it does seem obfuscated enough to look just like random LZMA functions
[14:41:58] <amdj> (autoconf puts this output in config.log)
[14:42:25] *** Quits: Guest9 (~Guest54@159.140.252.98) (Ping timeout: 250 seconds)
[14:42:42] <plat0> amdj https://github.com/codebox/homoglyph/blob/0209d35fe8ad79348b520401da8affe8df188909/raw_data/chars.txt#L35C2-L35C3 would this be it? :P
[14:42:45] *** Joins: neko2 (~nekosquar@user/deltasquared)
[14:42:58] *** Quits: kyub (~kyub@user/kyub) (Ping timeout: 255 seconds)
[14:42:58] *** Quits: ronfle (~ronfle@93.95.236.146) (Remote host closed the connection)
[14:43:10] <amdj> thanks for the nightmare fuel.
[14:43:14] <plat0> :D
[14:43:35] *** Joins: kevans (~kevans91@user/kevans)
[14:43:40] <amdj> also TIL Ca-Cb in github URLs.
[14:43:59] <balrog> the tests created with hex editing — maybe those could be reduced to scripts using xxd?
[14:44:00] <amdj> I knew La and La-Lb.
[14:44:09] *** Quits: nozaq (nozaq@user/nozaq) (Ping timeout: 250 seconds)
[14:44:58] <tolto> but i have to say, the actor really did try to hide everything very deeply
[14:45:27] <tolto> in a mix of actually useful and backdoored commits
[14:45:49] *** Quits: laanwj2 (~laanwj2@2a10:3781:26a2:fc:fc4a:8f47:7697:631c) (Quit: Client closed)
[14:46:02] *** Quits: Guest52 (~Guest52@bras-base-ktnron0814w-grc-01-184-146-159-136.dsl.bell.ca) (Quit: Client closed)
[14:46:14] *** Quits: ibra (~ibra@103.55.145.176) (Quit: Konversation terminated!)
[14:46:30] *** Joins: nwqed (~user@2405:201:9008:6099:ab02:a49e:b37a:ef3b)
[14:46:33] <aesthetics> i wonder how that person felt while doing those bad commits... heartbeat +100 or just "another day at work"
[14:46:46] <plat0> i guess that's what a good TA does
[14:46:57] <marius_zulu7> The dot was added on the 26’th of February https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
[14:47:29] <negril> it's also only in the cmake path, that isn't widely used
[14:47:31] *** Joins: grd (~grd@84-112-217-88.cable.dynamic.surfer.at)
[14:48:04] *** Joins: laanwj2 (~laanwj2@2a10:3781:26a2:fc:fc4a:8f47:7697:631c)
[14:48:11] *** Joins: Guest24 (~Guest24@2a02:8070:c688:4200:36e6:1115:b320:d495)
[14:48:28] *** Joins: helkaluin (~helkaluin@146.70.224.49)
[14:49:28] <hjalmar> plat0: would it make sense to grep for non latin (more realistically some more advanced filter) characters in the repo and associated files?
[14:49:40] *** Joins: Guest69 (~Guest2@c-75-68-170-11.hsd1.vt.comcast.net)
[14:50:00] *** Quits: nwqed (~user@2405:201:9008:6099:ab02:a49e:b37a:ef3b) (Remote host closed the connection)
[14:50:03] *** Joins: mcury (~mcury@user/mcury)
[14:50:15] *** Joins: Guest12 (~Guest12@110.164.79.250)
[14:50:26] <amdj> just flagging anything that isn't clean 7-bit US-ASCII will go a long way.
[14:50:52] <plat0> maybe, vscode does that regardless nowadays afaik too (at least when in view)
[14:51:11] <plat0> correction: only for look-alikes i think
[14:51:17] *** Joins: Guest40 (~Guest17@p200300fe170e3404bda60eb757fc7d95.dip0.t-ipconnect.de)
[14:51:24] <DasBrain> Can be done very fast. mask everything with 0b100000001000000010000001000000, look what doesn't come back as 0
[14:51:48] *** Joins: yongxiang (sid437863@user/yongxiang)
[14:52:35] *** Quits: pandada8 (~pandada8@131.186.37.152) (Quit: Client closed)
[14:52:53] *** Quits: Guest12 (~Guest12@110.164.79.250) (Client Quit)
[14:53:11] *** Quits: helkaluin (~helkaluin@146.70.224.49) (Quit: Leaving)
[14:53:22] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Quit: Client closed)
[14:53:39] *** Joins: eam (~eam@li155-76.members.linode.com)
[14:53:42] <Paistin> aesthetics: another day at work. just like the iranian embassy siege. "what did you felt killing those men"... "recoil"
[14:54:11] <plat0> btw tolto: not rly sure whether this might interest ya but there is certainly one function that seems sussier than the others; "Lx86_code_part_0"
[14:54:22] *** Joins: marius2 (~marius2@p54ac6081.dip0.t-ipconnect.de)
[14:54:46] <ozars2> amdj: I ran this: https://pastebin.com/W8Vs5vUN. It matched this only: https://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/common/lzip_decoder.c;h=651a0ae712c837590ca6c88e735d8d3300efc90e;hb=HEAD#l8
[14:54:55] *** Joins: nyanpass (~nyanpass@156.251.180.79)
[14:55:12] <amdj> you might want to include C header files too
[14:55:19] <ozars2> good point
[14:55:22] *** Joins: Guest76 (~Guest4@2a04:4e41:50:108d::fe19:298d)
[14:55:44] *** Joins: Mateon1 (~Thunderbi@user/mateon1)
[14:55:49] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[14:56:17] *** Quits: Guest435678 (~Guest4356@148.252.141.105) (Ping timeout: 250 seconds)
[14:56:25] <ozars2> file src/liblzma/common/lzip_decoder.c is not a valid ascii file
[14:56:25] <ozars2> 'ascii' codec can't decode byte 0xc5 in position 213: ordinal not in range(128)
[14:56:26] <ozars2> file src/liblzma/common/lzip_decoder.h is not a valid ascii file
[14:56:27] <ozars2> 'ascii' codec can't decode byte 0xc5 in position 213: ordinal not in range(128)
[14:56:42] <amdj> excellent.
[14:56:56] *** Quits: Guest76 (~Guest4@2a04:4e41:50:108d::fe19:298d) (Client Quit)
[14:57:00] *** Joins: ronfle (~ronfle@93.95.236.146)
[14:57:06] <neko2> question that popped into my head - based on my reading (which may be wrong) I presume so far there's only been a payload discovered for x86_64? (unless there was more than one payload hidden in that test file)
[14:57:15] *** Quits: yoyoremote39 (~yoyoremot@2a06:4944:18f3:4700:7068:67c8:ff59:cfaf) (Quit: Client closed)
[14:57:19] <neko2> emphasis on discovered, naturally
[14:57:21] *** Quits: Ampersander (~Ampersand@dzx2k8yd04hz63s-j1jzt-3.rev.dnainternet.fi) (Ping timeout: 256 seconds)
[14:57:21] <Snetry> correct
[14:57:26] <laanwj2> yes, only x86_64
[14:57:35] <negril> amdj: no, it stumbles on an author name
[14:57:44] <aesthetics> Paistin: i'm ashamed to admit that i laughed a bit
[14:57:49] <plat0> i love how that worked ozars2 but also `, encoding="utf-8"` in your open :)
[14:57:56] <Snetry> only x86_64, glibc, linux, in a deb package structure or in an rpm build
[14:58:08] *** Quits: Guest97 (~Guest58@p200300fe170e3404a90d150182af0c4d.dip0.t-ipconnect.de) (Quit: Client closed)
[14:58:24] <amdj> plat0: if you didn't open it in utf-8, it might entirely fail to open, or you'd only know which line, not which character, was bad, depending on how python reads it.
[14:58:30] *** Joins: levitating (~irc@user/levitating)
[14:58:32] *** Quits: Guest63 (~Guest36@2a02:8070:a382:efc0:44e3:31a0:227:b276) (Quit: Client closed)
[14:58:42] *** Joins: eider (~eider@user/eider)
[14:58:42] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Client Quit)
[14:58:54] *** Joins: zephyr (~zephyr@2a02:8070:a382:efc0:44e3:31a0:227:b276)
[14:59:00] <negril> it fails on ł
[14:59:03] <neko2> ... oh wait, derp, there was a specific if-check for the exact arch in the m4 file. brain is fried.
[14:59:12] <plat0> amdj interesting, error said ascii codec so assumed that was it 
[14:59:18] <amdj> negril: yeah that's expected.
[14:59:22] *** Quits: zephyr (~zephyr@2a02:8070:a382:efc0:44e3:31a0:227:b276) (Client Quit)
[14:59:46] *** Quits: Guest19 (~Guest19@218.34.249.5.rev.vodafone.pt) (Quit: Ping timeout (120 seconds))
[14:59:48] *** Joins: inference (~inference@host-92-27-157-205.static.as13285.net)
[15:00:12] <tolto> plat0: i'll check
[15:00:40] <neko2> why do I feel that somewhere right now there is someone with an arm64 system who is very smug
[15:00:46] *** Joins: Guest6 (~Guest54@129.145.50.30)
[15:00:48] <plat0> lmfao
[15:00:52] <laanwj2> the jiatan guy contributed some riscv stuff, but it hasn't been discovered to be suspicious yet
[15:01:00] <tolto> lol IDA Free hex-rays fails to decompile it with the error "10: cloud: No response"
[15:01:11] *** Quits: Guest40 (~Guest17@p200300fe170e3404bda60eb757fc7d95.dip0.t-ipconnect.de) (Quit: Client closed)
[15:01:14] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[15:01:17] <inference> neko2: Gentoo musl LLVM/Clang OpenRC. I only satisfy amd64.
[15:01:29] *** Joins: Guest78 (~Guest17@p200300fe170e3404bda60eb757fc7d95.dip0.t-ipconnect.de)
[15:01:45] *** Quits: Guest82 (~Guest82@ec2-13-234-113-77.ap-south-1.compute.amazonaws.com) (Quit: Client closed)
[15:02:35] <neko2> inference: ... ok yes, or have amd64 systems being used as source build space heaters. /t
[15:03:08] *** Quits: dd12 (~dd12@static-198-44-136-44.cust.tzulo.com) (Quit: Client closed)
[15:03:16] <plat0> tolto :(
[15:03:32] <inference> neko2: Build server and BINHOST to pull binaries for other systems from. I have 6 of these OSes across 4 physical systems. It's workable.
[15:03:36] <plat0> you made the cloud sad
[15:03:39] *** Joins: beforelight (~beforelig@32-218-57-192.bng02.brpt.ct.frontiernet.net)
[15:03:54] <levitating> laanwj2: I do find the riscv tests fairly suspicious. They internally look quite a bit like good-large_compressed.lzma, and the injected script from 5.6.1 shows that it tries to execute 2 more scripts found within tests.
[15:03:56] *** Quits: Guest69 (~Guest2@c-75-68-170-11.hsd1.vt.comcast.net) (Quit: Client closed)
[15:04:00] <tolto> there are also some kind of endbr64 instructions
[15:04:02] <tolto> haven't seen those before
[15:04:16] <amdj> tolto: that's intel CET.
[15:04:29] <tolto> hmm
[15:04:32] <neko2> I guess maybe also alpine would have dodged it, providing musl libc binaries?
[15:04:46] <inference> amdj: Doesn't it also work for Zen 3 and above for AMD Shadow Stack?
[15:05:07] <amdj> inference: yep
[15:05:23] *** Quits: ronfle (~ronfle@93.95.236.146) (Ping timeout: 250 seconds)
[15:05:23] *** Joins: aljazs (~aljazs@BSN-77-224-3.static.siol.net)
[15:05:33] <levitating> neko2: I think the script explicitly requires GLIBC to be used
[15:05:36] <levitating> as well as gcc
[15:05:42] <inference> neko2: musl doesn't provide the apparently required IFUNC.
[15:05:52] <inference> And it checks for GCC, too.
[15:05:52] <tolto> it's possible that the endbr64 is misused ("exploited") here
[15:05:54] <levitating> the build environment has to match the one they used
[15:06:00] *** Joins: ericdiao (~ericdiao@146.115.83.242)
[15:06:00] <tolto> but it also may be used how it was meant to be used
[15:06:01] *** Joins: odrling (~odrling@2a01:4f8:c012:70ef::1)
[15:06:31] <neko2> levitating: kinda figures I guess. if it's a pre-built object file a bunch of conditions have to be met lest you run into ABI issues and just alert everyone with a crash instead.
[15:06:38] <amdj> endbr64 is a NOP on x86 CPUs that don't support it.
[15:06:45] <amdj> I can't see how you would misuse it in an exploit.
[15:07:04] <Guest58> https://social.hackerspace.pl/@q3k/112184695043115759 someone managed to extract encoded strings from the malware payload
[15:07:16] <amdj> Guest58: q3k is here.
[15:07:17] <q3k> finally i am a someone
[15:07:17] <tolto> ah ok. i just haven't figured out how exactly it works
[15:07:34] <amdj> q3k: hahahaha.
[15:07:39] <q3k> man, what a ctf
[15:07:47] <q3k> world's first global collaborative ctf
[15:08:00] <plat0> shame we can't know the organizers
[15:08:23] <amdj> what do we think the odds are that the payload ultimately says "Hello, world!" ?
[15:08:28] <blingbling> q3k: cursedctf put up a pwn challenge where you've to exploit the backdoor. 0 solves yet :D
[15:08:31] * sam_ wakes up
[15:08:36] <FireFly> q3k: lol
[15:08:36] <sam_> amdj: I already had to explain to my mother...
[15:08:39] <neko2> > Set that as an env var, run the payload and win a mystery prize!
[15:08:41] <neko2> *snort*
[15:08:53] *** Joins: ePirat (~ePirat@user/epirat)
[15:08:55] <JTL> Well. I think the Morris worm was investigated by multiple people around the same time in 1988, so there is precedent for a "global CTF" :P
[15:08:56] <negril> amdj: https://paste.gentoo.zip/45KIKjcg
[15:09:03] <sam_> jess: I somehow managed, I don't know how, but I did
[15:09:04] <inference> neko2: BRB with a VM the complete opposite of my host for this.
[15:09:13] <negril> sam_: to the pub you go!
[15:09:17] <plat0> >.zip tld; *panic*
[15:09:17] <amdj> negril: yes I saw that part
[15:09:20] <amdj> I mean in sshd.
[15:09:30] <sam_> Larhzu: so glad you're okay
[15:09:52] <levitating> neko2: it was initially discovered partially by stack layout issues found with valgrind
[15:09:58] *** Joins: Ampersander (~Ampersand@dzx2k8ybjcy0bp-m4gyft-3.rev.dnainternet.fi)
[15:10:27] <neko2> yeah I had read about that. a bunch of coincidences had to happen just to arouse suspicion at all.
[15:10:27] <amdj> because when a someone who may or may not be q3k gets to the bottom of what exactly this payload does
[15:10:38] *** Joins: nomadgeek (~nomadgeek@047-134-024-163.res.spectrum.com)
[15:10:44] <amdj> if it turns out to be benign that would indeed be the best ctf ever
[15:10:57] <levitating> neko2: truly if the backdoor code wasn't so terribly slow this would've never been found
[15:11:01] *** Quits: hukhekhok (~hukhekhok@178.229.172.141) (Ping timeout: 250 seconds)
[15:11:04] <inference> amdj: printf("Hello World")
[15:11:13] <JTL> (while scaring the beejeesus of the internet in the process)
[15:11:15] <sam_> negril: yeah no pub for me lol
[15:11:20] <levitating> q3k: the flag is the public RSA key that will log into any sshd process linked to the backdoor
[15:11:33] <amdj> levitating: that won't work.
[15:11:33] <inference> Would this work with ED25519 keys?
[15:11:36] <negril> sam_: at least it's a good distraction :D
[15:11:38] <FireFly> amdj: . o O ( marketing stunt/ARG to advertise your new infosec product )
[15:11:48] <plat0> ok so levitating hear me out what if we then factor that key :)
[15:11:49] <negril> https://paste.gentoo.zip/xwtCU1Im the installer script for anyone that cares
[15:11:53] <sam_> negril: absolutely.. lmao
[15:12:00] <amdj> levitating: the SSH login process has the client offer the server a public key, the server checks if that key is in authorized_keys, then you have to sign a login challenge with the corresponding private key.
[15:12:10] *** Joins: Dervom (~Dervom@192.42.46.113)
[15:12:22] *** Joins: Guestasldfjalshg (~Guestasld@104.36.71.200.16clouds.com)
[15:12:29] <amdj> levitating: so what I think is that if you know the public key of someone and you know the box they login to, you can pass an invalid signature during the login process but the exploit will convince sshd that the signature is authentic.
[15:12:29] <dostoyevsky2> amdj: are there many other programs using libcrypt btw?
[15:12:35] <neko2> lol I'm reading the lwn quotes about the matter... although I don't get how this would happen: > Incredible work from Andres. The attackers made a serious strategic mistake: they made PostgreSQL slightly slower.
[15:12:54] <inference> amdj: Does that `RSA` function also happen for ed25519? I only use those keys, not that my system is affected regardless.
[15:12:55] <tolto> wait how is xz related to postgresql? does postgresql use xz for compression?
[15:13:00] <amdj> inference: no.
[15:13:12] <plat0> tolto this was discovered while benchmarking pgsql
[15:13:21] <tolto> and why would it be much slower? i'd expect the payload to quit once it discovers that the binary isn't sshd
[15:13:21] *** Joins: gagz (~gagz@user/gagz)
[15:13:29] <tolto> plat0: huh
[15:13:36] <plat0> i lost the tab :(
[15:13:38] <plat0> anyone back me up?
[15:13:54] <FireFly> tolto: the machine it was benchmarket on had openssh running
[15:14:06] <FireFly> which affected cpu perf
[15:14:07] <amdj> neko2, tolto: https://mastodon.social/@AndresFreundTec/112180083704606941
[15:14:18] *** Quits: beforelight (~beforelig@32-218-57-192.bng02.brpt.ct.frontiernet.net) (Quit: Client closed)
[15:14:22] *** Joins: Guest4 (~Guest4@2a09:bac3:7098:10f::1b:203)
[15:14:22] <amdj> (the person who wrote the openwall submission)
[15:14:28] <tolto> ohh
[15:14:37] <levitating> tolto: the backdoor could have more targets than sshd. And I think the major slowdowns were an oversight
[15:14:49] <tolto> yeah
[15:14:57] <neko2> oh right, they were benchmarking and the sshd nonsense in the background was causing problems™. god damnit my brain is so fried
[15:15:01] <tolto> https://git.tukaani.org/?p=xz.git;a=blobdiff;f=.github/SECURITY.md;h=9ddfe8e946cf1810f131bf4f56156626b7ca7e31;hp=e9b3458a2c377fea765483d51df5a33ebca8fd3e;hb=af071ef7702debef4f1d324616a0137a5001c14c;hpb=0b99783d63f27606936bb79a16c52d0d70c0b56f
[15:15:03] <tolto> lol
[15:15:11] <tolto> funny how Jia was editing SECURITY.md
[15:15:17] <amdj> the slowdowns are entirely accidental I reckon. it's only because sshd forks *and* re-execs itself when handling new connections. if it only forked, the slow bit would only run once; when sshd starts. not every time someone tries to login.
[15:15:18] <plat0> >spend 2 years in deep cover only for you to get caught because you made someone's benchmark slower
[15:15:21] *** Joins: protox (~protox@gateway/tor-sasl/protox)
[15:15:21] <plat0> i'd just quit at that point
[15:15:22] <tolto> totally not forecasting anything at all... not
[15:15:40] *** Quits: Guest85 (~Guest85@46.121.164.212) (Quit: Client closed)
[15:15:57] <tolto> plat0: yeah i can imagine how happy they were once they figured out their "dot" passed the reviews XD
[15:16:07] *** Joins: Guest89 (~Guest89@host-216-158-111-12.junet.se)
[15:16:08] <JTL> plat0: clearly exploit developers need to step up their QA game
[15:16:10] *** Quits: Guest4 (~Guest4@2a09:bac3:7098:10f::1b:203) (Client Quit)
[15:16:12] <tolto> and other similar things
[15:16:32] <plat0> JTL that and they need to hire someone that knows micro-optimizations
[15:16:37] *** Quits: Guest522234235 (~Guest5222@68.65.160.9) (Quit: Client closed)
[15:16:59] <dostoyevsky2> amdj: I wonder if the obfuscation of the exploit made it slower, but yeah, once those symbols are mapped, the ifuncs don't need to be loaded again
[15:17:21] <levitating> amdj: both could work no? a backdoor typically isn't that targeted, my guess is that if it is related to authentication it would let certain public keys in. It's an 88K object file most likely specifically built for sshd it could do anything
[15:17:27] *** Joins: io_default (~io_defaul@user/io-default/x-3141089)
[15:17:27] <plat0> according to *someone* that's the cause for the slowness dostoyevsky2
[15:17:39] *** Joins: guiambros (~guiambros@pool-100-33-241-112.nycmny.fios.verizon.net)
[15:17:45] <negril> levitating: a lot of the 88k is the original library
[15:17:48] <plat0> (<3 u q3 k [dont wanna ping tho])
[15:18:01] <amdj> dostoyevsky2: except they would be resolved all over again because sshd re-execs itself.
[15:18:05] <neko2> tfw if I'm slightly fried as a technical end user worrying about this stuff... I send strength to the people busting their backsides to get to the bottom of this, your work is truly appreciated
[15:18:25] <dostoyevsky2> amdj: for privsep, right?
[15:18:32] <plat0> as an end-user, just patchpatchpatchpatch
[15:18:41] <plat0> or well in this case down/upgrade
[15:18:42] <protox> any updates on the reverse engineering of the payload/backdoor?
[15:18:44] <levitating> negril: that's not true, if I built with the backdoor in or out I get like a 100K difference. Besides I managed to extract the specific .o from the binary test files.
[15:19:06] <amdj> dostoyevsky2: right. another benefit is that you don't have to restart sshd after upgrading it.
[15:19:07] <negril> levitating: oh, yeah the script has 88664 as length
[15:19:49] <tolto> >In xz 5.6.1 the backdoor was further obfuscated, removing symbol names.
[15:19:49] <ozars2> protox: q3k had some breakthrough on strings stored as trie https://social.hackerspace.pl/@q3k/112184695043115759
[15:20:01] <tolto> why didn't they remove the symbols initially? seems like an oversight
[15:20:07] *** Joins: Guest49 (~Guest49@2a02:8071:b84:0:e9e6:882b:cb5:68c)
[15:20:07] <levitating> negril: one way I found to get the liblzma_la-crc64-fast-5.6.0.o as generated from the script is to copy it in a while loop during compilation, that will give you the final version before it is deleted
[15:20:21] *** Joins: AnhTay (anh@user/AnhTay)
[15:20:25] <dostoyevsky2> tolto: I decompiled the .o file yesterday on dogbolt.org, worked fine 
[15:20:33] *** Quits: Dervom (~Dervom@192.42.46.113) (Quit: Client closed)
[15:20:39] <plat0> tolto from experience: nobody knows how to build for linux and every single binary you disassemble will end up having symbols because people keep forgetting to strip
[15:20:41] <tolto> dostoyevsky2: ohh. it has symbols still?
[15:21:01] <dostoyevsky2> tolto: https://dogbolt.org/?id=f784e46b-dae6-4ab5-9bf1-180e3e25da2b
[15:21:05] <protox> ozars2: thnx!
[15:21:10] <tolto> plat0: true, but they should have put their binary into IDA or Ghidra first to verify how easy would it be for someone to RE
[15:21:14] <ryzenda> https://boehs.org/node/everything-i-know-about-the-xz-backdoor mentions jiatan on Libera.chat with IP address, and currently /whowas jiatan is showing me [JiaTan] (~Jia@164.215.32.136): --- which is a different ip address
[15:21:16] <dostoyevsky2> Yeah, I guess that's the 5.6.0 version, which still had symbols
[15:21:22] <kalekale> when will the xz repo be back up? 
[15:21:23] *** Quits: Guest53 (~Guest53@p1618002-ipoe.ipoe.ocn.ne.jp) (Quit: Client closed)
[15:21:29] <levitating> https://dogbolt.org/?id=f784e46b-dae6-4ab5-9bf1-180e3e25da2b
[15:21:37] <kalekale> >xz-5.4.6_1: fetching distfile 'xz-5.4.6.tar.gz' from 'https://github.com/tukaani-project/xz/releases/download/v5.4.6/xz-5.4.6.tar.gz&apos;
[15:21:39] <kalekale> mfw 
[15:21:44] <levitating> dostoyevsky2: ah you were faster
[15:21:51] *** Quits: Totoposto (~Totoposto@197.153.79.137) (Ping timeout: 250 seconds)
[15:21:58] <protox> i am curious, are the test files used properly in the build, i.e do they actually act like a test file for XZ, or is the entire tests file a hand-crafted binary?
[15:22:01] <konimex> kalekale: it's never down in the first place (git.tukaani.org)
[15:22:28] <plat0> we need figma multiuser for ida
[15:22:31] *** Quits: inference (~inference@host-92-27-157-205.static.as13285.net) (Quit: Client closed)
[15:22:32] *** Joins: beforelight (~user@32-218-57-192.bng02.brpt.ct.frontiernet.net)
[15:22:37] <kalekale> oh i should have made it create 
[15:22:39] <kalekale> cleaer*
[15:22:41] <kalekale> clear*
[15:22:43] <levitating> protox: no lmao
[15:22:51] <levitating> they aren't actually used
[15:22:55] <kalekale> im looking for their release source archives 
[15:23:03] <levitating> kalekale: archive.org
[15:23:17] <DasBrain> Fun fact: When I had my home directory on NFS and the nfs server had root squash, logging in with my key still worked. Turns out sshd will do a seteuid or something similar to read the authorized_keys.
[15:23:23] <kalekale> oh right thank you that will do for now
[15:23:38] <amdj> DasBrain: reading keys happens before dropping privileges.
[15:24:00] <amdj> this is why AuthorizedKeysCommand can run as arbitrary users.
[15:24:16] <plat0> yknow, that oddly makes sense
[15:24:26] <DasBrain> Yes, but they are accessed in a way that works with NFS and root squash.
[15:24:29] <Guest78> ryzenda that was a VPN with M247 as ISP. They probably always use some VPN to hide their true location.
[15:24:53] *** Quits: Guest51 (~Guest76@n219078183117.netvigator.com) (Quit: Client closed)
[15:25:16] *** Joins: Guest67 (~Guest91@2a01:4f8:1c1e:a0e0::1)
[15:26:28] *** Joins: aloisw_ (~aloisw@user/aloisw)
[15:26:32] <JTL> Guest78: and unless they fucked up and didn't use VPN one time and someone logged that...
[15:26:33] <JTL> Of course "professionals" don't use setups that have the possiblity of tunnel leaks
[15:26:58] <protox> I think it should be a standard now to not include binary files into your repo, like in this example for tests files. If they need to be a binary, maybe a bash script that generates that binary could be pushed instead "i generated these test files on my computer *wink* *wink*"
[15:27:14] <ryzenda> hmm, 3 hours 25 minutes ago gamer191 mentioned a URL and I see now that specific url has 1 archive at wayback machine, I wonder why that is, not sure what it means or relevant or whatever but http://web.archive.org/web/20240329211902/https://github.com/tukaani-project/xz/commit/328c52da8a2bbb81307644efdb58db2c422d9ba7
[15:27:16] <kalekale> archive.org wont give it to me 
[15:27:18] <kalekale> ERROR 429: TOO MANY REQUESTS.
[15:27:28] <kalekale> guess ill just wait for things to settle 
[15:27:45] <plat0> i think this entire situation has upset IA
[15:27:49] *** Joins: Guest18 (~Guest18@c80-216-127-193.bredband.tele2.se)
[15:27:55] <amdj> kalekale: if you only want the archive for RE efforts, the malicious transcripted object file is attached to the openwall posty.
[15:27:56] <amdj> post*
[15:28:00] <ryzenda> but I see the comment "This little dot is just pure evil." which is similar to what was discussed before that link too
[15:28:03] *** Joins: wobfan (~wobfan@200116b80a3d34011caf5ff46f0e9fac.dip.versatel-1u1.de)
[15:28:11] *** Joins: carbon_dioxide (~CO2@ankh-morpork-clacks-tower.connected.by.freedominter.net)
[15:28:14] <kalekale> oh no its not for RE 
[15:28:19] *** Quits: Guest58 (~Guest58@2a10:3781:35cc:1:a50c:4ebf:7b2:9475) (Quit: Client closed)
[15:28:23] *** Quits: aloisw (~aloisw@user/aloisw) (Ping timeout: 255 seconds)
[15:28:26] <kalekale> i need older source archives generated by github actions 
[15:29:17] <levitating> kalekale: I don't think their tarballs were generated by github actions
[15:29:29] <kalekale> oh did they manually create it 
[15:29:32] <kalekale> same thing 
[15:29:48] <kalekale> ill just do it myself then 
[15:30:26] *** Joins: ozel (~ozel@2a02:8071:886:560:c52b:3976:d600:16d4)
[15:30:54] *** Joins: Fresh_Meat (~Fresh_Mea@82.78.164.200)
[15:31:20] *** Quits: protox (~protox@gateway/tor-sasl/protox) (Quit: Leaving)
[15:31:49] *** Quits: carbon_dioxide (~CO2@ankh-morpork-clacks-tower.connected.by.freedominter.net) (Remote host closed the connection)
[15:31:50] <tolto> looks like JiaTan was here several hours ago
[15:31:54] <tolto> * [JiaTan] tungsten.libera.chat :Sat Mar 30 12:04:19 2024
[15:32:17] *** Joins: koutakun (~koutakun@2800:a4:140d:2c00:b855:1177:7f1:417b)
[15:32:22] *** Joins: Guest50 (~Guest50@n7226t9c5wh20wtp1h2-1.v6.elisa-mobile.fi)
[15:32:23] <tolto> the IP is from Freedome VPN, Finland. that's funny
[15:32:24] *** Quits: Guest18 (~Guest18@c80-216-127-193.bredband.tele2.se) (Quit: Client closed)
[15:32:28] *** Quits: ErrorNoInternet (~error@23.162.40.16) (Ping timeout: 255 seconds)
[15:32:37] *** Joins: Guest32 (~Guest43@171.6.144.51)
[15:33:13] *** Quits: Guest89 (~Guest89@host-216-158-111-12.junet.se) (Quit: Client closed)
[15:33:33] *** Quits: Guest6 (~Guest54@129.145.50.30) (Ping timeout: 250 seconds)
[15:33:43] *** Joins: Guest61 (~Guest61@nmal-25-b2-v4wan-166401-cust115.vm24.cable.virginm.net)
[15:33:45] *** Quits: koutakun (~koutakun@2800:a4:140d:2c00:b855:1177:7f1:417b) (Client Quit)
[15:33:48] *** Guest61 is now known as k_
[15:33:56] <kalekale> are you a libera irc cop tolto 
[15:34:01] <tolto> no
[15:34:02] *** k_ is now known as k__
[15:34:04] <DasBrain> tolto: Sure it was JiaTan and not some troll?
[15:34:21] *** Joins: ErrorNoInternet (~error@204.152.216.102)
[15:34:21] *** kalekale is now known as JiaTan
[15:34:24] <JiaTan> lol
[15:34:28] *** JiaTan is now known as kalekale
[15:34:29] *** Joins: IntrnlCmplrErr (~IntrnlCmp@2607:fea8:9565:8e00::c54)
[15:34:33] <kalekale> probably a troll
[15:34:38] <plat0> oh shiiii its themm!!!!111
[15:34:40] <tolto> DasBrain: no idea. i wonder if he was registered on ChanServ
[15:34:48] <tolto> NickServ* i mean
[15:34:49] *** Joins: Guest62 (~Guest96@89-78-179-85.dynamic.chello.pl)
[15:35:00] <plat0> i saw a post somewhere about that, yeah there was a jiatan reg on nickserv
[15:35:16] <DasBrain> Ohh, NEWS tolto: --	[JiaTan] was logged in as kalekale /s
[15:35:25] <tolto> yeah you're right
[15:35:29] <plat0>     -NickServ- Information on jiatan (account jiatan):
[15:35:29] <plat0>     -NickServ- Registered : Dec 12 13:43:12 2022 +0000 (1y 15w 3d ago)
[15:35:29] <plat0>     -NickServ- Last seen : (less than two weeks ago)
[15:35:29] <plat0>     -NickServ- User seen : (less than two weeks ago)
[15:35:29] <plat0>     -NickServ- Flags : HideMail, Private
[15:35:30] <plat0>     -NickServ- jiatan has enabled nick protection
[15:35:30] <plat0>     -NickServ- *** End of Info ***
[15:35:31] <JTL> I think the JiaTan sighting on /whowas is a red herring, because it doesn't say it was logged in as him
[15:35:41] <plat0> from https://news.ycombinator.com/item?id=39870098
[15:35:49] *** Joins: cc_ (cc@henkirikos.com)
[15:36:01] <amdj> let's not start with the trying to dig up dox on them saga again please
[15:36:03] *** Joins: carbon_dioxide (~CO2@ankh-morpork-clacks-tower.connected.by.freedominter.net)
[15:36:16] <ErrorNoInternet> lots of people are gonna get confused by new whowas now lol
[15:36:19] *** Quits: beaver55 (~beaver@113.163.178.101) (Quit: Client closed)
[15:36:32] <tolto> lol
[15:36:44] *** Joins: tsohun (~tsohun@94.248.247.254)
[15:36:44] <kalekale> lmao 
[15:36:53] <orkim> incoming swat team in 3... 2...
[15:36:56] <kalekale> the feds are gonna get me
[15:36:56] <plat0> welp kalekale expect a few angry PMs :P
[15:36:58] *** levitating is now known as jiatan
[15:37:00] <jiatan> who?
[15:37:01] *** Quits: Guest49 (~Guest49@2a02:8071:b84:0:e9e6:882b:cb5:68c) (Ping timeout: 250 seconds)
[15:37:03] <neko2> was also just thinking the name itself is probably a red herring as to the affiliation of whoever was behind it
[15:37:05] *** jiatan is now known as levitating
[15:37:07] <Guest22> Was anywhere explained how the hooking works? As in: sshd does something, system-notify is triggered, but how does IFUNC just get to hook into that?
[15:37:10] <kalekale> thanks for saving me levitating 
[15:37:10] <JTL> neko2: that too
[15:37:14] <plat0> "im the real jiatan", "no im the real jiatan"
[15:37:19] <kalekale> lol
[15:37:37] <amdj> Guest22: the dynamic linker resolves ifuncs at library load time (before sshd's main() is executed)
[15:37:41] <levitating> neko2: If it wasn't him someone had his keys for a while
[15:37:44] <kalekale> does nickserv kick you after not id'ing after a few minutes or something
[15:37:47] <kalekale> i think rizon does that
[15:37:52] <amdj> it does.
[15:37:56] *** Quits: tsohun (~tsohun@94.248.247.254) (Read error: Connection reset by peer)
[15:38:08] <amdj> you would have gotten a notice from it.
[15:38:11] *** Joins: tsohun (~tsohun@94.248.247.254)
[15:38:19] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[15:38:24] <kalekale> oh yeah 30 seconds to id 
[15:38:36] *** Joins: Guest56 (~Guest56@22-202-209-87.ftth.glasoperator.nl)
[15:38:53] *** Joins: pnut27 (~pnut27@67-198-79-118.dyn.grandenetworks.net)
[15:40:04] <Guest22> amdj so all it takes is the dynamic linker resolving what it found in the lib, regardless of whether systemd-notify had a call to some function in the lib or not?
[15:40:21] <amdj> it doesn't matter whether openssh *calls* any systemd things or not.
[15:40:44] <amdj> just that openssh is linked against libsystemd, which is itself linked against liblzma, which contains a malicious ifunc resolver that intercepts the PLT for openssl.
[15:40:52] <carbon_dioxide> kalekale: auto nick changes on failed login are configurable, see [ /msg nickserv help set enforce ] and[ /msg nickserv help set enforcetime ]
[15:40:59] <Guest22> I see, thanks, gonna read up on it
[15:41:17] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[15:42:06] *** Quits: tsohun (~tsohun@94.248.247.254) (Remote host closed the connection)
[15:42:27] <jess> sam_: outstanding
[15:42:27] <DasBrain> /ns help set enforcetime
[15:42:44] *** Joins: iw250 (~ct@80.153.93.225)
[15:42:46] *** Quits: Guest13 (~Guest13@093105177108.dynamic-2-waw-k-1-1-0.vectranet.pl) (Quit: Client closed)
[15:43:00] *** Joins: tsohun (~tsohun@94.248.247.254)
[15:43:27] <ryzenda> hsiangkao, regarding trust, to me, Microsoft disabling the GitHub repo is a massive red flag signal that Microsoft does not care about any humanity other than its own selfish power to hijack timed at its own determination of timing to do so, and this even prevents the responsible entities to fix things by delegating alternative entities to asssume responsibility and takeover from there. Not everyone is concentrated on 
[15:43:27] <ryzenda> GitHub, but for example even a few hours ago in https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2 states:
[15:43:37] <ryzenda> "GitHub has disabled the xz repo: ... This package now can't be built from source."
[15:43:43] *** Joins: Guest4197 (~Guest41@p54b6fe4f.dip0.t-ipconnect.de)
[15:44:08] <ryzenda> which is not true, because the git.tukaani.org is still active, primary repo as far I have learned
[15:44:22] <orkim> and theres also about a million copies of it out there now.. ;)
[15:44:25] <dostoyevsky2> ryzenda: so then you can add the scripts from openwall.com to make logging in without key working again
[15:44:30] <susi> I wouldn't make such ... wht's the word, conclusions of this action
[15:45:00] <ryzenda> but I think there are far more eyes and attentions on GitHub, which is now owned by Microsoft, so it's like disrespect is centralized manufacturedly normal now, and I don't see any practical decentralized git things yet so....
[15:45:15] *** Quits: pastapoggers (~pastapogg@147.236.229.233) (Ping timeout: 250 seconds)
[15:45:24] <kalekale> im having the same problem 
[15:45:27] <neko2> amdj: personally I am a little bothered libraries could possibly pull hijacking stunts like that (outside of being explicitly granted that power by the the linker e.g. LD_PRELOAD) but that is just the state of the trust model in linux processes at the moment.
[15:45:30] <kalekale> the void package cant be built from source 
[15:45:40] <neko2> susi: jump to such conclusions?
[15:45:50] <susi> yeah, thanks
[15:46:15] <eam> are the compromised build artifacts available anywhere for download/analysis?
[15:46:31] <amdj> the openwall post has the malicious object file that the compromised build system artifact drops.
[15:46:57] <ryzenda> oh, and of course, given what I heard/learned/read so far, the tukaani git repo was not affected at all, just the github repo was, and that in and of itself resulted in compromising a lot of connected infrastructures throughout the world, so then that means a lot of pieces were already in place to facilitate this vulnerability to be signalingly opportunistic, and if there were no GitHub repo, it might not have happened at 
[15:46:57] <ryzenda> all, lol rip
[15:47:02] <ozars2> neko2: +1 that's likely a fixable problem though potentially with some massive effort and breaking existing ABI and tools
[15:47:19] <amdj> it's entirely fixable today already: just don't use glibc.
[15:47:23] <negril> ryzenda: the gh repo wasn't affected. how could it be. The release assets were
[15:47:34] <amdj> it's glibc's dynamic linker that supports ifuncs. musl doesn't for example.
[15:47:55] <FUZxxl> ddd
[15:48:09] <amdj> however there are numerous other ways
[15:48:12] <ozars2> ifuncs has legit use cases though, right, like having multiarch functions in a single binary iiuc
[15:48:13] <aesthetics> any musl distro to suggest ? i guess alpine, but perhaps there are others worth trying ?
[15:48:17] <amdj> such as __attribute__((__constructor__))
[15:48:20] *** Quits: tsohun (~tsohun@94.248.247.254) (Quit: leaving)
[15:48:32] <amdj> which also cause code to run before main().
[15:48:47] *** Quits: Guest67 (~Guest91@2a01:4f8:1c1e:a0e0::1) (Quit: Client closed)
[15:48:50] <DasBrain> I think it is strange that setting some environment variable could lead to code execution.
[15:48:54] <amdj> (and thus while the PLT is still vulnerable to manual malicious modifications)
[15:48:59] *** Quits: Guest24 (~Guest24@2a02:8070:c688:4200:36e6:1115:b320:d495) (Quit: Client closed)
[15:49:14] <DasBrain> And at the same time - probably one of the easiest ways to pass data to subprocesses.
[15:49:18] <dstolfa> you could also override one of the many weak symbols laying around...
[15:49:53] <konimex> aesthetics: if you want something radically different, then chimera?
[15:50:01] *** Quits: Guest78 (~Guest17@p200300fe170e3404bda60eb757fc7d95.dip0.t-ipconnect.de) (Ping timeout: 250 seconds)
[15:50:02] <DPA> I use __attribute__((constructor)) a lot in my programs and libraries. It's very useful.
[15:50:08] <negril> DasBrain: the env variables were only used to detect the rpm build environment
[15:50:12] <aesthetics> konimex: thanks, checking
[15:50:53] *** Quits: Guest56 (~Guest56@22-202-209-87.ftth.glasoperator.nl) (Quit: Client closed)
[15:51:28] *** Joins: tsohun (~tsohun@94.248.247.254)
[15:51:57] *** Quits: Ampersander (~Ampersand@dzx2k8ybjcy0bp-m4gyft-3.rev.dnainternet.fi) (Ping timeout: 260 seconds)
[15:52:15] *** Quits: tsohun (~tsohun@94.248.247.254) (Client Quit)
[15:52:26] <eam> if you don't want libraries calling code before main, you'll need to change the linker too - think about .init
[15:53:08] *** Joins: blingbling96 (~blingblin@89.125.87.194)
[15:53:09] <eam> readelf -p .init /bin/ls, etc
[15:53:13] <DPA> With __attribute__((constructor)) I can initialize things without having to know & list them all in one place. And I can also use that to create lists at startups, without listing every entry in one file explicitly. Such lists can also be of implementations of interfaces. This allows for a kind of inversion of control (IoC).
[15:53:51] <hsiangkao> ryzenda: +1, github is not good, yet I think Lasse could send an email to try to recover his account. I don't know what happened though.
[15:54:07] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Quit: Client closed)
[15:54:14] <amdj> github T&S will no doubt be in contact with him shortly.
[15:54:14] <otila> stupid Github keeps telling me I have unread notifications; there is only that disabled xz repo where there are/were notifications I can't read now
[15:54:37] *** Joins: Guest20 (~Guest20@192.222.198.98)
[15:54:40] *** Joins: koutakun (~koutakun@2800:a4:140d:2c00::8fd)
[15:54:56] <neko2> ozars2: admittedly the way I would have fixed it would have been POLA'ing what library code can call and locking down globals, which I guess does look like, for starters, not letting random libraries touch stuff like the ifunc business (*by default*) if it allowed this. or, it has to be passed some sort of capability to do that, preferably under control of the built program. (and idk how you'd enforce that 
[15:55:02] <neko2> a program can't just jump to the routine addresses anyway or forge said capability)
[15:55:20] *** Joins: Salamandar60 (~Salamanda@2001:912:1ac0:f00:2153:8e32:d87c:e023)
[15:55:44] *** Quits: Salamandar60 (~Salamanda@2001:912:1ac0:f00:2153:8e32:d87c:e023) (Client Quit)
[15:56:18] <neko2> (I acknowlege the latter would likely be quite invasive, so unlikely to happen in the real world.)
[15:56:57] *** Quits: blingbling (~blingblin@89.125.87.194) (Ping timeout: 250 seconds)
[15:57:05] *** Joins: tsohun (~tsohun@94.248.247.254)
[15:57:05] <DPA> It's impossible to do.
[15:57:11] <ozars2> what's polaing? ack even changing ABIs to have namespace encapsulation and forcing that at runtime might be impractical.
[15:57:20] *** Joins: fox911 (~fox911@i59F556E2.versanet.de)
[15:57:22] <sam_> yes, impossible pipedream nonsense
[15:57:27] <amdj> principle of least astonishment
[15:57:38] <neko2> I was thinking authority, but... x)
[15:57:51] <amdj> oh that works too
[15:58:02] *** Quits: wobfan (~wobfan@200116b80a3d34011caf5ff46f0e9fac.dip.versatel-1u1.de) (Quit: Client closed)
[15:58:20] <DPA> It's possible to remap a page readonly, but as far as I know, there is currently no way to prevent one from undoing that again.
[15:58:49] <eam> are there any systems where modules can't run code at load time? I can't think of any
[15:59:00] *** Joins: cfsf (~cfsf@113.163.178.101)
[15:59:20] <neko2> DPA: ... unless you could control which code pages could make syscalls, although if that even were possible (I know of no such mechanisms??) I can see some random program complaining it broke their shit
[15:59:40] *** Quits: Guest84 (~Guest54@host-87-27-173-117.business.telecomitalia.it) (Quit: Client closed)
[15:59:59] <amdj> OpenBSD does just this
[16:00:00] <DPA> There exists seccomp, but it applies to the process and all processes it spawns.
[16:00:07] <amdj> only the system call section of libc is allowed to make system calls.
[16:00:19] <ozars2> dunno. Could it be forcing not being able run code at load time is a harder problem than a library loading before another library not being able to override symbols exported by the latter?
[16:00:48] <sam_> they used a clever technique to bypass relro, for example
[16:01:17] *** Quits: ozel (~ozel@2a02:8071:886:560:c52b:3976:d600:16d4) (Ping timeout: 250 seconds)
[16:02:12] <neko2> amdj: out of academic curiosity do you know how that's implemented? some kind of process lockdown set in the libc that is one-way?
[16:02:18] <neko2> wrt the openbsd thing
[16:02:20] *** Joins: dag (~d@user/dag)
[16:02:28] *** Quits: cfsf (~cfsf@113.163.178.101) (Remote host closed the connection)
[16:02:36] *** Joins: Guest51 (~Guest17@p200300fe170e3404df61032b42efa75a.dip0.t-ipconnect.de)
[16:02:40] <ryzenda> dstolfa, "it was probably just a window of opportunity to land some malicious code and let it settle. likely a backdoor in-progress, but caught early." -- in this regard, disabling the repo to prevent further issues, this makes sense, and since nobody else was around to do it, Microsoft doing it seems reasonable, like a leaky gas pipe, homeowner gone on vacation, so someone's gotta fix it before disaster
[16:02:50] <andreyv> neko2: Most likely they look at the caller address and only allow addresses from libc.so
[16:02:52] <amdj> neko2: IIRC it's a feature of their dynamic linker that informs the kernel where the system call stub area of libc is (that it just loaded into memory) and that call can only be executed once per process
[16:03:10] <amdj> and then the kernel checks that the system call was entered from that area
[16:03:10] *** Joins: pjonesuk (~pjones@90.193.71.60)
[16:03:19] *** Quits: tolto (~tolto@5402D3E4.dsl.pool.telekom.hu) (Quit: Leaving)
[16:03:19] <susi> https://sourceware.org/glibc/wiki/GNU_IFUNC
[16:03:44] <DPA> relro should be easy to circumvent. Allocate a page. Copy the one to be modified. Map a new page that's not ro over the to be modified area. Write the copy back there. Make the modification. Done.
[16:04:16] <DPA> All it takes is a bit of mmap.
[16:04:18] <amdj> https://lwn.net/Articles/806863/
[16:04:23] <amdj> OpenBSD details ^
[16:04:47] *** Joins: Guest56 (~Guest91@2a01:4f8:1c1e:a0e0::1)
[16:04:48] *** Quits: tsohun (~tsohun@94.248.247.254) (Quit: leaving)
[16:04:50] <FenderQ> :)
[16:05:04] *** Joins: tolto (~tolto@5402D3E4.dsl.pool.telekom.hu)
[16:05:16] *** Joins: tsohun (~tsohun@94.248.247.254)
[16:05:42] <amdj> (there have been lots of follow ups since that post, e.g.  https://marc.info/?l=openbsd-tech&m=169841790407370&w=2 )
[16:05:54] *** Quits: Guest62 (~Guest96@89-78-179-85.dynamic.chello.pl) (Quit: Client closed)
[16:05:55] *** Quits: lpt (~lpt@mob-5-90-174-217.net.vodafone.it) (Quit: Quit)
[16:06:11] *** Quits: Guest56 (~Guest91@2a01:4f8:1c1e:a0e0::1) (Client Quit)
[16:06:14] *** Joins: larry (~larry@2a02:810d:ae3f:ed2b:872c:56e4:cf90:3024)
[16:06:38] *** Joins: lpt (~lpt@host-87-16-54-137.retail.telecomitalia.it)
[16:06:54] <amdj> other things OpenBSD does are relinking the kernel and libc on every reboot. so not only does ASLR place them at a random offset each time they run, but also the position of 1 block of code in the binary with respect to any other block is also different every boot
[16:07:37] *** Joins: Guest45 (~Guest45@nat-88-212-17-169.antik.sk)
[16:08:12] <FenderQ> also libcrypto and sshd
[16:08:44] *** Quits: pajlada (~pajlada@user/pajlada) (Remote host closed the connection)
[16:09:00] *** Joins: pajlada (~pajlada@user/pajlada)
[16:09:07] <FenderQ> https://github.com/openbsd/src/blob/master/etc/rc
[16:09:21] *** Joins: JCWasmx86 (~JCWasmx86@185.254.75.47)
[16:09:42] <dostoyevsky2> amdj: I also like on OpenBSD that they write down random entropy before booting, so there will be good entryopy during boot... I think Linux also does this nowadays
[16:10:20] <koutakun> Is there a version of the detect.sh script that doesn't just check ssh? I use arch which doesn't have the SSHd patch but I'd like to check that no other lzma-linked programs are vulnerable
[16:10:20] <amdj> every modern Linux distro does this yes
[16:10:53] <amdj> koutakun: the script checks liblzma. just patch it to pass the path to liblzma.so instead of detecting it via ldd on sshd.
[16:11:04] <sam_> probably the most notable recent development on it was when zx2c4 improved openrc for it and busybox init and such
[16:11:12] <amdj> or adjust it to e.g. detect liblzma path via ldd on xz(1).
[16:11:47] <koutakun> That worked, thanks
[16:12:07] *** Quits: pjonesuk (~pjones@90.193.71.60) (Quit: leaving)
[16:12:09] *** Joins: amosbird (~amosbird@20.205.108.97)
[16:12:09] *** Joins: ozel (~ozel@2a02:8071:886:560:c52b:3976:d600:16d4)
[16:12:11] <ryzenda> mm, they're gone, but st3fan mentioned https://twitter.com/birchb0y/status/1773871381890924872 earlier and it is interesting. So then even Jia Tan, whoever they may be, if ever they return, hopefully they are okay, if they are innocent in the situation. I dunno, but again innocent until proven guilty, lol
[16:12:20] *** Joins: Guest59 (~Guest59@201.103.218.139.dyn.wbroadband.net.au)
[16:12:32] *** Quits: ericdiao (~ericdiao@146.115.83.242) (Quit: Client closed)
[16:12:40] *** Parts: Guest59 (~Guest59@201.103.218.139.dyn.wbroadband.net.au) ()
[16:12:57] <JTL> ryzenda: I mean it would suck if an innocent maintainer got hacked and someone pushed commits with their credentails
[16:13:02] <amdj> sam_: you mean the ioctl ?
[16:13:09] <carbon_dioxide> I just used xz --version to see if the liblzma version was one of the affected once. I know that's not foolproof, it's technically possible for another version of that lib to be living on the system but I think it would cover most cases?
[16:13:29] *** Joins: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net)
[16:13:29] <tolto> another possibility is jiatan was trying to commit at weird times on purpose. maybe he was waiting until Lasse went asleep
[16:13:35] <tolto> to do the offending commits
[16:13:43] <bdrewery> or there are multiple people using the account
[16:13:48] <sam_> amdj: referring to https://github.com/OpenRC/openrc/issues/506 and the work he did elsewhere around the time
[16:13:48] <tolto> yes, that too
[16:14:02] <tolto> in the jiatan's team, maybe some people were doing actually useful commits to xz
[16:14:06] <tolto> while others were adding backdoors
[16:14:12] <tolto> this is all speculation of course
[16:14:27] <amdj> sam_: yeah, the RNDADDENTROPY ioctl. urandom(4) is normally world-writable, so the kernel doesn't credit anything written to it.
[16:15:02] <amdj> I wrote a small boot time utility to do the ioctl long before this for that reason. 
[16:15:15] *** Joins: ante (~ante@user/ante)
[16:15:59] <sam_> ah
[16:16:13] <IntrnlCmplrErr> Hi all, I have done a little bit of C and C++ before so I'm not totoally lost to system level constructs. But I mostly sticked to standard guranteed features and did not dabble in compiler specific flags and attributes. Seeing the discussions about IFUNC, pure attribute, etc made me curious about them. Is there a name I should search for these kind of implementation specific things?  
[16:16:23] <IntrnlCmplrErr> Or should I just start reading the glibc wiki?
[16:16:31] <sam_> in this case it's a GNU extension 
[16:16:40] <sam_> i would probably search for that term
[16:17:07] *** Joins: Guest49 (~Guest49@ip-176-199-211-212.um44.pools.vodafone-ip.de)
[16:17:09] <amdj> IntrnlCmplrErr: GCC's documentation has a comprehensive list of function attributes.
[16:17:30] <amdj> including ifunc. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
[16:18:20] *** Quits: MPThLee (~MPThLee@user/MPThLee) (Remote host closed the connection)
[16:18:54] <IntrnlCmplrErr> admj: thanks! Before yesterday the only attriubte on GCC i knew was align and pack
[16:19:41] <amdj> those are variable attributes.
[16:19:51] <amdj> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html
[16:20:26] <amdj> (assuming you meant aligned and packed)
[16:20:33] *** Quits: kalekale (~kalekale@2400:1a00:b012:2d:c8a3:5bab:58f2:1721) (Quit: WeeChat 4.2.1)
[16:22:25] *** Joins: piercemundy (~piercemun@169.red-88-22-198.staticip.rima-tde.net)
[16:23:18] *** Joins: MPThLee_ (~MPThLee@user/MPThLee)
[16:23:38] *** Quits: Guest45 (~Guest45@nat-88-212-17-169.antik.sk) (Quit: Client closed)
[16:23:50] *** MPThLee_ is now known as MPThLee
[16:24:47] <IntrnlCmplrErr> thanks! my knowledge about ABI is unfortunately pretty sparse and my experience for asm is limited to a uni course on 68k, clearly there is much to improve on!
[16:24:54] <amdj> :]
[16:25:09] *** Quits: Guest27 (~Guest51@83-233-238-61.cust.bredband2.com) (Quit: Client closed)
[16:25:53] <JTL> IntrnlCmplrErr: it's a start!
[16:26:22] <amdj> not all of the attributes have any ABI considerations btw.
[16:26:39] <amdj> for example function attribute warn_unused_result only makes the compiler moan if you don't consume a function's return value.
[16:27:01] *** Joins: guest454 (~guest454@76.71.100.208)
[16:27:03] *** Joins: Guest52 (~Guest52@2a02:8084:42c3:d680:8d17:a703:f1d8:de6f)
[16:27:16] *** Quits: Guest21 (~Guest34@i577B1DAA.versanet.de) (Ping timeout: 250 seconds)
[16:27:24] *** Quits: zipace (~john@p200300ecef4b426745a580a44e90fc31.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
[16:27:36] <amdj> e.g.    static bool __attribute__((__warn_unused_result__)) check_admin_is_really_admin(void) { /* ... */ }
[16:27:56] <neko2> IntrnlCmplrErr: 68k? I raise you 86hc11 asm from my uni course. traces back to the 6800, so I guess some common ancestry with the 68k (the register set bears some resemblance as does a subset of the instructions)
[16:28:26] <neko2> (they uhh really wanted to force us to cope with an 8-bit mcu)
[16:28:32] *** Joins: l_bratch (~l_bratch@tghost.co.uk)
[16:28:34] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[16:28:45] *** Joins: Dervom (~Dervom@82.67.61.73)
[16:28:47] *** Joins: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491)
[16:29:24] *** Quits: pnut27 (~pnut27@67-198-79-118.dyn.grandenetworks.net) (Quit: Client closed)
[16:30:28] <IntrnlCmplrErr> amdj: for that use case I would have done https://en.cppreference.com/w/cpp/language/attributes/nodiscard in C++, but I'm aware there's a difference of culture between C++ and C
[16:30:33] *** Quits: Guest52 (~Guest52@2a02:8084:42c3:d680:8d17:a703:f1d8:de6f) (Client Quit)
[16:30:44] <sam_> the gnu attribute long predates nodiscard ;_
[16:30:45] <sam_> *;)
[16:30:45] <amdj> C++ [[nodiscard]] and C warn_unused_result are mostly equivalent yes
[16:30:51] <amdj> also what sam_ said.
[16:31:00] <sam_> lots of things start life as vendor extensions
[16:31:42] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Ping timeout: 246 seconds)
[16:32:19] *** Joins: Bl3nd3r (~Bl3nd3r@185.107.56.47)
[16:32:40] <IntrnlCmplrErr> sam_: i mostly meant using vendor specific attributes usually is frown upon in the C++ community (at least the subset I belonged to), and they rather see for a push for standardization. That's what I meant by difference of cultures
[16:33:07] * sam_ shrugs
[16:33:14] *** Joins: TheTechRobo (~TheTechRo@170.75.167.217)
[16:33:17] <neko2> wrt vendor extensions, don't I know it, taking an interest in graphics programming... (all the API extensions that started out as $prefix_NV_newshinything)
[16:33:18] *** Joins: Guest82 (~Guest82@78-57-169-35.static.zebra.lt)
[16:33:47] <Guest51> ryzenda there were also the commits on 26th of February with the dot and the very first one: https://github.com/libarchive/libarchive/pull/1609
[16:33:47] <Guest51> I don't think that the account was taken over by someone else. The timing could have a different reason. In some countries there are holidays (yesterday and Monday) and not everyone on IT works then.
[16:33:48] <Guest51> As this seemed also to be a NMU (non-maintainer update) in one of the distros (Debian, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024)
[16:33:48] <Guest51> Not sure if this was done at a time when lasse sleeps to have more time.
[16:34:13] <sam_> i'm not worried about the MNU
[16:34:14] <sam_> *NMU
[16:34:19] <sam_> the guy has been doing it for like 10 years
[16:34:22] <sam_> he just never formally adopted it in debian
[16:34:34] <Bl3nd3r> Who last saw Jia Tan here
[16:34:35] <sam_> a lot of people are freaking out about normal things here, or normal-but-not-ideal things
[16:34:49] *** Joins: shamyr (~shamyr@cst2-174-103.cust.vodafone.cz)
[16:35:01] *** Joins: Wennadocta (~Wennadoct@host-2a0d-8480-1-759.hosted-by-vdsina.ru)
[16:36:10] <Guest51> I just mentioned a fact, not saying that this was reason for freaking out. I was referring to the timeplot of the commits from the tweet sam_
[16:36:11] <Guest51> Still I dont believe that someone took over the JiaTan account.
[16:36:19] <ryzenda> https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006446#gistcomment-5006446 one instance where Jia's username was different
[16:37:13] <laanwj2> i would think they would already have raised hell by now if someone abused their account and pushed commits like that
[16:37:33] <ryzenda> posted 23 hours ago https://news.ycombinator.com/item?id=39866326
[16:38:51] *** Quits: tsohun (~tsohun@94.248.247.254) (Quit: leaving)
[16:38:56] <sam_> Guest51: (other people did freak out though :p)
[16:39:06] *** Joins: tsohun (~tsohun@94.248.247.254)
[16:40:05] <brlin> One person created a Discord server for the collaboration of reverse engineering of the malicious binary: https://discord.gg/XqTshWbR5F
[16:40:45] <Sora> how bout not using a spyware platform for such discussion
[16:40:54] *** Joins: Baughn (sid153359@user/Baughn)
[16:41:02] *** Quits: guest454 (~guest454@76.71.100.208) (Remote host closed the connection)
[16:41:16] *** Quits: JCWasmx86 (~JCWasmx86@185.254.75.47) (Quit: Client closed)
[16:41:25] <Wennadocta> lol
[16:41:26] <neko2> ... not to mention I had to check that domain very closely for common invite URL typosquats
[16:41:27] <Paistin> haha discord. 
[16:41:32] <neko2> on reflex
[16:41:45] <brlin> Sora: There are synced Matrix chats as well, refer: https://www.openwall.com/lists/oss-security/2024/03/30/26
[16:41:47] <Paistin> lets just all reveal our identities to discord to get spearheaded! sounds great!
[16:41:51] *** Joins: intc (~intc@gateway/tor-sasl/intc)
[16:42:10] <brlin> Paistin: :shrugs:
[16:42:21] <amdj> I think you mean spearphished.
[16:42:22] <eam> ryzenda: that could be expected if the update was made via the web
[16:42:23] *** Quits: tsohun (~tsohun@94.248.247.254) (Client Quit)
[16:42:29] *** Joins: guest111 (~guest111@c-174-160-80-156.hsd1.ca.comcast.net)
[16:42:39] *** Joins: tsohun (~tsohun@94.248.247.254)
[16:42:44] *** Quits: Dervom (~Dervom@82.67.61.73) (Quit: Client closed)
[16:42:54] *** Quits: guest111 (~guest111@c-174-160-80-156.hsd1.ca.comcast.net) (Client Quit)
[16:42:59] <negril> brlin: the line should be 'sed "r\n" $gl_am_configmake | eval $gl_path_map | $gl_localedir_prefix 
[16:42:59] <negril> -d 2>/dev/null' btw
[16:43:03] *** Quits: tsohun (~tsohun@94.248.247.254) (Client Quit)
[16:43:06] <brlin> Matrix: #xz-backdoor-reversing:nil.im  /  IRC: #xz-backdoor-reversing on irc.oftc.net  / Just paste it here for easier access.
[16:43:22] <IntrnlCmplrErr> unfortunately discord is really popular with gen-z kids (i'm one of them so i'd know...)
[16:43:28] *** Quits: nomadgeek (~nomadgeek@047-134-024-163.res.spectrum.com) (Ping timeout: 272 seconds)
[16:43:28] *** Joins: Dervom (~Dervom@82.67.61.73)
[16:43:40] *** Quits: Dervom (~Dervom@82.67.61.73) (Client Quit)
[16:43:46] <amdj> which one is gen Z again
[16:43:51] *** Joins: tsohun (~tsohun@94.248.247.254)
[16:43:56] *** Joins: leggo (~katt__@147.28.162.171)
[16:44:03] <A_Dragon> amdj: the one after mellenials
[16:44:14] <neko2> IntrnlCmplrErr: or if you have interest in a very niche community or the people you met there, like myself. thankfully I don't do anything important on there.
[16:44:18] <koutakun> amdj the ones who are now adults lol
[16:44:22] <IntrnlCmplrErr> wikipedia says "mid-to-late 1990s as starting birth years and the early 2010s "
[16:44:41] <JTL> brlin: there's also other channels here on Libera and HackInt (CCC network) where people have been talking about it
[16:44:41] <koutakun> early 2010s is a bit of a stretch it generally ends around 2008 or 2009
[16:44:50] <JTL> brlin: https://xkcd.com/927/
[16:45:02] <neko2> when I see a discord invite URL my own initial reaction is to scrutinise every letter of the URL because of how common typosquats are with it
[16:45:10] <brlin> JTL: lmao
[16:45:36] *** Joins: Totoposto (~Totoposto@197.153.79.137)
[16:45:36] *** Quits: Totoposto (~Totoposto@197.153.79.137) (Client Quit)
[16:45:36] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[16:45:43] *** Joins: Yogurt (~Yogurt@158.51.82.203)
[16:45:44] <neko2> (typosquat phishing in particular)
[16:45:51] <IntrnlCmplrErr> I think i'm in 15+ servers but really ever talk on one of them
[16:45:57] <emaste> 19:21 -!- Guest12345 [~Guest1234@c-24-3-31-206.hsd1.pa.comcast.net] has joined #tukaani
[16:46:03] <neko2> ah yes, classic
[16:46:29] <brlin> Now you mentioned xkcd I'd like share https://xkcd.com/2347/ 
[16:46:37] <A_Dragon> I return
[16:46:50] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[16:46:51] <amdj> brlin: I love that one.
[16:47:37] <neko2> feels very relevant right now although in this case it wasn't that it went away, it's that the critical smol important piece got injected with evil
[16:47:48] *** Quits: pera (~pera@user/pera) (Ping timeout: 256 seconds)
[16:48:05] <IntrnlCmplrErr> to be fair there are some nice communities on discord, the community Rust server is really nice to ask questions. #include<c++> also helped me once
[16:48:16] <neko2> (more relevant to the xkcd, the amount of time I see "just use imagemagick" for things that it's really poor at is rather distressing)
[16:48:33] <amdj> I like the alt text joke about how many deps IM has yeah
[16:49:09] <Rounin> The thing with so many of these services, though... Slack, Discord, GitHub, Trello, whatever, is they're members-only services run by commercial entities
[16:49:18] <Celelibi> neko2, but it can do everything!
[16:49:20] <Rounin> And people are entrustingtheir lives to them
[16:49:20] <amdj> although it's nothing compared to ffmpeg.
[16:49:31] <neko2> Celelibi: jack of all trades, master of none ;)
[16:49:36] <Rounin> I guess I should include Facebook in that
[16:49:45] <Celelibi> neko2, that's like, your opinion, man.
[16:50:02] *** Quits: otila (~otila@gateway/tor-sasl/otila) (Quit: leaving)
[16:50:10] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Ping timeout: 240 seconds)
[16:50:21] <fox911> all of this chat is counterproductive, help the man by reviewing every commit in the last 2.5 years
[16:50:26] *** Quits: fox911 (~fox911@i59F556E2.versanet.de) (Quit: fox911)
[16:50:47] <neko2> nice troll and leave...
[16:51:09] <amdj> yeah like there aren't already people doing that
[16:51:28] <neko2> amdj: it occurs to me you must have had the patience of a saint these past 24 hours
[16:51:32] *** Joins: Totoposto (~Totoposto@197.153.79.137)
[16:51:43] <Rounin> I'll review the last ones... Since they're the ones with the backdoor, we'd better take those out
[16:51:50] <Rounin> Now you can do the next ones, amdj 
[16:52:18] *** Joins: GravyP (~GravyP@197.153.79.137)
[16:52:33] <amdj> neko2: oh?
[16:52:54] *** Joins: wehttam (~wehttam@1.146.120.30)
[16:52:59] <neko2> amdj: well just like all the influx of people who maybe don't have a concrete grasp on the situation or are being armchair whatevers
[16:53:19] <amdj> oh I only opped up when abby needed to head off, that was a couple of hours ago.
[16:53:38] <neko2> ok, then you and collectively everyone modding the space
[16:53:47] <amdj> I didn't even join until I woke up this morning :P
[16:53:54] <InPhase> It seems like somebody is really going to need to go through all of the JiaT75 commits to other projects as well.  For example, here's a commit marked as adding an error printout, yet the change removes "safe_" from one of the safe_fprintf calls.  Is that okay within this codebase?  It is easy to bury a web of problems with subtle changes like this.
[16:54:00] <InPhase> https://github.com/libarchive/libarchive/pull/1609/files
[16:54:21] <neko2> oh, libarchive, I've heard that name a few times today
[16:54:26] <dstolfa> InPhase: if you look at the conversation in the pull request you'll get your answer
[16:54:29] <dstolfa> people have already looked at it
[16:54:33] *** Joins: pera (~pera@user/pera)
[16:54:34] *** Joins: nomadgee_ (~nomadgeek@047-134-024-163.res.spectrum.com)
[16:54:39] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[16:54:54] <InPhase> dstolfa: Ah, excellent.
[16:55:08] <InPhase> dstolfa: I was just searching around, but it's good this is happening rapidly.
[16:55:26] <Rounin> Hmm, yeah, the printf family of functions can be used to adjust the stack pointer, if the formatting string and parameters aren't in sync
[16:55:44] <amdj> or corrupt memory if the format string is outright wrong
[16:55:47] <dstolfa> Rounin: the problem is that it feeds untrusted archive contents into fprintf, which does not ANSI escape codes
[16:55:47] <Rounin> Since they're vararg functions... So if you were going to try to exploint something, chances are you would want an u... Yeah
[16:55:59] <dstolfa> there's a poc gif on the pull request as an example
[16:56:03] *** Joins: ssgelm (~ssgelm@debian/ssgelm)
[16:56:04] <dstolfa> but you could attack terminal emulators and other fun things with it
[16:56:36] <neko2> once again that comment about "this is going to be a fun week" on a nixpkgs issue about the xz backdoor comes to mind
[16:56:59] <neko2> knock-on stuff that gets unearthed
[16:57:05] *** Quits: iw250 (~ct@80.153.93.225) (Quit: Leaving)
[16:57:12] *** Quits: Guest9129 (~Guest91@178.79.157.230) (Quit: Connection closed)
[16:57:17] <neko2> (it was specifically about that dev's other commits in context)
[16:57:31] <Baughn> That was me. Though we got very lucky… I hope.
[16:57:45] <amdj> something similar happened with UMN and the Linux Kernel. a mass revert of everything, then an audit of what's safe to put back in.
[16:58:03] <amdj> (I believe someone linked that here earlier)
[16:58:41] <ryzenda> aesthetics, re thinking too much and "cry for help" I also just recently saw https://twitter.com/birchb0y/status/1773871381890924872/photo/1 that seems to suggest possibly (maybe not, but possibly) additional persons involved in hijacking accounts or whatever
[16:58:48] <amdj> https://lwn.net/Articles/853717/
[16:58:55] <amdj> https://lwn.net/Articles/854645/
[16:59:05] <amdj> & https://lwn.net/Articles/870417/
[17:00:12] *** Quits: Guest49 (~Guest49@ip-176-199-211-212.um44.pools.vodafone-ip.de) (Ping timeout: 250 seconds)
[17:01:01] <ryzenda> amdj, "i'm saying it wasn't malicious before that" -- I don't know well enough about history of first sign of malice or whatever, but the timeline shown in that photo at twitter link I mentioned above, maybe it matches
[17:01:55] <neko2> anyway, in case it was needed - I just wanted to say, everyone working on this, the distro reverts/patches/whatever and the reverse engineering effort, your work is appreciated. hope also that larhzu is doing ok and that this mess can be sorted out.
[17:01:58] *** Quits: nomadgee_ (~nomadgeek@047-134-024-163.res.spectrum.com) (Ping timeout: 252 seconds)
[17:02:10] <aesthetics> ryzenda: yep, saw that as well. don't know what to think about it ... seems kinda off. Also autumn's comment makes sense... can't be a compromised account because it'd be easy for the "breached user" to spot commits he didn't do himself
[17:03:47] *** Joins: linuxdaemon (linuxdemon@bnc.linuxdemon.xyz)
[17:03:54] <A_Dragon> linkfanel: beat you to it
[17:03:56] <A_Dragon> oops
[17:03:59] <A_Dragon> linuxdaemon: ^ *
[17:04:23] <linuxdaemon> A_Dragon: hm?
[17:04:29] <A_Dragon> you're LATE!
[17:04:39] <linuxdaemon> I was BUSY
[17:04:47] <A_Dragon> sleeping doesnt count
[17:05:01] <ryzenda> This is nice! https://news.ycombinator.com/item?id=39870048 Example of what this user JiaT75 did so far: https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPTSBnaXRodWJfZXZlbnRzIFdIRVJFIGFjdG9yX2xvZ2luPSdKaWFUNzUnIE9SREVSIEJZIGZpbGVfdGltZSBERVND
[17:05:14] <linuxdaemon> also no one is paying me to do this right now so my priorities are lower than 6 months ago lol
[17:05:22] <ryzenda> as mentioned earlier by ozars2 o/
[17:05:50] <neko2> play.clickhouse.com? ok aside what the heck is that domain, I would not click that
[17:05:56] *** Quits: hannula (~hannula@2001:999:504:3f89:7e5f:c8f:68d7:ffb0) (Ping timeout: 256 seconds)
[17:06:00] <neko2> *an aside
[17:06:02] <amdj> but it tells you to click it :(
[17:06:11] *** Joins: hannula (~hannula@mobile-access-6df047-139.dhcp.inet.fi)
[17:06:20] *** Joins: mrkiko (~mrkiko@user/mrkiko)
[17:06:22] *** Quits: ErrorNoInternet (~error@204.152.216.102) (Ping timeout: 252 seconds)
[17:06:39] <neko2> amdj: clearly IRC needs format codes that says "make this  s h i n y" to make it more convincing to click
[17:06:53] *** Joins: wehttam (~wehttam@1.146.120.30)
[17:07:03] <amdj> IRC has colour, bold, underline, italic, and reverse video (which some clients interpret as blink)
[17:07:16] <amdj> 04For example this
[17:07:27] <neko2> not good enough, all IRC clients need to support a glowy shader /j
[17:07:29] <linuxdaemon> [free things!](https://not.a.scam/free-money.php.exe.asp.jpg.sfv.bin.sh)
[17:07:32] *** Joins: nomadgeek (~nomadgeek@047-134-024-163.res.spectrum.com)
[17:07:38] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[17:08:16] *** Joins: ErrorNoInternet (~error@146.70.173.147)
[17:08:22] <neko2> linuxdaemon: an aquiantance of mine on libera has a domain specifically chosen to appear sus for personal file hosting, so that people leave it alone or to mess with people
[17:08:25] *** Joins: gelx (~gelx@2a02:8071:b84:0:66e1:cde6:a99e:a0ee)
[17:08:30] <IntrnlCmplrErr> did you know there's a .toyota TLD? https://icannwiki.org/.toyota
[17:08:39] <tolto> sus.toyoa
[17:08:45] <linuxdaemon> that tracks lol
[17:08:47] <tolto> toyota*
[17:08:59] <neko2> can't wait to see $profanity.toyota
[17:09:08] <ozars2> folks, clickhouse is a valid db, why and how they have dump of github api I have no idea: https://en.wikipedia.org/wiki/ClickHouse
[17:09:26] <ozars2> another shiny link :P
[17:09:43] *** Parts: mrkiko (~mrkiko@user/mrkiko) ()
[17:09:53] <neko2> lol. "it's shiny, use your imagination!!"
[17:09:58] <linuxdaemon> I saw someone throwing speculations about libarchive around, has anyone confirmed anything there?
[17:10:10] *** Joins: ultra980 (~ultra@2a02:2f0a:b308:4000:f565:881a:839:5e2a)
[17:10:32] <ryzenda> Rounin, What does TCC route stand for?
[17:10:36] *** Quits: shamyr (~shamyr@cst2-174-103.cust.vodafone.cz) (Ping timeout: 250 seconds)
[17:11:05] <ryzenda> ah, tiny c compiler
[17:11:39] *** Joins: alreadydone (~alreadydo@2601:152:300:6266:706e:6030:ffd:4024)
[17:12:14] <tolto> > I think it might be something like looking for functions which call some symbols, or looking for function calls with debug statements. We're pretty sure somewhere in there is a small x86_64 disassembler :). All of this to be able to patch different versions of openssh.
[17:12:16] <tolto> woah
[17:12:23] <IntrnlCmplrErr> ozars2: clickhouse probably has cloud db hosting service and someone built a project gets GitHub data into it allow you to query 
[17:12:29] <ryzenda> fullstop, "I've been giving this whole thing some thought, and I think that this back door was the root of something far larger, and it was nipped early." --- haha yeah, first thing I saw was big headline "ssh compromised" and I dropped everything I was doing to focus on what is going on, lol
[17:12:47] *** Quits: piercemundy (~piercemun@169.red-88-22-198.staticip.rima-tde.net) (Quit: Client closed)
[17:13:08] <nomadgeek> linuxdaemon: it does look like they make a sus commit over there. https://github.com/libarchive/libarchive/pull/2101
[17:13:12] *** Quits: Guest82 (~Guest82@78-57-169-35.static.zebra.lt) (Ping timeout: 250 seconds)
[17:13:36] *** Joins: pastapoggers (~pastapogg@147.236.229.233)
[17:14:02] <Celelibi> Some say that the lack of embedded media, of shiny formatting and all is a limitation of IRC. I rather see it as the best feature.
[17:14:11] *** Quits: alexl (~alexl@2a0a-a543-5d23-0-c574-d6cd-1a44-566.ipv6dyn.netcologne.de) (Quit: Client closed)
[17:14:19] <nomadgeek> linuxdaemon: looks like they swapped out some functions for the unsafe counterparts.
[17:14:34] <nomadgeek> Celelibi: agreed.
[17:14:46] <neko2> ugh. I need to go eat instead of watching all this infold
[17:14:47] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[17:14:49] <neko2> *unfold
[17:14:50] <linuxdaemon> 100%, makes it easier on my screen reader too
[17:14:57] *** Quits: Guest99 (~Guest99@90.193.71.60) (Quit: Client closed)
[17:15:04] *** Joins: wehttam (~wehttam@1.146.120.30)
[17:15:13] <neko2> sucks as it may, watching this all play out in realtime is more interesting than any hacking depiction in a movie could be
[17:15:19] *** Joins: Wessie (~Wessie@static.226.41.47.78.clients.your-server.de)
[17:15:36] *** Joins: wolf (~wolf@ircpuzzles/staff/wolf)
[17:15:37] <Paistin> does libera.chat have matrix bridge
[17:15:56] <IntrnlCmplrErr> cries in Discord and Slack with on my wayland compositor with their electron refusing to play nice 
[17:15:58] <aesthetics> neko2: to be fair this made me think about "the undeclared war" mini serie (really worth watching, especially when it comes to analysis)
[17:16:10] <ozars2> IntrnlCmplrErr: I found out they offer querying github events as recent as thi month and also offer dump https://ghe.clickhouse.tech/ (this one is linked from https://clickhouse.com/docs/en/getting-started/example-datasets/github-events, calm down folks), but I'm just surprised they do that
[17:16:15] *** Quits: koutakun (~koutakun@2800:a4:140d:2c00::8fd) (Quit: Client closed)
[17:16:21] <neko2> I recall saying elsewhere yesterday that given the level of obfuscation used, feels kinda like "reality stranger than fiction"
[17:16:37] *** Quits: sedcore (~sed@2a01:e0a:b7d:89b0:ad4:cff:fee2:7ba1) (Quit: Client closed)
[17:16:53] *** Quits: aloisw_ (~aloisw@user/aloisw) (Quit: Konversation terminated!)
[17:16:56] <nomadgeek> neko2: this is truly some nation-state action happening in plain sight. Seriously scary stuff.
[17:17:19] *** Joins: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net)
[17:17:24] *** Joins: onlyJak0b (~onlyJak0b@p50865e95.dip0.t-ipconnect.de)
[17:17:30] <IntrnlCmplrErr> a good cpu has joined
[17:17:33] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[17:17:40] <i860> :-)
[17:17:41] *** Joins: ampelbein (~ampelbein@2001:bc8:1864:c2b::1)
[17:17:49] <i860> anyone RE the payload yet?
[17:18:07] <aesthetics> q3.k was on it afaik
[17:18:15] <nomadgeek> i860: I've seen several folks working on it.
[17:18:17] <amdj> somewhat. still ongoing
[17:18:20] <JTL> neko2: well, if it wasn't a nation state, it could be some genius whose very persistent towards their goals, has a lot of "background" Knowledge and knows to take it slow
[17:18:21] <laanwj2> Paistin: libera used to have its own matrix bridge, but it was disabled (due to some issues), some channels are bridged individually but afaik there's no general bridge anymore
[17:18:24] *** Quits: Guestasldfjalshg (~Guestasld@104.36.71.200.16clouds.com) (Ping timeout: 250 seconds)
[17:18:40] <levitating> i860: q3k was able to get a list of symbols/strings out of it, encoded as a prefix trie
[17:18:53] <Paistin> laanwj2: shucks :<
[17:19:12] <JTL> neko2: but I think attribution is a minefield with this sort of thing, in particular if the attacker is concious of what evidence can be left behind and how to misdirect it.
[17:19:13] *** Quits: pastapoggers (~pastapogg@147.236.229.233) (Quit: Client closed)
[17:19:38] <q3k> levitating: actually calling it a DFA makes more sense :)
[17:19:38] <nomadgeek> JTL: if this isn't a nationstate (or hired by a nation state) I'll eat my hat.
[17:19:42] <q3k> it's like a half-regex engine thing
[17:20:03] <IntrnlCmplrErr> https://x.com/nugxperience/status/1773906926503591970?s=20
[17:20:33] <tolto> from what i heard, the .o is only used when building a deb or rpm on x86_64
[17:20:39] *** Joins: john_dee (~john_dee@165.76.243.129)
[17:20:39] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Quit: peace)
[17:20:46] <tolto> otherwise the malicious script skips using it
[17:20:50] *** Joins: selckin (~selckin@user/selckin)
[17:21:07] <nomadgeek> tolto: that appears to be correct based on what we know at this point.
[17:21:15] <levitating> q3k: That's funny cause I should be studying that subject for a test next week instead of reversing some backdoor
[17:21:23] <dostoyevsky2> q3k: does it look like C code or any known language or was it written in assembly?
[17:21:27] <q3k> totally C
[17:21:30] <nomadgeek> C
[17:21:52] *** Quits: Guest51 (~Guest17@p200300fe170e3404df61032b42efa75a.dip0.t-ipconnect.de) (Quit: Client closed)
[17:21:52] <q3k> C with structs, but not C++
[17:21:58] <amdj> tolto: and must be building with gcc and gnu ld
[17:22:07] <nomadgeek> The additional push of 5.6.1 added more obfuscation and removed more symbols.
[17:22:12] <amdj> or something that claims to be gnu ld
[17:22:21] <dostoyevsky2> q3k: Interesting... I guess if the dfa is turing complete you can use it to program
[17:22:31] *** Joins: Guest37 (~Guest88@2a00:23c6:b310:9201:a879:1ec:2a2f:25b1)
[17:22:39] <q3k> i don't think that was the point
[17:22:41] <q3k> i didn't see any cycles
[17:22:45] <Manis> IntrnlCmplrErr, crypto in AWK? WTF?
[17:22:47] <q3k> extracting the string was literally exploring all states
[17:22:53] <q3k> *strings
[17:23:15] <levitating> q3k: could you add the python code for extracting the dfa to the gist?
[17:23:26] <q3k> yeah i'll do it later
[17:23:38] <q3k> currently trying to decide if the piece of code i'm staring at is an x86_64 disassembler or not :)
[17:23:40] <dostoyevsky2> q3k: you used ghidra to RE the code?
[17:23:42] <q3k> yes
[17:23:52] <IntrnlCmplrErr> Manis: at this point nothing surprises me. Have you not heard of the universal problem solving solution? Convert it to string, apply some regex, convert back. \s
[17:24:13] <nomadgeek> IntrnlCmplrErr: 😆
[17:24:29] *** Joins: luccc (~lukas@ip-193-53-104-44.changeis.iunxi.net)
[17:24:43] *** Joins: Guest4 (~Guest4@bras-base-qubcpq0339w-grc-22-76-69-185-67.dsl.bell.ca)
[17:24:45] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[17:24:53] <Manis> IntrnlCmplrErr, I love AWK, don't get me wrong. Im just surprised that it works apparantly. Because the most annoying thing in AWK is to iterate over a string byte wise. And NULs in a string
[17:25:11] <IntrnlCmplrErr> amdj: so you're saying this would also not trigger if they used https://github.com/rui314/mold? Time to start shilling :laughs:
[17:25:25] <dostoyevsky2> q3k: I guess the jump instructions and modrm would be easy to spot in an disassembler
[17:25:28] <sam_> if you run mold --version, you will get your answer.
[17:25:29] <i860> Manis: that's basically every "scripting" language to be fair
[17:25:43] <sam_> $ mold --version
[17:25:44] <sam_> mold 2.30.0 (compatible with GNU ld)
[17:25:55] <sam_> I don't recall if the check does *GNU ld* or what
[17:25:59] <IntrnlCmplrErr> https://www.openwall.com/lists/oss-security/2024/03/29/4/1
[17:26:02] <Manis> i860, yeah, somewhat, but AWK and sed are worse. I know because I eventually gave up implementing a CRC in AWK
[17:26:03] <sam_> but linkers on linux will pretend to be GNU ld 
[17:26:08] *** Joins: vvuGuest83 (~vvuGuest8@149.28.63.55)
[17:26:12] <sam_> because otherwise loads of stuff breaks 
[17:26:23] *** Joins: anyone (~filler@a4.inai.de)
[17:26:25] <IntrnlCmplrErr> LDv=$LD" -v" if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1;then exit 0
[17:26:36] <IntrnlCmplrErr> relevant section 
[17:26:55] *** Quits: mcury (~mcury@user/mcury) (Quit: Leaving)
[17:27:42] <IntrnlCmplrErr> ah so it would also work since only needs something to match and not the entire version string
[17:27:44] *** Joins: Arsen (arsen@gentoo/developer/managarm.dev.Arsen)
[17:28:16] <tolto> what do you guys think about jiatan's edit of SECURITY.md to """simplify""" it?
[17:28:32] <tolto> i think he was trying to get potential reports of backdoors to the xz email early so he could mitigate it somehow
[17:28:37] <dostoyevsky2> q3k: also, e.g in https://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html the loops come from '*' -> call matchhere() recursively
[17:29:14] *** Quits: Guest4 (~Guest4@bras-base-qubcpq0339w-grc-22-76-69-185-67.dsl.bell.ca) (Ping timeout: 250 seconds)
[17:29:15] <anyone> tolto: that was already exploited; 82ecc538193b380a21622aea02b0ba078e7ade92 reeks of that
[17:29:19] <q3k> dostoyevsky2: that's not how the matcher is implemented in software
[17:29:41] <i860> ah, I read that Lasse has begun reverting stuff and is aware of the whole situation... that is good
[17:30:02] <nomadgeek> i860: yeah. was on holiday and randomly checked their email.
[17:30:04] <q3k> dostoyevsky2: it's a function which iterates over tables, one table entry is used to check whether a character should be handled or not, the other is a pair of shorts that decide whether to mutate table offsets or return a symbol id
[17:30:07] *** Joins: Guest11 (~Guest54@136.37.175.163)
[17:30:11] *** Quits: luccc (~lukas@ip-193-53-104-44.changeis.iunxi.net) (Quit: Leaving)
[17:30:28] <Manis> tolto, no. Larhzu already confirmed he was involved in it.
[17:30:37] <tolto> anyone: not sure what you mean
[17:30:43] <tolto> Manis: ohh ok
[17:30:50] <nomadgeek> Manis: involved in the malware? Where did you see that?
[17:30:58] *** Quits: ozel (~ozel@2a02:8071:886:560:c52b:3976:d600:16d4) (Ping timeout: 250 seconds)
[17:30:59] <i860> and I'm sure "Jia" hasn't logged back in here, no doubt recalled to CCP headquarters for a talking to
[17:31:08] <Manis> No involved in the simplification of SECURITY.md, nomadgeek .
[17:31:19] *** Joins: Revy (sid545230@user/revy)
[17:31:21] <nomadgeek> Manis: ah, thanks. Sorry for the confusion.
[17:31:39] <dostoyevsky2> jia@12339.gov.cn  
[17:32:13] <tolto> lol
[17:32:18] *** Joins: blank (~blank@2600:100b:b028:6002:288c:ab03:b111:e5af)
[17:32:18] *** Joins: Guest64 (~Guest77@2a00:20:c054:c63e:bf49:d4b9:ef42:200d)
[17:32:54] <Celelibi> "You've discovered our secret backdoor. Keep it a secret or we'll make your whole family disapear. -- This is a automated response, please do not reply."
[17:32:57] <i860> lol and I see the /whowas info was finally pasted into https://boehs.org/node/everything-i-know-about-the-xz-backdoor  meaning everyone can stop bitching and moaning about not having the IP
[17:33:05] <IntrnlCmplrErr> checking if the linker versions string has 
[17:33:06] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[17:33:14] <tolto> funny how he also allegedly pretended to be a person with an indian name, as well as a scandinavian name "Hans Jansen" loll
[17:33:23] <nomadgeek> I don't have any RE experience so I'm itching to hear from y'all that do; if the binary does anything else.
[17:33:36] <IntrnlCmplrErr> checking if the linker version string has "GNU ld" anywhere reminded me of this https://webaim.org/blog/user-agent-string-history/
[17:33:46] <i860> Those other accounts pushing for the Hans Jensen changes to be merged were also cleanly in on it - probably the same entity
[17:34:22] <i860> I even think the guy complaining on the xz-devel (I think) mailing list about lack of a maintainer was also a plant
[17:34:24] *** Parts: vvuGuest83 (~vvuGuest8@149.28.63.55) ()
[17:34:27] *** Joins: noone (~noone@178.255.168.249)
[17:34:33] *** Joins: Guest44 (~Guest86@dslb-094-216-251-046.094.216.pools.vodafone-ip.de)
[17:34:36] <i860> Complete and total social rigging
[17:34:46] <nomadgeek> i860: indeed. if not sockpuppets then coconspirators. 
[17:35:31] *** Joins: Guest28 (~Guest28@p200300f857310000b52623e5726dc438.dip0.t-ipconnect.de)
[17:35:53] *** Quits: Yogurt (~Yogurt@158.51.82.203) (Quit: My MacBook has gone to sleep. ZZZzzz…)
[17:35:59] <dostoyevsky2> q3k: That might go in the direction of a virtual machine, yes...  and if you can jump in the instruction table, then you also have loops...
[17:36:09] *** Quits: hannula (~hannula@mobile-access-6df047-139.dhcp.inet.fi) (Read error: Connection reset by peer)
[17:36:10] <q3k> there are no loops
[17:36:19] <q3k> i've explored all possible states of that thing
[17:36:27] *** Joins: hannula (~hannula@n5f2t9n42jeflwzmg4q-1.v6.elisa-mobile.fi)
[17:36:35] <q3k> my shitty python script would've hung if there were loops :P
[17:36:38] <nomadgeek> imo, one or more actors targeted a single maintainer that was struggling with maintaining their project and wanted a replacement. Picked a package that involved functions that are inherently complicated. Got their trust over several years, and worked their backdoor in over time. Sprang the trap.
[17:36:46] <Celelibi> q3k, Then it's just macro instructions.
[17:37:10] *** Quits: Guest64 (~Guest77@2a00:20:c054:c63e:bf49:d4b9:ef42:200d) (Quit: Client closed)
[17:37:31] <nomadgeek> Their code had bugs, that was problem 1. But they also tried too hard to get the update adopted; as if they had a deadline.
[17:37:39] <levitating> q3k: at which offset did you find that dfa?
[17:37:44] <tolto> nomadgeek: i'm thinking almost the same. although in my opinion they were just analyzing sshd and figuring out at which part of linking they could hook. and they marked xz as a good candidate *shrug*
[17:38:01] <dostoyevsky2> q3k: Well, just saying... it wouldn't be difficult to add loops... you have an instruction table and then registers or an accumulator... that's like a small cpu
[17:38:17] <nomadgeek> tolto: that's true. The package they selected had a lot of reasons it was the right choice. 
[17:38:17] <i860> "I did a nmap on that IP after that /whois, and the results were a bit strange with tons of ports seemingly open. The IP is from Singapore, but I’d assume either a proxy or a hosted site or similar" <-- heh, I do something similar myself just to mess with port scanners and anyone outside the US attempting to screw with specific ports (ssh,
[17:38:18] <i860> postfix, dovecot):
[17:38:18] <i860>   19M  825M tarpit     6    --  bond0  *       0.0.0.0/0            0.0.0.0/0            multiport dports  !25,53,80,123,443,1537,9749,14222,32768:65535
[17:38:19] <i860>  867K  121M tarpit     17   --  bond0  *       0.0.0.0/0            0.0.0.0/0            multiport dports  !25,53,80,123,443,1537,9749,14222,32768:65535
[17:38:19] <i860>  2721  163K tarpit-non-us  6    --  bond0  *       0.0.0.0/0            0.0.0.0/0            multiport dports 1537,9749,14222 -m geoip ! --source-country US
[17:38:26] *** Quits: noone (~noone@178.255.168.249) (Remote host closed the connection)
[17:38:28] <tolto> nomadgeek: yeah i'm guessing
[17:38:34] *** Joins: bjorn3 (~bjorn3@2a02-a45d-df1e-1-815b-701b-2f4e-ee9a.fixed6.kpn.net)
[17:38:43] <anyone> i860: but what's inside tarpit
[17:38:45] <q3k> levitating: in 5.6.0: https://social.hackerspace.pl/@q3k/112185642579530097
[17:38:55] <i860> anyone:
[17:38:55] <i860> Chain tarpit (4 references)
[17:38:56] <i860>  pkts bytes target     prot opt in     out     source               destination
[17:38:56] <i860>   19M  878M CHAOS      6    --  *      *       0.0.0.0/0            0.0.0.0/0            -j CHAOS --tarpit
[17:38:57] <laanwj2> nomadgeek ubuntu 24.04 release maybe
[17:39:01] <anyone> i860: very good :D
[17:39:19] <Celelibi> BTW, has there been an official statement from github about the locking of the whole project?
[17:39:32] <anyone> Locking the project *is* the statement
[17:39:38] <i860> it's basically fail2ban on top of all the tarpit stuff
[17:39:41] <tolto> someone really wanted to pwn SSH servers worldwide. and may have had a specific target they were interested in long-term
[17:39:43] *** Quits: blank (~blank@2600:100b:b028:6002:288c:ab03:b111:e5af) (Remote host closed the connection)
[17:39:45] <nomadgeek> laanwj2: yeah - but that's a little arbitrary in the end. If not that release, then the next one. It appears this was at least a 3-year long attack.. what's another release window of time.
[17:39:46] <tolto> that seems like a HUGE operation
[17:39:52] <q3k> levitating: in fedora 5.6.1 .so (which is what i mostly use): 0x00125d60 / 0x00025d60
[17:40:03] <dostoyevsky2> Celelibi: github probably is forbidden by law to host malware, so they switched it off
[17:40:11] *** Joins: NexAdn (~nex@user/nexadn)
[17:40:13] <nomadgeek> tolto: that's the answer. They had a target(s) they wanted to hit and they had a timeframe they needed it in.
[17:40:14] <levitating> q3k: awesome, thanks
[17:40:17] <f_[xmpp]> how is it going?
[17:40:35] <levitating> I marked bd_hash and bd_elf_lookup_hash in ghidra
[17:40:38] <Celelibi> dostoyevsky2, really? Even security researchers can't host example files and whatnot?
[17:40:55] <amdj> nomadgeek: they did have a deadline, in a way. feature freeze for ubuntu 24.04 was rapidly approaching at the time they made the 5.6.0 release.
[17:41:05] *** Joins: andibmu (~andi@dslb-094-216-251-046.094.216.pools.vodafone-ip.de)
[17:41:10] <laanwj2> yes, maybe they were doing this as part of some other large=scale operation and it needs to be coordinated, who's to say, it's clear their plans are dead in the water
[17:41:13] <dostoyevsky2> Celelibi: There used to be sites that hosted malware for security researchers but they have all gone private to my knowledge
[17:41:15] *** Parts: onlyJak0b (~onlyJak0b@p50865e95.dip0.t-ipconnect.de) ()
[17:41:23] *** Quits: ErrorNoInternet (~error@146.70.173.147) (Ping timeout: 260 seconds)
[17:41:30] <Celelibi> I would have liked some explanations as to why they did it (even though we have some idea) for how long, what's the recovery process and all that.
[17:41:38] *** Joins: arnvid (~arnvid@147.161.147.71)
[17:41:39] <nomadgeek> laanwj2: unless other such attempts were more successful. We're not sure at this point if that other shoe exists or not.
[17:41:42] *** Joins: onlyJak0b (~onlyJak0b@p50865e95.dip0.t-ipconnect.de)
[17:41:45] <q3k> levitating: https://gist.github.com/q3k/3fadc5ce7b8001d550cf553cfdc09752
[17:41:51] <levitating> awesome!
[17:41:59] <nomadgeek> Timing this attack with others may have been in the cards.
[17:42:05] *** Joins: curious1 (~curious1@d-69-161-122-134.nh.cpe.atlanticbb.net)
[17:42:09] <levitating> dostoyevsky2: you have vx underground
[17:42:11] <Guest37> I can't imagine how pissed they are that it was found so quickly, hahah
[17:42:30] <tolto> true, this may have been a part of a larger attack
[17:42:35] <tolto> just one backdoor vector out of many
[17:42:45] <nomadgeek> Guest37: by a random dev dude angry about some ms lag in their benchmark tests. XD
[17:43:03] <andreyv> Guest37: Probably switching focus to other "projects"
[17:43:13] <amdj> Guest37: earlier:
[17:43:15] <amdj> 2024-03-30 15:29:12 < plat0> >spend 2 years in deep cover only for you to get caught because you made someone's benchmark slower
[17:43:16] <amdj> 2024-03-30 15:29:15 < plat0> i'd just quit at that point
[17:43:16] *** Joins: ErrorNoInternet (~error@static-198-44-129-106.cust.tzulo.com)
[17:43:17] <tolto> it's probably worth checking other open-source projects if they have backdoors as well
[17:43:19] <Celelibi> nomadgeek, worth repeating: xD https://infosec.exchange/@mainframed767/112180749990584294
[17:43:40] *** Quits: ozars2 (~ozars@c-174-160-80-156.hsd1.ca.comcast.net) (Changing host)
[17:43:40] *** Joins: ozars2 (~ozars@user/ozars2)
[17:43:41] <Guest37> exactly :D
[17:43:44] <nomadgeek> Celelibi: 😆. That's basically what happened.
[17:43:55] <neko2> IntrnlCmplrErr: I just read the user agent thing you linked, I am stealing this
[17:43:56] <tolto> Celelibi: LOL
[17:44:05] *** anyone is now known as xcvb
[17:44:12] <emaste> We are very lucky they did not have better QA.
[17:44:34] <Celelibi> neko2, what user agent ?
[17:44:57] <IntrnlCmplrErr> neko2: unfortunately this is exactly what you get from not having an API to directly report your abilities
[17:45:25] *** Quits: JuukaSalami978 (~JuukaSala@45.153.183.199) (Quit: Connection closed)
[17:45:31] <tolto> now imagine the slowness would have never been noticed (or at least not noticed for a long time)
[17:45:38] <tolto> would there be any way to find out about this backdoor?
[17:45:41] <tolto> because it's pretty well-hidden
[17:45:53] <tk> yeah I mean eventually someone will have noticed a compromised machine and it probably would get out
[17:46:02] <nomadgeek> tolto: imagine if that dude had a cold or was really tired that day and couldn't be bothered to dig in further.
[17:46:03] <Apachez> tolto: which means that microbenchmarking IS a thing ;-)
[17:46:05] <tk> could have been quite a while
[17:46:05] <tolto> tk: that's the "bad" way to find out lol
[17:46:06] <amdj> the image is slightly inaccurate. it wasn't the slowness that was noticed; it was the excessive CPU time consumption for sshd doing nothing in response to being hammered by login attempts. that lead them to benchmark ssh logins.
[17:46:16] <tolto> nomadgeek: omg...
[17:46:30] <i860> maybe... but they'd have to figure out how it got compromised after the fact and it's possible whatever entity is behind this wasn't planning on using it in a widespread fashion but against specific targets
[17:46:32] *** Quits: Guest33 (~Guest33@2804:b34:301b:7a00::42a) (Quit: Client closed)
[17:46:40] <nomadgeek> we'd have figured it out eventually, sure. But after much more exposure/damage had occurred. 
[17:46:42] <tolto> amdj: i'm pretty sure the slowness was noticed first and THEN they measured CPU consumption
[17:46:52] <amdj> tolto: no. they clarified this in their mastodon post.
[17:46:52] <i860> they were going for the xz code in the kernel next.. which i think is pretty much super ballsy
[17:46:53] <Apachez> the time difference were 0.3 sec original and 0.8 sec with malware, while SSH takes 2-4 seconds if the client is missing a PTR-record
[17:46:55] <tolto> ohhhh
[17:46:58] <nomadgeek> tolto: that's my understanding too
[17:47:12] <amdj> https://mastodon.social/@AndresFreundTec/112180083704606941
[17:47:13] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[17:47:17] *** Joins: Guest49 (~Guest49@2a02:908:1c26:2a0:54b2:469d:c3c0:e64c)
[17:47:17] <emaste> tolto: there's also the valgrind issues and ifunc oss-fuzz
[17:47:17] *** Quits: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[17:47:24] <xcvb> tolto: there are enough slow CPUs in the world that it would have become significant to someone at some point
[17:47:24] <sam_> emaste: those are complicated
[17:47:27] <sam_> ifunc genuinely is brittle
[17:47:35] <sam_> even when everything is normal
[17:47:38] <i860> it's not _just_ the sshd cpu spinning btw
[17:47:39] <sam_> asan doesn't work there, pgo doesn't
[17:47:41] *** Quits: john_dee (~john_dee@165.76.243.129) (Quit: Connection closed)
[17:47:43] <tolto> yeah. with the fuzz thing they were probably trying to make sure the fuzzer can't find the backdoor
[17:47:47] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[17:47:52] <tolto> but how exactly? not sure. they changed the git repo to another URL
[17:47:56] <i860> he _also_ remembered some random valgrind noise he saw from some days prior to that and went looking
[17:47:57] <tolto> what would that do? no idea
[17:48:00] *** Joins: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi)
[17:48:07] <i860> just an insane level of chance coming together
[17:48:08] *** Quits: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[17:48:18] *** Quits: aljazs (~aljazs@BSN-77-224-3.static.siol.net) (Ping timeout: 250 seconds)
[17:48:42] <Celelibi> I have never found a malware, but I sometime spent days investigating "weird behaviors". I always found it very much worth it. Either there's a bug lurking (90% of the time) or I didn't really understood what was supposed to happen.
[17:48:49] <Celelibi> Either way, that's a plus.
[17:48:52] <i860> same
[17:48:57] *** Quits: Guest44 (~Guest86@dslb-094-216-251-046.094.216.pools.vodafone-ip.de) (Quit: Client closed)
[17:49:00] <sam_> yes
[17:49:04] <sam_> that's always been my take on such things
[17:49:06] <InPhase> i860: That's often how it goes.  I once found a rootkit installed when the colors broke in ls.
[17:49:25] <nomadgeek> Celelibi: I chase red herrings all the time. My experience is in network security tho - so that's where my attention is directed.
[17:49:30] <i860> 95% of the time you have a gut feeling "nah, something isn't right here" and spending days pursuing it usually reveals a very deep bug that wasn't previously found or was esoteric enough that you have to have the right conditions - but in almost all cases you learn alot
[17:49:35] <tk> i860: the kernel code would not have been payloaded (at least not with this payload) 
[17:49:37] <InPhase> If they hadn't broken ls colors by accident, I might never have found that one.
[17:49:41] <tolto> one day i found a malware (several years ago)
[17:49:41] *** Joins: Guest87 (~Guest87@2607:fea8:9565:8e00::c54)
[17:49:45] *** Joins: Sohom_Datta (uid465374@mediawiki/sohom-data)
[17:49:49] <tolto> an ad popped up on a webpage and it downloaded a JS file
[17:50:01] <emaste> tolto: they turned off ifunc for the fuzzer
[17:50:06] <tolto> it was very obfuscated. there was JS upon JS upon JS meant to work in the Windows JS interpreter
[17:50:30] <tolto> i spent several hours deobfuscating it. after i've done all this, it wanted to contact the C&C server
[17:50:46] <IntrnlCmplrErr> Command and Conquer?
[17:50:47] <tolto> i downloaded the payload. it was an EXE from what i remember. also obfuscated. but i never submitted it anywhere
[17:50:50] <tolto> Command and Control
[17:51:07] *** Joins: Zemtex (~Blackblue@tmo-122-206.customers.d1-online.com)
[17:51:11] <tolto> emaste: yeah i wonder what they thought this would achieve
[17:51:12] <xcvb> IntrnlCmplrErr: C&C is a curry eatery :-p
[17:51:14] <neko2> ah yes the windows JS interpreter, in "why does this even exist again"
[17:51:17] <dostoyevsky2> #xz-cnc
[17:51:19] <laanwj2> "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" looks interesting in that string table, it's 24 bytes base64 encoded (no idea what though)
[17:51:22] <nomadgeek> IntrnlCmplrErr: the server that the malware connects to in order to get commands.
[17:51:47] <amdj> laanwj2: it's not base64.
[17:51:54] <amdj> there are 16 characters preceding the =.
[17:52:04] <i860> my thinking is they knew exactly how they were going to go about using xz/lzma as a vector (as they have a map of every single library dependency for all major linux distros) and then worked backwards from there on how to sneak it in, how to probe vulnerable projects, etc... the entire thing from the sock puppets to the sudden interest in a new
[17:52:05] <i860> maintainer heroically appearing was completely planned and slowly executed
[17:52:05] *** Joins: Guest33 (~Guest33@2804:b34:301b:7a00::42a)
[17:52:18] <laanwj2> ok maybe wrong, i could decode it using python's base64.b64decode
[17:52:29] <amdj> base64 converts 3 bytes into 4 characters, and terminates with 1 or 2 = depending on if the length wasn't enough. 16 characters means a multiple of 3 bytes precedes it, so no = termination would be required.
[17:52:45] <tolto> "dude, come on, just make me the admin of the project. you're tired, right? it's about time someone else took over"
[17:52:54] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[17:52:57] <i860> there is no way in hell this is just one "wouldn't it be cool if I could hack this?" blackhat dude doing it as a one-off
[17:53:04] <tolto> fake sockpuppets: "yeah i agree 100%, you should listen to jia tan"
[17:53:09] <i860> tolto: heh, yep
[17:53:12] *** Quits: Bl3nd3r (~Bl3nd3r@185.107.56.47) (Quit: Bl3nd3r)
[17:53:16] <nomadgeek> tolto: mhmm
[17:53:32] <bjorn3> could the "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" be an env var that needs to be set?
[17:53:39] <InPhase> i860: Well that's the more concerning theory, because it surely means there's a lot more of it than noticed.
[17:53:41] <i860> including the people raging about some xz-specific changes they totally need integrated right now! just so random
[17:53:44] *** Quits: a7x (~a7x@user/a7x) (Ping timeout: 260 seconds)
[17:53:48] <sam_> i will say though
[17:53:55] <sam_> newer xz releases genuinely did have some cool new features
[17:53:56] <InPhase> i860: And by that I mean in other projects, and other identities.  :(
[17:54:00] <sam_> it is not implausible that people wanted to make use of them
[17:54:03] <sam_> we get this all the time in distros etc
[17:54:08] <sam_> "please bump to THING RELEASED AN HOUR AGO"
[17:54:14] <sam_> we even have a wiki page about it in gentoo
[17:54:15] <amdj> lmao
[17:54:21] <i860> InPhase: Yep, this is merely one that was caught. You don't catch everyone. State actors are likely sitting on dozens of unknown holes.
[17:54:23] <sam_> https://wiki.gentoo.org/wiki/Zero-day_bump_requests
[17:54:36] <sam_> which doesn't mean nothing nefarious happened here
[17:54:41] <sam_> i just mean there's a LOT of spotlight on things which also happen normally
[17:55:04] *** Quits: Riastradh (~riastradh@netbsd/board/riastradh) (Ping timeout: 255 seconds)
[17:55:08] <dostoyevsky2> sam_: why not compile a version of xz for every platform instead of adding ifuncs?
[17:55:11] <i860> what did xz do in newer releases that was notable btw? It looked like a compression library that was basically 98% feature-complete
[17:55:20] <i860> (other than lower level optimizations)
[17:55:26] <sam_> "other than <biggest thing it could do>"
[17:55:29] <neko2> I know this isn't exactly C&C, but seeing it mentioned made me think of how WannaCry was killswitched by a domain being registered.
[17:55:41] <nomadgeek> neko2: ah, the good old days.
[17:55:42] <sam_> it gained support for e.g. riscv filters (to make compression more optimal for riscv binaries) 
[17:55:49] <sam_> the decoder got faster in general too, like 30%
[17:55:55] <sam_> dostoyevsky2: not really sure what you mean here
[17:55:57] <ozars2> I'm sure somebody already asked this, but are there any serious regressions due to rolling back?
[17:55:59] <sam_> dostoyevsky2: i know what ifuncs do
[17:56:19] <andreyv> dostoyevsky2: Not practical in most distribution systems
[17:56:20] *** Joins: leonn (~leonn@2a01:4f9:2b:2c50:42:0:100:4)
[17:56:27] <Celelibi> Isn't it a bit frustrating when people don't see how old projects could still need non-trivial improvements? ^^
[17:56:33] <sam_> Celelibi: just a bit!
[17:56:46] <Celelibi> My C teacher once said "you can look at stdio.h, it's always fun to look at those very old files".
[17:56:54] <Celelibi> I was like: lolwut?
[17:56:56] <nomadgeek> ozars2: not that we know of back to 5.4.x. Most distros didn't even move to 5.6.x yet.
[17:56:56] <xcvb> "not practical" - meanwhile, we're seeing /usr/lib64/glibc-hwcaps/x86-64-v3/libz.so.1 getting practically introduced
[17:57:08] <andreyv> dostoyevsky2: You might look up "glibc hardware capabilities", though
[17:57:11] <sam_> ha
[17:57:14] <sam_> jinx :)
[17:57:17] <dostoyevsky2> sam_: Yeah, so you cpuid and then you disable/enable certain features during rutime... but why not just use -DSSE2 -DAVX512 etc during compilation...
[17:57:30] <sam_> right
[17:57:33] <sam_> i'm not saying that's wrong
[17:57:34] <ozars2> nomadgeek: thx
[17:57:41] <sam_> jia definitely pushed for ifunc 
[17:58:10] <i860> in general, the instruction set/arch-specific optimization problem needs to be solved and it needs to be solved in a way that isn't 10x the amount of binary blobs being installed and selected at runtime.. that's a hack
[17:58:11] *** Quits: linkfanel (linkfanel@82-64-25-168.subs.proxad.net) (Ping timeout: 268 seconds)
[17:58:18] <amdj> some distros are still on 5.2
[17:58:37] <xcvb> Andres Freund wrote about -Wl,-z,now and LD_BIND_NOT[LD_BIND_NOW]. The detail got lost in the grammar. If -z now the same as LD_BIND_NOW, then we're fine, no?
[17:58:38] <Celelibi> I'm not sure how I feel about ifunc. But I guess it's better than trying to patch the GOT manually. Which has always been a possibility.
[17:58:41] <fullstop> I can't imagine working on something like this, for years, just to have it squashed before it could bloom.
[17:58:46] *** Joins: alcx (~alcx@82.67.36.23)
[17:58:48] <nomadgeek> amdj: ozars2, this is right. many are still back of 5.2.x
[17:58:52] *** Joins: NoahvdAa (~NoahvdAa@user/noahvdaa)
[17:58:56] <sam_> xcvb: no
[17:59:00] *** Quits: Guest49 (~Guest49@2a02:908:1c26:2a0:54b2:469d:c3c0:e64c) (Quit: Client closed)
[17:59:02] <InPhase> amdj: 5.2.5 here, and momentarily glad for running on behind.
[17:59:02] <sam_> xcvb: LD_BIND_NOT is genuinely a thing too
[17:59:10] <IntrnlCmplrErr> supposedly Red Star OS 3 is still on a version of xz from 2010 :laughs:
[17:59:11] <sam_> not just a typo of NOW
[17:59:19] <xcvb> oof. talk about glibc design choices :-/
[17:59:21] <sam_> ikr!
[17:59:25] <sam_> (I had the same question)
[17:59:25] <Apachez> InPhase: security by legacy ;-)
[17:59:29] <amdj> brb implementing LD_BIND_NOZ
[17:59:37] <nomadgeek> Many of my services were running behind on 5.2 though I had 5.4 on a few.
[17:59:39] <sam_> I was convinced at first it was surely a typo 
[17:59:39] <InPhase> Apachez: And that's the way I like my Amiga!
[17:59:56] <Apachez> InPhase: same thing when heartbleed struck... two of my servers were so old so the original commit of heartbleed backdoor didnt exist in the openssl on these two servers =)
[17:59:59] <fullstop> Apachez: we had a few servers still using log4j, not log4j2
[18:00:16] <i860> time for my daily emerge:
[18:00:16] <i860> [ebuild     UD ] app-arch/xz-utils-5.4.2::gentoo [5.4.6-r1::gentoo] USE="extra-filters nls -doc -pgo -static-libs -verify-sig" 2734 KiB
[18:00:29] <Celelibi> How about LD_BIND_NOP, where the function resolver does exists, but is full of NOP. xD
[18:00:29] <sam_> yeah, out of caution we've gone down to 5.4.2, as the last release Lasse signed
[18:00:36] *** Joins: Guest41 (~Guest77@2a00:20:c054:c63e:bf49:d4b9:ef42:200d)
[18:00:39] <sam_> there is no specific reason otherwise
[18:00:42] <sam_> (i promise)
[18:00:43] <Manis> Sorry for the stupid question: what is the reason for going back to 5.4.2 from 5.4.6?
[18:00:43] * amdj eyes -verify-sig O_o
[18:00:53] <amdj> Manis: sam_ just said.
[18:00:54] <Manis> Ah sorry, just a bit too late
[18:00:57] <amdj> :)
[18:01:40] <Manis> Maybe now is a good point to ask: should I enable verify-sig?
[18:01:41] *** Quits: Guest41 (~Guest77@2a00:20:c054:c63e:bf49:d4b9:ef42:200d) (Client Quit)
[18:01:46] <sam_> sure
[18:01:48] <amdj> I do
[18:02:07] <tolto> so yeah guys, does anybody here have the xz 5.5.x beta tarballs that jiatan posted on github?
[18:02:12] <sam_> (enabling it by default is tricky because: a) not everyone agrees on its value, but maybe more importantly: b) it introduces a lot of circular deps)
[18:02:16] <sam_> (which would be a pain on ne winstalls, etc)
[18:02:23] <Manis> OK, will look into it. I noticed it becoming available but was always like "gonna check it out later".
[18:02:27] <sam_> tolto: I'm about to go digging for them to see if I have them lying around
[18:02:31] <tolto> alright
[18:02:44] <amdj> at the moment you're protected by the digests of the distfile as contained in the Manifest file in your ebuild tree 
[18:02:46] *** Quits: nomadgeek (~nomadgeek@047-134-024-163.res.spectrum.com) (Remote host closed the connection)
[18:02:54] <amdj> which in turn is signed by PGP if you're enabling verification of portage tree updates
[18:02:57] <Manis> Ah, so one should only enable verify-sig after having the system set up?
[18:03:09] <Manis> amdj, this I know.
[18:03:16] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[18:03:27] <Manis> So theoretically the package maintainer should have verified the signature of these distfiles already.
[18:03:28] <amdj> however this is no guarantee that a gentoo dev wasn't a bit sloppy in verifying the distfile they fetched was legitimate 
[18:03:28] <nomadgeek> Here's a useful snip to check your docker containers:
[18:03:30] <nomadgeek> docker ps -aq | xargs -I {} docker exec {} sh -c 'xz --version || echo "xz not found"' 2>/dev/null
[18:03:33] <InPhase> I wish we could get all the larger wealthier societies to recognize the importance of public funding for open source projects like this.  Like Heartbleed, this one appears to have happened because a project didn't get the amount of focused attention it needed, and the volunteers were left struggling.  This is the same root cause, even if the mechanism of how it got inserted appears to have been 
[18:03:39] <InPhase> differently motivated.
[18:03:49] <sam_> ffs
[18:03:54] <Apachez> plottwist once media (non tech) starts to write about this: First AI attack discovered!
[18:04:02] <sam_> amdj: github serves 200, but.. with HTML for the old assets
[18:04:07] *** Quits: ErrorNoInternet (~error@static-198-44-129-106.cust.tzulo.com) (Ping timeout: 252 seconds)
[18:04:09] <neko2> Apachez: slap them all into the sun aaaaaa
[18:04:21] <amdj> sam_: hahahaha.
[18:04:25] <FireFly> sam_: classic
[18:04:31] *** Quits: ultra980 (~ultra@2a02:2f0a:b308:4000:f565:881a:839:5e2a) (Ping timeout: 272 seconds)
[18:04:37] <Manis> InPhase, I don't think supporting FLOSS is a problem of society. It should be primarily a corporate tax for companies using it.
[18:04:48] <sam_> I was hoping we had a copy of some of the bad versions on our mirrors still
[18:04:54] <sam_> we don't have xz-5.5.2beta.tar.gz at least
[18:05:35] <Manis> sam_: you don't need 5.6.1 I think?
[18:05:55] <InPhase> Manis: It's not like it would cost that much either way.
[18:06:02] <dostoyevsky2> InPhase: Fun fact Ministry of State Security in China is one of the largest funder of OpenSource Software
[18:06:02] *** Joins: ErrorNoInternet (~error@23.162.40.16)
[18:06:03] <sam_> i have xz-5.2.9, xz-5.4.6, xz-5.6.0, xz-5.6.1 
[18:06:06] <sam_> i am hoping to get the others for comparison
[18:06:08] <nomadgeek> Seems like 5.6.0 is better to dig into because 5.6.1 has more obfuscation and missing symbols.
[18:06:09] <sam_> i should've grabbed them earlier :/
[18:06:11] <InPhase> dostoyevsky2: lol
[18:06:31] <sam_> on the upside I know the checksums for the ones I need
[18:06:45] <negril> sam_: xz-5.4.0.tar.gz  xz-5.4.2.tar.gz  xz-5.4.6.tar.gz  xz-5.6.0.tar.gz  xz-5.6.1.tar.gz
[18:06:51] <fullstop> nomadgeek: do you need the 5.6.0 / 5.6.1 tarballs?
[18:07:05] <oldfashionedcow> ironic, the xz tarballs use gzip
[18:07:09] <sam_> not ironic
[18:07:11] <sam_> deliberate for bootstrapping
[18:07:14] <oldfashionedcow> oh okay
[18:07:24] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Quit: Client closed)
[18:07:32] <nomadgeek> fullstop: I don't need them. I won't be helpful in RE. Thanks though.
[18:07:40] *** Quits: Zemtex (~Blackblue@tmo-122-206.customers.d1-online.com) (Read error: Connection reset by peer)
[18:07:44] <fullstop> roger
[18:07:59] <FireFly> should've grabbed the tarballs earlier too, ahwell
[18:08:05] <neko2> sam_: the thought occurs that you could concievably stick them in a git repo as one commit for each version. ... the irony being that would show the true change history, unlike the actual github repo which the release tarballs were distinct from.
[18:08:09] <ozars2> not the tarball perhaps but: https://salsa.debian.org/debian/xz-utils/-/tree/upstream/5.5.2beta
[18:08:25] <nomadgeek> Give me some code to review and I can pitch in there, but once it's compiled I don't have any experience there. 
[18:08:33] <neko2> well, the "true" change history for distros that pulled those tarballs.
[18:08:37] <Celelibi> I take xz doesn't have self-extracting archives. That would be awesome for both bootstraping and backdooring. :)
[18:08:43] <xcvb> sam_: I don't see gzip using .Z ;)
[18:08:51] <sam_> :p
[18:09:04] <amdj> oldfashionedcow: if the xz tarballs used xz, how would you build xz when you don't have xz ? :)
[18:09:04] <sam_> xcvb: (xz made several formats available and in gentoo we used .gz so that if people bricked xz-utils, they could re-install it fine)
[18:09:16] *** Quits: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net) (Quit: Client closed)
[18:09:17] <oldfashionedcow> amdj: security feature!
[18:09:21] <boud> Larhzu: excellent summary :)  https://tukaani.org/xz-backdoor/
[18:09:26] <FUZxxl> amdj: you can use minixzdec from ... somewhere ...
[18:09:48] <Celelibi> amdj, some projects are notoriously hard to bootstrap. Like flex and bison (the newer lex and yacc). They depend on each other.
[18:09:50] <xcvb> be wary of "somewhere ..". Then again, anywhere is the same
[18:10:02] <Noisytoot> gzip also has uncompressed tarballs for if you don't have gzip
[18:10:05] *** Joins: Guest49 (~Guest49@2a02:908:1c26:2a0:54b2:469d:c3c0:e64c)
[18:10:07] *** Joins: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi)
[18:11:01] *** Parts: myrmidon (~vortex@72.46.187.81.in-addr.arpa) ()
[18:11:06] *** Joins: Garen (Garen@50.52.127.145)
[18:11:10] <i860> i do use xz for syslog backups and i also use it at work for mysql backup dump compression... never had any significant issues with it and it's useful for controlling memory usage and thread usage via args
[18:11:25] <Noisytoot> actually it doesn't, I was looking at an old version (1.3.12 seems to be the last with uncompressed tarballs). the latest version has gzip, xz, and zip
[18:11:38] *** Joins: jaeg-er (~jaeg-er@44-174-190-90.dyn.estpak.ee)
[18:11:53] *** jaeg-er is now known as jiatan
[18:11:54] *** Quits: larry (~larry@2a02:810d:ae3f:ed2b:872c:56e4:cf90:3024) (Remote host closed the connection)
[18:12:15] <nomadgeek> 👀
[18:12:22] <Guest37> o.O
[18:12:23] *** jiatan is now known as Guest3756
[18:12:26] <sam_> its just someone trying to be funny
[18:13:12] <Guest3756> wtf, censoring nicks now? perhaps start banning, while youre at it?
[18:13:29] <Guest3756> not trying, it is funny.
[18:13:40] <Noisytoot> Guest3756: jiatan has GUARD set, it's a registered nick
[18:13:45] <Celelibi> It was funny the first billion times.
[18:13:52] <sam_> ^^
[18:13:53] <susi> I think it's still pretty funny
[18:14:00] <susi> but that's just my opinion
[18:14:10] *** Guest3756 is now known as real_jiatan
[18:14:11] <amdj> s/GUARD/ENFORCE/
[18:14:21] <oldfashionedcow> Let's not create any more headache for the (probably) stressed people working on this
[18:14:49] <Celelibi> Noisytoot, I guess if you need to bootstrap gzip you can download older version first.
[18:14:49] <xcvb> "Are those people with us right now?"
[18:14:50] *** Joins: KGB (KGB@irc.chroot.pl)
[18:15:12] <i860> "Guest3756 is now known as the_real_jiatan_i_lost_my_old_account_ama"
[18:15:35] <real_jiatan> actual jia surely would hang around uring anything resembling his own name... if it ever even was his real name.
[18:15:36] <Celelibi> Just like gcc. If you want to bootstrap it, you'll have several stages of compiler versions.
[18:15:55] <oldfashionedcow> Celelibi: how was the first compiler made?
[18:16:00] <oldfashionedcow> Ig written in assembly and then linked?
[18:16:08] <i860> the history of bootstrapping is actually pretty fascinating
[18:16:12] <amdj> magifying glass and pick axe
[18:16:13] <i860> read up on it sometime
[18:16:18] <Celelibi> oldfashionedcow, that's an old question any programmer has asked at some point. :)
[18:17:11] <Celelibi> oldfashionedcow, nowadays, the first compilers for a given arch cross compiled. The first one ever was likely written in assembly.
[18:17:29] <amdj> but no on a serious note computers used to use magnetic core memory and then setting 1s or 0s is as simple as (de)magnetising it. so you could write a program (including a compiler) with a magnet and a lot of patience. that could then compile a better version of itself. and so on
[18:17:45] <nomadgeek> i860: this is neat history
[18:17:46] <amdj> this is why it's still called a coredump to this day.
[18:17:50] <Celelibi> oldfashionedcow, could have been written in an interpreted language, the iterpreter itself written in assembly.
[18:17:53] *** Joins: Fingel (~Fingel@user/fingel)
[18:18:59] <Celelibi> amdj, hopefully perforated cards became a thing. :)
[18:19:16] <oldfashionedcow> Celelibi: interesting
[18:19:56] <k__> Even the whole story behind punch cards is interesting, bugs introduced because the person punching the cards couldn't read the handwriting of the programmer. :D
[18:19:57] <boud> q3k: nice work in extracting the payload: https://social.hackerspace.pl/@q3k/112184695043115759    @robryk seems to have found that it includes a password to disable the crack...
[18:20:01] <i860> if i remember correctly it was direct machine code via physical punch cards in order to bootstrap an assembler of some sort and then from there likely assembly and so on...
[18:20:15] <Celelibi> oldfashionedcow, I said assembly, but the details remain to be checked out. More likely directly in opcodes on perforated cards or something.
[18:20:20] <boud> s/@robryk/@zeno/
[18:20:27] *** Joins: FH_thecat (~FH_thecat@75.11.25.212.ftth.as8758.net)
[18:20:32] <Celelibi> There are likely many books and videos and articles about the beginning of computer programming.
[18:20:42] * oldfashionedcow googles
[18:21:00] <nomadgeek> https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
[18:21:01] <amdj> I'd be surprised if the process wasn't restarted between punch cards and magnetic core memory
[18:21:04] *** Joins: Guest6656 (~Guest6656@bras-base-wdbgon4804w-grc-08-76-71-100-208.dsl.bell.ca)
[18:21:13] <amdj> the latter was just so much faster
[18:21:17] *** Joins: ky12 (~ky12@2607:fea8:4f20:c300:89ce:c312:bb89:6bd)
[18:21:43] *** Joins: Riastradh (~riastradh@netbsd/board/riastradh)
[18:22:24] *** Joins: LjL (~ljl@user/ljl)
[18:23:27] <amdj> we owe a lot of our current naming of things to these wonderful legacies of computing
[18:23:38] <susi> btw, xz-rs when?
[18:23:47] <amdj> for example they're called bugs because the first recorded malfunction of a computer was a moth stuck in the contacts of a relay
[18:24:05] <amdj> they're still called segfaults (segmentation faults) even though we moved onto paging a long time ago
[18:24:06] <Manis> susi, this question had to come...
[18:24:08] <amdj> etc
[18:24:32] *** Quits: Guest6656 (~Guest6656@bras-base-wdbgon4804w-grc-08-76-71-100-208.dsl.bell.ca) (Remote host closed the connection)
[18:24:32] <dostoyevsky2> xzsshd
[18:24:33] *** Joins: TheAifam5 (~Thunderbi@user/TheAifam5)
[18:25:12] <boud> ... and line lengths in source code are still 72 characters - the ones after don't matter.
[18:25:18] *** Joins: Guest66 (~Guest66@2a01:e0a:467:a5e0:400d:4a22:9c73:abba)
[18:25:18] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[18:25:44] <boud> except for people who have moved beyond fortran77 ;)
[18:25:53] <amdj> lol
[18:26:04] <xcvb> boud: but printing something on paper pretty much *also* only fit 80-ish chars
[18:26:06] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[18:26:34] *** Joins: dravine (~dravine@user/dravine)
[18:26:37] <rx80> sam_: shouldn't all the xz versions still be available on gentoo source mirrors?
[18:26:42] <levitating> this is the most CTFy backdoor ever
[18:26:43] <amdj> I wonder what wrapping zimmermann used when he printed the PGP book
[18:26:47] <sam_> no, they get purged 30 days after the ebuild is removed from ::gentoo
[18:26:48] <Guest22> Have you guys seen that the long string found is apparently a killswitch for the exploit?
[18:26:50] <Baughn> neko2: I'm sorely disappointed that the timeline for pulling 5.6.1 from nixos is "ten days maybe". :/
[18:26:59] <JTL> why?
[18:27:04] <levitating> Guest22: yes, but there are many "killswitches"
[18:27:16] <rx80> sam_: days?
[18:27:42] <sam_> yes?
[18:27:46] <i860> amdj: to be fair, a page fault is something else entirely
[18:27:46] <Guest22> levitating what others?
[18:28:12] <levitating> having TERM set, having LANG not set, binary not being /usr/sbin/sshd
[18:28:23] <rx80> sam_: maybe i wasn't really clear :D you asked who has all the different versions of it, so my suggestion is: download them from gentoo source mirros
[18:28:28] <levitating> the backdoor only activates in a very specific environment
[18:28:39] <sam_> rx80: like I said, not there unfortunately, the ones I need are aged out 
[18:28:49] <sam_> but maybe on older mirrors 
[18:28:53] <sam_> there are some archives out there, I am looking
[18:29:01] <rx80> sam_: also archive.org?
[18:29:15] <oldfashionedcow> sam_: what specific version(s) are you looking for
[18:29:54] *** Quits: achtagon (~achtagon@2601:246:5c02:ea3:197e:b6cb:31a2:a9f9) (Quit: Client closed)
[18:30:01] <Raito_Bezarius> Baughn: why does it even matter?
[18:30:03] <rx80> sam_: sorry i didn't see your message earlier, i just cleaned my local cache XD had all the versions back to 5.2.5
[18:30:12] <sam_> bugger!!!!
[18:30:21] <oldfashionedcow> sam i might have those versions
[18:30:24] <oldfashionedcow> in my distfiles
[18:30:27] <rx80> yes!
[18:30:43] <Baughn> Raito_Bezarius: In this case it probably doesn't, though we don't know for sure. Problem is there's no mechanism to do it faster.
[18:30:51] <Raito_Bezarius> there's a mechanism to do it faster.
[18:31:04] <Raito_Bezarius> it's not a mechanism meant to be distributed to final users because it breaks referential transparency
[18:31:08] <oldfashionedcow> dammit i only have xz-5.4.2.tar.gz xz-5.4.2.tar.gz xz-5.6.1.tar.gz
[18:31:10] <oldfashionedcow> let me check my server
[18:31:14] <Raito_Bezarius> except for true disaster class vulnerabilities
[18:31:25] <oldfashionedcow> hmm just xz-5.6.0.tar.gz there
[18:31:35] *** Joins: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net)
[18:31:41] <Raito_Bezarius> but multiple folks have been utterly unable to detect any presence of the attack payload in the outputs so…
[18:31:59] <Raito_Bezarius> (doesn't say that we didn't miss or something or that the other reverse engineers didn't miss anything but)
[18:32:02] <DasBrain> haha https://pbs.twimg.com/media/GJ4HKkuWoAELpot?format=jpg&name=large
[18:32:13] <xcvb> boud: ISO A4 page is 210mm wide - or about 594pt. 8pt is a somewhat 'typical' size for print (and almost typical for computer screens, being 10.6px), and that's how you end up with 72 chars per line.
[18:32:22] *** Joins: dos (~dos@dosowisko.net)
[18:32:24] <Baughn> I'm concerned about what might be in the previous two years. But eh. Turned off my machines for now.
[18:32:56] <Raito_Bezarius> Not sure what do you mean "what might be in the previous two years"
[18:33:02] <Raito_Bezarius> Like the past 750 commits?
[18:33:11] <Baughn> Yes? That will take a while to go through.
[18:33:12] *** Joins: Guest53 (~Guest20@192.222.198.98)
[18:33:20] <Baughn> I don't think I'm saying anything new here.
[18:33:34] <Raito_Bezarius> Right, but, then that's the same problem for every distro
[18:33:48] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Remote host closed the connection)
[18:33:54] <Raito_Bezarius> The downgrade from 5.6.1 is not time sensitive in our case so please no FUD :).
[18:34:05] <Baughn> True. I'm most impressed by Debian's response here... which wouldn't stop me from still killing the power to my server if it were running debian.
[18:34:10] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[18:34:24] <InPhase> oldfashionedcow: The ubuntu pools have an xz-utils_5.2.4.orig.tar.xz
[18:34:49] <oldfashionedcow> hmmm
[18:34:53] <Raito_Bezarius> I had no doubt that every folk working in distro are brillant folks and know how to do the right incident response and I'm very happy to be part of that community :)
[18:34:53] <oldfashionedcow> I am searching my snapshots
[18:34:57] <oldfashionedcow> to find all versions I have
[18:35:07] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[18:35:09] <Baughn> Raito_Bezarius: So part of the reason I'm extra worried is I was examining some unusual SSH traffic patterns to my desktop computer on Friday.
[18:35:15] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[18:35:21] <Baughn> I have no reason to think that was related, but the timing is... mm'kay.
[18:35:23] <negril> xz-5.5.1alpha.tar.gz xz-5.5.2beta.tar.gz are the two versions missing
[18:35:24] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[18:35:25] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[18:35:33] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[18:35:37] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[18:35:39] *** Joins: Vir0 (~irc@falcon.ctdx.de)
[18:35:46] <InPhase> oldfashionedcow: I don't know for sure if what ubuntu is stashing 1:1 matches with the release tarballs you're looking for though.  But I think that's what the "orig" label is supposed to mean.
[18:36:00] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[18:36:04] <Baughn> (I *think* it was actually a misconfigured backup! Can't finish that debug session right now.)
[18:36:05] <oldfashionedcow> tw
[18:36:08] <Raito_Bezarius> Baughn: IPv4 scanning and SSH bruteforcing is quite classical on Internet, consider using something like Greynoise to verify the reputation of an IP :)
[18:36:09] <i860> baughn: they'd have to somehow know your box was vulnerable and even the mere presence of anything phoning home would light up 100s of threat monitors
[18:36:12] <oldfashionedcow> i860: I'm on gentoo here
[18:36:15] <oldfashionedcow> oops InPhase ^
[18:36:32] <Baughn> i860: It was lighting up my threat monitors, yes, that's how I found out.
[18:36:40] <Guest22> levitating oh, yeah but I don’t consider those killswitches, but conditions - the killswitch seemed like a way for them in case of huge spread of this back door, to disable it on systems they own/manage themselves
[18:36:54] *** Joins: Guest7 (~Guest53@95.165.170.131)
[18:36:58] <InPhase> oldfashionedcow: Yeah, but by pools I mean the files you can just download.
[18:37:09] <oldfashionedcow> ahh
[18:37:11] <Baughn> Raito_Bezarius: Will take a look. Though FWIW this was actually successful logins.
[18:37:16] *** Quits: Guest20 (~Guest20@192.222.198.98) (Ping timeout: 250 seconds)
[18:37:22] *** Joins: Guest96 (~Guest96@194-218-34-180.customer.telia.com)
[18:37:33] *** Quits: Guest96 (~Guest96@194-218-34-180.customer.telia.com) (Client Quit)
[18:37:35] <boud> The earliest commit by Jia Tan looks like aa75c556 Fri Jun 10 21:35:18 2022 +0800 "Tests: Created tests for hardware functions."
[18:37:36] <rx80> sam_: there also exist some mirrors with really stale data: https://mirrorstats.gentoo.org/releases/
[18:37:56] <tolto> check this out https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
[18:38:23] <Raito_Bezarius> Baughn: *shrugs* at some point, if this is critical infrastructure, you can just conduct all the forensic work and examine everything properly, if it's not, everyone is in the same boat
[18:38:38] <Baughn> I'll go back to that. :p
[18:38:39] <tolto> oh nvm. already been posted
[18:38:53] <boud> Unfortunately (for portability) that's before the RHEL/CentOS7 "ill patch" was tidied up by Lasse.
[18:38:53] *** Quits: Guest17567 (~Guest1756@23.94.74.107) (Quit: Client closed)
[18:38:56] <Raito_Bezarius> but the latest xz backdoor does not affect NixOS, so you cannot have this RCE thingie, though other things could exist
[18:39:15] *** Joins: Guestasldfjalshg (~Guestasld@104.36.71.200.16clouds.com)
[18:39:31] *** Joins: Guest20 (~Guest20@192.222.198.98)
[18:39:52] <neko2> Baughn: ooooof. was that on the same PR discussion as your fun week quote
[18:39:58] <neko2> also, I confess I figured as such
[18:40:14] <q3k> https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b
[18:40:18] *** Quits: Guest53 (~Guest20@192.222.198.98) (Ping timeout: 250 seconds)
[18:40:30] <neko2> I was doing the mental math on the latency of it being merged into the other branches and then the rebuild happening
[18:40:51] <Baughn> neko2: I do try to stress that I have a much lower threshold for panicking about most people. A lot of that is because I don't _need_ the server running; it's an NAS, minecraft and random stuff server.
[18:41:00] <Baughn> *about stuff like this than most people
[18:41:07] <Raito_Bezarius> system.replaceRuntimeDependencies exist if you are critical infra
[18:41:40] <neko2> Baughn: meanwhile I had my entire system running off of *nixpkgs* as an incremental conversion, so the suggested nixos specific mitigations would not have worked for me.
[18:41:47] <neko2> well, almost
[18:42:04] <neko2> a tiny core of arch linux remained that was handling anything superuser, ssh included
[18:42:31] <tolto> > The payload is extracted from the N value (the public key) passed to RSA_public_decrypt, checked against a simple fingerprint, and decrypted with a fixed ChaCha20 key before the Ed448 signature verification.
[18:42:33] <tolto> ohh, that's clever
[18:42:34] <Baughn> Ouch. Though that should be unaffected as well, right?
[18:42:43] <tolto> so the main payload isn't even in the .o
[18:42:47] <tolto> there are more stages of the malware! :o
[18:43:11] <nomadgeek> tolto: yeah. looks like the .o is just a way to get RCE
[18:43:14] *** Joins: wehttam (~wehttam@1.146.120.30)
[18:43:30] <tolto> someone should make honeypots
[18:43:46] <Manis> If the RCE is the public key this means the payload must be fairly small, right?
[18:43:47] <tolto> which catch jiatan SSH attempts and capture the payloads. unless they abandoned this project
[18:44:00] *** Joins: BatmanAoD (~BatmanAoD@38.15.54.201)
[18:44:15] <tolto> after this has been publicised, i'm not sure if the original actors will try to make use of it anymore
[18:44:16] *** Joins: UltraBloxX (~UltraBlox@95.165.170.131)
[18:44:22] *** Joins: rawtaz (~rawtaz@user/rawtaz)
[18:44:24] <kevans> too risky
[18:44:27] *** Quits: BatmanAoD (~BatmanAoD@38.15.54.201) (Client Quit)
[18:44:28] <Raito_Bezarius> tolto: have you read the tweet you posted though?
[18:44:37] <tolto> Raito_Bezarius: not fully, still reading
[18:44:37] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[18:44:38] *** Joins: BatmanAoD (~BatmanAoD@38.15.54.201)
[18:44:41] <Raito_Bezarius> ok
[18:44:41] <tolto> kevans: yeah that's what i'm thinking
[18:44:43] <nomadgeek> Yeah. They've burned all their stuff by now. 
[18:45:37] *** Quits: BatmanAoD (~BatmanAoD@38.15.54.201) (Client Quit)
[18:46:20] <neko2> Baughn: given that we don't know everything it does for sure yet, I wasn't content to let the piece of malware even be accessible in the address space of any process in my system using liblzma whatsoever. I was able to perform a (perhaps overly paranoid) complete reversion back to arch, which wasn't a total waste of a fire drill in any case.
[18:46:21] *** Quits: Guest71 (~Guest71@83.139.24.99) (Quit: Client closed)
[18:47:02] <Noisytoot> software heritage archive has 5.0.0, 5.2.5, and 5.2.8 tarballs
[18:47:14] *** Quits: Speedy11CZ (~Speedy11C@2001-1ae9-158-5400-4008-30be-db44-7d4d.ip6.tmcz.cz) (Ping timeout: 250 seconds)
[18:47:25] *** Joins: Narrat (~omnius@p200300df5f132b0306ea56fffe2e7cdc.dip0.t-ipconnect.de)
[18:47:31] <Baughn> neko2: I switched my desktop to windows and turned off the server. I'm not sure I can deal with running a non-nixos system though, so I'll just deal with not having working linux right now.
[18:47:42] <kevans> i think a honeypot would still be an interesting exercise, though; it'd be wild if this turned out to be someone's crappy research project and they probe for impact anyways despite the wide discovery notice
[18:48:11] <Manis> lol, wouldn't be the first time.
[18:48:23] <nomadgeek> kevans: it probably couldn't hurt? Maybe the ISC will add it to their honeypots.
[18:48:31] <Baughn> Thinking of the linux kernel thing? That was vastly lower sophistication though.
[18:48:31] <aesthetics> over that long of a timespan ? that'd be some dedicated researcher
[18:48:48] <Manis> Maybe the malicious part only came later.
[18:48:50] <neko2> Baughn: in my case I had the mercy that because my nix expression was a list of packages, the whiplash move was mostly just a case of editing the file to turn it into a list of packages, translating names manually as needed, then feeding it to pacman. 1.8GB of downloads and nervous waiting for something to break later...
[18:48:58] *** Quits: Guest7 (~Guest53@95.165.170.131) (Ping timeout: 250 seconds)
[18:49:06] <tolto> > Unfortunately, this means that unless a bug is found, we can't write a reliable/reusable over-the-network scanner.
[18:49:10] *** Joins: Shinzon98 (~Shinzon@user/Shinzon)
[18:49:13] <tolto> how is this so, though?
[18:49:23] <tolto> you can simply try to exploit the system via the backdoor
[18:49:29] <Raito_Bezarius> neko2: just fyi, there was none of the code in the address space on NixOS but YMMV
[18:49:29] <jess> that's a crime surely
[18:49:29] <Baughn> neko2: Arguably you should flatten and reinstall, w/o keeping anything binary. Arguably we are being paranoid.
[18:49:30] <tolto> if it fails, that means it's most likely not vulnerable
[18:49:31] *** Quits: Nick111 (~Nick111@144.202.173.133) (Quit: Client closed)
[18:49:36] <kevans> two, three years is nothing for a research project like this
[18:49:38] <laanwj2> the problem is that you need to sign the payload to make it do *anything*
[18:49:48] <aesthetics> tolto: doesn't it require a specific key ?
[18:49:50] *** Quits: Guestasldfjalshg (~Guestasld@104.36.71.200.16clouds.com) (Ping timeout: 250 seconds)
[18:49:53] <aesthetics> to trigger, i mean
[18:49:55] <nomadgeek> tolto: you need to sign the payload with the PK that we don't have.
[18:49:55] <tolto> aesthetics: ohh that's true...
[18:50:00] *** Quits: Vir0 (~irc@falcon.ctdx.de) (Quit: Leaving)
[18:50:02] <tolto> yeah, indeed
[18:50:14] <nomadgeek> I believe they found a public key in the binary.
[18:50:19] <i860> the parties that be are likely actively working multiple angles here completely outside of xz
[18:50:24] *** Joins: eamanu (sid462779@id-462779.tinside.irccloud.com)
[18:50:45] *** Shinzon98 is now known as Shinzon
[18:50:55] <tolto> jiatans thought of everything. even making sure that others can't exploit the systems, only they can LOL
[18:51:16] *** Quits: Shinzon (~Shinzon@user/Shinzon) (Quit: leaving)
[18:51:20] <neko2> Raito_Bezarius: again I wasn't running nixos (yet??). my arch install has piled on a ton of scripts etc over years. nixpkgs was helping me reduce the "core" install size so I could more easily track everything down. so I was stuck in the unique situation of plain nixpkgs providing almost all software in my system... and then this happens
[18:51:27] <nomadgeek> If you fail the signature it forwards the request to libcrypto as normal.
[18:51:41] *** Joins: Shinzon (~Shinzon@user/Shinzon)
[18:51:42] <ryzenda> over 24 hours now https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006224#gistcomment-5006224 "which we still can't reverse after 16 hours past the incident."
[18:51:47] <Raito_Bezarius> neko2: i fail to understand what you are saying then
[18:51:56] <laanwj2> yes, it seems super carefully planned, clearly this isn't your average cyber crook
[18:52:03] <neko2> Raito_Bezarius: it means, none of the nixos suggested mitigations would operate on my system
[18:52:07] <aesthetics> i still have issue imagining that "single dot" line isn't just something left there to be found; for what purpose i'm not sure... perhaps just "hey look at this obvious thing that you'll fix and feel safe about" or something else
[18:52:10] *** Quits: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net) (Quit: Client closed)
[18:52:14] <Raito_Bezarius> neko2: i still fail to understand what that means
[18:52:24] <Paistin> so has anyone thought of compiling a vulnerable SSH with the package as a honeypot?
[18:52:27] <Raito_Bezarius> the nixos suggestion mitigated for nixpkgs-built software is "do nothing" :)
[18:52:45] <Paistin> that way you can just wait for the specific key and capture it
[18:52:47] <levitating> Paistin: almost no true bxoes are vulnerable
[18:52:48] <Raito_Bezarius> because nixpkgs-built software with vulnerable xz is not vulnerable because the build script fails in the nixpkgs build environment
[18:52:52] <tolto> > It's RCE, not auth bypass, and gated/unreplayable.
[18:52:53] <laanwj2> the choice to use Curve448 for the auth is interesting, kinda overkill
[18:52:58] <levitating> but I like the idea
[18:53:05] <tolto> i guess this means on exploitation success you still wouldn't log in to the server
[18:53:05] <nomadgeek> Paistin: you wouldn't capture the private key, only the signature.
[18:53:17] <tolto> it would say "wrong password/key", but still execute your shellcode
[18:53:23] <Paistin> holysmoke
[18:53:24] *** Joins: wehttam (~wehttam@1.146.120.30)
[18:53:25] <neko2> Raito_Bezarius: ... including on hydra?
[18:53:35] <Raito_Bezarius> neko2: well, yes?
[18:53:43] <Raito_Bezarius> i don't understand what is your mental model tbh
[18:53:44] *** Quits: Guest66 (~Guest66@2a01:e0a:467:a5e0:400d:4a22:9c73:abba) (Ping timeout: 250 seconds)
[18:53:46] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Quit: peace)
[18:53:58] <tolto> <Paistin> that way you can just wait for the specific key and capture it
[18:54:03] <Raito_Bezarius> the vulnerable xz source code does not build vulnerable xz binary artifacts
[18:54:04] <tolto> i guess you don't even need vulnerable SSH for that
[18:54:10] <tolto> just a way to capture payloads sent over SSH
[18:54:20] <ryzenda> > "I'd like a security audition on all my contribution but I'd prefer someone to pay me some real money if they turn out clean, like I've commented in the PR." 
[18:55:01] *** Joins: Guest89 (~Guest89@2a02:8071:a582:c9c0:1e98:ecff:fe0e:21f1)
[18:55:13] <neko2> Raito_Bezarius: nixpkgs not affected you say. that include -unstable by any chance, that is all news to me
[18:55:31] <Paistin> tolto: i'm confusing with capturing passwords, thats something you can do yaeh
[18:55:37] <f_[xmpp]> What have I missed?
[18:55:49] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Quit: Client closed)
[18:55:50] <tolto> f_[xmpp]: probably this https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
[18:56:17] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[18:56:40] <Guest89> So,  you guys aim for an immediate removal of xz from all projects using it? :D
[18:56:40] <Guest89> Proactively adding backdoors is not a nice thing
[18:56:41] <nomadgeek> Paistin: it sounds like the exploit added requires the payload to be signed by a private key. It verifies that using a public key it already has. There isn't a password.
[18:56:57] <nomadgeek> So nothing to capture that's worth anything.
[18:57:04] <Paistin> this is well planned.
[18:57:12] *** Joins: Guest21 (~Guest21@pool-72-87-118-229.prvdri.fios.verizon.net)
[18:58:00] <laanwj2> it would still be interesting to catch it used in the act to see what they're trying to do, but yes, it doesn't help crack the private key
[18:58:01] <negril> Guest89: why would someone do that?
[18:58:02] *** Parts: Nyx (~Ny@skryth.com) (WeeChat 4.1.2)
[18:58:03] *** Joins: Guestasldfjalshg (~Guestasld@104.36.71.200.16clouds.com)
[18:58:08] <f_[xmpp]> tolto: woah that's nasty
[18:58:10] <ryzenda> +1 agree "your time is better spent digging through associated commits and identities to try and find other suspicious contributions to this or related projects, and get them fixed."
[18:58:13] <tolto> yep
[18:58:28] <i860> There's zero reason to stop using xz. To think that this entity would've somehow retroactively compromised versions of the software that they weren't even involved with is completely irrational. I wish people would stop it with this knee-jerkery
[18:58:50] <Guest89> Who was the maintainer adding these commits to the repo?
[18:58:50] <Guest89> The repo is unfortunately (or fortunately) already takern down by github..
[18:58:51] <Guest89> Some blame on the committer would be nice anyway
[18:58:52] <aesthetics> on vulnerable systems, would it defuse the backdoor to disable pubkey auth ?
[18:58:57] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[18:58:58] <negril> Guest89: sod off?
[18:59:00] <tolto> is it possible that jiatan might have rebased some old commits with vulnerable code?
[18:59:37] <Baughn> That would be far easier to notice. Anyone who does a `git pull` would see the mismatch.
[18:59:44] <i860> everyone, including every single fork, would notice that
[18:59:45] <tolto> hmm
[18:59:50] <tolto> ok
[18:59:56] <nomadgeek> tolto: maybe, but that would probably have stuck out like a sore thumb.
[19:00:01] <i860> that's the entire point of why git does its hashing how it does
[19:00:03] <tolto> got it
[19:00:13] <Baughn> It would be *dumb*, and the blackhats here don't strike me as dumb.
[19:00:26] <sam_> tolto: not an unreasonable question, anyway.
[19:00:33] <sam_> just fortunately git makes this hard to do
[19:00:39] <i860> and it's also why people casually using --force all the time shouldn't be
[19:00:43] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Client Quit)
[19:00:44] <f_[xmpp]> > The repo is unfortunately (or fortunately) already takern down by github..
[19:00:44] <f_[xmpp]> https://git.tukaani.org/
[19:00:47] <sam_> i860: yep
[19:00:54] <sam_> i860: I never do it on anything public at all
[19:00:57] <sam_> i860: just revert my mistakes
[19:01:00] <Baughn> They should at least use --force-with-lease. ;-)
[19:01:11] *** Joins: zekica (~zekica@178-220-122-192.static.isp.telekom.rs)
[19:01:22] *** Joins: devesh (~devesh@218.185.248.66)
[19:01:25] <i860> and anyone doing it to a public branches, especially that others have pulled from, should be beaten with a stick for 24 hours straight unless they have a very good reason (btw: i still see it!)
[19:01:27] <Noisytoot> why did github take down the repo? the backdoor was only in the tarballs
[19:01:30] <sam_> i see it a lot
[19:01:34] <negril> Noisytoot: it was not
[19:01:47] <negril>  The two compromised test files contained the main payload
[19:02:02] <Noisytoot> but they weren't actually used
[19:02:06] <negril> And the release assets were in there as well
[19:02:11] <negril> They were
[19:02:13] <devesh> can someone send a summary 
[19:02:17] <selckin> because otherwise you'd all be yelling why hasn't github done anything
[19:02:19] *** Joins: rigid (~rigid@user/rigid)
[19:02:24] *** Joins: Guest81 (~Guest41@ppp-83-171-165-233.dynamic.mnet-online.de)
[19:02:26] <tolto> Tests: Update two test files.
[19:02:26] <tolto> The original files were generated with random local to my machine.
[19:02:26] <tolto> To better reproduce these files in the future, a constant seed was used
[19:02:26] <tolto> to recreate these files.
[19:02:27] <tolto> LOL
[19:02:31] *** Quits: ecco_indalo (~Thunderbi@85-23-76-3.bb.dnainternet.fi) (Quit: ecco_indalo)
[19:02:32] <sam_> you know
[19:02:34] <tolto> that sounds realistic
[19:02:37] <tolto> he isn't dumb
[19:02:38] <sam_> i probably shouldn't say it but 
[19:02:40] <nomadgeek> Nah. I think the dev/OSS community would have liked to see the github stay up in a readonly state.
[19:02:42] <sam_> when i read that, i remember thinking
[19:02:44] <f_[xmpp]> GitHub momeny..
[19:02:45] <sam_> "i should ask which command it was for future"
[19:02:48] <f_[xmpp]> *moment
[19:02:50] *** Quits: Guest32 (~Guest43@171.6.144.51) (Ping timeout: 250 seconds)
[19:02:54] <negril> sam_: smh my head
[19:02:54] *** Joins: a7x (~a7x@user/a7x)
[19:02:57] *** Joins: mmap (mmap@ip117.net198.grossman.com)
[19:02:57] <sam_> I know 
[19:02:59] <neko2> Noisytoot: the real reason why is because they Made It So because of ToS violations. nothing too deep to be gleaned there.
[19:03:13] <Raito_Bezarius> neko2: this is exactly what was written in https://discourse.nixos.org/t/cve-2024-3094-malicious-code-in-xz-5-6-0-and-5-6-1-tarballs/42405
[19:03:23] <Raito_Bezarius> > NixOS Unstable currently ships with xz 5.6.1, but the malicious code path exits early, and liblzma remains unpatched.
[19:03:25] *** Joins: beber_ (~beber_@2a05:d018:c28:1a00:fd:d0ae:0:5222)
[19:03:30] <nomadgeek> The OSS community was busy analyzing their commits when it was taken offline
[19:03:31] <neko2> (and naturally github are final deciders of what is or isn't a ToS violation on their own platform)
[19:03:32] <tolto> sam_: are you referring to the text i posted?
[19:03:33] <Raito_Bezarius> the workaround / "mitigation" is "none"
[19:03:34] <ryzenda> "'burned out maintainers' is how you pull off attacks like this" and Facebook's 2012 research study for a week testing manipulating human emotions, and that 2019 Cambridge Analytica data scandal shown in the film The Great Hack, certainly the ability to algorithmically a.i.ly find real-time vulnerable persons and target them is automatable
[19:03:37] <sam_> tolto: yes
[19:03:39] <Guest89> github absolutely did the right thing.  if something like this is able to slip in, the repository or the maintenance of it is fundamentally broken and insecure.
[19:03:39] <Guest89> not project should be using such projects.
[19:03:50] <sam_> tolto: (note that I'm not a maintainer of xz-utils, just a contributor)
[19:03:51] <tolto> ohh. that means you have realized something was suspicious
[19:03:58] <sam_> it is actually a pet peeve of mine in general
[19:04:04] <sam_> when people do big generated commits
[19:04:05] <negril> Noisytoot: bad-3-corrupt_lzma2.xz contains script 1 good-large_compressed.lzma contains script 2 and the binary
[19:04:08] <sam_> i like to ask them to include the how
[19:04:14] <tolto> yes, indeed lol
[19:04:16] <sam_> not just for security but in case i have to do it myself in future, etc
[19:04:40] <Celelibi> I'd love that volunteers working on opensource projects be compensated appropriately. Especially those low in the dependency tower: https://xkcd.com/2347/
[19:04:43] <Baughn> Better yet, commit the code that generates it instead?
[19:04:46] <sam_> inded
[19:04:47] <sam_> indeed
[19:04:54] <Noisytoot> negril: m4/build-to-host.m4 is not present in the repo
[19:04:55] <sam_> Raito_Bezarius: I think betting on that is not wise, really
[19:05:04] <Raito_Bezarius> sam_: we are not betting on it though
[19:05:05] <ryzenda> example a.i query "A.I, please [with a cherry on top], give me a list of the most vulnerable and most active and essential source code developers on Github in th elast 30 days"
[19:05:15] *** Quits: grmll (~grmll@2001:9e8:aad5:4601:6257:18ff:fe8b:c491) (Remote host closed the connection)
[19:05:18] <Baughn> Celelibi: https://usercontent.irccloud-cdn.com/file/oTTVbhyw/1000002717.png
[19:05:21] <negril> Noisytoot: yes, that is the only thing that is not because it would have been to obvious
[19:05:27] <sam_> Raito_Bezarius: how so?
[19:05:41] <neko2> Celelibi: that xkcd is going to get a lot of reposts in the coming days
[19:05:55] <Raito_Bezarius> sam_: there's two things at the same time, the build script patching something and running that backdoor and all the past 2 years of contributions
[19:06:02] <Celelibi> neko2, I was just using it to illutrate the tower of dependency.
[19:06:16] <sam_> Raito_Bezarius: yes, I'm talking about the first, combined with https://marc.info/?l=oss-security&m=171180346116384&w=2 and https://marc.info/?l=oss-security&m=171180362016470&w=2
[19:06:17] <negril> Noisytoot: bad-3-corrupt_lzma2.xz has a intentionally garbage stream 2 that contains the payload and good-large_compressed.lzma is never used (that's suspicious)
[19:06:26] <sam_> Raito_Bezarius: which suggests it's possible there's a second script which may be used in some cases
[19:06:33] <sam_> Raito_Bezarius: which is what i mean by betting unless someone actually analyses that too
[19:06:43] <sam_> i think you should really just eat the rebuilds
[19:06:52] <sam_> it's not about doing it out of fear
[19:06:52] <Raito_Bezarius> sam_: we are eating the rebuilds
[19:06:57] <sam_> oh ok
[19:07:02] <Celelibi> ryzenda, BTW, I've heared many years ago of some perl code that found out important perl modules based on dependency and number of downloads.
[19:07:04] <tolto> negril: oh wow, that's clever too. basically "bad" could mean bad for testing and bad as in malicious
[19:07:11] *** Quits: Guest4197 (~Guest41@p54b6fe4f.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
[19:07:14] <Raito_Bezarius> sam_: but we confirmed that the backdoor is not doing anything
[19:07:15] <tolto> while "good" cannot be bad for testing, that's why it's omitted from testing at all
[19:07:15] <sam_> sorry, I only skimmed the thread and got the wrong impression then
[19:07:16] <negril> No the second script is to avoid having to change the testfile further
[19:07:19] <Raito_Bezarius> sam_: no worries
[19:07:37] <Raito_Bezarius> we did two things (a) launching the rebuilds ASAP (probably will take 3 days if everything goes well)
[19:07:38] <negril> or rather the two script entry points in the main setup
[19:07:38] <tolto> intentionally "bad" (corrupted) for testing purposes*
[19:07:49] <sam_> negril: my point was more that I wouldn't be surprised if there's a bit more left 
[19:07:54] <sam_> negril: the analysis is not very advanced yet
[19:07:57] <Raito_Bezarius> (b) setting up harness to trigger the SSH backdoor with no avail
[19:08:04] <Raito_Bezarius> (even by manipulating the env, etc.)
[19:08:05] <sam_> it didn't sound prima facie impossible or anything
[19:08:08] *** Joins: rurapenthe (~rurapenth@102.132.133.163)
[19:08:16] <Raito_Bezarius> also, sshd on NixOS is not linked to liblzma
[19:08:17] <tolto> <negril> No the second script is to avoid having to change the testfile further
[19:08:18] <tolto> how does this work?
[19:08:43] *** Quits: Guest49 (~Guest49@2a02:908:1c26:2a0:54b2:469d:c3c0:e64c) (Quit: Client closed)
[19:08:46] <Apachez> looks like this backdoor now have both a name and a logotype ;-)  https://twitter.com/cthulhu_answers/status/1773872056784109906?s=46
[19:08:46] <Raito_Bezarius> this doesn't say that we are completely safe but this give strong bounds on this is a situation to monitor carefully but no panic is required
[19:08:52] <sam_> yeah
[19:08:57] <tolto> are you saying he put in a mechanism to update the payload without committing to git again?
[19:09:03] <negril> The code greps for a marker in $srcdir/tests/ and then extracts filename and offset for start and end and evals that
[19:09:13] *** Quits: devesh (~devesh@218.185.248.66) (Quit: Leaving)
[19:09:15] <tolto> ohh ok, thanks for explaining
[19:09:15] <negril> two markers actually
[19:09:23] <Raito_Bezarius> sam_: thanks for the marc.info links though :)
[19:09:26] <negril> That isn't active
[19:09:26] <beber_> If you plot Jai Tan's commit history over time, the cluster of offending commits occurs at an unusual time compared to rest of their activity. If the dev was pwned, it could be a sign that the threat actor contributed in their own timezone https://twitter.com/birchb0y/status/1773871381890924872
[19:09:47] <hexa> pretty sure everything in this room has already been said, just not by everyone :)
[19:10:00] <nomadgeek> 😆
[19:10:10] <rurapenthe> IRC is back baby!
[19:10:17] <Celelibi> It was never gone.
[19:10:25] <negril> sam_: the second link is from someone that couldn't figure out how to unescape 
[19:10:32] <sam_> negril: ah I see
[19:10:46] <sam_> negril: so they got incomplete output on their LHS
[19:10:47] *** Joins: opal (~wowaname@gateway/tor-sasl/wowaname)
[19:10:49] <sam_> ?
[19:10:55] <negril> LHS?
[19:10:57] <sam_> i still plan on trying it myself in a bit anyway
[19:11:06] <negril> And it would still abort if any of original conditions don't hold
[19:11:08] <rurapenthe> Celelibi said IRC to half of my tech staff aged 20-25 a few weeks ago and i got blank faces lol.
[19:11:48] <nomadgeek> <--- 👴
[19:12:08] <rurapenthe> interesting point beber_ on the commits
[19:12:10] <Raito_Bezarius> sam_: also, https://social.gerbet.me/@Le_suisse/112185757137238806 -- this may still be insufficient but this is very encouraging stuff wrt to our binary cache "taint" status
[19:12:39] <Celelibi> rurapenthe, dem kids! All they want is fancy stuff.
[19:12:44] <jess> LHS london hack space????
[19:12:45] <jess> wee woo
[19:12:50] <rurapenthe> brb
[19:12:58] <NotNite> I'm dem kids! woo
[19:13:01] <tolto> i wonder why would jiatan contribute using the same account both to xz and libarchive
[19:13:05] <Baughn> Linux Hierarchy Standard?
[19:13:06] *** Quits: rurapenthe (~rurapenth@102.132.133.163) (Quit: Client closed)
[19:13:08] <negril> sam_: the only way they could inject additional function here is if they ship the file with the offsets in $srcdir/tests/ and prepared testfile
[19:13:14] <tolto> isn't that a bit stupid? they could have used two separate puppets for both of them
[19:13:16] <NotNite> could probably very easily claim top 100 for "youngest people on libera"
[19:13:16] <negril> sam_: it's basically future proving
[19:13:20] <nomadgeek> tolto: reputation?
[19:13:25] <tolto> hmm
[19:13:36] *** Quits: Guest23 (~Guest58@2a02:768:6208:8136:7ca6:1add:963e:2f9d) (Quit: Client closed)
[19:13:55] <neko2> Raito_Bezarius: interesting re: the malicious build patch failing due to some conditions not being met... what conditions fail exactly? (I'm sorry to be a pest but keeping pace with this situation has kept my head in a spin)
[19:13:55] <Celelibi> beber_, interesting, but is that all the sus commits and only sus commits?
[19:14:26] <Raito_Bezarius> neko2: it seems (I say 'it seems') to check if this is a .deb-derivative or a .rpm-derivative distribution
[19:14:36] <negril> tolto: the link beber suggests that there might be two actors. The original jia tan and the malicious actor. So the real jia tan behaved like most open source developers would and file PRs to other projects. 
[19:15:03] <tolto> negril: hmm yeah...
[19:15:10] *** Joins: Guest12 (~Guest5@2a02:2f08:7412:aa70:7dd8:bb8e:747e:ecd7)
[19:15:14] <jess> i'm... sort of a young IRC user. only just missed being a zoomer
[19:15:24] <ryzenda> luke-jr, "IIRC, Arch was one of the distros that was vulnerable?" -- I wasn't immediately aware, until 12 hours after incident happened, but at that time, #archlinux was my first place to mention and I was informed with " While Arch Linux is unaffected by the exploit caused by the backdoor, it is still there. Update RIGHT NOW. Also see https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 and https://archlinux.o
[19:15:24] <ryzenda> rg/news/the-xz-package-has-been-backdoored/" and also I glanced at https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2
[19:15:25] * neko2 headpats jess
[19:15:27] <i860> no, there was clear sockpuppet coordination and "push" before the exploit even dropped
[19:15:29] <Raito_Bezarius> jess: i'm younger than you i guess
[19:15:39] <Raito_Bezarius> :ppp
[19:15:50] <jess> Raito_Bezarius: before or after 2000
[19:15:52] <i860> it's not like it just magically happened one day
[19:15:54] <Raito_Bezarius> jess: before
[19:16:02] <mmap> <-- started using IRC in 1989, when Jaarko what's-his-name first released the client, feels old now
[19:16:06] <Raito_Bezarius> don't tell me after jess
[19:16:09] <Raito_Bezarius> don't TELL ME THAT
[19:16:11] <Rounin> 2000 is in the future; how could anyone be born then
[19:16:17] <jess> no im before
[19:16:34] <NotNite> I'm definitely zoomer territory, 17
[19:16:35] <Raito_Bezarius> actually there could be nonzero chance we are very close :-)
[19:16:41] <nomadgeek> mmap: you're a little older than me. I probably started IRC ~1993-1994?
[19:16:43] <Guest12> is this the most ingenious backdoor we've ever seen?
[19:16:58] <jess> before or after Hackers was released (1995-09-15)
[19:17:02] <Guest12> looks so masterfully executed
[19:17:02] <Rounin> Guest12: Probably not, since it was discovered... And nearly discovered a few times
[19:17:07] <Rounin> But pretty clever
[19:17:14] <ryzenda> amdj, "please don't tell me I'm going to have my mother asking what xz is" lol I bought a laptop for my mom and installed Archlinux on it for her, and one of my first thoughts was I'll need to fix that for her asap, but then I realized archlinux is not affected
[19:17:15] <Celelibi> I got my first internet access in 2001. Because in france we loved out minitel so much it hung on for quite a long time. ^^
[19:17:18] <Raito_Bezarius> jess: queries
[19:17:23] <jess> >:P
[19:17:36] <i860> i started on irc in 1994, from a netcom.com shell account - back in the days of efnet, server splits every day, etc
[19:17:39] <neko2> Guest12: that we *actually saw*? it'd be up there. now consider the ones so good they're unseen. have fun sleeping /t
[19:17:46] *** Joins: rurapenthe (~None@102.132.133.163)
[19:17:47] <levitating> Celelibi: damn straight, minitel rules
[19:17:48] <mmap> hah, i remember netcom.. isn't that the ISP that Mitnick was using?
[19:17:52] <levitating> we learned about it in CS networking class
[19:17:56] <i860> yes
[19:18:19] <i860> i used to work for them from 96-00, good place, long gone now
[19:18:24] <mmap> I had a shell account at the Well back in those days, IIRC they were running SunOS 4.x
[19:18:45] <mmap> and AI's GNU labs, rms would give a shell account to anyone that promised to contribute
[19:19:02] <dravine> I started on IRC with undernet. I had a slip account with a local university.
[19:19:05] *** Quits: Guest89 (~Guest89@2a02:8071:a582:c9c0:1e98:ecff:fe0e:21f1) (Quit: Client closed)
[19:19:30] <dravine> it was a pretty big improvement over local rural BBS's 
[19:19:45] <dravine> also, howdy.
[19:19:59] <mmap> I miss playing around on the x.25 packet nets, they actually had BBS systems running on various networks connected via Tymnet/Telenet
[19:20:11] <Celelibi> You can't imagine how much I wish I had known this era and these technologies.
[19:20:16] <mmap> this is pre 88, or so
[19:20:19] <rurapenthe> Was around 1996 for me. Someone asked me if I knew what IRC was, I said no. They said download mIRC and connect to DALNet I'll find you there. Straight-up irc addict after that. 
[19:20:20] <i860> did the bbs thing too.. of course mostly "elite" bbses ;-)
[19:20:28] *** Joins: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net)
[19:20:44] <Celelibi> But I'd have likely prefered having my general CS knowledge of today with that old tech.
[19:20:54] <nomadgeek> rurapenthe: I'm pretty sure DALnet was my first.
[19:20:55] <f_[xmpp]> off-topic?
[19:20:58] <neko2> question, is there a way to check if the malicious object file is actually present in any given liblzma, could you scan for it's contents
[19:20:59] <Celelibi> (Instead of being 8 and not understanding anything.)
[19:21:10] *** Quits: ky12 (~ky12@2607:fea8:4f20:c300:89ce:c312:bb89:6bd) (Quit: Client closed)
[19:21:16] *** Joins: uniq_ (~uniq_@2605:a601:9190:3900:858c:a7fc:cc9e:77d1)
[19:21:18] <neko2> wait someone said something about a signature already didn't they aaaa
[19:21:22] *** Joins: Yogurt (~Yogurt@158.51.82.203)
[19:21:22] <mmap> My friend's dad was.. still is a math professor at Arizona State University, so we were able to get the necessary NSF sponsorship (pre InterNIC, National Science Foundation ran the ARPA net back then) to get an entry in the ARPA hosts table, equivalent of registering a domain these days
[19:21:26] <neko2> why won't this all fit in my dang brain
[19:21:26] <Raito_Bezarius> neko2: I did
[19:21:32] <Manis> neko2, yes, that's what the YARA rule is for, no?
[19:21:34] <Raito_Bezarius> neko2: you can find the YARA signature mentioned in the toot I posted
[19:21:47] <Raito_Bezarius> you can do yara $rule -r /nix/store if you need to check your store
[19:21:51] <Raito_Bezarius> but again, a rule is only a rule
[19:21:53] <Raito_Bezarius> it's not perfect
[19:22:08] <dravine> it was a fun era
[19:22:17] <dravine> the dialup mom and pop ISP phase was a lot of fun
[19:22:26] <mmap> I miss anon.penet.fi
[19:22:42] <rurapenthe> nomadgeek, yep was awesome on there. 
[19:22:50] *** Quits: iyanmv_ (~iyan@193.32.127.221) (Quit: Konversation terminated!)
[19:23:08] <nomadgeek> dravine: I worked for one for a while. Bank of modems connected to a unix machine. Sign up a new customer? Create them a shell account.
[19:23:11] <rurapenthe> Back on topic - I'm seeing a tweet that its not auth bypass but RCE to do with the key used in the RSA_public_decrypt?
[19:23:23] <tolto> the fact that it's 2024 and IRC still exists
[19:23:25] <Guest12> I think that's worse than auth bypass
[19:23:26] <nomadgeek> rurapenthe: that appears to be accurate.
[19:23:27] <dravine> I started my career as the helldesk kid in middle school 
[19:23:32] <dravine> and worked my way up
[19:23:44] <mmap> tolto: EFNet has the dubious honor now of being the world's oldest ongoing chat network
[19:23:46] <rurapenthe> Raito_Bezarius, can you repost the yara rule I won't have scroll back
[19:23:53] <dravine> my boss was a dick and made me write shit in C that could have been a very sort perl script 
[19:23:54] <Sora> [2nd hand info] yes it calls system() on some payload that is decrypted via chacha20 
[19:23:54] *** Joins: m1k3sh (~m1k3sh@ip-037-201-116-138.um10.pools.vodafone-ip.de)
[19:23:55] <tolto> nice
[19:23:58] <Habbie> https://abyssdomain.expert/@filippo/112185827553387306
[19:24:04] <Habbie> click this, skip one hand :)
[19:24:10] <tolto> my first network was freenode, i think. early 2000s
[19:24:10] *** Quits: plat0 (~plato@90-227-104-117-no2380.tbcn.telia.com) (Remote host closed the connection)
[19:24:15] <rurapenthe> tolto, IRC is gonna be here after the fallout dude. :p
[19:24:18] *** Joins: Guest93 (~Guest93@81.214.28.49)
[19:24:19] <tolto> lol
[19:24:37] <tolto> IRC doesn't support multiline messages. which is one thing that i would improve
[19:24:46] <Raito_Bezarius> rurapenthe: https://github.com/Neo23x0/signature-base/pull/313/files
[19:24:47] <nomadgeek> rurapenthe: looks like the key value was to be a signed payload. If it was signed correctly it was executed. If not, it was passed to libcrypt.
[19:24:48] <tolto> and sorry about the off-topic
[19:24:50] <Sora> federated twitter was a mistake
[19:24:51] *** Quits: Guest28 (~Guest28@p200300f857310000b52623e5726dc438.dip0.t-ipconnect.de) (Quit: Client closed)
[19:24:52] <neko2> on a technical note though, because my knowledge of linking is a bit fuzzy... I presume it's not quite as simple as "look for the .o file's contents in liblzma.so" because symbols would get resolved to addresses/offsets?
[19:24:55] *** Parts: leggo (~katt__@147.28.162.171) (Leaving)
[19:24:56] <dravine> there's work going on about V3 IRC spec
[19:24:58] <Sora> its not ok that my server gets ddosed every time someone posts an image
[19:25:07] <Sora> when 500 instances try to fetch it at the same time
[19:25:08] <Sora> ./rant
[19:25:12] <Guest93> hey guys is there any news from Jia Tan?
[19:25:19] <rurapenthe> Thx Raito_Bezarius 
[19:25:22] <mmap> Does anyone really know who he is?
[19:25:25] <nomadgeek> Guest93: not that I've seen.
[19:25:25] *** Quits: Guest87 (~Guest87@2607:fea8:9565:8e00::c54) (Quit: Client closed)
[19:25:41] <Raito_Bezarius> neko2: you can look for the characteristic symbols of the malicious payload
[19:25:44] *** Joins: Guest26 (~Guest26@31.134.189.244)
[19:25:49] <i860> funny story, as young punks, a friend and I were actually "hacking" auto-op bots in popular channels on efnet by manipulating usernames with a custom client and since we both had netcom shell accounts it was very easy to do.. we got our accounts temporarily locked over it and a couple years later i had to explain the whole story to the hiring
[19:25:49] <dravine> I suspect that identity was crafted 
[19:25:49] <i860> manager at netcom when i interviewed for a NOC position ..That hiring manager, Jay Adelson, went on to do equinix and digg..
[19:26:06] <mmap> Using a VPN, he could've been originating from anywhere... can't write off the possibility of state-sponsored bad actor
[19:26:19] <Celelibi> tolto, dravine, #ircv3 right here on libera. ^^
[19:26:22] <dravine> my buddy and I got the University of Alaska DDoS'd by romanian's one day
[19:26:24] <rurapenthe> nomadgeek, hmmm interesting. Quite specific and not really your "spray-n-pray" type of backdoor then. 
[19:26:30] <tolto> Celelibi: i'll join *shrug*
[19:26:32] <dravine> they wanted a channel we hung out in ( they won )
[19:26:43] <mmap> i860: don't forget about CTCP echo reply attack they were using against IRC servers to cause a split, man those were funny
[19:26:44] <nomadgeek> rurapenthe: nah. This was a nation-state with targets in mind or I'll eat my hat.
[19:26:45] <laanwj2> neko2 correct, you won't just find the entire .o in there, nor consecutive code, but you could look for the stuff from.data sections, such as the tables, it wont have relocations
[19:26:47] <f_[xmpp]> > I suspect that identity was crafted
[19:26:47] <f_[xmpp]> dravine: yeah that could be possible
[19:26:49] <tolto> (oh nvm it needs NickServ authentication)
[19:26:53] <i860> dravine: lol.. classic stuff
[19:26:55] <mmap> or was it ICMP port unreachable? I forget
[19:26:56] <rurapenthe> nomadgeek, yeah. Agree
[19:27:13] <dravine> our ISP at work called me "Why are you getting 900mb of constant traffic?"
[19:27:14] *** Joins: plat0 (~plato@178.158.218.215)
[19:27:31] <dravine> me: "oh man, that's a really good question have you guys figured it out yet? Let me know when you fix our internet!"
[19:27:49] <dravine> this was like 2006 or so lol
[19:27:59] <i860> rode so many splits back in the day.. when you're a 16-17 year old with an internet account it was just what you did at the time
[19:28:20] <f_[xmpp]> Starts getting off-topic AFAICT...
[19:28:26] <nomadgeek> rurapenthe: my speculation is that this needed to be in place to coordionate with something else they had in mind. That's why they were pressing so hard to get it into this release of distros.
[19:28:41] <dravine> I had a buddy in australia and I worked at an ISP, I used to ddos BigPond's core router for a minute to boot him offline 
[19:28:41] <jess> i860: thank goodness the s2s protocol resolved splitriding for the most part
[19:28:47] <dravine> that was late 90s
[19:28:48] *** Joins: mvxdg4hf (~mvxdg4hf@ip-037-201-116-138.um10.pools.vodafone-ip.de)
[19:29:00] <nomadgeek> Otherwise, I don't see a reason to press so hard to get it in. They played a 3 year long game. What is one more distro cycle.
[19:29:03] <jess> you can still splitride past a +i or similar cmode but you won't have op
[19:29:05] *** Quits: MPThLee (~MPThLee@user/MPThLee) (Quit: bye)
[19:29:10] <rurapenthe> nomadgeek, hmmm yeah. Wonder what though? Because by pressing harder they elevated their noise level. 
[19:29:15] <f_[xmpp]> also who in the world is real_jiatan
[19:29:16] <nomadgeek> exactly
[19:29:38] <i860> it's someone trolling
[19:29:52] <nomadgeek> i860: yeah.
[19:29:53] <tolto> about the 5.5.x beta/alphas:
[19:29:56] <tolto> <sjw[m]> <tolto> "there are also 5.5.x betas and..." <- You can find 5.5.1alpha and 5.5.2beta here: https://snapshot.debian.org/package/xz-utils/
[19:29:56] <tolto> <sjw[m]> They do not contain the malicious `build-to-host.m4`.
[19:30:10] * jess slams paws on keyboard
[19:30:14] <Rounin> There is a... #linux-offtopic with some people in it
[19:30:14] <f_[xmpp]> tolto: where was that?
[19:30:14] <Celelibi> f_[xmpp], it's jaeg-er
[19:30:21] *** real_jiatan is now known as 074AACD7D
[19:30:27] <Rounin> Though at this rate, perhaps there should be a #tokaani-ontopic instead
[19:30:28] <tolto> f_[xmpp]: #xz-backdoor-reversing on OFTC IRC
[19:30:30] <sam_> tolto: thank you!!
[19:30:33] <f_[xmpp]> Celelibi: Who's jaeg-er
[19:30:36] <f_[xmpp]> tolto: thx
[19:30:50] * neko2 offers jess headpats
[19:30:59] <dravine> hah
[19:31:40] <Celelibi> f_[xmpp], some random guy.
[19:31:45] <Celelibi> I guess.
[19:32:25] <jess> i will use the tools available to me to prevent impersonation with gay abandon
[19:32:45] <f_[xmpp]> jess: hehe
[19:33:03] *** Joins: MPThLee (~MPThLee@user/MPThLee)
[19:33:17] <xcvb> jess: well how is your prevention going
[19:33:43] *** Parts: mmap (mmap@ip117.net198.grossman.com) ()
[19:33:49] <levitating> q3k: anything new?
[19:34:01] *** Quits: Guest11 (~Guest54@136.37.175.163) (Ping timeout: 250 seconds)
[19:34:02] <jess> fine so far i think
[19:34:13] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[19:34:20] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[19:34:34] <q3k> levitating: not from me, but from others: https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b
[19:34:41] *** Joins: Guest87 (~Guest87@om126156186134.26.openmobile.ne.jp)
[19:34:42] <levitating> I saw that yes
[19:34:49] <q3k> and that fits with what we've seen so far (we have the RSA hook, and someone is looking at that)
[19:34:53] <tolto> yeah, just checked the 5.5.2 beta. it literally has the "build-to-host" missing
[19:34:55] *** Quits: MPThLee (~MPThLee@user/MPThLee) (Client Quit)
[19:35:01] <tolto> jiatan just sneakily added "build-to-host" since 5.6.0
[19:35:14] <q3k> but the key isn't just hardcoded, no. it seems to be assembled throughout execution by little functions calls here and there
[19:35:20] <levitating> classic
[19:35:28] <tk> I'm curious about this: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
[19:35:32] <levitating> I guess all those CTF reverse engineering challenges are paying off lmao
[19:35:47] *** Joins: MPThLee (~MPThLee@user/MPThLee)
[19:35:50] *** Joins: marblood (~marblood@45.134.213.216)
[19:35:56] <tk> Is there any actual evidence that there are systems with linux/landlock.h but without SYS_landlock_create_ruleset, SYS_landlock_restrict_self, LANDLOCK_CREATE_RULESET_VERSION and PR_SET_NO_NEW_PRIVS defined?
[19:36:00] <dravine> is there a copy of the final payload available?
[19:36:16] <Celelibi> tk, even reading this diff I missed the sneaky period. ^^
[19:36:52] <Guest93> what even is the final payload?
[19:37:10] <negril> Guest93: unknown. it's injected over ssh
[19:37:28] <tolto> .
[19:37:29] *** Quits: Guest81 (~Guest41@ppp-83-171-165-233.dynamic.mnet-online.de) (Ping timeout: 250 seconds)
[19:37:29] *** Quits: zekica (~zekica@178-220-122-192.static.isp.telekom.rs) (Ping timeout: 250 seconds)
[19:37:34] <levitating> dravine: oss-security 
[19:37:37] <amdj> tk: the header comes from some sort of linux-headers package, and it's quite common that it exceeds the kernel version. for example I have 11 systems with linux-headers-6.1 but kernel 5.10.x.
[19:37:47] <Manis> tk, yes it could theoretically be. the linux/landlock.h header comes from the linux-headers package while the system could not have these installed or running a different kernel altogether.
[19:37:54] <levitating> amdj: should those not be in sync
[19:38:02] <amdj> they don't have to be.
[19:38:02] <jess> network staff won't disclose any information we do or dont know about jiatan but i will say the nickserv account remains available to login by its owner and efforts are being undertaken to ensure the account retains the same amount of authenticity it had before all this came to light
[19:38:17] <Manis> levitating, you can have 10 kernels installed but only one set of linux-headers.
[19:38:21] *** Quits: grd (~grd@84-112-217-88.cable.dynamic.surfer.at) (Ping timeout: 250 seconds)
[19:38:22] <nomadgeek> Guest93: "final" that we know about is the hook to RSA that allows a signed payload to be executed. Because this was caught before it got into major distros, we'll likely never know what the final payload was meant to be,.
[19:38:29] <tk> yes sure, but this is a check_c_source_compiles check, if the header defines things and then you get an ENOSYS you already need to check that in the code even if this check_c_source_compiles succeeds
[19:38:31] <f_[xmpp]> jess: Fair.
[19:38:37] <negril> levitating: they should be, might be a typo
[19:38:48] <Manis> But OTOH the kernel you're running is volatile. xz-utils won't automaically recompile when you pick a different kernel of course.
[19:38:48] *** Joins: Guest96 (~Guest68@142.147.89.219)
[19:38:50] <negril> it's also been committed in the normal time frame
[19:38:53] *** Joins: zekica (~zekica@178-220-122-192.static.isp.telekom.rs)
[19:39:01] <tk> so yes, I agree headers can mismatch, but this check seems bogus on the basis that if you have linux/landlock.h (and don't have landlock support) then this won't check for that anyway
[19:39:12] <sam_> tbh
[19:39:14] <Celelibi> Manis, I'm pretty sure you can have as many headers as you want. I do on some machines.
[19:39:25] <sam_> I think that part is slightly overdone, because many systems don't even support landlock yet
[19:39:27] <Celelibi> And they should match one of the installed kernel.
[19:39:29] <sam_> but yes, it's obviously bad
[19:39:31] <Manis> Celelibi, how do they not clobber?
[19:39:38] <brlin> I've created a HackMD workspace for collecting related information regarding this incident: https://hackmd.io/@cve-2024-3094/home
[19:39:38] <brlin> It's quite a work in progress as of now but feel free to contribute.
[19:39:53] <Manis> Is it not possible to detect landlock at runtime? That would make the most sense IMO.
[19:39:59] <tk> Manis: yes it is possible
[19:40:07] <Celelibi> s -d /usr/src/linux-headers-*
[19:40:12] <Celelibi> /usr/src/linux-headers-6.6.13-amd64/  /usr/src/linux-headers-6.6.13-common/  /usr/src/linux-headers-6.6.15-amd64/  /usr/src/linux-headers-6.6.15-common
[19:40:12] <Manis> So you'd just need the header for the function declarations.
[19:40:14] <sam_> to do this kind of thing robustly, you have to do a compile-check because you do not know what linux-headers is in use
[19:40:15] <jess> and many efforts are being undertaken to prevent nickname-based impersonation attempts alongside the effort to maintain integrity of the nickserv account
[19:40:17] <sam_> and you also need a runtime check for ENOSYS
[19:40:23] <tk> but I am wondering if there is a state in which you would have linux/landlock.h but where that check_c_source_compiles (with the sneaky . removed) would ever fail
[19:40:29] <sam_> because of: a) missing runtime support (too old kernel or disabled config), OR b) seccomp and such
[19:40:37] <Manis> sam_, so the header exists check would suffice for compile time.
[19:40:50] <sam_> it depends on if constants are used from it rathe rthan just existence
[19:40:54] <sam_> i don't know off the top of my head
[19:40:55] *** Parts: Guest87 (~Guest87@om126156186134.26.openmobile.ne.jp) ()
[19:40:57] <Manis> tk, latest linux-headers but running an older kernel.
[19:40:59] <tk> because if you don't, a good option might just be to forego the unnecessary compile-time check, and just always check in the code, surely a single kernel context switch to call landlock_create_ruleset is not a huge price to pay
[19:41:00] <f_[xmpp]> jess: nice.
[19:41:09] <tk> Manis: the code would still compile in that case nio?
[19:41:16] <tk> Manis: syscalls don't rely on linking
[19:41:21] <Celelibi> Manis, in my experience, headers are mostly used to compile kernel modules for a given kernel version.
[19:41:29] <tk> if the headers are there, the SYS_ values are defined
[19:41:46] <Manis> tk, hmm I'm not sure. Is the code only compiled and never run in the configure check?
[19:41:51] <tk> Manis: correct
[19:41:55] *** Joins: Guest76 (~Guest76@159.148.172.3)
[19:41:56] <Manis> in that case, yes.
[19:42:00] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[19:42:12] <sam_> iirc landlock has diff. versions
[19:42:12] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[19:42:21] <sam_> it might be they shove it all in the header but the relevant bits arent always there
[19:42:25] <sam_> i don't know, i'm just saying that's pretty normal
[19:42:27] <q3k> https://gynvael.coldwind.pl/?lang=en&id=782 writeup about the injection part
[19:42:28] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Quit: peace)
[19:42:38] <sam_> thanks
[19:42:51] <Manis> I would tend to say that this commit is malicious, too.
[19:42:54] <q3k> (by gynvael, not me)
[19:42:54] *** Quits: dutch (~DutchIngr@user/dutch) (Quit: WeeChat 4.2.1)
[19:42:59] *** Joins: alexl (~alexl@2a0a-a543-5d23-0-c574-d6cd-1a44-566.ipv6dyn.netcologne.de)
[19:43:21] <sam_> q3k: added to the FAQ as I am familiar with the author + at a skim (I read quickly) it looks great
[19:43:24] <sam_> thanks!
[19:43:24] *** Parts: gagz (~gagz@user/gagz) (seeya)
[19:43:26] <Manis> ofc this more complicated check was a good place to inject a typo. If it's just a two line diff it would have been spotted more easily.
[19:43:47] <sam_> q3k: feel free to throw me anything more if I miss stuff
[19:43:56] <tolto> yeah the attackers behind jiatan were considerate indeed
[19:44:00] <tolto> about many possible scenarios
[19:44:24] <bt__> q3k: kinda offtopic, but are you the same q3k who did the steamid ticket injection POC back in 2010s? Haven't heard your name in a while
[19:44:29] *** Joins: GynDream (~gynvael@77-58-247-142.dclient.hispeed.ch)
[19:45:02] <q3k> bt__: lmao yes
[19:45:07] <q3k> jesus christ what a throwback
[19:45:28] *** Quits: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi) (Ping timeout: 268 seconds)
[19:45:39] *** GynDream is now known as Gynvael
[19:45:44] <JTL> steamid ticket injection?
[19:45:44] <q3k> sam_: other than filippo's bsky post i don't have anything (yet)
[19:45:45] <levitating> steam ticket injection POC? taht sounds fun
[19:45:55] <sam_> q3k: I'll chuck it in too as it was useful reading
[19:46:08] <levitating> sam_: you writing some kind of writeup?
[19:46:13] <q3k> JTL, levitating: valve's source netcode had a bug where you can sniff authentication tickets and then replay them
[19:46:23] <sam_> I'm maintaining the FAQ + rolling summary at least (see /topic)
[19:46:27] <JTL> ah
[19:46:28] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[19:46:28] <sam_> I may or may not write up more if it's needed
[19:46:32] <q3k> so if you had an admin of server A join your server B while you capture the packet, you could log in as them to server A
[19:46:32] *** Joins: NickerBocker (~NickerBoc@2001:99a:411:7000:576e:a5c8:7802:ab38)
[19:46:37] <sam_> right now I'm collecting tarballs 
[19:46:37] <q3k> (or any other server)
[19:46:38] <Guest93> nomadgeek: sorry if I'm coming off as a newbie here, but what do you mean by signed payload? Is is something like the attacker send something signed and then RSA hook executes that thing? And since it won't be executed anymore, we will never know what it is? Am I correct?
[19:46:40] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[19:46:45] <JTL> q3k: someone did the same for Minecraft at some point
[19:46:49] <JTL> called "session stealer"
[19:46:55] <f_[xmpp]> that's the same q3k who decided that running wayland on an iPod was a good idea
[19:47:00] <neko2> sam_: thank you for your time doing so btw
[19:47:03] <sam_> <3
[19:47:04] <q3k> f_[xmpp]: my apologies
[19:47:08] <JTL> lmao
[19:47:30] <nomadgeek> Guest93: We could capture the payload if it was sent (to a honeypot) but the attackers here were caught before completing their plan, so we don't get to see that final payload.
[19:47:33] <f_[xmpp]> q3k: I mean..
[19:47:37] *** Joins: Guest6 (~Guest6@071-010-183-017.res.spectrum.com)
[19:47:43] <q3k> sam_: also the Gynvael that just joined is the real deal, fwiw :)
[19:47:48] <f_[xmpp]> ..I might be crazy
[19:47:48] <levitating> q3k: why the hell are the bullet points on your webpage not centered with the content lmao
[19:47:52] <bt__> damn, 14/11/2010 (at least according to NTFS)
[19:48:01] *** Quits: uniq_ (~uniq_@2605:a601:9190:3900:858c:a7fc:cc9e:77d1) (Quit: nyaa~)
[19:48:03] <q3k> levitating: because i good at html
[19:48:13] <q3k> (i have a fix for that... somewhere)
[19:48:24] <Gynvael> uhm, hi?
[19:48:24] <f_[xmpp]> I myself thought that reverse engineering 2015 SoC firmware was a good idea :P
[19:48:39] <f_[xmpp]> Gynvael: hi
[19:48:42] <sam_> Gynvael: ha, sorry, we were just talking about the post which is great
[19:48:48] <sam_> thanks for it
[19:48:54] <JAA> sam_: Collecting the original/compromised tarballs that were on GitHub, or something else?
[19:49:08] <sam_> JAA: yes
[19:49:08] <laanwj2> rc4 in awk... hah... more overkill, the backdoor authors definitely like their ciphers
[19:49:08] <Znevna> ah you're one of the train guys, hi! ^^
[19:49:10] <f_[xmpp]> But I never went as far as reverse engineering a train's firmware :P
[19:49:14] <Gynvael> sam_: thank you for maintaining that FAQ, that's an amazing source
[19:49:31] <JAA> sam_: I archived all of those yesterday before the repository was taken down.
[19:49:43] <sam_> JAA: Would you mind sending me them? I have checksums, just not the actual files for all of it
[19:49:46] <f_[xmpp]> JAA: nice
[19:49:47] *** Quits: s3 (~bn@user/bn) (Quit: Leaving)
[19:50:05] <JAA> https://web.archive.org/web/*/https://github.com/tukaani-project/xz/releases/download/*
[19:50:08] <tolto> is the payload encrypted?
[19:50:11] <sam_> ah great
[19:50:13] <tolto> that is meant to be sent.
[19:50:20] <tolto> or is just the signature verified against the public key in the .o?
[19:50:24] <nomadgeek> Guest93: also, no worries about being a noob. Asking questions is how folks go from not knowing to knowing. 
[19:50:30] *** 074AACD7D is now known as jia_tan
[19:50:38] <levitating> sam_: what you writing
[19:50:42] <susi> just make sure not to ask dumb questions
[19:50:46] <nomadgeek> tolto: sounds like the public key was assembled in the process of build.
[19:50:48] <levitating> wow guys its jia_tan how interesting
[19:50:59] <levitating> hey susi you here as well
[19:51:00] <JAA> I also archived a copy of the GitHub repository, including all branches and unmerged PRs.
[19:51:02] <tolto> nomadgeek: "build"?
[19:51:08] <laanwj2> don't want to get into attribution, but all of this screams sigint community
[19:51:09] *** Joins: otlesfenrtf^ (~cd@c-98-242-74-66.hsd1.ga.comcast.net)
[19:51:21] *** Quits: zekica (~zekica@178-220-122-192.static.isp.telekom.rs) (Ping timeout: 250 seconds)
[19:51:30] <JAA> (Not issues and PR discussions though.)
[19:51:37] <Guest93> just curious, anyone tracking down jia tan? lol
[19:51:38] <f_[xmpp]> jess: > jia_tan
[19:51:48] <JTL> f_[xmpp]: it's a troll
[19:51:50] <nomadgeek> tolto: let me see where I saw that - but I mean the execution of shell scripts that pull the hook code out of the test files.
[19:51:51] <rurapenthe> Q3k what that your blog u linked?
[19:52:06] <jess> sacre bleu
[19:52:07] <susi> levitating: hey, your nick come up in /whowas <youknowwhat>!
[19:52:09] <f_[xmpp]> JTL: yes I'm aware, thus why I'm pinging jess about it
[19:52:15] <tolto> nomadgeek: there's some write up here: https://gynvael.coldwind.pl/?lang=en&id=782
[19:52:26] <tolto> i meant in sshd
[19:52:28] <jess> jia_tan: i'm going to ban you from the network if you keep trying to impersonate
[19:52:36] <q3k> rurapenthe: gynvael.coldwind.pl isn't mine, it's Gynvael's
[19:52:38] <levitating> susi: that's great lmao
[19:52:39] <negril> Gynvael: would you agree that the "eval $zrKcjv" stuff is for debugging?
[19:52:48] <mvxdg4hf> Celelibi where is the sneaky period? I can not see it.
[19:52:52] <levitating> susi: I know you from #archlinux-offtopic I think?
[19:52:57] <rurapenthe> Oh Gynvael is here nvm :) wanted to say its an awesome write-up
[19:53:02] <tolto> when it runs and the jiatan HQ wants to send a payload. do they sign (?) the payload using their private key, or do they *encrypt* the payload?
[19:53:13] <Gynvael> negril: yeah, that was my Guess
[19:53:20] <Gynvael> rurapenthe: <3
[19:53:23] *** Joins: Guest60 (~Guest60@dsl-hkibng42-56733b-157.dhcp.inet.fi)
[19:53:26] <JAA> mvxdg4hf: https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00
[19:53:45] <tk> sam_: and there's no feature test macros for this?
[19:53:47] *** Quits: NickerBocker (~NickerBoc@2001:99a:411:7000:576e:a5c8:7802:ab38) (Ping timeout: 268 seconds)
[19:53:52] *** jia_tan is now known as 074AACD7D
[19:54:07] <nomadgeek> tolto: appears to me that they are signing it. To encrypt it would mean the malware would need to maintain a private key to decrypt.. which would be mostly pointless.
[19:54:12] *** Joins: khzn (~khzn@2607:fb91:21c7:c890:9c16:6492:3c13:fc83)
[19:54:25] <tk> It just seems to me like it should *** be entirely possible to test for this stuff without autotools-grade "check-if-this-snippet-of-code-compiles" nonsense
[19:54:32] <tk> My least favourite feature of autotools
[19:54:42] <sam_> tk: sorry, could you be more specific? it's the norm to have to probe stuff via linux-headers at compile-time. you can #ifdef stuff though, yeah. i guess it's useful to be able to say "--enable-sandbox=landlock" and have it abort if it can't do what you wanted
[19:54:43] *** Quits: k__ (~Guest61@nmal-25-b2-v4wan-166401-cust115.vm24.cable.virginm.net) (Ping timeout: 268 seconds)
[19:54:48] <sam_> tk: but whether or not that's worth it is another question ;)
[19:54:51] <tolto> nomadgeek: ok, i guess that means the payload would be in plain text
[19:54:53] <sam_> (I guess it isn't.)
[19:55:05] <sam_> going to eat for a bit
[19:55:07] <nomadgeek> tolto: yeah. 
[19:55:11] *** Joins: NickerBocker (~NickerBoc@mobile-access-c1d2cb-124.dhcp.inet.fi)
[19:55:13] <tolto> apparently it's feeded to system()
[19:55:16] <tolto> according to that researcher
[19:55:26] <mvxdg4hf> JAA thanks
[19:55:42] <jess> f_[xmpp]: ty for ping
[19:55:51] <f_[xmpp]> jess: np
[19:55:58] <sam_> also thanks for everyone helpinf keep the channel sane + useful
[19:56:03] *** Joins: ozel (~ozel@2a02:8071:886:560:c52b:3976:d600:16d4)
[19:56:03] *** Quits: NickerBocker (~NickerBoc@mobile-access-c1d2cb-124.dhcp.inet.fi) (Read error: Connection reset by peer)
[19:56:04] <sam_> it's not easy 
[19:56:08] <sam_> now really bbiab
[19:56:13] <nomadgeek> ❤️
[19:56:14] <f_[xmpp]> sam_: including you :)
[19:56:15] <jess> ciao sam, much love
[19:56:20] <sam_> <3
[19:56:25] <f_[xmpp]> <3
[19:56:26] *** Joins: NickerBocker (~NickerBoc@81-197-72-195.elisa-laajakaista.fi)
[19:56:46] <levitating> have a nice meal
[19:56:50] *** Quits: khzn (~khzn@2607:fb91:21c7:c890:9c16:6492:3c13:fc83) (Client Quit)
[19:57:43] <Guest12> so the final crafted malicious .o already has the compiled binary code that we didn't yet see? because I see all blog posts just covering the way that code got there, and not the actual bad code itself
[19:57:52] <nomadgeek> tolto: if this went off the way they planned, we wouldn't have known it was there. Depending on the payload and how much clean up they did we may not have caught it even after they used it.
[19:57:53] <f_[xmpp]> mm..
[19:58:03] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[19:58:06] *** Joins: zekica (~zekica@178-220-122-192.static.isp.telekom.rs)
[19:58:16] <Gynvael> Guest12: yeah, there's no code there, there's only the binary .o; and it's obfuscated af
[19:58:23] <nomadgeek> Guest12: there doesn't appear to be much payload - it's an RCE injector.
[19:58:24] <Gynvael> though folks are crunching through it
[19:58:29] <levitating> Guest12: the test files includes the compiled binary instructions that ended up in the final build library
[19:58:40] <negril> Good thing is, all this relies on the testfiles being present
[19:58:44] <Guest12> this is absolutely mindblowing tbh
[19:58:51] <rurapenthe> sam_, anytime. Missed IRC actually so I'm quite happy. Getting to catch up on this issue and do some good old chatting
[19:58:52] <levitating> for everyone tbh
[19:59:07] <levitating> rurapenthe: you should get on irc more often
[19:59:09] *** Quits: alreadydone (~alreadydo@2601:152:300:6266:706e:6030:ffd:4024) (Ping timeout: 250 seconds)
[19:59:21] <rurapenthe> levitating, I should. I will :p
[19:59:22] <nomadgeek> build script -> pull payload out of test files -> hook into RSA calls -> if SSH Key is actually a signed payload -> Shell Code.
[19:59:22] <f_[xmpp]> rurapenthe: my entire bnc is down so I use that f_[xmpp] connection for now :/
[19:59:31] *** Joins: Red (~Red@102.92-221-235.customer.lyse.net)
[19:59:38] <ryzenda> hsiangkao, "I don't know what happened though." yeah, i asked Larhzu earlier and they said all they know about disabled access is "account violates our Acceptable Use Policy" and they also said "Suspending the account has pros and cons. If compromised account was suspected then it's good to do." and "But it also takes away one way of communication." and "So I'm glad I insisted on keeping the rest of Tukaani on my own website 
[19:59:38] <ryzenda> and domain."
[19:59:40] <f_[xmpp]> I usually have an "f_" connection which is a bnc
[19:59:48] <rurapenthe> f_[xmpp],  aah ok
[20:00:07] <tolto> nomadgeek: yeah, although linking with a binary executable may have crashed on some rare configurations. and that may be one way to catch it. however, how long were they planning to take advantage of the backdoor for?
[20:00:13] *** Joins: Guest36 (~Guest36@2804:14c:65d2:8835::1001)
[20:00:16] <tolto> all in all, it's a pretty sophisticated method
[20:00:16] <Guest12> nomadgeek: that seems like a good summary, yes. but why is the binary so slow?
[20:00:21] *** 074AACD7D is now known as jaeg-er
[20:00:33] <negril> indirection
[20:00:35] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[20:00:43] <nomadgeek> Guest12: they rushed? Only they know why they made mistakes.
[20:00:47] <Apachez> Guest12: sure - optimizing a malware, what could possible go wrong? ;-)
[20:00:53] <tolto> has anyone seen the "Operation Triangulation" talk on 37C3? it's an ios exploit that had very many stages
[20:00:55] <xcvb> indirection is software's biggest problem these days. nevermind that it's written in sh or awk
[20:01:16] <tolto> and as far as i remember, one of them meant supplying payloads dynamically
[20:01:19] <Guest12> Apachez: looks like the very reason we're all here was insufficient optimization :D
[20:01:25] <negril> they seem to heavily split up the actual functionality to make it harder to detect
[20:01:45] <neko2> xcvb: sh or awk? I raise you haskell compiled on the fly by a shebang wrapper /j
[20:01:55] <tolto> i'm pretty sure a lot of malware of such grade works that way. that they try to hide the end purpose of it
[20:01:56] *** Quits: dravine (~dravine@user/dravine) (Quit: My MacBook has gone to sleep. ZZZzzz…)
[20:01:58] *** Joins: Guest98 (~Guest60@190-205-178-192.dyn.dsl.cantv.net)
[20:02:00] *** jaeg-er is now known as jiat-an
[20:02:01] *** Quits: Guest9034 (~user@cpe-94-253-208-181.st2.cable.xnet.hr) (Quit: Konversation terminated!)
[20:02:02] <tolto> even after sending payloads they would try to clean up as much of it as possible
[20:02:14] *** Quits: Guest26 (~Guest26@31.134.189.244) (Quit: Client closed)
[20:02:26] <nomadgeek> tolto: indeed. and if execute discretely, you may still not notice.
[20:02:37] <tolto> yeah
[20:02:51] *** Quits: jiat-an (~jaeg-er@44-174-190-90.dyn.estpak.ee) (K-Lined)
[20:02:53] <jess> warned ya
[20:02:58] <f_[xmpp]> jess: ?
[20:03:21] <f_[xmpp]> Sorry, I can't see kicks/bans/quits/joins from this XMPP client..
[20:03:29] <nomadgeek> I think someone was just banned.
[20:03:31] <tolto> the guy impersonating jiatan got k-lined
[20:03:46] <f_[xmpp]> can anyone paste? ;P
[20:04:00] <f_[xmpp]> mm ok
[20:04:02] <tolto> * jiat-an has quit (K-Lined)
[20:04:11] <f_[xmpp]> heh
[20:04:29] <neko2> do not anger the jess
[20:04:58] <levitating> so I guess this is how we're all going to spend our weekends
[20:04:59] * f_[xmpp] looks at our favourite sandcat.
[20:05:16] <Noisytoot> f_[xmpp]: use a different client
[20:05:23] <neko2> levitating: wait what is sorry?
[20:05:34] <nomadgeek> levitating: I need to wander off for some time touching grass with my little one shortly, but otherwise I'll be here.
[20:05:36] <carbon_dioxide> Ongoing backdoor analysis of the payload: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
[20:05:36] <f_[xmpp]> Noisytoot: I'm chatting from a phone
[20:05:38] *** Quits: zekica (~zekica@178-220-122-192.static.isp.telekom.rs) (Quit: Client closed)
[20:05:39] *** Joins: Platonides (~Wikipedis@wikimedia/Platonides)
[20:05:47] <f_[xmpp]> not much choices regarding an xmpp client
[20:05:57] <f_[xmpp]> poezio shows quits/joins just fine
[20:06:04] <f_[xmpp]> but monocles-chat doesn't
[20:06:16] <f_[xmpp]> and Conversations doesn't either
[20:06:29] *** Joins: Skyluker4 (~Skyluker4@2600:8804:84c0:1:94ed:a40d:de31:54a6)
[20:06:40] *** Joins: wehttam (~wehttam@1.146.120.30)
[20:06:46] <Red> mobile irc client:-)
[20:06:54] <nomadgeek> My Limechat on Macos doesn't show the K-line either.
[20:07:06] <Red> that's surely a configuration option?
[20:07:13] <nomadgeek> A little disappointing, honestly.
[20:07:21] *** Quits: Guest93 (~Guest93@81.214.28.49) (Quit: Client closed)
[20:07:28] <f_[xmpp]> Red: except I'm not chatting from an irc client
[20:07:29] <nomadgeek> Red: I checked after the ban to see.. no option.
[20:07:32] <tolto> carbon_dioxide: wow this is really sophisticated
[20:07:33] <bjorn3> pidgin doesn't show it for me either. couldn't find any option to show it. regular leaves are shown though.
[20:07:42] <tolto> like the usage of Tries as well as ELF detection
[20:08:04] <Red> that's very strange
[20:08:08] <f_[xmpp]> Red: the "f_" connection I usually have is a bnc (which is down)
[20:08:23] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[20:08:42] <f_[xmpp]> and this connection is my xmpp bridged to IRC using biboumi/irc.cheogram.com
[20:09:50] <f_[xmpp]> Red: got it?
[20:09:51] *** Joins: Guest47 (~Guest47@185.160.20.244)
[20:09:59] *** Quits: Totoposto (~Totoposto@197.153.79.137) (Ping timeout: 250 seconds)
[20:10:00] <Red> yes:-)
[20:10:27] <f_[xmpp]> To IRC-side that f_[xmpp] connection just works like a regular bouncer
[20:10:35] *** Joins: Guest52 (~Guest36@179.214.112.141)
[20:10:41] <f_[xmpp]> and I use it as a backup bouncer when I need to ^^
[20:10:51] <carbon_dioxide> tolto: to be clear, I'm not the author of that gist, I just got sent the link and decided to share it here
[20:10:57] <tolto> ok
[20:11:04] *** Quits: Skyluker4 (~Skyluker4@2600:8804:84c0:1:94ed:a40d:de31:54a6) (Remote host closed the connection)
[20:11:34] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[20:11:35] <tolto>     In version 5.6.0 it's 86 F9 5A F7 2E 68 6A BC,
[20:11:35] <tolto>     and in 5.6.1 that's E5 55 89 B7 24 04 D8 17.
[20:11:41] <tolto> looks like malformed x86 ASM to me
[20:11:43] *** Quits: Guest36 (~Guest36@2804:14c:65d2:8835::1001) (Ping timeout: 250 seconds)
[20:11:54] <tolto> but could very well just be random
[20:12:13] <negril> They might be need to make the xz stream valid
[20:12:29] <tolto> > The check whether the script is running on Linux was added in 5.6.1, and the fact that it's repeated 5 times makes this pretty funny – was someone like "oops, forgot this last time and it cause issues, better put it in 5 times as an atonement!"?
[20:12:36] <tolto> probably to control the size of the file
[20:12:37] <f_[xmpp]> I'll go
[20:12:40] <f_[xmpp]> cya!
[20:12:42] <tolto> bye
[20:12:50] <bt__> cya
[20:12:52] <Manis> bye f_[xmpp] 
[20:13:01] <f_[xmpp]> Hopefully tomorrow I'll have enough time to get that bouncer up and running again :)
[20:13:04] *** Joins: dutch (~DutchIngr@user/dutch)
[20:13:20] <f_[xmpp]> (to be clear that connection won't disconnect, I'll just be afk for a while)
[20:13:35] <nomadgeek> tolto: I find the buffering of the first 1024 bytes of the file with 'A' kinda like an 'FU'
[20:14:01] <tolto> hmm lol
[20:14:09] <negril> I looked at the hexdump of those two files and was like huh
[20:14:44] <tolto> nomadgeek: doesn't that make it look like a specially crafted file for "unit testing" purposes? that's probably what they were going for idk
[20:15:20] *** Joins: Bl3nd3r (~Bl3nd3r@185.107.56.47)
[20:15:27] <NotNite> filling stuff with As is pretty common with exploit development because you can look for crashes with 0x41414141
[20:15:38] <NotNite> but unsure if related
[20:15:46] <negril> that is good-large_compressed.lzma file is not used anyware and just pure rubbish
[20:15:50] <tolto> true, and same
[20:15:53] <nomadgeek> tolto: I guess so. I just found it cheeky to use 'A' re NotNite above.
[20:16:01] <tolto> lol
[20:16:54] <levitating> nomadgeek: what file? the one the .o is extracted from is actually just in segments
[20:17:01] *** Quits: Guest96 (~Guest68@142.147.89.219) (Quit: Client closed)
[20:17:05] *** Joins: busch (~busch@mail.datenschleuder.com)
[20:17:09] <levitating> and A is commonly used for padding and stuff, first letter in ASCII
[20:17:16] <levitating> everybody knows its hex
[20:17:23] <levitating> 0x41
[20:17:45] <nomadgeek> levitating: I guess I've really seen it in context of exploits. Didn't really consider that it's used more widely.
[20:18:11] <xcvb> A is common because that's what a bunch of \x00 encode to in base64
[20:18:59] <levitating> ah makes sense
[20:19:15] *** Quits: curious1 (~curious1@d-69-161-122-134.nh.cpe.atlanticbb.net) (Remote host closed the connection)
[20:19:19] <tolto> > In the last step the deciphered data is decompressed (xz -F raw --lzma1 -dc) and the resulting Stage 2 is promptly executed.
[20:19:28] <tolto> lol. so the stage is decompressed using xz. how ironic
[20:19:37] <levitating> I thought that was ironic as well
[20:20:07] <nomadgeek> we discussed that interesting bootstrapping earlier.
[20:20:20] *** Joins: grd (~grd@84-112-217-88.cable.dynamic.surfer.at)
[20:20:25] <DasBrain> Hey, what tool is on a machine if the backdoor is delivered thorugh xz? Right! xz.
[20:20:27] <xcvb> not much irony there, a testsuite would also exercise an xz
[20:20:31] <susi> why is it ironic or interesting?
[20:20:36] <ryzenda> brlin, haha that xkcd practically illustrates the situation, https://xkcd.com/2347/ 
[20:20:38] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[20:20:54] <levitating> nomadgeek: did you also see that 5.6.1 leaves room for 1 or 2 additional test files to eval
[20:21:12] <nomadgeek> ryzenda: yeah, 2347 is pretty famous, though this is one of the most severe examples.
[20:21:25] <DasBrain> levitating: I am more convinced that we build our stuff on top of a card house.
[20:21:40] <levitating> one of those extremely accurate ones, I also think often of 927
[20:21:44] <JAA> https://teh.entar.net/@ckape/112182452162916476/embed
[20:22:09] <nomadgeek> levitating: not specifically - I'm not a particularly skilled RE so I'm leaving that to the folks that are.
[20:22:58] <nomadgeek> JAA: 😆
[20:23:15] <DasBrain> 927: Standards
[20:23:17] <kawys> https://twitter.com/1nternaut/status/1774160687473815613
[20:23:52] <tolto> huh, in japanese
[20:24:09] <ryzenda> neko2, lol, the clickhouse domain, that specific one is for -> "SELECT * FROM github_events WHERE actor_login='JiaT75' ORDER BY file_time DESC" and the main home page https://play.clickhouse.com/ you can paste that string yourself to query the same results 
[20:24:11] <nomadgeek> Time for me to pop out for a bit. I'll check back later.
[20:24:18] <tolto> i thought he was "chinese". and "cheong" is usually korean
[20:24:18] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Remote host closed the connection)
[20:24:37] *** Joins: hlein (~hlein@ec2-3-81-87-64.compute-1.amazonaws.com)
[20:24:42] <kawys> i don't know
[20:25:10] *** Quits: Guest47 (~Guest47@185.160.20.244) (Quit: Client closed)
[20:25:24] <kawys> his following list isn't useful either
[20:26:04] <supakeen> gia or jia is also a japanse name but there's so much that can be speculated on
[20:26:10] <InPhase> tolto: Cantonese also, which aligns plausibly with a Singapore VPS having been used to connect.
[20:26:20] <tolto> ah
[20:26:39] <InPhase> tolto: Which does not imply he was in Singapore.
[20:26:48] <rurapenthe> Is the signed payload using a specifically identifiable signature or header or something one can detect?
[20:27:09] <Rounin> I thought maybe Hong Kong... They could totally mix Mandarin and Cantonese
[20:27:12] *** Joins: Guest61 (~Guest61@nmal-25-b2-v4wan-166401-cust115.vm24.cable.virginm.net)
[20:27:19] <Rounin> But it could all be a made up name; who knows
[20:27:22] <tolto> i mean most likely it's not a real name
[20:27:26] *** Guest61 is now known as k__
[20:27:34] <Rounin> And here we are overanalyzing it, haha
[20:28:32] <tolto> "Jigar Kumar" it rhymes
[20:28:45] <neko2> ryzenda: I figured that out later but that URL definitely looked sus at the time
[20:28:45] <tolto> "Hans Jansen" sounds like John Doe but in danish or swedish
[20:28:51] *** Joins: wehttam (~wehttam@1.146.120.30)
[20:29:01] <Manis> Hans is German.
[20:29:02] <Noisytoot> "Cheong" begins with a C and Hans Reiser wrote C. Coincidence?!?!
[20:29:11] <tolto> lol
[20:29:16] <Manis> Noisytoot, I think you're on to something XDD
[20:29:28] <tolto> Manis: but is "Jansen" german?
[20:29:40] <Manis> Nope, tolto, I'd say Danish.
[20:29:44] <tolto> yeah same
[20:29:48] <Manis> what?
[20:29:52] <tolto> so they mixed a german first name with a scandinavian surname
[20:29:55] <Yogurt> people also name their kids whatever
[20:29:56] <tolto> i also think the same
[20:30:01] <Steffanx> Jansen is a common dutch name too. So is Hans. 
[20:30:12] <Manis> Possibly a Danish family moved to Germany and gave their kids German names.
[20:30:13] <levitating> susi: it's ironic because one of the payloads is decompressed, resegmented, translated then decompressed again. so at that point its just using xz to obfuscate itself 
[20:30:14] <tolto> okay, well, i'm indeed overanalyzing by this point
[20:30:25] <Rounin> Lots of Scandinavians are called Hans... Though it sounds a tad German, to be sure
[20:30:26] <Manis> Steffanx, oh, didn't know that.
[20:30:26] <carbon_dioxide> yeah Hans Jansen could be a Dutch John Doe
[20:30:40] <gromit> it is: https://youtu.be/IfhMILe8C84?si=V8XoPAvyUnng9vgs&t=113
[20:30:56] <JAA> Jansen isn't uncommon in German.
[20:31:02] <levitating> hey gromit!
[20:31:15] <JAA> But the German John Doe would normally be Max Mustermann.
[20:31:17] <gromit> ^ "Prank interview with Elijah Wood" the fake name the interviewer has given themselves is "Hans Jansen" :p
[20:31:30] <ryzenda> sam_ "i should've grabbed them earlier :/" I saw this site mentioned earlier, here's the tags page https://git.rootprojects.org/root/xz/tags I dunno if this is the same that you mentioned, but if it is, toto_ and tolto mentioned earlier that the site that apparently has the malicious commits
[20:31:47] *** Joins: pmk (6afe4476a1@2a03:6000:1812:100::26d)
[20:31:48] <levitating> gromit: is is that progress on splitting the repo server
[20:32:01] <levitating> s/is/how/
[20:32:08] *** Joins: Guest47 (~Guest47@185.160.20.244)
[20:32:11] <tolto> ryzenda: oh true, it has the beta and alpha as well
[20:32:20] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[20:32:34] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[20:32:35] <neko2> urgh I should sleep rather than trying to keep watching this, I'm sure I can catch up on developments tomorrow morning
[20:32:40] <ryzenda> FireFly, "should've grabbed the tarballs earlier too, ahwell" o/ same as I said above
[20:33:07] <JAA> The tarballs are all archived.
[20:33:07] <neko2> someone yell at me to go sleep
[20:33:08] <Noisytoot> ryzenda: are you sure that those are the real release tarballs and not generated by gitea?
[20:33:24] <JAA> https://web.archive.org/web/*/https://github.com/tukaani-project/xz/releases/download/*
[20:33:30] <wolf> neko2: you should really go to sleep!
[20:33:39] <sam_> i'm currently compiling them into a git repo for my own sake
[20:34:00] <tolto> JAA: not all of them are archived. at least the beta and alpha aren't
[20:34:02] <rurapenthe> neko2, espresso is calling :)
[20:34:21] *** Quits: neko2 (~nekosquar@user/deltasquared) (Quit: yells at self: GO TO SLEEP b*tch)
[20:34:27] <FH_thecat> https://gynvael.coldwind.pl/?lang=en&id=782
[20:34:28] <StefanCristian> lol
[20:34:32] <rurapenthe> Guess thats a no lol
[20:34:39] <StefanCristian> rurapenthe: about espresso, there's something else to be talked about
[20:34:52] *** Joins: Arwo34 (~Arwo34@77-164-154-185.fixed.kpn.net)
[20:35:02] <JAA> tolto: Those are all 'assets' that were available on the release page as of a bit under 24 hours ago.
[20:35:12] <rurapenthe> StefanCristian, ?
[20:35:14] <JAA> GitHub release page*
[20:35:19] <Celelibi> mvxdg4hf, sneaky period?
[20:35:25] <StefanCristian> I'm going to offer my opinion about a different topic. Larhzu. right now he needs MORAL and emotional support. he needs to know that community is here for him
[20:35:35] <tolto> ah
[20:35:36] <StefanCristian> it doesn't matter who the malicious actor was, or what happened
[20:35:44] <StefanCristian> it's about *WE* supporting Larhzu
[20:35:51] <StefanCristian> he's in a extremely difficult moment
[20:36:04] <StefanCristian> 15 years of work, hobby, work, and again
[20:36:09] <StefanCristian> and then, this shit happens
[20:36:11] <tolto> yeah, hope he's ok
[20:36:16] *** Quits: adelgado (~adelgado@85-23-76-3.bb.dnainternet.fi) (Remote host closed the connection)
[20:36:17] <StefanCristian> community, without any doubts, is here for him
[20:36:25] <StefanCristian> we need to have his back no matter what
[20:36:35] <tolto> i bet he feels tricked by jiatan
[20:36:37] <StefanCristian> whoever talks about the lack of security of everything, these things happen
[20:36:45] <Steffanx> Best support you can give him is support in maintaining the project.
[20:36:48] <StefanCristian> yes, tolto, he's been tricked most probably. but who else wouldn't?
[20:36:54] <tolto> so hopefully he doesn't take it personally
[20:36:55] *** Quits: Noisytoot (~noisytoot@sourcehut/user/noisytoot) (Remote host closed the connection)
[20:37:01] <tolto> StefanCristian: indeed
[20:37:08] <StefanCristian> I hope he understands community, we are here for Larhzu
[20:37:13] <StefanCristian> this is the most important fact
[20:37:22] *** Joins: Noisytoot (~noisytoot@sourcehut/user/noisytoot)
[20:37:26] <rurapenthe> I second that. Not to mention that his work is in use in many many places many of which are making people a lot of money, powering important systems and so forth. His contribution has been invaluable. 
[20:37:37] <StefanCristian> we must support him, understand him, push him on the stable ground
[20:37:45] <StefanCristian> this is beyond what a human being can take right now
[20:37:51] <StefanCristian> normal people are shattered
[20:37:59] <StefanCristian> as I am
[20:38:03] *** Joins: Guest75 (~Guest75@188.116.27.70)
[20:38:03] <wb9688> tolto: Jansen is a pretty common Dutch last name, while Hans is also a common first name in Dutch
[20:38:08] <StefanCristian> (shattered, not normal. I can't consider myself normal)
[20:38:12] <levitating> StefanCristian: you're spamming the channel
[20:38:21] <tolto> i was also impacted by trauma... still can't fully recover from it
[20:38:33] <wb9688> Oh, others already mentioned that
[20:38:43] <tolto> wb9688: ah
[20:38:53] <DPA> Is it known yet what keys would have been allowed access? Have the been isolated yet?
[20:38:56] <Rounin> He was talking here earlier, and I think everyone was nice..? Everyone is obsessing a bit over what happened, but there's no malice anywhere that I can see
[20:39:01] <StefanCristian> levitating: thank you for noting that, I'll stop
[20:39:07] <levitating> np
[20:39:11] <JAA> sam_, tolto: Oh, sorry, I checked again, and it turns out that my archive is *not* in the Wayback Machine yet. The v5.5.2beta and v5.5.1alpha tarballs were archived at about 2024-03-29 21:54 UTC.
[20:39:25] <tolto> JAA: i see
[20:39:27] <JAA> They will eventually appear there as the data makes its way through the systems.
[20:39:29] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[20:39:34] <StefanCristian> levitating: though, would you not agree with what I said? :)
[20:39:55] <levitating> JAA: I was able to retrieve archived tarballs just by browsing it
[20:40:41] *** Parts: GravyP (~GravyP@197.153.79.137) ()
[20:40:41] <JAA> levitating: Not the ones of those two versions at least.
[20:40:51] <levitating> StefanCristian: Of course, this is in no way his fault. This is a big warning for the whole FOSS community. 
[20:41:12] <StefanCristian> levitating: nono, i mean the moral support.
[20:41:13] *** Quits: KGB (KGB@irc.chroot.pl) (Ping timeout: 246 seconds)
[20:41:25] <levitating> JAA: Oh yes correct, but they are not infected are they? Well I guess we need the archives to be sure
[20:41:29] <tolto> i think there was also another sockpuppet identity of a slavic person
[20:41:34] <tolto> does anyone remember what it was?
[20:41:45] *** Joins: smpl (~smpl@user/smpl)
[20:41:59] <gromit> levitating: if you wanna chat about arch stuff do it in the arch channel ;)
[20:42:18] <levitating> gromit: of course, I am just excited to see familiar faces :)
[20:42:55] *** Joins: KGB (KGB@irc.chroot.pl)
[20:44:07] *** Joins: r2rien (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr)
[20:44:18] *** Quits: Guest98 (~Guest60@190-205-178-192.dyn.dsl.cantv.net) (Quit: Client closed)
[20:44:46] <ryzenda> Guest80, "if something like this is able to slip in, ...... [no] project should be using such projects" also see https://xkcd.com/2347/ 
[20:45:05] *** Quits: lpt (~lpt@host-87-16-54-137.retail.telecomitalia.it) (Quit: Leaving)
[20:45:31] *** Quits: zoneroyadmin20 (~zoneroyad@178-251-151-7.ftth.kajonet.fi) (Ping timeout: 250 seconds)
[20:46:10] *** Joins: agl (~agl@user/agl)
[20:46:51] *** Joins: Vaporeon (~vaporeon@vaporeon.io)
[20:47:06] *** Quits: Guest75 (~Guest75@188.116.27.70) (Quit: Ping timeout (120 seconds))
[20:47:18] *** Joins: CipherLab (~NSA@2a03:1b20:4:f011::3e)
[20:49:17] <Rounin> There's a counterpoint to the "single point of failure" argument too, in that there's only one point to repair
[20:50:16] *** Parts: Arwo34 (~Arwo34@77-164-154-185.fixed.kpn.net) ()
[20:50:21] *** Joins: Square2 (~Square@user/square)
[20:50:21] *** Joins: kennethm (~kennethm@193.90.196.121)
[20:50:24] <Bl3nd3r> How can I delete XZ Utils
[20:50:29] <JAA> sam_, tolto: I can't say when the missing tarballs will be available (I'm not affiliated with the Internet Archive), but I would expect it to happen within the next few hours.
[20:50:44] <tolto> alright
[20:51:04] <negril> JAA: https://snapshot.debian.org/package/xz-utils/
[20:51:35] *** Quits: Guestasldfjalshg (~Guestasld@104.36.71.200.16clouds.com) (Ping timeout: 250 seconds)
[20:51:39] *** Quits: Guest52 (~Guest36@179.214.112.141) (Quit: Client closed)
[20:52:19] <Rounin> Bl3nd3r: It can probably be done either using your package manager or with rm, but it might break a lot of things on your system. Many things depend on it.
[20:52:27] *** Quits: blingbling96 (~blingblin@89.125.87.194) (Ping timeout: 250 seconds)
[20:52:36] <JAA> negril: Doesn't have all of them.
[20:52:56] <Rounin> Bl3nd3r: The safest for now might be to check that you have an older version of xz (5.4 and not 5.6), and downgrade if you have to.
[20:53:07] <JAA> negril: It only has the .tar.xz ones, not the .tar.gz, for example.
[20:53:14] <JAA> At least for the version I just checked.
[20:53:15] <Bl3nd3r> thx Rounin
[20:53:53] <agl> Bl3nd3r: less than 5.4.6
[20:53:57] <Noisytoot> If you are affected, removing xz will almost certainly break things (systemd links to liblzma)
[20:54:16] <tolto> JAA: so wait, did you submit the tarballs you had to the internet archive? how can they verify that that the tarballs you supplied are original?
[20:54:40] <sam_> you should be able to compare with the manifest in gentoo
[20:54:44] <sam_> via git history
[20:54:57] *** Joins: Raqbit (~Raqbit@user/raqbit)
[20:54:58] <tolto> hmm
[20:55:04] <sam_> in app-arch/xz-utils/Manifest
[20:55:21] <tolto> i never actually thought that internet archive data could be tampered
[20:55:29] <tolto> still not sure if that's possible at all
[20:55:34] <abby> anyone can upload anything
[20:55:38] *** Joins: ZLima12 (~zlima12@user/ZLima12)
[20:55:38] <tolto> uhm, more specifically, the wayback machine
[20:56:22] <ZLima12> Who else joined after reading https://boehs.org/node/everything-i-know-about-the-xz-backdoor ?
[20:56:28] <JAA> Regular users can't put data into the Wayback Machine precisely because of that issue.
[20:56:38] <tolto> JAA: are you a regular user?
[20:56:48] <JAA> No
[20:57:13] <JAA> I'm part of a group of archivists who are closely collaborating with IA to make our data available.
[20:57:33] <tolto> ohh ok
[20:57:39] <tolto> that explains it then
[20:58:08] <sinbad> Did the payload change between various compromised xz source tarballs, I wonder.
[20:58:09] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[20:58:14] <tolto> ah so yes, "krygorin4545" sounds like a random slavic surname. and that repeating "4545", sus
[20:58:15] <nomadgeek> What'd I miss?
[20:58:28] <negril> sinbad: 5.6.0 to 5.6.1 had changes
[20:58:49] <tolto> nothing much, nomadgeek. JAA is going to upload the missing tarballs to IA
[20:59:13] <ryzenda> kawys (they left) mentioned  https://twitter.com/1nternaut/status/1774160687473815613 @jiat75107 on twitter, no activity though
[20:59:37] *** Parts: bjorn3 (~bjorn3@2a02-a45d-df1e-1-815b-701b-2f4e-ee9a.fixed6.kpn.net) ()
[21:00:05] <sinbad> negril: I am talking about the binary blob injected into the release tar balls.
[21:00:16] <negril> so am i
[21:00:33] *** Quits: UltraBloxX (~UltraBlox@95.165.170.131) (Quit: Client closed)
[21:00:35] *** Quits: Fingel (~Fingel@user/fingel) (Quit: Fingel)
[21:00:40] <sinbad> I see. So they corrected something
[21:00:47] <negril> yes
[21:01:07] *** Quits: bret (~bret@user/bret) (Remote host closed the connection)
[21:01:12] <negril> not in the release tarballs though, the two relevant testfiles are in the git repo
[21:01:26] *** Joins: jemb (~jemb@2a02-a45f-3f35-0-559e-6036-60a0-89e6.fixed6.kpn.net)
[21:01:41] <negril> the release tar balls only added build-to-host.m4 that triggered the extraction
[21:02:15] *** Quits: andibmu (~andi@dslb-094-216-251-046.094.216.pools.vodafone-ip.de) (Ping timeout: 256 seconds)
[21:02:19] <ryzenda> Noisytoot, I'm not sure, I'm just catching up what I missed while sleeping, and repeating some of the things I learned before I fell asleep for anyone that seems unsure, and sharing a few other interesting things too. 
[21:02:31] *** Parts: jemb (~jemb@2a02-a45f-3f35-0-559e-6036-60a0-89e6.fixed6.kpn.net) ()
[21:03:15] *** Joins: bret (~bret@user/bret)
[21:03:26] <ryzenda> maybe they are simply generated by gitea
[21:03:29] *** Joins: xxpor (~skooz@user/xxpor)
[21:03:33] *** Quits: laanwj2 (~laanwj2@2a10:3781:26a2:fc:fc4a:8f47:7697:631c) (Quit: Client closed)
[21:03:35] <ryzenda> lol I'm already falling asleep again too
[21:03:59] * jess tucks ryzenda in
[21:04:26] <ryzenda> k, all caught up, haha thanks
[21:04:30] <tolto> looks like Jiatan's backdoors caused some real ifunc-related bugs in GCC to be fixed: https://bugs.gentoo.org/925415 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
[21:04:35] <sinbad> negril: right. my point these changes happened  before the accidental discovery. they must have got some experimental  feedback and made corrections 
[21:04:39] <Steffanx> ryzenda lol. The only like by that account 😬😬😬
[21:04:52] <Steffanx> Must be a secret message 
[21:05:06] <ryzenda> Steffanx, lol I didn't even check that, but I see it now, haha
[21:05:23] <sam_> tolto: yes, this is something i've been trying to tell people
[21:05:26] <Noisytoot> Is/was tukaani.org running a backdoored version of xz? Is it possible that Jia Tan gained access to it using the backdoor?
[21:05:37] <sam_> tolto: unfortunately my name is in one of the commits in the original oss-security post, but the change there is genuinely right
[21:05:44] <nomadgeek> build-to-host.m4 -> extracts payload from test files -> hooks to RSA calls -> if the incoming key is a signed payload then -> shell code.
[21:05:45] <tolto> hmm
[21:05:52] <negril> sinbad: see the message above yours
[21:05:57] <sam_>  tolto: (which is why the gcc bug remains open and it has a patch pending, even)
[21:05:58] *** Joins: bauen1 (~bauen1|@ppp-212-114-180-66.dynamic.mnet-online.de)
[21:06:08] <negril> Noisytoot: no
[21:06:09] <tolto> nice
[21:06:32] <levitating> sam_: that's kind of sus sam_
[21:06:33] <negril> Noisytoot: this was either social engineering or someone got to Jia Tan
[21:06:38] <sam_> thanks levitating 
[21:06:57] *** Joins: atuk10 (~atuk10@124.170.233.88)
[21:07:02] *** Quits: TheAifam5 (~Thunderbi@user/TheAifam5) (Quit: See yaa)
[21:07:13] <linuxdaemon> evening folks, any updates since the morning? 
[21:07:42] <nomadgeek> Did you just join, linuxdaemon?
[21:07:53] <nomadgeek> (or can you see my little flow chart from a minute ago)
[21:08:10] <linuxdaemon> been around since the morning haha
[21:08:19] <sinbad> negril: oops, thanks.
[21:08:50] <nomadgeek> linuxdaemon: My little flowchart is pretty much the update we have at this point. Looks like the payload was an RCE implementation to allow a delivered payload to be executed.
[21:09:06] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[21:09:19] *** Quits: Bl3nd3r (~Bl3nd3r@185.107.56.47) (Remote host closed the connection)
[21:09:50] <negril> nomadgeek: https://gynvael.coldwind.pl/?lang=en&id=782 this might be interesting
[21:09:51] <linuxdaemon> oo fun, and the scope hasn't expanded?
[21:11:02] <negril> nope
[21:11:19] *** Quits: linuxdaemon (linuxdemon@bnc.linuxdemon.xyz) (Changing host)
[21:11:19] *** Joins: linuxdaemon (linuxdemon@user/linuxdaemon)
[21:12:16] <nomadgeek> negril: I read through that. The explicit steps in the process are fascinating. Just trying to keep the summary boiled down. The fact that they made a way to add new test files to be executed without having to modify the execution once it was installed...
[21:12:17] <tolto> Jia Cheong Tan <jiat0218@gmail.com> Jia Tan <jiat75@gmail.com>
[21:12:26] <tolto> also funny how jiatan had two emails, both on gmail
[21:12:34] <tolto> and always those numbers are the end
[21:12:38] <ZLima12> So many people are going to be trying to track this guy down now
[21:12:43] <tolto> with "krygorin" (sounds like Grigory), "misoeater"
[21:12:49] <tolto> even hansjansen had numbers at the end
[21:12:51] <negril> tolto: some people weren't around in the early 2000s to reserve the names without digits
[21:13:05] <tolto> negril: yeah but it's more of the pattern of fake names that i find funny
[21:13:18] <linuxdaemon> will be interesting to see how this shakes out, can't wait for inevitable talks at conferences in a few months haha
[21:13:19] <negril> it's fairly standard and suggested by gmail when you register
[21:13:31] <tolto> well, true i guess
[21:14:35] <xcvb> "Stop being poor and get your own domain" :p
[21:14:39] <Guest12> tbh if this exact thing was the script of a movie I would call it bullshit so fast
[21:14:40] <rurapenthe> Both those email addresses aren't in haveibeenpwned - so they weren't used very much (Considering how many leaks are out there)
[21:14:52] <tolto> > Windows 11 22H2 22621.3007 may contain Jia Tan code
[21:14:53] <negril> nomadgeek: not really surprising though
[21:14:54] <tolto> oh bummer lol
[21:15:08] <negril> tolto: yeah the libarchive changes that are not relevant
[21:15:15] <tolto> rurapenthe: apparently a twitter account is registered to at least one of them
[21:17:11] <susi> tolto: how so
[21:17:36] <tolto> someone did "forgot your password" on them
[21:17:41] <nomadgeek> rurapenthe: interesting that we're using HIBP as a litmus test for how long an address has been around / used now.😆
[21:18:01] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Ping timeout: 250 seconds)
[21:18:06] <nomadgeek> That's a statement on the state of the internet nowadays if I ever heard one.
[21:18:32] <susi> but how could this someone tell, that jixxxxxx@gmail.com is jiat0218 , even if the number of letters matches
[21:18:54] <rurapenthe> nomadgeek, I'm using it more to see if its had "personal" activity. Almost all of us here are prob listed in there. But if your job is covert operations of some kind you generally didn't go signing up to all-and-sundry with the account you had specific reasons for having?
[21:18:55] <tolto> not sure, i assumed twitter just tells you. no idea
[21:19:31] *** Parts: wolf (~wolf@ircpuzzles/staff/wolf) (SIGHUP)
[21:19:56] <konimex> susi: maybe they try it one by one, jiat0000, jiat0001, until 0218
[21:20:37] <xcvb> bday on Feb 18?
[21:21:19] <Guest12> even if all this info leads to a real person it still means nothing
[21:21:25] <mroszko> susi because twitter is fucking stupid
[21:21:31] <mroszko> if you enter a valid email to password reset
[21:21:38] <mroszko> the send page after confirming you want to reset
[21:21:42] <mroszko> shows your account username
[21:21:45] <nomadgeek> I have a hard time believeing that the perp here would use their legit birthday in their username if they were setting up a persona.
[21:21:57] <mroszko> the second page after confirming*
[21:22:08] <rurapenthe> Of course, there's also the possibility this was a legitimate person. Who was compromised, turned or ... worse.
[21:22:26] <abby> reminder that this is not the place to dox anyone
[21:22:28] <susi> tolto: what is this 22H2 thingie
[21:22:56] <tolto> susi: from here https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006612#gistcomment-5006612
[21:22:57] <peb> looks like a windows update?
[21:23:00] <peb> susi: ^
[21:23:13] *** Quits: Guest76 (~Guest76@159.148.172.3) (Ping timeout: 250 seconds)
[21:23:22] <nomadgeek> That's posible, though their interactions with the project(s) make me question that. Unless the attacker made some of these changes and the legit user just didn't notice these random commits 'he' made while he was sleeping.
[21:23:56] <Guest12> to me it seems like ill intent was there from day 1 :)
[21:24:01] <nomadgeek> That's one heck of a compromise if that's what's going on here. 
[21:24:11] <nomadgeek> Guest12: that's my take too
[21:24:36] *** Joins: nozaq (nozaq@user/nozaq)
[21:24:44] <nomadgeek> Specially because, afaict, we haven't heard from them in the now over 24 hours since this broke.
[21:24:50] *** Joins: ciro (~ciro@user/ciro)
[21:25:13] *** Parts: fuxino (~fuxino@user/fuxino) ()
[21:25:39] *** Quits: wehttam (~wehttam@1.146.120.30) (Read error: Connection reset by peer)
[21:26:01] <susi> Guest12: so what happened @ day 0? :o
[21:26:37] <xx> sam_: is the gist up to date? I don't want to read the whole backlog. Also the alternative to `ldd` that you may have been thinking about was `lddtree` from https://wiki.gentoo.org/wiki/Hardened/PaX_Utilities
[21:26:44] <sam_> it is up to date 
[21:26:48] <sam_> xx: you don't have to tell me about lddtree ;)
[21:26:57] <negril> tell me about lddtree.py!
[21:27:00] <sam_> xx: what i was looking for was a ML post about ldd vs lddtree
[21:27:01] <negril> nomadgeek: people can also be coerced into doing things
[21:27:03] <sam_> but someone found it for me
[21:27:33] *** Quits: Guest6 (~Guest6@071-010-183-017.res.spectrum.com) (Ping timeout: 250 seconds)
[21:27:53] <nomadgeek> negril: absolutely posible. I guess I should say that it isn't my (or our) job to persecute anyone. I'm sure the fed (of various countries) are working on that.
[21:29:03] *** Joins: Guest94 (~Guest94@p200300fe170e3404a90d150182af0c4d.dip0.t-ipconnect.de)
[21:29:03] *** Joins: TrevorH (~trevor@centos/qa/trevorh)
[21:30:53] <xx> sam_: I see, I didn't know it's the same sam
[21:31:05] <sam_> the very same sam as thesamesam as gentoo sam 
[21:31:11] <Habbie> lol
[21:31:19] <abby> toucan sam?
[21:31:31] <nomadgeek> "thesamesam" - appropriate. 
[21:31:35] <negril> What happened to the other sam?
[21:31:44] <susi> they were replaced
[21:31:57] <susi> we are still investigating it further
[21:32:18] <nomadgeek> negril: It's an Agent situation from the Matrix
[21:32:19] *** Quits: k__ (~Guest61@nmal-25-b2-v4wan-166401-cust115.vm24.cable.virginm.net) (Ping timeout: 246 seconds)
[21:32:32] <negril> I knew it!
[21:34:34] *** Joins: lychee (~lychee@2601:483:4500:2b79:d070:843f:dfd0:ad2)
[21:35:06] <lychee> hiya
[21:35:36] <tolto> hi
[21:35:43] <nomadgeek> 👋
[21:35:48] <abby> sam_: ouch https://gitweb.gentoo.org/repo/gentoo.git/tree/app-arch/xz-utils/xz-utils-5.4.6-r1.ebuild#n4
[21:37:05] *** Quits: ungato (~ungato@ip70-181-175-24.sd.sd.cox.net) (Ping timeout: 250 seconds)
[21:37:32] *** Quits: lychee (~lychee@2601:483:4500:2b79:d070:843f:dfd0:ad2) (Client Quit)
[21:37:57] *** Quits: meson800 (~meson800@18.10.138.247) (Ping timeout: 250 seconds)
[21:39:15] *** Quits: breakgimme (~breakgimm@user/breakgimme) (Ping timeout: 250 seconds)
[21:41:07] *** Joins: Guest78 (~Guest78@2a02:8010:6650:2::2)
[21:41:37] *** Joins: ori_ (~ori@wikimedia/ATDT)
[21:41:44] *** Quits: ori_ (~ori@wikimedia/ATDT) (Client Quit)
[21:42:49] *** Joins: ori_ (~ori@wikimedia/ATDT)
[21:42:53] *** Quits: ori_ (~ori@wikimedia/ATDT) (Client Quit)
[21:43:04] *** Joins: ori_ (~ori@wikimedia/ATDT)
[21:43:12] *** Quits: ori_ (~ori@wikimedia/ATDT) (Client Quit)
[21:45:52] *** Joins: ori_ (~ori@wikimedia/ATDT)
[21:47:08] *** Quits: Guest78 (~Guest78@2a02:8010:6650:2::2) (Quit: Client closed)
[21:47:40] *** Joins: dittoid (~dittoid@5.151.23.131)
[21:48:07] *** Quits: kennethm (~kennethm@193.90.196.121) (Quit: Client closed)
[21:48:31] *** Joins: phishing_pharao (~phishing_@ip-037-201-116-138.um10.pools.vodafone-ip.de)
[21:48:57] *** Quits: mvxdg4hf (~mvxdg4hf@ip-037-201-116-138.um10.pools.vodafone-ip.de) (Quit: Client closed)
[21:49:22] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[21:49:22] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Remote host closed the connection)
[21:49:25] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[21:49:31] *** Joins: kawys (~kawys@public-gprs652329.centertel.pl)
[21:49:35] *** Quits: carbon_dioxide (~CO2@ankh-morpork-clacks-tower.connected.by.freedominter.net) (Remote host closed the connection)
[21:49:51] *** Quits: Guest17 (~Guest17@174.30.40.113) (Quit: Client closed)
[21:50:12] <dittoid> big oof
[21:50:18] <sam_> :)
[21:51:01] *** Quits: rurapenthe (~None@102.132.133.163) (Quit: This computer has gone to sleep)
[21:51:11] <Manis> the cyclic dependency is running autogen.sh before configuring?
[21:51:17] <sam_> yeah
[21:51:25] <bauen1> abby: autotools has so many self-dependencies and version incompatibilities, it's not even funny: https://github.com/fosslinux/live-bootstrap/tree/master/steps
[21:51:33] *** Quits: Guest60 (~Guest60@dsl-hkibng42-56733b-157.dhcp.inet.fi) (Quit: Client closed)
[21:51:43] <abby> i'm aware :)
[21:51:54] <Manis> It's good old Unix. A collection of scripts which magially works :-)
[21:52:08] <Manis> The version incompatibilities are really annoying, tough, I agree.
[21:52:34] *** Joins: ZenWalker (~r00t@47.pool85-56-150.dynamic.orange.es)
[21:52:48] <DasBrain> Build tools are black magic for me.
[21:52:50] *** Quits: rigid (~rigid@user/rigid) (Quit: +++ATH NO CARRIER)
[21:52:55] *** Joins: aaceac (~aaceac@2a00:23c5:9ba2:c300:9ac9:5601:ebcb:c900)
[21:52:59] <Square2> Not often you see 20 GuestXYZ accounts idling in a channel
[21:53:29] <Manis> I don't know however if they cannot have a stable API because of technological reasons or just because it's a GNU project.
[21:53:41] *** Joins: rigid (~rigid@user/rigid)
[21:53:50] *** Quits: bertronika (~nejc@user/nejc) (Ping timeout: 264 seconds)
[21:53:53] <aaceac> is 5.4 known to be safe yet?
[21:54:07] <Manis> no, nothing is ever known to be safe.
[21:54:20] *** Quits: Guest50 (~Guest50@n7226t9c5wh20wtp1h2-1.v6.elisa-mobile.fi) (Quit: Client closed)
[21:54:23] <aaceac> with respect to Jia's commits
[21:54:25] *** Quits: Guest94 (~Guest94@p200300fe170e3404a90d150182af0c4d.dip0.t-ipconnect.de) (Ping timeout: 250 seconds)
[21:54:36] <Rounin> Someone mentioned earlier that 5.4.6 is not safe, but before that it should at least not have the known exploit
[21:54:46] <aaceac> im on 5.4.1
[21:54:53] <sam_> i don't think 5.4.6 is known bad
[21:54:54] <Rounin> Should be fine.. ish
[21:54:55] <Manis> not safe in that it was released by Jia?
[21:54:56] <sam_> it's just not known good
[21:54:58] <sam_> right
[21:55:01] *** Joins: rurapenthe (~None@102.132.133.163)
[21:55:03] <aaceac> Manis, yes...
[21:55:25] <xcvb> as said on the mailing list: "probably" fine
[21:55:29] *** Joins: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6)
[21:55:37] <negril> Build from the git tags not from the release tar balls
[21:55:43] <aaceac> xcvb, im not on the mailing list - thought id ask here
[21:55:43] *** Quits: pera (~pera@user/pera) (Quit: leaving)
[21:56:05] <xcvb> right, .. said on *a* mailing list. Anyway, I had to chuckle at '"probably"'
[21:56:37] <aaceac> lol
[21:56:58] <aaceac> grim situation, the security.md message was spooky
[21:57:04] <xcvb> it's so true (universe is a lot about stochastics) yet so vague
[21:57:11] <abby> not really
[21:57:22] <abby> Larhzu approved of the security.md change
[21:57:27] <amdj> Line 4: Remember, we cannot leverage autotools
[21:57:32] <amdj> Line 18: inherit autotools
[21:57:35] <amdj> ( ≖‿≖)
[21:57:39] <sam_> it's only for the live ebuild :p
[21:57:42] <dittoid> I finally feel vindicated for always putting off software updates
[21:57:56] <xcvb> dittoid: "37% rule" applies, as usual
[21:58:12] <aaceac> abby, if Jia is nation state then reporting knowledge of the backdoor privately would have been risky
[21:58:16] <Manis> xcvb 37% rule?
[21:58:27] <xcvb> google it :D
[21:58:29] *** Quits: syu (~syu@user/syu) (Quit: WeeChat 4.2.1)
[21:58:33] <abby> aaceac: it's standard practice...
[21:58:43] <aaceac> sure, but the timing is spooky
[21:58:53] *** Joins: syu (~syu@user/syu)
[21:59:17] <Rounin> If you can just pick something from a selection once and not change your pick, you should sample 1/e of it first, which is about 37%
[21:59:24] <Fresh_Meat> wires
[21:59:28] <Rounin> To have the highest chance of satisfaction
[21:59:32] *** Parts: dittoid (~dittoid@5.151.23.131) ()
[21:59:46] *** Joins: G3 (~G3@51.252.174.39)
[21:59:46] <Rounin> Hahahaha, we scared him away
[21:59:51] *** Joins: Guest94 (~Guest94@p200300fe170e3404a90d150182af0c4d.dip0.t-ipconnect.de)
[22:00:03] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[22:00:13] <aaceac> xcvb, do i update after 37% of users?
[22:00:17] *** G3 is now known as fOSSUser
[22:00:20] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[22:00:31] *** Joins: Guest53 (~Guest53@194.127.199.84)
[22:00:32] *** Quits: Guest94 (~Guest94@p200300fe170e3404a90d150182af0c4d.dip0.t-ipconnect.de) (Client Quit)
[22:00:40] <xcvb> I guess that's my takeaway
[22:00:49] <aaceac> i saw the veritasium video
[22:01:03] <Manis> but how do you know if 37% of users have updated?
[22:01:23] <Rounin> Anonymous survey
[22:01:29] <Manis> 😀
[22:01:35] <aaceac> could ask a mystic or someone
[22:01:44] <sam_> probed via an old backdoor in zstd...
[22:01:54] <xcvb>  /We asked 100 people whether..../
[22:02:15] <aaceac> yes - count the % of users whose sshd you can backdoor
[22:02:26] *** Joins: nomadgee_ (~nomadgeek@047-134-024-163.res.spectrum.com)
[22:02:29] <Manis> fair
[22:02:30] *** Quits: nomadgee_ (~nomadgeek@047-134-024-163.res.spectrum.com) (Client Quit)
[22:02:38] <Rounin> 👏
[22:02:43] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Client Quit)
[22:02:45] <aaceac> hi Rounin 
[22:02:47] *** Parts: sinbad (~sinbad@user/sinbad) ()
[22:02:59] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[22:02:59] <Rounin> Hi there
[22:03:13] *** Joins: Fingel (~Fingel@user/fingel)
[22:03:15] <Manis> TBH it bothers me a bit that xz is getting all the bad publicity now while the exploit only works with the help of glibc, systemd and modified openssh.
[22:03:33] <abby> it doesn't require systemd and modified openssh
[22:03:34] *** Joins: nomadgeek_ (~nomadgeek@047-134-024-163.res.spectrum.com)
[22:03:38] *** Quits: gch981213 (~quassel@2401:c080:1400:4da2:5400:3ff:feb4:7578) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
[22:03:42] <abby> there are other dependency paths
[22:03:59] *** Quits: pajlada (~pajlada@user/pajlada) (Remote host closed the connection)
[22:04:11] *** Quits: nomadgeek_ (~nomadgeek@047-134-024-163.res.spectrum.com) (Client Quit)
[22:04:11] *** Quits: gelx (~gelx@2a02:8071:b84:0:66e1:cde6:a99e:a0ee) (Quit: Client closed)
[22:04:15] *** Joins: gch981213 (~quassel@45.76.163.178)
[22:04:23] *** Quits: bhaible (~bruno@2a02:908:193:6800:3128:ab45:6103:663a) (Ping timeout: 255 seconds)
[22:04:28] <Manis> abby, do you know one?
[22:04:34] <aaceac> maybe there shouldnt be binaries in the source tree and xz wouldnt get bad publicity
[22:04:40] *** Joins: wehttam (~wehttam@1.146.120.30)
[22:04:40] *** Quits: wehttam (~wehttam@1.146.120.30) (Client Quit)
[22:04:45] <marius_zulu7> Did someone find anything indicating it could potentially work under macOS (eventually using brew or macports)?
[22:04:56] <sam_> aaceac: there will be time to discuss what could and should be done better, but test data in the main repo is not uncommon
[22:05:05] *** Joins: alreadydone (~alreadydo@2601:152:300:6266:706e:6030:ffd:4024)
[22:05:13] <Manis> aaceac, xz archives are binaries by definition. Using xz archives to test xz seems fine by me.
[22:05:15] <abby> i believe openssh -> libpam -> libselinux (built with sysd support) -> liblzma is another
[22:05:23] <aaceac> sam_, it should be uncommon but i agree - i still need to update one of my systems
[22:05:29] <sam_> i haven't seen libselinux -> liblzma actually happen 
[22:05:32] <levitating> sam_: From my understanding the big script runs twice? Once as ./configure on line 25655 and once within src/liblzma/Makefile on line 338?
[22:05:33] <sam_> i've looked into it a bit but not seen how
[22:05:53] <abby> marius_zulu7: we don't know for sure yet but nothing has been found now
[22:05:54] <sam_> but i agree it is totally possible via other paths
[22:05:56] <sam_> not trying to argue on that
[22:06:03] <sam_> just mean i'm looking for info on that bit
[22:06:09] *** Joins: davet (sid595516@id-595516.uxbridge.irccloud.com)
[22:06:10] <Manis> me too
[22:06:38] <Manis> If I look through ldd output of my sshd I don't see any path to lzma
[22:06:44] <rurapenthe> marius_zulu7, I did notice brew has pushed an update to revert back to v 5.4
[22:07:09] <bauen1> abby: libpam -> libselinux -> ... -> liblzama ; do you mean libpam loading pam_systemd -> liblzma ? Or does libselinux somehow load liblzma
[22:07:09] <xcvb> Manis: since pam uses dlopen, ldd wouldn't show it
[22:07:22] *** Joins: Guest60 (~Guest60@dsl-hkibng42-56733b-157.dhcp.inet.fi)
[22:07:28] <sam_> levitating: in which version? that line doesnt look relevant to me in configure in 5.6.1
[22:07:31] <aaceac> dont run ldd on xz
[22:07:32] *** Joins: bhaible (~bruno@2a02:908:193:6800:eac9:6ca0:1ba6:4eb6)
[22:07:37] <abby> the theory is that libselinux would link to libsystemd
[22:07:38] <Manis> xcvb, true, didn't think of PAM plugins.
[22:07:40] <levitating> sam_: I am looking at 5.6.0
[22:07:50] <levitating> I am going to ask gynvael about it
[22:07:54] <cjwatson> the openssh → libsystemd linkage is likely to be removed, though that mainly stops people from yelling about it
[22:07:58] <abby> but i'm not sure if that's the case
[22:08:19] <sam_> levitating: ah yeah, i _think_ that's where the Makefile may then get patched, but i'm not sure - please do ask and let me know the answer
[22:08:29] <sam_> levitating: (because the script does a bunch of greps to see if mods are already done, i think)
[22:08:33] <bauen1> abby: I'm confused how / why libselinux would link to libsystemd ? libsystemd definietly links to libselinux
[22:08:33] <sam_> anyway lmk
[22:08:47] *** Quits: Paistin (~Paistin@193.138.7.204) (Quit: Leaving)
[22:09:05] *** Quits: kawys (~kawys@public-gprs652329.centertel.pl) (Remote host closed the connection)
[22:09:06] <abby> bauen1: i'm not sure, what I saw was theoretical
[22:09:26] <sam_> i plan on trying to spend some time looking at it but theres so much to do lol
[22:09:29] <xcvb> libpam -> pam_systemd.so -> liblzma
[22:09:35] <sam_> i am confident other paths exist 
[22:09:38] <sam_> yeah
[22:09:46] <abby> yeah that seems more realisitc
[22:10:09] <bauen1> xcvb: yeah that I understand and know about, but that's not libselinux loading liblzma which I would find confusing
[22:10:21] <xcvb> though ldd pam_systemd.so doesn't mention libsystemd.so, now that's interesting
[22:10:22] <Manis> hmm all the paths we come up with include systemd.
[22:10:24] <r2rien> speaking of pam...is it me beeing paranoid : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066060 ..or just a coincidence..
[22:10:46] <sam_> Manis: i'm confident if i sit down and try find more, i will find several without systemd
[22:10:55] <sam_> i just haven't done it yet
[22:11:09] <sam_> pam is the best way i think
[22:11:13] <bauen1> I don't see how libselinux would be very useful since it has barely any dependencies, the most useful would be to alter exploit behavior on an SELinux enabled system, since there's a much higher chance of detection
[22:11:21] <xcvb> r2rien: nah, lastlog being gone has to do with y2038 issues in the lastlog itself
[22:12:29] <xcvb> r2rien: replacement is pam_wtmpdb.so, if I followed the conversations sufficiently enough
[22:13:00] <nomadgeek> Heh. Just received the first abuse complaint on one of my Tor exit nodes in a whiiiiile.
[22:13:30] <r2rien> xcvb: ..ah thks for this pointer (but that bug number :D)
[22:13:37] *** Quits: atuk10 (~atuk10@124.170.233.88) (Remote host closed the connection)
[22:14:09] *** Joins: Guest54 (~Guest88@174.30.40.113)
[22:14:11] *** Quits: fOSSUser (~G3@51.252.174.39) (Quit: Client closed)
[22:15:04] <rurapenthe> I'm out for some Zzz. bbl
[22:17:05] <nomadgeek> 👋
[22:17:14] *** Quits: rurapenthe (~None@102.132.133.163) (Quit: Leaving)
[22:18:37] <satanist> Manis: modprobe, dpkg
[22:18:40] *** Quits: Guest12 (~Guest5@2a02:2f08:7412:aa70:7dd8:bb8e:747e:ecd7) (Quit: Client closed)
[22:18:52] <Manis> ?
[22:18:54] <r2rien> xcvb: ...+ when you have /var/log/dpkg.log:19858:2024-03-28 18:23:41 status installed xz-utils:amd64 5.6.1-1 ..and you know you habe been sshing and noticing this pam_lastlog disappearing..
[22:19:10] <cjwatson> r2rien: yeah, apparently intentional upstream, but I just emailed a note to the Debian bug with more details
[22:19:16] <satanist> as a path to compromise sshd with liblzma
[22:19:36] <satanist> ^ without systemd
[22:20:25] *** Quits: ThePotato (~ThePotato@63.135.76.182) (Read error: Connection reset by peer)
[22:20:43] <Manis> Do I not understand enough about IFUNC? Doesn't liblzma need to be loaded into the sshd process?
[22:20:45] <r2rien> cjwatson: thks for my mental health
[22:21:10] <sam_> there is no guarantee that it only does something with sshd
[22:21:28] <q3k> sam_: i'm like 90% sure that it only does sshd things fwiw
[22:21:41] <xcvb> but Murphy's Law
[22:21:43] <sam_> thanks (although I'm still going to stick with the earlier line for now)
[22:21:47] <sam_> but appreciate you saying
[22:21:55] <q3k> it might have been written to be more generic for any openssl rsa code, but it has a pretty honkin' check for 'am i /usr/whatever/sshd'
[22:21:59] <q3k> yeah, understandable
[22:22:14] <q3k> that's why i'm saying '90%' and not 'totally dude trust me'
[22:22:17] <sam_> i still find it kind of curious because out of everything, that part seems so specific
[22:22:36] *** Joins: uniq_ (~uniq_@2600:382:1701:24bb:fc21:6207:c015:4792)
[22:22:47] <Manis> If I were an attacker and achieved pre-auth RCE via sshd, what do I want more?
[22:22:54] <cjwatson> maybe trying to reduce probability of detection?
[22:22:56] <nomadgeek> I think that circles back to the ability of the build script to load other test files [instead]. Could be used for other things in the future.
[22:23:05] <sam_> what i mean is, it doesn't try to do things other than sshd. it might fail to hook sshd (might be at a diff. path, might fail for random reasons)
[22:23:07] *** Quits: uniq_ (~uniq_@2600:382:1701:24bb:fc21:6207:c015:4792) (Client Quit)
[22:23:10] <sam_> not "they got sshd, they should do more"
[22:23:25] <q3k> yeah, the payload is very conservative
[22:23:25] <FireFly> yeah, avoiding detection is the only thing I could think of
[22:23:25] *** Joins: uniq_ (~uniq_@2600:382:1701:24bb:fc21:6207:c015:4792)
[22:23:33] <nomadgeek> Yeah. hook sshd for RCE. Small and effective.
[22:23:39] <FireFly> which I guess didn't exactly work out according to plan, fortunately for us
[22:23:41] <negril> nomadgeek: being able to inject other code without changing the test files is something you absolutely want
[22:23:43] <sam_> the part i'm most surprised by is not trying to call home (it seems)
[22:23:45] <q3k> the code tries very hard to not do any other random pokes at the FS or even libc/syscalls that could be noticed
[22:23:52] *** Quits: alreadydone (~alreadydo@2601:152:300:6266:706e:6030:ffd:4024) (Quit: Client closed)
[22:24:04] <q3k> sam_: that would require issuing a syscall :)
[22:24:05] <FireFly> I'm def. looking forward to the eventual writeup :p
[22:24:07] <sam_> :)
[22:24:09] <q3k> and that's immediately visible in an strace
[22:24:11] <sam_> yes
[22:24:14] <negril> Seems like they had a target in mind?
[22:24:14] <q3k> while the payload is pure memory manip
[22:24:22] <pabs3> !ao https://pastebin.com/5gnnL2yT
[22:24:22] <nomadgeek> Calling home is a beacon for folks to notice.
[22:24:45] <q3k> and it's still super stealthy. no rwx remap. no nothing.
[22:24:46] <dnsmcbr> sam_: Don't need to phone home when you can fingerprint an OS remotely and get it's versions and all that.
[22:24:48] <nomadgeek> best to have all the payloads lay silent and let them target who they want.
[22:24:57] <Manis> While incoming failed SSH auth is about as unsuspicious as it gets.
[22:25:02] <sam_> yeah
[22:25:06] <nomadgeek> Manis: truth
[22:25:29] <negril> Does the payload come with the key?
[22:25:39] <nomadgeek> This could have hidden for years if it made it in and no one would notice until it was too late.
[22:25:40] <Manis> fingerprint AFAIK
[22:26:07] <sam_> I suppose the idea may have been to augment with more later with test data 
[22:26:19] <aaceac> does anyone have a list of similar backdoors in open source? ignoring supposedly accidental vulnerabilities
[22:26:30] <negril> years would have required continuous integration of the hostile build-to-host.m4
[22:26:31] *** Joins: Guest79 (~Guest79@198.137.18.234)
[22:27:02] <negril> any release by Lasse would have prevented that
[22:27:16] <Manis> I don't know if this could've stayed hidden for years. I mean e.g. the dot in the landlock configure detection. At some point someone would've noticed that landlock is always disabled, no?
[22:27:24] <rawtaz> has there been any other open source projects that because of the xz story looked into their own tests and already found a similar case yet?
[22:27:39] <sam_> Manis: not many people use the cmake build for xz
[22:27:39] <aaceac> ^ rawtaz id like to know too
[22:27:40] <joepie91> Manis: didn't that only affect a relatively uncommon build mode? from what others mentioned
[22:27:43] <sam_> ^^
[22:27:47] <Manis> sam_, it's also in autotools.
[22:27:48] <nomadgeek> That wasn't the part that was noticed tho. build scripts are pretty common. The dot in landlock was a silly choice imo.
[22:27:50] <sam_> is it?
[22:27:55] <joepie91> (which would be in line with trying to evade unnecessary detection risks)
[22:28:06] <negril> It's not
[22:28:09] <Manis> huh, am I too tired?
[22:28:20] <sam_> i didnt see a dot earlier in the landlock check in autotools
[22:28:34] <Manis> dafuq, I would've sworn it was there.
[22:28:52] <sam_> (also i built and tested the landlock functionality in xz)
[22:28:58] <sam_> in 5.6.0 or so, i think
[22:30:00] <Manis> yes, true, it's only in cmake.
[22:30:09] *** Joins: Guest40 (~Guest40@2a09:bac2:383d:d2d::150:55)
[22:30:43] <Manis> https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da
[22:31:05] *** Joins: panorain (~panorain@user/panorain)
[22:32:06] <cjwatson> nomadgeek: very deniable though, unlike some of the other stuff
[22:32:21] <nomadgeek> cjwatson: the dot?
[22:32:28] <cjwatson> yeah
[22:32:42] <bauen1> Manis: If someone would have noticed you'd have just said thank you, "fixed" it ; the dot is easily deniable as a typo / mistake that went unnoticed due to lack of testing
[22:32:57] <cjwatson> on its own, it's totally "editing mistake, sorry about that"
[22:32:57] <Manis> the dot is.
[22:33:14] <nomadgeek> I could see that, taken in isolation.
[22:33:24] *** Quits: Guest21 (~Guest21@pool-72-87-118-229.prvdri.fios.verizon.net) (Ping timeout: 250 seconds)
[22:33:53] <bauen1> aaceac: the key word is "Trojan Source" I think, sadly not that much info on that topic yet the last time I checked
[22:34:05] *** Quits: Guest40 (~Guest40@2a09:bac2:383d:d2d::150:55) (Client Quit)
[22:34:07] <aaceac> bauen1, thanks, will search
[22:34:18] <cjwatson> Though, does Fedora use the cmake build or something?  Debian doesn't, and the attack otherwise seems to target those distributions
[22:34:35] *** Quits: uniq_ (~uniq_@2600:382:1701:24bb:fc21:6207:c015:4792) (Quit: nyaa~)
[22:34:42] *** Quits: Guest22 (~Guest22@2a02:908:8c1:e060:956d:734:6923:63f6) (Ping timeout: 250 seconds)
[22:34:50] <Manis> I just wanted to check Fedora but I can't find the build description
[22:34:53] <sam_> it is ofc genuinely possible it was a mistake
[22:35:02] <sam_> (a fair q to ask though)
[22:35:05] <sam_> https://src.fedoraproject.org/rpms/xz/blob/rawhide/f/xz.spec
[22:35:19] <Manis> also autools.
[22:35:20] <bauen1> aaceac: I can also recommend https://bootstrappable.org/ and https://github.com/fosslinux/live-bootstrap which solves the "self-hosting" part of the trusting-trust attack to a certain extend, obviously it still has the problem of needing to audit all source code
[22:35:39] <cjwatson> Doesn't seem to, looking at e.g. https://kojipkgs.fedoraproject.org//packages/xz/5.6.1/1.fc41/data/logs/x86_64/build.log
[22:35:58] <aaceac> bauen1, trusting trust reminds me of ken thompsons paper
[22:36:01] <bauen1> honestly I hope that as a result of this distributions will make their definition of "binary" vs. "source" much stricter, leading to autotool artifacts being considered binary
[22:36:04] <cjwatson> I guess maybe some other RPMish distro does
[22:36:05] <bauen1> aaceac: yep, that's it
[22:36:06] <aaceac> reflections on trusting trust
[22:36:41] <bauen1> aaceac: it's also an absolutely horrifying scenario of what this could have evolved into given how much of a central position xz has
[22:36:47] <aaceac> maybe LLMs will prove themselves useful and point out suspicious code
[22:36:55] <cjwatson> haha no
[22:37:02] <cjwatson> more likely to generate it
[22:37:03] <sam_> lol
[22:37:04] <aaceac> lol
[22:37:07] * pabs3 wrote this recently https://wiki.debian.org/AutoGeneratedFiles
[22:37:09] <sam_> yeah, great way to spam maintainers with sludge so they quit
[22:37:15] <sam_> "this commit looks suspicious"
[22:37:17] <nomadgeek> aaceac: or create their own, based on some of the news articles I was reading today.
[22:37:27] <nomadgeek> cjwatson: exactly.
[22:37:27] <aaceac> they can take legal documents and (sometimes) point out parts that are anti-consumer
[22:37:50] * pabs3 wonders about the future of autotools cruft and gnulib cruft after this
[22:37:55] <cjwatson> only because such things exist in their corpus
[22:38:01] <aaceac> yes
[22:38:04] <cjwatson> they aren't going to do nearly so well with novel constructs
[22:38:13] <sam_> i'm going to be a corpus by the end of this weekend
[22:38:13] <balrog> pabs3: > the Debian package should rebuild the generated autotools files using autoreconf. Modern debhelper compat versions will do this automatically.
[22:38:15] <sam_> am i right guys
[22:38:16] <balrog> is this incomplete?
[22:38:25] <aaceac> im under no illusion that LLMs are an intelligent silver bullet
[22:38:33] <cjwatson> balrog: dh-autoreconf does autoreconf, but not gnulib
[22:38:38] <cjwatson> (which is a lot harder to automate)
[22:38:41] <pabs3> balrog: no. the file in question was from gnulib, not autoconf, and autoreconf doesn't update gnulib
[22:38:43] <sam_> gnulib is a really irritating situation for distros
[22:38:44] <balrog> ahh...
[22:38:48] <Manis> pabs3, you could've done this with any other build system, too.
[22:38:50] <sam_> it's so hard for us to handle properly
[22:38:53] <sam_> Manis: well, yes, and no
[22:38:54] <pabs3> indeed
[22:39:02] <bauen1> pabs3: oh that's nice, I suppose a major problem is the cyclic-dependency of autotools
[22:39:02] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Remote host closed the connection)
[22:39:04] <sam_> Manis: autotools is the only real major one with generated gunk
[22:39:17] <sam_> cmake however also has a tendency to encourage metaprogramming with modules and stuff tho
[22:39:28] <Manis> But would you have spotted some malicious lines in hundreds of lines of CMakeFiles.txt?
[22:39:34] <sam_> well yeah i just said that
[22:39:39] <balrog> seems like distros would basically have to determine what version of gnulib from upstream is desired
[22:39:44] <bauen1> arguably the issue also applies more broadly to vendoring dependencies in general
[22:39:49] *** Quits: dppes (~dppes@2a02:908:1862:2d40:2a1f:8c70:f45f:5441) (Quit: Leaving)
[22:39:56] <sam_> balrog: in the past, we had CVEs in gnulib and figuring out which packages were actually vulnerable sucked so hard
[22:39:57] <cjwatson> the thing is ... gnulib is _really_ useful, it has quite a bit of useful inlineable utility code as well as build machinery
[22:39:58] <Manis> The attack would've probably worked a bit differently.
[22:40:01] <pabs3> there are so fucking many embedded code copies in Debian https://wiki.debian.org/EmbeddedCopies
[22:40:09] <sam_> cjwatson: yes!
[22:40:13] <cjwatson> and it needs autoconf
[22:40:21] *** Joins: nomadgeek_ (~nomadgeek@047-134-024-163.res.spectrum.com)
[22:40:22] <pabs3> gnulib stuff should be copied in at build time
[22:40:22] <cjwatson> so if you're using it, it is not even remotely a trivial proposition to stop
[22:40:41] <sam_> we stopped using it in pax-utils recently and it turned out loads of the stuff wasnt even wired up 
[22:40:48] <bauen1> Manis: thing is that cmake files are at least meant to be read usually, so I'd say the chances are at least slightly better compared to scripts that literally noone valuing their santiy ever looks at
[22:41:06] *** Joins: atuk10 (~atuk10@124.170.233.88)
[22:41:09] <Red> gnulib is extremely helpful in making software portable
[22:41:12] *** Joins: atuq12 (~atuq12@124.170.233.88)
[22:41:16] <cjwatson> right, it is, but it is not just that
[22:41:20] <sam_> yeah i do not claim it is useless at all
[22:41:32] <sam_> it just has some substantial difficult properties
[22:41:34] <Manis> bauen1, yeah well maybe, but usually when you read it you read it in a git checkout where the malicious code is missing.
[22:41:34] <negril> Manis: reading arbitrary parts of files from cmake is a lot harder and way more obvious
[22:41:35] <Red> even between different versions of linux, hello nanosleep(!)
[22:42:27] <cjwatson> my packages that use gnulib got a lot better-organized and (I would claim) considerably more correct once I started using gnulib's basic data structures (linked lists, hashes, etc.) rather than trying to hardcode things - and most of the other similar implementations are much bigger
[22:42:42] <cjwatson> ultimately I guess Rust is the answer, but time
[22:42:45] <bauen1> Manis: yes, but ideally reproducible tar balls will help with bridging that gap
[22:42:51] <sam_> rust isn't really immune to this anyway 
[22:42:54] <sam_> it's just got a diff. set of problems
[22:42:57] <cjwatson> Yep
[22:43:00] *** Quits: jess (meow@libera/staff/cat/jess) ()
[22:43:12] * pabs3 wonders if anyone is comparing cargo.io artifacts with upstream git repos yet
[22:43:22] <Red> ahahahahah
[22:43:22] <sam_> I think I saw the Tor people asking about that
[22:43:32] <pabs3> Rust has the same problem as autotools :)
[22:43:37] <sam_> (as they're working on arti)
[22:43:42] <Manis> pabs3, no this is also not done for node or python and has been a problem in the past already.
[22:43:46] *** Quits: IntrnlCmplrErr (~IntrnlCmp@2607:fea8:9565:8e00::c54) (Remote host closed the connection)
[22:43:56] <pabs3> I have seen code in a crate that was generated by a Python script in git, that was not also in the crate
[22:44:09] <cjwatson> I guess I just have a bit of a knee-jerk about this since most times I see people complaining about gnulib they have no idea what it is and just think it's like a few extra handy autoconf checks or portability to AIX 0.1 or something
[22:44:12] *** Joins: Guest11 (~Guest11@bras-base-ktnron0814w-grc-01-184-146-159-136.dsl.bell.ca)
[22:44:14] <tk> I was going to do this myself but I was curious if someone else hasn't done it already: when did libsystemd start depending on liblzma?
[22:44:15] <pabs3> aka, the crate was missing source code
[22:44:21] <Yogurt> pabs3: there's an xz wrapper on crates
[22:44:22] <Yogurt> ya
[22:44:33] <Red> cjwatson, tell me about it. *sigh*
[22:45:13] <Yogurt> there's an npm one too but it's using an older xz
[22:45:14] <Yogurt> https://www.npmjs.com/package/lzma-native
[22:45:20] <tk> And, when notify support for openssh was being patched in by distros, was there anything odd about why the libsystemd route was picked? (it's like 6 lines of C to do this without libsystemd)
[22:45:39] <tk> I imagine this is old stuff and not important but I was wondering
[22:45:52] <cjwatson> tk: my _guess_ would be 2014 when libsystemd-journal was merged into libsystemd
[22:46:10] <tk> okay, so it wasn't like 2-3 years ago then, that's a relief
[22:47:37] <cjwatson> tk: I committed the libsystemd patch in Debian, because it was the patch I was given by people I trusted and it seemed perfectly reasonable to use a library rather than reimplement; later upstream complained about it but I never had time to rewrite, plus I really dispute this "6 lines of C" thing, upstream's current draft patch in https://bugzilla.mindrot.org/attachment.cgi?id=3798&action=diff is not 
[22:47:43] <cjwatson> that trivial
[22:48:04] <pabs3> Manis: when you say "problem in the past", got any more details? feel free to PM since its a bit OT
[22:48:08] <cjwatson> it's not _giant_, but I did not want to make a mistake so it needed a serious chunk of time that I didn't have
[22:48:16] <cjwatson> and it didn't seem important until like ... Friday
[22:48:24] *** Quits: atuk10 (~atuk10@124.170.233.88) (Remote host closed the connection)
[22:48:57] <Manis> pabs3, I'll have to think about it. It was years ago and I cannot remember from the top of my head, but I had a deja vu when I saw this in xz.
[22:48:59] <sam_> also, removing a patch like this is often pretty hard once it's gone in
[22:49:06] <sam_> if it affected config options or anything
[22:49:18] <sam_> plus upstream never replied to kangie's attempt to upstream it
[22:49:22] <sam_> until y'day
[22:49:32] <cjwatson> well it came up on mailing lists a couple of times as well and the response was more like "no"
[22:49:39] <sam_> ah
[22:49:40] <balrog> yeah upstream not replying is weird
[22:49:42] <nomadgeek_> Yeah. No blame from here cjwatson 
[22:49:48] <cjwatson> I was certain I'd get it in the neck if I rewrote to inline the library and made a mistake, too
[22:49:50] <balrog> often different people read the mailing list vs. the github
[22:49:53] <sam_> oh absolutely
[22:49:58] <sam_> "debian NIHed it for no reason"
[22:50:01] <cjwatson> precisely
[22:50:08] *** Quits: phishing_pharao (~phishing_@ip-037-201-116-138.um10.pools.vodafone-ip.de) (Ping timeout: 268 seconds)
[22:50:21] <sam_> lennart is also on record as saying he'd prefer people open-code it on mastodon & hn i think, but i dont think the docs say that anywhere either
[22:50:41] *** Joins: lpt (~lpt@host-87-16-54-137.retail.telecomitalia.it)
[22:50:47] <cjwatson> we've had the good outcome from this that openssh-portable upstream is finally doing the thing all the systemd distros need, so
[22:51:04] <sam_> yes
[22:51:16] <nomadgeek_> What are they doing? I missed it. 
[22:51:26] <cjwatson> see towards the end of https://bugzilla.mindrot.org/show_bug.cgi?id=2641
[22:51:36] *** Quits: Guest72 (~Guest72@195.150.184.101) (Ping timeout: 250 seconds)
[22:52:04] <cjwatson> (they generally prefer bugzilla - honestly I'm surprised that github stuff ever gets a reaction from them, I don't expect it to)
[22:52:33] <xcvb> cjwatson: it's 6 lines when you trim all the error handling, error reporting, and variable declarations :-p
[22:52:47] <cjwatson> yeah, who cares about that stuff right :)
[22:52:59] <nomadgeek_> Ah, independent systemd notifications. 
[22:53:18] <cjwatson> Debian needs a bit more because there's also a patch to use sd_listen_fds, but that's simpler I think
[22:53:25] <bauen1> tk: there's a couple of things I'd love to know, given that it took 2 years to go from joining xz to exploiting, what came first ? The chain of exploiting it, or getting access to xz ? And depending on that I would wonder if there are other, similarly central, projects that faced similar (attempts) at maintainer changes around the same time +/- a year or so
[22:53:36] <xcvb> cjwatson: to be fair, what *if* notification fails?
[22:54:04] <cjwatson> xcvb: same as if it fails in sd_notify I suppose.  I haven't had a serious look yet, because I was offline most of today
[22:54:08] *** Quits: mathis123325234 (~mathis123@2605:a601:a9b2:e300:9c06:1299:243b:cb8b) (Quit: Client closed)
[22:54:12] <sam_> that said, we've actually got on fine w/o it for ages, but i don't blame people for adding it in either
[22:54:16] <sam_> we only ever had a handful of systemd users request it
[22:54:40] <cjwatson> it's more of an issue if you're trying to build non-trivial things on top that need to react to sshd starting
[22:54:41] <sam_> but we are not debian and people have diff. expectations of diff. distros
[22:54:51] <xcvb> cjwatson: no I mean like... systemd will just report sshd as "has already started" when it's not fully up. That feels almost like an "eh, whatever" case.
[22:54:52] <sam_> like in gentoo people expect it to be a bit less turn-key
[22:55:19] <q66> i kinda fail to see in what kind of case one would need sshd to have readiness notification
[22:55:19] <brlin> syu: sam_ 
[22:55:19] *** Quits: m1k3sh (~m1k3sh@ip-037-201-116-138.um10.pools.vodafone-ip.de) (Read error: Connection reset by peer)
[22:55:23] <sam_> ?
[22:55:32] <syu> brlin: ?
[22:55:38] <sam_> the openssh situation overall isnt always ideal because upstream are nice but linux distros have to patch in a lot of integration things which do not apply to openbsd
[22:56:02] <brlin> syu: I must have mistyped my phone, apologies.
[22:56:03] <balrog> are they reluctant to merge stuff into openssh-portable?
[22:56:08] <cjwatson> it's mixed
[22:56:12] <beber_> Thinking about the `.` issue introduced in cmake's check_c_source_compiles, and that invalid syntax are considered as not passing the test, it would potentially be interesting for check_c_source_compiles to do a first pass to verify the syntax of embedded code is valid before considering the C code itself compiles or not, and potentially trigger a hard fail instead of soft fail. Same for autotools as well.
[22:56:12] <beber_>  gcc and clang have a -fsyntax-only for this purpose. 
[22:56:28] <cjwatson> sometimes I'm successful at persuading them to take stuff, sometimes I just run into a brick wall and there's no persuading them
[22:56:39] <sam_> yep
[22:56:44] <cjwatson> mostly it's a more positive relationship than not, but there are warts
[22:57:25] <balrog> when several major distros are applying a patch that upstream doesn't want to accept... that raises questions (imo)
[22:57:28] <cjwatson> I have at least one patch in my stack labelled as basically "upstream are demonstrably wrong about their rejection reason but ..."
[22:58:01] <cjwatson> sure, but what are you gonna do, the patches aren't there for fun.  and upstream are mostly very functional
[22:58:11] <cjwatson> we try our best to make things work
[22:58:17] *** Joins: DigitalDragon (~digital@arto.servers.digitaldragon.dev)
[22:59:10] *** Joins: Guest49 (~Guest49@h-94-254-64-68.A465.priv.bahnhof.se)
[22:59:31] <Red> the only time I've met a brick wall was trying to get build fixes merged into BIND
[22:59:38] <Red> "we don't support that configuration. go away."
[23:00:33] *** Quits: ozel (~ozel@2a02:8071:886:560:c52b:3976:d600:16d4) (Quit: Client closed)
[23:00:48] <levitating> sam_: I asked my question to gynvael publicly on the mailing list
[23:00:49] <Habbie> beber_, i like that
[23:00:58] <sam_> levitating: which one? oss-security?
[23:01:07] <levitating> yes, still needs to be aproved of course
[23:01:11] <sam_> thanks
[23:01:14] *** Quits: Guest11 (~Guest11@bras-base-ktnron0814w-grc-01-184-146-159-136.dsl.bell.ca) (Quit: Client closed)
[23:01:22] <levitating> man this backdoor is weird
[23:01:22] *** Joins: linkfanel (linkfanel@82-64-25-168.subs.proxad.net)
[23:01:28] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[23:01:36] *** Quits: nomadgeek_ (~nomadgeek@047-134-024-163.res.spectrum.com) (Remote host closed the connection)
[23:01:49] <levitating> how can it take so many people to obtain so little information in so much time
[23:01:49] <negril> levitating: what question?
[23:02:06] <levitating> negril: if the stage 2 is itself run in two stages
[23:02:16] <levitating> once during ./configure and once during make
[23:02:44] <negril> no, it's run twice once from $srcdir and once from $srcdir/src/liblzma
[23:03:02] <negril> which i guess equates to from ./configure and make
[23:03:04] *** Joins: Guest93 (~Guest93@2.53.42.42)
[23:03:15] *** Quits: mroszko (~mroszko@2600:4041:539c:f700:f8c8:8bbe:5fe3:120a) (Quit: Client closed)
[23:03:23] *** Quits: Guest93 (~Guest93@2.53.42.42) (Client Quit)
[23:03:31] <qwerty2024> a recent proposal for systemd notify without libsystemd: https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c13
[23:04:28] <negril> levitating: the first call from ./configure injects it into $srcdir/src/liblzma/Makefile
[23:04:50] <levitating> negril: that's my understanding, but I didn't really see that mentioned
[23:05:27] <negril> if test -f config.status; then <..> elif (test -f .libs/liblzma_la-crc64_fast.o) && (test -f .libs/liblzma_la-crc32_fast.o); then <..> fi 
[23:05:46] <negril> The first part isn't overly relevant for most people
[23:06:13] <negril> levitating: also Gynvael is in here
[23:06:27] <levitating> really? haven't seen him yet
[23:07:12] <negril> 3 hours ago last
[23:07:29] <tk> cjwatson: the stat is ... odd (toctou and unnecessary). the code is pretty verbose for reasons I don't think benefit anyone. with proper error messages you will get it a bit longer, but the core functionality is: getenv != NULL, strlen() + 1 <= sizeof sa.sun_path, memcpy, socket, connect, write, close
[23:07:34] <bauen1> levitating: well, your message was approved I think
[23:07:38] <tk> cjwatson: 7 lines of actual logic
[23:07:52] <tk> a bit more with some error reporting
[23:08:15] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Remote host closed the connection)
[23:08:53] *** Joins: nomadgeek_ (~nomadgeek@047-134-024-163.res.spectrum.com)
[23:08:59] <xx> wait what, the real jiatan (logged into the correct nickserv account) was in this channel on the 29th?
[23:09:05] <tolto> wait are there two object files? crc32 and crc64?
[23:09:16] <levitating> xx: yes I think so
[23:09:36] <levitating> tolto: I think the single .o is injected into both, but I might be wrong
[23:09:46] <tolto> hmmm
[23:09:58] *** Quits: Guest79 (~Guest79@198.137.18.234) (Quit: Client closed)
[23:10:00] <tolto> i see
[23:10:56] *** Joins: Guest21 (~Guest21@pool-72-87-118-229.prvdri.fios.verizon.net)
[23:12:19] *** Joins: Guest39 (~Guest15@p200300ebc7434b00b017bda752b19941.dip0.t-ipconnect.de)
[23:12:35] *** Quits: Guest39 (~Guest15@p200300ebc7434b00b017bda752b19941.dip0.t-ipconnect.de) (Client Quit)
[23:12:42] <bauen1> tk: spinning this idea bit further, I guess as an attacker I'd be looking for some library 
[23:13:07] <bauen1> ah sorry, didn't mean to send that
[23:13:33] *** Quits: nomadgeek_ (~nomadgeek@047-134-024-163.res.spectrum.com) (Ping timeout: 272 seconds)
[23:13:41] <DPA> Before systemd, other service managers already had a simple protocol for readiness notifications. You can make them pass an fd, and as soon as a newline is written to it, it's presumed ready. Other stuff can also be written to it, it just needs to be a line. That's much simpler than how systemd does it.
[23:14:07] <aaceac> is it worth auditing all of Jia's commits or is the project killed?
[23:14:35] <pabs3> Debian update: https://fulda.social/@Ganneff/112184975950858403
[23:17:14] *** Quits: xxpor (~skooz@user/xxpor) (Ping timeout: 255 seconds)
[23:17:45] *** Joins: jghali (~jghali@77.195.50.21)
[23:21:15] <Noisytoot> aaceac: unlikely that it would be killed, xz/liblzma are quite widely used
[23:21:41] *** Quits: Guest53 (~Guest53@194.127.199.84) (Quit: Client closed)
[23:21:54] <levitating> I think xz will see some changes in maintainers soon
[23:22:01] <levitating> but it surely won't disappear
[23:22:12] <levitating> it's real fast lmao
[23:22:38] <levitating> q3k: given up yet?
[23:23:12] <q3k> for today, yes
[23:24:39] <JTL> get some sleep :P
[23:24:45] <levitating> yes
[23:26:39] <kroot> By the way, when I looked at that random string with a = in the middle, my first thought was two Base64 strings concatenated together.
[23:26:56] <tk> untested - and not practical/recommended - but illustrative - 9 lines: http://sprunge.us/bjtDGt
[23:27:09] <tk> (not even compiled)
[23:27:13] <kroot> They do decode to two 12 byte values
[23:27:30] <levitating> kroot: if used as an env variable the backdoor doesn't run
[23:27:57] *** amdj sets mode: -o amdj
[23:28:00] <amdj> Heading off to bed.
[23:29:06] <marius_zulu7> What do you see as possible to get once this thing got activated inside of the Debian Unstable building infrastructure? Other distributions?
[23:29:12] *** Quits: Guest47 (~Guest47@185.160.20.244) (Quit: Client closed)
[23:29:40] <bauen1> ß
[23:29:50] <abby> 'night amdj 
[23:30:00] <DasBrain> Good night
[23:30:52] <levitating> night night
[23:31:25] *** Joins: Guest4116 (~Guest41@p54b6fe4f.dip0.t-ipconnect.de)
[23:31:29] <tk> slightly fixed version which compiles: http://sprunge.us/3pclho
[23:31:52] <bauen1> ah, found the source for the libselinux pulls in liblzma poettering@hn https://news.ycombinator.com/item?id=39867126
[23:32:19] *** Quits: Raqbit (~Raqbit@user/raqbit) (Quit: Client closed)
[23:32:38] <Apachez> pabs3: thanks for the debian update link
[23:32:55] <rawtaz> it would be really fun if jiatan came around again (here or wherever) and started explaining how this is all a big misunderstanding, that the code is not at all a backdoor.
[23:33:06] <bauen1> but I still don't see how libselinux supposedly links to liblzma, for me libselinux0 only links to libpcre2 and libc
[23:33:13] <rawtaz> and it would be even more hilarious if they could somehow prove that there is no harm at all with the code :P
[23:33:26] <bauen1> Unless I'm missing it dynamically loading it, which I would be very surprised about \o/
[23:34:53] *** Quits: sraue (~sraue@2a00:20:4002:d4a5:acd0:91ab:c1a2:b805) (Quit: Client closed)
[23:36:14] *** Quits: grd (~grd@84-112-217-88.cable.dynamic.surfer.at) (Ping timeout: 250 seconds)
[23:36:40] *** Joins: mroszko (~mroszko@2600:4041:539c:f700:f8c8:8bbe:5fe3:120a)
[23:40:23] *** Joins: hirokiAkama (~hirokiAka@2.29.101.126)
[23:41:06] <Yogurt> bauen1: here I think https://koji.fedoraproject.org/koji/rpminfo?rpmID=37363189
[23:41:12] <Yogurt> requires xz-devel
[23:42:04] *** Quits: mroszko (~mroszko@2600:4041:539c:f700:f8c8:8bbe:5fe3:120a) (Quit: Client closed)
[23:42:51] *** Quits: a7x (~a7x@user/a7x) (Quit: Leaving)
[23:43:44] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[23:44:06] <bauen1> Yogurt: but that doesn't mean that libselinux links to liblzma (and I see no mention of xz in the selinux repo right now) which is how the current exploit works
[23:44:06] *** Quits: Garen (Garen@50.52.127.145) (Remote host closed the connection)
[23:44:21] <Habbie> wait, when did selinux come into it?
[23:44:23] *** Joins: Garen (~Garen@50.52.127.145)
[23:44:40] <bauen1> Habbie: poettering@hn https://news.ycombinator.com/item?id=39867126
[23:44:53] <Yogurt> is xz-devel not just the redhat naming for it?
[23:44:57] <Habbie> bauen1, ah
[23:45:17] <bauen1> Habbie: I really don't believe him, especially since I do a lot with SELinux and know what libselinux does ; and I can't actually think of anything that requires xz (or any compression for that matter)
[23:45:30] <Habbie> ack
[23:45:49] <bauen1> nor can I find a reference in the build / repo and the libselinux library doesn't link to it either
[23:46:29] <bauen1> too lazy to login to HN right now, but if someone wants to point that out (feel free to quote me)
[23:46:45] *** Joins: atuk10 (~atuk10@124.170.233.88)
[23:46:49] *** Quits: atuk10 (~atuk10@124.170.233.88) (Remote host closed the connection)
[23:47:15] <bauen1> Yogurt: I understand only a little bit about RPMs, but could it be that it's a transitive dependency in this case because of systemd ?
[23:47:45] <Yogurt> could be
[23:47:48] *** Joins: devnull24 (~devnull@20.2.87.176)
[23:50:16] *** Quits: atuq12 (~atuq12@124.170.233.88) (Ping timeout: 268 seconds)
[23:53:15] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Remote host closed the connection)
[23:54:19] *** Quits: Guest33 (~Guest33@2804:b34:301b:7a00::42a) (Quit: Client closed)
[23:55:17] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[23:58:20] *** Quits: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
[23:58:24] *** Quits: panorain (~panorain@user/panorain) (Quit: Konversation terminated!)
[23:59:16] *** Quits: rigid (~rigid@user/rigid) (Read error: Connection reset by peer)
[23:59:53] *** Quits: Guest60 (~Guest60@dsl-hkibng42-56733b-157.dhcp.inet.fi) (Quit: Client closed)
[00:00:04] <spacespork> lmao
[00:00:09] <ztrawhcse> spacespork: unfortunately for you, the doas you run on a non-openbsd system isn't openbsd doas ;)
[00:00:28] <ztrawhcse> actually, unfortunate for your argument but fortunate for you!
[00:00:40] <spacespork> i dont really care, its still better than sudo
[00:00:43] <ztrawhcse> I am partly, but only partly, jesting
[00:00:59] <ztrawhcse> doas is an excellent example of openbsd disinterest in working with the community
[00:01:43] *** Quits: Baughn (sid153359@user/Baughn) (Changing host)
[00:01:43] *** Joins: Baughn (sid153359@user/meow/Baughn)
[00:01:49] <dostoyevsky2> the collaboration is mostly in terms of CVEs
[00:01:58] <spacespork> fair point, i dont run openbsd, i dont plan to run openbsd, but doas is fun and so is openssh
[00:02:52] *** Joins: clopnaz (~clopnaz@pool-108-3-96-88.pitbpa.east.verizon.net)
[00:02:54] <ztrawhcse> ok. I've decided to give openbsd half credit for doas, since it doesn't actually run outside of openbsd but people have forked it to do so
[00:03:04] <sam_> :)
[00:03:05] <ztrawhcse> so they have written 2.5 useful softwares...
[00:05:07] <spacespork> althogh i am annoyed doas dosen't have persistance on most os
[00:06:27] <dnsmcbr> Oh dear god. I just saw the sudo logo.
[00:06:34] <dnsmcbr> When did that monstrosity happen.
[00:06:36] *** Quits: DasKatze (weechat@user/dasbrain) (Changing host)
[00:06:36] *** Joins: DasKatze (weechat@user/meow/DasBrain)
[00:07:03] <sam_> it is sooo 2010s coded
[00:07:22] <ztrawhcse> > The current sudo logo, © 2019 by Mark Stillman and licensed under CCBY 4.0. It was inspired by xkcd 149.
[00:07:23] <sam_> https://www.sudo.ws/about/logo/ says 2019 but i am convinced it was earlier than that
[00:08:01] <selckin> you might feel thats a year ago, buts its 5
[00:08:13] <sam_> ;_;
[00:08:20] <spacespork> oh and yall heard that sudo removed that "this incident will be reported" error message
[00:08:28] <sam_> woke has won
[00:08:59] *** Quits: Mooncairn (~mooncairn@user/mooncairn) (Quit: Leaving)
[00:09:09] <spacespork> part of me is tempted to fork sudo, and the message back, and just rebase every time sudo updates
[00:09:18] *** Joins: Mooncairn (~mooncairn@user/mooncairn)
[00:09:26] <sam_> if you used gentoo, it's just /etc/portage/patches away :)
[00:09:37] <clopnaz> I regret joining this channel for what I have learned about sudo having a logo
[00:10:06] <spacespork> whats that dir for? i dont use gentoo, but i plan to switch soon
[00:10:21] <sam_> it lets you automatically add patches to packages when they get installed
[00:10:26] <sam_> so you can just shove random customisations for stuff in there
[00:10:41] <spacespork> thats what i thought, but thats awsome
[00:10:46] <spacespork> thats actually so usefull
[00:10:59] <sam_> yeah its great
[00:11:10] <sam_> super useful both for customisations like that which you want to keep, and also testing other stuff to send upstream
[00:12:16] <spacespork> speaking of gentoo, do you know anything about use zfs? is that a bad idea?
[00:12:37] <sam_> using zfs on gentoo is fine and it's easier if you use dist-kernels because you get automatic module rebuilds
[00:12:53] <sam_> that said
[00:12:57] <sam_> https://wiki.gentoo.org/wiki/User:Sam/Memorable_bugs_I_like_to_reference#Bugs_found_by_Portage.27s_native_file_copying :p
[00:14:55] *** Quits: xx (~xx@user/xx) (Changing host)
[00:14:55] *** Joins: xx (~xx@user/meow/xx)
[00:15:06] <spacespork> i would image it one of the better distros to use it on bc if im compiling by kernel anyway its suddenly no longer and out of tree filesystem
[00:15:16] <spacespork> other than the gentoo CoW issue
[00:16:38] <ztrawhcse> zfs is a garbage FS but it probably works better on gentoo than anywhere else
[00:16:56] <spacespork> well i wanna dualboot with freebsd
[00:16:59] *** Quits: miton (uid542385@id-542385.tinside.irccloud.com) (Changing host)
[00:16:59] *** Joins: miton (uid542385@user/meow/miton)
[00:17:05] <ztrawhcse> even sam_ has finally been won over to the "zfs bad" camp
[00:17:19] <sam_> we are on a break
[00:17:22] <ztrawhcse> and sam_ is a longtime stockholm syndrome victim of the zfs wars
[00:17:30] <aaabbb> since when is zfs bad?
[00:17:41] *** Joins: balling (~balling@2a00:1370:8184:46d8:ff1d:79c:3482:f946)
[00:17:54] <aaabbb> openzfs has bugs but the filesystem is fine
[00:18:12] *** Quits: balling (~balling@2a00:1370:8184:46d8:ff1d:79c:3482:f946) (Read error: Connection reset by peer)
[00:18:24] *** Joins: balling (~balling@172.96.141.95)
[00:18:31] <spacespork> well doesn't freebsd maintain openzfs now so it should be better
[00:19:36] *** Quits: [ (2loH56eelS@sourcehut/user/noisytoot) (Changing host)
[00:19:36] *** Joins: [ (2loH56eelS@user/meow/Noisytoot)
[00:19:36] *** Quits: Noisytoot (~noisytoot@sourcehut/user/noisytoot) (Changing host)
[00:19:36] *** Joins: Noisytoot (~noisytoot@user/meow/Noisytoot)
[00:20:59] <bernard__> spacespork: wanna be my fren?
[00:21:10] <spacespork> ok? sure?
[00:22:44] *** Quits: beber_ (~beber_@2a05:d018:c28:1a00:fd:d0ae:0:5222) (Ping timeout: 268 seconds)
[00:23:02] *** Quits: balling (~balling@172.96.141.95) (Ping timeout: 268 seconds)
[00:23:15] *** Joins: balling (~balling@2a00:1370:8184:46d8:9a0e:b7b6:c339:ceb)
[00:24:30] *** Quits: balling (~balling@2a00:1370:8184:46d8:9a0e:b7b6:c339:ceb) (Read error: Connection reset by peer)
[00:24:40] *** Joins: balling (~balling@172.96.161.119)
[00:24:53] <spacespork> looks like someone is having internet problems
[00:25:13] <bernard__> sorry my pizza arrived
[00:25:21] <spacespork> pizza
[00:25:30] <spacespork> no i was talking about balling tho
[00:25:43] <spacespork> bernard__: are you sharing?
[00:25:55] *** Joins: mroszko (~mroszko@2600:4041:539c:f700:9155:e753:7557:e9cf)
[00:26:04] *** Quits: mroszko (~mroszko@2600:4041:539c:f700:9155:e753:7557:e9cf) (Client Quit)
[00:26:05] <bernard__> oh my joins and parts are hidden
[00:26:25] <spacespork> yeah i didn't see anything
[00:26:29] <balling> Nope, probably not Internet, just the app. Revolution IRC, lol, conoiled for android
[00:26:42] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[00:28:07] <spacespork> terminal irc client gang
[00:28:47] <balling> What CLI app do you use?
[00:29:09] <spacespork> rn irssi but thinking of switching to iii
[00:29:22] <balling> I see
[00:30:06] <jmh_> no one uses btchx anymore it seems
[00:30:15] <spacespork> wtf is that
[00:31:15] <d_m> irc client
[00:31:31] <spacespork> is it any good
[00:31:58] <jmh_> well, it hasnt been updated for years and years :D so that might be the reason why its not used :)
[00:32:02] *** Joins: Guest59 (~Guest59@137.132.26.249)
[00:32:27] *** Quits: Guest59 (~Guest59@137.132.26.249) (Client Quit)
[00:32:29] <balling> Not as good as KVirc, it even has history protocol
[00:32:33] <spacespork> that would make sense\
[00:35:44] <bernard__> pizza so good it cant be shared
[00:36:11] *** Joins: midou (~midou@sl.projectsegfau.lt)
[00:37:14] *** Quits: ZLima12 (~zlima12@user/ZLima12) (Changing host)
[00:37:14] *** Joins: ZLima12 (~zlima12@user/meow/ZLima12)
[00:40:09] *** linuxdaemon is now known as linuxdaeMEOW
[00:40:45] *** Joins: duxsco (~duxsco@user/duxsco)
[00:42:02] *** Quits: fireonlive (fire@user/fireonlive) (Changing host)
[00:42:02] *** Joins: fireonlive (fire@user/meow/fireonlive)
[00:44:10] *** Affliction is now known as Affeline
[00:44:50] *** Quits: blb (~blb@user/blb) (Changing host)
[00:44:50] *** Joins: blb (~blb@user/meow/blb)
[00:45:36] <stefk> jmh_: exactly! :D I checked BitchX' status prior to settling on some web client
[00:45:44] *** Joins: atuq12 (~atuq12@124.170.233.88)
[00:45:45] *** Joins: beber_ (~beber_@2a05:d018:c28:1a00:fd:d0ae:0:5222)
[00:45:57] *** Quits: semz (~semz@user/semz) (Quit: ZNC 1.8.2+deb2build5 - https://znc.in)
[00:46:24] <spacespork> has anyone here tried iii or any other ii derivatives?
[00:47:04] *** Quits: JAA (~JAA@user/jaa) (Changing host)
[00:47:04] *** Joins: JAA (~JAA@user/meow/JAA)
[00:50:32] *** Joins: semz (~semz@user/semz)
[00:50:54] *** Quits: atuq12 (~atuq12@124.170.233.88) (Ping timeout: 256 seconds)
[00:53:43] *** Joins: nozaq (nozaq@user/nozaq)
[00:59:13] *** Parts: adamus1red (~M@user/mrr) (Leaving)
[01:00:51] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[01:04:08] <stefk> spacespork: BitchX is one but I guess you're looking for recommendations and that's a firm no for a while now apparently :)
[01:04:32] <spacespork> bitchx is ii based?
[01:05:33] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 255 seconds)
[01:06:32] <levitating> first of all, irc clients are fairly off-topic to this channel, but I guess it's night anyway
[01:06:39] <levitating> don't settle for a web client for irc
[01:07:34] <spacespork> yeah its night, if there was a more important conversation going on i wouldn't clog the channel with client talk but theres not much else happening so i thought itd be ok
[01:08:00] <spacespork> also i feel like a web client is the oposite of ii
[01:08:26] *** Joins: Fingel (~Fingel@user/fingel)
[01:08:36] <levitating> a big benefit of irc is that you can just connect directly to the servers
[01:08:40] *** Joins: Riastradh (~riastradh@netbsd/board/riastradh)
[01:08:49] <levitating> with a protocol so easy you could even use a raw tcp connection
[01:08:59] *** Joins: Cass (uid609017@user/meow/dax)
[01:09:09] <stefk> that's at least what the wp article said earlier. for me it's just what came with some remote ISP shell, I don't know details. Such as that it was quite vulnerable also back then. p/m me for user stories ;)
[01:09:10] <spacespork> yeah, i love irc
[01:09:28] <levitating> if you'd use a web client that's kind of a shame
[01:09:39] <levitating> besides, desktop applications are highly underrated
[01:10:19] <levitating> if you want a simple desktop application to connect to irc with I recommend HexChat (even though it did recently go unmaintained)
[01:10:37] <levitating> though there's many alternatives out there, even thunderbird can do irc
[01:10:58] *** Quits: jghali (~jghali@77.195.50.21) (Read error: Connection reset by peer)
[01:11:15] <levitating> as for terminal applications, I use irssi over ssh, but many would prefer weechat
[01:11:28] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[01:11:29] <stefk> levitating: I should have said "settled for now". The temp. alternative in my mind was some Windows instance with mIRC but deemed even lamer by me :)
[01:11:32] <balling> I would not use a raw TCP socket
[01:11:37] <balling> At least HTTPS 
[01:11:41] *** Parts: Guest78 (~Guest78@p5dc70edf.dip0.t-ipconnect.de) ()
[01:12:09] <balling> So you were talking RISC-V stuff, where is that?
[01:12:25] <levitating> balling: you mean tls?
[01:12:40] <stefk> Thunderbird seems to be able to do a lot...
[01:12:41] <levitating> balling: like the literal files in the repo, the discussion or what do you mean?
[01:13:03] <levitating> stefk: Thunderbird is highly underrated and has been making a comeback recently
[01:13:19] <balling> TLS 1
[01:13:23] <balling> .3
[01:13:27] <beber_> I've locally imported compromised xz-5.6.1 on top of af071ef7702debef4f1d324616a0137a5001c14c, and the diff appears to be much larger with changes in much more places than just in m4/build-to-host.m4.
[01:13:27] <beber_> The diff is available on https://git.pants-on.net/xz.git/commit/?h=dev/jiatan/5.6.1&id=708012158e4a93831ecea6a49ea64f6753da4e14 (need cacert root ca in trust store)
[01:13:30] <levitating> 2023 was a good year for Thunderbird, you can expect the ability to sync your configurations like on Firefox in the next release
[01:13:52] <beber_> In particular what's worrying me are changes in CMakeLists.txt in regards to FreeBSD, Win32
[01:13:58] <ztrawhcse> stefk: thunderbird is a communications platform which happens to be primarily used for its mail support.
[01:14:07] <sam_> beber_: are you comparing with the 5.6 branch?
[01:14:17] <levitating> beber_: your ssl isn't doing too well
[01:14:24] <beber_> yeah, with git commit right prior to Lasse dot revert
[01:14:50] <sam_> the 5.6 branch doesn't contain the rvert I think
[01:15:12] <sam_> fwiw I have checked over a bunch of diffs (which is no guarantee) and not found anything odd yet in terms of tags vs release tarballs
[01:15:14] <beber_> it's rebased on top of security.md change
[01:15:16] <sam_> *anything else odd
[01:15:47] <sam_> it is also helpful to compare with autoreconf -fi as well
[01:15:56] <levitating> sam_: you say anything odd, what kind of stuff is different from the source normally? Just autoconf files?
[01:16:14] <sam_> levitating: autoconf + translations
[01:16:47] <sam_> beber_: that CMake change is curious (looks fine at a glance) but are you saying it wasn't ever in a git commit?
[01:16:57] <beber_> I could be rebased on wrong commit, checking this
[01:17:09] <sam_> my instinct is you might have but not sure, i will look in a bit too
[01:17:14] <stefk> levitating: I do use Thunderbird for email, but prefer to let it only deal with that
[01:17:23] <spacespork> Tan made a lot of updates to translations, ive been looking through those commits to see if he snuck anything funky in those, nothing yet
[01:17:42] <sam_> it's hard because translations are indeed huge diffs but also that's how we missed the autoconf stuff 
[01:17:44] <bernard__> spacespork: can you link me to the translations?
[01:17:44] <sam_> so..
[01:17:54] <beber_> it seems FreeBSD stuff are present in 82f0c0d39eb2c026b1d96ee706f70ace868d4ed4
[01:18:11] <sam_> also, wihle I diff tarballs (but not atm tags vs tarballs), I didn't notice the autoconf stuff in there even though I've been worried about someoen smuggling stuff in autoconf for ages
[01:18:14] <balling> beber_: no need to https://git.rootprojects.org/root/xz/commit/82ecc538193b380a21622aea02b0ba078e7ade92?ref=connortumbleson.com
[01:18:20] <stefk> spacespork: with a big recent translation update pretty quickly after a certain other one ;)
[01:18:42] <spacespork> bernard__: ive just been looking on the tukaani git repo and searching for tan's commits with the word translation
[01:19:00] *** Quits: Riastradh (~riastradh@netbsd/board/riastradh) (Remote host closed the connection)
[01:19:22] <levitating> balling: what's up with the ?ref
[01:19:31] <balling> It is from hia site
[01:19:36] <balling> *His
[01:19:39] <sam_> beber_: btw, similar in vein to your CMake proposed change, see https://lists.gnu.org/archive/html/bug-autoconf/2024-03/msg00000.html
[01:19:50] <sam_> beber_: not the same type of thing but same kind of class of "stuff we might be able to make better in light of this"
[01:19:52] <spacespork> there was a bunch of translation commites on feb 17th and 20th
[01:20:14] <stefk> balling: links coming from https://connortumbleson.com/2024/03/31/watching-xz-unfold-from-afar/ , if you don't strip them ;)
[01:20:22] <balling> Yes
[01:20:48] <sam_> beber_: also, Brad asked you to file a bug but it looks like someone else has for you: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9391
[01:20:53] <sam_> uh https://gitlab.kitware.com/cmake/cmake/-/issues/25846 **
[01:21:03] <levitating> stefk: I also use the calendar, sometimes tasks
[01:21:10] <beber_> sam_, correct, did not get the chance yet
[01:21:22] <sam_> np, meant more as "fyi because the guy hasnt linked the mr"
[01:21:28] <sam_> not "something is waiting on you"
[01:21:34] <balling> >however the change instead brought in silent failure
[01:21:35] <balling> in check_c_source_compiles(), preventing the feature from ever be
[01:21:35] <balling> enabled.
[01:22:23] *** Joins: Riastradh (~riastradh@netbsd/board/riastradh)
[01:22:35] *** Joins: Guest14 (~Guest88@174.30.40.113)
[01:23:32] *** Quits: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
[01:23:46] <balling> Imagine how many more stuff @jiatan knows, hahahaha
[01:24:23] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 268 seconds)
[01:26:15] *** Quits: Guest15 (~Guest34@ecs-119-8-242-171.compute.hwclouds-dns.com) (Quit: Client closed)
[01:27:44] *** Quits: catia (katia@user/katia) (Changing host)
[01:27:44] *** Joins: catia (katia@user/meow/katia)
[01:29:56] <blb> has that person responded in any way yet?
[01:30:08] <sam_> no
[01:30:31] <spacespork> ok, the "translation" commit right after the test file commit is just translations. Interesting that hes making legit commits along with the malicious ones
[01:30:33] <sam_> but lasse did say he also wasn't expecting to hear, either, before all fo this, because they were both supposed to be offline for easter
[01:31:00] <blb> sam_: has this channel grown significantly in these few days? lol
[01:31:09] <sam_> blb: this channel used to be like, 10 people, and very cosy
[01:31:43] <sam_> i woke up on.. saturday morning(?) friday afternoon? whatever it was, and it had like, 250+ people in it, and libera staff had kindly intervened to keep the peace and given op to a few of us
[01:31:51] <fullstop> I'm just here to lurk, don't mind me.
[01:32:10] <balling> spacespork: how would he become a mantainer otherwise?
[01:32:20] <blb> same here. just seeing what people are saying
[01:32:25] <sam_> i think maybe spacespork meant that it's interesting it was done at the same time as the badness
[01:32:29] <spacespork> balling: from making the legit commits before
[01:32:30] <sam_> not like, in general
[01:32:40] <spacespork> sam_: exactly
[01:32:58] <spacespork> interesting that hes doing them at the same time
[01:33:13] <dnsmcbr>  The ol' shit sandwich I guess
[01:33:20] <spacespork> i guess
[01:33:31] <fullstop> It's easier to hide things if there is a flurry of activity.
[01:33:51] <spacespork> there were some more translation commits back in feb, do we think those are worth going through?
[01:34:14] <fullstop> The french one looked interesting to me
[01:34:27] <spacespork> from feb?
[01:34:33] <balling> Of course: he literally disabled compilation with 1 dot in one line.
[01:34:34] <spacespork> why, whats wrong with it?
[01:35:01] <dnsmcbr> Never trust the french, only their food. 
[01:35:20] <spacespork> good point
[01:35:41] <stefk> spacespork: a tiresome line by line check? I considered that one after the test updates to be safe since it was just to hide the badness ;)
[01:36:37] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[01:36:42] *** Quits: duxsco (~duxsco@user/duxsco) (Quit: WeeChat 4.2.1)
[01:36:44] <spacespork> stafk: not really line by line, just checking if theres changes to anything other than the .1 file
[01:36:57] *** Joins: duxsco (~duxsco@user/duxsco)
[01:37:05] *** Joins: zipace (~john@p200300ecef4b42c3742021ec9695ad1b.dip0.t-ipconnect.de)
[01:37:07] <balling> BTW, did debian use cmake by default and not make?
[01:37:11] *** Joins: Guest35 (~Guest35@062066200179.static.telenor.dk)
[01:39:00] <fullstop> Yeah, the one from February.  There was a lot of formatting done on top of the fixed fuzzy patch offsets.
[01:39:12] <sam_> i am not aware of any major distribution or vendor using cmake for it
[01:39:15] <stefk> spacespork: there are changes to .po files!!11
[01:39:42] <balling> Then what was the point to stop cmake?
[01:39:56] <fullstop> it might be a legit typo
[01:39:58] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[01:39:58] <sam_> dunno. might have been a genuine error (lol), might have been future sabotage work
[01:40:12] <spacespork> if he somehow found a way to obfuscate malicious code in document files, sue me
[01:40:27] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[01:40:29] <sam_> i absolutely skim over .po changes in diffs
[01:40:32] <sam_> many people do
[01:40:36] <sam_> it is not unreasonable to at least check
[01:40:53] <fullstop> If you were going to fix the patch offsets, why would you format the po file at the same time?
[01:41:00] <sam_> (that said, it would be extraordinary, I agree)
[01:41:16] *** Noisytoot is now known as Noisymeow
[01:41:18] <balling> Patch offsets are here? Or what https://git.rootprojects.org/root/xz/commit/82ecc538193b380a21622aea02b0ba078e7ade92
[01:41:27] <sam_> maybe they mean offsets in the script or test data? not sure
[01:41:33] <sam_> or do you mean fuzz in the translations
[01:41:39] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 268 seconds)
[01:41:44] <fullstop> commit 24355c5280bc95e3d594432d60bb8432aa6af173
[01:41:53] <fullstop> the man pages, actually
[01:42:03] <stefk> little harm to be done with .po (famous last words), at least can be checked for correctness
[01:42:05] <spacespork> also i dont speak any other langueges than english so it coudle be saying "this is malicious code, this puts a backdoor in ssh" in frech and id jave no idea
[01:42:09] <sam_> ah, that's fuzz in translations
[01:42:23] <fullstop> yes, but they were unfuzzed and formatted at the same time
[01:42:29] <fullstop> it is probably nothing, but it stuck out to me
[01:42:36] <sam_> i have no idea what the norm is for handling it so will leave commentary for others
[01:42:39] <sam_> all i know is i find it laborious 
[01:42:57] <stefk> oh wait, I'm now reminded of a format string mismatch with translations :)
[01:43:02] <sam_> no project i maintain happens to have translations so not sure of what the usual method is
[01:43:48] <spacespork> i figure i dont really know much about this project so i figure itll be easier to find oddeties in translation commits than anything else
[01:44:00] <fullstop> Some languages have a different word order, so token replacements are swapped in some cases.
[01:44:20] <fullstop> but this is just a man page, I think, so it is probably nothing.
[01:45:58] *** Quits: waleee (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 268 seconds)
[01:47:38] *** Joins: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8)
[01:50:02] <stefk> spacespork: me neither, just scraping to see if there's more b.s. commit messages like "To better reproduce these files in the future, a constant seed [...]"
[01:50:25] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[01:52:00] <spacespork> romainian is safe
[01:52:32] <bernard__> imo that's him building his contributor persona
[01:54:07] <spacespork> can someone explain this, in one of the translation commits, git is saying there is changes to .c files, but whats changed looks like its man files
[01:54:33] <fullstop> which commit id?
[01:55:28] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 264 seconds)
[01:55:46] <balling> So...  sys/capsicum.h was removed. Another sandbox in the story
[01:56:20] <spacespork> fullstop: a65fd7ce9d6228e87faf61dc56a35984d0088248
[01:57:03] *** Joins: duxsco_ (~duxsco@user/duxsco)
[01:57:07] <sam_>  po/eo.po | 502 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------------
[01:57:07] <sam_>  1 file changed, 306 insertions(+), 196 deletions(-)
[01:57:10] <sam_> i do not see anything else?
[01:57:25] <stefk> same
[01:58:03] <sam_> that said, you just made me realise something interesting to check..
[01:59:11] <spacespork> as im scrowling through the commitdiff online, its showing changes to stuff like src/xz/args.c but the chages look like man files
[01:59:11] *** Quits: LjL (~ljl@user/ljl) (Read error: Connection reset by peer)
[01:59:12] <stefk> spacespork: do you also validate format string correct-ness? btw I also think these are safe (as in: done with good intentions), but doesn't hurt to check
[01:59:33] *** Quits: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au) (Ping timeout: 272 seconds)
[01:59:55] *** Joins: LjL (~ljl@user/ljl)
[02:00:23] <stefk> spacespork: these are strings extracted for translation, the source file locations update when the translation files does (if source file lines changed last translation file update)
[02:00:42] <stefk> or strings get added/removed etc...
[02:00:46] *** Quits: duxsco (~duxsco@user/duxsco) (Ping timeout: 268 seconds)
[02:01:03] <spacespork> stefk: i dont understand
[02:01:20] <sam_> we think you are looking at changes in the .po file where it references .c lines
[02:01:39] <sam_> but that is how it works normally
[02:01:53] <spacespork> why is the diff showing it as changes to the c fill then
[02:02:03] <sam_> can you show us what you're seeing via copy/paste or screenshot or similar
[02:02:23] <bernard__> spacespork: that's simply translations of command messages
[02:03:16] <spacespork> -#: src/xz/args.c:116+#: src/xz/args.c:124+#, c-format+msgid "In --block-list, block size is missing after filter chain number '%c:'"+msgstr "En --block-list, la blokgrando mankas post numero de la filtrila ĉeno '%c:'"++#: src/xz/args.c:150 msgid "0 can only be used as the last element in --block-list" msgstr "0 povas nur esti uzata kiel la lasta elemento en --block-list" -#: src/xz/args.c:451+#: 
[02:03:22] <spacespork> src/xz/args.c:539 #, c-format msgid "%s: Unknown file format type" msgstr "%s: Nekonata dosierformata tipo" -#: src/xz/args.c:474 src/xz/args.c:482+#: src/xz/args.c:562 src/xz/args.c:570 #, c-format msgid "%s: Unsupported integrity check type" msgstr "%s: Nekomprenata tipo de integra kontrolo" -#: src/xz/args.c:518-msgid "Only one file can be specified with `--files' or `--files0'."-msgstr "Nur oni 
[02:03:28] <spacespork> dosiero estas specifebla per `--files' aŭ `--files0'."+#: src/xz/args.c:606+msgid "Only one file can be specified with '--files' or '--files0'."+msgstr "Nur unu dosiero estas specifebla per '--files' aŭ '--files0'."  #. TRANSLATORS: This is a translatable #. string because French needs a space #. before the colon ("%s : %s").-#: src/xz/args.c:533 src/xz/coder.c:691 src/xz/coder.c:707 
[02:03:34] <spacespork> src/xz/coder.c:967-#: src/xz/coder.c:970 src/xz/file_io.c:605 src/xz/file_io.c:679-#: src/xz/file_io.c:769 src/xz/file_io.c:940 src/xz/list.c:369-#: src/xz/list.c:415 src/xz/list.c:477 src/xz/list.c:581 src/xz/list.c:590+#: src/xz/args.c:621 src/xz/coder.c:1058 src/xz/coder.c:1074+#: src/xz/coder.c:1374 src/xz/coder.c:1377 src/xz/file_io.c:685+#: src/xz/file_io.c:759 src/xz/file_io.c:849 
[02:03:37] <Bahhumbug> ...
[02:03:40] <spacespork> src/xz/file_io.c:1020+#: src/xz/list.c:368 src/xz/list.c:414 src/xz/list.c:476 src/xz/list.c:590+#: src/xz/list.c:599 #, c-format msgid "%s: %s" msgstr "%s: %s" -#: src/xz/args.c:589+#: src/xz/args.c:677 #, c-format msgid "The environment variable %s contains too many arguments" msgstr "La medivariablo %s enhavas troajn argumentojn" -#: src/xz/args.c:691+#: src/xz/args.c:779 msgid "Compression support 
[02:03:42] <sam_> that's on me i guess :p
[02:03:46] <spacespork> was disabled at build time" msgstr "Rego de kunpremado estas malaktivigita dum muntotempo" -#: src/xz/args.c:698+#: src/xz/args.c:786 msgid "Decompression support was disabled at build time" msgstr "Rego de malkunpremado estas malaktivigita dum muntotempo" sample of what im seeing
[02:03:51] <sam_> i never learn
[02:03:52] <dnsmcbr> sam_: smh mh
[02:04:03] <ztrawhcse> sam_: the autoconf issue is complicated, since it's genuinely useful to provide updated critical macros that downstream distros are too old to have...
[02:04:04] <Bahhumbug> sam_: Every day's a Monday
[02:04:08] <sam_> :)
[02:04:13] <stefk> spacespork: to only see which files changed in a commit use --stat, e.g. git show a65fd7ce --stat
[02:04:16] <sam_> ztrawhcse: yes :/
[02:04:32] <balling> Copied from Discord: The 5.6 branch has commits from 2 months ago, in the time of Jia, and Jia made that branch.   In 5.4 where the Capsicum check is still present, that's also a Jia branch.    Jia took this out.
[02:04:53] <spacespork> stefk: yeah ik, but that would require me to clone the repo and im being lazy
[02:05:07] <sam_> you are trying to analyse something from a possible state actor
[02:05:13] <sam_> if you want to do useful work, you cannto be lazy lol
[02:05:16] <sam_> either leave it or do it right
[02:05:37] <bernard__> spacespork: this is what is being changed https://github.com/sailfishos-mirror/xz/blob/master/po/es.po
[02:05:41] <bernard__> this is how translations work
[02:05:44] <bernard__> read the source of that file
[02:05:51] <bernard__> actual .c files are not being changed
[02:05:59] <dnsmcbr> sam_: that behavious is big manager energy
[02:06:10] <sam_> is it?
[02:06:11] <spacespork> bernard__: ik, the diff is being funky
[02:06:34] <spacespork> sam_: ill come back tommorow ig, thought i could still try to be helpful
[02:06:35] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Remote host closed the connection)
[02:06:39] <sam_> i don't mean it badly
[02:06:45] *** Joins: jghali_ (~jghali@21.50.195.77.rev.sfr.net)
[02:06:53] <sam_> i just mean that taking shortcuts is going to lead to confusion
[02:07:09] <sam_> this stuff is so subtle
[02:07:47] <bernard__> spacespork: https://i.imgur.com/l4XsfKL.png
[02:08:09] <spacespork> listen, i dont feel like cloning the repo tonight, ill do that tommorow and come back. is there anything i can do to be helpful before then?
[02:08:37] <bernard__> spacespork: we are good
[02:08:45] <spacespork> goodnight yall
[02:08:45] <bernard__> thanks
[02:08:48] <bernard__> gn
[02:08:49] *** Quits: spacespork (~satan@user/spacespork) (Quit: leaving)
[02:10:28] <beber_> Jia was using a "dirty" version of autoconf 2.72 as per https://git.pants-on.net/xz.git/diff/build-aux/ltmain.sh?h=dev/jiatan/autofoo&id=d80170884c094b292020a720f80415c4916f92a0
[02:10:36] *** Quits: Guest35 (~Guest35@062066200179.static.telenor.dk) (Quit: Client closed)
[02:10:43] <sam_> fwiw that is not by itself suspicious 
[02:10:53] <sam_> that is just libtool right?
[02:11:01] <beber_> libtool correct
[02:11:16] <ztrawhcse> sam_: I also wonder how much of a downside it will be if cmake fails to configure for configure tests that check whether a macro exists, where without the macro the hresulting test file is not valid syntax
[02:11:18] <sam_> it would be worth checking if that short hash matches one of the changes in libtool but the -dirty makes it sound like maybe not
[02:11:24] <ztrawhcse> you get that sort of thing a lot also with C++ stds
[02:12:34] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[02:13:11] <sam_> beber_: so this is related to the general autotools situation and why dist tarballs exist (one reason, anyway). you generally want to make sure you ship it with some generated versions which work, as you don't know what versions are on the systems building $tool. if you YOURSELF are building with old versions of these tools, then you get complaints. so often people build from git autoconf/automake/libtool
[02:13:28] <sam_> beber_: but if you look up git describe & the gnulib git-describe thing (it has a name i forget), the -dirty has a meaning too, so i dunno
[02:13:36] <beber_> yeah, which is a major infiltration risk on its own, but not specific to xz here
[02:13:37] <sam_> it might have been them applying arch or other distro patches, might have been something else entirely...
[02:13:57] *** Quits: jghali_ (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[02:14:27] *** Joins: jghali_ (~jghali@21.50.195.77.rev.sfr.net)
[02:14:32] <sam_> iirc lasse encouraged jia to use newer versions and even commented on how he rejected a previous tarball in the past because it had to oold autoconf or similar
[02:14:50] * opal 8,1🐔0,1: happy easter fellow gentooman
[02:17:36] <stefk> JiaT75's last (ever, I suspect) comment on GH is at least funny in hindsight: "Also, I would probably want to generate the Windows binaries locally instead of relying on GitHub runners. The GitHub CI runners are a common attack surface these days so it could be an extra risk. Currently, we only use CI for testing so if the GitHub runners are compromised then its not a security threat."
[02:18:15] <ztrawhcse> that ltmain.sh diff stinks of a distro patch, as removing it reverted back to ~stock GNU libtool defaults
[02:18:23] <sam_> stefk: lol
[02:19:12] <ztrawhcse> it doesn't appear to be part of the debian tree...
[02:20:29] *** Quits: steering (~steering@enceladus.whatbox.ca) (Changing host)
[02:20:29] *** Joins: steering (~steering@user/meow/steering)
[02:20:32] *** Joins: Guest25 (~Guest34@ecs-119-8-243-91.compute.hwclouds-dns.com)
[02:20:42] <bernard__> oh jia.. generate your binaries locally and in the CI and compare the results ;]
[02:20:56] <ztrawhcse> doesn't appear to be in https://src.fedoraproject.org/rpms/libtool/tree/rawhide either
[02:21:16] *** Quits: smpl (~smpl@user/smpl) (Quit: Leaving)
[02:21:22] <sam_> ztrawhcse: ./cxx-pthread/2.4.6 in elt-patches...
[02:21:57] <ztrawhcse> oh haha
[02:22:02] <ztrawhcse> ironic...
[02:23:28] <ztrawhcse> rejected upstream:
[02:23:31] <ztrawhcse>     It seems to be a bug in libtool, right?
[02:23:31] <ztrawhcse> No. All is fine in my environment where most of packages are without vendor patches and linux distribution is different. 
[02:23:57] <beber_> 2.4.7.4-1ec8f-dirty points to one of your upstream commits: git.savannah.gnu.org/cgit/libtool.git/commit/?id=1ec8fa28dcb29500d485c136db28315671ec4c3b
[02:24:02] <ztrawhcse> perhaps vapier could investigate this incredibly powerful need
[02:24:11] <sam_> beber_: that guy is a total moro-
[02:24:49] <ztrawhcse> anyways the difference doesn't seem to be significant either way
[02:25:02] <sam_> ztrawhcse: idk. the patch is the same kind of thing as q66 complained about wrt it removing clang libs and also i think how it doesnt always work properly with sanitizers (see https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=3561199667a999c969d18be0d404d0ad2576c2e4). it might be that it's worse if your distro patches gcc to do as-needed or something
[02:25:02] <ztrawhcse> it's just resetting to stock libtool
[02:25:08] <sam_> but in any case it's harmless in terms of this
[02:26:18] *** Joins: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au)
[02:27:08] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[02:29:45] *** Quits: balling (~balling@172.96.161.119) (Read error: Connection reset by peer)
[02:30:55] *** Joins: balling (~balling@172.96.161.119)
[02:32:52] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 255 seconds)
[02:37:37] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[02:38:24] *** Quits: balling (~balling@172.96.161.119) (Read error: Connection reset by peer)
[02:41:47] *** Joins: balling (~balling@172.96.161.119)
[02:42:19] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 255 seconds)
[02:44:50] *** Joins: Guest53 (~Guest53@32-218-57-192.bng02.brpt.ct.frontiernet.net)
[02:46:57] *** Quits: jghali_ (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[02:47:01] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[02:47:35] *** Joins: jghali_ (~jghali@21.50.195.77.rev.sfr.net)
[02:48:52] *** Quits: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au) (Ping timeout: 268 seconds)
[02:51:04] <bernard__> hm m247.ro
[02:51:16] <bernard__> isnt that a bulletproof hosting from back in the day?
[02:51:22] <bernard__> name rings a bell
[02:51:50] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 252 seconds)
[02:51:56] <bernard__> ah witopia vpn
[03:00:13] <balling> How can you be sure it witopia I have no idea...
[03:01:01] *** Quits: Guest21 (~Guest21@pool-72-87-118-229.prvdri.fios.verizon.net) (Ping timeout: 250 seconds)
[03:01:16] <upb> i suppose a few of those could have ran on m247 but it's a colo provider 
[03:02:55] *** Joins: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au)
[03:03:03] *** Joins: sraue (~sraue@ip-095-223-016-008.um35.pools.vodafone-ip.de)
[03:03:07] *** Quits: panorain (~panorain@user/panorain) (Quit: Konversation terminated!)
[03:03:40] *** Quits: mxz (~mxz@user/mxz) (Ping timeout: 260 seconds)
[03:03:50] *** Quits: Guest53 (~Guest53@32-218-57-192.bng02.brpt.ct.frontiernet.net) (Quit: Client closed)
[03:04:56] *** Quits: Fingel (~Fingel@user/fingel) (Quit: Fingel)
[03:05:17] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[03:06:17] *** Joins: xxpor (~skooz@75-172-43-144.tukw.qwest.net)
[03:06:54] *** Joins: panorain (~panorain@user/panorain)
[03:10:27] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 268 seconds)
[03:14:41] *** Quits: r2rien (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr) (Ping timeout: 255 seconds)
[03:16:11] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[03:17:07] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Remote host closed the connection)
[03:17:45] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[03:18:08] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[03:22:05] *** Quits: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au) (Ping timeout: 260 seconds)
[03:24:07] *** Joins: Yogurt (~Yogurt@158.51.82.203)
[03:24:09] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Remote host closed the connection)
[03:24:17] *** Joins: genr8eofl__ (~genr8eofl@user/genr8eofl)
[03:24:31] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[03:26:52] *** Quits: genr8eofl_ (~genr8eofl@user/genr8eofl) (Ping timeout: 255 seconds)
[03:29:39] <bernard__> nbd. they are behind a vpn
[03:29:45] <bernard__> doesn't matter that much right now
[03:29:48] <bernard__> maybe to the feds
[03:30:41] *** Joins: akaWolf0 (~akaWolf0@2a05:3580:df03:1a55::1000)
[03:31:23] *** Joins: r2rien (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr)
[03:31:40] <GNU_world> This comment's kinda interesting in hindsight (about an old CVE from 2022 in libarchive)... i wonder if there's anything related to jia or just coincidence https://github.com/libarchive/libarchive/issues/1672#issuecomment-1072364013
[03:32:26] <GNU_world> https://github.com/libarchive/libarchive/pull/1682
[03:34:18] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Remote host closed the connection)
[03:34:35] *** Joins: plato (~plato@bl22-40-171.dsl.telepac.pt)
[03:34:50] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[03:35:49] *** Quits: plat0 (~plato@79.78.2.34) (Ping timeout: 256 seconds)
[03:38:17] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[03:38:17] *** Quits: devnull6 (~devnull@202-63-67-177.ip4.superloop.au) (Ping timeout: 250 seconds)
[03:38:37] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[03:43:45] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 268 seconds)
[03:44:16] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 260 seconds)
[03:59:42] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[04:04:13] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 255 seconds)
[04:05:44] *** Quits: r2rien (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr) (Ping timeout: 260 seconds)
[04:07:22] *** Joins: BlueShark (sid10311@ircpuzzles/2021/april/winner/blueshark)
[04:07:25] *** Joins: mefistofeles (~mefistofe@user/mefistofeles)
[04:18:48] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[04:25:31] *** Quits: akaWolf0 (~akaWolf0@2a05:3580:df03:1a55::1000) (Ping timeout: 250 seconds)
[04:26:30] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Remote host closed the connection)
[04:27:06] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 272 seconds)
[04:27:14] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[04:28:08] *** Joins: vin (~vin@user/crash)
[04:29:02] *** Quits: vin (~vin@user/crash) (Client Quit)
[04:29:24] *** Joins: ErrorNoInternet (~error@23.162.40.16)
[04:31:13] *** Quits: xxpor (~skooz@75-172-43-144.tukw.qwest.net) (Ping timeout: 268 seconds)
[04:32:23] *** Joins: vin (~vin@user/crash)
[04:32:46] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Remote host closed the connection)
[04:33:12] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[04:39:35] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[04:43:57] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 246 seconds)
[04:45:13] *** Joins: loganaden (~logan@102.117.25.107)
[04:46:50] *** Quits: plato (~plato@bl22-40-171.dsl.telepac.pt) (Remote host closed the connection)
[04:47:08] *** Joins: plat0 (~plato@bl22-40-171.dsl.telepac.pt)
[04:50:19] *** Quits: Guest68 (~Guest68@ec2-54-69-95-168.us-west-2.compute.amazonaws.com) (Quit: Client closed)
[04:51:24] *** Joins: akaWolf0 (~akaWolf0@2a05:3580:df03:1a55::1000)
[04:55:00] *** Quits: akaWolf0 (~akaWolf0@2a05:3580:df03:1a55::1000) (Client Quit)
[04:55:35] *** Quits: hirokiAkama (~hirokiAka@user/hirokiAkama) (Ping timeout: 268 seconds)
[04:56:41] *** Quits: balling (~balling@172.96.161.119) (Read error: Connection reset by peer)
[04:57:50] *** Joins: balling (~balling@172.96.161.119)
[05:00:38] *** Joins: zdong (~zdong@user/meow/zdong)
[05:00:56] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[05:08:03] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 264 seconds)
[05:09:11] *** Joins: mxz (~mxz@user/mxz)
[05:11:53] *** Parts: vin (~vin@user/crash) (WeeChat 2.8)
[05:20:19] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[05:23:26] *** Quits: Mooncairn (~mooncairn@user/mooncairn) (Quit: Leaving)
[05:24:05] *** Quits: Yogurt (~Yogurt@158.51.82.203) (Quit: My MacBook has gone to sleep. ZZZzzz…)
[05:24:52] *** Quits: stefk (~stefk@89.205.226.72) (Ping timeout: 250 seconds)
[05:26:06] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 268 seconds)
[05:27:24] *** Joins: hmnxynhiaz_ (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz)
[05:28:22] *** Quits: hmnxynhiaz (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz) (Remote host closed the connection)
[05:32:12] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Remote host closed the connection)
[05:32:36] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[05:33:10] *** hmnxynhiaz_ is now known as hmnxynhiaz
[05:37:18] *** Quits: panorain (~panorain@user/panorain) (Quit: Konversation terminated!)
[05:38:44] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[05:40:36] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[05:40:43] *** Joins: vtorri__ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[05:44:21] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Ping timeout: 272 seconds)
[05:44:26] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 256 seconds)
[05:44:36] *** Quits: loganaden (~logan@102.117.25.107) (Ping timeout: 268 seconds)
[05:45:15] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 264 seconds)
[05:45:57] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[05:46:01] *** Joins: loganaden (~logan@102.117.50.19)
[05:47:22] *** nullvalue is now known as nullc4t
[05:50:39] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 264 seconds)
[05:52:16] <FH_thecat> what was the purpose of the legitimate build-to-host.m4 script in the first place? If it was only distributed in the upstream archive, and was not in the git repo, was it essential for the build process ?
[05:53:01] <FH_thecat> also, looking at the script, even before Jia added his payload extraction lines, it alredy looked funny, with sed commands piped to tr
[05:53:30] <FH_thecat> what are those sed | tr shenanigans in the original script for ?
[05:55:27] *** Quits: balling (~balling@172.96.161.119) (Ping timeout: 264 seconds)
[05:55:40] <andreyv> From the description of that file, it translates build environment paths to host environment paths during the build.
[05:55:40] <ztrawhcse> FH_thecat: the GNU autotools are based around the use of m4 scripts as utility macro libraries, which then get assembled into portable POSIX sh scripts that run on 1980s solaris boxes
[05:56:40] <ztrawhcse> the macro libraries are typically installed from various locations and included at release time into tarballs, in addition to generating the main configure script. This helps you also recreate the configure script if configure.ac is updated, without going and installing the m4 macros too
[05:57:10] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[05:58:13] <sam_> I don't recall what build-to-host is actually used for, if anything, specifically in xz 
[06:00:15] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[06:02:40] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 252 seconds)
[06:03:52] *** Quits: vtorri__ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Ping timeout: 255 seconds)
[06:06:46] <upb> nice anagram, so it's not .cn or .us :) JIA CHEONG TAN -> CIA JHEONG TAN -> CIA JHON EGTAN -> CIA JOHN AGENT -> CIA AGENT JOHN [from discord chat]
[06:07:20] <sam_> thank u for ur service
[06:07:23] <FH_thecat> which discord chat ?
[06:09:32] <upb> i'm only half-joking, how probable is it, that services fr those countries would generate such double-misdirection name pointing to themselves
[06:12:22] <FH_thecat> anybody have name of the discord server, or the invite link ?
[06:12:50] <davet> discord link is at the top of https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
[06:14:30] <FH_thecat> davet:  thanks 
[06:16:31] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[06:17:10] *** Joins: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net)
[06:21:36] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 268 seconds)
[06:23:20] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[06:24:43] *** Joins: andibmu (~andi@dslb-094-216-240-042.094.216.pools.vodafone-ip.de)
[06:27:32] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 246 seconds)
[06:35:12] *** Joins: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au)
[06:35:28] *** Quits: duxsco_ (~duxsco@user/duxsco) (Quit: WeeChat 4.2.1)
[06:36:00] <ztrawhcse> I think that it is unlikely a Gematriya has any meaning here.
[06:39:20] *** Quits: i860 (~i860@c-73-92-114-165.hsd1.ca.comcast.net) (Quit: Client closed)
[06:39:59] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[06:40:32] *** Joins: beaver20 (~beaver@113.163.178.101)
[06:41:02] *** Joins: duxsco (~duxsco@user/duxsco)
[06:43:40] *** Quits: beaver20 (~beaver@113.163.178.101) (Client Quit)
[06:44:28] *** Quits: Garen (~Garen@50.52.127.145) (Ping timeout: 256 seconds)
[06:44:28] *** Joins: vin (~vin@user/crash)
[06:45:45] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 255 seconds)
[06:48:06] *** Joins: pajlada (~pajlada@user/pajlada)
[06:53:40] *** Quits: nulldata (~nulldata@185.153.177.39) (Ping timeout: 268 seconds)
[06:54:41] *** Joins: nulldata (~nulldata@185.153.177.40)
[06:55:05] *** Joins: rurapenthe (~None@102.132.133.163)
[07:00:16] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[07:01:30] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Ping timeout: 255 seconds)
[07:05:58] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 255 seconds)
[07:07:17] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[07:09:37] *** Quits: rurapenthe (~None@102.132.133.163) (Quit: This computer has gone to sleep)
[07:10:29] *** Joins: Guest43- (~Guest43-@202.58.197.26)
[07:14:30] *** Quits: Guest43- (~Guest43-@202.58.197.26) (Client Quit)
[07:19:28] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[07:19:36] *** Joins: Guest74 (~Guest74@2605-4A80-A101-EB80-0-0-0-B1D-dynamic.midco.net)
[07:20:41] *** Quits: Guest74 (~Guest74@2605-4A80-A101-EB80-0-0-0-B1D-dynamic.midco.net) (Client Quit)
[07:27:03] *** Joins: Guest0 (~Guest0@91-156-196-177.elisa-laajakaista.fi)
[07:30:07] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 260 seconds)
[07:33:06] *** Joins: rurapenthe (~None@102.132.133.163)
[07:42:35] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[07:46:16] *** Quits: intc (~intc@gateway/tor-sasl/intc) (Remote host closed the connection)
[07:46:54] *** Joins: intc (~intc@gateway/tor-sasl/intc)
[07:47:09] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 252 seconds)
[07:48:21] <f_[xmpp]> hi all
[07:48:28] <ponycat> funderscore
[07:48:36] <f_[xmpp]> ponycat: pony cat
[07:48:41] <ponycat> :3c
[07:49:09] <f_[xmpp]> Glad to know biboumi still works while my actual bnc is still dead :P
[07:49:10] *** Quits: duxsco (~duxsco@user/duxsco) (Quit: WeeChat 4.2.1)
[07:49:29] <rurapenthe> Mornings all (if thats you're timezone otherwise afternoon, and good evening)
[07:49:33] *** Quits: steckie (~steckie@p54b6fe4f.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
[07:49:51] <f_[xmpp]> Lasse said he would be available today right?
[07:50:00] *** Quits: intc (~intc@gateway/tor-sasl/intc) (Remote host closed the connection)
[07:50:04] <sam_> he didn't promise that, no
[07:50:32] <sam_> i'm kind of expecting him to pop up but i wont be shocked if he doesnt
[07:51:55] *** Joins: intc (~intc@gateway/tor-sasl/intc)
[07:52:43] <f_[xmpp]> sam_: not promise
[07:53:01] <f_[xmpp]> but he did say "See you on Monday!" or something like that
[07:53:26] <f_[xmpp]> sam_: Wouldn't be shocked either
[07:53:30] <sam_> lemme look
[07:53:34] <sam_> (I wasn't here the whole time he was)
[07:54:03] <sam_> you're right!
[07:54:04] <f_[xmpp]> I could've looked if my bouncer was still working..
[07:54:09] <sam_> sorry, I completely misse dit
[07:54:17] <f_[xmpp]> it's fine
[07:54:29] <sam_> honestly today seems like a nice day to pop up if he can, so far it's quite quiet
[07:54:42] <sam_> no more of the mania for a bit 
[07:54:46] <sam_> not sure how long it will last
[07:54:53] <f_[xmpp]> /shrug
[07:56:10] <f_[xmpp]> Maybe he still didn't wake up
[07:56:17] <f_[xmpp]> let's give him time :)
[07:58:28] *** Joins: steckie (~steckie@p54b6fe4f.dip0.t-ipconnect.de)
[08:00:13] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk)
[08:00:30] <rurapenthe> Wait till the t-shirts come out sam_  :)
[08:01:43] <steckie> Has anyone talked about the sudden license change to 0BSD just before release of 5.6.0?
[08:02:09] <sam_> rurapenthe: :)
[08:02:16] <sam_> steckie: no, but i'm not sure it's really that interesting, is it?
[08:02:24] <sam_> it was discussed here loads before it happened and then in news and such 
[08:04:31] *** Joins: whiskerst (bakerst@libera/staff/bakerst)
[08:04:55] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 256 seconds)
[08:06:51] *** Quits: ErrorNoInternet (~error@23.162.40.16) (Ping timeout: 272 seconds)
[08:08:35] *** Joins: ErrorNoInternet (~error@static-198-44-129-42.cust.tzulo.com)
[08:25:55] *** Joins: Rijenkii (~Rijenkii@78.142.230.108)
[08:32:49] *** Joins: Leviticoh (~Leviticoh@user/Leviticoh)
[08:35:32] *** Joins: duxsco (~duxsco@user/duxsco)
[08:36:41] *** Quits: Leviticoh (~Leviticoh@user/Leviticoh) (Remote host closed the connection)
[08:37:11] *** Joins: Leviticoh (~Leviticoh@user/Leviticoh)
[08:38:45] *** Quits: Leviticoh (~Leviticoh@user/Leviticoh) (Remote host closed the connection)
[08:39:11] *** Joins: Leviticoh (~Leviticoh@user/Leviticoh)
[08:43:35] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[08:44:29] <susi> Lasse said he may be online today or tomorrow
[08:45:15] <susi> it's sabbath still
[08:46:28] *** Joins: Guest48 (~Guest2@2605:4a80:a101:eb80::b1d)
[08:47:24] *** Quits: Guest48 (~Guest2@2605:4a80:a101:eb80::b1d) (Client Quit)
[08:48:02] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 260 seconds)
[08:54:05] <Manis> susi: depending on where you are...
[08:54:21] <Manis> It's Monday in Europe
[08:56:52] *** Quits: tolto (~quassel@5402D3E4.dsl.pool.telekom.hu) (Read error: Connection reset by peer)
[08:57:44] *** Joins: tolto (~quassel@5402D3E4.dsl.pool.telekom.hu)
[09:07:33] *** Quits: Cass (uid609017@user/meow/dax) (Quit: Connection closed for inactivity)
[09:09:51] *** Quits: hannula (~hannula@mobile-access-6df05f-224.dhcp.inet.fi) (Read error: Connection reset by peer)
[09:10:06] *** Joins: hannula (~hannula@mobile-access-6df05f-224.dhcp.inet.fi)
[09:11:31] <f_[xmpp]> Just wait for him :)
[09:11:34] *** Quits: Mateon1 (~Thunderbi@user/mateon1) (Changing host)
[09:11:35] *** Joins: Mateon1 (~Thunderbi@user/meow/Mateon1)
[09:15:47] *** Quits: solsTiCe (~solsTiCe@user/solsTiCe) (Ping timeout: 256 seconds)
[09:16:02] *** Quits: hannula (~hannula@mobile-access-6df05f-224.dhcp.inet.fi) (Read error: Connection reset by peer)
[09:16:20] *** Joins: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi)
[09:17:43] *** Quits: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[09:18:00] *** Joins: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi)
[09:21:25] *** Quits: Chiitoo (~Chiitoo@gentoo/developer/chiitoo) (Quit: Sayonara sandwich!)
[09:21:52] *** Quits: Leviticoh (~Leviticoh@user/Leviticoh) (Quit: WeeChat 4.2.1)
[09:24:41] <supakeen> it’s still Easter
[09:26:07] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Remote host closed the connection)
[09:26:19] *** Quits: Etabeta1 (~Etabeta1@user/Etabeta1) (Changing host)
[09:26:19] *** Joins: Etabeta1 (~Etabeta1@user/meow/Etabeta1)
[09:29:09] <tomreyn> I believe he was referring to Tue/Wed as the earliest. And he'll need to do a LOT of catch-up first of all.
[09:30:19] *** Quits: rigid (~rigid@user/rigid) (Read error: Connection reset by peer)
[09:31:11] *** Joins: rigid (~rigid@user/rigid)
[09:40:48] *** Quits: tolto (~quassel@5402D3E4.dsl.pool.telekom.hu) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
[09:44:35] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[09:44:51] *** Quits: marius2 (~marius2@p54ac6081.dip0.t-ipconnect.de) (Remote host closed the connection)
[09:48:36] *** Joins: Guest61 (~Guest61@2605:8d80:6a1:3ad5:75b1:58f2:a406:bf66)
[09:49:26] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 264 seconds)
[09:52:28] *** Joins: 080AAL0DP (~onlyJak0b@p50865e95.dip0.t-ipconnect.de)
[09:52:58] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[09:53:55] <Guest61> is there any archive of this channel?
[09:54:04] *** Joins: teatkin (~tom@adsl-5-198-5-39.karoo.kcom.com)
[09:56:51] <tomreyn> probably not officially. i couldn't find public logs for it when searching the web.
[09:57:07] *** Joins: junon (~junon@user/junon)
[09:59:21] <Guest61> saw the ars technica article and thought "no way" and then started digging through github and was flabbergasted
[10:00:31] <Guest61> nice work with the FAQ
[10:00:55] *** Quits: jghali_ (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[10:01:01] <Guest61> hope the full story of this gets explained so better protections can be made
[10:01:12] *** Quits: Guest61 (~Guest61@2605:8d80:6a1:3ad5:75b1:58f2:a406:bf66) (Quit: Client closed)
[10:01:14] <sam_> thank you 
[10:01:25] *** Joins: jghali_ (~jghali@21.50.195.77.rev.sfr.net)
[10:05:51] *** Joins: marius2 (~marius2@p54ac6081.dip0.t-ipconnect.de)
[10:06:31] *** Quits: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8) (Ping timeout: 250 seconds)
[10:09:15] *** Quits: xx (~xx@user/meow/xx) (Quit: xx)
[10:09:33] *** Quits: Guest0 (~Guest0@91-156-196-177.elisa-laajakaista.fi) (Ping timeout: 250 seconds)
[10:10:27] *** Quits: plat0 (~plato@bl22-40-171.dsl.telepac.pt) (Ping timeout: 255 seconds)
[10:10:40] *** Quits: marius2 (~marius2@p54ac6081.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
[10:12:25] *** Quits: jghali_ (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[10:12:55] *** Joins: jghali_ (~jghali@77.195.50.21)
[10:15:21] *** Joins: plat0 (~plato@p4fe6d824.dip0.t-ipconnect.de)
[10:15:49] *** Quits: steckie (~steckie@p54b6fe4f.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
[10:16:37] *** Joins: steckie (~steckie@p54b6fe0d.dip0.t-ipconnect.de)
[10:24:54] *** Quits: teatkin (~tom@adsl-5-198-5-39.karoo.kcom.com) (Quit: Konversation terminated!)
[10:28:04] *** Joins: r2rien (~r2rien@37.171.195.186)
[10:28:26] *** Joins: stefk (~stefk@188.213.88.212)
[10:29:03] *** Joins: Guest65 (~Guest65@109-236-81-168.hosted-by-worldstream.net)
[10:29:16] *** Joins: zer0def (~zer0def@user/zer0def)
[10:29:32] <Noisymeow> maybe the backdoor was actually an april fools' day joke that was discovered early
[10:29:33] *** Joins: Chiitoo (~Chiitoo@gentoo/developer/chiitoo)
[10:29:40] *** Quits: stefk (~stefk@188.213.88.212) (Remote host closed the connection)
[10:29:42] <Manis> lol
[10:30:25] *** Quits: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[10:30:39] *** Joins: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi)
[10:33:32] *** Joins: Guest15 (~Guest15@2a02:a210:bc0:f00:9c64:b9d2:893b:214e)
[10:33:43] *** Guest15 is now known as arikb
[10:34:10] *** Joins: bertronika (~nejc@user/nejc)
[10:35:28] *** Joins: Guest60 (~Guest60@dsl-hkibng42-56733b-157.dhcp.inet.fi)
[10:35:51] *** Joins: Guest45 (~Guest45@nat-88-212-17-123.antik.sk)
[10:42:28] *** Quits: DPA (~DPA@75-128-16-94.static.cable.qlnet.ch) (Changing host)
[10:42:28] *** Joins: DPA (~DPA@user/meow/DPA)
[10:44:32] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Ping timeout: 272 seconds)
[10:45:34] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[10:46:49] *** Quits: Guest45 (~Guest45@nat-88-212-17-123.antik.sk) (Ping timeout: 250 seconds)
[10:50:43] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 246 seconds)
[10:52:19] *** Quits: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au) (Ping timeout: 255 seconds)
[10:54:05] *** Joins: vegard_no (~vegard_no@anice-653-1-505-141.w86-205.abo.wanadoo.fr)
[10:56:26] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[10:57:01] *** Joins: hirokiAkama (~hirokiAka@user/hirokiAkama)
[10:57:19] *** Joins: Guest45 (~Guest45@nat-88-212-17-123.antik.sk)
[10:59:36] *** Quits: tobbez (tobbez@user/tobbez) (Changing host)
[10:59:36] *** Joins: tobbez (tobbez@user/meow/tobbez)
[11:00:52] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 246 seconds)
[11:01:38] *** Quits: Guest60 (~Guest60@dsl-hkibng42-56733b-157.dhcp.inet.fi) (Quit: Client closed)
[11:01:42] *** Quits: Guest65 (~Guest65@109-236-81-168.hosted-by-worldstream.net) (Quit: Client closed)
[11:02:09] *** Quits: hirokiAkama (~hirokiAka@user/hirokiAkama) (Ping timeout: 268 seconds)
[11:04:34] <susi> I think it might have been a benevolent OTA upgrade/extension mechanism that got misunderstood
[11:05:25] *** Quits: arikb (~Guest15@2a02:a210:bc0:f00:9c64:b9d2:893b:214e) (Quit: Client closed)
[11:07:00] *** Quits: Celelibi (celelibi@user/celelibi) (Changing host)
[11:07:00] *** Joins: Celelibi (celelibi@user/meow/Celelibi)
[11:12:26] *** Joins: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au)
[11:13:28] *** Joins: bnf (~ben@user/bnf)
[11:13:41] *** Joins: marius2 (~marius2@p200300f1df08aa00116ebf23914dbdcc.dip0.t-ipconnect.de)
[11:16:31] *** Quits: marius2 (~marius2@p200300f1df08aa00116ebf23914dbdcc.dip0.t-ipconnect.de) (Remote host closed the connection)
[11:16:58] *** Joins: marius2 (~marius2@p200300f1df08aa00116ebf23914dbdcc.dip0.t-ipconnect.de)
[11:21:53] *** Quits: marius2 (~marius2@p200300f1df08aa00116ebf23914dbdcc.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
[11:27:59] *** Joins: teatkin (~tom@31.94.62.135)
[11:29:47] *** Joins: NachPlus (~Nach@vba-m/team/NachPlus)
[11:31:24] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[11:35:32] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 240 seconds)
[11:35:42] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[11:38:36] *** Quits: Guest45 (~Guest45@nat-88-212-17-123.antik.sk) (Quit: Client closed)
[11:38:49] *** Joins: jghali__ (~jghali@21.50.195.77.rev.sfr.net)
[11:42:49] *** Quits: jghali_ (~jghali@77.195.50.21) (Ping timeout: 264 seconds)
[11:43:15] *** Parts: st3fan (sid43079@id-43079.lymington.irccloud.com) ()
[11:45:08] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Ping timeout: 240 seconds)
[11:45:41] *** Joins: xx (~xx@user/meow/xx)
[11:45:58] <xx> is there a pool for money for performing a security audit of xz codebase?
[11:46:10] *** Joins: Guest21 (~Guest21@pool-72-87-118-229.prvdri.fios.verizon.net)
[11:46:33] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[11:47:04] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Ping timeout: 256 seconds)
[11:48:40] <aesthetics> Larhzu: hello (and wb if you're reading this ;p) - just a random request: would it be possible to add a donation page or something to tukaani.org ? or maybe there's already but i missed it ?
[11:48:45] <aesthetics> ahah
[11:48:47] *** Joins: ray65536 (~ray65536@lopatin.pw)
[11:48:55] <aesthetics> not exactly the same question but ... :)
[11:49:01] *** Quits: aaceac (~aaceac@2a00:23c5:9ba2:c300:8601:9d0c:f094:7b4e) (Ping timeout: 255 seconds)
[11:51:02] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 256 seconds)
[11:52:38] <xx> donations and a security audit are related
[11:53:02] *** Joins: gamer191 (~gamer191@124.168.216.118)
[11:53:25] <xx> basically pay someone to throw every fuzzer, static code analyzer, ... on the codebase, and also perform a manual code audit
[11:53:43] <gamer191> Has anything happened in the 24 hours since I last joined this IRC?
[11:54:00] <xx> I can already tell one conclusion of the auditor: "The build system is archaic"
[11:56:21] *** Joins: elgar (sid515085@id-515085.uxbridge.irccloud.com)
[11:56:44] *** Quits: Guest43 (~Guest43@2001:1838:200d:2:46c7:85d0:3a81:45a6) (Quit: Client closed)
[11:56:53] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[11:57:10] <sh4> the quickest way to fix the codebase is to start from last commit before jia tan, then go through all changes and apply only the ones that improve something
[11:57:53] <rawtaz> sh4: or even, if that is easier, rewrite the relevant changes oneself, completely ignoring jiatan's implementation.
[11:57:54] <NachPlus> sh4: Need to be wary if any other commits back then were associated with Jia Tan
[11:58:05] <rawtaz> might be easier than decoding whatever they did, in some cases
[11:58:27] <NachPlus> You cannot assume that the entity Jia Tan only did work under the name Jia Tan
[11:58:32] *** Joins: stefk (~stefk@89.205.226.157)
[11:59:11] <rawtaz> indeed not
[11:59:57] <sh4> true, though before the bad actors decided to target xz and started pushing, the repo was pretty stale
[12:00:41] <rawtaz> at some point N times back it will be more fruitful to start looking at other repos instead xD
[12:00:43] *** Joins: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[12:01:04] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[12:01:42] <rawtaz> sam_: FWIW, it would probably be better if the FAQ authors joined forces on one single FAQ instead. PRs that can be reviewed, one single source
[12:04:26] *** Quits: ErrorNoInternet (~error@static-198-44-129-42.cust.tzulo.com) (Ping timeout: 268 seconds)
[12:05:03] *** Joins: plato (~plato@p4fe6d824.dip0.t-ipconnect.de)
[12:05:40] *** Quits: gamer191 (~gamer191@124.168.216.118) (Ping timeout: 250 seconds)
[12:06:02] *** Joins: ErrorNoInternet (~error@146.70.201.83)
[12:06:10] *** Quits: teatkin (~tom@31.94.62.135) (Read error: Connection reset by peer)
[12:06:22] *** Joins: gamer191 (~gamer191@124.168.216.118)
[12:06:56] *** Quits: gamer191 (~gamer191@124.168.216.118) (Client Quit)
[12:06:57] *** Joins: Leviticoh (~Leviticoh@user/Leviticoh)
[12:08:20] *** Quits: plat0 (~plato@p4fe6d824.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
[12:08:45] *** plato is now known as plat0
[12:10:16] *** Quits: dutch (~DutchIngr@user/dutch) (Quit: WeeChat 4.2.1)
[12:11:21] *** Joins: teatkin (~tom@31.94.62.135)
[12:12:19] *** Joins: dutch (~DutchIngr@user/dutch)
[12:16:38] *** Quits: ErrorNoInternet (~error@146.70.201.83) (Ping timeout: 252 seconds)
[12:17:24] *** Joins: voxxit (~txt@50.227.146.194)
[12:17:24] *** Quits: voxxit (~txt@50.227.146.194) (Changing host)
[12:17:24] *** Joins: voxxit (~txt@user/voxxit)
[12:18:58] *** Joins: hirokiAkama (~hirokiAka@user/hirokiAkama)
[12:19:24] *** Quits: jacksonchen666 (~jackson@user/jacksonchen666) (Remote host closed the connection)
[12:19:25] *** Quits: r2rien (~r2rien@37.171.195.186) (Ping timeout: 260 seconds)
[12:22:34] *** Quits: ray65536 (~ray65536@lopatin.pw) (Quit: This computer has gone to sleep)
[12:22:34] *** Quits: teatkin (~tom@31.94.62.135) (Read error: Connection reset by peer)
[12:22:50] *** Joins: ray65536 (~ray65536@lopatin.pw)
[12:23:28] *** Joins: ErrorNoInternet (~error@23.162.40.98)
[12:24:03] *** Quits: Leviticoh (~Leviticoh@user/Leviticoh) (Remote host closed the connection)
[12:24:28] *** Joins: Leviticoh (~Leviticoh@user/Leviticoh)
[12:27:34] *** Quits: Guest14 (~Guest88@174.30.40.113) (Quit: Client closed)
[12:28:43] *** Joins: Guest14 (~Guest14@174.30.40.113)
[12:29:59] *** Quits: voxxit (~txt@user/voxxit) (Quit: My MacBook has gone to sleep. ZZZzzz…)
[12:31:10] *** Quits: brlin (sid357232@id-357232.helmsley.irccloud.com) (Changing host)
[12:31:10] *** Joins: brlin (sid357232@user/meow/brlin)
[12:31:15] *** Joins: voxxit (~txt@user/voxxit)
[12:31:51] *** Quits: sathyabhat (~sathyabha@n114-77-128-9.mas2.nsw.optusnet.com.au) (Read error: Connection reset by peer)
[12:32:37] *** Parts: billings (~nobody@user/billings) (WeeChat 4.2.1)
[12:34:14] *** Joins: jacksonchen666 (~jackson@user/jacksonchen666)
[12:37:15] *** Joins: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu)
[12:42:01] *** Joins: Guest23 (~Guest23@78.143.78.15)
[12:42:48] *** Joins: teatkin (~tom@31.94.62.135)
[12:43:37] *** Quits: jacksonchen666 (~jackson@user/jacksonchen666) (Quit: WeeChat 4.2.1)
[12:45:50] *** whiskerst is now known as bakerst
[12:46:56] *** Joins: r2rien (~r2rien@37.171.195.186)
[12:47:11] *** Quits: voxxit (~txt@user/voxxit) (Quit: My MacBook has gone to sleep. ZZZzzz…)
[12:49:54] <josuah> > commit before jia tan
[12:50:39] *** Parts: vin (~vin@user/crash) (WeeChat 2.8)
[12:50:52] <josuah> why not include them? regardless of the implication with flawing security, did he not spend several years supporting a project that much needed it? that work needs not be discarded :)
[12:51:55] <rawtaz> since they completely lost trust, anything that's kept from them needs to be 100% certain it cannot possibly contain anything shady, obviously
[12:53:45] <josuah> for finding a backdoor, sure. for security, all the code can benefit from some extra review, no?
[12:53:54] <negril> The malicious code was introduced in a very narrow timeframe of those two years
[12:53:55] <fullstop> I'm okay with wiping all of their contributions.  Code can be rewritten, but trust can not be regained.
[12:55:29] <josuah> negril: oh right, that makes some low-hanging fruit to quickly verify. Makes sense.
[12:55:48] *** Joins: Guest95 (~Guest95@cpc102338-sgyl38-2-0-cust532.18-2.cable.virginm.net)
[12:56:08] <negril> It also makes it likely there was a sudden shift in "motivation"
[12:56:15] *** Joins: Snetry (~snetry@87.122.107.24)
[12:56:31] *** Quits: beber_ (~beber_@2a05:d018:c28:1a00:fd:d0ae:0:5222) (Ping timeout: 255 seconds)
[12:56:51] *** Quits: sentry (~snetry@87.122.107.24) (Ping timeout: 268 seconds)
[12:57:05] <andreyv> xz worked fine for 10+ years before the bad actor was added. Just revert to the version before, it is not impossible. Keeping any "bad" commits will always cast shade.
[12:57:57] <andreyv> negril: The groundwork for this attack was laid more than a year ago
[12:58:38] <negril> What groundwork?
[12:59:32] *** Joins: Guest49 (~Guest49@49.204.128.117)
[12:59:45] <andreyv> the ifunc code
[12:59:55] *** Quits: teatkin (~tom@31.94.62.135) (Ping timeout: 240 seconds)
[13:00:09] *** Joins: teatkin (~tom@2a00:23ee:1198:1255:5839:7912:f57b:bde6)
[13:00:16] <negril> You say that as if there was no legitimate reason to use that
[13:02:00] *** Quits: Guest49 (~Guest49@49.204.128.117) (Client Quit)
[13:02:51] *** jghali__ is now known as jghali
[13:04:06] <josuah> ifunc?
[13:04:07] *** Joins: beber_ (~beber_@2a05:d018:c28:1a00:fd:d0ae:0:5222)
[13:04:10] <josuah>     liblzma: Add ifunc implementation to crc64_fast.c.
[13:04:13] <josuah>     Thanks to Hans Jansen for the original patch.
[13:04:18] <josuah> Author: Lasse Collin <lasse.collin@tukaani.org>
[13:04:30] <josuah> (that's ee44863)
[13:06:09] *** Joins: Guest67 (~Guest34@i577B1DAA.versanet.de)
[13:06:19] *** Quits: GlaringGeraldine (~GlaringGe@p5b071378.dip0.t-ipconnect.de) (Remote host closed the connection)
[13:07:20] <f_[xmpp]> I don't think Larhzu wrote that code.
[13:07:50] <andreyv> "Hans Jansen" is suspected to be another identity of the attacker. So they pushed for it in the first place.
[13:09:32] <andreyv> And they specifically needed ifunc because after that it is no longer possible to override sshd symbol addresses.
[13:10:14] <bernard__> it's pretty much confirmed it's the same attacker or works with him
[13:12:14] <negril> confirmed how? enough people repeated the claim?
[13:13:40] *** Joins: ultra980 (~ultra@2a02:2f0a:b308:4000:24f8:a1a0:33b3:fb43)
[13:14:02] *** Quits: Guest46 (~Guest46@pool-173-76-234-218.bstnma.fios.verizon.net) (Quit: Client closed)
[13:15:36] <bernard__> Hans Jansen <hansjansen162@outlook.com> >> Dear mentors, I am looking for a sponsor for my package "xz-utils":
[13:16:19] <bernard__> they are clear burners.. along with jigar kumar
[13:16:21] <bernard__> and others
[13:16:54] *** Quits: crawler (~crawler@user/crawler) (Quit: Leaving)
[13:17:16] <negril> So it's likely or certain. But not "confirmed"
[13:17:18] <f_[xmpp]> andreyv: Yes.
[13:17:33] <bernard__> very very likely
[13:17:51] <negril> yes, but confirmed would mean you have proof
[13:17:58] *** Joins: Risunen (~Risunen@88-113-0-20.elisa-laajakaista.fi)
[13:18:14] *** Quits: Risunen (~Risunen@88-113-0-20.elisa-laajakaista.fi) (Client Quit)
[13:18:23] <bernard__> you don't need proof. do you need proof jia has malicious intent too?
[13:18:58] <negril> We have proof for that? By what the code can be used for.
[13:19:20] <josuah> unreated to above few messages: https://bugs.gentoo.org/925415#c16
[13:19:46] *** Quits: Guest25 (~Guest34@ecs-119-8-243-91.compute.hwclouds-dns.com) (Quit: Client closed)
[13:20:08] <negril> josuah: read https://bugs.gentoo.org/925415#c20
[13:20:08] *** genr8eofl__ is now known as genr8eofl
[13:21:25] *** Quits: Guest21 (~Guest21@pool-72-87-118-229.prvdri.fios.verizon.net) (Quit: Client closed)
[13:21:42] *** Joins: Guest16 (~Guest41@103.216.220.39)
[13:23:39] <balrog> fwiw Easter Monday is a holiday in much of Europe
[13:24:49] *** Joins: Guest21 (~Guest21@pool-72-87-118-229.prvdri.fios.verizon.net)
[13:25:32] <Manis> xlib
[13:26:18] <josuah> Manis: hello, what about it?
[13:26:46] <josuah> negril: thank you! I read shortly after. it looks like a lot of ramifications of the contributions are plain legitimate bugfixes
[13:26:49] <Manis> josuah, ah, I hoped no one would notice the message 😀 I was in the wrong window ;-)
[13:27:23] <Rounin> Wait, are you telling me the American stock markets are open so I can feed my gambling addiction?
[13:27:51] <junon> bernard_: where did you find the Hans Jansen request for sponsorship message? Can you link me?
[13:27:59] *** Joins: at (~at@66.63.167.157)
[13:28:21] <negril> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1963514.html
[13:28:30] *** Joins: tty6 (~user@2a01:c22:90b6:2000:4b32:1da4:9155:c47d)
[13:29:18] <junon> Thank you. Hans was never a maintainer was he?
[13:30:13] <junon> By the way we were doing some poking around an extracted corpus of text from both Hans and Jia Tan and they both have similar plurality / conjugation mistakes. We don't have a linguistic analyst on hand but we might try to seek one out, would be interesting to get their take on it.
[13:30:15] <negril> no
[13:30:23] <junon> thanks negril, didn't think so.
[13:30:28] *** Parts: hjalmar (~katt__@147.28.162.171) (Leaving)
[13:32:47] *** Quits: Guest16 (~Guest41@103.216.220.39) (Quit: Client closed)
[13:33:00] *** Quits: Snetry (~snetry@87.122.107.24) (Ping timeout: 256 seconds)
[13:33:18] *** Joins: voxxit (~txt@user/voxxit)
[13:33:23] *** Joins: solsTiCe (~solsTiCe@user/solsTiCe)
[13:33:58] <tomreyn> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708 would be a better view of the above, incl. available mail headers.
[13:34:37] <vivia> junon: Sometimes this kind of mistakes comes from having the same native language, fwiw. Just mentioning - I agree that this needs a professional.
[13:35:24] *** Joins: Guest43 (~Guest43@2001:1838:200d:2:46c7:85d0:3a81:45a6)
[13:35:49] <f_[xmpp]> adrien: heh https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg6047567.html
[13:37:14] *** Joins: solsTiCe5 (~solsTiCe@user/solsTiCe)
[13:37:14] *** Joins: _0xdd (~miker@user/m1k3e221)
[13:37:47] <junon> vivia: right, but notably Hans Jansen is a nordic/germanic name, Jia Tan is not. But yes, we're not making any hastey conclusions until the time if/when an analyst comes to a conclusion.
[13:38:07] <junon> Could it be the case that Hans is referring to being a maintainer of the debian package specifically?
[13:38:20] *** Quits: solsTiCe (~solsTiCe@user/solsTiCe) (Killed (NickServ (GHOST command used by solsTiCe5)))
[13:38:23] *** solsTiCe5 is now known as solsTiCe
[13:39:08] *** Quits: voxxit (~txt@user/voxxit) (Quit: My MacBook has gone to sleep. ZZZzzz…)
[13:39:32] <junon> Or, better put, was Hans the debian package maintainer?
[13:39:44] <negril> junon: yes, see the non-maintainer-upload 
[13:39:50] *** Joins: Snetry (~snetry@87.122.107.24)
[13:40:46] <josuah> Regardless of any threat, would it make sense to withdraw the ((__ifunc__)) features? They seemed like being causing a few troubles downstream.
[13:40:58] <negril> it's the same as proxy-maintainers in gentoo
[13:41:52] *** Quits: at (~at@66.63.167.157) (Ping timeout: 250 seconds)
[13:42:26] <supakeen> Specifically for Debian it means someone isn't a packager, they still have to ask approval and review for each update they submit.
[13:43:14] <junon> Gotcha, thanks for the information.
[13:43:20] <supakeen> s/packager/maintainer.
[13:43:25] *** Quits: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi) (Ping timeout: 260 seconds)
[13:43:29] <supakeen> I think packager is other-distro terminology.
[13:44:02] *** Joins: hannula (~hannula@mobile-access-6df05f-224.dhcp.inet.fi)
[13:44:27] *** Joins: crawler (~crawler@user/crawler)
[13:44:34] *** Joins: panorain (~panorain@user/panorain)
[13:45:00] <josuah> well, at least, that revealed a handful of bugs at the junction of GCC, Valgrind, and some profiling tools
[13:46:23] <bernard__> does mail-archive.com return a SSL_ERROR_BAD_MAC_READ ?
[13:46:47] <josuah> bernard__: do you have a full URL?
[13:47:08] <bernard__> https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg6047567.html
[13:47:11] <josuah> this might matter for troubleshooting redirections, dns common name, etc.
[13:47:12] <josuah> thanks!
[13:47:19] <bernard__> it was returning 503 earlier.. odd
[13:47:26] <josuah> I see it too
[13:47:53] <josuah> Error code: SSL_ERROR_BAD_MAC_READ
[13:49:38] *** Joins: hmnxynhiaz_ (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz)
[13:49:41] *** Quits: hmnxynhiaz (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz) (Read error: Connection reset by peer)
[13:49:41] *** Quits: sgm (~sgm@gateway/tor-sasl/sgm) (Remote host closed the connection)
[13:49:41] *** Quits: Tuvix (~Tuvix@gateway/tor-sasl/tuvix) (Remote host closed the connection)
[13:49:41] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Remote host closed the connection)
[13:49:41] *** Quits: opal (~wowaname@gateway/tor-sasl/wowaname) (Remote host closed the connection)
[13:49:43] *** Quits: guilhem (~nobody@debian/guilhem) (Remote host closed the connection)
[13:49:56] *** Quits: vegard_no (~vegard_no@anice-653-1-505-141.w86-205.abo.wanadoo.fr) (Quit: Client closed)
[13:50:53] <josuah> bernard__: [Bug 2059417] Re: Sync xz-utils 5.6.1-1 (main) from Debian unstable (main) -- https://www.mail-archive.com/ubuntu-bugs%40lists.ubuntu.com//maillist.html#6047566
[13:51:46] <josuah> https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417
[13:52:14] <josuah> https://archive.is/jFGCt
[13:52:28] <bernard__> yep it works again
[13:53:08] *** Quits: zoneroyadmin (~zoneroyad@178-251-151-7.ftth.kajonet.fi) (Ping timeout: 250 seconds)
[13:53:29] *** Joins: zoneroyadmin (~zoneroyad@178-251-151-7.ftth.kajonet.fi)
[13:53:45] *** Joins: Tuvix (~Tuvix@gateway/tor-sasl/tuvix)
[13:53:46] *** Joins: guilhem (~nobody@debian/guilhem)
[13:53:47] *** Joins: sgm (~sgm@gateway/tor-sasl/sgm)
[13:54:44] *** Joins: beforelight (~user@32-218-57-192.bng02.brpt.ct.frontiernet.net)
[13:55:28] *** Joins: vegard_no (~vegard_no@anice-653-1-505-141.w86-205.abo.wanadoo.fr)
[13:56:14] *** Quits: genr8eofl (~genr8eofl@user/genr8eofl) (Remote host closed the connection)
[13:59:03] *** Quits: r2rien (~r2rien@37.171.195.186) (Ping timeout: 256 seconds)
[13:59:41] *** Quits: erk (~erk@85.10.149.145) (Changing host)
[13:59:41] *** Joins: erk (~erk@user/meow/erk)
[14:01:04] *** Joins: Guest58 (~Guest58@2a02:768:6208:8136:e8ff:4079:b1e7:4465)
[14:01:14] *** Quits: Guest58 (~Guest58@2a02:768:6208:8136:e8ff:4079:b1e7:4465) (Client Quit)
[14:01:59] *** Quits: hmnxynhiaz_ (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz) (Remote host closed the connection)
[14:01:59] *** Quits: guilhem (~nobody@debian/guilhem) (Remote host closed the connection)
[14:02:14] *** Joins: guilhem (~nobody@debian/guilhem)
[14:02:23] *** Joins: hmnxynhiaz_ (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz)
[14:03:33] *** Quits: teatkin (~tom@2a00:23ee:1198:1255:5839:7912:f57b:bde6) (Ping timeout: 255 seconds)
[14:04:10] *** Joins: opal (~wowaname@gateway/tor-sasl/wowaname)
[14:04:58] *** Joins: spacespork (~satan@user/spacespork)
[14:05:09] *** Joins: Guest42 (~Guest42@167.224.214.200)
[14:05:11] *** Quits: hmnxynhiaz_ (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz) (Remote host closed the connection)
[14:05:37] *** Joins: hmnxynhiaz_ (~hmnxynhia@gateway/tor-sasl/hmnxynhiaz)
[14:07:18] *** Quits: Tuvix (~Tuvix@gateway/tor-sasl/tuvix) (Remote host closed the connection)
[14:07:38] *** Joins: Tuvix (~Tuvix@gateway/tor-sasl/tuvix)
[14:10:52] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[14:11:09] *** Joins: genr8eofl (~genr8eofl@user/genr8eofl)
[14:13:15] *** Quits: dostoyevsky2 (~sck@user/dostoyevsky2) (Quit: leaving)
[14:13:36] *** Joins: dostoyevsky2 (~sck@user/dostoyevsky2)
[14:14:09] *** Quits: Guest23 (~Guest23@78.143.78.15) (Quit: Client closed)
[14:14:21] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[14:16:02] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Read error: Connection reset by peer)
[14:16:21] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[14:21:55] *** Quits: Celelibi (celelibi@user/meow/Celelibi) (Ping timeout: 240 seconds)
[14:22:53] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Read error: Connection reset by peer)
[14:22:53] *** Quits: hannula (~hannula@mobile-access-6df05f-224.dhcp.inet.fi) (Read error: Connection reset by peer)
[14:23:11] *** Joins: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi)
[14:23:13] *** Quits: Guest42 (~Guest42@167.224.214.200) (Quit: Client closed)
[14:23:15] *** Joins: r2rien (~r2rien@37.171.197.204)
[14:24:00] <spacespork> just finished skimming through all of Tan's translation commites, none seem odd
[14:24:16] <spacespork> *since feb 15
[14:24:35] *** Quits: blb (~blb@user/meow/blb) (Ping timeout: 256 seconds)
[14:25:16] *** Joins: blb (~blb@user/meow/blb)
[14:25:24] *** Quits: guiambros (~guiambros@pool-100-33-241-112.nycmny.fios.verizon.net) (Ping timeout: 264 seconds)
[14:26:09] <adrien> f_[xmpp]: yep, got conned! but due to too much work with something else, I didn't do anything more than a couple bug reports basically!
[14:26:30] <Steffanx> spacespork i wonder how many did that by now :P
[14:26:42] *** Joins: Celelibi (celelibi@user/meow/Celelibi)
[14:27:20] <adrien> Ubuntu has been lucky due to all this happening at the same time as the t64 transition (Y2038 support for armhf) which prevented xz 5.6.0 from getting out of -proposed and even being actually installable (dependencies were unresolvable)
[14:27:28] <spacespork> Steffanx: your right, but im the first one Ive seen talking about it hear, so hopefully it put the nail in the coffin
[14:27:33] <adrien> and that, despite Ubuntu likely being the main target
[14:27:44] *** Joins: tonyoy (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr)
[14:27:50] <spacespork> debian was likely the main target
[14:27:54] *** Quits: tty6 (~user@2a01:c22:90b6:2000:4b32:1da4:9155:c47d) (Remote host closed the connection)
[14:28:08] <cjwatson> I'm not sure we have any idea who the main target was.
[14:28:24] *** Quits: r2rien (~r2rien@37.171.197.204) (Ping timeout: 264 seconds)
[14:28:26] <adrien> well, I was in contact with Jia Tan and in time for Ubuntu 24.04 Noble was a goal
[14:28:27] <cjwatson> You don't put this amount of effort in unless you want to leverage it into something bigger somehow.
[14:28:42] <spacespork> only debain and redhat were affeected, thus they were the main targets
[14:28:58] <cjwatson> spacespork: Ubuntu inherits from Debian in this respect
[14:29:04] <cjwatson> (and in most respects)
[14:29:08] <spacespork> true
[14:29:11] <adrien> next Debian release is more than a year from now (freeze duration in debian is also pretty long, maybe not a great idea)
[14:29:14] <spacespork> it was also affected
[14:29:26] <adrien> fedora got it but it doesn't have LTS releases AFAIK while Ubuntu has
[14:29:33] <cjwatson> But I'd have guessed that distributions were means to some larger end ... who knows
[14:29:42] <spacespork> but i would bet there are more deb systems run sshd than ubuntu
[14:30:01] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[14:30:04] <cjwatson> spacespork: Ubuntu runs in a ridiculously enormous number of cloud installations
[14:30:07] <adrien> ubuntu is the main distribution "in the cloud"
[14:30:16] <cjwatson> I would take your bet on that and expect to win
[14:30:27] <spacespork> so does deb
[14:30:39] <adrien> now, how many sshd; I don't know but the timeline matches ubuntu better than debian
[14:30:43] <supakeen> Timing wise CentOS 10 Stream starts as well with Fedora 40 :)
[14:30:51] <supakeen> So there's plenty of interesting timings.
[14:30:55] *** Joins: Guest59 (~Guest59@p5dc70edf.dip0.t-ipconnect.de)
[14:31:12] <spacespork> timing i think tan was caught earlier than he thought
[14:31:24] <dstolfa> cjwatson: not just cloud, it's pretty common as the go-to linux desktop in many orgs in my experience
[14:31:33] <adrien> I'm not familiar with RH timelines and I can't compare; all I can say is that Ubuntu was at least one of the main target, which is backed by https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417
[14:31:58] <cjwatson> This is just like the first result from a web search and I have no idea how trustworthy it is, but https://www.enterpriseappstoday.com/stats/linux-statistics.html has Ubuntu as being about 2x Debian.  (I'm a developer of both so have no particular bias)
[14:32:06] <kevans> i don't think you can meaningfully derive anything about their main target by where they tried to push for it
[14:32:17] <nomadgeek> I'd bet Tan had to fastforward their plan because of the systemd change that was in the pipe.
[14:32:20] <supakeen> I think it's a given since the exploit was targetting both .deb and .rpm generation and both downstreams were contacted to update.
[14:32:20] <spacespork> i also think it ateficially avoided arch and gentoo bc thats what sam and lasse run
[14:32:32] <dstolfa> kevans: +1
[14:32:33] <kevans> if i was executing this attack i'd 100% throw in a bunch more targets than I care about
[14:32:52] <spacespork> true
[14:33:13] <spacespork> like i said, i think tan was avoiding gentoo and arch
[14:33:45] <TrevorH> but if you cover ubuntu/debian/fedora and later on, RHEL then you have about 95% of the available instances
[14:33:59] <spacespork> exactly
[14:34:01] <negril> more targets mean you are more likely to be discovered
[14:34:26] <spacespork> negril: which is why he avoided arch and gentoo
[14:34:29] <TrevorH> true
[14:34:39] *** Joins: tty6 (~user@2a01:c22:90b6:2000:4b32:1da4:9155:c47d)
[14:34:44] <TrevorH> it's a shame no-one knows the motivation behind this
[14:34:47] <negril> or they were not used by the intended targets
[14:35:23] <adrien> btw, does anyone have a link to the systemd change? I didn't immediately find it when searching for it a couple days ago
[14:35:40] <spacespork> which systemd change?
[14:35:58] <negril> The attack vector was going to be removed. one sec
[14:36:08] <cjwatson> https://github.com/systemd/systemd/pull/31550 ?
[14:36:15] <spacespork> ah
[14:36:24] <kevans> more targets != more likely to be discovered, no. most packagers aren't really auditing what they update to anywhere near closely enough to state that as fact
[14:36:38] <adrien> gentoo is probably a more difficult target when you're shipping .o files: valgrind issues were due to slight and unexpected code layout and they are probably going to vary much more on gentoo systems compared to binary distributions
[14:36:52] <adrien> cjwatson: thanks!
[14:36:57] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[14:37:26] <kevans> hell, I'd put $$ on sam_ not even noticing for a while, but that's a higher risk
[14:37:41] <kevans> and they pay more attention
[14:37:46] <spacespork> adrien: from what we know i dont think gentoo couldve been affected, A) gentoo is not a systemd distro, B) the issue comes from the blobs
[14:38:27] <adrien> cjwatson: thanks
[14:38:40] <negril> kevans: the real gcc bug masked a part of the problem
[14:38:56] <adrien> time-wise, I think ubuntu 24.04 (LTS) was announced as a target already before the systemd PR was opened
[14:39:54] <adrien> spacespork: yup, definitely; and now I wonder about other failures that could have happened on source-based distros
[14:40:18] <spacespork> gcc is a bigger problem than its getting credit for, its a huge clusterfuck
[14:41:55] <negril> spacespork: gentoo does support systemd and builds install media for it. the blobs were present in gentoo. Just the openssh patch was missing there. (plus the deb/rpm checks fail)
[14:42:36] <spacespork> negril: I know they do, but they still maintain they are not a systemd distro
[14:43:04] <negril> not systemd-only, yes. it's agnostic
[14:43:44] <spacespork> I know that, you know that, but go to their website and itll say theyre not a systemd distro (last time i checked
[14:44:35] <adrien> negril: the hidden build system checked for deb or rpm, which excludes gentoo and arch among others
[14:45:22] <xx> Since this is the place where current things are happening, I'm looking for advice on how to report tampering with gnupg source code ~10 years ago that was subtle, was noticed already (so it's not under embargo) but nothing was done about it. Do I just do a writeup and send it to oss-security, and don't need to bother with any sort of coordinated disclosure?
[14:45:30] *** Joins: Guest60 (~Guest73@65.51.53.211)
[14:45:50] <negril> adrien: that's what I've said
[14:49:10] <spacespork> i also feel like this is showing a bigger problem in that the systemd guys and the openssh guys don't like talking to each other (or anyone for that matter)
[14:50:27] *** Quits: Leviticoh (~Leviticoh@user/Leviticoh) (Quit: WeeChat 4.2.1)
[14:52:15] <Guest60> open source is volunteer work, there is no obligation for anyone to talk to anyone lol
[14:52:46] <kevans> it's not clear why you think openssh folks need a systemd burden, that's extra complexity and more to audit
[14:52:57] <cjwatson> I think we're on a path to sorting out the openssh/systemd interactions, admittedly as a result of all this
[14:53:17] <cjwatson> accurate readiness notification in daemons really is useful for overall system reliability
[14:53:35] *** Joins: lurker002 (~lurker002@73.60.40.214)
[14:53:35] <Guest60> the systemd response was really "O you dont need libsystemd for that" heh
[14:53:39] <cjwatson> but it can be done more economically
[14:53:43] <spacespork> no i dont think they need to talk, hell im a systemd hater, but they could tell us theyre not maintaining the patch
[14:54:20] <spacespork> also if im not mistaken, system is maintained by redhat, so not volunteer work
[14:54:26] <spacespork> *systemd
[14:54:32] <cjwatson> eh that's kind of misleading
[14:54:47] <spacespork> cjwatson: which part?
[14:55:12] <cjwatson> sure, Poettering worked for RH when he started systemd; he doesn't any more, and there are also a bunch of other parties involved
[14:55:38] <cjwatson> even as a non-RH person I think "it's maintained by redhat" is kind of reductive and not usefully accurate
[14:56:11] <TrevorH> it's unfortunate that systemd is involved in this because now all discussion seems to end up talking about systemd
[14:56:24] <spacespork> yeah bc systemd sucks
[14:56:30] <cjwatson> sigh PRODUCTIVE
[14:56:42] <kevans> what does any of that have to do with the current situation? the attack vector still exists either way because these distros want systemd integration
[14:56:43] *** Joins: Mooncairn (~mooncairn@user/mooncairn)
[14:56:48] <cjwatson> maturity levels are somehow down the toilet
[14:57:15] <spacespork> cjwatson: sorry, it just needed to be said, im done now
[14:57:48] <eam> more useful to say: there are improvements that could be made to the systemd architecture vis a vis security
[14:57:50] *** Joins: mali (~malina@user/malina)
[14:57:56] <kevans> you're asking for more openssh maintenance hassle with no basis
[14:58:11] <spacespork> no im not
[14:58:32] <spacespork> lets move on, what was said was said but lets be productive
[14:59:36] <andreyv> kevans: The current situation is not a techical problem. Had sshd not linked to systemd, the attacker would've looked for another way.
[15:00:09] <Guest60> yea, liblzma is linked to tons more stuff, including basically every programming language via libxml2
[15:00:18] <Guest60> plenty of applications that could have been targetted
[15:00:29] <spacespork> andreyv: we dont really know that, Tan couldv been being opertunistic
[15:00:57] <supakeen> If someone is being opportunistic there are lower hanging fruits than this saga.
[15:01:19] <Guest60> this was a longcon with explicit goal of burying a deep cover exploit
[15:01:23] <andreyv> Investing 2+ years is not really opportunistic, it is targeted
[15:01:30] <spacespork> but we should move navelgazing about the nature of the attack to another channel
[15:01:35] <Guest60> theres even an extension system for add more exploits silently into the tests folder over time
[15:01:43] <kevans> andreyv: yes, agreed
[15:01:57] <spacespork> i still dont think he went into this two years ago with this in mind
[15:02:18] <Guest60> you say that, but the timezones in his commits go back the entire time
[15:02:28] <Guest60> i.e. the flip flopping of timezone between asia and eastern europe
[15:02:36] <kevans> i don't think it's useful to speculate either way (originally motivated or not), tbh
[15:03:03] <spacespork> i think it is usufell but i dont think its what we should be using this channel for
[15:04:12] <spacespork> *useful
[15:04:14] *** Quits: duxsco (~duxsco@user/duxsco) (Quit: WeeChat 4.2.1)
[15:04:42] *** Joins: duxsco (~duxsco@user/duxsco)
[15:06:07] <cjwatson> if you were trying to analyse my timezone from my commits then I'd be in trouble
[15:06:41] <TrevorH> mine would vary from mid-atlantic to mid-pacific :-)
[15:07:39] <spacespork> im not conviced of the timezone thing, while most malicious commits were made at the "odd" time, there were malicious ones at his normal times, and normal commits at "odd" times
[15:07:55] <spacespork> *convinced
[15:08:24] <Guest60> the point was in the same day of commits, it varied timezones
[15:09:02] <spacespork> but that was true for not malicious commits
[15:09:18] <spacespork> too
[15:09:23] *** Quits: Guest67 (~Guest34@i577B1DAA.versanet.de) (Ping timeout: 250 seconds)
[15:11:38] *** Quits: pajlada (~pajlada@user/pajlada) (Remote host closed the connection)
[15:12:02] *** Joins: pajlada (~pajlada@user/pajlada)
[15:12:03] *** Quits: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu) (Read error: Connection reset by peer)
[15:13:08] *** Quits: linuxdaeMEOW (linuxdemon@user/linuxdaemon) (Changing host)
[15:13:08] *** Joins: linuxdaeMEOW (linuxdemon@user/meow/linuxdaemon)
[15:13:11] *** Joins: Cass (uid609017@user/meow/dax)
[15:13:19] *** Joins: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu)
[15:14:58] *** Quits: zipace (~john@p200300ecef4b42c3742021ec9695ad1b.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
[15:18:48] *** Quits: steckie (~steckie@p54b6fe0d.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
[15:22:55] <q3k> https://github.com/amlweems/xzbot
[15:25:27] *** Quits: spacespork (~satan@user/spacespork) (Quit: leaving)
[15:27:51] *** Quits: panorain (~panorain@user/panorain) (Quit: Konversation terminated!)
[15:29:08] <TrevorH> q3k++
[15:32:59] <rurapenthe> Lo spacespork, everyone
[15:34:24] <int-e> q3k: really cool
[15:36:20] <catia> wow
[15:41:38] <bernard__> cool however the dude or team is not going to be doing any mass scans or attempts now that it's been discovered
[15:41:54] *** Joins: Guest13 (~Guest13@2a02:810d:b83f:e400:16a0:2f96:e202:fd52)
[15:42:07] *** Joins: smpl (~smpl@user/smpl)
[15:45:02] *** Joins: Fingel (~Fingel@user/fingel)
[15:45:55] <Steffanx> Who knows...
[15:46:13] <int-e> they may have IPs to burn
[15:46:52] <int-e> but it's also nice to see the pieces put together and see the actual remote code execution.
[15:47:18] *** Parts: ndesaulniers (sid510531@id-510531.lymington.irccloud.com) ()
[15:47:22] <int-e> (with a different Ed448 key of course)
[15:50:04] *** Quits: Fingel (~Fingel@user/fingel) (Quit: Fingel)
[15:53:09] *** Quits: zoneroyadmin (~zoneroyad@178-251-151-7.ftth.kajonet.fi) (Ping timeout: 250 seconds)
[15:53:19] *** Quits: Square2 (~Square@user/square) (Ping timeout: 252 seconds)
[15:53:30] <bernard__> int-e: without a doubt
[15:55:22] *** Quits: rurapenthe (~None@102.132.133.163) (Quit: This computer has gone to sleep)
[15:57:42] *** Joins: test230117 (~Thunderbi@118.45.150.30)
[15:58:43] *** Joins: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de)
[15:59:13] *** Quits: oldfashionedcow (~Cow@user/oldfashionedcow) (Changing host)
[15:59:13] *** Joins: oldfashionedcow (~Cow@user/meow/oldfashionedcow)
[16:00:17] *** Parts: lurker002 (~lurker002@73.60.40.214) ()
[16:03:37] *** Quits: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[16:03:50] *** Joins: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi)
[16:03:54] *** Quits: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
[16:11:36] *** Joins: filipe (~ffernand@user/ffernand)
[16:11:52] *** Quits: Guest14 (~Guest14@174.30.40.113) (Quit: Client closed)
[16:12:38] *** Joins: Guest62 (~Guest62@2620:0:e00:5565:ddd9:e97f:7cd8:9c78)
[16:14:11] *** Joins: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8)
[16:14:39] <krushia> how many people were in this channel a week ago?
[16:15:43] *** Quits: Guest62 (~Guest62@2620:0:e00:5565:ddd9:e97f:7cd8:9c78) (Client Quit)
[16:15:49] <Steffanx> 10
[16:16:02] <Steffanx> is what someone here claimed
[16:16:27] *** Joins: Guest52 (~Guest52@2a09:bac2:53c1:505::80:155)
[16:17:01] <krushia> thanks. hard to tell from https://netsplit.de/channels/details.php?room=%23tukaani&net=Libera.Chat
[16:17:22] <dostoyevsky2> int-e: I wonder if one could scan locally for the exploit... but I guess they could simply hide themselves... and without the key one can't scan from other servers
[16:17:23] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[16:17:53] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[16:17:54] <dostoyevsky2> maybe from a rescue disk
[16:20:53] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[16:21:23] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[16:24:35] <bhaible> Guest60: The "flip flopping of timezone between asia and eastern europe" is explained when you look at the output of "git log --pretty=fuller". When Jia Tan submitted a patch and Lasse Collin committed it, the time zone is +0200. When Jia Tin committed himself, the time zone is +0800.
[16:25:09] *** Joins: panorain (~panorain@user/panorain)
[16:25:24] *** Joins: Fingel (~Fingel@user/fingel)
[16:26:01] *** Joins: kiveris52 (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8)
[16:26:31] *** Quits: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8) (Ping timeout: 250 seconds)
[16:27:01] *** Quits: bret (~bret@user/bret) (Remote host closed the connection)
[16:27:38] *** Joins: bret (~bret@user/bret)
[16:27:57] *** kiveris52 is now known as kiveris
[16:29:09] <TrevorH> good explanation
[16:29:21] <Larhzu> Hello
[16:29:59] *** Quits: Guest13 (~Guest13@2a02:810d:b83f:e400:16a0:2f96:e202:fd52) (Ping timeout: 250 seconds)
[16:30:11] *** Joins: steckie (~steckie@p54b6fe0d.dip0.t-ipconnect.de)
[16:30:14] <Larhzu> krushia: About ten, most had been a very long time.
[16:31:04] *** Quits: Guest52 (~Guest52@2a09:bac2:53c1:505::80:155) (Quit: Client closed)
[16:31:19] <orkim> oooh.. incoming flood of activity.. prepare..
[16:31:36] <Guest60> ?
[16:31:45] <krushia> Larhzu: I suppose the upside is that you have lots of new friends now :)
[16:32:20] <bernard__> orkim: ?
[16:32:35] <bernard__> unless there are any big developments this is going to die pretty quickly
[16:35:04] *** hmnxynhiaz_ is now known as hmnxynhiaz
[16:35:05] <Larhzu> aesthetics: Donations on tukaani.org -- There are higher priority things now.
[16:36:08] <s1gyn> It might lead to more stuff like this being found in other projects though bernard__.
[16:36:27] <vivia> Larhzu: welcome back :)
[16:36:40] *** Quits: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8) (Changing host)
[16:36:40] *** Joins: kiveris (~kiveris@user/meow/kiveris)
[16:37:22] <Larhzu> steckie: License change was my idea. It's unrelated to the problem at hand.
[16:37:27] *** Quits: terabit (terabit76@about/hackers/terabit) (Quit: Client closed)
[16:37:30] <s1gyn> hello Larhzu, sorry about this mess.
[16:38:09] *** Joins: terabit (terabit@about/hackers/terabit)
[16:39:42] <Larhzu> s1gyn: Thanks
[16:40:03] *** Parts: Cass (uid609017@user/meow/dax) ()
[16:40:18] <stefk> s1gyn: that's what I'm interested in as well. You won't find a different attack vector from this same identity (if you lose one like now, others will be found) among the 700+ commits. I'm more curious about other similar projects that fit the XKCD dependency comic
[16:40:36] <Larhzu> I have lots of email about people expressing sympathy. I'm grateful but let's keep such messages away from IRC because there is plenty of messages anyway. :)
[16:41:12] <vivia> We're glad you're getting support :)
[16:42:13] <Larhzu> I'm not reading any news about this for now. I'm making some plans about how to proceed: collecting facts, writing an article about what I know, and getting the codebase into trustable state.
[16:43:23] <Larhzu> vivia: Nice messages are nice but there is plenty of things to do and so I need to focus on that.
[16:44:16] <Larhzu> I don't mean to be rude with this.
[16:44:39] <vivia> Larhzu: Completely understandable.
[16:47:14] <dstolfa> Larhzu: i'd be interested in your take on committing binary archives into the repository after this (especially generated ones), given how easily payloads can be hidden in there without any good way to detect them without already knowing they're there
[16:47:37] <dstolfa> perhaps something for the article :)
[16:48:33] <Larhzu> That's on the list.
[16:48:37] *** Quits: nozaq (nozaq@user/nozaq) (Ping timeout: 250 seconds)
[16:48:40] *** Joins: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk)
[16:48:46] <dstolfa> great, thanks
[16:49:30] <Larhzu> I don't want to speak too much about the plans right now because things aren't well organized in my head yet.
[16:49:46] <Larhzu> I suppose the situation is such that people wish for every bit of information they can get.
[16:50:03] <dstolfa> no worries, i fully understand. i just wanted to bring it up because i'd be interested to read about it in the article you're writing
[16:50:04] <Larhzu> And when they get a bit they extrapolate/speculate and it likely goes wrong.
[16:50:12] <orkim> I'm pretty sure I know the answer to this, but has anyone received any communication from/with Jia since this broke?
[16:50:46] <Larhzu> The last SECURITY.md commit was such a good example, people thinking it was Jia being malicious while the commit was my suggestion, except that I also wished to change 90 days to 30 days (or even less).
[16:51:17] <Larhzu> I haven't but I understood we both would be offline the days matching the Easter.
[16:51:39] <orkim> Got it.. Thanks Larhzu
[16:51:57] <stefk> Larhzu: there's a gossip camp and code analysis one it seems yes ;)
[16:52:06] <Larhzu> I need to add some things to the xz-backdoor page. Reporters want more info and I won't reply to most people who wish me well.
[16:52:55] <Larhzu> What I read about the code analysis side, the exploit is sophisticated. That's interesting but it's not what I plan to write.
[16:52:56] *** Quits: Rijenkii (~Rijenkii@78.142.230.108) (Ping timeout: 250 seconds)
[16:53:36] <dstolfa> i'm also fairly convinced that the use of a modified rc4 was intentional, probably to match the entropy of the PRNG used to generate the rest of the random data in the test
[16:53:49] <dstolfa> quite sophisticated indeed
[16:54:47] <Larhzu> I want to understand and explain how the exploit got into the package past me. I have some clue already but collecting all info will take a few days and writing a few days too.
[16:54:56] *** Quits: Guest95 (~Guest95@cpc102338-sgyl38-2-0-cust532.18-2.cable.virginm.net) (Quit: Client closed)
[16:55:26] <s1gyn> Have you ever met them in person?
[16:55:37] *** Joins: falsifiability (~falsifiab@user/falsifiability)
[16:55:53] <Larhzu> I won't withhold info that shows my mistakes. I understand people might interpret such things in various ways (not just positively).
[16:56:48] <Larhzu> With my article plan the important thing is to provide as much info as possible that will help others that might get targeted.
[16:57:32] *** Quits: midou (~midou@sl.projectsegfau.lt) (Ping timeout: 256 seconds)
[16:58:32] <Larhzu> s1gyn: Me met Jia?
[16:58:43] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Ping timeout: 256 seconds)
[16:58:50] <s1gyn> yeah
[16:58:56] <Larhzu> I speak of Jia as a single person but perhaps some word is needed for the team behind.
[16:59:00] <Larhzu> No
[16:59:04] *** Joins: spacespork (~satan@user/spacespork)
[16:59:28] <Larhzu> On the other hand, very few software devs have met me.
[16:59:37] <s1gyn> Larhzu: yeah, that's exactly what I was thinking, although they could have had "spokesperson".
[16:59:48] <Larhzu> Capcom
[17:00:05] <bernard__> capcom?
[17:00:54] <Larhzu> https://en.wikipedia.org/wiki/Flight_controller#CAPCOM
[17:01:21] <Larhzu> All communication going via a single person.
[17:03:11] *** Joins: midou (~midou@sl.projectsegfau.lt)
[17:04:26] <FH_thecat> Larhzu: could there be more backdoors in other places ?
[17:04:31] *** Quits: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi) (Read error: Connection reset by peer)
[17:04:43] *** Joins: hannula (~hannula@81-197-12-63.elisa-laajakaista.fi)
[17:04:53] <kevans> the answer is always 'yes'
[17:04:53] *** Quits: panorain (~panorain@user/panorain) (Quit: Konversation terminated!)
[17:05:11] *** Joins: panorain (~panorain@user/panorain)
[17:05:29] <kevans> you can't really speculate on that in the current state, anything's possible
[17:05:42] <Larhzu> FH_thecat: Assuming you meant to ask if I suspect something specific, no.
[17:06:05] <Larhzu> I try to avoid speculation, it goes wrong too easily.
[17:06:21] <dnsmcbr> Larhzu: Good thing you weren't in this room over easter then
[17:06:28] <spacespork> FH_thecat: there is the possibility that there is more malicious code in the binaries that we are in the process of decompiling, but i have spent the past few days searching through Tan's other commits looks for any other oddities and i have found nothing
[17:06:35] <mspo> BSD-levels of paranoia avoids danger (2021) https://github.com/libarchive/libarchive/pull/1595 (but some PRs were later accepted into libarchive)
[17:07:47] <spacespork> we should also look for other ways libsystemd might call liblzma
[17:08:34] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[17:10:09] <Noisymeow> mspo: Is there anything actually wrong in that PR?
[17:10:25] <xx> Larhzu: did you consider forking xz yourself into a new repo, where you rewrite the history to clear out the (infected) binary blobs?
[17:10:25] *** Quits: plat0 (~plato@p4fe6d824.dip0.t-ipconnect.de) (Remote host closed the connection)
[17:10:30] <Guest60> spacespork eh the systemd guys know what they are doing, the hard linker dependencies on liblzma and other crypto libraries was already removed 3 weeks ago
[17:10:32] <int-e> spacespork: or sshd
[17:10:38] <xx> just so that we don't have that essentially forever every time we git clone
[17:10:42] <Guest60> other archive lbiraries*
[17:11:19] <int-e> spacespork: and then extend your scrutiny to all the libraries that sshd can pull in. (including PAM, yay)
[17:11:43] <kevans> Noisymeow: the script is hideous abuse of bash-isms that don't need to be bash-isms
[17:11:48] *** Joins: Guest98 (~Guest95@cpc102338-sgyl38-2-0-cust532.18-2.cable.virginm.net)
[17:11:55] <spacespork> int-e: sshd never calls liblzma directly, so we need to be looking for libs that sshd calls that in turn call liblzma
[17:12:13] <kevans> (other than that it looks fine)
[17:12:34] <int-e> spacespork: I know, but you should not limit your focus to liblzma.
[17:13:01] *** Quits: Guest60 (~Guest73@65.51.53.211) (Quit: Client closed)
[17:13:32] <spacespork> int-e: so far personally i have only been looking through Tan's commits, this afternoon ill probbably get to work looking at libcalls
[17:13:44] *** Joins: mcury (~mcury@user/mcury)
[17:14:21] <Larhzu> xx: I haven't gotten that far, to think of history rewriting.
[17:14:32] *** Joins: nomadgee_ (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net)
[17:14:47] <Larhzu> I think such history rewrite, if desirable, would be among last steps.
[17:15:01] <xx> fair enough
[17:15:02] <Larhzu> As far as I understand, the test files are inert without a trigger.
[17:15:17] *** Joins: Guest93 (~Guest93@84-106-132-186.cable.dynamic.v4.ziggo.nl)
[17:15:17] <xx> they are inert, but disgusting to have on my drives
[17:15:19] <mspo> re funding - github makes it the easiest but some foundations (*bsd/asf/who knows) do grants for specific things sometimes
[17:15:19] *** Joins: aloisw (~aloisw@user/aloisw)
[17:15:27] *** Joins: Guest9 (~Guest9@82.77.169.172)
[17:15:28] <mspo> Noisymeow: download random shell scripts
[17:15:30] <FH_thecat> Larhzu: and was the IFUNC addition legitimate, or part of the backdoor ?
[17:15:32] <andreyv> Larhzu: xx: Note that old tags and commits in the same repository could also have been rewritten with malicious changes.
[17:15:42] <sh4> what would be interesting is chat logs of this chan while jia was here, so one can look at his writing style, and guess his TZ from hours of presence
[17:15:44] <Larhzu> xx: Understandable
[17:16:38] <xx> andreyv: it would be easy to compare the git clone from the new repo to the archived git repo, and see that the only changes are the removal of binary blobs
[17:16:47] <fullstop> Did Jia have clones of zstd on gh?
[17:16:54] *** Quits: nomadgeek (~nomadgeek@pool-96-253-98-252.rcmdva.fios.verizon.net) (Ping timeout: 252 seconds)
[17:17:04] <Larhzu> FH_thecat: IFUNC was legitimate addition but, as IRC logs[*] show, the number of bugs with the IFUNC made me seriously consider ripping it out completely. Jia wanted to keep it.
[17:17:20] <Larhzu> [*] I have logs and I hope some of channel regulars have too.
[17:17:50] <spacespork> sh4: someone create a graph of his commit history to try to find his tz, at first it seemed like the malicious commits were at a different time than his normal ones, but there are some discrepancies in this data that makes me sceptical
[17:18:06] <Larhzu> sam_, adrien: Do you have logs of this channel from the past months? I don't suggest publishing anything now, I just want to know if multiple people have logs.
[17:18:08] <sh4> i heard AI's are pretty good these days to identify people based on their writing (heck, even the unabomber was id'd that way 20+ years ago)
[17:18:15] <fullstop> when did this channel move from freenode?
[17:18:23] <Noisymeow> it's possible that commit times were faked
[17:18:38] <spacespork> unabomber was id'ed by his brother, not AI
[17:18:47] *** Quits: nullc4t (uid55386@user/nullvalue) (Quit: Connection closed for inactivity)
[17:18:52] <sh4> yeah, because he recognized the writing style
[17:19:30] <spacespork> yeah, so we gotta find Tan's brother and then he can id... oh wait
[17:19:30] <sh4> what i've seen so far jia's english was top notch
[17:19:50] *** Joins: Narrat (~omnius@p200300df5f132bfe06ea56fffe2e7cdc.dip0.t-ipconnect.de)
[17:20:04] *** Joins: plat0 (~plato@213.94.27.50)
[17:20:07] <sh4> no, you compare it to blogs, commit messages of other people, chat logs, facebook posts, etc
[17:20:10] <Larhzu> sh4: Timezone is +0800 (or so) at least. Majority of chat was on Signal.
[17:20:27] *** Joins: aloisw_ (~aloisw@user/aloisw)
[17:20:30] <spacespork> sh4: i spoke to sam yesterday and they didn't metion any oddities in tan english, but other than that idk
[17:20:51] *** Quits: mosesofmason (~admin@mediawiki/mosesofmason) (Remote host closed the connection)
[17:21:00] <Larhzu> xx: History rewrite means that commit ID references break. But if only a few dozen latest commits are rewritten then it's not that bad.
[17:21:45] *** Joins: mosesofmason (~admin@mediawiki/mosesofmason)
[17:21:57] <Larhzu> fullstop: When Libera Chat was created. This was on Freenode since 2007-2008 I guess.
[17:22:29] <fullstop> Most things moved immediately, I wasn't sure about this channel, though.  there should be a pretty complete history
[17:22:35] <xx> I've become a little allergic to having binary blobs committed to repositories, instead of instructions/scripts on how to generate the blobs
[17:22:43] <andreyv> xx: Might not be sure that the only bad changes are the binary blobs…
[17:22:47] <Larhzu> His English was at the same level as mine. Perhaps some errors were different but not much.
[17:22:58] <stefk> sh4: I didn't read much but there's repeated wrong "its" usage at least
[17:23:01] <xx> andreyv: I'm going by what we know with 100% certainty
[17:23:06] <Larhzu> I suspect my writing style is quite easy to notice. ;)
[17:23:24] <loganaden> i bet my money on chinese companies like i-soon
[17:23:51] <xx> I bet on CIA AGENT JOHN /s
[17:24:10] *** Quits: aloisw (~aloisw@user/aloisw) (Ping timeout: 256 seconds)
[17:24:23] *** aloisw_ is now known as aloisw
[17:24:28] <Larhzu> xx: See tests/files/README, most files are created in hexeditor by me. Thus those are the source code. The new files however... I wanted generator programs but I'll save the details for later, sorry.
[17:24:46] <sh4> Larhzu, were you contacted by some sort of police ?
[17:24:47] <xx> no worries
[17:25:23] *** Joins: Guest399 (~Guest399@194.127.199.53)
[17:25:34] <Larhzu> sh4: No
[17:25:56] <Larhzu> But hasn't been normal work days either due to Easter.
[17:26:44] <fullstop> Larhzu: I was going through commit histories and looking for things like "realize" vs "realise" and noticed that you use the z form.  Is that common for Finns?
[17:27:23] <Larhzu> fullstop: I have no idea. I know I have some preference to US English because color is shorter than colour. And Commodore 128 had "color" command. ;)
[17:27:33] <fullstop> lol
[17:27:35] <balrog> Larhzu: unrelated to the project itself I suggest preserving / backing up any emails or other data (logs etc) that could contain IP addresses or other information of Jia Tan or similar people, mostly in case government cybersecurity organizations doing an investigation contact you
[17:27:44] <Larhzu> In practice I likely mix UK/US English without knowing it myself.
[17:27:59] <balrog> (Also I would not provide that to any random person, only properly identified law enforcement or government organizations)
[17:28:13] *** Joins: phishing_pharao (~phishing_@ip-037-201-116-138.um10.pools.vodafone-ip.de)
[17:28:19] <Larhzu> balrog: Sure
[17:28:34] <Celelibi> God, so much activity here and on oftc. I hope the FAQ in the topic will keep being updated.
[17:28:45] <sh4> balrog, yeah because those can be trusted
[17:28:54] <Larhzu> balrog: I would be positively surprised if tracking was possible though.
[17:29:27] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[17:29:35] * kevans notes that Larhzu is a lot more patient than he would be in the same situation
[17:29:54] <balrog> Larhzu: yeah, but considering that it looks like Jia Tan slipped a few times with timezones, it's possible he slipped up elsewhere as well
[17:30:25] <supakeen> Larhzu: What would be your current preferred way of receiving patches? E-mail?
[17:30:57] <stefk> fullstop: last time I checked it seemed en-gb (hmm or I should say the UK or something I guess) was moving to more usage of Z
[17:31:09] <Larhzu> kevans: Based on emails, people assume I'm feeling terrible, especially due to depression history.
[17:31:47] <Larhzu> kevans: That's logical but apart from too little sleep (too much sitting indoors playing boardgames) I'm not down.
[17:32:29] <Larhzu> kevans: I have been better in the past several months.
[17:32:42] <fullstop> If you're playing board games, you have others with you and that's a good thing.
[17:33:08] <Larhzu> kevans: I'm more like in analysis mode, this is a puzzle to be understood, how it got past me etc.
[17:34:09] <FH_thecat> Larhzu: if you had seen the build-to-host.m4 file, would the added lines have struck you as suspicious, or was it obfuscated even to fool you ?
[17:34:09] <Larhzu> balrog: I won't comment that now.
[17:34:21] <balrog> Larhzu: it's fine, I'm not looking for a comment :)
[17:34:50] <spacespork> has anyone here been looking for other ways sshd indirectly calls liblzma? I dont wanna step on anyone's toes or repeat anyones work, and if anyone is we can divide and conquer
[17:34:55] <sh4> is there even a law that prohibits backdooring software ? i mean, i could imagine that as a result of this new laws come out, but probably only some that take away more liberties
[17:35:14] <fullstop> sshd links to more libraries than I had expected
[17:35:40] <vivia> sh4: enforcing that and especially judging intent would be more questionable, it's not always a clear-cut case like now :(
[17:35:44] <sh4> (liberties like signing on to github anonymously)
[17:35:48] <fullstop> although maybe that is because of what libsystemd brings in.
[17:35:52] <Larhzu> supakeen: I don't know if sending patches is the best thing to do right now. Patch review takes time. When I look at the code, I suppose I should review what's already in the repo and clean it up.
[17:36:02] <spacespork> fullstop: im only seeing 14 that sshd calls directly, less than i would have thought
[17:36:07] <balrog> sh4: laws like the CFAA are rather broad and it comes down to a prosecution being able to collect enough evidence establishing malicious intent
[17:36:20] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Quit: Quit)
[17:36:27] <spacespork> also i dont have a systemd system my sshd doesnt have that patch
[17:36:35] <supakeen> Larhzu: no problem, I’ll have to work on my branch for a tad anyhow I’ll submit it after things have appropriately cooled down.
[17:37:08] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[17:37:13] <test230117> Well, Sabotage by Chinese is not special event in open-source community at all, Even Chinese-American sabotaged linux kernel
[17:37:55] *** Quits: mikolajw (~mikolajw@user/mwielgus) (Client Quit)
[17:38:09] *** Joins: mikolajw (~mikolajw@user/mwielgus)
[17:38:36] <test230117> Resulting in full revert of commit of specific mail domain(He was professor).
[17:38:56] *** Joins: cyberpege (~cyberpege@194.191.251.149)
[17:39:24] *** Quits: iNomad (~iNomad@user/iNomad) (Quit: leaving)
[17:39:28] <sh4> if i were a chinese sponsored hacker, i'd certainly not use a chinese-sounding name
[17:39:47] <supakeen> As an aside, systemd was already moving towards dlopen and OpenSSH will likely upstream the sd_notify patch by not linking in libsystemd but writing the 25 lines necessary.
[17:39:52] *** Joins: aaceac (~aaceac@2a00:23c5:9ba2:c300:c4dc:75f8:20f8:775d)
[17:39:57] <Steffanx> sh4: or maybe you should, just because people would think exactly that.
[17:40:03] <Larhzu> FH_thecat: Suspicious, yes. I won't comment much now though, I will write in detail in an article.
[17:41:22] *** Joins: Guest15 (~Guest56@2a0e:1d47:419c:4400:c06a:6f51:f1a:109f)
[17:41:30] <Larhzu> I don't know Chinese names. I mean, I don't know what is family name and what is first name. Jia did.
[17:41:45] <Larhzu> But that doesn't mean he was Chinese. Don't jump to conclusions.
[17:42:09] <FH_thecat> was it suspicious that the m4 file was ignored in git ?
[17:42:12] <Larhzu> I mean, I only can provide the info that he knew the names.
[17:42:38] <kevans> Larhzu: right, regardless of past issues, I would've likely noped out of the channel at least 30 minutes ago to avoid getting bogged down with questions
[17:42:39] <Larhzu> FH_thecat: No because ./autogen.sh or autoreconf -fi adds it. That's why it's ignored.
[17:43:06] <Larhzu> supakeen: What kind of branch? One email I got was about branch without any Jia's code.
[17:43:10] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[17:43:57] <Larhzu> kevans: As long as the amount of text is low enough, that is, most people remain observers, I'm here because I said I would be on Monday and people obviously want to know things.
[17:44:58] *** Joins: Guest10 (~Guest96@194-218-34-180.customer.telia.com)
[17:46:21] <Larhzu> supakeen: I plan to get the Git repo into a state where *I* can say with confidence that I approve the contents.
[17:46:23] <susi> is there a book coming about your interactions with the legendary Jia Tan?
[17:46:29] <Larhzu> Haha
[17:46:42] <Larhzu> Three movies at least ;)
[17:47:00] <Larhzu> Hmm
[17:47:04] *** Quits: Guest10 (~Guest96@194-218-34-180.customer.telia.com) (Client Quit)
[17:47:19] <int-e> Larhzu: AIUI autogen.sh does not add that particular file (build-to-host.m4) if you run it in the repo.
[17:47:21] <Larhzu> Are 5.6.0 and 5.6.1 tarballs and .sig files available somewhere still?
[17:47:58] <sh4> sam_ has them, i saw them uploaded on gentoo bugtracker or something like that
[17:48:02] *** Quits: sraue (~sraue@ip-095-223-016-008.um35.pools.vodafone-ip.de) (Quit: Client closed)
[17:48:03] <netx_> Larhzu: https://web.archive.org/web/*/https://github.com/tukaani-project/xz/releases/download/*
[17:48:35] <Larhzu> int-e: What's your gettext version? I have gettext 0.22.4.
[17:48:47] <Larhzu> Thanks
[17:48:58] <supakeen> Larhzu: generating test data at test time.
[17:49:09] <FH_thecat> Larhzu: I downloaded the archive from https://deb.debian.org/debian/pool/main/x/xz-utils/xz-utils_5.6.1.orig.tar.xz
[17:49:52] *** Quits: tonyoy (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr) (Ping timeout: 255 seconds)
[17:49:52] <vivia> I still have the 5.6.0 .deb's in my /var/cache/apt/archives if that helps someone
[17:50:07] <int-e> Larhzu: Oh it's 0.21 here.
[17:50:51] <Larhzu> FH_thecat: Thanks, no .sig file though
[17:50:51] <supakeen> Larhzu: here are the release tarballs as imported by Fedora: https://src.fedoraproject.org/lookaside/pkgs/xz/
[17:51:34] <int-e> Debian also has original tar-balls as https://deb.debian.org/debian/pool/main/x/xz-utils/xz-utils_5.6.1.orig.tar.xz (and ...5.6.0...)
[17:51:59] <int-e> But I don't see the sig files? Maybe I'm too stupid to find them.
[17:52:24] <tomreyn> append .asc
[17:52:33] <xx> Larhzu: https://0x0.st/XzVr.bin is xz-5.6.1.tar.gz.sig
[17:52:44] <int-e> tomreyn: ah! nice.
[17:54:01] *** Joins: Guest52 (~Guest52@165.225.36.172)
[17:54:04] <beber_> Larhzu, happy to see around and thank you for all the work on xz, it's been a change change in compression software, thanks for all your work
[17:54:18] <beber_> s/change change/game changer/
[17:54:37] <xx> int-e: https://deb.debian.org/debian/pool/main/x/xz-utils/xz-utils_5.6.1.orig.tar.xz.asc
[17:54:43] <Larhzu> Thanks to all, I'll be away a few minutes!
[17:55:48] <tomreyn> Larhzu: i /msg'd you privately the other day (not sure if you are receiving private messages, though). i was wondering about improving the hosting situation going forwards (also for others to regain trust in the project)? also (cryptographically) signed commits might be good, so that commits can actually be attributed to users (no longer falsifiable by any committer).
[17:56:12] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[17:56:59] *** Joins: Tom^ (~Tom^@user/tom/x-0773808)
[17:58:52] <int-e> xx: I don't know why I didn't try https://deb.debian.org/debian/pool/main/x/xz-utils/
[17:59:12] <int-e> instead of blindly guessing full URLs
[17:59:12] *** Joins: Lockal (~Lockal@user/Lockal)
[17:59:27] <xx> I don't know why debian hasn't taken it down
[17:59:42] <int-e> Hmm what would that accomplish?
[17:59:44] <xx> however they did currently freeze the whole archive, so maybe they received a request to not touch it
[18:00:08] <xx> int-e: people who download things without running `apt update` will get the bad version
[18:00:08] <int-e> They did downgrade the package, everything else seems to be water down the bridge.
[18:01:05] <int-e> xx: the deb files seem to be gone
[18:01:55] *** Joins: duxsco_ (~duxsco@user/duxsco)
[18:02:02] <xx> heh, guess who had an old cached version of that page in the web browser :)
[18:02:04] *** Quits: aaceac (~aaceac@2a00:23c5:9ba2:c300:c4dc:75f8:20f8:775d) (Ping timeout: 268 seconds)
[18:02:11] * xx really should refresh pages more often
[18:02:41] <xx> https://deb.debian.org/debian/pool/main/x/xz-utils/xz-utils_5.6.1-1_amd64.deb
[18:03:07] <int-e> Oh it may depend on which particular mirror you hit too.
[18:03:29] <xx> it doesn't
[18:03:35] <xx> it's just not visible in the listing
[18:03:40] <xx> but the files exist
[18:03:57] <int-e> So it does. That is... odd.
[18:04:42] *** Quits: duxsco (~duxsco@user/duxsco) (Ping timeout: 240 seconds)
[18:06:29] <Larhzu> tomreyn: I did, I get many messages.
[18:06:29] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[18:06:53] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[18:07:23] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[18:07:37] *** Joins: Garen (~Garen@50.52.127.145)
[18:07:41] <Larhzu> tomreyn: It's a shared host webhotel. On Saturday I spent over an hour on phone with the hosting provider's security person.
[18:07:49] <Larhzu> tomreyn: He called me.
[18:08:31] <Larhzu> tomreyn: We talked about things, he looked at IPs where my account had logged in (all fine) and assured that capacity should be there.
[18:09:12] <Larhzu> tomreyn: Security was discussed too.
[18:09:30] *** Quits: cyberpege (~cyberpege@194.191.251.149) (Quit: Client closed)
[18:10:37] <tomreyn> Larhzu: my suggestion would be to consider moving away from shared web hosting, to either a large org's SaaS Git host, or some VM hosting where the ip address only points to your hosting, without web accessible hosting panel (to ANY).
[18:10:50] <Larhzu> I understood.
[18:10:55] <tomreyn> ok
[18:11:14] <Larhzu> I'm not sure if I have skills to compare the risks.
[18:11:39] <gromit> Larhzu: Some people have voiced allegations of you being part of this conspiracy, do you have any plans of how you could re-establish trust back to you? Because that sounds like a hard problem
[18:12:23] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[18:12:27] <Larhzu> tomreyn: The hosting provider takes security seriously. But obviously it doesn't mean perfect and obviously shared hosting has downsides.
[18:12:50] <Rounin> Hmm... I mean, if they don't trust the main author of the application, why are they using it?
[18:12:57] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[18:13:07] <Larhzu> tomreyn: Many things are possible but I have to prioritize heavily.
[18:13:57] *** Joins: Paistin (~Paistin@193.138.7.199)
[18:14:10] <Paistin> new found, they tried getting it into macos homebrew same night https://github.com/orgs/Homebrew/discussions/5243
[18:14:24] <Larhzu> Signed commits etc. are someting to look at and I understand why but I need to focus on the main things in the near future.
[18:14:40] *** Quits: ponycat (sid524992@smol/hors) ()
[18:14:42] <Paistin> macos homebrew has skipped many dozen versions and out of the blue same night this empty account comes to shout we need macos homebrew xz 5.6.1
[18:15:06] <orkim> macos isn't rpm or deb based though?
[18:15:18] <Paistin> no it isn't but this cannot be coincidence
[18:16:08] <Larhzu> gromit: I don't think much about the trust side at the moment. Time will tell how it will be. It will depend on what I do.
[18:16:18] <kevans> a competent attacker would display the same vigor in trying to get it into innocuous places that they do in places they really care about
[18:16:56] *** Joins: ponycat (sid524992@smol/hors)
[18:17:14] <cjwatson> Paistin: the reason that the upgrade demands went unnoticed was that they were indistinguishable from what demanding open source users do all the time.  so it definitely can be coincidence, I'm afraid
[18:17:14] <int-e> Paistin: I believe this is after the fact, note the "upgrading from 5.6.1 to 5.4.1"
[18:17:36] <cjwatson> (three days ago is weird timing, but not everyone is terminally online)
[18:17:48] <int-e> So a user noticed a downgrade and thought that was weird, so reported it.
[18:18:13] <Larhzu> gromit: I hope to write an article about what I know and hope that it will help others from getting in the same situation.
[18:18:28] <Paistin> int-e: the title says installs outdated version, but OP doesn't talk about the vuln or having concerns
[18:18:35] <int-e> It may be nefarious of course but I think it's more likely benign... there's no point getting this into homebrew from the attacker's perspective.
[18:19:04] <int-e> Paistin: I imagine they didn't know.
[18:20:07] <Paistin> true I could be just starting to see connections I think 
[18:21:15] *** Quits: spacespork (~satan@user/spacespork) (Ping timeout: 252 seconds)
[18:21:44] <JAA> sam_, tolto: FYI, in case you haven't seen, all tarballs are in the Wayback Machine by now.
[18:22:53] <tomreyn> Larhzu: *in case* you will be going to sign everything, the hosting choice becomes a matter of availability / reliability only - which the current can likely provide well enough. for opsec recommendations: pick and contact 3 or 5 of those discussing what happened, get their recommendations. they are willing to listen to and support you now.
[18:23:42] *** Quits: aloisw (~aloisw@user/aloisw) (Quit: Konversation terminated!)
[18:23:56] <Larhzu> FH_thecat: "would the added lines have struck you as suspicious" -- I said "yes" but I actually have to cancel that comment *partially*.
[18:24:39] <Larhzu> FH_thecat: I'm still learning about this and I just learned one more thing. Wow.
[18:24:57] <FH_thecat> please tell us
[18:25:00] <Larhzu> FH_thecat: I mean "wow" as in something that public cannot know right now.
[18:25:15] <Larhzu> I will later, if I try now, I will miss something and then speculation starts.
[18:25:27] <dstolfa> Larhzu: save it for the article to curb conspiracies until then perhaps?
[18:25:35] <Larhzu> dstolfa: Yes
[18:26:15] <Larhzu> tomreyn: I don't mind moving back to GH or some other place.
[18:26:21] <f_[xmpp]> Welcome back Larhzu !
[18:26:21] <Larhzu> But home page will be on tukaani.org.
[18:26:58] <Larhzu> I learned GH enough that I find issue tracking nice and so on. The repo browser UI is not nice compared to a few others including Gitweb, GH is slow.
[18:27:05] <Noisymeow> GitHub is proprietary, please don't move back to it
[18:27:10] <Lockal> JAA, they are still on mirrors (like http://gentoo.mirror.root.lu/distfiles/9f/), probably won't be removed
[18:27:15] <f_[xmpp]> Noisymeow oh my
[18:27:18] <f_[xmpp]> meow
[18:27:40] <Noisymeow> Use codeberg.org (or another forgejo instance) if you want GitHub-style issue tracking. There's also sourcehut, but that's more different.
[18:27:47] <negril> The gentoo mirrors will remove them in ~30 days
[18:27:55] <sh4> best repo browser is gitk, fyi
[18:28:00] <Larhzu> GH was picked because Jia preferred it. In the past (1-2 years before Jia) GH was proposed to me as well.
[18:28:47] <Larhzu> sh4: How to use it on linux.git so that it stops scanning history soon enough?
[18:28:57] <Larhzu> sh4: gitk also requires cloning the repo first.
[18:29:04] <Noisymeow> You can't submit PRs or open GitHub issues without registering an account, which involves running nonfree JavaScript. GitHub's repo browser doesn't even work without nonfree JavaScript any more.
[18:29:11] <sh4> tru.dat
[18:29:20] <stefk> Paistin: why should they talk about the vuln? This was on Friday when the news spread. Account also has other activity unlike previous sock puppets
[18:29:33] <Larhzu> I'd prefer more FOSS-oridented host than GH. GH had CI, that was nice. But I didn't learn how to actually use it.
[18:29:42] <sh4> linux repo is kind of an oddball. even my bash prompt takes like a minute to tell me the branch :/
[18:29:59] <sh4> imagine they would've used hg...
[18:30:00] <f_[xmpp]> Larhzu: I personally use Cgit + Gitolite.
[18:30:12] <Larhzu> My computer is old and I'm very impressed with Git's speed even on linux.git.
[18:30:17] *** Joins: Priolix (~Priolix@modemcable156.69-81-70.mc.videotron.ca)
[18:30:22] <f_[xmpp]> Mine is old too.
[18:30:29] <mspo> signing commits with ssh is nice and easy. So much nicer than gpg
[18:30:31] <Larhzu> f_[xmpp]: Can you beat CPU from 2009?
[18:30:45] <dstolfa> git is plenty fast for me as long as you don't use one of those crappy extensions that wants to get the status in O(n^2)
[18:30:47] <f_[xmpp]> Larhzu: heh, I used a 2006 laptop a few years ago
[18:30:49] <susi> mine is new! has 4G of RAM and cool Celeron N4500
[18:30:49] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[18:30:58] <f_[xmpp]> It was a corebooted MacBook2,1
[18:31:13] <JAA> Lockal: The keyword is 'all'; it includes the beta releases and all variants (e.g. .tar.gz and .tar.xz).
[18:31:13] <Larhzu> Oh ;-)
[18:31:13] <f_[xmpp]> I'm now on a 2011 laptop, an EliteBook 8560w.
[18:31:37] *** Joins: xorAxAx (sid624141@id-624141.hampstead.irccloud.com)
[18:31:46] <f_[xmpp]> It's fast enough to compile U-Boot in a few minutes
[18:32:09] <f_[xmpp]> and I don't compile linux that often, but when I do it's slow but reasonable (~30 minutes)
[18:32:21] <JAA> Lockal: Your link only has a single one of the last version. Debian has a bit more but is missing a bunch, too.
[18:32:21] *** Joins: alcx (~alcx@2a01:e0a:32e:9f50:1c56:c118:4031:620c)
[18:32:29] <f_[xmpp]> I think I compiled linux many times before on that MB2,1 too.
[18:32:33] *** Joins: Guest71 (~Guest200@2a01:599:702:4c6b:ed5a:2299:2d58:484e)
[18:32:35] <Larhzu> Noisymeow: I suppose learning a new UI isn't that much work but one thing at a time.
[18:32:45] <Stalevar> Did jiatan say anything personally in IRC or elsewhere after the backdoor was discovered?
[18:32:48] <Larhzu> Sorry I derailed the discussion.
[18:32:55] <Larhzu> No
[18:33:01] <f_[xmpp]> Larhzu: haha, it happens :P
[18:33:09] <Larhzu> sh4: We were supposed to be offline during Easter.
[18:33:11] <sh4> f_[xmpp], if you compile the kernel often, ccache can reduce your compile time to like a third, at the cost of about 500 mb hdd space
[18:33:16] <Larhzu> *Stalevar: ^
[18:33:28] <f_[xmpp]> sh4: yeah plus that.
[18:34:20] <sh4> now in the brave new future, the kernel will be rewritten in rust, then it will take 20 hrs to build even on a mainframe
[18:34:32] <f_[xmpp]> please no
[18:34:42] <f_[xmpp]> I want to keep my C alive!
[18:34:45] <Larhzu> Now that I re-think of the build-to-host.m4 additions, I suspect I would have missed it. But the full story will be out later.
[18:35:09] <FH_thecat> interesting
[18:35:14] <f_[xmpp]> Larhzu: Are you undoing changes rn?
[18:35:19] <Larhzu> rn?
[18:35:23] <sh4> right nao
[18:35:24] <f_[xmpp]> right now?
[18:36:00] <Larhzu> I'm mostly chatting. I was hoping to reply to a few emails but we'll see, I should be sleeping soon.
[18:36:06] <stefk> using GitHub has quite some advantages, I just would try not to depend on them and be able to move around easily
[18:36:13] <Larhzu> I need to sleep to work on the code.
[18:36:41] <f_[xmpp]> I guess it's evening/night in your timezone..
[18:36:54] *** Joins: Guest78 (~Guest78@ip72-204-13-218.fv.ks.cox.net)
[18:37:07] <Larhzu> stefk: *Very* much agreed. For me it was a place to host the repo and such. The number of open issues isn't that big so if that is lost (like it is now) it's not terrible.
[18:37:23] <Larhzu> stefk: This kind of things I emphasized before the move was made.
[18:37:55] <f_[xmpp]> I rather not use GitHub as logging in is a pain to start with in my case
[18:38:21] *** Joins: spacespork (~satan@user/spacespork)
[18:38:22] <tolto> JAA: thanks
[18:39:05] <tolto> but yeah it looks like someone managed to make a PoC for the backdoor https://github.com/amlweems/xzbot
[18:39:09] <Larhzu> f_[xmpp]: It was but often I could just fetch/push via ssh and reply via email.
[18:39:30] *** Joins: Earnestly (~earnest@user/earnestly)
[18:39:37] <f_[xmpp]> I see.
[18:40:06] <tolto> that was quick. that means amlweems has already reversed most of the code
[18:40:57] *** Quits: Priolix (~Priolix@modemcable156.69-81-70.mc.videotron.ca) (Quit: Leaving)
[18:42:12] <Stalevar> How likely that xz utils has other hidden backdoors besides the discovered one?
[18:42:24] *** Joins: aaceac (~aaceac@2a00:23c5:9ba2:c300:c564:8150:40ab:95b)
[18:42:39] *** Joins: jnalanko (~niklas@87-95-168-136.bb.dnainternet.fi)
[18:42:41] <tty6> tolto: there are still some unknown features in the binary. It seems to parse ssh logs too
[18:42:45] <beber_> Larhzu, I know this will sound suspicious and you should take it that way, but is there anything we could all collectively do to help you in any form ?
[18:43:07] <Stalevar> Larhzu, by the way, I was also wondering, do you think that lzip is a good alternative to xz?
[18:43:10] <brlin> We probably should introduce a policy that all test files should be reproducible by readable code instead of hand-crafted binaries.
[18:43:14] <spacespork> im sure im not the first to do this, but i wrote a small script to recursivly run ldd on all the libs sshd calls, ofc this leaves out staticly link binaries but in my experience with the distro most are dynamic. On  my systemd-free distro sshd never class liblzma, but the more important question is are then any other programs (qemu? iptables?) it might be useful to run this on to see if/how they call 
[18:43:18] <tomreyn> Larhzu: i assume you can likely get a dump of what was on github if you ask them for it, as least issues (open and closed) + merge requests.
[18:43:20] <spacespork> lzma and if any other volnerablities exist? 
[18:43:21] <tolto> tty6: ah, i assume these features are for cleaning up the logs. actually doesn't the xzbot github page mention that?
[18:43:25] <int-e> beber_: be patient? :-)
[18:43:26] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[18:44:21] <Tom^> spacespork: "some versions of ldd may attempt to obtain the dependency information by attempting todirectly execute the program, which may lead to the execution of whatever code is defined in the program’s ELF interpreter" fyi
[18:44:34] *** Joins: rurapenthe (~None@102.132.133.163)
[18:44:49] <Stalevar> strings could replace ldd
[18:44:59] <Tom^> spacespork: perhaps not the best idea to run on all sorts of things that might or might not be ugly
[18:45:34] *** Quits: tty6 (~user@2a01:c22:90b6:2000:4b32:1da4:9155:c47d) (Remote host closed the connection)
[18:46:07] *** Joins: tty6 (~user@2a01:c22:90b6:2000:9e6b:ff:fe26:c5e9)
[18:46:36] <Apachez> Larhzu: tip to include for your upcoming article on this event (unless its already part of it): when was the last time you communicated with "Jia" before this went public, ever spoked over phone or similar and have "Jia" replied to any com attempts since all this went public
[18:46:42] <spacespork> Tom^: im aware of that issue but since im running this with user priv on a distro that was never effected i think the risk is tolerable
[18:46:55] <Larhzu> Apachez: Thanks, sure
[18:47:08] <FH_thecat> Stalevar: I asked same question earlier. Larhzu said, he has no specific suspicion of more backdoors in other places
[18:47:53] *** Joins: terabit63 (terabit@about/hackers/terabit)
[18:47:54] <Apachez> benefit of a doubt in theory it can be that "Jia" got his/hers account pwned... as what happend to a kernel.org dev a few years ago and malicious code was commited into linux kernel (but spotted within hours)
[18:48:38] <Stalevar> $ tr -cs '\040-\176' '\n' < /usr/sbin/sshd | grep lib
[18:49:10] *** Joins: Guest16 (~Guest16@2a05:4f46:41b:d000:8f06:5133:9710:cddf)
[18:49:15] *** Quits: loganaden (~logan@102.117.50.19) (Quit: leaving)
[18:49:18] <spacespork> Tom^: given ldd shows more libs than objdump i was worried id be missing information by using objdump
[18:49:41] <int-e> Apachez: My pet speculation is that a genuine contributor was coerced into doing a bit more than that. Who knows. Maybe we'll never know...
[18:49:53] <Larhzu> tomreyn: I think xz-java repo had most open issues but once I have GH account back I can put repos back too. But I have to prioritize things.
[18:50:46] <f_[xmpp]> good luck
[18:50:59] <Larhzu> Stalevar: The history between me (and a few other persons) and the lzip developer is, umm, complicated. He writes good code and I've used his GNU ddrescue successfully.
[18:51:14] *** Quits: terabit (terabit@about/hackers/terabit) (Ping timeout: 250 seconds)
[18:51:35] <Larhzu> Stalevar: I eventually accepted the addition of .lz decompression support into XZ Utils.
[18:51:50] <tomreyn> sure, GH issues would also need vetting before restoring
[18:52:23] <spacespork> that all being said, are there any other programs we can gain useful data from by running this script on?
[18:52:33] <Larhzu> int-e: Knowing for 100 % sure, probably not. Knowing for 90 %, maybe.
[18:52:41] <f_[xmpp]> Larhzu: Also, I saw you removed jiatan's contact info?
[18:52:42] <stefk> int-e: if so, it would seem early on. definitely at the time when there was that maintainer bullying by sock puppets already
[18:53:10] <Stalevar> I don't like that github can arbitrarily suspend any project making things like issues completely inaccessible. I was wondering whether anybody tried to create an issue about backdoor or not, for example
[18:53:30] <int-e> stefk: true, there's that
[18:53:35] <f_[xmpp]> Stalevar: I saw an issue about the backdoor on GH at some point
[18:54:30] <spacespork> int-e: my thoughts exactly, i think Tan was a legit maintainer coerced into doing this by a governemnt
[18:54:32] <int-e> yeah GH blocking the repo is a mixed bag :-/
[18:54:35] <beber_> Stalevar, They do have concern about legal liability to host large scale compromise code/archive, that's a legit decision until situation is cleared off. They are a business with people in line for breaking the law from different countries they operate in
[18:54:41] <spacespork> anyway, i mush leave
[18:54:49] *** Quits: spacespork (~satan@user/spacespork) (Quit: leaving)
[18:54:51] <Stalevar> Ideally it's better to host issues and repository on your own than to trust big sites like github or gitlab, especially since github was bought by Microsoft. Who knows how many backdoors they might have added in places?
[18:54:55] *** Joins: shm (shm@turing.digitalsun.pl)
[18:54:57] *** Joins: flmrc (~fllll@151.66.26.237)
[18:55:02] *** Quits: alcx (~alcx@2a01:e0a:32e:9f50:1c56:c118:4031:620c) (Quit: Client closed)
[18:55:08] <Larhzu> brlin: Reproducible test files: All generated files must have a generator program. I'm not sure about the old files.
[18:55:10] <Stalevar> Though git itself helps against backdoors
[18:55:27] <int-e> Larhzu: I'll wait and watch whatever facts come out. This is hardly an emergency at this point, not worth losing sleep over.
[18:55:44] <Larhzu> beber_: I don't know right now. I might have tasks that others could do but I don't know right now.
[18:55:50] <Stalevar> At least Windows has know backdoors out of the box
[18:55:55] <Stalevar> (telemetry)
[18:56:15] *** Quits: rurapenthe (~None@102.132.133.163) (Quit: This computer has gone to sleep)
[18:56:34] <Larhzu> f_[xmpp]: I did.
[18:57:05] <Larhzu> int-e: Blocked repo meant that my email inbox stopped getting tons of notifications. :)
[18:57:14] <f_[xmpp]> https://tukaani.org/about.html
[18:57:24] <int-e> Larhzu: Ah so something good came out of it :)
[18:57:28] <f_[xmpp]> Larhzu: jia is still mentionned in this page
[18:57:38] *** Joins: hporten (~porten@ip5f5afc0b.dynamic.kabel-deutschland.de)
[18:58:14] *** Quits: hporten (~porten@ip5f5afc0b.dynamic.kabel-deutschland.de) (Quit: leaving)
[18:58:14] <Larhzu> f_[xmpp]: I should cleanup things from the home page. I had hoped to do that today too but I've been just chatting.
[18:58:24] <Larhzu> There are dead redirections etc.
[18:58:33] <f_[xmpp]> heh sorry
[18:58:39] <int-e> (The negative side was that we lost a central place to discuss things. And, of course, the discussions that had already taken place on GH. Though a lot of that was noise.)
[18:58:40] <Stalevar> int-e, are you maintaining some kind of page similar to sam's?
[18:58:45] <tomreyn> Larhzu: in case you will be too modest to point it out in your article: i suggest stating which additional 'resources' you could currently make use of, be it developers, security consulting / auditing, money, hardware shopping vouchers, hosting, etc. if you don't bring it up it won't be offered.
[18:58:54] <int-e> Stalevar: No.
[18:58:56] <flmrc> I could be blind but he's not mentioned in the page
[18:58:56] <Larhzu> I'll take the XZ logos away too. I didn't mind them but didn't love either.
[18:59:15] <f_[xmpp]> Larhzu: Weren't the logos made by someone else?
[18:59:40] <f_[xmpp]> as in, not made by Jia
[18:59:42] <Larhzu> f_[xmpp]: So the story went, friend made but wanted to remain anonymous so copyright was transferred to Jia.
[18:59:53] <f_[xmpp]> sure
[19:00:17] <beber_> f_[xmpp], they were made as of https://git.tukaani.org/?p=xz.git;a=commitdiff;h=31293ae7074802cc7286089a89c7b552d930c97f;hp=6daa4d0ea46a8441f21f609149f3633158bf4704 by Kia
[19:00:21] <Stalevar> Is there a chance that backdoor was introduced by somebody else, not Jia?
[19:00:35] <Stalevar> Like stolen account
[19:00:52] *** Joins: FrodoBaggins (~frodo@136-144-129-60.colo.transip.net)
[19:00:57] <sh4> stolen account, stolen pgp key, stolen ssh key...
[19:01:09] <f_[xmpp]> that would be a lot of stolen things..
[19:01:12] <Stalevar> Yeah, 
[19:01:16] <Stalevar> Stolen computer
[19:01:19] <Mopman_> or one stolen machine
[19:01:21] <sh4> only likely if jia tan used windows :)
[19:01:33] <f_[xmpp]> :)
[19:01:34] <Larhzu> Often on the same computer though... but I'll get to this kind of things in time.
[19:01:59] <FH_thecat> he would also have to have been murdered. Otherwise he could have easily alerted someone his account was compromised
[19:02:01] <Larhzu> I spent 26 months chatting with him so I know a few more things than most.
[19:02:03] <s1gyn> You'd think they'd have said something by now
[19:02:41] <Larhzu> People love to speculate but I'm intentionally not commenting every imagined story.
[19:02:47] <Lockal> Stalevar, nomody knows, specific governments can easily kill/arrest/threaten developer if they want to push a backdoor
[19:02:58] <f_[xmpp]> Let's set that aside and instead undo what was done.
[19:03:19] *** Quits: aaceac (~aaceac@2a00:23c5:9ba2:c300:c564:8150:40ab:95b) (Remote host closed the connection)
[19:03:21] <f_[xmpp]> Speculating about jia won't lead anywhere really.
[19:03:33] <Larhzu> To infiltrate a project, one has to do good proper quality work most of the time.
[19:03:35] *** Quits: flmrc (~fllll@151.66.26.237) (Quit: Leaving)
[19:03:49] <f_[xmpp]> Analyzing the backdoor, removing the backdoor, cleaning up, etc will lead somewhere.
[19:04:08] <Larhzu> I understand it sounds scary but highly likely most commits by Jia are fine. But one has to fine every single one of the bad ones.
[19:05:07] <Larhzu> Ripping out all Jia's commits and then redoing them is suggested by some but I'll make decisions when I have investigated things more.
[19:05:23] *** Joins: fll (~fllll@151.66.26.237)
[19:05:28] <f_[xmpp]> I have nothing against keeping some of Jia's commits really
[19:05:39] <Larhzu> To many they look scary.
[19:05:53] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[19:06:15] <sh4> every commit could've introduced an integer overflow, a double-free or what have you
[19:06:23] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[19:06:27] <tomreyn> Larhzu: i don't want to speculate, but, if a nation state was involved, we also need to consider the possibility that your life got difficult at the time when you were offered help to make you accept the help. i.e. you may not just need to review code changes, also those to your social life. sorry for this ugly thought.
[19:06:29] <f_[xmpp]> As long as those commits are fine, I wouldn't rip them out just because "it was made by Jia Tan"
[19:06:44] <Larhzu> Most of the time I reviewed patches in branches and we edited them via feedback etc. So often the branches were in state that I would approve. However...
[19:07:16] <Larhzu> ...in cases where the merges were done by Jia, it's not obvious that the branch-that-I-reviewed was merged as is.
[19:07:34] <xcvb> In other places (like CRNG), people get scared by a few constants already, never mind larger swaths of code.
[19:07:43] <Larhzu> For example, perhaps there was one more typo to fix in commit 1 of 4 and thus that would rewrite the commit IDs.
[19:08:06] <Noisymeow> codeberg and sourcehut both have CI and are fully free software
[19:08:08] <Apachez> https://en.wikipedia.org/wiki/NSAKEY this didnt stop people from using Windows and Im not sure recommiting the same code by somebody else would help things - better IMHO to spot out the bad code and fix that in later commits as we all do with regular bugs introduced by somebody else
[19:08:40] <stefk> sh4: it would make sense to only make minimal commits required for the bad shit, and not draw attention with other bad commits that aren't related (to their gem, the attack vector)
[19:08:58] <Larhzu> Noisymeow: Sounds great
[19:09:08] *** Joins: hoihoihoi (~hoihoihoi@89.205.135.51)
[19:09:45] <Larhzu> I somewhat like traitor boardgames where there is a common goal but one or two are actually trying to sabotage without getting caught.
[19:09:57] <Larhzu> In such games one often needs to play normally most of the time.
[19:10:30] <agl> Larhzu: Go to bed, you need the sleep so you are fit to go through the code.
[19:12:07] <Larhzu> agl: You are right, I don't dare to reply to emails anymore either.
[19:12:41] <vtorri_> Larhzu, do you know sourcehut for git repo ?
[19:12:53] <Larhzu> vtorri_: I have heard the name.
[19:13:00] *** Quits: ultra980 (~ultra@2a02:2f0a:b308:4000:24f8:a1a0:33b3:fb43) (Ping timeout: 256 seconds)
[19:13:12] <Larhzu> I don't plan to self-host the repo & issue tracker.
[19:13:30] <sh4> so glad we had the vigilant anarazel aka andres freund discovering this coincidentally before it could do major harm
[19:13:36] <Lockal> f_[xmpp], you may think this looks fine, only "dot" should be removed? https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.txt;h=d2b1af7ab0ab759b6805ced3dff2555e2a4b3f8e;hp=76700591059711e3a4da5b45cf58474dac4e12a7;hb=328c52da8a2bbb81307644efdb58db2c422d9ba7;hpb=eb8ad59e9bab32a8d655796afd39597ea6dcc64d
[19:13:51] *** Joins: rurapenthe (~None@102.132.133.163)
[19:13:58] *** Joins: Guest32 (~Guest25@164.92.98.0)
[19:14:03] <Larhzu> vtorri_: Your comments about build systems I will keep in mind. Feel free to bug me again about those in 4-6 months.
[19:14:03] <Lockal> But in reality nobody complained that "some systems have linux/landlock.h, but do not have the syscalls"
[19:14:07] <vtorri_> sourcehut is managed by people who prefer non proprietary softwares
[19:14:45] <Larhzu> Lockal: I tested the fix which I committed.
[19:14:47] <vtorri_> Larhzu, i have other things to ask for the build system, but i think that these days, it's useless
[19:14:57] <vtorri_> too much buzz to do something constructive
[19:15:12] <Larhzu> Lockal: In reality the commit you linked was made because such systems were surprisingly common.
[19:15:42] *** Quits: Garen (~Garen@50.52.127.145) (Ping timeout: 252 seconds)
[19:15:54] <Larhzu> Lockal: I don't remember now if I reviewed that commit. Somewhat probably not, considering the date.
[19:16:07] <Larhzu> Lockal: But I did approve the idea of the change.
[19:16:22] <Larhzu> I suspect that most of the the malicious commits were made this year.
[19:18:22] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[19:18:38] *** Joins: Guest67 (~Guest3@2409:40e4:4c:1791:b1b7:9242:493d:80d)
[19:18:40] <Lockal> Larhzu, then there is https://cmake.org/cmake/help/latest/module/CheckSymbolExists.html for that. Initial code was written with ill intention, that's why it should be reverted and reimplemented in a clean-room conditions
[19:18:52] *** Joins: jghali (~jghali@21.50.195.77.rev.sfr.net)
[19:19:30] *** Joins: jghali_ (~jghali@21.50.195.77.rev.sfr.net)
[19:19:41] <Larhzu> vtorri_: In that context sourcehut sounds promising then. But these things don't have the highest priority right now.
[19:20:17] *** Quits: mcury (~mcury@user/mcury) (Ping timeout: 240 seconds)
[19:20:34] <vtorri_> Larhzu, sure, you'll see that later
[19:20:40] *** Joins: spacespork (~satan@user/spacespork)
[19:20:53] <Larhzu> Lockal: Perhaps. Apart from the sabotage, the commit looks like what I think I discussed with Jia, I mean, the big picture that a single CMake variable is set when checking for all those features (headers, #defines, and prctl).
[19:21:21] *** Quits: fll (~fllll@151.66.26.237) (Quit: Leaving)
[19:21:28] <Larhzu> Lockal: It's simpler to check one macro in C code than three. All three are needed together.
[19:21:50] <Larhzu> Lockal: So cleanroom in my style could be close to identical.
[19:22:09] <Larhzu> It sounds like that people assume that Jia worked alone most of the time.
[19:23:09] <Larhzu> In reality it got somewhat like that in early 2024 (or slightly earlier, this I haven't verified myself clearly enough yet).
[19:23:09] <spacespork> I think he had other people with him, but in terms of git profiles his was the only one making malicious commits
[19:23:09] <kevans> I suspect a large amount of speculation comes from folks that haven't co-maintained a project like this before
[19:23:27] *** Quits: jghali (~jghali@21.50.195.77.rev.sfr.net) (Ping timeout: 255 seconds)
[19:24:46] <Larhzu> kevans: Yeah. The amount of real help was huge, that is, just reviewing commits that *I* wrote.
[19:25:30] <spacespork> are there updates to the investigation or are we waiting for lasse before we do anything
[19:25:37] <int-e> https://git.tukaani.org/?p=xz.git;a=commitdiff;h=de5c5e417645ad8906ef914bc059d08c1462fc29 looks intimidating
[19:25:52] <Lockal> Larhzu, all 3 of them were added in Linux 5.13. It is just a single person who gaslighted that "some OS don't have"
[19:26:03] <int-e> (huge diff and tricky code)
[19:26:45] *** Joins: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de)
[19:26:56] *** Quits: Guest67 (~Guest3@2409:40e4:4c:1791:b1b7:9242:493d:80d) (Quit: Client closed)
[19:27:02] <Larhzu> spacespork: I likely talked with the same person the whole time. That's how things are kept convincing. And Jia learned enough that he would have had the skills do be a good maintainer. It took time though, in the beginning it was bad.
[19:27:12] *** Joins: spacespo1k (~satan@user/spacespork)
[19:28:16] <Larhzu> int-e: I might need to re-review it but that was one of the things I asked him to do.
[19:28:50] <rurapenthe> Larhzu, assuming "Jia" is  only 1 person. Not different personas fulfilling required roles... 
[19:28:52] <Larhzu> int-e: As you can see, I was the committer of that commit so what I reviewed was what was merged.
[19:29:22] *** Quits: plat0 (~plato@213.94.27.50) (Remote host closed the connection)
[19:29:23] <Larhzu> rurapenthe: Thus my CAPCOM analogy: https://en.wikipedia.org/wiki/Flight_controller#CAPCOM
[19:29:38] *** Joins: plat0 (~plato@213.94.27.50)
[19:29:43] <Larhzu> rurapenthe: One person talks to me and does most of the day-to-day work with me.
[19:29:43] <rurapenthe> Yep good one
[19:29:46] <susi> Larhzu: how the initial contact happened?
[19:29:52] <Larhzu> xz-devel
[19:30:12] <int-e> Larhzu: Yeah, I'm not trying to suggest that there's anything there. Just that it needs somebody who really understands the code to judge. Which is not me.
[19:30:21] <spacespo1k> Larhzu: did you notice any irregularities with Tan's coding style?
[19:31:23] *** Quits: spacespo1k (~satan@user/spacespork) (Client Quit)
[19:31:28] *** Quits: spacespork (~satan@user/spacespork) (Quit: Lost terminal)
[19:31:30] <Larhzu> int-e: Yep, it's tricky code. Also note it's switch-while, not while-switch.
[19:31:49] <int-e> Larhzu: To pick something simple... the fact that dict_put is changed to be unchecked is scary but at the same time it's *obviously* scary so something that you would've reviewed.
[19:32:01] <Larhzu> int-e: The edit itself isn't as tricky as the diff makes it appear. It still needs a lot of care.
[19:32:38] *** Joins: Guest6 (~Guest78@ip72-204-13-218.fv.ks.cox.net)
[19:32:42] *** Joins: spacespork (~satan@user/spacespork)
[19:33:00] <spacespork> thats better, not sure why my nickname was wrong
[19:33:05] <Larhzu> int-e: If you want to get scared, look at LZMA_IN_REQUIRED and count how many times a new input byte seemingly can be read in unchecked way. Hint: it seems it more than 20.
[19:34:00] <Larhzu> int-e: And yes, unchecked things are on purpose. LZMA SDK has similar but still quite different way.
[19:34:23] <Larhzu> int-e: As a bonus, that code explodes realllly easily if you make a tiny error.
[19:34:34] *** Quits: Guest78 (~Guest78@ip72-204-13-218.fv.ks.cox.net) (Ping timeout: 250 seconds)
[19:35:15] *** Quits: Guest71 (~Guest200@2a01:599:702:4c6b:ed5a:2299:2d58:484e) (Quit: Client closed)
[19:35:21] <FH_thecat> Larhzu: what do you mean, Jia was bad at the beginning? A bad programmer ?
[19:35:22] <Larhzu> I realized the formula for 20 isn't there.
[19:35:43] <spacespork> Larhzu: I had suggested to sam yesterday that we could branch the repo now, and remove the malicious blobs from the main branch. that way we can continue investigating while giving distro devs the option to rollback or compile from the main branch. Thoughts?
[19:35:56] *** Joins: Guest200 (~Guest200@2a01:599:702:4c6b:ed5a:2299:2d58:484e)
[19:36:30] <Larhzu> FH_thecat: I'm really picky, I want proper sentences and grammar and detailed commit messages, not just a single line. And coding style has to be consistent unless there is a reason to deviate.
[19:38:08] <Larhzu> FH_thecat: That is, Jia didn't conform at first and I didn't accept the commits.
[19:39:02] <FH_thecat> Larhzu: the backdoor, and the obfuscation seems quite sophisticated. Do you think he could have come up with it himself ?
[19:39:28] <Larhzu> spacespork: I don't have a clear thought at this time of the evening. I feel I should review the recent suspicious Jia stuff first (year 2024).
[19:39:58] <Larhzu> spacespork: I want to do that with the current repo. So if you get ahead of me then it might be fine or it might be a bit duplicate work.
[19:40:04] * rawtaz thinks everyone should just let Larhzu do his thing now and not interrupt with a ton of various questions and discussion. let the guy focus!
[19:40:24] <Larhzu> FH_thecat: I'll skip speculation for now.
[19:40:43] <spacespork> Larhzu: understandable, i spend a lot of time yesterday thumbing through jia's commits so let me know if i can help at all
[19:40:46] <int-e> rawtaz: or better yet, sleep!
[19:40:52] <rawtaz> yeah that too :)
[19:41:24] <Larhzu> spacespork: Collect what you found, including anything small, no matter how silly it feels.
[19:41:34] <Larhzu> spacespork: And send to me. :)
[19:41:40] <Larhzu> Sleep I need indeed.
[19:41:41] *** Joins: Guest12 (~Guest96@194-218-34-180.customer.telia.com)
[19:41:59] <Larhzu> I wanted to update the home page info a bit. :( But I guess this chat was quite useful too.
[19:42:11] *** Quits: phishing_pharao (~phishing_@ip-037-201-116-138.um10.pools.vodafone-ip.de) (Remote host closed the connection)
[19:42:17] <agl> Larhzu: I'am going also to bed now ;-)
[19:42:23] <Larhzu> Reporters want more info, I thought putting a note online would help.
[19:42:30] <spacespork> Larhzu: gladly, but im not very familiar with irc, mind if i email?
[19:42:46] *** Joins: aaceac (~aaceac@2a00:23c5:9ba2:c300:c564:8150:40ab:95b)
[19:43:13] <Larhzu> spacespork: Email is fine. Sending via IRC is impractical due to firewalls and encryption.
[19:43:44] <Larhzu> (Old times IRC connections weren't encrypted so Linux firewall could peek that IRC protocol packets and open a port dynamically.)
[19:44:09] <hoihoihoi> @Larhzu : please take care of yourself irst & foremost! We all feel for you. 
[19:44:15] *** Quits: Guest12 (~Guest96@194-218-34-180.customer.telia.com) (Client Quit)
[19:44:22] <rawtaz> +1
[19:44:24] <rurapenthe> Old time IRC was basically just an open plate lol
[19:44:34] <rurapenthe> Pretty sure intercepting messages was the norm
[19:44:48] <Larhzu> And also assumed, I guess.
[19:45:19] *** Joins: Guest4 (~Guest27@2804:14d:7481:581c:2d19:b24b:4258:fb44)
[19:46:01] <Larhzu> hoihoihoi: Thanks
[19:46:03] *** Parts: agl (~agl@user/agl) (Good Night)
[19:47:45] *** Joins: kennethm (~kennethm@193.90.196.121)
[19:50:39] *** Quits: Noisymeow (~noisytoot@user/meow/Noisytoot) (Excess Flood)
[19:51:30] *** Joins: phishing_pharao (~phishing_@ip-037-201-116-138.um10.pools.vodafone-ip.de)
[19:51:52] *** Quits: kennethm (~kennethm@193.90.196.121) (Client Quit)
[19:52:05] *** Joins: Noisytoot (~noisytoot@user/meow/Noisytoot)
[19:52:49] <FH_thecat> Larhzu: in summary, this is the most exciting thing that happened in IT security in the last 10 years. Some of us are obsessed with this, and need to know as much as possible. I would rather hear your speculation, than other people's findings.
[19:53:23] <Larhzu> If I speculate, others will extrapolate.
[19:53:35] <Larhzu> I learned a few things today, thanks to this chat.
[19:53:58] *** Joins: junaid_ (~junaid@ip5f587376.dynamic.kabel-deutschland.de)
[19:56:08] *** Quits: spacespork (~satan@user/spacespork) (Ping timeout: 268 seconds)
[19:57:55] <rurapenthe> Definitely so. I think rather than speculation, waiting for what Larhzu thinks is concrete and sure - is of more benefit to us. His thoughts and speculations are best shared between him and a much smaller trusted circle, if any. 
[19:58:35] <Larhzu> What I plan to write is best to be public.
[19:59:07] *** Joins: Guest999 (~Guest999@2a02:8108:50c0:dfd:3c8b:8c0:7468:ce6b)
[19:59:38] <rurapenthe> Looking forward to it :) 
[19:59:57] <Larhzu> This is an opportunity to learn so all info has to be written down so that others can understand warning signs.
[20:00:25] *** Quits: duxsco_ (~duxsco@user/duxsco) (Quit: WeeChat 4.2.1)
[20:00:33] *** Quits: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
[20:00:51] <mali> FH_thecat, you haven't gotten any info then about the past 10 years whatsoever if you  think this was the most exiting thing. check out cool stuff like PyLoose, or heartbleed, or my personal worst nightmare, BPFDoor (don't think anyting can beat this) , apart from I suppose ME/PSP. and ironically, as someone pointed to, a gnu "joke" from 2005? in fact even details an attack more or less ot be exactly like this
[20:01:00] <tomreyn> https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27#analysis-of-the-payload and https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27#references-and-other-reading-material seems to have most if not all of the links with good analysis i've seen during the past days. maybe a good place to start reading tomorrow.
[20:01:02] <rurapenthe> I like your transparency and see your point. Since I'm not in your position I can't really say one way or another what i'de do... 
[20:01:32] *** Joins: hporten (~kvirc@95.90.252.11)
[20:02:01] *** Parts: Guest999 (~Guest999@2a02:8108:50c0:dfd:3c8b:8c0:7468:ce6b) ()
[20:02:17] *** Quits: kiveris (~kiveris@user/meow/kiveris) (Ping timeout: 250 seconds)
[20:02:23] <Larhzu> I count on that I have enough reputation to tell about my mistakes to the public, including those that no one would otherwise know.
[20:02:32] <FH_thecat> mali: heartbleed wasn't a malicious backdoor
[20:02:40] <mali> I completely diagree
[20:02:44] <Larhzu> Because that is needed to maximize the possibility for others to learn.
[20:02:48] *** Quits: junaid_ (~junaid@ip5f587376.dynamic.kabel-deutschland.de) (Remote host closed the connection)
[20:02:50] <FH_thecat> if anything, this has similarities to Stuxnet
[20:03:00] <mali> the openssl boss once stated in emails they had/have over 200 NDAs with NSA for example
[20:03:40] <mali> I think dr. Henson, took one for the team, "taking an arrow to the knee" as he puts it and the German researcher, chucking it in, were both doing it after request imo. but sure, we "don't know"
[20:03:50] <rurapenthe> Larhzu, I wouldn't call it mistakes. Yes, going back on your actions I'm sure you'll identify things you could have done differnently. But, your intent and your hard work was taken advantage of - that is the cause. Mistakes are simply the minor directions you could have taken, but didn't. I prefer the term "my lessons learnt". 
[20:04:31] <Larhzu> rurapenthe: Something like that, yes.
[20:05:01] <rawtaz> jesus christ, dont people realize that every time they address Larhzu here they force a context switch and takes from his time that he said he'd like to spend focusing on what is important right now.
[20:05:17] <Larhzu> I don't have sound notifications. :P
[20:05:24] <Larhzu> I'm just chatting.
[20:05:27] <bnf> Not wanting to create any pressure, but I’d try to not wait too long with publishing information, which you think would be helpful for others to learn – aren’t you afraid law enforcement could prohibit any public statements?
[20:05:33] <hoihoihoi> Like rurapenthe says: this could have happened to anyone. If anything is to blame it's the systems we as a acommunity put in place (or fail to put in place).
[20:05:33] <rurapenthe> rawtaz, I'm sure he's quite capable of not responding anymore if he's busy lol. Its IRC, you expect people to come and go
[20:05:43] <rawtaz> rurapenthe: yeah but its still stupid honestly
[20:05:57] <Larhzu> rurapenthe: Exactly
[20:06:19] *** Joins: Guest82 (~Guest82@50.207.106.34)
[20:06:37] *** Quits: Guest9 (~Guest9@82.77.169.172) (Ping timeout: 250 seconds)
[20:06:51] <Larhzu> rurapenthe: I mean, I fully agree with your comment about IRC.
[20:07:01] *** Joins: Guest24 (~Guest24@176.98.252.77)
[20:07:02] <rurapenthe> Larhzu, yeah I figured :)
[20:07:55] <junon> Larhzu: I work with a former cofounder of github and we do git tooling 24/7. If you end up going with Github, I can help set up Github Actions configs so you're not locked in and don't really have to touch them but still get the benefits. Just LMK, happy to PR, I write those configs all the time.
[20:07:57] <Larhzu> bnf: I'm not particularly fast, it will take more than a week, could be three, depends on how Git repo work vs. article is prioritized.
[20:08:18] <Larhzu> bnf: I don't see any law enforcement issues.
[20:08:41] <Lockal> tomreyn, good link... "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115 - a real bug which xz found" - unfortunately, all compilers are notoriously bad when it comes to "less known features"... I just recently debugged crash in clang miscompilation of lbzip2 and clang crash on VLA... Gentoo helps to find wonderful bugs xD
[20:08:50] <xx> what does it mean if the code contributed by jia has copyright attributed to them? Is it even valid, if it's not a real name? It makes it impossible to relicense the project.
[20:08:59] <FH_thecat> law enforcement ? who would have jurisdiction ?
[20:09:07] <Larhzu> junon: OK, thanks. I didn't understand all of you comment though, Jia handled quite a bit of GH config etc.
[20:09:44] *** Noisytoot is now known as Noisymeow
[20:09:55] <Larhzu> xx: Most was "public domain" until quite recently it became 0BSD. There was a detailed post about by me on GH.
[20:09:58] <junon> Larhzu: tldr is that github actions is a CI system that runs Docker containers on certain repo actions (push, PR, etc.) and can run your CI tasks for you. They're written in YAML and stored under /.github/.
[20:10:07] <junon> They can be a pain to work with if you're new to them.
[20:10:25] <Larhzu> junon: Jia did CI integration.
[20:10:48] <Larhzu> junon: The .github dir likely is that only thing I haven't reviewed at all.
[20:10:49] <vtorri_> i needed sometimes several commits to make them working
[20:10:52] <junon> Ah okay. Well I can certainly take a look whenever the repos come back online, if you'd like.
[20:10:56] <Larhzu> (Well, the new test files I didn't either.)
[20:10:58] <rurapenthe> Law enforcement isn't an issue here. The tool is not malicious, the intent with which it was modified is with malicious - and that applies to the targets they intended it to run on which at this stage are unknown (hence we could assume anywhere). 
[20:11:28] <Larhzu> junon: Or clone the current one from git.tukaani.org.
[20:11:30] <rurapenthe> And its also blatantly clear the modification was meant to be covert, not official.
[20:11:40] <Larhzu> junon: I mean, if you wanted to see what was there.
[20:11:51] <junon> Sure I can do that. :)
[20:12:04] <junon> Will ping back when I've taken a look, probably tomorrow sometime.
[20:12:25] <Larhzu> It was very important for me to keep git.tukaani.org around as a mirror. I didn't like to rely on GH alone.
[20:12:33] <Larhzu> junon: Thanks!
[20:12:49] <junon> rurapenthe: Worth mentioning that the US agency CISA has already launched an investigation.
[20:12:50] <vtorri_> Larhzu, btw, i've begun to write a meson build
[20:13:02] *** Quits: Guest52 (~Guest52@165.225.36.172) (Quit: Client closed)
[20:13:23] <tomreyn> Lockal: thanks for the link. i read about this on one of the other posts referenced by sam's github gist, but had not read the gcc bugzilla post, yet (i also think it's over my head, though - i'm not a programmer).
[20:13:25] <Larhzu> vtorri_: Autoconf side might have slightly more features than CMake side but difference is nowadays fairly small.
[20:13:59] <vtorri_> Larhzu, which kind of features for example ?
[20:14:14] *** Joins: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de)
[20:14:45] <rurapenthe> Junon - oh I'm sure they are interested in who and why and what. Especially who is behind it and why 
[20:14:48] <Larhzu> vtorri_: For example, see the list at the top of CMakeLists.txt.
[20:14:58] <rurapenthe> I mean, we would all love to know that.
[20:15:21] <Larhzu> vtorri_: First version doesn't need to be full config option selection.
[20:15:44] <junon> Larhzu: Have you spoken with Github about the suspension at all?
[20:15:46] <Larhzu> vtorri_: I don't think I want to maintain three build systems though.
[20:15:51] <vtorri_> Larhzu, i've already written the same options than autoconf :)
[20:16:13] <Larhzu> junon: Not yet, plan was some point this week but my schedule plans tend to be optimistic all the time.
[20:16:16] <vtorri_> Larhzu, that's why the build must be simplified first
[20:16:47] *** Quits: Guest32 (~Guest25@164.92.98.0) (Quit: Client closed)
[20:16:59] <Noisymeow> If you do go with GitHub, there should at least be a way to report bugs and submit patches that does not require using GitHub/nonfree software
[20:17:08] <vtorri_> i've looked at some Makefile.am and i find them too complicated
[20:17:34] <Larhzu> vtorri_: src/common/tuklib_physmem.c is a place to look for OSes that are supported. I wonder if Meson does them all.
[20:18:13] <Larhzu> Noisymeow: I fully agree. Email is such way and to me it's equally fine.
[20:18:18] <junon> Noisymeow: You can interact with GH issues with email.
[20:19:00] <Larhzu> My view about non-free JavaScript question is milder than Noisymeow's even though I understand his point. But...
[20:19:17] <Larhzu> ...I like that bug reporting can be done without creating accounts. Sure, many have a GH account already but still.
[20:19:21] <Red> there's nothing wrong w/ autotools, it works as you'd expect everywhere and then some.
[20:19:54] <Noisymeow> junon: I don't think you can do that without an account (the creation of which requires using nonfree JavaScript)
[20:20:06] <vtorri_> Larhzu, https://mesonbuild.com/Reference-tables.html
[20:20:16] *** Quits: Guest4 (~Guest27@2804:14d:7481:581c:2d19:b24b:4258:fb44) (Quit: Client closed)
[20:20:44] *** Joins: duxsco (~duxsco@user/duxsco)
[20:20:44] <vtorri_> no qnx support for example
[20:20:48] *** Quits: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
[20:21:15] <Larhzu> Red: Libtool shared versioning has been a complaint for me.
[20:21:20] <Larhzu> Red: https://lists.gnu.org/archive/html/libtool/2011-06/msg00006.html
[20:21:32] *** Parts: Earnestly (~earnest@user/earnestly) (WeeChat 4.2.1)
[20:21:41] <Larhzu> Red: FreeBSD was changed quite some time ago and QNX fix was merged very recently.
[20:21:52] *** Quits: andibmu (~andi@dslb-094-216-240-042.094.216.pools.vodafone-ip.de) (Ping timeout: 246 seconds)
[20:22:02] <vtorri_> also irix
[20:22:02] *** Joins: johuck (772e02f487@2a03:6000:1812:100::1343)
[20:22:12] <Red> irix died a long time ago, nobody uses it
[20:22:13] *** Quits: Guest24 (~Guest24@176.98.252.77) (Ping timeout: 250 seconds)
[20:22:15] *** Joins: Guest23 (~Guest73@2a02:9140:4d80:4e00:709f:a9a3:5937:eb06)
[20:22:38] <joepie91> xx: regarding your copyright question: copyright is assigned to the creator of something by default (whether it is explicitly asserted or not), and no 'government name' is necessarily required to enforce it; see also writer pseudonyms for books
[20:22:39] <Red> is there even a supported version of hpux?
[20:23:03] <Larhzu> vtorri_: Oh, cool :) but IRIX is dead.
[20:23:14] <joepie91> so from a copyright perspective this isn't a terribly interesting case, other than that it's unlikely the true author will ever claim copyright, because they will likely want to keep their identity hidden even from courts
[20:23:17] <joepie91> (disclaimer: I am not a lawyer)
[20:23:19] <Red> meson definitely doesn't support any of these old things either.
[20:23:21] <Larhzu> Red: I think so
[20:23:28] <Red> "is it linux"
[20:23:30] <Red> "is it macos"
[20:23:32] <Red> "is it windows"
[20:23:49] <Larhzu> People actually use xz on less common platforms.
[20:24:02] <Red> <--- one such user
[20:24:17] *** Quits: duxsco (~duxsco@user/duxsco) (Client Quit)
[20:24:27] <abby> Red: did you see the support tables linked earlier? it's far more than just linux/mac/win https://mesonbuild.com/Reference-tables.html
[20:24:31] <xx> joepie91: but it's the difference between you thinking it's a single person, vs it suddenly becoming a nameless team within a security agency
[20:24:42] *** Joins: big-MAC (~bigMAC@user/big-MAC)
[20:24:51] <Noisymeow> Does xz support hurd?
[20:25:00] <Larhzu> Noisymeow: I hope
[20:25:35] <Red> abby, linux, *bsd, windows (& cygwin), macos and solaris & its forks yes yes.
[20:26:12] * emaste wrestling with a discussion about how FreeBSD is not vulnerable to this specific class of attack, and how to explain it without appearing to gloat
[20:26:38] <Larhzu> abby: https://web.archive.org/web/20240308213521/https://xz.tukaani.org/xz-utils/#platforms
[20:27:02] <Riastradh> emaste: `we got lucky; we weren't targeted by _this_ attack even if we could be vulnerable in principle to this _kind_ of attack'
[20:27:26] <Red> Larhzu, it runs unmodified on a new posix layer for windows too:-)
[20:27:53] <Larhzu> emaste: liblzma and various other libs getting linked to sshd just because a dependency needs those for some reason... modesty is good but no need to over-do it in this case.
[20:28:30] <emaste> Larhzu: but in this case we import xz bits into the FreeBSD base system but discard the upstream build infra and write our own
[20:28:39] <Riastradh> emaste: (we are in the same situation over in NetBSD and pkgsrc)
[20:29:14] <Larhzu> emaste: That's one thing I've wondered, how to make it simpler for you as the build stuff used to change somewhat often a bit.
[20:29:54] *** Joins: notif (~notif@host-131-239-155-186.customer.veroxity.net)
[20:29:55] <emaste> Larhzu: yeah - I'm not quite sure what to think about what we do in fact, we have something like 100+ contrib software bits and our own bespoke build infra for all of them
[20:30:09] <Larhzu> Noisymeow: See the archive.org link above, GNU/HURD is mentioned, I don't remember who tested it.
[20:31:02] <Larhzu> emaste: With xz you need big/little endian, fast/non-fast unaligned access, CPU-specific bits, ... I'm sorry for the hassle.
[20:31:18] <sh4> and symbol versioning :-p
[20:31:51] <kevans> our makefile for liblzma is acutally not that bad
[20:31:59] <Larhzu> FreeBSD can use the same symbol versioning for all targets, right?
[20:32:07] <emaste> oh on the topic of build systems this came up in libarchive as well - I suggested dropping the autoconf build and just using cmake
[20:32:13] <Riastradh> Larhzu: Speaking on behalf of NetBSD: it's easiest if it's organized into libraries composed of a clear set of .c files, and programs composed of a clear set of .c files and library dependencies, plus a clear set of build options.
[20:32:52] <Larhzu> Riastradh: At lib side, build options affect which files are chosen. Although NetBSD likely builds just the main fast variant with full features.
[20:33:00] *** Quits: patjk (~patjk@198-91-249-44.cpe.distributel.net) (Quit: peace)
[20:33:02] <emaste> Riastradh: for FreeBSD too. (aside, I wonder how much of an opportunity there is to share the bmake build effort)
[20:33:03] <Riastradh> NetBSD's liblzma makefile doesn't strike me as particularly gnarly, slightly more complicated than some but not that bad.
[20:33:04] <Larhzu> Riastradh: But one cannot just *.c for the lib.
[20:33:06] <vtorri_> write xz 6.0 with a clean base first :)
[20:33:10] <kevans> Larhzu: yes, we maintain one Symbol.map for all archs
[20:33:31] <Larhzu> kevans: Not using the upstream liblzma_generic.map?
[20:33:31] *** Quits: Guest23 (~Guest73@2a02:9140:4d80:4e00:709f:a9a3:5937:eb06) (Quit: Client closed)
[20:33:40] <kevans> nope, but perhaps it's derived from it
[20:33:45] <Larhzu> :)
[20:33:53] *** Quits: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu) (Ping timeout: 240 seconds)
[20:34:02] <kevans> hmm, maybe not. we had one case of a symbol that needed to be removed that was done far post-mortem
[20:34:16] *** Quits: Riastradh (~riastradh@netbsd/board/riastradh) (Remote host closed the connection)
[20:34:21] *** Joins: tolto (~tolto@81.90.125.229)
[20:34:44] *** Quits: hoihoihoi (~hoihoihoi@89.205.135.51) (Remote host closed the connection)
[20:34:51] *** Quits: smpl (~smpl@user/smpl) (Quit: Leaving)
[20:34:51] *** Quits: tolto (~tolto@81.90.125.229) (Read error: Connection reset by peer)
[20:35:07] *** Joins: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu)
[20:35:09] <Larhzu> kevans: No one likely needs to install liblzma out-of-tree anyway.
[20:35:47] *** Joins: Riastradh (~riastradh@netbsd/board/riastradh)
[20:35:53] <Riastradh> oops, network blip
[20:35:57] *** Joins: Guest8 (~Guest8@37.166.198.144)
[20:36:23] <Larhzu> Now I really must go to sleep.
[20:36:31] <vtorri_> gn
[20:36:31] <Larhzu> Thanks! Bye!
[20:36:32] <kevans> emaste: in any event, you could just add that "we're only not vulnerability to this class because of probably antiquated build/import practices"
[20:36:35] <kevans> perhaps
[20:36:40] <emaste> Larhzu: good night!
[20:36:41] <Lockal> bye Larhzu 
[20:36:43] *** Quits: Guest8 (~Guest8@37.166.198.144) (Client Quit)
[20:37:10] *** Joins: Guest8 (~Guest8@37.166.198.144)
[20:37:18] <Riastradh> kevans: I don't think this particular back door would have affected FreeBSD even if it used the autoconf-based build system.
[20:37:33] *** Joins: patjk (~patjk@198-91-249-44.cpe.distributel.net)
[20:37:48] <emaste> it looks like we added Symbol.map for FreeBSD's liblzma in 2010
[20:37:49] <kevans> nah, that's harder to accomplish... we do have IFUNC support, but I have no idea how that works cross-DSO
[20:38:28] <Riastradh> kevans: Do you have a FreeBSD system handy?  What does `echo foobar | (head -c +3 >/dev/null; head -c +4)' print?
[20:38:48] <kevans> nothing
[20:39:00] *** Joins: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8)
[20:39:33] *** Quits: Guest98 (~Guest95@cpc102338-sgyl38-2-0-cust532.18-2.cable.virginm.net) (Quit: Client closed)
[20:39:38] *** Quits: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8) (Changing host)
[20:39:38] *** Joins: kiveris (~kiveris@user/meow/kiveris)
[20:39:41] <Riastradh> We looked into the mechanism extensively to see whether it would affect NetBSD or any pkgsrc platforms, and we're confident neither 5.6.0 nor 5.6.1 would affect NetBSD, for different reasons -- and it's unlikely to affect even pkgsrc on Linux for other reasons.
[20:40:06] <sauce> I don't think it's a reach to say that vendoring libs mitigates supply chain attacks. definitely doesn't eliminate them though
[20:40:22] <Riastradh> kevans: The stage-1 injection script relies on head(1) to consume exactly the number of bytes requested from the standard input file descriptor.  Otherwise it has on hope of getting the stage-2 injection script.
[20:40:41] <Riastradh> no hope
[20:41:14] <emaste> Riastradh: so there's a head(1) bug to fix here :)
[20:41:15] *** Quits: Guest82 (~Guest82@50.207.106.34) (Quit: Client closed)
[20:41:15] <kevans> hmm, trying to decide if this is technically a head(1) bug
[20:41:17] <kevans> heh
[20:41:22] <Riastradh> kevans: And, on both NetBSD and FreeBSD, head(1) consumes a buffer's worth of data from the standard input stream.  So on NetBSD it produces an empty stage-2 injection script, and I bet the same is true on FreeBSD.
[20:41:41] <Riastradh> We talked about whether it's a bug and kre (Robert Elz) is convinced it's intentionally allowed by POSIX.
[20:42:11] <Riastradh> That's for 5.6.0; for 5.6.1 the $(uname) = "Linux" test in the stage-1 and stage-2 scripts would also thwart it on FreeBSD.
[20:42:14] *** Joins: Guest24 (~Guest24@176.98.252.77)
[20:42:50] *** Quits: Guest200 (~Guest200@2a01:599:702:4c6b:ed5a:2299:2d58:484e) (Quit: Client closed)
[20:43:17] <Riastradh> But, you can see that this is a matter of target choice, not a matter of vulnerability to the class of attacks.
[20:43:27] *** Quits: Guest8 (~Guest8@37.166.198.144) (Ping timeout: 250 seconds)
[20:43:27] <kevans> my interpretration is that it's not just allowed, it's mandated based on the version I'm reading
[20:43:28] <Riastradh> Could've used dd instead of head and that part would have worked.
[20:43:46] <kevans> "The head utility shall copy its input files to the standard output, ending the output for each file at a designated point."
[20:43:48] <int-e> or another awk script
[20:44:05] <kevans> ending the output at a designated point is pretty non-ambiguous, this is 1003.1-2017
[20:44:08] <emaste> Riastradh: but I mean discarding upstream's build infra is what prevents a class of attack
[20:44:10] <Riastradh> (I didn't look up head(1) in POSIX, I deferred to kre, no idea what it really says here, was kinda preoccupied with other matters!)
[20:44:10] <kevans> unambiguous, even
[20:44:17] *** Quits: Guest399 (~Guest399@194.127.199.53) (Quit: Client closed)
[20:44:42] <kevans> hmm
[20:44:47] <Riastradh> emaste: Well, kinda.  Does running autoreconf count as discarding upstream's build infra?  Not discarding entirely, but close.
[20:44:47] <kevans> but this is the rest of stdin
[20:45:04] <Riastradh> kevans: (`ending the _output_' isn't about how much input it consumes)
[20:45:07] <kevans> yeah
[20:45:24] <emaste> for anyone interested, we've reviewed all of the jiat0218@gmail.com commits in libarchive, and found one that is in hindsight a plausibly intentional minor security regression
[20:45:50] *** Joins: Guest82 (~Guest82@50.207.106.34)
[20:46:03] *** Quits: Guest82 (~Guest82@50.207.106.34) (Client Quit)
[20:47:16] <susi> but which one
[20:47:26] <Riastradh> That's the safe_fprintf one?
[20:47:29] *** Joins: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de)
[20:47:49] <emaste> Riastradh: maybe that qualifies, but I mean we didn't even import autoconf parts into the vendor tree
[20:47:56] <emaste> Riastradh: the safe_fprintf one, indeed
[20:48:40] <kevans> yeah, this version at least omits any mention of how to treat it; it'd probably be good to get clarification, even if to explicitly state that it's not defined
[20:49:05] <emaste> reverting to safe_fprintf isn't sufficient though, libarchive issue #2107 is open to track a better fix
[20:49:54] <Riastradh> Well I'd love to follow along but github just suspended my account today!
[20:49:59] *** Joins: duxsco (~duxsco@user/duxsco)
[20:50:04] <emaste> Riastradh: wth
[20:51:15] *** Quits: Guest24 (~Guest24@176.98.252.77) (Quit: Client closed)
[20:51:18] <Riastradh> As far as I'm aware I'm not in any exciting position like Larhzu, but maybe CISA knows something I don't...!
[20:55:04] *** Quits: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu) (Quit: Quit)
[20:55:22] *** Joins: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu)
[20:58:01] <emaste> it's interesting that Jia Tan added the Capsicum sandboxing support in xz
[20:58:15] <kevans> yeah, I was eyeballing the implementation a little bit ago
[20:58:24] *** Joins: js (~js@matrix.netbsd.org)
[20:58:44] <kevans> seems to be fine, and it's actually enabled when I build locally from upstream build 
[21:02:15] *** Joins: lipmas (~lipmas@2601:280:5c00:1e90::7)
[21:04:56] <Guest59> Riastradh: note that it seems autoreconf even with --force may not have been enough to clear all pre-existing files: https://lists.debian.org/debian-devel/2024/03/msg00367.html
[21:05:14] <Riastradh> Guest59: Yes, that was my point about discarding (some of) the build system.
[21:05:39] *** Quits: Guest15 (~Guest56@2a0e:1d47:419c:4400:c06a:6f51:f1a:109f) (Quit: Client closed)
[21:07:17] *** Quits: kiveris (~kiveris@user/meow/kiveris) (Ping timeout: 250 seconds)
[21:08:02] *** Joins: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net)
[21:08:15] *** Joins: Guest1 (~Guest22@r179-25-81-233.dialup.adsl.anteldata.net.uy)
[21:08:35] <js> I never understood why m4 files that are in /usr/share/aclocal anyway need to be checked in. If you're regenerating configure, you have auto* installed anyway.
[21:09:38] <vegard_no> isn't it to support older versions of auto*?
[21:09:49] *** Quits: Mooncairn (~mooncairn@user/mooncairn) (Quit: Leaving)
[21:09:58] <Lockal> Guest59, there is an idea to download releases not from https://github.com/tukaani-project/xz/releases/download/..., but from https://github.com/tukaani-project/xz/archive/refs/tags/..., effectively eliminating all injected binaries. I'm just waiting when the dust settles down, but for me it looks like "the only way"
[21:10:22] <js> vegard_no: Which is pretty pointless if the first line is AC_PREREQ
[21:10:45] *** Quits: Guest6 (~Guest78@ip72-204-13-218.fv.ks.cox.net) (Ping timeout: 250 seconds)
[21:11:35] <beber_> Should f9cf4c05edd14dedfe63833f8ccbe41b55823b00 be cherry-picked on top of origin/v5.6 ? the dot issue is still present on that branch
[21:13:20] <aaceac> any updates? is 5.4.1 still considered safe?
[21:14:21] *** Quits: phishing_pharao (~phishing_@ip-037-201-116-138.um10.pools.vodafone-ip.de) (Remote host closed the connection)
[21:14:29] *** Quits: b00p (~b00p@c-73-179-92-98.hsd1.fl.comcast.net) (Quit: b00p)
[21:14:53] *** Joins: alanparker3 (AP@user/meow/Alanparker3)
[21:15:29] *** Joins: Guest78 (~Guest78@ip72-204-13-218.fv.ks.cox.net)
[21:15:29] *** Quits: duxsco (~duxsco@user/duxsco) (Quit: WeeChat 4.2.1)
[21:16:39] *** Quits: beber_ (~beber_@2a05:d018:c28:1a00:fd:d0ae:0:5222) (Quit: Gateway shutdown)
[21:17:33] *** Joins: Guest46 (~Guest22@2a09:bac2:b1d6:de1::162:1b)
[21:17:53] *** Quits: aesthetics (~user@user/aesthetics) (Quit: leaving)
[21:19:20] *** Joins: aesthetics (~user@user/aesthetics)
[21:19:42] *** Joins: beber_ (~beber_@2a05:d018:c28:1a00:fd:d0ae:0:5222)
[21:21:01] *** Quits: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de) (Ping timeout: 256 seconds)
[21:21:12] *** Quits: Guest46 (~Guest22@2a09:bac2:b1d6:de1::162:1b) (Client Quit)
[21:21:37] *** Joins: spacespork (~satan@user/spacespork)
[21:22:00] *** Quits: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu) (Read error: Connection reset by peer)
[21:23:09] *** Joins: Guest72 (~Guest22@2a09:bac2:b1d1:de1::162:1e9)
[21:23:44] *** Joins: ceejay63 (~ceejay@2600:387:f:5713::1)
[21:25:05] *** Quits: ceejay63 (~ceejay@2600:387:f:5713::1) (Client Quit)
[21:25:35] *** Quits: Guest72 (~Guest22@2a09:bac2:b1d1:de1::162:1e9) (Client Quit)
[21:26:05] *** Joins: Guest56 (~Guest22@2a09:bac2:b1d5:1791::259:bd)
[21:27:28] *** Joins: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8)
[21:27:36] *** Quits: kiveris (~kiveris@2a02:8084:513b:e00:546b:e034:3bd6:4db8) (Changing host)
[21:27:36] *** Joins: kiveris (~kiveris@user/meow/kiveris)
[21:29:46] <alanparker3> Hi, I’m a maintainer of an internal linux distro used only internally at a cloud company based on Debian. We noticed we picked the package from the unstable debian, is there anything we should know / check if this was exploited?
[21:30:11] <alanparker3> Luckily this is on our testing infrastructure so it never went beyond that stage
[21:30:31] <q66> do you have outside-facing sshd
[21:30:40] <q66> if not, probably nothing to worry about
[21:30:56] *** Joins: tolto (~tolto@20014C4E1E193000B18C623D51B087CA.dsl.pool.telekom.hu)
[21:31:02] *** Joins: ceejay83 (~ceejay@2600:387:f:5713::1)
[21:31:45] *** Quits: 080AAL0DP (~onlyJak0b@p50865e95.dip0.t-ipconnect.de) (Remote host closed the connection)
[21:31:52] <f_[xmpp]> alanparker3: use 5.4.5
[21:32:15] <f_[xmpp]> you should have 5.6.1+really5.4.5-1 installed if you upgraded anyway
[21:32:21] *** Quits: Guest56 (~Guest22@2a09:bac2:b1d5:1791::259:bd) (Quit: Client closed)
[21:32:28] *** Quits: ceejay83 (~ceejay@2600:387:f:5713::1) (Client Quit)
[21:32:31] <f_[xmpp]> (which just packages 5.4.5)
[21:33:00] *** Joins: ceejay68 (~ceejay@2600:387:f:5713::1)
[21:33:19] *** Quits: ceejay68 (~ceejay@2600:387:f:5713::1) (Client Quit)
[21:33:50] *** Joins: Guest10 (~Guest22@2a09:bac3:b1d1:166e::23c:2a)
[21:33:50] <alanparker3> okay I see we will check internally. They do have externally facing SSHD through our test domain (test.example.com). They all are setup with fail2ban but I guess in that case that would not help much.
[21:34:22] <cjwatson> I don't expect fail2ban would have helped, no
[21:36:28] *** Joins: neurognostic (~neurognos@gateway/tor-sasl/neurognostic)
[21:36:28] <kevans> f_[xmpp]: it sounds like they already understand their upgrade plan, they're trying to ascertain if anything bad came in during the time the bad version was present
[21:37:07] *** Quits: Guest10 (~Guest22@2a09:bac3:b1d1:166e::23c:2a) (Client Quit)
[21:38:36] <alanparker3> Also on a more human level, I wanted to say I’m sorry to Lasse Collin and I wish him all the best. We know it’s a bit of a messy situation but we are grateful for his work during all those years
[21:39:09] *** Joins: r2rien (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr)
[21:39:14] *** Joins: turtleturtle19 (~turtletur@user/meow/turtleturtle)
[21:39:36] *** Joins: Guest13 (~Guest93@dsl-hkibng42-5673c9-155.dhcp.inet.fi)
[21:40:20] *** Quits: spacespork (~satan@user/spacespork) (Ping timeout: 252 seconds)
[21:41:01] <tomreyn> alanparker3: he mentioned twice that he appreciates all the goodwill he is receiving but that he's going to fully concentrate on the technical aspects for now (i hope i have summarized this somewhat correctly).
[21:41:18] <alanparker3> I just checked. On our newest test release we have 5.6.1+really5.4.5-1. I guess we will just "burn" to the ground the previous one and make sure it is never used
[21:42:03] *** Joins: Guest22 (~Guest22@2a09:bac3:b1d2:1678::23d:42)
[21:42:59] <cjwatson> I'm not up to speed with the details of the backdoor reverse-engineering effort, but my conservative assumption would be that a successful attack leaves no logs.
[21:43:33] <cjwatson> At least in the absence of extra stuff like logs on external firewalls.
[21:45:48] *** Joins: orfeo (~orfeo@17-124-205-185.access.kommitt.de)
[21:45:49] <kevans> yeah, there's likely no evidence to detect an intrusion in any generic way
[21:46:08] *** Joins: nozaq (nozaq@user/nozaq)
[21:46:53] *** Joins: Guest44 (~Guest22@2a09:bac2:b1d1:a0::10:4d2)
[21:47:01] *** Quits: Guest22 (~Guest22@2a09:bac3:b1d2:1678::23d:42) (Quit: Client closed)
[21:48:05] *** Quits: Guest44 (~Guest22@2a09:bac2:b1d1:a0::10:4d2) (Client Quit)
[21:48:19] *** Joins: spacespork (~satan@user/spacespork)
[21:48:22] *** Joins: marius2 (~marius2@p5b2955c6.dip0.t-ipconnect.de)
[21:50:20] *** Quits: notif (~notif@host-131-239-155-186.customer.veroxity.net) (Quit: Client closed)
[21:50:32] *** Parts: mdehling (~mdehling@076-088-053-132.res.spectrum.com) (WeeChat 4.1.2)
[21:50:34] *** Quits: Guest1 (~Guest22@r179-25-81-233.dialup.adsl.anteldata.net.uy) (Quit: Client closed)
[21:52:09] *** Quits: orfeo (~orfeo@17-124-205-185.access.kommitt.de) (Quit: orfeo)
[21:52:16] *** Joins: Cjunky (~Cjunky@107.116.92.51)
[21:53:50] *** Quits: Cjunky (~Cjunky@107.116.92.51) (Remote host closed the connection)
[21:55:07] *** Quits: midou (~midou@sl.projectsegfau.lt) (Ping timeout: 255 seconds)
[21:56:01] *** Joins: Palaver (~Palaver@178.sub-174-198-15.myvzw.com)
[21:56:44] <alanparker3> We do not believe we got intruded because it is relatively new and probably was never used in the wild. But still
[21:56:45] *** Joins: Cjunky (~Cjunky@107.116.92.49)
[21:57:21] *** Quits: pajlada (~pajlada@user/pajlada) (Remote host closed the connection)
[21:58:01] *** Quits: Cjunky (~Cjunky@107.116.92.49) (Remote host closed the connection)
[21:58:28] *** Joins: Cjunky (~Cjunky@107.116.92.49)
[21:58:51] *** Quits: Guest78 (~Guest78@ip72-204-13-218.fv.ks.cox.net) (Ping timeout: 250 seconds)
[21:59:36] *** Quits: Cjunky (~Cjunky@107.116.92.49) (Remote host closed the connection)
[22:00:24] *** Palaver is now known as john
[22:00:33] *** Joins: Cjunky (~Cjunky@107.116.92.50)
[22:00:54] *** john is now known as Guest2509
[22:01:16] *** Guest2509 is now known as POLITICOJohn
[22:01:55] <NachPlus> alanparker3: I wouldn't rely on fail2ban for anything, it parses logs periodically, at that point, it's already too late. Also, this is assuming that SSHd is the only attack vector. The binary blob hijacks a bunch of libcrypto functions, beyond the RSA signature verification, and they haven't all been studied yet. It's possible those other ones do something else under the right conditions. Just as an example, imagine you have a web browser linked 
[22:01:56] <NachPlus> against liblzma and libcrypto, and one of the other vectors attacks you when you visit some webpage.
[22:02:37] *** Joins: Guest74 (~Guest74@2a00:1169:11f:d680::)
[22:02:48] *** Joins: mikecmpb3l (~mikecmpbl@179.48.251.105)
[22:04:17] *** Joins: Guest69 (~Guest69@d-159-250-123-247.fl.cpe.atlanticbb.net)
[22:05:01] *** Quits: r2rien (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr) (Quit: Quit)
[22:05:04] <js> alanparker3: If you have an externally open SSHD, it's time to reinstall.
[22:05:35] <tomreyn> my understanding is that debian decided to burn down their build infrastructure and set it up again, just to be safe.
[22:05:56] *** Quits: mikecmpbll (~mikecmpbl@92.40.189.134.threembb.co.uk) (Ping timeout: 272 seconds)
[22:05:58] <js> cjwatson: Correct, it's RCE, not auth bypass
[22:06:38] *** Quits: Guest69 (~Guest69@d-159-250-123-247.fl.cpe.atlanticbb.net) (Client Quit)
[22:06:38] <spacespork> tomreyn: i had heard they were considering that, but hadn't heard anything definitive
[22:06:51] *** Quits: bauen1 (~bauen1|@ppp-212-114-180-66.dynamic.mnet-online.de) (Ping timeout: 268 seconds)
[22:07:01] <js> NachPlus: it's being studied over at #xz-backdoor-reversing @ OFTC. So far nobody has found anything that would trigger outside of SSHD, but that of course doesn't mean there isn't something else.
[22:07:43] *** Quits: POLITICOJohn (~Palaver@178.sub-174-198-15.myvzw.com) (Remote host closed the connection)
[22:08:27] *** Joins: bauen1 (~bauen1|@ppp-212-114-180-66.dynamic.mnet-online.de)
[22:08:34] <NachPlus> js: And have they yet explained why it's also hooking into functions for DSA, ECDSA, and SM?
[22:09:04] *** Joins: POLITICOJohn (~POLITICOJ@178.sub-174-198-15.myvzw.com)
[22:09:27] <spacespork> js: do you know how much research has been put into the riscv test binaries? in my report to lasse i noted how the commits for those have been suspicous
[22:10:25] *** Quits: mikecmpb3l (~mikecmpbl@179.48.251.105) (Ping timeout: 255 seconds)
[22:10:47] <js> NachPlus: The payload to be executed is hidden in the client certificate public key
[22:11:01] <js> spacespork: I believe some have looked into it, but it's hard to follow everything. There is about 1000 people over there.
[22:11:18] *** Quits: POLITICOJohn (~POLITICOJ@178.sub-174-198-15.myvzw.com) (Remote host closed the connection)
[22:11:30] *** Joins: dostoyev1ky2 (~sck@user/dostoyevsky2)
[22:11:58] <js> (you won't see all of them on the IRC side, but there's about 200 on Matrix and 700 on Discord)
[22:12:02] <NachPlus> js: I'm aware of that, that still doesn't explain why it needs access to those other public key functions
[22:12:31] *** Joins: r2rien (~r2rien@abordeaux-653-1-47-108.w90-11.abo.wanadoo.fr)
[22:12:36] *** Quits: dostoyevsky2 (~sck@user/dostoyevsky2) (Quit: leaving)
[22:12:42] <js> NachPlus: I haven't looked into it myself, so I don't feel confident making any claim, but I heard some people claim that it reimplements parts of SSHD because it still needs to function normally
[22:13:16] *** Quits: dostoyev1ky2 (~sck@user/dostoyevsky2) (Client Quit)
[22:13:37] <NachPlus> js: If all that it did was hijack the RSA verification, and wrap back to the true one as pass through when not getting a special payload, it wouldn't need any other connections to function normally
[22:13:43] *** Joins: dostoyevsky2 (~sck@user/dostoyevsky2)
[22:14:02] *** Quits: clopnaz (~clopnaz@pool-108-3-96-88.pitbpa.east.verizon.net) (Quit: Lost terminal)
[22:14:21] <js> NachPlus: Best to ask over there 🙂. But my understanding was that people found some code in there that pretty much looked like upstream openssh
[22:14:39] *** Joins: xaero (~xaero@irc.stevesoltys.com)
[22:15:09] <NachPlus> js: I've been reviewing it myself, I'm almost certain there's at least two other bits of stuff hidden in there, but I haven't been able to figure out what it's doing
[22:15:24] *** Quits: beforelight (~user@32-218-57-192.bng02.brpt.ct.frontiernet.net) (Quit: WeeChat 4.2.1)
[22:16:00] <wb9688> js: Ah, so Matrix still hasn't properly fixed their bridges
[22:16:11] *** Joins: wikky (~wikky@memleek.org)
[22:16:14] <abby> were they ever going to?
[22:16:38] <wb9688> They were supposed to, but I doubt it, yeah
[22:16:51] <f_[xmpp]> wb9688: I don't expect them to do so
[22:17:06] <wb9688> Me neither anymore
[22:17:06] <f_[xmpp]> their bridge still spams and leaks messages around
[22:17:50] <NachPlus> js: I also haven't heard of SM support being added to OpenSSH. So that to me looks like a red flag. I am more familiar with the OpenSSL side of the code, and the parts I think it might recreating is missing a bunch of stuff that should be there if it was recreating some OpenSSL functionality.
[22:18:46] <ztrawhcse> Larhzu: speaking of portability between OSes, the OpenSSL developers very famously refuse to use either GNU autotools or CMake because neither one work well on OpenVMS. tuklib_physmem supports VMS though... :) -- as for meson, it should work on any platform with python3, "the big three" as well as BSD/AIX/Solaris are known to work, muon "should" support any POSIX compatible platform
[22:19:07] <spacespork> signing off now, cheers from outer space
[22:19:09] *** Quits: spacespork (~satan@user/spacespork) (Quit: leaving)
[22:19:13] *** Quits: Guest43 (~Guest43@2001:1838:200d:2:46c7:85d0:3a81:45a6) (Ping timeout: 250 seconds)
[22:19:20] <js> NachPlus: SM support?
[22:19:26] <ztrawhcse> amiga and djgpp really are the kind of thing where I always have to feel skeptical anyone has tested it in the last 10 years. No one ever seems to ask for support, that much I know...
[22:19:49] <js> f_[xmpp]: You might have a better experience using an XMPP -> Matrix bridge rather than going XMPP -> IRC -> Matrix -> Discord
[22:19:52] <NachPlus> js: Chinese cryprtography
[22:20:09] <js> ztrawhcse: I used both this year!
[22:20:15] <NachPlus> js: The binary blob is wraping those functions in libcrypto, but I don't know why
[22:20:24] <wb9688> js: He normally is directly on IRC but his znc died
[22:20:30] *** Quits: crawler (~crawler@user/crawler) (Ping timeout: 272 seconds)
[22:20:44] <f_[xmpp]> wb9688: I do not use znc
[22:20:51] <f_[xmpp]> I use soju
[22:20:52] <js> yeah, but still, XMPP already supports more than IRC so the experience should be better
[22:21:02] <f_[xmpp]> js: it's worse actually
[22:21:13] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Remote host closed the connection)
[22:21:14] <js> wow, that's an achievement
[22:21:19] <f_[xmpp]> the xmpp bridge is completely b0rked
[22:21:25] *** Quits: Cjunky (~Cjunky@107.116.92.50) (Remote host closed the connection)
[22:21:26] <js> maybe there's an XMPP -> Discord bridge?
[22:21:29] <f_[xmpp]> I cannot send messages
[22:21:37] *** Joins: Cjunky (~Cjunky@107.116.92.50)
[22:21:38] *** Joins: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64)
[22:21:39] <wb9688> f_[xmpp]: Oh, sorry, I thought you said that and because it died you are using your XMPP backup? But I might of course be mixing up some things :)
[22:21:45] <f_[xmpp]> js: Maybe, but I'm usually on IRC
[22:21:57] *** Quits: Cjunky (~Cjunky@107.116.92.50) (Remote host closed the connection)
[22:22:03] <js> I can look into setting up heisenbridge instead of the OFTC bridge
[22:22:13] <js> but then on IRC everything will look like "<bridge> someuser: foo"
[22:22:17] *** Joins: Cjunky (~Cjunky@107.116.92.50)
[22:22:33] <f_[xmpp]> wb9688: yeah pretty much my bouncer died so I use that xmpp<>irc bouncer-like gateway connection instead :>
[22:23:06] <f_[xmpp]> js: the issue is using 2 separate bridges that were not designed to be used together
[22:23:31] <wb9688> Not sure where I got znc from then, maybe someone else recently mentioned that somewhere, but it doesn't matter much anyway what bouncer you are using
[22:23:39] <ztrawhcse> js: interesting. What do you use them for?
[22:23:43] *** Joins: Guest22 (~Guest22@r179-25-81-233.dialup.adsl.anteldata.net.uy)
[22:23:44] <wb9688> I am using WeeChat in tmux running 24/7 on my NUC
[22:23:59] <f_[xmpp]> I usually shorten 'bouncer' to 'bnc' so maybe you got it from that lol
[22:24:47] <js> f_[xmpp]: Yeah, I think the problem is that nicknames in anything but IRC can contain spaces, while on IRC they can't, so the bridge takes the username instead of the nickname, which for discord users is just their user ID.
[22:24:49] <tomreyn> in response to spacespork, who left: https://fulda.social/@Ganneff/112184975950858403
[22:25:02] <f_[xmpp]> js: no..
[22:25:04] <wb9688> f_[xmpp]: Hmm… that might be a thing and then just mixing up the first letter lol
[22:25:13] *** Quits: neurognostic (~neurognos@gateway/tor-sasl/neurognostic) (Ping timeout: 260 seconds)
[22:25:32] <f_[xmpp]> those arw stripped out usually
[22:25:35] <f_[xmpp]> *are
[22:25:41] <wb9688> Or replaced or whatever
[22:25:50] * f_[xmpp] afk
[22:26:35] <wb9688> But without double puppeting you don't have that problem lol, but idk what's worse
[22:26:50] *** Quits: marius2 (~marius2@p5b2955c6.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
[22:27:00] *** Quits: Cjunky (~Cjunky@107.116.92.50) (Remote host closed the connection)
[22:27:44] *** Quits: xybre (~xybre@about/music/xybre) (Quit: Konversation terminated!)
[22:27:53] *** Quits: jghali_ (~jghali@21.50.195.77.rev.sfr.net) (Read error: Connection reset by peer)
[22:28:22] *** Joins: jghali_ (~jghali@21.50.195.77.rev.sfr.net)
[22:28:55] *** Joins: queenbeectoria (~queenbeec@fixed-187-190-11-77.totalplay.net)
[22:29:01] *** Joins: jghali__ (~jghali@21.50.195.77.rev.sfr.net)
[22:29:06] <queenbeectoria> Hello!
[22:29:08] <js> wb9688: Exactly, not sure what's worse, not having user mappings or having bad user mappings 😉
[22:29:50] *** Joins: Cjunky (~Cjunky@107.116.92.50)
[22:30:08] *** Quits: Cjunky (~Cjunky@107.116.92.50) (Remote host closed the connection)
[22:30:19] *** Joins: nerblock (~nerblock@2E8BD921.catv.pool.telekom.hu)
[22:31:15] *** Quits: Lockal (~Lockal@user/Lockal) (Remote host closed the connection)
[22:32:53] *** Quits: jghali_ (~jghali@21.50.195.77.rev.sfr.net) (Ping timeout: 255 seconds)
[22:33:36] *** Joins: Guest79 (~Guest79@122.161.65.113)
[22:33:59] *** Quits: vtorri_ (~vtorri@2a01:e0a:a4f:12e0:bdad:d397:dd28:6d64) (Ping timeout: 268 seconds)
[22:34:25] <Guest74> I wonder if bricking a linux install with `rm -rf /` and then flashing new clean bootable media is sufficient. What do you think? :)
[22:34:45] *** Joins: mikecmpb1l (~mikecmpbl@92.40.189.136.threembb.co.uk)
[22:36:49] *** Joins: spacespork (~satan@user/spacespork)
[22:37:04] *** Quits: steckie (~steckie@p54b6fe0d.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
[22:37:32] <alanparker3> @guest74 you proably are joking, but re-installing / reflashing is more than enough
[22:38:27] *** Joins: Cjunky (~Cjunky@107.116.92.49)
[22:38:37] <ztrawhcse> you'd fail to brick it anyway...
[22:38:51] *** Quits: hporten (~kvirc@95.90.252.11) (Ping timeout: 260 seconds)
[22:39:08] *** Quits: Cjunky (~Cjunky@107.116.92.49) (Remote host closed the connection)
[22:40:53] *** Quits: Guest22 (~Guest22@r179-25-81-233.dialup.adsl.anteldata.net.uy) (Quit: Client closed)
[22:41:56] *** Joins: marius2 (~marius2@p200300cd370893cba124cdb3e21053bc.dip0.t-ipconnect.de)
[22:42:08] *** Quits: mikecmpb1l (~mikecmpbl@92.40.189.136.threembb.co.uk) (Quit: Lost terminal)