From: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
To: openembedded-core@lists.openembedded.org
Subject: [PATCH] openssl: rehash actual mozilla certificates inside rootfs
Date: Fri, 28 Oct 2016 10:22:35 +0300 [thread overview]
Message-ID: <1477639355-28937-1-git-send-email-dmitry.rozhkov@linux.intel.com> (raw)
The c_rehash utility is supposed to be run in the folder /etc/ssl/certs
of a rootfs where the package ca-certificates puts symlinks to
various CA certificates stored in /usr/share/ca-certificates/mozilla/.
These symlinks are absolute. This means that when c_rehash is run
at rootfs creation time it can't hash the actual files since they
actually reside in the build host's directory
$SYSROOT/usr/share/ca-certificates/mozilla/.
This problem doesn't reproduce when building on Debian or Ubuntu
hosts though, because these OSs have the certificates installed
in the same /usr/share/ca-certificates/mozilla/ folder.
Images built in other distros, e.g. Fedora, have problems with
connecting to https servers when using e.g. python's http lib.
The patch fixes c_rehash to check if it runs on a build host
by testing $SYSROOT and to translate the paths to certificates
accordingly.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
---
.../openssl/openssl/openssl-c_rehash.sh | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
index f67f415..25ea729 100644
--- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
+++ b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
@@ -114,11 +114,11 @@ link_hash()
LINKFILE=${HASH}.${TAG}${SUFFIX}
done
- echo "${1} => ${LINKFILE}"
+ echo "${3} => ${LINKFILE}"
# assume any system with a POSIX shell will either support symlinks or
# do something to handle this gracefully
- ln -s ${1} ${LINKFILE}
+ ln -s ${3} ${LINKFILE}
return 0
}
@@ -142,7 +142,19 @@ hash_dir()
ls -1 *.pem *.cer *.crt *.crl 2>/dev/null | while read FILE
do
- check_file ${FILE}
+ REAL_FILE=${FILE}
+ # if we run on build host then get to the real files in rootfs
+ if [ -n "${SYSROOT}" -a -h ${FILE} ]
+ then
+ FILE=$( readlink ${FILE} )
+ # check the symlink is absolute (or dangling in other word)
+ if [ "x/" == "x$( echo ${FILE} | cut -c1 -)" ]
+ then
+ REAL_FILE=${SYSROOT}/${FILE}
+ fi
+ fi
+
+ check_file ${REAL_FILE}
local FILE_TYPE=${?}
local TYPE_STR=''
@@ -157,7 +169,7 @@ hash_dir()
continue
fi
- link_hash ${FILE} ${TYPE_STR}
+ link_hash ${REAL_FILE} ${TYPE_STR} ${FILE}
done
}
--
2.5.5
reply other threads:[~2016-10-28 7:23 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=1477639355-28937-1-git-send-email-dmitry.rozhkov@linux.intel.com \
--to=dmitry.rozhkov@linux.intel.com \
--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