I need to sort out a few more defects but will try both BoringSSL and the FIPS Version of OpenSSL 3.0. In theory both should "just work" with this integration. Albeit with the caveat that FIPS 140-2 verification ended last mouth and I don't believe either BoringSSL or OpenSSL 3 are FIPS 140-3 validated yet.
- Eric On Wed, 20 Oct 2021, 6:51 pm enh, <e...@google.com> wrote: > > > On Wed, Oct 20, 2021 at 10:35 AM Rob Landley <r...@landley.net> wrote: > >> On 10/20/21 11:51 AM, enh wrote: >> > for the ignorant (like me) --- are these libraries like BearSSL an extra >> > abstraction on top of stuff like openssl/boringssl, or are they roughly >> equivalent? >> >> Roughly equivalent. Think openssh vs dropbear. >> >> > (i'm just thinking ahead to what i'd have to do to get toybox wget >> working with >> > boringssl because of FIPS. >> >> ... the federal procurement standard? >> >> (What are they up to now, anyway? My computer history geek side has a >> basic >> familiarity with FIPS 151-2, but I thought it got repealed?) >> > > https://csrc.nist.gov/publications/detail/fips/140/3/final is the > relevant one here. (and, tbh, the only on i've heard of in the last couple > of decades.) > > the TL;DR is that you have to do some [useless] self-check at startup > [because no attacker that can change bits on a read-only partition would be > smart enough to change/disable the self-check too], but you _don't_ have to > use CFI or anything that might actually add some value in this day and age. > and you have to spend time and money to get your implementation certified. > but some buyers care, so some sellers care, and here we are... > > >> > which, yes, makes about as much sense as requiring >> > current vehicles to demonstrate that their hand-cranks are appropriately >> > protected against collisions with horses, but it is what it is, and >> that's a >> > problem to be solved by politicians and lawyers, not us :-( ) >> >> wget is used in a lot of scripted resource fetching*, and these days it's >> near-useless without https. I'm 100% in favor of making this work, but I >> also >> want a minimal built-in version which is nontrivial. (Denys Vlasenko, the >> busybox maintainer I handed off to many moons ago, wrote his own from >> scratch >> over a period of a couple years. Alas he did it as multiple files and >> didn't do >> it in a subdirectory so you can't easily pull up the commit log from the >> web >> repo, but https://git.busybox.net/busybox/log/networking/tls.c gives you >> the >> general idea. To be honest, making puppy eyes at him to use his work >> under 0BSD >> and then cleaning it up to be a proper lib/tls.c that toybox and busybox >> could >> share would be good. Busybox already has ) >> > > does that seem likely? wasn't he the one who moved strace from BSD to GPL > so we never took another update? > > >> I know you won't use the built-in one, but that whole "no external >> dependencies >> in the base" thing comes up.** And if I do a built-in readonly git >> fetcher, that >> also needs https:// to pull repos... >> >> Rob >> >> * wget and curl are semi-interchangeable, but busybox only ever >> implemented >> wget. Curl is more a library for programs to link against, with the >> command line >> utility sort of an afterthought. >> > > yeah, libcurl is used for OTAs, but iirc you need to explicitly build in > external/curl to get a curl binary; it's not available by default. i don't > remember whether there was a good reason for that, given that test > infrastructure people have certainly asked for it. > > >> ** Buncha reasons: defeating trusting trust, being a good self-contained >> educational resources showing all the code needed to do the thing, >> reproducible >> builds, avoiding archival versions being hit by version skew between >> packages or >> website-went-away syndrome... >> >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
