Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "André Draszik" <git@andred.net>
To: openembedded-core@lists.openembedded.org
Subject: [PATCH v2] ca-certificates: use relative symlinks from $ETCCERTSDIR
Date: Thu, 29 Mar 2018 16:43:19 +0100	[thread overview]
Message-ID: <20180329154319.15810-1-git@andred.net> (raw)

From: André Draszik <andre.draszik@jci.com>

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]
Signed-off-by: André Draszik <andre.draszik@jci.com>

---
v2:
* update SYSROOT_DIRS
* mention openjdk issue
---
 ...ertificates-use-relative-symlinks-from-ET.patch | 71 ++++++++++++++++++++++
 .../ca-certificates/ca-certificates_20170717.bb    |  6 +-
 2 files changed, 75 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-support/ca-certificates/ca-certificates/0003-update-ca-certificates-use-relative-symlinks-from-ET.patch

diff --git a/meta/recipes-support/ca-certificates/ca-certificates/0003-update-ca-certificates-use-relative-symlinks-from-ET.patch b/meta/recipes-support/ca-certificates/ca-certificates/0003-update-ca-certificates-use-relative-symlinks-from-ET.patch
new file mode 100644
index 0000000000..4bd967f788
--- /dev/null
+++ b/meta/recipes-support/ca-certificates/ca-certificates/0003-update-ca-certificates-use-relative-symlinks-from-ET.patch
@@ -0,0 +1,71 @@
+From a9fc13b2aee55655d58fcb77a3180fa99f96438a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@jci.com>
+Date: Wed, 28 Mar 2018 16:45:05 +0100
+Subject: [PATCH] update-ca-certificates: use relative symlinks from
+ $ETCCERTSDIR
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+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. Do so.
+
+Upstream-Status: Inappropriate [OE-specific]
+Signed-off-by: André Draszik <andre.draszik@jci.com>
+---
+ sbin/update-ca-certificates | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/sbin/update-ca-certificates b/sbin/update-ca-certificates
+index 00f80c7..7e911a9 100755
+--- a/sbin/update-ca-certificates
++++ b/sbin/update-ca-certificates
+@@ -29,6 +29,7 @@ CERTSDIR=$SYSROOT/usr/share/ca-certificates
+ LOCALCERTSDIR=$SYSROOT/usr/local/share/ca-certificates
+ CERTBUNDLE=ca-certificates.crt
+ ETCCERTSDIR=$SYSROOT/etc/ssl/certs
++FSROOT=../../../ # to get from $ETCCERTSDIR to the root of the file system
+ HOOKSDIR=$SYSROOT/etc/ca-certificates/update.d
+ 
+ while [ $# -gt 0 ];
+@@ -125,9 +126,10 @@ add() {
+   PEM="$ETCCERTSDIR/$(basename "$CERT" .crt | sed -e 's/ /_/g' \
+                                                   -e 's/[()]/=/g' \
+                                                   -e 's/,/_/g').pem"
+-  if ! test -e "$PEM" || [ "$(readlink "$PEM")" != "${CERT##$SYSROOT}" ]
++  DST="$(echo ${CERT} | sed -e "s|^$SYSROOT||" -e "s|^/|$FSROOT|" )"
++  if ! test -e "$PEM" || [ "$(readlink "$PEM")" != "${DST}" ]
+   then
+-    ln -sf "${CERT##$SYSROOT}" "$PEM"
++    ln -sf "${DST}" "$PEM"
+     echo "+$PEM" >> "$ADDED"
+   fi
+   # Add trailing newline to certificate, if it is missing (#635570)
diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb b/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
index 51af72e79a..a2efb3b4ef 100644
--- a/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
+++ b/meta/recipes-support/ca-certificates/ca-certificates_20170717.bb
@@ -21,10 +21,12 @@ SRC_URI = "git://anonscm.debian.org/collab-maint/ca-certificates.git \
            file://0001-update-ca-certificates-don-t-use-Debianisms-in-run-p.patch \
            file://update-ca-certificates-support-Toybox.patch \
            file://default-sysroot.patch \
-           file://sbindir.patch"
+           file://sbindir.patch \
+           file://0003-update-ca-certificates-use-relative-symlinks-from-ET.patch \
+           "
 
 S = "${WORKDIR}/git"
-SYSROOT_DIRS_class-native += "${sysconfdir}"
+SYSROOT_DIRS_class-native += "${sysconfdir} ${datadir}/ca-certificates"
 
 inherit allarch
 
-- 
2.16.2



                 reply	other threads:[~2018-03-29 15:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180329154319.15810-1-git@andred.net \
    --to=git@andred.net \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox