IRC channel logs

<mark_weaver>surprisingly, the https URL I used for archive.apache.org doesn't work, because some TLS error happens right at the end of the download.

<mark_weaver>I lost the exact output, and am now doing an guix package --upgrade that I'd rather not interrupt.

<mark_weaver>ah, just finished.. let's see.

<mark_weaver>wget on Debian wheezy works properly, and is also linked with gnutls (2.12.20)

<civodul>hey mark_weaver!

<civodul>oh, weird

<civodul>it's not the same GnuTLS though

<civodul>because it's built in a derivation, that uses "our" GnuTLS

<mark_weaver>I just tried, and the wget from guix also works.

<civodul>ok

<mark_weaver>maybe wget is ignoring that particular TLS error, dunno.

*civodul tries

<civodul>i can reproduce it

<mark_weaver>I see something about it on this page: http://download.opensuse.org/distribution/12.1/repo/oss/ChangeLog

<mark_weaver>For glib-networking update to version 2.29.92, it says "Fixed a problem when linking against GNUTLS 3.0, where connections would sometimes return the error "The TLS connection was non-properly terminated". (bgo#659233)"

<mark_weaver>I'm not sure what bug tracking system that bug number is in.

<civodul>the rationale is discussed at http://comments.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/4842

<mark_weaver> https://bugzilla.gnome.org/show_bug.cgi?id=659233

<mark_weaver>well, I suppose we could just use plain http for that URL.

<civodul>sure :-)

<civodul>though the problem is worth fixing

<mark_weaver>is it a problem on our end, or on the apache archive server?

<mark_weaver>given that we will check the SHAsum on the downloaded file, I suppose there's no harm in ignoring that error for downloads, in any case.

<civodul>yes, that's what i was thinking

<civodul>but it's actually tricky to ignore

<civodul>because we pass a TLS port to the download code

<mark_weaver>here's what glib-networking did, fwiw: https://bug659233.bugzilla-attachments.gnome.org/attachment.cgi?id=196741

<mark_weaver>I don't yet understand the issues well enough to know what's the right solution.

<civodul>it really seems the server is closing the connection without sending a TLS goodbye packet

<civodul>which is impolite

<mark_weaver>if the server is violating the relevant standard, my instinct would be to remain strict on our end unless the bad server behavior is widespread.

<civodul>yeah

<civodul>here's a plan: we ignore it in Guix for now, and i change the GnuTLS session-record port code to ignore it

<civodul>because what matters is that the report returns the EOF object

<mark_weaver>I'm not sure what code you're talking about. If you mean to ignore the error in the general-purpose guile-gnutls code, that makes me nervous.

<mark_weaver>though I confess I don't fully understand the issues.

<mark_weaver>if you mean to ignore it only for purpose of downloads, then I guess that's fine, since the SHAsum will be checked anyway.

<mark_weaver>I think it's become fairly clear that Postel's idea that one should be permissive in what one accepts has turned out to be a bad idea. It tends to result in widespread violations of the standards, as happened in the world wide web.

IRC channel logs

2013-06-08.log