[OE-core] [PATCH] ca-certificates: prevent executing update-ca-certificates from host system

[Richard Purdie]

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.

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