linux/poky.git/meta/recipes-support/ca-certificates, branch master-test

ca-certificates: correct upstream version check

2020-06-09T12:14:00+00:00

(From OE-Core rev: 9bc2943a7819c7e6d1bd4c1c03b265671811784c) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

ca-certificates: upgrade 20190110 -> 20200601

2020-06-04T12:27:32+00:00

-License-Update: format changed (From OE-Core rev: 0007f38b03bcb0bd561bd9181fbffc7dec47fe9a) Signed-off-by: Wang Mingyu Signed-off-by: Richard Purdie

ca-certificates: use python 3 for builds

2019-09-01T21:33:07+00:00

(From OE-Core rev: 8157c6d32e2af67211eb8fcd048a0771f10f7b26) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

ca-certificates: Fix reproducibilty and multilib issue

2019-08-29T16:12:34+00:00

This command was dependent on the order of files on the disk and for multilib builds could result in: Error: Transaction check error: file /etc/ca-certificates.conf conflicts between attempted installs of ca-certificates-20190110-r0.core2_32 and lib64-ca-certificates-20190110-r0.x86_64 Sorting the file makes things deterministic. (From OE-Core rev: c8f329fc562c9eecdcc1cb10d2c7661f44110fb4) Signed-off-by: Richard Purdie

ca-certificates: Fix openssl runtime dependencies

2019-05-31T14:36:20+00:00

Since yocto thud, and more specifically since poky switched to openssl 1.1 line, the openssl binary is provided by 'openssl-bin'. This impacts the native and nativesdk recipe variants as well. (From OE-Core rev: dc778c70449ee5401b5a24ad18b22b88338c47c5) Signed-off-by: Andrei Gherzan Signed-off-by: Richard Purdie

openssl: Remove the c_rehash shell re-implementation

2019-03-19T23:50:41+00:00

We had a c_rehash shell re-implementation being used for the native package however the ca-certificates now uses the openssl rehash internal application so there is no use for the c_rehash anymore. (From OE-Core rev: 672b076158247f823a518b7c33b50c82272d6388) Signed-off-by: Otavio Salvador Signed-off-by: Richard Purdie

ca-certificates: upgrade 20180409 -> 20190110

2019-02-20T11:30:35+00:00

(From OE-Core rev: 73ebdcaedde460108f98971f037e50e9b15c9f0c) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

ca-certificates: update to 20180409

2018-09-04T10:03:56+00:00

License-Update: URI fix (From OE-Core rev: 87acc51a7892524a22640bf9eba46c11701365d6) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

ca-certificates: avoid using += with an over-ride

2018-07-06T21:55:02+00:00

Using += with an over-ride can be a source of confusion so try to avoid the construct in core recipes. In this case, the commit which added the over-ride seems to have been buggy - the commit message mentions "add to SYSROOT_DIRS" rather than a correct description of what the change actually did, ie "over-ride SYSROOT_DIRS": http://git.openembedded.org/openembedded-core/commit/?id=355e49e19abb3e729c82a6de46ada8da8a257f58 The commit also appears to have been unnecessary as ${sysconfdir} is appended to SYSROOT_DIRS for -native recipes by default from within staging.bbclass. To workaround the bug introduced by the first commit, a subsequent commit later added ${datadir}/ca-certificates to the over-ride value (which would not normally be necessary as ${datadir} is included in the default value of SYSROOT_DIRS - ie the value which was lost due to being over-ridden): http://git.openembedded.org/openembedded-core/commit/?id=09bb7718d74573be9a5db4d0737fb14126f6489c Therefore the fix seem to be to remove the SYSROOT_DIRS over-ride entirely - the default value of SYSROOT_DIRS set by staging.bbclass includes both ${datadir} and ${sysconfdir} when building for -native. (From OE-Core rev: c1f18efda0280644b4a4ce6f2988fb7ada71faf6) Signed-off-by: Andre McCurdy Signed-off-by: Richard Purdie

ca-certificates: use relative symlinks from $ETCCERTSDIR

2018-03-31T08:48:42+00:00

update-ca-certificates symlinks (trusted) certificates from $CERTSDIR or $LOCALCERTSDIR into $ETCCERTSDIR. update-ca-certificates can call hook scripts installed into /etc/ca-certificates/update.d. Those scripts are passed the pem file in /etc/ssl/certs/ that was added or removed in this run and those pem files are absolute symlinks into $CERTSDIR or $LOCALCERTSDIR at the moment. When running update-ca-certificates during image build time, they thusly all point into the host's file system, not into the $SYSROOT. This means: * the host's file system layout must match the one produced by OE, and * it also means that the host must have installed the same (or more) certificates as the target in $CERTSDIR and $LOCALCERTSDIR This is a problem when wanting to execute hook scripts, because they all need to be taught about $SYSROOT, and behave differently depending on whether they're called at image build time, or on the target, as otherwise they will be trying to actually read the host's certificates from $CERTSDIR or $LOCALCERTSDIR. This also is a problem when running anything else during image build time that depends on the trusted CA certificates. Changing the symlink to be relative solves all of these problems. At the same time, we have to make sure to add $CERTSDIR to SYSROOT_DIRS, so that the symlinks are still valid when somebody DEPENDS on ca-certificates-native. As a side-effect, this also fixes a problem in meta-java, where some recipes (e.g. openjdk-8-native) try to access certificates from $CERTSDIR to generate the java trustStore at build time. Do so. Upstream-Status: Inappropriate [OE-specific] (From OE-Core rev: 09bb7718d74573be9a5db4d0737fb14126f6489c) Signed-off-by: André Draszik Signed-off-by: Richard Purdie