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

[Khem Raj]

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