[Toybox] [PATCH] toysh: fix -Wuse-after-free > FYI lsb

Sat Mar 23 23:05:25 PDT 2024

On 3/22/24 18:09, scsijon wrote:
> Date: Fri, 22 Mar 2024 08:24:18 -0700
> 
>> From: enh <enh at google.com>
>> To: Rob Landley <rob at landley.net>
>> Cc: Oliver Webb <aquahobbyist at proton.me>, toybox
>> 	<toybox at lists.landley.net>
>> Subject: Re: [Toybox] [PATCH] toysh: fix -Wuse-after-free
>> Message-ID:
>> 	<CAJgzZorSHXVzaoaN1FqjG4_5pupFmVWC4GpVEpwwg2+=gNrVXA at mail.gmail.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Thu, Mar 21, 2024 at 8:45?PM Rob Landley <rob at landley.net> wrote:
>>> On 3/17/24 14:52, Oliver Webb wrote:
>>>> On Thursday, March 14th, 2024 at 12:04, enh <enh at google.com> wrote:
>>>>> at a high level, it does seem like many/most people interpret "pending" as "almost done" (he says, being part of the problem himself, having several pending things building and shipping on all Android devices) whereas in actual fact it can mean anything from "yeah, actually pretty much done" to "will be completely rewritten" via "still just trying random experiments trying to work out _how_ this should be rewritten".
>>>>> sadly i don't have a better suggestion...
>>>> pending/experimental and pending/functional maybe, or something along that gist?
>>> That would be my "not adding more complexity to manage transient clutter that
>>> should instead go away" objection, already made.
>>>
>>>> Then again it'd make it harder to track the history of pending commands, adding only new ones
>>>> to those 2 directories would fix that, but would make the organizational problem for the old
>>>> ones worse.
>>> https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering
>>>
>>> Stop. No. Halt. Wait. Hold it. Woah. Cease. Desist. Caution severe tire damage.
>>> Klatu barata nikto. Subcalifragilisticexpialidocious.
>>>
>>>>> a branch would be the usual git option, but that would probably mean "no pending stuff in the main branch"
>>>> Also a problem if you want to switch Version Control systems or distribute tarballs without a .git/ directory.
>>> I already DID switch version control systems (from mercurial to git), and I
>>> already distribute release tarballs. Why do you think these are new issues?
>>>
>>>> It'd hide these commands too,
>>> I want to close tabs. I am not creating additional scaffolding for clutter
>>> management:
>>>
>>> $ ls -d */toys
>>> clean3/toys  clean8/toys     github/toys  kl4/toys  kl9/toys      toybox/toys
>>> clean5/toys  clean.old/toys  kl10/toys    kl6/toys  kleen/toys
>>> clean6/toys  clean/toys      kl2/toys     kl7/toys  kl/toys
>>> clean7/toys  debian/toys     kl3/toys     kl8/toys  release/toys
>>>
>>> I already try not to publish quite as much clutter as accumulates locally.
>>>
>>> There's some real fossils checked into the tree. I started work on gene2fs back
>>> under busybox, checked in what I had to the toybox repo in 055cfcbe5b05 in 2007
>>> and haven't LOOKED at it this decade because I just haven't gotten back around
>>> to it. Since then they INVENTED EXT4. (I still hope to get back to it, but at
>>> the moment I'm answering email.)
>>>
>>>> For the first time I checked if there were any special branches in the repo because
>>>> I didn't bother to think about that in the months I spent working on it.
>>>>
>>>>> i still struggle between "other" and "lsb" in particular.
>>>> Same here, I can remember the posix commands.
>>> Can you? I still have to check some from time to time, and the definition of
>>> whether "tar" is a posix command or not is outright eldrich bordering on quantum.
>>>
>>>> But I don't care about LSB enough to
>>>> memorize everything in wants. And keeping all completed commands that aren't in poisx,
>>>> lsb, networking or android
>>> The "example" directory is important because it's the only other directory of
>>> commands that should not "default y" in defconfig. It has a policy distinction.
>>>
>>> Back in 2012, when the number of commands was growing fast and having one big
>>> directory of them all was getting a bit busy, the alternative of sorting them
>>> into directories was annotating them with tags, and THAT was a nightmare (of the
>>> "this command has three tags" variety). And also implied future pressure to
>>> extend the existing kconfig implementation to USE the tags, which would be worse.
>>>
>>> Moving them into subdirectories, with each command in ONE directory, and a
>>> README explaining what the directory was for, with kconfig automatically
>>> displaying them in menus and using the first line of the README as the menu's
>>> title, seemed the least bad crowd control option at the time.
>>>
>>>> in a massive "other" folder sorta defeats
>>>> the purpose of these directories which are supposed to reduce clutter.
>>> It wasn't really about reducing clutter. I mean yeas, back then some web viewers
>>> wouldn't display more than 250 files in a directory, the way github truncates at
>>> 1000 today:
>>>
>>> https://github.com/landley/linux/tree/master/arch/arm/boot/dts
>>>
>>> But the goal was annotating command categories. Posix and pending are obvious,
>>> and I mentioned example. Back when I split them up, LSB was still a viable
>>> standard (the Linux Foundation hadn't destroyed it yet), and it STILL kind of
>>> means "this command existed back in Y2K and was considered part of the base
>>> system back then, even if posix never caught up". Several commands in pending
>>> get promoted into LSB (such as most of the password stuff, although oddly
>>> mkpasswd is NOT in lsb 4.1).
>>>
>>> Hmmm, possibly instead of a dead standard the linux foundation killed, I should
>>> instead check the $PATH of my old red hat 9 install from the dawn of time...
>> the BSDs have already done that experiment for us (with bin, sbin,
>> usr.bin, and usr.sbin [and contrib!] directories), and it's also a
>> PITA.
>>
>> "if the new organization _still_ means i need to use find(1) for a
>> command that's default 'y', we haven't made things any better" :-)
>>
>>> Hah, it's still on busybox's website:
>>> https://busybox.net/downloads/qemu/rh-9-shrike.img.bz2 Login as user busybox
>>> password busybox, I believe the root password is also busybox. But that's
>>> post-1.0, I'm not changing horses midstream...
>>>
>>> Anyway, toys/android basically meant (to me), "commands that come from and are
>>> maintained by Elliott which I can't even test because they don't apply to a
>>> vanilla linux system that isn't running the full android environment". Although
>>> that's a personally idiosyncratic definition because I lumped selinux in with
>>> that;
>> (heh. you beat me to it :-) )
>>
>>> the only other environment I've noticed having a big selinux rule stack is
>>> Red Hat. I haven't noticed a lot of selinux in debian, arch, gentoo, alpine,
>>> buildroot... Even SuSE used apparmor instead, although they switched to selinux
>>> recently because their business model is to be the Diet Red Hat so vendors have
>>> a second source to solicit enterprise bids from, so there's business logic to
>>> minimizing the delta between them regardless of technical merit (and spending
>>> less maintaining parallel infrastructure just to sign things in triplicate).
>>>
>>> I admit "toys/net" is a distinction that hasn't really worked out: I didn't even
>>> put nbd_client.c and nbd_server.c in there. I could move all that into other I
>>> suppose, if one less directory was worth making git log history less obvious...
>>>
>>> And then everything that ISN'T in one of those groups needed a place to go,
>>> hence "other". It's not ideal, but it was motivated by the number commands
>>> continuing to increase and One Big Directory getting a bit busy, and needing a
>>> place for "pending".
>> (tbh, just merging "lsb" into "other" would be a step forwards. wtf
>> is/was "lsb" anyway?

https://en.wikipedia.org/wiki/Linux_Standard_Base

>> and while i can _usually_ guess "POSIX or not?"
>> correctly, "lsb or other" is impossible by virtue of being
>> meaningless.)
> 
> The lsb standard stopped being updated in 2015 and current Linux 
> distributions do not adhere to or offer it;

The Linux Standard Base and the Filesystem Hierearchy Standard were the two main
standards put out by the Free Standards Group before the Linux Foundation
consumed it in January 2007:

  https://landley.net/notes-2010.html#18-07-2010

They were attempts to go beyond posix's perpetually stale and incomplete
standards with something that actually documented the reality of Linux. Before
the Linux Foundation destroyed the project, it came out with an updated LSB
version every 3-4 years for the first 4 versions, and they were better than nothing.

LSB 4.0 came out in 2008 (pushing out the work done before the Linux Foundation
could dismantle the hobbyist), and 4.1 in 2011 was a very minor tweak. Those
were the last versions that actually mattered.

LSB 5.0 came out in 2015, eight years after 4.0, and everybody threw up on it.
Debian immediately gave up on them:

  https://lwn.net/Articles/658809/

And everybody else went "yeah, all right" and wandered off because the Linux
Foundation bureaucracy had completely destroyed the distributed volunteer
collaboration that had produced the standard, replacing it with input
exclusively from sponsors who wanted to buy influence.

Toybox says on roadmap.html that we only pay attention to 4.1 not 5.0.

> however, the |lsb_release| 
> command is sometimes still available.

Nah, it was replaced by the /etc/os-release file long ago. All the info
lsb_release -a emitted is just a text file in the /etc directory now, which
makes WAY more sense:

  https://www.linux.org/docs/man5/os-release.html

I have a local patch here adding something to mkroot/mkroot.sh ala:

  echo -e
"NAME=\"mkroot\"\nVERSION=\"$VERSION\"\nHOME_URL=\"https://landley.net/toybox\""
> "$ROOT/etc/os-release"

But haven't checked it in yet because it's a coin toss whether a minimal system
should bother...?

> On February 7, 2023, a former 
> maintainer of the LSB wrote, "The LSB project is essentially abandoned."

Has been for many years, but up until 5.0 came out and Debian set it on fire
people treated the old versions from before the linux foundation as still
reasonable. The toys/lsb directory was created and populated in 2012 right after
4.1 came out.

I already said this repeatedly, but I'm not interested in shuffling stuff around
again before emptying the "pending" directory. Without the need for pending, I
probably don't mind dumping toys/example in with the rest if 'default n' would
uniquely mean what toys/example does now, and I could have "make
posix_defconfig" be a starting config file like macos_defconfig, bsd_defconfig,
and android_defconfig. But while pending remains, that's kinda moot and I don't
want to shuffle everything around more times than necessary.

Also if I needed to teach a new kconfig implementation new tricks, I could do
that with a new kconfig implementation. Not with a gpl codebase I refuse to
modify further even when https://github.com/landley/toybox/pull/332 really wants
me to, and yes that's one of the things pushing that rewrite further up my todo
list...

Rob