Wayne Blaszczyk wrote:
On Sun, 2016-11-06 at 13:54 -0600, DJ Lucas wrote:
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.
I just like to put my 2 cents. There was one thing I didn't like about the
previous method, and that was that the certdata.txt file was kept at anduin.
There was no checksum or signing to this file, and therefore to my mind, was
untrustworthy.
That file is still present. The checksum was a problem since the file was
checked daily against upstream sources and modified to include a date of
last update. It would not have been appropriate to put a checksum in the
book. I suppose I could have had it as a separate file or did a digital
signature, but no one asked.
So much so, I actualy slightly modified the previous script to
initially take the file from the nss tarball. Later on I changed to the
firefox tarball.
I don't particular like pulling in libwww-perl as it pulls in 17 modules, but
I can live with it.
If you did go back to the way before, could you consider extracting the
certdata.txt from a distribution tarball?
What distribution tarball? Debian, Fedora, etc? I don't know how often
those are updated.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
