* NSM certificate prompt @ 2014-12-13 14:43 Eli Zaretskii 2014-12-13 15:12 ` Lars Magne Ingebrigtsen 2014-12-13 15:27 ` Michael Albinus 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 14:43 UTC (permalink / raw) To: emacs-devel If I use eww to connect to www.google.com and then click on the "Sign in" link, I get the following buffer displayed to me by the NSM: Certificate information Issued by: Google Internet Authority G2 Issued to: Google Inc Hostname: accounts.google.com Public key: RSA, signature: RSA-SHA1 Protocol: TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD Security level: Medium Valid: From 2014-12-03 to 2015-03-03 The TLS connection to accounts.google.com:443 is insecure for the following reasons: certificate signer was not found (self-signed) certificate could not be verified This is in Emacs 25.0.50 built with GnuTLS 3.3.11 on MS-Windows. Other Web browsers on this system don't have any trouble displaying that page. Do others see this on other systems? Is my system/Emacs somehow misconfigured wrt certificates? TIA ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 14:43 NSM certificate prompt Eli Zaretskii @ 2014-12-13 15:12 ` Lars Magne Ingebrigtsen 2014-12-13 16:01 ` Eli Zaretskii 2014-12-13 15:27 ` Michael Albinus 1 sibling, 1 reply; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-13 15:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Issued by: Google Internet Authority G2 > Issued to: Google Inc > Hostname: accounts.google.com If I go to https://accounts.google.com, I do not get any warnings. (This is on Debian.) Is it possible that your CA bundle doesn't include the Google Internet Authority G2 CA root certificate? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 15:12 ` Lars Magne Ingebrigtsen @ 2014-12-13 16:01 ` Eli Zaretskii 2014-12-13 16:04 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 16:01 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: emacs-devel > From: Lars Magne Ingebrigtsen <larsi@gnus.org> > Cc: emacs-devel@gnu.org > Date: Sat, 13 Dec 2014 16:12:52 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Issued by: Google Internet Authority G2 > > Issued to: Google Inc > > Hostname: accounts.google.com > > If I go to https://accounts.google.com, I do not get any warnings. > (This is on Debian.) Is it possible that your CA bundle doesn't include > the Google Internet Authority G2 CA root certificate? GnuTLS on Windows doesn't by default use the CA bundle, it uses the Windows's own certificate store. I don't know how to examine that store, except by writing a program that accesses it. If the conclusion is that this is the source of the problem, I'll do that, but I wonder how both MS IE and Firefox have no problems with that on the same system. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 16:01 ` Eli Zaretskii @ 2014-12-13 16:04 ` Lars Magne Ingebrigtsen 2014-12-13 16:46 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-13 16:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > GnuTLS on Windows doesn't by default use the CA bundle, it uses the > Windows's own certificate store. I don't know how to examine that > store, except by writing a program that accesses it. If the > conclusion is that this is the source of the problem, I'll do that, > but I wonder how both MS IE and Firefox have no problems with that on > the same system. Is Emacs/gnutls able to access the certificate store? That is, is this the only https site you get warnings? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 16:04 ` Lars Magne Ingebrigtsen @ 2014-12-13 16:46 ` Eli Zaretskii 2014-12-13 17:27 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 16:46 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: emacs-devel > From: Lars Magne Ingebrigtsen <larsi@gnus.org> > Cc: emacs-devel@gnu.org > Date: Sat, 13 Dec 2014 17:04:17 +0100 > > Is Emacs/gnutls able to access the certificate store? How do I tell? > That is, is this the only https site you get warnings? I see the same for savannah.gnu.org, github.com, and www.facebook.com/GitHub. If you have other https sites you want me to check, please tell. But it looks like this happens for pretty much any https URL. And in each case, Emacs does show me the authority that issued the certificate, but always claims that "certificate signer was not found" and "certificate could not be verified". ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 16:46 ` Eli Zaretskii @ 2014-12-13 17:27 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-13 17:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > I see the same for savannah.gnu.org, github.com, and > www.facebook.com/GitHub. If you have other https sites you want me to > check, please tell. But it looks like this happens for pretty much > any https URL. And in each case, Emacs does show me the authority > that issued the certificate, but always claims that "certificate > signer was not found" and "certificate could not be verified". Yeah, that means that gnutls isn't able to access any root CAs from the certificate store. I'm wholly unfamiliar with how that's supposed to work under Windows, but perhaps somebody else knows how to debug this? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 14:43 NSM certificate prompt Eli Zaretskii 2014-12-13 15:12 ` Lars Magne Ingebrigtsen @ 2014-12-13 15:27 ` Michael Albinus 2014-12-13 15:35 ` Lars Magne Ingebrigtsen ` (2 more replies) 1 sibling, 3 replies; 37+ messages in thread From: Michael Albinus @ 2014-12-13 15:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > If I use eww to connect to www.google.com and then click on the "Sign > in" link, I get the following buffer displayed to me by the NSM: > > Certificate information > Issued by: Google Internet Authority G2 > Issued to: Google Inc > Hostname: accounts.google.com > Public key: RSA, signature: RSA-SHA1 > Protocol: TLS1.2, key: ECDHE-RSA, cipher: AES-128-GCM, mac: AEAD > Security level: Medium > Valid: From 2014-12-03 to 2015-03-03 > > > The TLS connection to accounts.google.com:443 is insecure for the > following reasons: > > certificate signer was not found (self-signed) > certificate could not be verified > > This is in Emacs 25.0.50 built with GnuTLS 3.3.11 on MS-Windows. > Other Web browsers on this system don't have any trouble displaying > that page. Do others see this on other systems? Is my system/Emacs > somehow misconfigured wrt certificates? "Other Web browsers" carry builtin certificates. For example if you use Firefox, click on the lock icon heading the url. Click on "More Information". Click on "View Certificate". In the "Details" tab, you'll see that "Google Internet Authority G2" is signed by "GeoTrust Global CA", which is signed by "Equifax Secure CA". The latter one is a builtin certificate Firefox knows about, so it is a valid certificate chain. > TIA Best regards, Michael. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 15:27 ` Michael Albinus @ 2014-12-13 15:35 ` Lars Magne Ingebrigtsen 2014-12-13 16:57 ` Michael Albinus 2014-12-13 16:03 ` Eli Zaretskii 2014-12-13 16:39 ` Eli Zaretskii 2 siblings, 1 reply; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-13 15:35 UTC (permalink / raw) To: Michael Albinus; +Cc: Eli Zaretskii, emacs-devel Michael Albinus <michael.albinus@gmx.de> writes: > "Other Web browsers" carry builtin certificates. We should do that too, I guess. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 15:35 ` Lars Magne Ingebrigtsen @ 2014-12-13 16:57 ` Michael Albinus 2014-12-13 17:06 ` Eli Zaretskii 2014-12-13 17:29 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 37+ messages in thread From: Michael Albinus @ 2014-12-13 16:57 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Michael Albinus <michael.albinus@gmx.de> writes: > >> "Other Web browsers" carry builtin certificates. > > We should do that too, I guess. I don't think so. It will be an endless story, because this will require permanent updates. Certificates have a limited life (see the Expires attribute); new certificates must be added regularly, and even established certificates must be revoked sometimes (if the CA has been hacked, for example). A better solution might be to use system-installed certificates. For example, Debian offers the package ca-certificates. It installs known certificates at /usr/share/ca-certificates, which could be used. See also /usr/share/doc/ca-certificates/README.Debian. Similar packages might exist for other systems. Don't know, whether gnutls uses them already by default. Best regards, Michael. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 16:57 ` Michael Albinus @ 2014-12-13 17:06 ` Eli Zaretskii 2014-12-13 17:29 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 17:06 UTC (permalink / raw) To: Michael Albinus; +Cc: larsi, emacs-devel > From: Michael Albinus <michael.albinus@gmx.de> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > Date: Sat, 13 Dec 2014 17:57:03 +0100 > > A better solution might be to use system-installed certificates. For > example, Debian offers the package ca-certificates. It installs known > certificates at /usr/share/ca-certificates, which could be used. > See also /usr/share/doc/ca-certificates/README.Debian. > > Similar packages might exist for other systems. Don't know, whether > gnutls uses them already by default. It does, and I do have the certificate bundle installed on the system I'm experiencing this. But I configured GnuTLS to use the Windows's certificate store for now, so the bundle is not used in my build of GnuTLS. I can change that, but I don't yet have sufficient information to claim that this is the root cause for the problem. See my other messages. I'd like to understand the problem more before I decide to dig into the code or ask GnuTLS developers a question. I still feel this is somehow a configuration issue, or maybe Emacs doesn't use GnuTLS correctly, at least on Windows. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 16:57 ` Michael Albinus 2014-12-13 17:06 ` Eli Zaretskii @ 2014-12-13 17:29 ` Lars Magne Ingebrigtsen 2014-12-13 18:03 ` Eli Zaretskii 1 sibling, 1 reply; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-13 17:29 UTC (permalink / raw) To: Michael Albinus; +Cc: Eli Zaretskii, emacs-devel Michael Albinus <michael.albinus@gmx.de> writes: > I don't think so. It will be an endless story, because this will require > permanent updates. It's what all other web browsers do. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 17:29 ` Lars Magne Ingebrigtsen @ 2014-12-13 18:03 ` Eli Zaretskii 2014-12-13 18:06 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 18:03 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: michael.albinus, emacs-devel > From: Lars Magne Ingebrigtsen <larsi@gnus.org> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > Date: Sat, 13 Dec 2014 18:29:06 +0100 > > Michael Albinus <michael.albinus@gmx.de> writes: > > > I don't think so. It will be an endless story, because this will require > > permanent updates. > > It's what all other web browsers do. A middle ground would be to offer to perform an update of the certificates when validation fails. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 18:03 ` Eli Zaretskii @ 2014-12-13 18:06 ` Lars Magne Ingebrigtsen 2014-12-13 19:16 ` Michael Albinus 0 siblings, 1 reply; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-13 18:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael.albinus, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > A middle ground would be to offer to perform an update of the > certificates when validation fails. Yes, that would be nice. We'd have to have a secure way to retrieve those certificates, though. Perhaps we could use GNU ELPA for this? Wasn't there some work done on signing packages? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 18:06 ` Lars Magne Ingebrigtsen @ 2014-12-13 19:16 ` Michael Albinus 2014-12-13 20:02 ` Ted Zlatanov 0 siblings, 1 reply; 37+ messages in thread From: Michael Albinus @ 2014-12-13 19:16 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Eli Zaretskii <eliz@gnu.org> writes: > >> A middle ground would be to offer to perform an update of the >> certificates when validation fails. > > Yes, that would be nice. We'd have to have a secure way to retrieve > those certificates, though. Perhaps we could use GNU ELPA for this? > Wasn't there some work done on signing packages? That's not the crucial point. A root certificate could be compromised, and with this compromised root certificate a validation might still succeed when it shouldn't. ELPA does not has the means to urge a package update of the hypothetical ca-certificates package, when a new version appears. And who from the core Emacs team will feel responsible to produce a new version of that package when necessary? This must happen short-term, which means a small security team of Emacs must observe relevant mailing list and alike, and must react in time. I don't believe this belongs to Emacs' core functionality. It might be better to investigate first, whether there exist already an infrastructure on the different supported systems we could use. Like the Debian package I've mentioned already. Best regards, Michael. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 19:16 ` Michael Albinus @ 2014-12-13 20:02 ` Ted Zlatanov 0 siblings, 0 replies; 37+ messages in thread From: Ted Zlatanov @ 2014-12-13 20:02 UTC (permalink / raw) To: emacs-devel On Sat, 13 Dec 2014 20:16:30 +0100 Michael Albinus <michael.albinus@gmx.de> wrote: MA> Lars Magne Ingebrigtsen <larsi@gnus.org> writes: >> Eli Zaretskii <eliz@gnu.org> writes: >> >>> A middle ground would be to offer to perform an update of the >>> certificates when validation fails. >> >> Yes, that would be nice. We'd have to have a secure way to retrieve >> those certificates, though. Perhaps we could use GNU ELPA for this? >> Wasn't there some work done on signing packages? We have signed packages (but you need GnuPG installed). The last time I brought up storing the CA certificates inside Emacs, there was no interest in maintaining that facility. Similarly, we don't package GnuTLS with Emacs, so the user has to update it manually (we also discussed this with Eli a while back). MA> That's not the crucial point. A root certificate could be compromised, MA> and with this compromised root certificate a validation might still MA> succeed when it shouldn't. ELPA does not has the means to urge a package MA> update of the hypothetical ca-certificates package, when a new version MA> appears. Well, typically CRLs are used for such urgent revocations, right? So those could be supported specifically. And we could say that `network-security-level' of 'high or above requires having the latest GNU ELPA certificates package. I think it's technically possible. MA> I don't believe this belongs to Emacs' core functionality. It might be MA> better to investigate first, whether there exist already an MA> infrastructure on the different supported systems we could use. Like the MA> Debian package I've mentioned already. It's definitely easier to rely on the host OS. I don't know if it's always the right thing because not all platforms are up to date, and the user may not be able to control the CA store updates. The GnuTLS updates are handled similarly. Ted ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 15:27 ` Michael Albinus 2014-12-13 15:35 ` Lars Magne Ingebrigtsen @ 2014-12-13 16:03 ` Eli Zaretskii 2014-12-13 16:39 ` Eli Zaretskii 2 siblings, 0 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 16:03 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel > From: Michael Albinus <michael.albinus@gmx.de> > Cc: emacs-devel@gnu.org > Date: Sat, 13 Dec 2014 16:27:32 +0100 > > "Other Web browsers" carry builtin certificates. Does that include MS IE? Because it, too, doesn't have any problems with HTTPS URLs, on that very system. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 15:27 ` Michael Albinus 2014-12-13 15:35 ` Lars Magne Ingebrigtsen 2014-12-13 16:03 ` Eli Zaretskii @ 2014-12-13 16:39 ` Eli Zaretskii 2014-12-13 17:06 ` Michael Albinus 2 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 16:39 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel > From: Michael Albinus <michael.albinus@gmx.de> > Date: Sat, 13 Dec 2014 16:27:32 +0100 > Cc: emacs-devel@gnu.org > > "Other Web browsers" carry builtin certificates. For example if you use > Firefox, click on the lock icon heading the url. Click on "More > Information". Click on "View Certificate". In the "Details" tab, you'll > see that "Google Internet Authority G2" is signed by "GeoTrust Global > CA", which is signed by "Equifax Secure CA". The latter one is a builtin > certificate Firefox knows about, so it is a valid certificate chain. If I do the same for savannah.gnu.org in IE, it shows the following certification path: UTN-USERFirst-Hardware Gandi Standard SSL CA savannah.gnu.org Emacs's eww prompts me about https://savannah.gnu.org and shows me this information about its certificate: Certificate information Issued by: Gandi Standard SSL CA Issued to: Domain Control Validated Hostname: savannah.gnu.org Public key: RSA, signature: RSA-SHA1 Protocol: TLS1.0, key: RSA, cipher: AES-128-CBC, mac: SHA1 Security level: Medium Valid: From 2014-03-05 to 2015-03-05 The TLS connection to savannah.gnu.org:443 is insecure for the following reasons: certificate signer was not found (self-signed) certificate could not be verified which also talks about Gandi Standard SSL CA. So I wonder why GnuTLS isn't happy with this, while MS IE is. Am I missing something? (Please be gentle: I know nothing about Internet security and certificates.) ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 16:39 ` Eli Zaretskii @ 2014-12-13 17:06 ` Michael Albinus 2014-12-13 18:01 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Michael Albinus @ 2014-12-13 17:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > If I do the same for savannah.gnu.org in IE, it shows the following > certification path: > > UTN-USERFirst-Hardware > Gandi Standard SSL CA > savannah.gnu.org > > Emacs's eww prompts me about https://savannah.gnu.org and shows me > this information about its certificate: > > Certificate information > Issued by: Gandi Standard SSL CA > Issued to: Domain Control Validated > Hostname: savannah.gnu.org > Public key: RSA, signature: RSA-SHA1 > Protocol: TLS1.0, key: RSA, cipher: AES-128-CBC, mac: SHA1 > Security level: Medium > Valid: From 2014-03-05 to 2015-03-05 > > > The TLS connection to savannah.gnu.org:443 is insecure for the > following reasons: > > certificate signer was not found (self-signed) > certificate could not be verified > > which also talks about Gandi Standard SSL CA. So I wonder why GnuTLS > isn't happy with this, while MS IE is. Am I missing something? Likely for the same reason as Firefox: it knows the certificate(s) which have been used for signing "Gandi Standard SSL CA". In your case, it is "UTN-USERFirst-Hardware". In Firefox, the chain is shown as AddTrust External CA Root UTN-USERFirst-Hardware Gandi Standard SSL CA savannah.gnu.org One hop more ... > (Please be gentle: I know nothing about Internet security and > certificates.) Not a big deal: Every certificate must be signed by another one (certificate authority, or CA), which gives you the trust that this certificate is valid. The CA certificate must be signed ("guarantee that it is true") by another one, and so on. This is called a chain of trust. In order not to create an infinite chain, there are so-called Root CAs, which are "known by default". If any chain ends in such a root certificate, you know that the initial certificate is true. The problem is to distribute and maintain such root certificates. Browsers have them built-in, but I don't believe Emacs (eww) shall do so. Best regards, Michael. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 17:06 ` Michael Albinus @ 2014-12-13 18:01 ` Eli Zaretskii 2014-12-13 19:09 ` Michael Albinus 2014-12-13 19:13 ` Eli Zaretskii 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 18:01 UTC (permalink / raw) To: Michael Albinus; +Cc: emacs-devel > From: Michael Albinus <michael.albinus@gmx.de> > Date: Sat, 13 Dec 2014 18:06:37 +0100 > Cc: emacs-devel@gnu.org > > In order not to create an infinite chain, there are so-called Root CAs, > which are "known by default". If any chain ends in such a root > certificate, you know that the initial certificate is true. > > The problem is to distribute and maintain such root > certificates. Browsers have them built-in, but I don't believe Emacs > (eww) shall do so. GnuTLS on Windows uses the CertEnumCertificatesInStore API to retrieve all the Root and Certification Authority certificates known to the system. I suppose at least IE uses the same API, so I wonder how come GnuTLS fails to validate the certificates, while IE succeeds. I guess some debugging is in order. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 18:01 ` Eli Zaretskii @ 2014-12-13 19:09 ` Michael Albinus 2014-12-13 19:13 ` Eli Zaretskii 1 sibling, 0 replies; 37+ messages in thread From: Michael Albinus @ 2014-12-13 19:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> The problem is to distribute and maintain such root >> certificates. Browsers have them built-in, but I don't believe Emacs >> (eww) shall do so. > > GnuTLS on Windows uses the CertEnumCertificatesInStore API to retrieve > all the Root and Certification Authority certificates known to the > system. I suppose at least IE uses the same API, so I wonder how come > GnuTLS fails to validate the certificates, while IE succeeds. As usual, I cannot speak about MS Windows. But even if IE uses the same API, it might read the root certificates from somewhere else. And like other browsers, it might also carry builtin root certificates inside. Best regards, Michael. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 18:01 ` Eli Zaretskii 2014-12-13 19:09 ` Michael Albinus @ 2014-12-13 19:13 ` Eli Zaretskii 2014-12-13 19:47 ` Ted Zlatanov 1 sibling, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 19:13 UTC (permalink / raw) To: michael.albinus, Ted Zlatanov; +Cc: emacs-devel > Date: Sat, 13 Dec 2014 20:01:59 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > GnuTLS on Windows uses the CertEnumCertificatesInStore API to retrieve > all the Root and Certification Authority certificates known to the > system. I suppose at least IE uses the same API, so I wonder how come > GnuTLS fails to validate the certificates, while IE succeeds. > > I guess some debugging is in order. Ha! It's very simple: we don't call the GnuTLS function that adds system's default trusted CAs to the data used for certificate verification. The simple patch below solves the problem for me. Any objections to installing this? Including on the branch? Ted? What about Posix systems -- won't calling gnutls_certificate_set_x509_system_trust remove the need to load gnutls-trustfiles explicitly for every TLS connection? diff --git a/src/gnutls.c b/src/gnutls.c index ad4d997..bbe5d49 100644 --- a/src/gnutls.c +++ b/src/gnutls.c @@ -103,6 +103,11 @@ enum extra_peer_verification DEF_GNUTLS_FN (int, gnutls_certificate_set_x509_key_file, (gnutls_certificate_credentials_t, const char *, const char *, gnutls_x509_crt_fmt_t)); +#if GNUTLS_VERSION_MAJOR + \ + (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3 +DEF_GNUTLS_FN (int, gnutls_certificate_set_x509_system_trust, + (gnutls_certificate_credentials_t)); +#endif DEF_GNUTLS_FN (int, gnutls_certificate_set_x509_trust_file, (gnutls_certificate_credentials_t, const char *, gnutls_x509_crt_fmt_t)); @@ -227,6 +232,10 @@ enum extra_peer_verification LOAD_GNUTLS_FN (library, gnutls_certificate_set_verify_flags); LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_crl_file); LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_key_file); +#if GNUTLS_VERSION_MAJOR + \ + (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3 + LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_system_trust); +#endif LOAD_GNUTLS_FN (library, gnutls_certificate_set_x509_trust_file); LOAD_GNUTLS_FN (library, gnutls_certificate_type_get); LOAD_GNUTLS_FN (library, gnutls_certificate_verify_peers2); @@ -314,6 +323,10 @@ enum extra_peer_verification #define fn_gnutls_certificate_set_verify_flags gnutls_certificate_set_verify_flags #define fn_gnutls_certificate_set_x509_crl_file gnutls_certificate_set_x509_crl_file #define fn_gnutls_certificate_set_x509_key_file gnutls_certificate_set_x509_key_file +#if GNUTLS_VERSION_MAJOR + \ + (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3 +#define fn_gnutls_certificate_set_x509_system_trust gnutls_certificate_set_x509_system_trust +#endif #define fn_gnutls_certificate_set_x509_trust_file gnutls_certificate_set_x509_trust_file #define fn_gnutls_certificate_type_get gnutls_certificate_type_get #define fn_gnutls_certificate_verify_peers2 gnutls_certificate_verify_peers2 @@ -1308,6 +1321,14 @@ one trustfile (usually a CA bundle). */) int file_format = GNUTLS_X509_FMT_PEM; Lisp_Object tail; +#if GNUTLS_VERSION_MAJOR + \ + (GNUTLS_VERSION_MINOR > 0 || GNUTLS_VERSION_PATCH >= 20) > 3 + ret = fn_gnutls_certificate_set_x509_system_trust (x509_cred); + if (ret < GNUTLS_E_SUCCESS) + GNUTLS_LOG2i (4, max_log_level, "setting system trust failed with code ", + ret); +#endif + for (tail = trustfiles; CONSP (tail); tail = XCDR (tail)) { Lisp_Object trustfile = XCAR (tail); ^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 19:13 ` Eli Zaretskii @ 2014-12-13 19:47 ` Ted Zlatanov 2014-12-13 20:06 ` Eli Zaretskii 0 siblings, 1 reply; 37+ messages in thread From: Ted Zlatanov @ 2014-12-13 19:47 UTC (permalink / raw) To: emacs-devel On Sat, 13 Dec 2014 21:13:50 +0200 Eli Zaretskii <eliz@gnu.org> wrote: EZ> Ha! It's very simple: we don't call the GnuTLS function that adds EZ> system's default trusted CAs to the data used for certificate EZ> verification. The simple patch below solves the problem for me. EZ> Any objections to installing this? Including on the branch? Ted? No problem for me, as long as it works. This function was not available back when we did the first cut of the GnuTLS integration. I'd make it the default, but through the trustfiles list: if the symbol 'system is found in the list, we load the system trust. And that's the default. But the user can add their own trustfiles, as they do now. EZ> What about Posix systems -- won't calling EZ> gnutls_certificate_set_x509_system_trust remove the need to load EZ> gnutls-trustfiles explicitly for every TLS connection? I think the user should be able to customize the trustfiles so the two are not exclusive. I don't know about once-per-connection either, is that a GnuTLS feature with gnutls_certificate_set_x509_system_trust()? Ted ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 19:47 ` Ted Zlatanov @ 2014-12-13 20:06 ` Eli Zaretskii 2014-12-14 0:23 ` Lars Magne Ingebrigtsen 2014-12-14 1:38 ` Ted Zlatanov 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-13 20:06 UTC (permalink / raw) To: emacs-devel > From: Ted Zlatanov <tzz@lifelogs.com> > Date: Sat, 13 Dec 2014 14:47:32 -0500 > > I'd make it the default, but through the trustfiles list: if the symbol > 'system is found in the list, we load the system trust. And that's the > default. But the user can add their own trustfiles, as they do now. What would be the reason for the user to remove 'system from the list? If a user is somehow not happy about system trust data, she should customize her system (if she is authorized), not Emacs. E.g., add a list of blacklisted certificates, remove certificates from the bundle, etc. > EZ> What about Posix systems -- won't calling > EZ> gnutls_certificate_set_x509_system_trust remove the need to load > EZ> gnutls-trustfiles explicitly for every TLS connection? > > I think the user should be able to customize the trustfiles so the two > are not exclusive. To add certificates, I agree. But to remove certificates through Emacs? That sounds backwards to me. > I don't know about once-per-connection either, is that a GnuTLS > feature with gnutls_certificate_set_x509_system_trust()? No, I meant that we do this inside gnutls-boot, which AFAIU is invoked for each new TLS connection. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 20:06 ` Eli Zaretskii @ 2014-12-14 0:23 ` Lars Magne Ingebrigtsen 2014-12-14 1:38 ` Ted Zlatanov 1 sibling, 0 replies; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-14 0:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > What would be the reason for the user to remove 'system from the list? > If a user is somehow not happy about system trust data, she should > customize her system (if she is authorized), not Emacs. Yeah, I agree. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-13 20:06 ` Eli Zaretskii 2014-12-14 0:23 ` Lars Magne Ingebrigtsen @ 2014-12-14 1:38 ` Ted Zlatanov 2014-12-14 3:46 ` Eli Zaretskii 1 sibling, 1 reply; 37+ messages in thread From: Ted Zlatanov @ 2014-12-14 1:38 UTC (permalink / raw) To: emacs-devel On Sat, 13 Dec 2014 22:06:55 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Ted Zlatanov <tzz@lifelogs.com> >> Date: Sat, 13 Dec 2014 14:47:32 -0500 >> >> I'd make it the default, but through the trustfiles list: if the symbol >> 'system is found in the list, we load the system trust. And that's the >> default. But the user can add their own trustfiles, as they do now. EZ> What would be the reason for the user to remove 'system from the list? EZ> If a user is somehow not happy about system trust data, she should EZ> customize her system (if she is authorized), not Emacs. E.g., add a EZ> list of blacklisted certificates, remove certificates from the bundle, EZ> etc. I don't see how it's OK to exclude users who are not authorized to customize their systems. This is a common case. Another case is where the system is out of date and you don't have the option of updating it, because it's too old or the update server is down. There's also the case that you may not want to use the host OS's trust store for your own reasons. That should not be a struggle. Emacs is not a all-in-one web browser, it's a platform. Don't take away the users' choice of who they trust. Furthermore, GnuTLS until recently didn't have this functionality and somehow we survived. So it's not essential. But even if we decide to make 'system the only option, we'd have "if you're running GnuTLS 3.x or older, you'll get this behavior, but with 3.y or newer, another behavior." I think it's pretty unpleasant behavior to dynamically toggle who you trust based on system library versions. So unless we *only* support GnuTLS versions that have this functionality, I'm strongly against making it the only option when it's available. Finally, we have to consider backward compatibility. Users who have customized their trustfiles should not be surprised. We can put warnings in NEWS and blame the users when they don't read them, but I think it's much nicer to preserve the users' customizations. Ted ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-14 1:38 ` Ted Zlatanov @ 2014-12-14 3:46 ` Eli Zaretskii 2014-12-14 8:16 ` Lars Magne Ingebrigtsen 2014-12-14 11:34 ` Ted Zlatanov 0 siblings, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-14 3:46 UTC (permalink / raw) To: emacs-devel > From: Ted Zlatanov <tzz@lifelogs.com> > Date: Sat, 13 Dec 2014 20:38:20 -0500 > > EZ> What would be the reason for the user to remove 'system from the list? > EZ> If a user is somehow not happy about system trust data, she should > EZ> customize her system (if she is authorized), not Emacs. E.g., add a > EZ> list of blacklisted certificates, remove certificates from the bundle, > EZ> etc. > > I don't see how it's OK to exclude users who are not authorized to > customize their systems. This is a common case. If she's not authorized, she doesn't necessarily know what she is doing. This is security, right? > Another case is where the system is out of date and you don't have the > option of updating it, because it's too old or the update server is > down. This case means the user should want to _add_ certificates, not remove the system ones. > There's also the case that you may not want to use the host OS's trust > store for your own reasons. That should not be a struggle. Emacs is > not a all-in-one web browser, it's a platform. Don't take away the > users' choice of who they trust. No other browser I know of allows that. > Furthermore, GnuTLS until recently didn't have this functionality and > somehow we survived. So it's not essential. We survived because we do the equivalent by reading gnutls-trustfiles. > But even if we decide to make 'system the only option That's not my suggestion. My suggestion is always to use system trust (when it's available), and in addition allow the user to customize gnutls-trustfiles. The only issue is whether to have 'system' in gnutls-trustfiles and allow its removal. > we'd have "if you're running GnuTLS 3.x or older, you'll get this > behavior, but with 3.y or newer, another behavior." Yes, and why is that a problem? Differences in behavior in different versions exist whether we want it or not. > I think it's pretty unpleasant behavior to dynamically toggle who > you trust based on system library versions. So unless we *only* > support GnuTLS versions that have this functionality, I'm strongly > against making it the only option when it's available. > > Finally, we have to consider backward compatibility. Users who have > customized their trustfiles should not be surprised. We can put > warnings in NEWS and blame the users when they don't read them, but I > think it's much nicer to preserve the users' customizations. Fine. I'm going to make this a Windows-only code, and we can then stop arguing. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-14 3:46 ` Eli Zaretskii @ 2014-12-14 8:16 ` Lars Magne Ingebrigtsen 2014-12-14 16:04 ` Eli Zaretskii 2014-12-14 11:34 ` Ted Zlatanov 1 sibling, 1 reply; 37+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-12-14 8:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> There's also the case that you may not want to use the host OS's trust >> store for your own reasons. That should not be a struggle. Emacs is >> not a all-in-one web browser, it's a platform. Don't take away the >> users' choice of who they trust. > > No other browser I know of allows that. In Firefox, it's edit->preferences->advanced->certificates, and you can remove any CAs you want there. Not that I've ever heard of anybody using that. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-14 8:16 ` Lars Magne Ingebrigtsen @ 2014-12-14 16:04 ` Eli Zaretskii 2014-12-19 12:14 ` Lars Ingebrigtsen 0 siblings, 1 reply; 37+ messages in thread From: Eli Zaretskii @ 2014-12-14 16:04 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: emacs-devel > From: Lars Magne Ingebrigtsen <larsi@gnus.org> > Cc: emacs-devel@gnu.org > Date: Sun, 14 Dec 2014 09:16:01 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> There's also the case that you may not want to use the host OS's trust > >> store for your own reasons. That should not be a struggle. Emacs is > >> not a all-in-one web browser, it's a platform. Don't take away the > >> users' choice of who they trust. > > > > No other browser I know of allows that. > > In Firefox, it's edit->preferences->advanced->certificates, and you can > remove any CAs you want there. Yes, I know. But that's one certificate at a time. The equivalent would be to add a certificate to a blacklist, or remove its file from the certificate directory. What I meant is a check-box saying "disregard all system-wide certificates" or some such. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-14 16:04 ` Eli Zaretskii @ 2014-12-19 12:14 ` Lars Ingebrigtsen 2014-12-19 14:41 ` Eli Zaretskii 2014-12-19 19:53 ` Simon Leinen 0 siblings, 2 replies; 37+ messages in thread From: Lars Ingebrigtsen @ 2014-12-19 12:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Yes, I know. But that's one certificate at a time. The equivalent > would be to add a certificate to a blacklist, or remove its file from > the certificate directory. > > What I meant is a check-box saying "disregard all system-wide > certificates" or some such. To the best of my knowledge, no other browsers use the system's certificates. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-19 12:14 ` Lars Ingebrigtsen @ 2014-12-19 14:41 ` Eli Zaretskii 2014-12-19 16:42 ` Ivan Shmakov 2014-12-19 16:47 ` Lars Ingebrigtsen 2014-12-19 19:53 ` Simon Leinen 1 sibling, 2 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-19 14:41 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > From: Lars Ingebrigtsen <larsi@gnus.org> > Cc: emacs-devel@gnu.org > Date: Fri, 19 Dec 2014 13:14:51 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Yes, I know. But that's one certificate at a time. The equivalent > > would be to add a certificate to a blacklist, or remove its file from > > the certificate directory. > > > > What I meant is a check-box saying "disregard all system-wide > > certificates" or some such. > > To the best of my knowledge, no other browsers use the system's > certificates. If they go to /etc/ssl/ on Posix hosts, then they do. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-19 14:41 ` Eli Zaretskii @ 2014-12-19 16:42 ` Ivan Shmakov 2014-12-19 16:47 ` Lars Ingebrigtsen 1 sibling, 0 replies; 37+ messages in thread From: Ivan Shmakov @ 2014-12-19 16:42 UTC (permalink / raw) To: emacs-devel >>>>> Eli Zaretskii <eliz@gnu.org> writes: >>>>> From: Lars Ingebrigtsen Date: Fri, 19 Dec 2014 13:14:51 +0100 >>>>> Eli Zaretskii <eliz@gnu.org> writes: >>> What I meant is a check-box saying "disregard all system-wide >>> certificates" or some such. >> To the best of my knowledge, no other browsers use the system's >> certificates. > If they go to /etc/ssl/ on Posix hosts, then they do. Unless I be mistaken, the newer versions of Firefox (as in: Debian testing) no longer do that, relying instead on something called “Network Security Service.” [1] [1] http://www.mozilla.org/projects/security/pki/nss/ -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-19 14:41 ` Eli Zaretskii 2014-12-19 16:42 ` Ivan Shmakov @ 2014-12-19 16:47 ` Lars Ingebrigtsen 1 sibling, 0 replies; 37+ messages in thread From: Lars Ingebrigtsen @ 2014-12-19 16:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > If they go to /etc/ssl/ on Posix hosts, then they do. They don't. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-19 12:14 ` Lars Ingebrigtsen 2014-12-19 14:41 ` Eli Zaretskii @ 2014-12-19 19:53 ` Simon Leinen 2014-12-19 21:37 ` Eli Zaretskii 1 sibling, 1 reply; 37+ messages in thread From: Simon Leinen @ 2014-12-19 19:53 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel On Fri, Dec 19, 2014 at 1:14 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote: > To the best of my knowledge, no other browsers use the system's > certificates. I am forced to use Mac OS X at work. (Yes, I know, I should look for another job.) All browsers *except* for Firefox do use the system's certificate store ("Keychain"). This makes it quite convenient for the user to manage which kinds of certificates she wants to trust. I'd like Emacs' emerging TLS support to be able to access the same. Unfortunately I don't have the cycles to do this - and I understand that the willingness of others to support this non-free system may be low. -- Simon. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-19 19:53 ` Simon Leinen @ 2014-12-19 21:37 ` Eli Zaretskii 0 siblings, 0 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-19 21:37 UTC (permalink / raw) To: Simon Leinen; +Cc: larsi, emacs-devel > From: Simon Leinen <simon.leinen@gmail.com> > Date: Fri, 19 Dec 2014 20:53:31 +0100 > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org > > On Fri, Dec 19, 2014 at 1:14 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote: > > To the best of my knowledge, no other browsers use the system's > > certificates. > > I am forced to use Mac OS X at work. (Yes, I know, I should look for > another job.) All browsers *except* for Firefox do use the system's > certificate store ("Keychain"). This makes it quite convenient for > the user to manage which kinds of certificates she wants to trust. I'd > like Emacs' emerging TLS support to be able to access the same. It already does -- assuming that GnuTLS on OS X reads that store when we call the gnutls_certificate_set_x509_system_trust function. If not, then you should lobby the GnuTLS developers to make GnuTLS do that on OS X. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-14 3:46 ` Eli Zaretskii 2014-12-14 8:16 ` Lars Magne Ingebrigtsen @ 2014-12-14 11:34 ` Ted Zlatanov 2014-12-14 12:52 ` Michael Albinus 2014-12-14 16:53 ` Eli Zaretskii 1 sibling, 2 replies; 37+ messages in thread From: Ted Zlatanov @ 2014-12-14 11:34 UTC (permalink / raw) To: emacs-devel On Sun, 14 Dec 2014 05:46:15 +0200 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Ted Zlatanov <tzz@lifelogs.com> >> Date: Sat, 13 Dec 2014 20:38:20 -0500 >> EZ> What would be the reason for the user to remove 'system from the list? EZ> If a user is somehow not happy about system trust data, she should EZ> customize her system (if she is authorized), not Emacs. E.g., add a EZ> list of blacklisted certificates, remove certificates from the bundle, EZ> etc. >> >> I don't see how it's OK to exclude users who are not authorized to >> customize their systems. This is a common case. EZ> If she's not authorized, she doesn't necessarily know what she is EZ> doing. This is security, right? The authentication and authorization structure of the host system targets different risks. I've often had the need to build and install binaries or dynamically updated external package systems like oh-my-zsh for instance. Even when I was the host system's manager, it didn't always make sense to make system-level changes to accommodate one user's preferences and needs. >> Another case is where the system is out of date and you don't have the >> option of updating it, because it's too old or the update server is >> down. EZ> This case means the user should want to _add_ certificates, not remove EZ> the system ones. There have been several cases where users wanted to remove certificates signed by a compromised certificate authority before updated CA certificate OS packages were available. Sometimes a few hours can be critical in these situations. While CRL support is a good way to deal with this in general, I still think giving the user the option to manage their trustfiles is valuable. But we should definitely try to support CRLs or DANE more urgently, rather than expecting the user to manage trustfiles and certificate revocations. >> But even if we decide to make 'system the only option EZ> That's not my suggestion. My suggestion is always to use system trust EZ> (when it's available), and in addition allow the user to customize EZ> gnutls-trustfiles. The only issue is whether to have 'system' in EZ> gnutls-trustfiles and allow its removal. OK, sorry, I was arguing with a straw man. I think there's a better approach, below... EZ> Fine. I'm going to make this a Windows-only code, and we can then EZ> stop arguing. Please add the code unconditionally as you planned. I think it will be an improvement that way. I will then add code to make the transition easier after your patch: * add a featurep or a function to GnuTLS that tells us if that system function is available * when it's available, default the trustfiles to nil * when it's not available, use the old trustfiles default * add a specific boolean option to disable that system function, off by default * improve messaging to tell the user what trustfiles we're loading * update NEWS, docs, etc. I hope that's more agreeable. Ted ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-14 11:34 ` Ted Zlatanov @ 2014-12-14 12:52 ` Michael Albinus 2014-12-14 16:53 ` Eli Zaretskii 1 sibling, 0 replies; 37+ messages in thread From: Michael Albinus @ 2014-12-14 12:52 UTC (permalink / raw) To: emacs-devel Ted Zlatanov <tzz@lifelogs.com> writes: > While CRL support is a good way to deal with this in general, I still > think giving the user the option to manage their trustfiles is valuable. > But we should definitely try to support CRLs or DANE more urgently, > rather than expecting the user to manage trustfiles and certificate > revocations. CRLs are a good thing, in theory. But they work only when you are online, and when you are able to retrieve a proper CRL from the CA. If the CA is blocked by whatever means, CRLs don't work. DANE uses an indepedent way in order to give you trust into a given certificate (via DNSSec). However, I don't know how much it is supported already, by both the servers and by gnutls as client. I do not object to support CRLs and DANE, but we shouldn't expect perfect trust then. > Ted Best regards, Michael. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: NSM certificate prompt 2014-12-14 11:34 ` Ted Zlatanov 2014-12-14 12:52 ` Michael Albinus @ 2014-12-14 16:53 ` Eli Zaretskii 1 sibling, 0 replies; 37+ messages in thread From: Eli Zaretskii @ 2014-12-14 16:53 UTC (permalink / raw) To: emacs-devel > From: Ted Zlatanov <tzz@lifelogs.com> > Date: Sun, 14 Dec 2014 06:34:32 -0500 > > Please add the code unconditionally as you planned. I think it will be > an improvement that way. Done in e99ce63 on master. > I will then add code to make the transition easier after your patch: > > * add a featurep or a function to GnuTLS that tells us if that system > function is available > > * when it's available, default the trustfiles to nil > > * when it's not available, use the old trustfiles default > > * add a specific boolean option to disable that system function, off by default Please mention in the docstring of that option that disabling the system function on MS-Windows requires the user to install a certificate bundle and point gnutls-trustfiles to the place where it is installed. > * improve messaging to tell the user what trustfiles we're loading > > * update NEWS, docs, etc. > > I hope that's more agreeable. Yes, thanks in advance. ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2014-12-19 21:37 UTC | newest] Thread overview: 37+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-12-13 14:43 NSM certificate prompt Eli Zaretskii 2014-12-13 15:12 ` Lars Magne Ingebrigtsen 2014-12-13 16:01 ` Eli Zaretskii 2014-12-13 16:04 ` Lars Magne Ingebrigtsen 2014-12-13 16:46 ` Eli Zaretskii 2014-12-13 17:27 ` Lars Magne Ingebrigtsen 2014-12-13 15:27 ` Michael Albinus 2014-12-13 15:35 ` Lars Magne Ingebrigtsen 2014-12-13 16:57 ` Michael Albinus 2014-12-13 17:06 ` Eli Zaretskii 2014-12-13 17:29 ` Lars Magne Ingebrigtsen 2014-12-13 18:03 ` Eli Zaretskii 2014-12-13 18:06 ` Lars Magne Ingebrigtsen 2014-12-13 19:16 ` Michael Albinus 2014-12-13 20:02 ` Ted Zlatanov 2014-12-13 16:03 ` Eli Zaretskii 2014-12-13 16:39 ` Eli Zaretskii 2014-12-13 17:06 ` Michael Albinus 2014-12-13 18:01 ` Eli Zaretskii 2014-12-13 19:09 ` Michael Albinus 2014-12-13 19:13 ` Eli Zaretskii 2014-12-13 19:47 ` Ted Zlatanov 2014-12-13 20:06 ` Eli Zaretskii 2014-12-14 0:23 ` Lars Magne Ingebrigtsen 2014-12-14 1:38 ` Ted Zlatanov 2014-12-14 3:46 ` Eli Zaretskii 2014-12-14 8:16 ` Lars Magne Ingebrigtsen 2014-12-14 16:04 ` Eli Zaretskii 2014-12-19 12:14 ` Lars Ingebrigtsen 2014-12-19 14:41 ` Eli Zaretskii 2014-12-19 16:42 ` Ivan Shmakov 2014-12-19 16:47 ` Lars Ingebrigtsen 2014-12-19 19:53 ` Simon Leinen 2014-12-19 21:37 ` Eli Zaretskii 2014-12-14 11:34 ` Ted Zlatanov 2014-12-14 12:52 ` Michael Albinus 2014-12-14 16:53 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.