On Thu, Nov 19, 2020 at 11:11 PM Shachar Menashe <[email protected]> wrote: > > I agree that replacing busybox wget with another tool to handle HTTPS is a > cleaner solution, I am just a bit worried about backward compatibility...
Breaking backwards compatibility is not generally a big concern for OE so long as any use cases within oe-core and its test suite are updated and continue to work. > If someone used Yocto and relied on HTTPS download functionality (and seeing > there are no other suitable tools such as curl that are already supplied with > Yocto) then we are breaking that use case oe-core provides both curl and wget, so alternatives to Busybox wget are certainly available. > So the question is whether we break compatibility by removing > FEATURE_WGET_HTTPS, or retaining compatibility by including the openssl > binary (or doing nothing and retaining the security issue, which personally I > think is problematic) > > -----Original Message----- > From: Andre McCurdy <[email protected]> > Sent: Thursday, November 19, 2020 9:45 PM > To: Shachar Menashe <[email protected]> > Cc: Randy MacLeod <[email protected]>; [email protected]; Patches > and discussions about the oe-core layer > <[email protected]> > Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin > dependency? > > [External email: Use caution with links and attachments] > > On Wed, Nov 18, 2020 at 10:46 PM Shachar Menashe <[email protected]> wrote: > > > > Hi Andre, > > The way I see it - even if something is declared, it does not mean it > > is reasonable or even expected I mean - do you earnestly believe that every > > Yocto user (or busybox wget user for that matter) read the help text > > associated with the config option that their tool is built with? > > No, but I expect them to notice the "TLS certificate validation not > implemented" warning which Busybox wget outputs. > > > From my perspective, they could not care less, they have the prebuilt > > binary and they just use it and expect it to work, they have no idea what > > config flags were used when building the tool... > > In the year 2020 it is expected that tools that come pre-shipped with > > your OS aren't exposed to naïve attacks such as SSL MitM, that can be > > executed by automated tooling > > Trying to be secure by default is a good argument. The solution is probably > just to disable FEATURE_WGET_HTTPS though. Users who understand the > limitations can enable it manually. Users who want to validate certificates > should be guided towards using curl. Having Busybox wget call out to the > openssl command line tool is certainly a creative solution, but feels too > much like a hack to want to enable by default. > > > I think I can back this up with the fact that busybox maintainers > > chose to integrate our patch that fixes the CVE, and not dismiss it > > > > Note that the GNU version of wget is not exposed to this attack, so > > this furthers the confusion > > > > If there are severe technical issues with shipping the openssl > > executable with Yocto, then we should definitely think about it, but I > > think this endeavor is worthwhile > > > > -----Original Message----- > > From: Andre McCurdy <[email protected]> > > Sent: Thursday, November 19, 2020 3:45 AM > > To: Randy MacLeod <[email protected]> > > Cc: Shachar Menashe <[email protected]>; [email protected]; Patches and > > discussions about the oe-core layer > > <[email protected]> > > Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin > > dependency? > > > > [External email: Use caution with links and attachments] > > > > On Wed, Nov 18, 2020 at 2:30 PM Randy MacLeod <[email protected]> > > wrote: > > > > > > Hi Shachar, > > > > > > On 2020-11-18 1:49 p.m., Shachar Menashe wrote: > > > > About the busybox patch, I realized that Dunfell doesn't come with > > > > the "openssl" binary built-in (only the library) but this fix will > > > > actually requires having the openssl binary (busybox invokes the > > > > openssl binary directly) Do you think it's reasonable to add it? > > > > The library is already getting built, so I don't think it's a huge > > > > deal to add the binary as well > > > > > > Hopefully someone opinionated about busybox will make a suggestion > > > on how to resolve this bug. > > > > The meaning of the busybox FEATURE_WGET_HTTPS configure option is made > > quite clear in the associated help message. Claiming it's a "severe CVE" is > > not correct - it's working as designed. > > > > https://git.busybox.net/busybox/tree/networking/wget.c#n49 > > > > The behaviour may not be suitable for everyone, but it's the default config > > we've used for a long time. Users who need a wget which checks certificates > > should think about installing the full featured version (or try curl if > > wget's GPLv3 license isn't acceptable).
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#144845): https://lists.openembedded.org/g/openembedded-core/message/144845 Mute This Topic: https://lists.openembedded.org/mt/78352776/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
