[Toybox] protect against sha*sum misconfiguration?

[Rob Landley]

On 8/27/19 11:25 AM, enh wrote:
> On Tue, Aug 27, 2019 at 8:54 AM Rob Landley <rob at landley.net> wrote:
>>
>> On 8/26/19 12:49 PM, enh wrote:
>>>>> 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...)
>>>
>>> i've never really understood why anyone would want the ui. it feels
>>> strictly worse than just having a text file to edit. all the same
>>> information, but squirreled away behind hundreds of tiny little doors.
>>
>> It's the dependency resolution and contextual help. Can't enable Y without
>> enabling X, it shows you what the prerequisites are in the help text.
>>
>> What would be NICE is a dependency resolver that runs in reverse (I switch this
>> on, switch on the prerequisites) but the problem is there aren't deterministic
>> prerequisites, it can depend on a subset of multiple options.
>>
>> That said: overkill for toybox, which does NOT have a lot of dependencies.
> 
> my understanding is that even where you support the optimized SHA from
> libcrypto or whatever, you always want a fallback portable
> implementation (even if you haven't had time to write it yet), which
> means you should get _something_ in most/all cases anyway.

Yes, but we can handle that with USE() macros and "command isn't available in
this config because I haven't written it yet" is sadly still common. (Working on
it...)

>> (A
>> couple on android, a couple on float, you basically have all of 'em switched on
>> I think.)
> 
> yeah, we're mostly "yes to everything". the "do you have library X?"
> and "do you need to run under asan/hwasan so want to avoid using
> uninitialized memory even if the results are thrown away anyway?"
> switches are the other two that spring to mind.

ASAN's not a switch, it's a CFLAG in your build environment. Although I should
merge your patch to export ASAN=1, I just haven't done it yet because that
logically belongs in configure with the other environment variables. Easy enough
to fix...

Sigh. Moving everything back into one directory's going to screw up "git
annotate" something fierce. I'm reluctant to do it just for that reason. Hmmm.
(Well, --follow is accepted by annotate. I should just mention in the commit "if
you got here, try again with --follow". Didn't stop the kernel guys from moving
all the include files into uapi, and they did THAT in a way that doesn't work
for --follow. Grumble.)

Rob