[Toybox] [PATCH] wget: do not append toybox version at runtime

[Rob Landley]

On 7/5/20 5:31 AM, ariadne at dereferenced.org wrote:
>     I applied the patch, but given the above context, the question "are you
>     actually
>     using these commands on alpine"...?
> 
> We are not yet using toybox.
> 
> It is available in the testing repo, as defconfig.

*nods* Back when I maintained busybox I implemented a rule that defconfig was
the "maximum sane configuration", and toybox works the same way.

> This work is about
> evaluating toybox as a possible eventual replacement to BusyBox down the line,
> but a lot of things will need to happen before we get there I think.  I am not
> opposed to doing those things as I believe toybox is probably more sustainable
> in the long term due to not being a licensing mess.

Cool. I'm happy to help with this.

> For example, several of the applets contain code that, bluntly, I would expect
> either from the demoscene or in an IOCCC entry.

Busybox has applets, toybox has commands. :)

Could you give me specific examples of code you had trouble understanding
please? (From stuff NOT in pending? And I'm aware ps.c is a nest of vipers.)

I keep meaning to do youtube video walkthroughs of each command, but that's
probably a post-1.0 release thing. I've got the two overview videos linked from
the about.html page, but they're mostly "why" rather than "what". Proper "what"
videos would be way shorter and walk through the source on the screen.

  https://landley.net/notes-2017.html#20-09-2017
  https://landley.net/notes-2018.html#01-05-2018

I at least try to be consistent. There's some coding style stuff on the
http://landley.net/toybox/design.html page, and I've explained _some_ of the
infrastructure at http://landley.net/toybox/code.html but there's never enough
documentation and "chocolate sauce is not the answer to bad cooking"...

> While there is something to be
> said about squeezing the maximum possible binary size, I think in 2020
> transparency in implementation is more important, so that we and others can
> effectively audit the code.

I've been explicitly going for auditability, but what counts as readable can
vary between programmers...

> If you agree, I would be happy to refactor some of that stuff.
> 
> In this case, I wanted to evaluate the wget command verses the BusyBox one.  It
> crashed so I sent you a patch fixing it :)

The entire pending directory is a nightmare and promoting code _out_ of pending
requires a long and elaborate auditing and cleanup process, ala:

  https://landley.net/toybox/cleanup.html

>     But the ones android's using are my priority to clean up (and most of them are
>     in better shape with a lot less work required, more auditing than
>     reconstructions).
> 
> readelf is quite problematic actually.  There are numerous warnings generated by
> static analysis of that applet, for example a specially crafted ELF file with a
> 2^33 section size will likely crash your parser.

Elliott Hughes, the Android Base OS maintainer, wrote that. It's in pending
because I haven't done the a full cleanup pass on it, which looks for exactly
that sort of thing.

The _reason_ I haven't done that particular cleanup yet is it's a pain to
dissect things while they're still moving. I actually started readelf cleanup in
February and then stopped again because of conflicting incoming patches:

http://lists.landley.net/pipermail/toybox-landley.net/2020-February/011453.html

Right now I'm trying to write a proper bash replacement shell. (Hence all the
threads on the toybox list with the bash maintainer where I ask him stupid
questions and he tells me I already asked that. Patience of a saint.)

Working on it...

Rob