On 8/23/17 5:44 AM, Richard Purdie wrote: > On Wed, 2017-08-23 at 14:07 +0200, Andrej Valek wrote: >> I have found out that even master with HOSTTOOLS does not fix my >> problem. >> We use ASSUME_PROVIDED for ca-certificates-native due to corporate >> environment CAs. >> Since nativesdk-ca-certificates depends on ca-certificates-native >> whichis not built, so it could not be found. Unfortunately adding >> update-ca-certificates to HOSTTOOLS is not working, since build user >> does not have permissions to modify system CAs and also is in >> /usr/sbin/ which is not in usual system path. >> >> Therefore I think that this patch applies for master branch, too. >> Possible improvement would be also removing ca-certificates-native >> from DEPENDS of class-nativesdk. >> >> Solution of installing corporate CAs within OE recipe does not seem >> to be ideal, because the CAs have short expiration date. So using >> system CAs assures reachability of resources over https. >> We had to do this because svn fetcher uses https without option to >> ignore errors (unlike wget which ignores certificates by default). > > Reading this made me realise this is a pretty complex issue. In general > we cannot assume that we can execute nativesdk binaries. Since ca- > certificates is allarch and we're executing an sh script, this is less > of an issue in this very specific case. There is a binary involved, > c_rehash and we do need to make sure there are the right -native > dependencies to get that.
c_rehash comes from openssl-native in this case. > > There is a further complication with regard to the paths used, ca- > certificates-native will use one set of paths, nativesdk-ca- > certificates will use a different set and target ca-certificates a > differnt set again. > > I suspect you're right and the ca-certificates-native dependency may be > incorrect and the certs installed into sdks may be broken too. If the > native sysroot and target sysroot layouts don't match, that would cause > an additional source of errors. > > So some changes in this area does appear to be needed... > > Cheers, > > Richard > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
