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
Wayne. > -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
