kevans: Thanks for the info. I'll look into that.

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"?

"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)

twb: OpenBSD tar is the same binary as for cpio and pax so your assumption is wrong from the outset.

Fair enough

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

I think they have to be cated before compression

date >x; (bsdtar cz x; bsdtar cz x) | bsdtar t --options read_concatenated_archives ==> x

date >x; (bsdtar c x; bsdtar c x) | gzip | bsdtar t --options read_concatenated_archives ==> x x

the linux initrd stuff is typically like "cat microcode.cpio firmware.cpio.gz rootfs.cpio.zst" so not even consistently compressed

Hello, all. My FreeBSD box has sent me this e-mail today <paste.c-net.org/EnforcerShocking>, 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?

this is a far shout: what do you have for `grep VULNX /usr/local/etc/pkg.conf`

My first thought was "network issue?" (e.g. internet is unplugged)

Or can't reach the VuXML server through otherwise-working network

ya, e.g. wonky dns or routing or invalid TLS because wonky clock

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

that'll do it!

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<

did you ever reach somebody with both clue and power?

not directly but after I stormed out and a couple of weeks, internally it got escalated until it was fixed

I laugh, but it's the pained laughter of someone who, if not has been through the same situation, has seen such things happen.

I'm sorry we live in a world that does this now.

Ellenor, I have an apparently commented line: #VULNXML_SITE = "vuxml.freebsd.org/freebsd/vuln.xml.xz";

painted laughter?

Oh, "pained".

painful.

then it just uses the compiled in default, which is that but with https: instead of http. Does `fetch vuxml.freebsd.org/freebsd/vuln.xml.xz` put a vuln.xml.xz file in your working directory or does i tsomehow error?

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!

well that's.. not very good.

ant-x: so next step is to isolate the fault

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...

Ellenor, lo and behodl! `proxychains curl ...` has succeeded where `proxychains fetch ...' failed with: 'SSL certificate subject doesn't match host vuxml.freebsd.or"

twb, Stupid silly useless hypocritical unjustified and undeclared blocages of the internet in Russia is the likely cause.

For long time, I have had to invoke pkg install via proxychains, and now this.

does fetch use the same TLS library?

Well that's scary.

Or maybe it's not affected by proxychains for whatever reason?

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`)

I don't think socks is supported.

"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

proxychains is a wrapper that does not work with all programs, increasing the need for native SOCKS5-proxy support in individual tools.

twb, I hope it is just that fetch is incompatible with the way proxychains works.

(because curl succeeded.)

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?

Would require editing the periodic scripts

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"

Ellenor, indeed.

Or I could check whether 3proxy or some other tool can implenet an HTTP proxy chained to a SOCKS proxy.

i have privoxy on my desktop, but to my ken that's GPL, so not redistributable in conjunction with freebsd.

I am using proxychains, 3proxy, and tor -- all installed from the standard repositories. Not part of the base non-GPL system.

right

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 :-)

It seems to be able to chain proxies of different types, however.

wow I haven't done privoxy since like 2003

I remember we had it set up to do something like --replace SCO=<blink>ligitious b*rds</blink>

hahha

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

(Canada: the government here has been making some very unpleasant noises)

IIRC canada does denylist a small list of human trafficking sites

most defenders of internet freedom shrug at something of that gender

twb, can you please explain the SCO=reference to someone not immersed in whatever culture it belongs to?

Ellenor: yeah just distinguishing between "no denylist" vs "denylist, but not used for evil"

ant-x, Santa Cruz Operation, sued Linux vendors I believe because they thought Linux included proprietary SCO UNIX code

FTR quick fact check at en.wikipedia.org/wiki/Censorship_in_Canada#Internet sounds like I mis-remember. It's past my bedtime so not gonna read it all.

twb, you missed you bedtime already, so must wait till the next bedtime.

i wasn't referring to that, but yeah, worrying noises twb

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

Should be same as normal file permissions; if you already got a handle, the permissions don't matter anymore

i can use dd of=/dev/tty, which would reopen

ofc fd 1 is connected already

I just checked; my /dev/pts/X is set to my user:group

/dev/tty should magically alias to your allocated tty

ok, when i use a ssh login it's owned by me

i used su - $USER previously, and it was owned by root

but it still worked, which is surprising to me

I think /dev/tty is doing some kernel magic

Can you check if you can alos open your /dev/pts/X file in that case?

yeah works the same

ok let's read the source then :D

Always a good idea =)

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

yeah, it keeps track somehow

so when i come with su, i have getlogin root

not sure that implies any privileges tho

leah2: My guess would be that it is somehow related to the concept of the controlling terminal

The same mechanism that magically maps /dev/tty to the correct pty could also override the permission check

leah2: hc: cgit.freebsd.org/src/tree/sys/fs/devfs/devfs_vnops.c#n679

ahh, the controlling terminal. so many moving parts :)

thanks!

(it's actually the session check right after that, but yeah, you get the idea)

yep

Fascinating; good to know that there is still this kind of implicit magic in the kernel %}

I wonder how linux does it these days

hc: linux chowns the tty on su(1) at least, but perhaps that's just virtual too

Tbh this FreeBSD behavior is something that surprises me quite a bit... I'd have expected less magic