[Toybox] protect against sha*sum misconfiguration?

[enh]

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.

> (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.

> But it's what a lot of the base OS developers have been used to
> forever. And when I left busybox I'd already made it work there, so had inertia. :)
>
> Rob