On 11/08/2016 10:52 PM, DJ Lucas wrote:
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,?,?).
Okay, so how to make it work. I tested my making my own CA and importing
the root cert. Here are necessary changes in addition to the HOWTO links.
dj [ ~/LFS/BLFS/trunk/BOOK-no-lib64 ]$ cat /etc/pki/nssdb/pkcs11.txt
library=libnsssysinit.so
name=NSS Internal PKCS #11 Module
parameters=configdir='sql:/etc/pki/nssdb' certPrefix='' keyPrefix=''
secmod='secmod.db' flags= updatedir='' updateCertPrefix=''
updateKeyPrefix='' updateid='' updateTokenDescription=''
NSS=Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100
slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512]
askpw=any timeout=30})
Changes are (noted by asterisks) library=*libnsssysinit.so*,
configdir=`sql:*/etc/pki/nssdb*' and Flags=internal,*moduleDBOnly,*critical
dj [ ~/LFS/BLFS/trunk/BOOK-no-lib64 ]$ cat ~/.pki/nssdb/pkcs11.txt
library=libnsssysinit.so
name=NSS Internal PKCS #11 Module
parameters=configdir='sql:/home/dj/.pki/nssdb' certPrefix=''
keyPrefix='' secmod='secmod.db' flags=optimizeSpace updatedir=''
updateCertPrefix='' updateKeyPrefix='' updateid=''
updateTokenDescription=''
NSS=Flags=moduleDBOnly,internal,critical trustOrder=75 cipherOrder=100
slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512]
askpw=any timeout=30})
Same two changes here: library and moduleDBOnly (correct path should
already be in place).
Locally signed cert with my root CA now works, as does stuff on the web
provided by internal (libnssckbi.so). At this point, I think we are
better going with something similar to the custom solution we had
originally and eliminating internal (libnssckbi.so). Above (and earlier
links) should be enough to get it working. I'm not going to expand
further in this thread, though I'd still like to hear any additional
thoughts from y'all.
Unfortunately, this has snowballed. I'm going to clam up and provide a
complete example with all the necessary parts in place. We can flesh out
the details (which will primarily be where/how to get certdata.txt)
after a complete working example solution is proposed. If anybody has
issue with going back to a modified version of the old method, please
speak up. This will take me at a couple of days I think.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
