[Toybox] [PATCH] wget: add TLS support

[enh]

On Wed, Oct 20, 2021 at 1:45 PM Eric Molitor <emolitor at molitor.org> wrote:

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

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


> - Eric
>
> On Wed, 20 Oct 2021, 6:51 pm enh, <enh at google.com> wrote:
>
>>
>>
>> On Wed, Oct 20, 2021 at 10:35 AM Rob Landley <rob at 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...
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20211020/ae7a9aa5/attachment-0001.htm>