<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 1:45 PM Eric Molitor <<a href="mailto:emolitor@molitor.org">emolitor@molitor.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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. </div></blockquote><div><br></div><div>heh, just to clarify (if it's not already obvious): i don't actually know what i'm talking about here, since i'm only involved with it second or third hand. it's more than likely that i actually meant 140-2, but 140-3 was the newest link a web search offered me when i tried to find a reference for rob :-) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">- Eric</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Oct 2021, 6:51 pm enh, <<a href="mailto:enh@google.com" target="_blank">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 10:35 AM Rob Landley <<a href="mailto:rob@landley.net" rel="noreferrer" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/20/21 11:51 AM, enh wrote:<br>
> for the ignorant (like me) --- are these libraries like BearSSL an extra<br>
> abstraction on top of stuff like openssl/boringssl, or are they roughly equivalent?<br>
<br>
Roughly equivalent. Think openssh vs dropbear.<br>
<br>
> (i'm just thinking ahead to what i'd have to do to get toybox wget working with<br>
> boringssl because of FIPS.<br>
<br>
... the federal procurement standard?<br>
<br>
(What are they up to now, anyway? My computer history geek side has a basic<br>
familiarity with FIPS 151-2, but I thought it got repealed?)<br></blockquote><div><br></div><div><a href="https://csrc.nist.gov/publications/detail/fips/140/3/final" rel="noreferrer" target="_blank">https://csrc.nist.gov/publications/detail/fips/140/3/final</a> is the relevant one here. (and, tbh, the only on i've heard of in the last couple of decades.)<br></div><div><br></div><div>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...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> which, yes, makes about as much sense as requiring<br>
> current vehicles to demonstrate that their hand-cranks are appropriately<br>
> protected against collisions with horses, but it is what it is, and that's a<br>
> problem to be solved by politicians and lawyers, not us :-( )<br>
<br>
wget is used in a lot of scripted resource fetching*, and these days it's<br>
near-useless without https. I'm 100% in favor of making this work, but I also<br>
want a minimal built-in version which is nontrivial. (Denys Vlasenko, the<br>
busybox maintainer I handed off to many moons ago, wrote his own from scratch<br>
over a period of a couple years. Alas he did it as multiple files and didn't do<br>
it in a subdirectory so you can't easily pull up the commit log from the web<br>
repo, but <a href="https://git.busybox.net/busybox/log/networking/tls.c" rel="noreferrer noreferrer" target="_blank">https://git.busybox.net/busybox/log/networking/tls.c</a> gives you the<br>
general idea. To be honest, making puppy eyes at him to use his work under 0BSD<br>
and then cleaning it up to be a proper lib/tls.c that toybox and busybox could<br>
share would be good. Busybox already has )<br></blockquote><div><br></div><div>does that seem likely? wasn't he the one who moved strace from BSD to GPL so we never took another update?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I know you won't use the built-in one, but that whole "no external dependencies<br>
in the base" thing comes up.** And if I do a built-in readonly git fetcher, that<br>
also needs https:// to pull repos...<br>
<br>
Rob<br>
<br>
* wget and curl are semi-interchangeable, but busybox only ever implemented<br>
wget. Curl is more a library for programs to link against, with the command line<br>
utility sort of an afterthought.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
** Buncha reasons: defeating trusting trust, being a good self-contained<br>
educational resources showing all the code needed to do the thing, reproducible<br>
builds, avoiding archival versions being hit by version skew between packages or<br>
website-went-away syndrome...<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>