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 -- 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
