06:43:52 kevans: Thanks for the info. I'll look into that. 06:45:36 So BSD tar can understand linux initrd (compressed cpio). But nowadays they are often several compressed cpio files catted together. Is there a straightforward way to tell bsdtar tf "some idiot catted several archives together, keep looking for more archives after the first one"? 06:51:31 "bsdtar --options read_concatenated_archives -tf /initrd.img" didn't Just Work. (I'm assuming all BSDs have basically the same tar -- if not, I'll try to reproduce this on actual fbsd) 08:14:45 twb: OpenBSD tar is the same binary as for cpio and pax so your assumption is wrong from the outset. 08:15:41 Fair enough 08:39:15 freebsds tar has read_concatenated_archives in the man page, but that only speaks about tar archives, no idea if it works on non-tar archives 08:41:44 I think they have to be cated before compression 08:41:47 date >x; (bsdtar cz x; bsdtar cz x) | bsdtar t --options read_concatenated_archives ==> x 08:41:51 date >x; (bsdtar c x; bsdtar c x) | gzip | bsdtar t --options read_concatenated_archives ==> x x 08:43:21 the linux initrd stuff is typically like "cat microcode.cpio firmware.cpio.gz rootfs.cpio.zst" so not even consistently compressed 09:32:32 Hello, all. My FreeBSD box has sent me this e-mail today , complaining that it cannot download an XML with vulnerabilities. Is it a problem on FreeBSD side, on my side, or between the chair and keyboard? 09:40:32 this is a far shout: what do you have for `grep VULNX /usr/local/etc/pkg.conf` 09:41:03 My first thought was "network issue?" (e.g. internet is unplugged) 09:41:40 Or can't reach the VuXML server through otherwise-working network 09:42:12 ya, e.g. wonky dns or routing or invalid TLS because wonky clock 09:43:04 I had difficult-to-diagnose problems recently because IXP had broken v6 routing way upstream of me, and nobody else noticed because they all had Happy Eyeballs 2 clients and I had emacs 09:43:18 that'll do it! 09:44:15 me "here's a minimal curl command reproducer" them "we have forwarded this to the email team because your example used imap.gmail.com" >facepalm< 09:44:43 did you ever reach somebody with both clue and power? 09:45:01 not directly but after I stormed out and a couple of weeks, internally it got escalated until it was fixed 09:45:43 I laugh, but it's the pained laughter of someone who, if not has been through the same situation, has seen such things happen. 09:46:13 I'm sorry we live in a world that does this now. 10:22:09 Ellenor, I have an apparently commented line: #VULNXML_SITE = "http://vuxml.freebsd.org/freebsd/vuln.xml.xz"; 10:23:09 painted laughter? 10:23:20 Oh, "pained". 10:23:23 painful. 10:24:15 then it just uses the compiled in default, which is that but with https: instead of http. Does `fetch https://vuxml.freebsd.org/freebsd/vuln.xml.xz` put a vuln.xml.xz file in your working directory or does i tsomehow error? 10:27:11 * ant-x was away looking for a suitalble ajective -- acrimonious. 10:29:14 Ellenor, no: it stall at 0% -- blocked. Perhaps I can work around it using a proxy, but hardly for the scheduled job. Will see. Thanks! 10:30:24 well that's.. not very good. 10:33:04 ant-x: so next step is to isolate the fault 10:33:07 Russian specifics! I can download it from the browser on another machine using FoxyProxy with my proxy, but weirdly not from the FreeBSD machine, using proxychains with exactly the same proxy... 10:35:11 Ellenor, lo and behodl! `proxychains curl ...` has succeeded where `proxychains fetch ...' failed with: 'SSL certificate subject doesn't match host vuxml.freebsd.or" 10:35:52 twb, Stupid silly useless hypocritical unjustified and undeclared blocages of the internet in Russia is the likely cause. 10:36:16 For long time, I have had to invoke pkg install via proxychains, and now this. 10:36:39 does fetch use the same TLS library? 10:36:46 Well that's scary. 10:37:55 Or maybe it's not affected by proxychains for whatever reason? 10:38:10 If you have a local HTTP proxy that goes out through your proxy of choice, you may be able to add a pkg_env http_proxy=[local proxy URL] (according to `man 5 pkg.conf`) 10:38:36 I don't think socks is supported. 10:38:40 "subject doesn't match" usually means either you hit the government's fake landing page (i.e. not proxied) or your TLS library is dumb and doesn't look at the cert's altnames properly 10:43:02 proxychains is a wrapper that does not work with all programs, increasing the need for native SOCKS5-proxy support in individual tools. 10:44:03 twb, I hope it is just that fetch is incompatible with the way proxychains works. 10:44:21 (because curl succeeded.) 10:44:23 Hang on, you actually don't care about fetch, that was only for diagnostics. If you were running pkg behind proxychains before, and it worked, just do so again now? 10:45:43 Would require editing the periodic scripts 10:46:03 Yes, no problem. But this time, it was from some system scheduled (cron-)job that the error came. It was actually mailed to me in regular e-mail, titled: "$HOST daily run output" 10:46:13 Ellenor, indeed. 10:46:47 Or I could check whether 3proxy or some other tool can implenet an HTTP proxy chained to a SOCKS proxy. 10:47:09 i have privoxy on my desktop, but to my ken that's GPL, so not redistributable in conjunction with freebsd. 10:48:06 I am using proxychains, 3proxy, and tor -- all installed from the standard repositories. Not part of the base non-GPL system. 10:50:30 right 10:51:33 Ellenor, thanks for the mention of http_proxy in pkg. I'll see if I can make it. Either 3proxy is complicated or its documentation :-) 10:52:02 It seems to be able to chain proxies of different types, however. 10:53:35 wow I haven't done privoxy since like 2003 10:54:13 I remember we had it set up to do something like --replace SCO=ligitious b*rds 10:54:36 hahha 10:55:13 yeah Privoxy still exists. I mainly use it to unify an i2p and a tor proxy to be able to use them in conjunction. I don't, yet, have to deal with a repressive national internet 10:55:30 (Canada: the government here has been making some very unpleasant noises) 10:57:22 IIRC canada does denylist a small list of human trafficking sites 10:58:24 most defenders of internet freedom shrug at something of that gender 10:58:28 twb, can you please explain the SCO=reference to someone not immersed in whatever culture it belongs to? 10:59:34 Ellenor: yeah just distinguishing between "no denylist" vs "denylist, but not used for evil" 11:00:09 ant-x, Santa Cruz Operation, sued Linux vendors I believe because they thought Linux included proprietary SCO UNIX code 11:01:47 FTR quick fact check at https://en.wikipedia.org/wiki/Censorship_in_Canada#Internet sounds like I mis-remember. It's past my bedtime so not gonna read it all. 11:02:58 twb, you missed you bedtime already, so must wait till the next bedtime. 11:06:22 i wasn't referring to that, but yeah, worrying noises twb 14:20:57 how do pty permissions work? my tty is /dev/pts/0, root:tty with permissions 0640, but i can write to it without being root nor in group tty 14:21:46 Should be same as normal file permissions; if you already got a handle, the permissions don't matter anymore 14:21:56 i can use dd of=/dev/tty, which would reopen 14:22:05 ofc fd 1 is connected already 14:22:44 I just checked; my /dev/pts/X is set to my user:group 14:23:16 /dev/tty should magically alias to your allocated tty 14:24:04 ok, when i use a ssh login it's owned by me 14:24:13 i used su - $USER previously, and it was owned by root 14:24:21 but it still worked, which is surprising to me 14:25:08 I think /dev/tty is doing some kernel magic 14:25:18 Can you check if you can alos open your /dev/pts/X file in that case? 14:25:28 yeah works the same 14:25:40 ok let's read the source then :D 14:26:03 Always a good idea =) 14:27:11 Hmm, I just tried: If I login as that user from ssh directly, I cannot open the root owned pts file. Only if I come from sudo 14:27:38 yeah, it keeps track somehow 14:41:13 so when i come with su, i have getlogin root 14:42:14 not sure that implies any privileges tho 14:51:27 leah2: My guess would be that it is somehow related to the concept of the controlling terminal 14:51:49 The same mechanism that magically maps /dev/tty to the correct pty could also override the permission check 14:57:41 leah2: hc: https://cgit.freebsd.org/src/tree/sys/fs/devfs/devfs_vnops.c#n679 14:58:22 ahh, the controlling terminal. so many moving parts :) 14:58:24 thanks! 15:02:54 (it's actually the session check right after that, but yeah, you get the idea) 15:23:11 yep 16:05:25 Fascinating; good to know that there is still this kind of implicit magic in the kernel %} 16:05:31 I wonder how linux does it these days 16:11:24 hc: linux chowns the tty on su(1) at least, but perhaps that's just virtual too 16:33:41 Tbh this FreeBSD behavior is something that surprises me quite a bit... I'd have expected less magic