On 11/12/2016 07:56 PM, Wayne Blaszczyk wrote:
On Fri, 2016-11-11 at 00:54 -0600, DJ Lucas wrote:
On 11/10/2016 01:24 AM, DJ Lucas wrote:
As far as I can tell, the only remaining thing brought up in the
previous thread was how to obtain and verify the file. I do like using
the release branch as the default source (with version info as provided
by Bruce's script on Anduin). Bruce, what do you think about signing
that file for verification? Or even automatically updating the date and
md5sum of the file in the book -- changelog would need to be skipped I
think, but with that little concession, it should be reasonably easy to
do from cron.
Just curious, what was the reason for downloading the certdata.txt file to
Anduin and reprocessing it in the first place?
Was it just to convert it from html to txt and adding a date as per the note?
This link provides the raw file:
https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
as per https://wiki.mozilla.org/CA:Root_Store_Trust_Mods
My preference would still be grabbing it from the nss tarball.
The file certdata.txt from the current version (3.27.1) of nss, the md5sum
matches the md5sum of the above link.
I also read this thread,
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/FYIBEF_AVMI
The paragraph 'I have seen plenty of bungled attempts...' worries me a bit.
That is an interesting take by the Mozilla devs, and honestly, they are
correct, as evidenced by the number of changes I'm about to commit to
the book in this regard. It is pretty easy to mess up, which is why,
despite normal BLFS conventions, I'm pushing a big ugly script to do the
work, and to (hopefully) do it right. Things have changed considerably
and we simply haven't kept up. There is more to do yet, GnuTLS can use
p11-kit somehow, but I'm not familiar with that configuration.
Unfortunately, the alternative is even more daunting. I've expanded the
introduction to the page to convey the difficulty of doing this
yourself... verifying company info such as name, address, contact
information, making sure this is always accurate, ensuring that the
trusted CA undergoes regular security audits, verifying that they don't
do anything untoward, verifying that their CRL is always up to date,
verifying that any misuse of certificates is handled appropriately (and
if not, providing a reasonable set of consequences based on severity),
etc. All of that times ~170 (and realistically, looking at past
inclusions and current requests for enrollment, ~500) is what we get for
free from the Mozilla Foundation.
Having limited knowlege of how certificates work myself, I cannot give any
other advise.
I'll add the Mozilla tarballs as additional options 7-10. :-)
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
