01:13:39 <papertigers> jbk: I use the in kernel smb for apple timemachine fwiw.  Although I can't remember why I ended up using samba to share music to my sonos speaker.  I think I couldn't get guest access without a password working 
01:13:46 <papertigers> could have been total user error though
01:34:38 <jbk> yeah.. i have a nas zone on my smartos box that i use for that and it works pretty well..
02:27:52 <sommerfeld> papertigers: well, older sonos can only do SMB1 - maybe that was it?
03:51:38 <NCommander> o/
04:03:42 <jclulow> Hey
04:18:26 <jclulow> NCommander: So, I think you have to run this suite via "gmake test"
04:18:50 <jclulow> There is at least one critical bug if you run it directly, which is that THIS_SH doesn't get set in the environment until after it's used the first time
04:24:41 <jclulow> Some of these failures are just because they are using essentially unstable output of programs like od(1)
04:26:38 <jclulow> e.g., for us: "printf '\n' | od -t a" prints "0000000  lf", but apparently GNU od prints "0000000  nl"
04:52:31 <jbk> how od(d)
04:52:32 <jbk> :P
04:55:05 <jclulow> There are two pieces of delta that don't otherwise seem to be related to the fact that we don't have some of the less common locales: run-test and run-errors.  The run-test thing seems to be a test that's supposed to fail, the "enable sh bash" line
04:55:58 <jclulow> It seems like it happens wth an error message structure it was not necessarily expecting
04:57:07 <jclulow> err rather I guess that's the run-errors thing
05:03:54 <jclulow> I'm not sure about the run-test thing, but it's a bit odd.  It seems like the test expects that "exec 6>&-" will create file descriptor 6, and it wll apparently be a pipe
05:04:09 <jclulow> but ... I don't see that fd open on the process after using that syntax
05:04:19 <jclulow> Some more digging there required probably
05:04:45 <jclulow> NCommander: I don't see any evidence of bash crashing though, FWIW
05:05:03 <jclulow> (this is OmniOS r151046ac)
05:05:12 <NCommander> oh I was trying to figure out what tab this was coming from
05:06:12 <NCommander> jclulow: that might be environment specific
05:06:22 <NCommander> Give me a moment, I forgot I had this open in the background
05:06:28 <jclulow> ok
05:07:29 <sommerfeld> bash manpage: "the redirection operator
05:07:30 <sommerfeld>               [n]>&digit-
05:07:30 <sommerfeld>        moves the file descriptor digit to file descriptor n, or the standard
05:07:30 <sommerfeld>        output (file descriptor 1) if n is not specified.
05:07:30 <sommerfeld> "
05:07:31 <NCommander> I shut down the VM to export it, so I have to boot everything back up
05:07:46 <sommerfeld> so it's some sort of fd juggle
05:08:35 <NCommander> Ah, gmake check does work
05:09:02 <NCommander> And you're right, no core file. I saw the error about the struct issue. Too used to linux just posting something like that and not coring
05:09:41 <NCommander> I have a core dump of bash dying on login. I also have a few litering around.
05:10:12 <jclulow> FWIW, it's the "enable" built-in using dlsym() to look into itself to find "bash_struct" (to do the "enable bash" thing) and not finding it.  It is _expected_ that it doesn't find it, seemingly; I'm not sure what Linux systems do there.  It's totally possible the Mac OS X equivalent doesn't use dlsym() but something else.
05:10:19 <jclulow> Given they're Mach-O instead of ELF
05:10:57 <jclulow> So that error pops out there because they print it, in the code in "builtins/enable.def"
05:11:20 <jclulow> I think this test suite is actually in pretty good shape FWIW
05:11:39 <NCommander> https://gist.github.com/NCommander/ad6684898f400c2611bfb19dc3a7470e - yeah its less broken with gmake
05:11:42 <jclulow> If you run it with the GNU stuff in PATH first, it finds the GNU od and stops whinging about that stuff; e.g., PATH=/usr/gnu/bin:$PATH gmake test
05:11:44 <NCommander> I legitimately forgot about that
05:12:09 <jclulow> The locale stuff is probably because that locale is missing
05:12:22 <NCommander> Well on Mastodon, the locale got brought up as a suspected cause
05:12:37 <NCommander> I just noted they're not installed, since perl was complaining about it when I was trying to build arm64-gate
05:12:38 <jclulow> Yeah I made that suggestion wrt. the segfault/core file stuff
05:13:11 <NCommander> I am uploading the VHDs to Google right now, but they're 72 GiB
05:13:18 <NCommander> So its taking awhile
05:13:27 <jclulow> But because you're ostensibly using en_US.UTF-8 and a stock install, I am less sure it's locale related haha
05:13:48 <NCommander> I've crawled around in bash's internals before
05:13:57 <jclulow> It is not my favourite neighbourhood
05:14:06 <NCommander> (I dunno if you've seen my YouTube channel, I had an adventure with it on AIX)
05:14:13 <jclulow> I have not!
05:14:29 <NCommander> the long story short: old AIX defines strtoimax, but doesn't include it in the headers. It's also buggy
05:14:41 <NCommander> This does *really fun things*, cause a configure check in bash was broken and uh
05:15:12 <NCommander> well needless to say I filed a few bugs on the matter :)
05:15:19 <jclulow> neat
05:15:28 <jclulow> bugs filed is always good haha
05:15:59 <NCommander> Yeah, this is actually me following up on trying to build illumos for arm64, which is largely how I got here.
05:17:45 <NCommander> The stack traceback to me tells me its dying somewhere in readline
05:18:02 <NCommander> Bash has its own built in version that it uses if the system one isn't present, but I think its linked to readline
05:19:10 <jclulow> presumably "ldd /usr/bin/bash" includes /usr/lib/64/libreadline.so.8 in there
05:19:38 <NCommander>         libreadline.so.8 =>      /usr/lib/64/libreadline.so.8
05:19:42 <jclulow> yeah
05:19:42 <NCommander> We have ourselves a winner
05:21:09 <NCommander> Readline doesn't have a test suite :/
05:21:25 <jclulow> If you "pargs -e <corefile>" can you gist the result
05:21:26 <NCommander> Although there are some compiler warnings
05:22:05 <NCommander> https://gist.github.com/NCommander/7ce54489f9dc26f3541fbc0a4f7d93f6
05:22:24 <jclulow> ok
05:22:30 <jclulow> LC_CTYPE=UTF-8 is probably the issue
05:23:09 <NCommander> ncmdr@rosetta2:~/bash-5.2.21$ cat configure.log | grep -i nls
05:23:10 <NCommander> checking whether NLS is requested... yes
05:23:10 <NCommander> checking whether to use NLS... yes
05:23:17 <NCommander> The crash is in readline though
05:23:28 <NCommander> Hold on, let me make a new account which has bash as its shell
05:23:31 <NCommander> so I can test different scenarios
05:24:09 <jclulow> OK I can reproduce it
05:24:21 <jclulow> with... LC_CTYPE=UTF-8 /usr/bin/bash
05:25:00 <jclulow> It is somewhat unconscionable that it handles SIGSEGV haha
05:25:06 <NCommander> ncmdr@rosetta2:~/bash-5.2.21$ LC_CTYPE=UTF-8 /usr/bin/bash -c 'echo HERE'
05:25:07 <NCommander> UTF-8: unknown locale
05:25:07 <NCommander> HERE
05:25:08 <NCommander> ncmdr@rosetta2:~/bash-5.2.21$
05:25:23 <NCommander> It's not crashing here
05:25:43 <jclulow> you're not doing the same thing I was doing
05:25:50 <jclulow> It also does not crash if I pass it a -c argument
05:26:00 <jclulow> with no arguments, it attempts to start an interactive shell
05:26:04 <jclulow> which is when readline comes in
05:26:19 <NCommander> that also worked
05:26:23 <NCommander> I tried that first
05:28:09 <NCommander> Well I can't reproduce the SSH login crash now. I don't think I saved a snapshot before upgrading
05:28:50 <jclulow> what do you get if you: pkg info readline | grep FMRI
05:30:48 <NCommander> on bloody?
05:30:50 <NCommander> er
05:30:51 <NCommander> sorry
05:31:08 <NCommander> ncmdr@rosetta2:~$ pkg info readline | grep FMRI
05:31:08 <NCommander>              FMRI: pkg://omnios/library/readline⊙8:20240402T110232Z
05:31:28 <jclulow> ok and that's ... bloody or stable or?
05:31:59 <NCommander> bloody
05:32:08 <NCommander> ncmdr@rosetta2:~$ uname -a
05:32:08 <NCommander> SunOS rosetta2 5.11 omnios-master-b797611cbb i86pc i386 i86pc
05:32:09 <NCommander> ncmdr@rosetta2:~$
05:32:21 <jclulow> ok tah
05:32:51 <NCommander> The core file for me was generated by selecting /usr/bin/bash as the shell on the OmniOS installer
05:33:05 <NCommander> I could log in ont he system console, but it dumped when I logged into SSH until I changed it to ksh93
05:33:30 <jclulow> https://gist.github.com/jclulow/3cc98adaa23ccbc3b7227db5f318331b
05:33:47 <jclulow> this is the stack at the point of the actual SIGSEGV
05:33:55 <jclulow> It has, I believe, passed NULL to strlen()
05:34:07 <jclulow> from _rl_init_eightbit()
05:35:32 <NCommander> I'm going through the code
05:35:38 <NCommander> to see if I can figure out where it blows its brains out
05:35:53 <jclulow> it is in _rl_init_locale()
05:36:04 <jclulow> it is explicitly looking at LC_CTYPE haha
05:36:43 <NCommander> well there's a big giant #if here that relates to a configure check
05:36:53 <NCommander> (looking at readline-8.2 source code)
05:37:14 <jclulow> I believe the #if is true
05:37:27 <NCommander> it is
05:37:34 <jclulow> because "_rl_init_locale::dis ! grep call" in the debugger lists some <PLT=libc.so.1`setlocale> calls
05:38:40 <jclulow> I...
05:38:43 <NCommander> Well, this is where it jumps into the C library
05:38:52 <jclulow> am not sure you are allowed to pass NULL to setlocale() like that?!
05:39:25 <jclulow> oh I guess maybe you are
05:39:41 <NCommander> Well in the case on Linux where locales won't be installed, I think it would go down that codebranch.
05:39:53 <NCommander> It could be a regression in libreadline ...
05:42:32 <NCommander> https://git.savannah.gnu.org/cgit/readline.git/log/nls.c
05:42:35 <NCommander> I'm looking at it in git
05:42:42 <NCommander> This function hasn't changed in like 10 years.
05:46:22 <jclulow> ok so we get "UTF-8" back from the environment lookup
05:46:34 <jclulow> so we are in fact passing it straight to setlocale()
05:47:04 <NCommander> This sounds like the C library is choking
05:47:20 <NCommander> Wasn't NLS one of the bits that was closed source from Sun and had to be replaced?
05:47:35 <jclulow> The i18n stuff
05:47:37 <jclulow> was
05:49:03 <NCommander> ls
05:49:10 <NCommander> this is not my terminal
05:49:18 <jclulow> accurate
05:51:55 <NCommander> I'm trying to find where the other side of that function call goes
05:53:01 <NCommander> https://github.com/illumos/illumos-gate/blob/d363b1b0cb9ef6d6f3febdd8d1cba46507e97098/usr/src/lib/libc/port/locale/setlocale.c#L68
05:54:32 <jclulow> yes I am single stepping through
05:57:18 <jclulow> ok so newlocale() in there returns NULL ultimately
05:57:21 <jclulow> because we parsed it rubbish
05:57:25 <jclulow> *passed
05:57:43 <jclulow> we are back in _rl_init_locale()
05:58:32 <jclulow> yeah it passes NULL to strlen() itself
05:59:03 <jclulow> It's in savestring()
05:59:09 <jclulow> in readline-8.2
05:59:25 <jclulow> It seems to have been inlined (blah)
05:59:40 <jclulow> but at the point where it calls strlen() it is about to pass the result to xmalloc()
05:59:46 <jclulow> which is what their savestring() does
06:00:30 <NCommander> So is the bug that readline passes in NULL or illumos's libc not being happy with that NULL? Cause this all looks like old code
06:01:03 <jclulow> The bug is that in the event that a rubbish locale is passed to setlocale(), setlocale() returns NULL because, well, it failed to set the locale 
06:01:06 <jclulow> and then
06:01:27 <jclulow> readline does the wrong thing
06:01:28 <NCommander> wait
06:01:31 <jclulow> by assuming it won't be NULL
06:01:37 <NCommander> the manpage actually defines behavior for nullpointer
06:01:48 <NCommander>        A null pointer for locale causes setlocale() to return a pointer to the
06:01:48 <NCommander>        string associated with the category for the program's current locale.
06:01:49 <jclulow> We're not passing in NULL, we're _returning_ NULL
06:01:49 <NCommander>        The program's locale is not changed.
06:01:52 <NCommander> Oh
06:02:01 <jclulow> we pass in what you set in your environment for LC_CTYPE
06:02:08 <jclulow> i.e., "UTF-8"
06:02:10 <jclulow> which is not a locale
06:03:26 <NCommander> oh hold on
06:03:35 <NCommander> I think I see what happens on Linux
06:03:37 <jclulow> "LC_CTYPE=mr_stephens bash" also fails FWIW
06:03:48 <NCommander> I think on Linux, this would return 'C'
06:04:12 <jclulow> I suspect it depends on your C library, but that may well be true
06:05:07 <jbk> at least some linux manpage suggests it could return NULL as well
06:05:15 <NCommander> mcasadevall@lighthouse:~$ ./test_setlocale
06:05:16 <NCommander> setlocale returned: C
06:05:38 <NCommander>   printf("setlocale returned: %s\n", setlocale(LC_CTYPE, NULL));
06:05:38 <jclulow> It can definitely return NULL
06:05:48 <jclulow> well to be clear
06:05:57 <jclulow> setlocale(LC_CTYPE, "mrstephens")
06:06:00 <jclulow> not NULLL
06:06:12 <NCommander> macOS also returns 'C'
06:07:57 <jclulow> linux actually returns NULL
06:08:08 <NCommander> ?
06:08:13 <jclulow> if all you call is setlocale(LC_CTYPE, "mr_stephens");
06:09:31 <jclulow> at least that's true on Ubuntu 22.04.3 LTS
06:09:45 <jclulow> so glibc, really, rather than Linux
06:10:12 <NCommander> yeah my test case was wrong, sorryh, its late here
06:10:37 <jclulow> I believe Mac OS X also returns NULL there
06:11:23 <jclulow> It does seem like /bin/bash on Ubuntu, at least, does _not_ link against libreadline
06:11:29 <jclulow> at least not dynamically
06:11:34 <jclulow> maybe the internal readline is less ruinous
06:11:38 <NCommander> It's likely using the built in one, bash can be set to /bin/sh
06:11:50 <NCommander> And there are some special considerations for /bin/sh and dpkg
06:11:56 <jclulow> sure
06:12:04 <jclulow> So I guess that's why it's not broken there haha
06:12:33 <NCommander> It's also possible that no one has actually run glibc with an entirely invalid lang environment. That code is pretty much older than dirt.
06:12:33 <jclulow> I can't really see how this would not segfault in the same way if you built it linked against the real libreadline -- unless of course they've patched _that_ in Ubuntu
06:12:58 <NCommander> like if you don't have the environmental variables sent
06:13:02 <jclulow> Do you know how LC_CTYPE is getting into your environment?
06:13:03 <NCommander> it sends NULL into setlocale()
06:13:35 <NCommander> As in my SSH shell or on illumos?
06:13:42 <jclulow> on your illumos system yeah
06:14:03 <NCommander> declare -x LANG="en_US.UTF-8"
06:14:17 <NCommander> I am not sure if its getting that from ssh or not
06:14:25 <NCommander> Hold on, let me check locale if I log on the system terminal
06:14:41 <jclulow> we're specifically looking for, like, env | grep LC_CTYPE
06:15:04 <NCommander> Its not set, but its also not crashing now ...
06:15:04 <NCommander> wait
06:15:06 <NCommander> hold on
06:15:18 <NCommander> LC_CTYPE=UTF-8
06:15:25 <jclulow> j'accuse!
06:15:28 <NCommander> I was using cool-retro-term because I was making a video
06:15:34 <jclulow> ah ha
06:15:37 <NCommander> The standard macOS Terminal.app doesn't cause it
06:15:41 <NCommander> but I wanted the fancy graphics
06:15:41 <jclulow> fascinating
06:15:56 <jclulow> I wonder why it does that!
06:16:27 <NCommander> mcasadevall@infinityway ~ % ssh ncmdr⊙110
06:16:27 <NCommander> (ncmdr⊙110) Password:
06:16:28 <NCommander> Last login: Thu Apr  4 05:46:02 2024 from 192.168.2.215
06:16:28 <NCommander> OmniOS r151049  omnios-master-b797611cbb        April 2024
06:16:29 <NCommander> You have new mail.
06:16:29 <NCommander> Connection to 192.168.0.102 closed.
06:16:30 <NCommander> mcasadevall@infinityway ~ %
06:16:33 <NCommander> And that infact reproduces the crash
06:17:02 <NCommander> I just checked for good measure and I can ssh into Linux VMs just fine
06:17:03 <NCommander> so uh
06:18:01 <jclulow> You should definitely fix the LC_CTYPE value that cool-retro-term is setting there, I don't believe that's ever valid
06:18:11 <NCommander> I didn't even notice it was broken
06:18:17 <NCommander> cause this was the first time I saw it go kaboom
06:18:28 <jclulow> Well most software probably correctly handles a return of NULL from setlocale() haha
06:18:31 <NCommander> except its a valid locale
06:18:33 <NCommander> C.UTF_8
06:18:43 <NCommander> I believe that would match through locale rules
06:19:14 <jclulow> LC_CTYPE=UTF-8 locale on Ubuntu complains loudly
06:19:50 <NCommander> hold on
06:19:53 <NCommander> I need to figure out what's doing
06:20:02 <NCommander> my locale when logging into Ubuntu over SSH is being set to C.UTF-8
06:20:08 <NCommander> Instead of what its coming in on SSH
06:21:39 <NCommander> so if I login over SSH with an invalid locale, it gets set to C.UTF-8
06:21:48 <NCommander> If I log in with an invalid locale to OmniOS
06:21:50 <NCommander> LC_CTYPE=abcdefg
06:22:28 <jclulow> good lord, /etc/profile.d/01-locale-fix.sh
06:23:21 <jclulow> Yeah ok so they've invented some training wheels in /usr/bin/locale-check haha
06:23:30 <jclulow> if you..  LC_CTYPE=frank /usr/bin/locale-check C.UTF-8
06:23:44 <jclulow> it emits LANG=C.UTF-8 LC_CTYPE=C.UTF-8
06:23:50 <NCommander> Why do I feel like this bug was found a decade ago and this was the fix?
06:24:11 <jclulow> I mean, it is on some level true that not having your locale set properly is bad
06:24:19 <jclulow> but it is also true that it should probably _tell you_
06:24:34 <jclulow> because how would you ever know that your terminal is setting it to something that is totally bogus
06:24:50 <jclulow> cool-retro-term should be passing C.UTF-8 there if that's what wants
06:24:54 <jclulow> or tbh not changing it at all?
06:24:57 <NCommander> I'm pretty sure we are all intended to be coding on VT100's in a dark room ;)
06:25:04 <jclulow> haha
06:25:24 <jclulow> I do recall using Cathode.app a million years ago, before I gave up on the Mac
06:26:03 <NCommander> So the question is what is the actual and proper fix?
06:26:25 <NCommander> I guess patching readline to be less stupid and hope upstream takes it
06:27:00 <jclulow> Yes I believe it is a readline bug
06:27:20 <jclulow> https://github.com/TritonDataCenter/node-manta/issues/61#issuecomment-19653740 is the only evidence I can recall of my Cathode.app use lol
06:28:21 <jclulow> It's possible we could consider sanitising user locale stuff too, though that really feels like a perilous ptah
06:28:23 <jclulow> *path
06:28:32 <jclulow> I'm sure we'll break _other_ things doing stuff like that
06:29:50 <NCommander> Well, hold on, would you? Applications should be expected not to crash if there's a valid locale, and making sure the environment has a safeguard incase of bad terminals is not necessarily a bad thing
06:30:20 <jclulow> It's just a big hammer
06:30:21 <NCommander> Essentially, this is more making getty (or whatever the equivelent is) basically sanity check what comes in, and screech loudly if it dislikes it.
06:30:46 <jclulow> Well, getty/ssh don't care
06:31:05 <jclulow> most programs correctly handle rubbish in the locale variables FWIW
06:31:14 <jclulow> it's why you got all those messages about it haha
06:31:23 <jclulow> It was in fact crying out in pain
06:31:50 <NCommander> I got desensitized to it because debootstrapped Ubuntu doesn't install locales so Perl screaming is normal.
06:31:52 <NCommander> >.>;
06:31:55 <jclulow> I am surprised that this "locale-check" program doesn't warn people about it
06:32:02 <NCommander> I didn't even know it existed
06:32:07 <jclulow> Me neither!
06:32:20 <jclulow> It of course has no manual page despite being in /usr/bin
06:32:35 <NCommander> hold on, I can find who owns it
06:33:09 <NCommander> mcasadevall@lighthouse:~$ dpkg-query -S /etc/profile.d/01-locale-fix.sh
06:33:10 <NCommander> base-files: /etc/profile.d/01-locale-fix.sh
06:33:12 <jclulow> lol, "locale-check --help" silently exits 0
06:33:40 <jclulow> is "base-files" the package?
06:34:21 <NCommander> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1134036
06:35:57 <jclulow> "I'm not a big fan of this approach but I certainly don't have any better idea myself."
06:36:18 <NCommander> Well they were having postgres explode
06:36:21 <NCommander> ... which uses libreadline
06:36:39 <NCommander> Well I found the common thread here :P
06:36:59 <jclulow> lol
06:37:01 <jclulow> indeed
06:37:12 <NCommander> So I can actually provide some context
06:37:17 <NCommander> because I worked on MaaS, albiet loosely
06:37:32 <NCommander> They were basically deploying absolutely minimium images without locales for bare metal VM hosting
06:37:44 <jclulow> https://git.launchpad.net/ubuntu/+source/base-files/tree/locale-check.c
06:38:28 <NCommander> This is a deeply magical behavior
06:38:47 <jclulow> it truly is
06:38:58 <jclulow> That's what I mean by peril haha
06:39:08 <jclulow> Like, people will set their locales like your terminal did
06:39:14 <jclulow> and never know they were not getting what they asked for
06:39:26 <jclulow> and stuff will just magically work except sometimes when it doesn't
06:39:40 <jclulow> It really feels like this thing should emit a WARNING to stderr
06:40:05 <NCommander> Arguably, OpenSSH should be sanitizing what its setting the environemnt to
06:40:16 <NCommander> Because its entirely valid that you will have a locale on system A that doesn't exist on system B
06:40:29 <jclulow> Well I believe SunSSH used to actually do thta
06:40:31 <jclulow> *thta
06:40:34 <jclulow> sigh *that
06:40:35 <NCommander> And that formatting doesn't necessarily need to be the same across operating systems
06:40:42 <jclulow> it would negotiate the locale
06:40:54 <jclulow> but we dropped SunSSH (a fork of OpenSSH) long ago
06:41:03 <jclulow> and the OpenSSH people are not into complex stuff like that
06:41:09 <NCommander> yeah I'm not surprised
06:41:29 <NCommander> The ubuntu-devel discussion seems to conclude that openssh is doing the wrong thing
06:41:45 <jclulow> We have our OpenSSH built to AcceptEnv the LC_* LANG stuff by default, as is the broad custom
06:41:54 <jclulow> and then it's just up to users to hold it properly basically
06:42:30 <NCommander> The question becomes is it realistic that OpenSSH will get a locale that's valid on linux/mac/windows, but not valid on illumos, and what the correct behjavior is in that case
06:42:44 <jclulow> It's unfortunately not really possible to say
06:43:17 <jclulow> If you don't follow the spec, and you don't specify a locale that works on the remote system, the best anyone can really do is guess
06:43:26 <jclulow> maybe C, maybe C.UTF-8 if we thought you wanted UTF-8
06:43:43 <jclulow> also what if you specify a correct LANG but a bung LC_COLLATE
06:43:51 <jclulow> It is ultimately a mess haha
06:44:03 <NCommander> Is there an actual defined spec for locales?
06:44:32 <jclulow> I feel like some of it is covered in the various standards yes
06:44:35 <jclulow> between C and POSIX
06:45:41 <jclulow> e.g., https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
06:46:03 <jclulow> which of course doesn't cover UTF-8 haha
06:46:57 <jclulow> I think C.UTF-8 is actually probably a made up debian thing
06:47:02 <jclulow> that we've mostly all subsequently adopted
06:47:52 <NCommander> The category body shall consist of one or more lines of text. Each line shall contain an identifier, optionally followed by one or more operands. Identifiers shall be either keywords, identifying a particular locale element, or collating elements. In addition to the keywords defined in this volume of POSIX.1-2017, the source can contain
06:47:52 <NCommander> implementation-defined keywords
06:47:54 <jclulow> https://www.illumos.org/issues/11661
06:47:55 <fenix> → BUG 11661: provide C.UTF-8 locale (Closed)
06:48:15 <NCommander> So there's no defined format
06:48:19 <NCommander> for locale names
06:48:38 <NCommander> Or well, there's nothing saying I can't make my own locale of LANG="pirate_ARGGGG", and be against spec
06:49:07 <NCommander> and then ssh into a normal illumos system from my pirate speaking wonderland
06:49:12 <jclulow> I think that's basically true haha
06:49:29 <jclulow> But I'm not an expert in this area
06:49:39 <NCommander> Neither am I
06:50:01 <jclulow> At any rate, I will file an OmniOS bug describing the readline bug
06:50:09 <jclulow> And we can figure out what to do next
06:50:10 <NCommander> This is getting fairly close the eldritch tomes of lore that AT&T used to forge the One Ring deep in the heart of Murry Hill
06:51:10 <NCommander> I guess fix the readline bug, and see if upstream accepts it, and then deciding if illumos needs to have a locale wrapper, since readline is probably one of the most deployed codebases on the planet
06:54:39 <NCommander> make sure to shoot me the link to that bug, since I'll weigh in. If nothing else, making a video on describing how a bug in libreadline was found will be interesting
06:58:56 <NCommander> I just had a stupid thought
06:59:10 <NCommander> is there any way this can be exploited for code execution? This is a variable a user controls.
06:59:58 <NCommander> I'm not sure it actually gets you anything, but crashing on bad environment data in a library as well used as readline makes me twitchy
07:03:06 <NCommander> no wait, the bad data causes NULL to strlen, nothing a user writes to
07:03:11 <NCommander> ugh, I need sleep
07:08:40 <jclulow> NCommander: https://github.com/omniosorg/omnios-build/issues/3537
07:08:42 <jclulow> I filed the bug
09:37:47 <jimklimov> cheers, got a question about NWAM which manages my OI VM's networking: sometimes the home DHCP server from the access point goes AWOL, and the OI VM loses networking (probably lease expires?) -- is it possible to tell it to use the last served address indefinitely until told otherwise? Or a specific fallback IP?
09:41:28 <nikolam> if LAn have multiple gateways, how to tell illumos to always use first gateway (and DNS server) and then if it fails the other one(s). 
09:42:08 <nikolam> I see it alternating between gateways to access outside world, even if explicitly set what gateway and DNS to use. (SmartOS) 
15:13:13 <danmcd> Silly question... *our* ldd(1) doesn't execute the binary at all while trying to find paths, right?
15:13:15 <danmcd> https://jmmv.dev/2023/07/ldd-untrusted-binaries.html
15:15:13 <danmcd> I'm also pretty sure our strings(1) isn't as dangerous as the binutils one used to be...
15:15:18 <danmcd> https://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-untrusted-files.html
15:41:27 <sommerfeld> our ldd most certainly exec's the binary after setting a bunch of environment variables that cause ld.so to dump its guts rather than run the program.
15:42:28 <sommerfeld> our ldd does check that the ELF interpreter is in a plausible location (in /lib, /usr/lib, or /etc/lib) which reduces but doesn't eliminate the chance of mischief
16:19:27 <rmustacc> strings should probably dumps privs.
16:19:34 <rmustacc> s/dumps/drop
16:50:46 <alanc> danmcd: sorry to disappoint you: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/sgs/ldd/common/ldd.c#L36-L39
17:57:17 <danmcd> Oh damn...
17:57:48 <danmcd> Well, glad I asked?
21:04:05 <gitomat> [illumos-gate] 16413 Post-barrier Return Stack Buffer (PBRSB) fixes can be detected in HW -- Dan McDonald <danmcd⊙mi>