[Toybox] protect against sha*sum misconfiguration?

[enh]

On Tue, Aug 27, 2019 at 10:51 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> 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.

aye, but you have code (in ls, iirc) that uses uninitialized memory
but throws the results away, so we have to turn on the config option
to not do that.

> 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