06:20:08 fun, the new lib xz with systemd and ssh backdoor sounds linux specific 06:22:21 xz (XZ Utils) 5.4.4 liblzma 5.4.4 ftw! 06:23:07 rolling releases bite you, imho... 06:23:15 i like static os.. 06:24:56 yeah, but ssh doesn't use it. systemd did. 06:25:19 i was reading that linux boxes that patch sshd to use logind to inform systemd are the ones vulnerable 06:25:23 no new features just correct current errors would be nice 06:25:50 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 06:25:51 Title: xz-utils backdoor situation · GitHub 06:30:17 we don't include the test bits (payload) in our import of it, and we don't use its build system 06:30:27 so even if there was a chance it wasn't linux specific 06:30:47 (it'd have to be a bit less stealthy to hit us) 06:30:59 supply chain attack pip python, java log4j 06:31:13 nothing new at this point 06:31:28 same old shit dog just a different day 06:31:34 hehe 06:31:52 * kevans queues up some DMX 06:33:44 smoke a bowl and drink a pint... 06:35:29 we need you to come in this easter weekend... 06:37:55 rennj: actually... this being a security bug in 3 layers deep code is novel 06:39:31 i'm simultaneously surprised but not at all that andres seems to be the first to detect it 06:41:52 (he's very good at what he does, which is... usually database stuff) 06:43:07 or more horrifying 06:43:23 all those checks, and unit tests 06:43:32 haha...reproducable builds 06:44:05 nix so easy to just roll back 06:44:42 ah, sounds like it also needs glibc 06:44:49 just another failure what i see.. ports/pkg..source..what diff..if your backdoored on github 08:13:19 that's a hell of an attack chain 08:13:31 makes me want to hang up the computer and grow edible lupins 08:28:24 <[0x1eef]> Probably too late for that :P 08:30:03 [0x1eef], yes, I know the lupin supply chain in Canada is fully patented 08:30:13 <[0x1eef]> Lol 08:30:19 I don't give a fuck 08:55:39 is there an order to zfs / nullfs mount in /etc/fstab? I have some zfs mounts explicitly in my /etc/fstab and then I have some null mounts and the null mounts are empty 11:18:53 hi all 11:19:01 Hi 11:24:10 hi 12:02:51 The blender version for freebsd 14 (3.6.1) has a segfault bug in a feature I need. How do I go about handling this? 12:05:35 ideally I'd upgrade to 4.1 but something tells me that's not going to be easy 12:21:15 i am working on getting a zfs dataset to show in a jail and the jail is able to "see" the datasets with a zfs list but when i do try ot mount it, i get this error message: cannot set property for 'storage/movies': 'mountpoint' cannot be set while dataset 'zoned' property is set 12:37:31 afternoon 13:43:53 entikan: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275819 no idea what is missing there 13:43:56 Title: 275819 – graphics/blender update to v4.0.2 14:53:03 are we affected by the xz backdoor or whatever? 14:53:50 Only Linux is 14:55:12 mmlj4: it targets linux distros which have sshd which loads systemd library, which loads xz, which rewrites it's functions 14:55:48 ah, thanks 17:39:01 ketas: that's one known possible target. so far nobody knows the true target, there are a lot of programs which use RSA and link to liblzma 17:49:10 that payload seems have some argv[0] = /usr/sbin/sshd check, so pretty sure only some sshds where directly affected, but as it was a RCE, no idea what happend after that 17:49:54 there is some discussion on the mailing list about other issues in the source which don't seem directly related to the sshd code, but it's not clear if that's another vulnerability or just preparation for something that would have been added later 19:30:08 That malicious agent was playing "the long game". We will be learning much as it is studied and reverse engineered. 19:34:09 systemd :) 19:46:23 OT here but the main issue around the xz exploit was that systemd brings in a godzillian million lines of dependent code that is not needed nor otherwise used. That's definitely on systemd as a problem. 19:47:43 rwp: i don't think this is systemd's fault. Linux vendors could have chosen to implement the systemd notify protocol themselves (it's extremely simple) but made the decision to link to a systemd library instead 19:48:55 lw, Yes but the implementation is strongly influenced by the mentality that systemd must be obeyed and must be used for everything. It's not technology at this point. It is a cult with religious zealots. 19:49:31 i don't know what that means - there's no requirement to "obey systemd", you can implement the (publicly-documented) notification protocol any way you like, as far as i know 19:50:10 linking to a systemd library in sshd certainly doesn't seem like a great idea (at least in hindsight) but systemd doesn't force anyone to do that 19:56:31 rwp: if the vector via systemd and xz didn't exist, they would have found another way to bring the payload into sshd 19:59:55 nimaje: or just exploited it via the linux kernel, since xz is imported there 20:00:08 i assume they decided sshd route was less likely to be detected 20:00:10 lw, If you participate in any interaction with any of the distros that use systemd and propose even accidental ability to do something without systemd you will be shouted down as a bad person for not using systemd. It's a peer pressure thing. You might not find it in the systemd documentation. But you will find it in any interaction with the people. 20:01:18 rwp: this is not about whether sshd supports systemd or not. they could have provided this systemd-related functionality without linking to libsystemd, which would not have brought in liblzma/xz 20:01:55 the notification protocol is *extremely* simple and trivial to implement in an application 20:02:16 OpenSSH upstream does not use it at all. It was the systemd developer base that imposed itself upon sshd. Do you think systemd developers are going to use something systemd independent? 20:03:09 rwp: i'm not suggesting they use something "systemd independent" - what i'm saying is that this systemd functionality can be implemented *in exactly the same way* to talk to systemd without linking to libsystemd. that doesn't make it more portable and it doesn't change what it does - it simply implements exactly the same functionality without bringing in libsystemd's dependencies 20:03:42 given what we know about exploitation methods for network servers, even before this issue, not linking to libsystemd in sshd would have been a fairly reasonable choice 20:04:23 Uhm... It's certainly possible to do anything. What I am saying is that they won't do just anything. They will force implementation using systemd. That's just what they are doing. Everyday. And if anyone proposes something different then they will have to fight tooth and nail to get independence instead of systemd. That's just the facts of my experience dealing with them. 20:05:04 what do you mean by "force implementation using systemd"? 20:05:33 the feature we're talking about is to allow sshd to communicate its current state to systemd over the notify socket - however you implement it, it's specific to systemd, so this isn't about doing something "with systemd" or "without systemd" 20:05:57 I'll put on my Devil's advocate cap here. This is not me. Since systemd implements this functionality already then you should be using systemd to do it. Not using systemd is always going to be the wrong thing to do. 20:06:17 do you mean libsystemd, rather than systemd? because systemd is always involved here, the only question is whether to use libsystemd or not 20:07:12 It's Debian Policy as decided by the ctte to use systemd as the default infrastructure for Debian. By Policy we do not need to support any other solution. If you want to do something without systemd then you should fork the package and maintain it yourself. 20:07:35 It is clear that you are not using Debian. Since by Policy Debian is using systemd. Please say what OS you are actually using? 20:07:44 I have had all of the above said to me over the years. 20:07:46 ... 20:07:57 rwp: i think the argument lw is making is that you don't need to *link* to libsystemd which has in-process memory access and depends on liblzma. however i do agree that a systemd discussion here is a bit irrelevant 20:08:03 dstolfa: yes, exactly 20:08:20 And in the end they are right. I am here in FreeBSD using FreeBSD on my servers and on my desktop now. So in the end the are now proven correct. 20:08:40 Discussing systemd here is completely off topic. 20:08:52 there is no need to link to libsystemd to do what sshd does, and not linking to sshd does not mean you're "not using systemd" - that Debian policy quote is completely irrelevant 20:08:57 Unless FreeBSD decided to adopt it. And then it would be an awful day. 20:09:26 i'll drop it, but the original statement i was replying to (about systemd) seems incorrect, so i wanted to correct wrong information 20:09:40 It's relevant because you were asking and perhaps insisting strongly that systemd folks were not requiring use of systemd everywhere. That's the point I was refuting. 20:10:00 no, i didn't say anything like that. 20:10:34 No one disagrees that it isn't technically possible not to use libsystemd there. Many don't. But Debian et al are linking it it. Because that is the systemd way to do things. 20:11:37 systemd is like that science. and if you question it... 20:12:04 You are questioning it? You must be a heretic! 20:12:25 Anything unrelated to elephants is irrelephant. Let's move on. Sorry I ranted so strongly. It's a sore point. 20:13:09 are you anti-systemd ? 20:14:22 its a joke :) 20:32:22 rwp: even Poetttering said, if all you're doing is sending a notify, use a fuckin socket() call. Don't link all of libsystemd if that's all you're doing. 20:33:18 My point that I've made a couple of times now still stands: If that pull request had been properly reviewed instead of ignored, people could've come to that conclusion, instead, distros just started pulling it as "good enough" 21:35:35 Hi everyone! 21:36:00 Does anyone know if we're going to see errata notices / OS patches released to address libarchive? 21:36:03 https://github.com/libarchive/libarchive/pull/2101 21:36:05 Title: tar: make error reporting more robust and use correct errno by emaste · Pull Request #2101 · libarchive/libarchive · GitHub 21:37:47 jmpp: i don't know, but i would suggest asking Ed since he submitted the PR 21:38:09 (emaste⊙fo) 21:40:10 already did in the GitHub PR 21:40:26 but just wanted to check the box of asking here, in case anyone knew the answer 21:40:35 does Ed hang around here in IRC? 21:41:29 jmpp: i am curious too so i asked him on Mastodon 21:41:35 will let you know if he replies... 21:41:43 i don't think he's on irc here 21:41:45 thank you, most appreciated! 21:42:38 what a shitshow this xz ordeal! 21:43:25 I am just flabbergasted reading the details, how it occurred over the years, everythign that went into place, the ramifications 21:44:17 jmpp: i really hope this leads to a serious evaluation of the human factors involved in open source development 21:44:32 other industries (like aviation) recognised this a long time ago, software engineering really has not 21:44:46 by far the most important resource, for sure 21:45:24 and surely one on the lower-end of of our attention and focus 21:46:03 lw: right, when it was realized that a pilot had the capacity to, oooppsss, fly a plane into a giant wall, whether that was a mountain... or a building?! 21:47:01 jmpp: i mentioned this in another channel (that perhaps we should consider the needs of individial open source developers) and someone did a big eye-roll about "coddling" people and "making their life perfect"... pretty clear we do not have a 'safety culture' in IT :-( 21:47:45 (i've thought for a long time that 'software engineering' is a bad term, because engineers normally have ethical and moral obligations in the things they do, and software 'engineers' do not have those) 21:48:16 lw: sounds to me like the kind of person who'd not even consider contributing to an open source project in any way, and then feel entitled to complain very loudly about bugs, delayed release schedules, etc. 21:50:48 lw: I'd tend to agree. Computers are, simply put, general purpose software machines, and people tend to not appreciate the ramifications of what those machines can do with the (in)correct set of instructions, and therefore tend to not think about that problem too much, as opposed to how a civil engineer, for example, would think about what'd happen to a bridge if not built correctly 21:51:29 a fuck, just realized macOS has xz 5.6.1! 21:51:48 at least, as far as we know, macOS isn't affected by the backdoor 21:51:56 right, right, Linux only 21:52:10 and it's not bundled by Apple, it's my MacPorts installation 21:52:44 In the there's-a-xkcd-for-everything dept: https://xkcd.com/2347/ and https://www.explainxkcd.com/wiki/index.php/2347:_Dependency#Transcript 21:52:45 Title: xkcd: Dependency 21:53:04 port outdated --> xz 5.6.1_0 < 5.4.6_0 (epoch 0 < 1) 21:53:07 heh! 21:53:16 V_PauAmma_V: heh, i mentioned this specifically in my comment on the other channel -- everyone always linked this xkcd, no one does anything about it 21:53:24 * jmpp "upgrades" 21:54:06 cf. openssl 21:54:32 and IIRC, somethign similar happened with cURL at some point 22:03:41 i wonder, if i have both ipfw and pf enabled, which goes first? i'd like to use ipfw for NAT64, but pf for firewall, since ipfw is missing important feature like ipv6 fragment reassembly 22:06:40 apparently OpenBSD's pf supports nat64, maybe i should just use that 22:15:09 * V_PauAmma_V nods at lw. 22:16:11 https://github.com/libarchive/libarchive/commit/02cfa8ae67fa60e6d0415b75babf64864f0d8e72#commitcomment-140401844 22:16:12 Title: Reusing code from zip size known and adjusting comments · libarchive/libarchive@02cfa8a · GitHub 22:16:14 facepalm! 22:17:40 V_PauAmma_V: is that a nod about using OpenBSD? i did, once, many years ago... maybe i should see how it's doing nowadays 22:18:04 (i always preferred NetBSD, but NetBSD's npf doesn't seem to do NAT64, and since pf's upstream is OpenBSD, i guess it makes sense to just use that...) 22:20:40 lw: Ed must be incredibly busy right now! https://github.com/libarchive/libarchive/issues/2103 22:20:43 Title: re-review commits · Issue #2103 · libarchive/libarchive · GitHub 22:20:43 2103 – syslogd cannot log to ttys https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=2103 22:21:10 jmpp: i have the impression he's always quite busy 22:25:03 i really wish there one OS that did everything i need and wasn't Linux 22:25:37 other than my Unifi devices, I don't have any Linux at home, and I just couldn't be happier! 22:26:18 i've been having endless problems with 15.0 on rpi to the point that i'm considering booting Linux on them and running FreeBSD in a VM... 22:26:56 and I do, of course, know that this situation right now is not per se Linux's fault, but man, I'd hate to be right now in a position of having to defend the Linux echosystem (*cough*TrueNAS SCALE*cough*!) 22:27:20 that a lot of talk there was here 22:27:26 personally i'm happy if other people use Linux, that just means fewer exploits targetting FreeBSD or other OSs 22:27:31 since my highlight 22:31:26 why imagemagick is pictured as small stick in that xkcd 22:31:30 it's open? 22:31:56 so you can't really kick it off 22:32:07 causing contraption to collapse 23:13:56 how do i enable the audio jack port on freebsd? 23:32:09 has anyone tried "Chimera Linux"? https://chimera-linux.org/about/ -- it seems to be a Linux kernel with FreeBSD userland... 23:32:10 Title: Chimera Linux - About 23:37:28 lw: re engineers having obligations, phk has written about that at some lengths, with the go-to example being electricians who're certified, or at least work under someone whose job it is to check that anything does matches the certification specifications they hold 23:37:58 it's interesting that we have code of absolutely equal criticality to electrical engineering, but without any of the certification requirements 23:38:48 as for macOS, the presumptive apt did clone ziparchive, which is used in macOS: https://github.com/JiaT75/ZipArchive 23:38:49 Title: GitHub - JiaT75/ZipArchive: ZipArchive is a simple utility class for zipping and unzipping files on iOS, macOS and tvOS. 23:39:21 debdrup: yeah, most engineers have obligations... but software 'engineers' really don't, from what i can see 23:39:41 i suspect if phk doesn't know about them, nobody does :) 23:40:16 he probably wouldn't know without checking either, but i'm certain he knows how to check 23:42:12 i know in some fields, like aviation, there are specific engineering criteria for software and you could probably call that 'engineering' 23:42:18 but that ofc really doesn't apply to open source 23:43:41 it doesn't apply to proprietary software at large either, it's specifically fields with much larger oversight 23:44:18 yeah. i just mean it doesn't apply to open source since that's specifically what matters to us 23:45:26 (ofc, Boeing showed us that even having these criteria doesn't guarantee funcitonal software... but still)