On Thu, 2019-05-30 at 15:47 +0100, Philippe Normand wrote: > On Thu, 2019-05-30 at 17:06 +0300, Adrian Bunk wrote: > > On Thu, May 30, 2019 at 02:30:14PM +0100, Philippe Normand wrote: > > > Hi Adrian, > > > > Hi Philippe, > > > > > On Thu, 2019-05-30 at 15:17 +0300, Adrian Bunk wrote: > > > ... > > > > 2. Wouldn't the more common case be to use the ca-certificates > > > > package instead of PKCS #11? > > > > > > I don't know why glib-networking needs to go through gnutls which > > > then > > > needs to query p11-kit. I suppose p11-kit could directly be used, > > > but > > > this is not my call to make. > > > ... > > > > I think your "which then needs to query p11-kit" is not correct. > > > > My reading of configure.ac is that ca-certificates could be used > > instead, and this also makes a lot more sense in the default case. > > > > I've asked Michael Catanzaro about this, he's not subscribed to this > list so he can't reply to the thread. Here's his reply: > > The GnuTLS default trust store can be a certificate file bundle or a > certificate directory (provided by ca-certificates), or a PKCS#11 > URI, > but PKCS#11 is a better default. If you do not use PKCS#11, then > expected functionality like trusting and distrusting certificates > using > the 'trust' command or applications like seahorse will not work. Most > modern Linux distributions are now using PKCS#11 URIs; the only major > holdouts are Debian and Ubuntu. So I would definitely recommend the > PKCS#11 URI. Of course, basic functionality will work whichever way > you > choose; glib-networking only requires that GnuTLS has a default trust > store, one way or the other, so using a bundle would be OK if you > want to avoid the dependency on p11-kit.
I think most of our system is already using ca-certificates at this point so consistency here might make sense. If you use a PKCS#11 URI does that mean the systems would need network access to obtain the trust store? Ultimately we may want this to be a global config selection but using ca-certs and then having a wider discussion about a global option might make most sense. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
