[Toybox] protect against sha*sum misconfiguration?

[enh]

On Fri, Aug 23, 2019 at 8:54 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> 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...)

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.

anyway, patch sent.

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