2025/01/22

Newest at the top

2025-01-22 07:49:44 +0100euleritian(~euleritia@dynamic-176-006-129-235.176.6.pool.telefonica.de)
2025-01-22 07:49:31 +0100euleritian(~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2025-01-22 07:47:17 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 248 seconds)
2025-01-22 07:46:58 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-22 07:46:31 +0100beaky_beaky
2025-01-22 07:42:51 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-22 07:42:21 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-22 07:40:24 +0100aforemny(~aforemny@2001:9e8:6ce4:b500:6e75:95aa:3ce2:b258) (Ping timeout: 272 seconds)
2025-01-22 07:39:32 +0100aforemny_(~aforemny@i59F4C565.versanet.de) aforemny
2025-01-22 07:32:55 +0100weary-traveler(~user@user/user363627) (Remote host closed the connection)
2025-01-22 07:31:33 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-22 07:27:00 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-22 07:25:25 +0100agent314(~quassel@208.131.130.69) (Ping timeout: 248 seconds)
2025-01-22 07:23:43 +0100 <homo> btw, the following patch is required to be applied to hugs to ignore integer overflow https://github.com/augustss/hugs98-plus-Sep2006/commit/a87d3a15194e4d7724627e43a94ac1d12ab78f9c.pa…
2025-01-22 07:21:36 +0100acidjnk(~acidjnk@p200300d6e7283f9028c796acceb77e24.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
2025-01-22 07:19:35 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-01-22 07:19:14 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2025-01-22 07:15:39 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2025-01-22 07:14:04 +0100michalz(~michalz@185.246.207.205)
2025-01-22 07:08:56 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-22 07:04:35 +0100Sgeo(~Sgeo@user/sgeo) Sgeo
2025-01-22 07:04:02 +0100 <homo> also xz situation shows why free software is important: you can fix it on source level (instead of disassembling binary) and you can legally share your fixes with other people
2025-01-22 06:58:45 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-22 06:58:06 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 276 seconds)
2025-01-22 06:57:07 +0100ft(~ft@p4fc2a1c1.dip0.t-ipconnect.de) (Quit: leaving)
2025-01-22 06:56:05 +0100 <homo> geekosaur even without security concern, for academic haskell this is proof where each binary comes from, guix is a very cool distro for science
2025-01-22 06:54:05 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-22 06:53:07 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-01-22 06:47:14 +0100bgamari(~bgamari@64.223.233.64)
2025-01-22 06:46:46 +0100acidjnk(~acidjnk@p200300d6e7283f9028c796acceb77e24.dip0.t-ipconnect.de) acidjnk
2025-01-22 06:45:51 +0100fmira(~user@user/fmira) fmira
2025-01-22 06:45:46 +0100bgamari(~bgamari@64.223.233.64) (Remote host closed the connection)
2025-01-22 06:43:32 +0100ColinRobinson(~juan@user/JuanDaugherty) (Ping timeout: 252 seconds)
2025-01-22 06:43:17 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2025-01-22 06:38:42 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-22 06:31:15 +0100 <probie> geekosaur: It's no security panacea, but it still reduces the number of parties you need to trust
2025-01-22 06:28:12 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds)
2025-01-22 06:25:38 +0100 <geekosaur> that's just one way to do it. the one I described above is another. there are a lot of exploits possible; RoTT isn't about a single specific form of exploit but the entire class. it uses the specific one as an example
2025-01-22 06:23:18 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-22 06:23:15 +0100 <mange> Isn't the point of "reflections on trusting trust" that the exploit survives in the binary alone? Bootstrapping at least ensures we can find the exploit in source, eventually.
2025-01-22 06:16:10 +0100tnt2tnt1
2025-01-22 06:16:10 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 272 seconds)
2025-01-22 06:16:04 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-01-22 06:15:15 +0100 <geekosaur> (so you're going to vet patches. (a) damn lot of patches in something as old as gcc; (b) Alice strings together 30 patches, each innocuous but together you get the xz exploit. Will you catch that?)
2025-01-22 06:12:21 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds)
2025-01-22 06:11:55 +0100 <geekosaur> I have to say I still don't see the point. The only thing I can think of is vetting the entire build chain, but the xz exploit demonstrated that "Reflections on Trusting Trust" is still with us and only gets worse with every new link in the chain
2025-01-22 06:07:56 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-22 06:06:08 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 252 seconds)
2025-01-22 06:06:07 +0100 <jackdk> MicroHs will be buildable from Hugs, meaning that we have at least one actively developed Haskell compiler that's bootstrappable from C, which means you could if you wanted root its bootstrap chain in hex0, the couple-hundred-byte assembler
2025-01-22 06:01:43 +0100alfiee(~alfiee@user/alfiee) alfiee