[Toybox] protect against sha*sum misconfiguration?

[Rob Landley]

On 8/23/19 10:08 AM, enh wrote:
> On Fri, Aug 23, 2019 at 7:55 AM Rob Landley <rob at landley.net> wrote:
>>
>> On 8/22/19 2:54 PM, enh via Toybox wrote:
>>> i accidentally ended up with a toybox binary that had the sha*sum
>>> binaries enabled, but TOYBOX_LIBCRYPTO disabled. this silently output
>>> md5sums instead. seems like a compile-time error would have been
>>> ideal, and a run-time error still better than just silently doing the
>>> wrong thing.
>>
>> Sigh. My _plan_ was to implement sha*sum in the built-in logic, I just haven't
>> gotten around to it yet. (In the meantime they default "n" like the rest of the
>> pending stuff, but of course you don't use that. :)
> 
> ain't nobody got time for kconfig.

One of my pre-1.0 release items is writing a menuconfig replacement so I can
clean the last of the gplv2 build infratructure out of the tree. :P

(Upstream kernel made kconfig TURING COMPLETE. Why... Ouch. I just want a
menuconfig I can run without multiple files of weirdness...)

>>> runtime's easy enough; something like
>>>
>>>   if (!CFG_TOYBOX_LIBCRYPTO) error_exit("toybox built without libcrypto");
>>>
>>> in sha1sum_main (which implements all the sha*sums). but i feel like a
>>> build-time check would be better, and i'm not sure about the right way
>>> to write that?
>>
>> Well, it already says "depends on TOYBOX_LIBCRYPTO" in the kconfig entries so
>> you shouldn't be _able_ to select it if you've disabled that. (It shouldn't show
>> up in menuconfig, you'd have to hand-edit your config file. Is this a kconfig
>> bug or did you do that?)
> 
> i always do that --- when you have three configs (device, linux, mac)
> to maintain and you're tracking upstream so it's a question of "add
> the newly added thing with a yes or a no" rather than "browse hundreds
> of options like a tourist", manual edits seem like the only sensible
> way to go?

http://landley.net/aboriginal/FAQ.html#dev_miniconfig
https://lwn.net/Articles/161086/
https://lkml.org/lkml/2006/7/6/404
https://github.com/landley/toybox/blob/master/scripts/mkroot.sh#L430

I'm aware that
https://github.com/landley/aboriginal/blob/master/more/miniconfig.sh is slow,
modifying the kernel kconfig plumbing to generate them internally has been on my
todo list since... well since those original kernel threads got enough pushback
and I gave up on trying to merge it upstream.

>> Sigh, what are we up to. Let's check the drinking game page...
>>
>> https://valerieaurora.org/hash.html
>>
>> Looks like sha3 is still current.
> 
> the table at the bottom of https://en.wikipedia.org/wiki/SHA-1 is
> similar. (arm64 has sha3 hardware acceleration, but as long as x86-64
> doesn't, i don't expect to see md5 and sha1 disappear any time soon.)

Neither do I. Heck, rsync was based on md4 until a few years ago.

A bit like git still using sha1sum (https://lwn.net/Articles/715716/
), it didn't really matter because the hash wasn't being used for _security_
exactly, that was just a nice side effect. You do rsync over https (and git over
ssh), and the git devs use signing keys when they care about verifying who did what.

That said, I was reading sha3 reference code with an eye to implementing it in
toybox while waiting to sign house buying paperwork, and that was 2012. (This
whole "dayjob" thing gets in the way of doing real work. Sigh, I meant to be
sneaky and upload my talk outline to https://patreon.com/landley and do my
presentation from that page, and just didn't get around to it...)

Rob