Tiny Core Linux
Tiny Core Extensions => TCE Corepure64 => Topic started by: andyj on May 04, 2017, 10:52:53 AM
-
I see that TCL 8.x has the latest version of OpenSSL, whereas 7.x is behind. Is there a security reason why the 8.x binary shouldn't be used on 7.x, or is it safe to use? Also, are the certificates files different between platforms?
-
It probably won't work due to being compiled against newer libs, but if it works, there is no downside to using it.
-
Note also that the openssl extensions in the tc-7.x x86 and X86_64 repos contained ca-certificates - these were factored out to a separate extension in the tc-8.x repos.
-
I saw that which got me thinking. OpenSSL extension is openssl + ca-certificates, and ca-certificates extension is ca-certificates only, so to get updated ca-certificates you wind up with them being loaded twice unless in the process of loading ca-certificates it unloads any existing ones first. Seems that it would be cleaner and easier if openssl was software only with ca-certificates as a dependency, and maybe less overall maintenance.
-
In tc-8.x, the openssl extension does not contain any ca-certificates.
-
I noticed that in TC-8 the ca-certificates depends on (but I couldn't see where) perl, which wasn't required before. Ignoring the hugeness of the perl extension, what is this for?
-
As you say, needing perl is not ideal - c_rehash (openssl) is a perl script.
-
So, perl is an optional dependency of openssl, but not ca-certificates? Could we remove the dependency on perl from ca-certificates dep file, and leave it out of the openssl dep file?
-
perl is not optional for ca-certificates, c_rehash is run by update-ca-certificates, which is called by the start-up script.
-
I accepted your challenge, and wrote the equivalent (as far as I can tell) functionality (that we're using c_rehash for) for sh:
#!/bin/sh
#
CERTDIR="$1"
# remove hash links
/bin/busybox find "$CERTDIR" -regex '.*/[0-9a-f]\{8\}\.[0-9]\{1,\}' -type l -exec rm {} \;
for CFILE in $CERTDIR/*.pem $CERTDIR/*.crt $CERTDIR/*.cer $CERTDIR/*.crl; do
FNAME=$(echo $CFILE | sed "s/'/\\'/g")
KEYS=""
grep -q -E '^-----BEGIN (X509 |TRUSTED |)CERTIFICATE-----' $FNAME 2>/dev/null && \
KEYS=$(openssl x509 -subject_hash -fingerprint -noout -in $FNAME) && \
CRL=""
grep -q -E '^-----BEGIN X509 CRL-----' $FNAME 2>/dev/null && \
KEYS=$(openssl crl -hash -fingerprint -noout -in $FNAME) && \
CRL="r"
if [ -n "$KEYS" ] ; then
HASH=${KEYS:0:8}
FPRINT=${KEYS##*=} && FPRINT=${FPRINT//:/}
SFX=0
while [ $SFX -lt 10 ] ; do
HASHSFX=HASH_${HASH}_${CRL}${SFX}
eval "HASHED=\${$HASHSFX}"
if [ -z "$HASHED" ] ; then
eval "$HASHSFX=$FPRINT"
ln -s $CFILE "${HASH}.${CRL}${SFX}"
break
elif [ "$HASHED" = "$FPRINT" ] ; then
echo "duplicate certificate $CFILE"
break
else
SFX=$(($SFX + 1))
fi
done
fi
done
Once the 14 meg perl extension is loaded TinyCore becomes PudgyCore. :o I already have enough bloat issues :P
-
looks interesting - I'm away tomorrow, but will test when I get back.
-
Maybe openssl or libressl would also be interested? (if it works with GNU versions and not just bb, of course)
-
The syntax of the regex for GNU find is different, which is why I had to specify busybox as the command. I put together this script to solve our specific problem and not replace all the functionality of c_rehash, although this is probably 90+% of it. Also, as you can see, there isn't much in the way of verbose logging or error checking. I don't know what the common issues are to put in the handling for them.
-
corepure64 8.x ca-certificates updated - thanks for this :)
-
Not to be a nag, but somehow the version of the script in my updated ca-certificates extension got corrupted and gives me a "expected done" error. I couldn't see the problem, so I'm uploading the script that works on my system. I modified the for loop to use find instead of globbing files in the shell so we won't get the pattern back if it doesn't match. Update-ca-certificates is also complaining about a missing /usr/local/etc/ca-certificates.conf. Could we maybe add a /usr/local/etc/ca-certificates.conf-sample to the extension as a go by? Not that I don't appreciate all the fame and glory and so on, but maybe a name more like c_rehash.sh?
-
posted