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

[Tito]

On 04/30/2016 02:58 PM, Jody Lee Bruchon wrote:
> On April 30, 2016 8:39:24 AM EDT, Andreas Oberritter <obi at opendreambox.org> wrote:
>> 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.
>
> This problem can be avoided at compile time by hashing all possible applet names in BusyBox and checking for collisions.

Hi,
is it possible at compile time also to check for every arbitrary string 
the user could throw at busybox?

Ciao,
Tito

> I question whether all the extra machinery is worth it in any case.