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

[Andrej Valek]

What about enabling ASSUME_PROVIDED functionality also for nativesdk-
components?

Andrej

On 08/23/2017 09:00 PM, Khem Raj wrote:
> 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
>>
>>
>