00:05:03 | | sralracer quits [Client Quit] |
00:09:01 | <immibis> | c3manu: browsers always do syscalls directly... so does every other program... |
00:09:19 | <immibis> | even with glibc you can do direct syscalls by calling syscall(SYS_open, whatever...) |
00:09:33 | <immibis> | and the glibc wrappers around most syscalls are basically direct wrappers anyway |
01:35:36 | | BlueMaxima joins |
01:36:08 | | etnguyen03 (etnguyen03) joins |
01:43:45 | | Naruyoko5 quits [Quit: Leaving] |
01:53:42 | | useretail quits [Quit: Leaving] |
02:34:38 | | wickedplayer494 quits [Remote host closed the connection] |
02:39:21 | | Gadelhas5625 joins |
02:42:33 | | Gadelhas5623 joins |
02:42:50 | | Gadelhas562 quits [Ping timeout: 260 seconds] |
02:42:50 | | Gadelhas5623 is now known as Gadelhas562 |
02:45:53 | <pabs> | c3manu that_lurker - James Mickens is another great speaker https://mickens.seas.harvard.edu/wisdom-james-mickens |
02:46:20 | | Gadelhas5625 quits [Ping timeout: 260 seconds] |
02:46:36 | <pabs> | (scroll down) |
02:54:17 | | lukash98 joins |
03:06:54 | <pabs> | https://firesky.tv/ - Bluesky firehose site |
03:07:26 | <pabs> | websocket: wss://firesky.tv |
03:07:48 | <pabs> | rss site, needs a filter parameter https://rss.firesky.tv |
03:07:57 | | SootBector quits [Ping timeout: 240 seconds] |
03:08:42 | | SootBector (SootBector) joins |
03:14:40 | | etnguyen03 quits [Client Quit] |
03:15:16 | | etnguyen03 (etnguyen03) joins |
03:17:37 | | sec^nd quits [Remote host closed the connection] |
03:18:10 | | sec^nd (second) joins |
03:22:43 | | wickedplayer494 joins |
03:39:40 | | etnguyen03 quits [Remote host closed the connection] |
03:40:09 | | sec^nd quits [Remote host closed the connection] |
03:40:27 | | sec^nd (second) joins |
03:41:12 | <pabs> | in case anyone is using puppet: https://www.puppet.com/blog/open-source-puppet-updates-2025 |
03:41:23 | <pabs> | now might be the time to switch away from it |
03:44:15 | <steering> | "it's because supply chain attacks, even though it has nothing to do with them. just trust us!" |
03:45:13 | <steering> | and "same license" but then "The new development license is an EULA"?? what are they actually saying? that they're not going to do development under Apache so it's just going to rot? |
03:46:24 | <pabs> | the binaries will be under the EULA, they will be doing dev in a private git repo and the public git repo will get some lower amount of commits |
03:47:14 | <pabs> | and anarcat mentioned something about no longer publishing ruby gems |
03:53:06 | <pabs> | (anarcat and other Tor folks are maintaining the puppet source+binary packages uploaded to Debian) |
03:53:44 | <steering> | ah the good ol' "we still want you to do unpaid work for us but we're not going to give anything back" |
03:54:18 | | BlueMaxima quits [Read error: Connection reset by peer] |
04:11:47 | | FartWithFury (FartWithFury) joins |
04:14:21 | <nulldata> | https://wordpressenginetracker.com/ |
04:16:29 | <FartWithFury> | Yeah wp admin is going nuts |
04:34:31 | <@OrIdow6^2> | "ship any new binaries and packages developed by our team to a private, hardened, and controlled location" |
04:34:38 | <@OrIdow6^2> | What I imagine: concrete bunker |
04:35:10 | <@OrIdow6^2> | What it probably actually is: a webpage with a single checkbox |
05:40:27 | | FartWithFury quits [Read error: Connection reset by peer] |
05:58:12 | <that_lurker> | pabs: Could maybe be a good idea to create external link grabber for the bluesky firehose and run them in #// |
05:59:04 | <pabs> | sounds good to me, I didn't manage to get anything from the websocket yet. focused on #wikibot for a bit |
05:59:22 | <pabs> | I'm not familiar with #// very much btw |
06:34:25 | | pixel (pixel) joins |
07:11:03 | | pixel leaves |
07:24:20 | | Dango360_ (Dango360) joins |
07:27:18 | | Dango360 quits [Ping timeout: 240 seconds] |
07:35:05 | | MetaNova quits [Ping timeout: 260 seconds] |
07:38:45 | | midou quits [Remote host closed the connection] |
07:42:20 | | MetaNova (MetaNova) joins |
08:00:19 | | midou joins |
09:06:33 | | ducky quits [Ping timeout: 260 seconds] |
09:07:31 | | lennier2_ quits [Quit: Going offline, see ya! (www.adiirc.com)] |
09:15:17 | | nulldata quits [Client Quit] |
09:16:11 | | nulldata (nulldata) joins |
09:23:00 | | Doranwen quits [Ping timeout: 260 seconds] |
09:59:45 | | driib quits [Quit: The Lounge - https://thelounge.chat] |
10:00:05 | | driib (driib) joins |
11:05:36 | | sralracer joins |
11:06:45 | | sralracer is now authenticated as sralracer |
11:14:47 | | Dango360_ quits [Read error: Connection reset by peer] |
11:23:56 | | ducky (ducky) joins |
12:00:03 | | Bleo182600722719623 quits [Quit: The Lounge - https://thelounge.chat] |
12:02:48 | | Bleo182600722719623 joins |
12:05:24 | | Dango360 (Dango360) joins |
12:15:03 | | Doranwen (Doranwen) joins |
12:22:18 | | Doranwen quits [Ping timeout: 240 seconds] |
12:23:03 | | Doranwen (Doranwen) joins |
13:18:28 | <that_lurker> | "How to self-host all of Bluesky (except the AppView (for now))" https://alice.bsky.sh/post/3laega7icmi2q |
13:21:00 | | Doranwen quits [Ping timeout: 260 seconds] |
13:21:30 | | Doranwen (Doranwen) joins |
13:26:48 | | midou quits [Remote host closed the connection] |
13:26:55 | | midou joins |
13:29:30 | | Doranwen quits [Read error: Connection reset by peer] |
13:29:52 | | Doranwen (Doranwen) joins |
13:54:58 | | xDEADBEEF quits [Ping timeout: 240 seconds] |
13:55:49 | | th3z0l4 joins |
13:57:20 | <immibis> | steering: developers are champing at the bit to do unpaid labour for mega corporations, if you hadn't noticed. It's why everything is MIT licensed these days |
14:00:40 | | th3z0l4 quits [Ping timeout: 260 seconds] |
14:00:59 | <Harzilein> | immibis: that's a very simplistic view |
14:01:00 | | th3z0l4 joins |
14:51:07 | <immibis> | the simplest explanation is usually the correct one |
14:54:32 | | Chris50100 (Chris5010) joins |
14:56:18 | | Chris5010 quits [Ping timeout: 240 seconds] |
14:56:18 | | Chris50100 is now known as Chris5010 |
16:56:42 | | qwertyasdfuiopghjkl18 joins |
17:00:22 | | qwertyasdfuiopghjkl quits [Ping timeout: 255 seconds] |
17:05:35 | | katocala quits [Ping timeout: 260 seconds] |
17:06:21 | | katocala joins |
17:27:38 | | katocala quits [Ping timeout: 240 seconds] |
17:28:09 | | katocala joins |
18:04:11 | <c3manu> | immibis: welp, sounds like understand even less of that stuff than i thought ^^ |
18:04:48 | | ducky quits [Read error: Connection reset by peer] |
18:04:53 | | ducky (ducky) joins |
18:05:21 | <immibis> | you should be worried if they say JAVASCRIPT can do syscalls directly. If it's just the browser itself, that's fine. |
18:05:50 | <immibis> | it's actually useful for sandboxing to know exactly what syscalls your process makes, bypassing glibc |
18:07:14 | <nicolas17> | or for setting up the sandbox, which may involve newly-introduced syscalls that are not exposed by glibc |
19:13:05 | <immibis> | glibc always had a bypass mechanism to make direct syscalls, and it knows the sandboxing syscalls (seccomp, prctl, bpf) |
19:13:25 | <immibis> | the problem is if you whitelist the open syscall, but when you call the open wrapper, it actually makes an openat syscall |
19:13:49 | <immibis> | you have to know things like that, and they can change. Making syscalls directly makes a more reliable sandbox because you know which ones they are. |
19:15:58 | | Aoede_ is now known as Aoede |
19:26:38 | | ThreeHM quits [Ping timeout: 240 seconds] |
19:28:58 | | ThreeHM (ThreeHeadedMonkey) joins |
20:12:59 | | Dango360_ (Dango360) joins |
20:16:46 | | DigitalDragons quits [Read error: Connection reset by peer] |
20:16:47 | | Exorcism quits [Read error: Connection reset by peer] |
20:16:55 | | Dango360 quits [Ping timeout: 260 seconds] |
20:17:02 | | DigitalDragons (DigitalDragons) joins |
20:17:11 | | Exorcism (exorcism) joins |
20:39:09 | | BlueMaxima joins |
20:51:07 | | DigitalDragons quits [Client Quit] |
20:51:07 | | Exorcism quits [Client Quit] |
20:52:26 | | Exorcism (exorcism) joins |
20:53:01 | | DigitalDragons (DigitalDragons) joins |
21:26:10 | | Dango360_ quits [Read error: Connection reset by peer] |
21:27:05 | | useretail joins |
21:28:14 | | etnguyen03 (etnguyen03) joins |
21:32:33 | | Dango360 (Dango360) joins |
21:59:19 | | BearFortress quits [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] |
22:30:08 | | etnguyen03 quits [Client Quit] |
22:39:44 | | revi is now authenticated as revi |
22:40:02 | | BearFortress joins |
22:40:29 | | revi quits [Changing host] |
22:40:29 | | revi (revi) joins |
22:47:22 | <kpcyrd> | the puppet.com blogpost sounds like they are completely lost and have no idea what they are doing. if you want good supply-chain security you try to be as transparent as possible and deploy reproducible builds, what they are doing is the polar opposite |
22:49:37 | <kpcyrd> | I don't understand the connection to javascript and syscalls |
22:49:51 | <kpcyrd> | if you squint hard enough html can do syscalls |
22:50:08 | <immibis> | javascript and syscalls have nothing to do with puppet - they have to do with javascript and syscalls |
22:51:42 | <kpcyrd> | the trick to Linux is understanding everything is assembly interfaces that happen to use the C calling convention |
22:51:51 | <kpcyrd> | seccomp is infamous for being painful |
22:52:11 | <kpcyrd> | not just because of libc, but also because of dynamic linking, and downstream patches |
22:53:02 | <kpcyrd> | Debian patches their libc in ways that requires additional syscalls, so if you develop on Arch Linux the program may not work when compiled on Debian |
22:53:49 | <kpcyrd> | (when using hand-rolled syscall seccomp allow-lists) |
22:59:14 | | revi quits [Quit: Updating details, brb] |
22:59:21 | | revi (revi) joins |
23:00:35 | <kpcyrd> | (the catch with dynamic linking is that "use of new syscall" is not considered a breaking change, but with seccomp it may, potentially leaving your program in a broken state until somebody notices and a new update is rolled out) |
23:09:53 | | etnguyen03 (etnguyen03) joins |
23:10:48 | | superkuh quits [Remote host closed the connection] |
23:44:38 | <steering> | kpcyrd: everything everywhere in computers is "assembly interfaces" :) |
23:46:23 | <nicolas17> | I read of an Intel engineer who said "oh assembly is too high level for me" |
23:46:35 | <kpcyrd> | steering: good luck putting assembly into /bin/sh :) |
23:46:36 | <steering> | ok, fine, except maybe microcode :D |
23:47:10 | <nicolas17> | obligatory https://gist.github.com/nicolas17/966a03ce49f949dd17b0123415ef2e31 |