[PATCH 1/2] Allow BusyBox to be built without a list of applet names

[Andreas Oberritter]

On 30.04.2016 09:16, Laurent Bercot wrote:
>>> The lookup hash isn't collision-free: more than one input string
>>> points to the same applet.  Normally invalid applet names might
>>> cause an unexpected one to run
>>
>> And this should be a GoodThing (TM) ?
> 
>  I'm inclined to vote against this change, because even if the risk
> is minimal, and even if hashing has important gains, it's just not worth
> it to change a correct, working mechanism to an incorrect one.
> 
>  Also, "rwok" is a cool name for a command. Somebody should add a "rwok"
> applet.
> 

Even worse, consider a busybox binary that someone expects to contain a
real command like cat or hexdump, which it doesn't. The colliding hash
of this command could map to a command that accepts the same
command-line arguments but destroys data, like mkfs.* or rm.

Still even worse, without the list of applet names included in the
binary, you can't make sure that the applet you're calling actually
exists without dissecting the binary.

Btw., invalid symlinks of e.g. previous installations of busybox might
exist in the filesystem. I've seen that in real products. And I've also
seen scripts call "busybox $cmd" directly many times before.

Regards,
Andreas