From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nikos Mavrogiannopoulos Newsgroups: gmane.emacs.devel,gmane.comp.encryption.gpg.gnutls.devel Subject: Re: Emacs core TLS support Date: Tue, 14 Sep 2010 20:55:51 +0200 Message-ID: <4C8FC537.2020207@gnutls.org> References: <878wc1vfh3.fsf@lifelogs.com> <87r5ptpnz2.fsf@stupidchicken.com> <871vhsvkut.fsf@lifelogs.com> <87d41csktn.fsf@lifelogs.com> <87k4v0n0m8.fsf@lifelogs.com> <87wrrvfnc4.fsf@lifelogs.com> <87r5i2d00q.fsf@lifelogs.com> <87zkwqijye.fsf@stupidchicken.com> <878w4actmg.fsf@lifelogs.com> <877hju123h.fsf@stupidchicken.com> <8762yklrdk.fsf@lifelogs.com> <87wrqzhrjv.fsf@lifelogs.com> <87fwxmihyz.fsf@lifelogs.com> <8762ycfhqo.fsf@lifelogs.com> <8739tcch48.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1284490637 3486 80.91.229.12 (14 Sep 2010 18:57:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 14 Sep 2010 18:57:17 +0000 (UTC) Cc: gnutls-devel@gnu.org, emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 14 20:57:13 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ovag0-0001l6-GG for ged-emacs-devel@m.gmane.org; Tue, 14 Sep 2010 20:57:07 +0200 Original-Received: from localhost ([127.0.0.1]:37101 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ovafn-0006tH-6D for ged-emacs-devel@m.gmane.org; Tue, 14 Sep 2010 14:56:07 -0400 Original-Received: from [140.186.70.92] (port=57176 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ovaff-0006pz-7Q for emacs-devel@gnu.org; Tue, 14 Sep 2010 14:56:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ovafd-000291-Q1 for emacs-devel@gnu.org; Tue, 14 Sep 2010 14:55:58 -0400 Original-Received: from mail-ew0-f41.google.com ([209.85.215.41]:55166) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvafZ-00027n-Oj; Tue, 14 Sep 2010 14:55:53 -0400 Original-Received: by ewy28 with SMTP id 28so3912172ewy.0 for ; Tue, 14 Sep 2010 11:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=quFMe7kNekKVaLWVz0pGx7Ehv8InAwE8NALmABxVn+k=; b=RY1EikCsUTX727P+hagELAne/e5LyWYHjPXpaITR+0Ek/0EzuFxoVR2iiZ2E3YfGYq P4RLSZAjSOnJKDR65ZavU0hGgSvQECJ4SS2LlMk3Ipv3TA+sN6JmK9Zz3pyyEVBDo064 XRiG9N4ZsI9szPFxuZtQr2t9O4+rynRbJOv5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=rhtSPDjX6pQ3hzw2fH1GjGI/4eEdiKRx4CcBUgrwNJxopnfEQHiDjXXaIG3GU4QxXv vDhGhTIzX2B8thDf7O/l+te1DRjAfTLNQVduZfh5hi5/Fq0Hl4VbW+yWAYVDZkDf3Y+j 0FVLlcbifrBQMvcAf5dX2dvxQ+kUk+qSNbghk= Original-Received: by 10.213.106.7 with SMTP id v7mr374461ebo.31.1284490552569; Tue, 14 Sep 2010 11:55:52 -0700 (PDT) Original-Received: from [10.100.2.14] (78-23-65-223.access.telenet.be [78.23.65.223]) by mx.google.com with ESMTPS id u9sm699533eeh.5.2010.09.14.11.55.50 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Sep 2010 11:55:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826 Thunderbird/3.0.7 In-Reply-To: <8739tcch48.fsf@lifelogs.com> X-Enigmail-Version: 1.0.1 OpenPGP: id=96865171 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130143 gmane.comp.encryption.gpg.gnutls.devel:4508 Archived-At: On 09/14/2010 08:30 PM, Ted Zlatanov wrote: > On Mon, 13 Sep 2010 09:49:30 +0200 Nikos Mavrogiannopoulos wrote: > > NM> 2010/9/11 Ted Zlatanov : >>> - no SRP anywhere, just anon and x509 (I'll add SRP if we need it and >>> when the other two are working) >>> Now I get GNUTLS_E_INSUFFICIENT_CREDENTIALS when I open a x509 >>> connection to an IMAP TLS server so I think there's still work to do. >>> The trust file seems to be wrong (see lisp/net/gnutls.el, I tried both >>> "/etc/ssl/certs/ca-certificates.crt" and "/etc/ssl/certs/ca.pem"). >>> The GnuTLS examples don't seem to cover the standard situation of >>> talking to a web server over SSL and possibly accepting an insecure >>> connection if the server credentials are bad. I must have missed >>> something. Could the GnuTLS developers look at my patch and help me >>> out? > NM> I cannot look at the patch but the example you are looking for is: > NM> http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support > NM> to do the connection, and this one to verify the certificate: > NM> http://www.gnu.org/software/gnutls/manual/html_node/Verifying-peer_0027s-certificate.html#Verifying-peer_0027s-certificate > > What ca.pem should I use? There's one in GnuTLS and one in > /etc/ssl/certs/ca.pem on my Ubuntu system. It should Just Work so it > may make sense to ship ca.pem with Emacs. WDYT? This is local policy, I don't think that it has to be shipped with emacs. Just give the option of someone specifying it. > The simple client code is implemented in my current patch. Without > verifying anything I keep getting GNUTLS_E_AGAIN when I try to handshake > against an SSL server. See gnutls-boot, the control flow is really > simple and I think correct. What am I missing? GNUTLS_E_AGAIN is returned only if the transport layer function (recv/send) return -1 and EAGAIN. Usually this is normal behavior and is enough to loop around them. Do you use non-blocking IO? regards, Nikos