From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.bugs Subject: bug#24075: tls/https support in Guile (through r6rs binary ports?) Date: Sun, 06 Nov 2016 22:13:51 +0100 Message-ID: <87oa1sxqeo.fsf@gnu.org> References: <8760rss8al.fsf@dustycloud.org> <87a8gstgn6.fsf@pobox.com> <878tvqqfkq.fsf@dustycloud.org> <87r36p6aaz.fsf@dustycloud.org> <87fun56987.fsf@gnu.org> <87lgww5x1y.fsf@dustycloud.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1478466937 1188 195.159.176.226 (6 Nov 2016 21:15:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 6 Nov 2016 21:15:37 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: 24075@debbugs.gnu.org To: Christopher Allan Webber Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sun Nov 06 22:15:33 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3UmU-0005Te-F2 for guile-bugs@m.gmane.org; Sun, 06 Nov 2016 22:15:10 +0100 Original-Received: from localhost ([::1]:47843 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3UmX-0007w9-Dm for guile-bugs@m.gmane.org; Sun, 06 Nov 2016 16:15:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3UmR-0007tm-Br for bug-guile@gnu.org; Sun, 06 Nov 2016 16:15:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3UmM-0003xb-Qe for bug-guile@gnu.org; Sun, 06 Nov 2016 16:15:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60006) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c3UmM-0003xV-ME for bug-guile@gnu.org; Sun, 06 Nov 2016 16:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c3UmM-0006Yw-Gy for bug-guile@gnu.org; Sun, 06 Nov 2016 16:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 06 Nov 2016 21:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24075 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 24075-submit@debbugs.gnu.org id=B24075.147846684625135 (code B ref 24075); Sun, 06 Nov 2016 21:15:02 +0000 Original-Received: (at 24075) by debbugs.gnu.org; 6 Nov 2016 21:14:06 +0000 Original-Received: from localhost ([127.0.0.1]:47172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3UlR-0006XL-Ts for submit@debbugs.gnu.org; Sun, 06 Nov 2016 16:14:06 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c3UlP-0006Wi-Ga for 24075@debbugs.gnu.org; Sun, 06 Nov 2016 16:14:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3UlF-00030T-PG for 24075@debbugs.gnu.org; Sun, 06 Nov 2016 16:13:58 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3UlF-00030I-Lk; Sun, 06 Nov 2016 16:13:53 -0500 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]:50828 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1c3UlE-0000H2-Qw; Sun, 06 Nov 2016 16:13:53 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 16 Brumaire an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87lgww5x1y.fsf@dustycloud.org> (Christopher Allan Webber's message of "Sun, 06 Nov 2016 11:37:45 -0600") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8452 Archived-At: Christopher Allan Webber skribis: > Ludovic Court=C3=A8s writes: > >>> +(define (ensure-gnutls) >>> + (if (not (force gnutls-module)) >>> + (throw 'gnutls-not-available "(gnutls) module not available"))) >> >> I wonder if this is the right exception, but I can=E2=80=99t think of an= ything >> better (there=E2=80=99s no generic =E2=80=9Cnot supported=E2=80=9D excep= tion I think; (throw >> 'system-error =E2=80=A6 ENOSYS) would do that but it=E2=80=99s too vague= .) > > I don't know... it's hard for me to tell when to use what exception > symbol in Guile! > > I prefer specific exceptions when a more general exception Yes, I agree. I was just wondering out loud whether there might be another exception. Anyway, this one=E2=80=99s fine! >> What about leaving the =E2=80=98ensure-gnutls=E2=80=99 call and then sim= ply use the >> GnuTLS symbols directly and rely on autoloading, as in (guix build >> download)? >> >> --8<---------------cut here---------------start------------->8--- >> ;; Autoload GnuTLS so that this module can be used even when GnuTLS is >> ;; not available. At compile time, this yields "possibly unbound >> ;; variable" warnings, but these are OK: we know that the variables will >> ;; be bound if we need them, because (guix download) adds GnuTLS as an >> ;; input in that case. >> >> ;; XXX: Use this hack instead of #:autoload to avoid compilation errors. >> ;; See . >> (module-autoload! (current-module) >> '(gnutls) '(make-session connection-end/client)) >> --8<---------------cut here---------------end--------------->8--- >> >> That would lead more concise and slightly more efficient code, and I >> think it would still work as expected in the absence of (gnutls). >> >> WDYT? > > So there was this converstaion on #guile: > > mark_weaver: the autoload hack fails gracelessly when GnuTLS = is=20=20=20=20=20=20=20 > missing > that's fine in the context of Guix, but maybe not in a more g= eneral=20=20=20 > context > oh :) > civodul: what approach would you suggest then? > civodul: could we make it more graceful? > yeah maybe with some explicit module hackery > an explicit resolve-interface + module-ref > something like that > sounds doable > > So... that's what lead me to change it. > > Admittedly I'm not totally clear what was meant by "the autoload hack > fails gracelessly", and what would be more graceful. Would it be > because it's trying to utilize a symbol that's not bound to anything? > > Which leads to the next question: if I did the autoload hack, what would > (ensure-gnutls) look like? Sorry for the confusing statements. :-) I think =E2=80=98ensure-gnutls=E2=80=99 would be exactly as in this patch, = and the autoload hack would be exactly as shown above. Here it would fail =E2=80=9Cgracefully=E2=80=9D in the sense that =E2=80=98= ensure-gnutls=E2=80=99 would catch a potential problem early on and raise the =E2=80=98gnutls-not-availa= ble=E2=80=99 exception (you=E2=80=99d have to double-check that this is indeed the behav= ior we get, but I=E2=80=99m quite confident ;-)). In (guix build download) there=E2=80=99s no such protection so when (gnutls= ) is missing, users get an unbound variable right in the middle of the code. >>> + (define (read! bv start count) >>> + (define read-bv (get-bytevector-n record count)) >>> + (define read-bv-len (bytevector-length read-bv)) >>> + (bytevector-copy! read-bv 0 bv 0 read-bv-len) >>> + read-bv-len) >> >> Beware: =E2=80=98get-bytevector-n=E2=80=99 can return the EOF object ins= tead of a >> number, so you need to check for that. (Conversely, =E2=80=98read!=E2= =80=99 needs to >> return 0 to indicate EOF.) > > So that would look like this? > > (define (read! bv start count) > (define read-bv (get-bytevector-n record count)) > (if (eof-object? read-bv) > 0 > (let ((read-bv-len (bytevector-length read-bv))) > (bytevector-copy! read-bv 0 bv 0 read-bv-len) > read-bv-len))) Exactly. >>> + (define (open-socket) >>> + (let loop ((addresses addresses)) >> >> Or just =E2=80=9C(define sock =E2=80=A6=E2=80=9D. > > Hm, is that a good idea? Does this need to happen before or within the > with-https-proxy? Oh you=E2=80=99re right, sorry. > From 91c0a4a728ca4bf2e9468cdc849c350dd3f7380f Mon Sep 17 00:00:00 2001 > From: Christopher Allan Webber > Date: Thu, 17 Sep 2015 15:14:54 -0500 > Subject: [PATCH] web: Add https support through gnutls. > > Since importing gnutls directly would result in a dependency cycle, > we load gnutls lazily. > > This uses code originally written for Guix by Ludovic > > * module/web/client.scm: (%http-receive-buffer-size) > (warn-no-gnutls-return-false, gnutls-module, ensure-gnutls) > (gnutls-ref, tls-wrap): New variables. > (open-socket-for-uri): Wrap in tls when uri scheme is https. > * doc/ref/web.texi (open-socket-for-uri): Document gnutls usage. [...] > @deffn {Scheme Procedure} open-socket-for-uri uri > -Return an open input/output port for a connection to URI. > +Return an open input/output port for a connection to URI. Guile > +dynamically loads gnutls for https support; for more information, see > +@xref{Guile Preparations, > +how to install the GnuTLS bindings for Guile,, gnutls-guile, > +GnuTLS-Guile}. @xref generates a =E2=80=9CSee=E2=80=9D for the beginning of a sentence, so= it should be: =E2=80=A6 support. @xref{=E2=80=A6}, for more information. Also, =E2=80=9CHTTPS=E2=80=9D and =E2=80=9CGnuTLS=E2=80=9D. :-) The rest is all good for me, so the only remaining bits are the autoload thing and maybe the bug you observed? Thanks! Ludo=E2=80=99.