On Mon, 2016-11-07 at 15:08 -0600, DJ Lucas wrote: > Actually, all of the Mozilla products are using the version that shipped with > the NSS that they were built against... the internal copy in libnssckbi.so, > and that is likely what should be used for a > single source. > > On November 7, 2016 2:12:15 PM CST, Wayne Blaszczyk <[email protected]> > wrote: > > On Mon, 2016-11-07 at 10:50 -0600, Bruce Dubbs wrote: > > > 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 > > > > > > > Sorry, I meant to say upstream tarball. > > e.g. firefox-49.0.2.source.tar.xz > > > > > Actually, all of the Mozilla products are using the version that shipped with > the NSS that they were built against...the internal copy in libnssckbi.so, > and that is likely what should be used for a > single source. > > --DJ > > Last I looked at this, comparing nss to firefox tarballs, it seemed to me at the time that firefox was more current, or maybe I was comparing to what was in the Mozilla repostitory. I cannot remember now, but for some reason I switched from nss to firefox.
Wayne. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
