On 11/06/2016 11:51 AM, Bruce Dubbs wrote:
Pierre Labastie wrote:
As far as I understand, Perl LWP is required for make-ca-bundle.pl,
which is
included in curl package, but otherwise, make-ca-bundle.pl and Perl
LWP are
not needed for curl. Strictly speaking, Perl LWP is therefore a
dependency of
curl, but is not used by curl...
I would say that mixture between CA-certificates retrieval and curl
library is
all but KISS.
So why not separate things:
- on CA-certificates page: put the curl tarball as additional download
for
CA-certificates, give instruction to install make-ca-bundle.pl from that
package, and mention the Perl LWP dep.
- on the curl page: remove the make-ca-bundle.pl installation (but
keep the
cacerts as recommended at runtime).
I'm good with this, in fact, we could probably link to the script in
curl's VCS, but see below.
Thoughts?
Pierre
PS : I do not really like the idea of having Perl LWP as a dep for
cacerts.
Isn't it possible to modify the script to only use standard perl
modules (or
script in another language)?
It's difficult, but not impossible. I had already started looking into
this, but pivoted to the script included with curl. The certdata.txt
file is DER/Octal (PITA to do in all bash with assistance from already
installed binaries). Also, we need to expand the make-ca.sh script that
we used previously to check for additional CKA_TRUST* values. The old
let a few certs slip that we don't need (8 as of today's nss tip, but
they don't cause harm). We could certainly go back to something custom
(as we did before) if LWP is too much to ask for. I don't personally
think it is, but it wasn't discussed on list.
Or we could do like we did before and pull the data to anduin and have
users get that.
We can also easily go back to what we had before, and that was a
consideration before I made the changes. Before we do that, however, I'd
like to discuss the goals that were in mind for the new setup, and see
if anybody has objections, suggestions for change, or more questions.
First, and most important for me, was to allow for local certs in the
installed certificate chain via /etc/ssl/local. This could easily be
accomplished by modifying our old script. An example of why this might
be necessary would be participating in an Active Directory domain that
has it's own CA (all Windows AD domains - this can, but shouldn't, be
the case for Samba AD domains). Also, trusting certs from somewhere like
http://www.cacert.org/ might be desirable, or say Let's Encrypt before
they were recently accepted in Mozilla's trust.
Second, I wanted to be able to update all three local copies of cacerts
in one shot to keep things synchronized, but mainly to provide something
that could be used in a cron job directly. Additionally, there was the
concern of maintaining version information from upstream. In the new
setup, we use the md5sums of the downloaded file (this is internal to
the perl script that ships with curl), to verify the version and see if
an update is even necessary. Additionally, that script actually does the
date verification for us, but we still need that part of the script to
handle the certs in /etc/ssl/local.
Third, I wanted to reduce dependence on our own scripts and
infrastructure. I thought it kind of sloppy that we had three separate
scripts in the book (and yes, this was my doing originally, and we still
use two in the new setup). The script included with the curl
distribution was ready made for this task, meaning that we don't have to
maintain our own (especially the perl script that we used). That script
also allowed us to grab the certs directly from upstream sources and
choose from which HG tree to use (in my case, I use NSS tip). It was the
slow inclusion of Let's Encrypt and the also the slowly adopted
remediation of WoSign/StartCom that prompted me to move to NSS tip as
the upstream source locally. We still use the release branch (what
matches our installed Firefox browser) by default with the option to
switch in the wrapper script that I put into the book. With the old
setup, we can still download whichever we choose, but we do not provide
the URLs in the book. Personally, I only care about NSS tip at this
point (changes upstream are pretty well fleshed out before they go in).
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
