On 11/08/2016 02:30 PM, Bruce Dubbs wrote:
Ken Moffat wrote:
On Tue, Nov 08, 2016 at 12:02:53PM -0600, DJ Lucas wrote:
On November 8, 2016 1:47:28 AM CST, Wayne Blaszczyk
<[email protected]> wrote:
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.
Yes, they tend to go back and forth. I *believe* that this has been
the effective policy for the Mozilla products in the book since the
inclusion of standalone NSS (~2008 at best guess), but that needs to
be verified. Most recommended will be the release branch for
certdata.txt, with latest always being NSS tip.
http://hg.mozilla.org/projects/nss/raw-file/default/lib/ckfw/builtins/certdata.txt
Ultimately, the book needs some policy. The release branch has worked
for the CLI apps for a long time (and obviously FF, SM, and TB).
Maybe we could add some pointers to additional reading, in the book
or the wiki, for those who want (or need) to brave the latest and
greatest. Even the perl script included with curl could be utilized
to do a comparison. One could even go so far as to update the shared
nssdb with the modified trust from upstream, but that's a bit too
much for the book IMO. I'm not against making mention of it, along
with the "beyond the scope of the BLFS book" blurb.
--DJ
For my own current builds, I doubt that whatever happens will make
much difference - I always build LWP during my normal desktop
builds, and I've obviously only picked up recent certificate changes
from a completed system, so I don't need to get fresh certs in the
early stages of BLFS.
My one reservation is that at the moment I can look for updated
certificates several times a week, if I wish to. Usually I c heck
before updating firefox, but also if deprecation of a CA gets
mentioned anywhere. I'm not clear if I can still do that *easily*
if we move to using an nss (or firefox) release, or whether in
practice I'll have to wait for a new release of whichever package you
choose.
Example: I last updated my certs to 20161030. As of 60 seconds ago
the current version is 20161103 - and BOTH of those are newer than
the current nss and non-beta firefox.
I've stayed out of this discussion mostly because I don't want to
interfere with progress in allowing for local or java certs. For
regular certs used by a browser, I still prefer the method we had before
because of reasons Ken gives above. The certs on anduin are checked
daily from the hg.mozilla.org site. If upstream makes changes, a one
line header is added simulating a CVS header and then posted for users.
I do not want to discourage changes, but there are advantages and
disadvantages to different methods. The issue is which is best for the
book.
There seems to be some confusion about what we currently have.
Unfortunately, what we have now (and had previously) has no effect on
FF/SM/TB/Chromium (or anything else using NSS instead of OpenSSL). They
all use the built-ins in NSS's libnssckbi.so and their own local copy of
additional certificates unless told to use something else (ie: the
proposed shared nssdb in /etc/pki/nssdb). Which reminds me, the script I
posted yesterday is not a complete solution.
What I've proposed is that we use the NSS built-ins as the base
certificate store for BLFS (keep in mind that this is already what our
browsers have been using for the past 8 years or so), setup the shared
nssdb, and provide an _example_ of how to extend everything via
/etc/ssl/local (probably using the mk-ca-bundle.pl script included with
curl as an example).
When NSS is installed (or updated), if our script is installed, run it
to update everything in one shot. The Mozilla products and Evolution
need to be setup to take advantage of the shared nssdb, but WebKit/NSS
uses ~/.pki/nssdb by default (this includes Chromium and I *think* the
KDE browser as well, the Gnome browser uses OpenSSL currently). I'm not
sure if new profiles in the Moz products can be made to easily default
to ~/.pki/nssdb (without modifying NSS...see OpenSUSE solution below),
but I'm sure, given a little time, I can probably find something less
intrusive.
Further considerations for those of us going beyond the default store:
duplicates are not an issue for OpenSSL/GNUTLS - the hash will be the
same so it'll get overwritten in the cert directory, and duplicates in
the bundle I've seen before without issue (the first matching entry
wins). Unfortunately, the same is not true for NSS as it uses the
built-in certificates for more than just server certificate
verification, (the three additional fields in certutil list output), so
the extras in /etc/ssl/local should be limited to certs not already
included in libnssckbi.so, or we could update the shared db using the
CKA_TRUST* fields, or just blindly do -t C,C,C or equivalent (this seems
to be what the big distros do). It's, complicated to say the least. At
least for a browser or mail client, C,C,C should be safe (as long as the
source is C,?,?).
I'll take a stab at a write-up that explains all of this for possible
inclusion in the book, but I'd like to encourage others to look into it
as well. If my babbling above has done more harm than good, here are a
few links that exclude my incessantly long posts: :-)
Here is documentation for certutil:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_certutil
The shared DB:
https://wiki.mozilla.org/NSS_Shared_DB
Configuring FF/SM/TB to use the shared DB:
https://wiki.mozilla.org/NSS_Shared_DB_Howto
or
http://blog.xelnor.net/firefox-systemcerts/
Here is the application overview, not particularly useful for BLFS, but
should help to explain what happens internally:
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
OpenSUSE uses another module (which we *could* also add) to make
application configuration dead easy:
https://en.opensuse.org/SDB:Share_certificates_between_applications_or_whole_system
I think RedHat does something similar.
This was also interesting reading:
https://old-en.opensuse.org/SharedCertStore
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
