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_certutilfor 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.
--DJ
make-ca.sh
Description: application/shellscript
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
