On 08/11/2016 08:03, DJ Lucas wrote:
On 11/07/2016 02:21 AM, 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. 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?
So, how does NSS being a dependency sit with everyone (since it's our
source for the browsers anyway)? We avoid downloading an external
file, it's a single script (which is actually readable with no crazy
ranges), we get the local directory, a shared nssdb with only the
added certs (internal ones are still used), there are no other
dependencies, and everything is synced. I also added back in the dump
text for the individual pem files (so we have a text account of the
CKA_TRUST bits), as well as other useful information.
I like this a lot...much cleaner than the other two. :-) It needs some
testing, but I think it's fairly sane. I'm also not sure about the
trustargs for the local certs. I went with CT,c,c, but was thinking
maybe CT,C,c would be more appropriate. See
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_certutil
for a description. Just run make-ca.sh after you update NSS and all
will be in sync again.
There is a bit more to it than just that to actually used the shared
DB for firefox/seamonkey/thunderbird/chrome, but that's the gist of
getting it all together.
I think there are two aspects of the problem:
- CA certificates are an important part of system security, so they
should be handled as carefully as possible. What DJ proposes is very
good in that respect, AFAICT
- BLFS systems should be easy to build. CA-certificates are needed early
in the build, because a lot of download sites are https nowadays. That's
why including too many dependencies is annoying. NSS is very good in
this respect, since it only adds NSPR and sqlite (as recommended). But
sqlite is needed early too, because it is used in subversion, which is
itself needed if one wants to use the development book...
So +1 for me
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
