No worries. I'm still somewhat familiar with BoringSSL from previous Jobs and more wget users means it will be maintained better and biased to be pulled out of pending.
- Eric On Sat, 30 Oct 2021, 1:32 am enh, <[email protected]> wrote: > (sorry for not having time to take a look yesterday, but...) > > yeah, the openssl patch[1] works for me on android with the fips boringssl. > > and, yes, fips definitely still a thing[2], and that's exactly why i'd > need to have a boringssl option even when rob has his stand-alone tls code. > > thanks! (even though i haven't enabled this in the regular build yet, i > assume we'll turn it on some day.) > > ____ > 1. which rob _said_ he'd committed, but i think he forgot to `git push` > --- i applied the patch manually. > 2. despite being comically anachronistic, at least the part i'm familiar > with :-( > > On Fri, Oct 29, 2021 at 11:59 AM Eric Molitor <[email protected]> > wrote: > >> I suspect having basic ssl_init, ssl_read, ssl_write, ssl_close would be >> useful for quite a few use cases. I had thought about that earlier in the >> week but it seemed like something to consider when implementing a second >> use case. >> >> Denny's stuff is interesting, I do prefer Thomas Pornins BearSSL >> implementation but it's an Apples / Oranges comparison. Constant time >> security focused and small vs Denny's make it as small as possible, >> reducing security and validation along the way. But Thomas's development on >> BearSSL has slowed to a crawl since he started developing new crypto >> routines and looking at compression. Even so, BearSSL is still the only TLS >> implementation that I know of (other than maybe WolfSSL) which has >> withstood the various recent timing attacks. >> >> Looking forward to your cleanup. I always learn something when you do so. >> >> - Eric >> >> >> On Fri, 29 Oct 2021, 6:30 pm Rob Landley, <[email protected]> wrote: >> >>> On 10/29/21 7:03 AM, Eric Molitor wrote: >>> > Attached is a reworked patch which adds OpenSSL and BoringSSL support >>> to wget. >>> > It avoids the use of OpenSSL's IO abstractions and uses default >>> settings which >>> > should be sensible on any modern OpenSSL (1.1+) or BoringSSL version. >>> >>> I'm a little uncomfortable having two different sets of code to do the >>> same >>> thing. I suppose they could be moved to portability.[ch]. The "link >>> against both >>> libraries" issue is back, but at least shouldn't conflict... >>> >>> > I tested it with the latest version of BoringSSL but it should also >>> work with >>> > the fips branch of BoringSSL, if that is still a thing at Google. >>> >>> >>> https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips >>> >>> It's still a thing at the US Government, and all their suppliers. (Which >>> is >>> somewhere between 1/4 and 1/3 of the US economy: US GDP is ~$23 trillion >>> and the >>> 2021 estimated federal spending is just under $7 trillion...) >>> >>> > I also tested >>> > it with OpenSSL 1.1.1l on Alpine and 1.1.1f on Ubuntu 20.04 LTS. >>> >>> Sigh. Applied (while grumbling), and I _really_ need to do a cleanup >>> pass this >>> weekend. (And ask Denys if I can get a license to his tls >>> implementation.) >>> >>> > - Eric >>> >>> Rob >>> >> _______________________________________________ >> Toybox mailing list >> [email protected] >> http://lists.landley.net/listinfo.cgi/toybox-landley.net >> >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
