[bug#29046] [PATCH] gnu: linux-libre: Update to 4.13.10 and change URL to HTTPS.

[bug#29046] [PATCH] gnu: linux-libre: Update to 4.13.10 and change URL to HTTPS.

[Rutger Helling]

[-- Attachment #1.1: Type: text/plain, Size: 77 bytes --]

Hey Guix, 

here's a patch to update linux-libre and change the URL to HTTPS.

[-- Attachment #1.2: Type: text/html, Size: 270 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-linux-libre-Update-to-4.13.10-and-change-URL-to-.patch --]
[-- Type: text/x-diff; name=0001-gnu-linux-libre-Update-to-4.13.10-and-change-URL-to-.patch, Size: 1505 bytes --]

From 3faa493a607907d6fb571e6c0e3eb391af7a5aec Mon Sep 17 00:00:00 2001
From: Rutger Helling <rhelling@mykolab.com>
Date: Sat, 28 Oct 2017 22:36:16 +0200
Subject: [PATCH] gnu: linux-libre: Update to 4.13.10 and change URL to HTTPS.

* gnu/packages/linux.scm (linux-libre): Update to 4.13.10 and change URL to HTTPS.
---
 gnu/packages/linux.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 49665e24d..831c26884 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -140,7 +140,7 @@ defconfig.  Return the appropiate make target if applicable, otherwise return
 (define (linux-libre-urls version)
   "Return a list of URLs for Linux-Libre VERSION."
   (list (string-append
-         "http://linux-libre.fsfla.org/pub/linux-libre/releases/"
+         "https://linux-libre.fsfla.org/pub/linux-libre/releases/"
          version "-gnu/linux-libre-" version "-gnu.tar.xz")
 
         ;; XXX: Work around <http://bugs.gnu.org/14851>.
@@ -368,8 +368,8 @@ It has been modified to remove all non-free binary blobs.")
 
 (define %intel-compatible-systems '("x86_64-linux" "i686-linux"))
 
-(define %linux-libre-version "4.13.9")
-(define %linux-libre-hash "1ymsdvm4djh7hg2wmn2v11w380i0ss9nkp4slfrgihdvn6yp5gbv")
+(define %linux-libre-version "4.13.10")
+(define %linux-libre-hash "0y1p5b1rxpbr3apvqqv589qwzfyzjpdrzysfj4h17s0k4gy6c5p8")
 
 (define-public linux-libre
   (make-linux-libre %linux-libre-version
-- 
2.14.3

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Rutger Helling]

[-- Attachment #1.1: Type: text/plain, Size: 96 bytes --]

I noticed linux-libre had already been updated, so this new patch only
changes the URL to HTTPS.

[-- Attachment #1.2: Type: text/html, Size: 283 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-linux-libre-Change-URL-to-HTTPS.patch --]
[-- Type: text/x-diff; name=0001-gnu-linux-libre-Change-URL-to-HTTPS.patch, Size: 985 bytes --]

From b68a2c630258324628a7ef34005ff1d790a3a139 Mon Sep 17 00:00:00 2001
From: Rutger Helling <rhelling@mykolab.com>
Date: Mon, 30 Oct 2017 08:02:10 +0100
Subject: [PATCH] gnu: linux-libre: Change URL to HTTPS.

* gnu/packages/linux.scm (linux-libre): Change URL to HTTPS.
---
 gnu/packages/linux.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 8a817df34..6315b674c 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -140,7 +140,7 @@ defconfig.  Return the appropiate make target if applicable, otherwise return
 (define (linux-libre-urls version)
   "Return a list of URLs for Linux-Libre VERSION."
   (list (string-append
-         "http://linux-libre.fsfla.org/pub/linux-libre/releases/"
+         "https://linux-libre.fsfla.org/pub/linux-libre/releases/"
          version "-gnu/linux-libre-" version "-gnu.tar.xz")
 
         ;; XXX: Work around <http://bugs.gnu.org/14851>.
-- 
2.14.3

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Mon, Oct 30, 2017 at 08:06:39AM +0100, Rutger Helling wrote:
> I noticed linux-libre had already been updated, so this new patch only
> changes the URL to HTTPS.

> From b68a2c630258324628a7ef34005ff1d790a3a139 Mon Sep 17 00:00:00 2001
> From: Rutger Helling <rhelling@mykolab.com>
> Date: Mon, 30 Oct 2017 08:02:10 +0100
> Subject: [PATCH] gnu: linux-libre: Change URL to HTTPS.
> 
> * gnu/packages/linux.scm (linux-libre): Change URL to HTTPS.

Hi! Thanks for paying attention to the linux-libre packages.

I'm copying Mark on this email, since he typically handles the
linux-libre packages. Mark, what do you think of this change?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Mark H Weaver]

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> On Mon, Oct 30, 2017 at 08:06:39AM +0100, Rutger Helling wrote:
>> I noticed linux-libre had already been updated, so this new patch only
>> changes the URL to HTTPS.
>
>> From b68a2c630258324628a7ef34005ff1d790a3a139 Mon Sep 17 00:00:00 2001
>> From: Rutger Helling <rhelling@mykolab.com>
>> Date: Mon, 30 Oct 2017 08:02:10 +0100
>> Subject: [PATCH] gnu: linux-libre: Change URL to HTTPS.
>> 
>> * gnu/packages/linux.scm (linux-libre): Change URL to HTTPS.
>
> Hi! Thanks for paying attention to the linux-libre packages.
>
> I'm copying Mark on this email, since he typically handles the
> linux-libre packages. Mark, what do you think of this change?

Thanks for bringing this to my attention.

I'm not strongly opposed to it, but in general, I'm not sure I
understand the rationale for changing source URLs to use HTTPS.  We
already verify the authenticity of the downloaded file by SHA256 hash,
and verify the GPG signature when updating to a new version.  Both of
these are far stronger than HTTPS, which in practice can be subverted by
compromising *any* certificate authority listed in our trust database
(in Mozilla NSS).

HTTPS also fails to hide from an evesdropper which file was downloaded,
because in practice that can be determined by the amount of data
transferred.

So, unless I'm mistaken, HTTPS doesn't provide any benefit to us here.
On the other hand, using HTTPS entails using more complex code to
download the files, which exposes a much larger attack surface that
might be exploited to compromise our systems.  Many security flaws have
been uncovered in TLS libraries over the years.  Using HTTPS also adds
more load on the server.

In summary, I'm mildly opposed to this change, but if I've made a
mistake in my reasoning here, or if other people feel strongly, I'm okay
either way.

What do you think?

      Mark

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

On Mon, Oct 30, 2017 at 03:14:10PM -0400, Mark H Weaver wrote:
> I'm not strongly opposed to it, but in general, I'm not sure I
> understand the rationale for changing source URLs to use HTTPS.  We
> already verify the authenticity of the downloaded file by SHA256 hash,
> and verify the GPG signature when updating to a new version.  Both of
> these are far stronger than HTTPS, which in practice can be subverted by
> compromising *any* certificate authority listed in our trust database
> (in Mozilla NSS).
>
> HTTPS also fails to hide from an evesdropper which file was downloaded,
> because in practice that can be determined by the amount of data
> transferred.
> 
> So, unless I'm mistaken, HTTPS doesn't provide any benefit to us here.
> On the other hand, using HTTPS entails using more complex code to
> download the files, which exposes a much larger attack surface that
> might be exploited to compromise our systems.  Many security flaws have
> been uncovered in TLS libraries over the years.  Using HTTPS also adds
> more load on the server.
> 
> In summary, I'm mildly opposed to this change, but if I've made a
> mistake in my reasoning here, or if other people feel strongly, I'm okay
> either way.
> 
> What do you think?

I think I'm more bullish on the TLS X.509 PKI than you but I basically
agree with your points.

We wouldn't gain anything with regards to the integrity of the
downloaded files and the HTTPS client software is probably more complex
than for unauthenticated HTTP.

It's true that, in this case, an active attacker could probably learn
which file you are downloading. But using TLS would foil passive
surveillance, which is probably widespread.

If I understand correctly we don't actually verify certificates when
downloading sources while building because we verify the integrity of
the files via the SHA256 hash, out of band.

If we did verify the certificates, I would argue that using TLS is an
improvement here because it could reduce the feasibility of exploits of
the download client and SHA256 verifier by MITM attackers. Examples of
this type of attack would be (hypothetical) exploits of CVE-2017-13089
and CVE-2017-13090, recently fixed in wget. IIUC, those bugs in the wget
client could be exploited by any MITM attacker; using TLS to ensure the
client is talking to the right server would help.

As it is, an attacker with knowledge of how Guix works could easily
circumvent TLS in this sort of scenario, since we don't verify the
certificates. Besides, as you mentioned previously, the TLS client
brings its own bugs.

Because I think that using HTTPS here reduces the effectiveness of
totally passive surveillance, I'm in favor of the change. What do you
think? And anyone else?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Ludovic Courtès]

Hi,

Replying to an old message…

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Oct 30, 2017 at 03:14:10PM -0400, Mark H Weaver wrote:
>> I'm not strongly opposed to it, but in general, I'm not sure I
>> understand the rationale for changing source URLs to use HTTPS.  We
>> already verify the authenticity of the downloaded file by SHA256 hash,
>> and verify the GPG signature when updating to a new version.  Both of
>> these are far stronger than HTTPS, which in practice can be subverted by
>> compromising *any* certificate authority listed in our trust database
>> (in Mozilla NSS).
>>
>> HTTPS also fails to hide from an evesdropper which file was downloaded,
>> because in practice that can be determined by the amount of data
>> transferred.
>> 
>> So, unless I'm mistaken, HTTPS doesn't provide any benefit to us here.
>> On the other hand, using HTTPS entails using more complex code to
>> download the files, which exposes a much larger attack surface that
>> might be exploited to compromise our systems.  Many security flaws have
>> been uncovered in TLS libraries over the years.  Using HTTPS also adds
>> more load on the server.
>> 
>> In summary, I'm mildly opposed to this change, but if I've made a
>> mistake in my reasoning here, or if other people feel strongly, I'm okay
>> either way.
>> 
>> What do you think?

I very much sympathize with everything you wrote.  Regarding
eavesdropping (which to me is the main reason to change to HTTPS in this
context), the “bicycle attack” kinda confirms that HTTPS is not so good
at protecting from eavesdropping: <http://arxiv.org/pdf/1403.0297.pdf>.

However, it remains a relatively elaborate attack: I can trivially see
what you are getting over HTTP, and I would have to target you and be
fairly determined to analyze your HTTPS traffic.  So overall, I still
think that HTTPS improves privacy, even if we must be aware of its
limitation.

> It's true that, in this case, an active attacker could probably learn
> which file you are downloading. But using TLS would foil passive
> surveillance, which is probably widespread.

+1

> If I understand correctly we don't actually verify certificates when
> downloading sources while building because we verify the integrity of
> the files via the SHA256 hash, out of band.

Right.

> If we did verify the certificates, I would argue that using TLS is an
> improvement here because it could reduce the feasibility of exploits of
> the download client and SHA256 verifier by MITM attackers. Examples of
> this type of attack would be (hypothetical) exploits of CVE-2017-13089
> and CVE-2017-13090, recently fixed in wget. IIUC, those bugs in the wget
> client could be exploited by any MITM attacker; using TLS to ensure the
> client is talking to the right server would help.
>
> As it is, an attacker with knowledge of how Guix works could easily
> circumvent TLS in this sort of scenario, since we don't verify the
> certificates. Besides, as you mentioned previously, the TLS client
> brings its own bugs.

Yeah.

> Because I think that using HTTPS here reduces the effectiveness of
> totally passive surveillance, I'm in favor of the change. What do you
> think? And anyone else?

I’m in favor of it as well.

Thanks,
Ludo’.

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Mark H Weaver]

Hi,

ludo@gnu.org (Ludovic Courtès) writes:

> Leo Famulari <leo@famulari.name> skribis:
>
>> On Mon, Oct 30, 2017 at 03:14:10PM -0400, Mark H Weaver wrote:
>>> I'm not strongly opposed to it, but in general, I'm not sure I
>>> understand the rationale for changing source URLs to use HTTPS.  We
>>> already verify the authenticity of the downloaded file by SHA256 hash,
>>> and verify the GPG signature when updating to a new version.  Both of
>>> these are far stronger than HTTPS, which in practice can be subverted by
>>> compromising *any* certificate authority listed in our trust database
>>> (in Mozilla NSS).
>>>
>>> HTTPS also fails to hide from an evesdropper which file was downloaded,
>>> because in practice that can be determined by the amount of data
>>> transferred.
>>> 
>>> So, unless I'm mistaken, HTTPS doesn't provide any benefit to us here.
>>> On the other hand, using HTTPS entails using more complex code to
>>> download the files, which exposes a much larger attack surface that
>>> might be exploited to compromise our systems.  Many security flaws have
>>> been uncovered in TLS libraries over the years.  Using HTTPS also adds
>>> more load on the server.
>>> 
>>> In summary, I'm mildly opposed to this change, but if I've made a
>>> mistake in my reasoning here, or if other people feel strongly, I'm okay
>>> either way.
>>> 
>>> What do you think?
>
> I very much sympathize with everything you wrote.  Regarding
> eavesdropping (which to me is the main reason to change to HTTPS in this
> context), the “bicycle attack” kinda confirms that HTTPS is not so good
> at protecting from eavesdropping: <http://arxiv.org/pdf/1403.0297.pdf>.
>
> However, it remains a relatively elaborate attack: I can trivially see
> what you are getting over HTTP, and I would have to target you and be
> fairly determined to analyze your HTTPS traffic.  So overall, I still
> think that HTTPS improves privacy, even if we must be aware of its
> limitation.
>
>> It's true that, in this case, an active attacker could probably learn
>> which file you are downloading. But using TLS would foil passive
>> surveillance, which is probably widespread.
>
> +1

Is an active attack needed to determine which file we are downloading
from linux-libre.fsfla.org?  I think not.  The IP address of that host
reverse resolves to "linux-libre.fsfla.org", which makes it obvious.
The title of the paper Ludovic cited above makes the point:

  I Know Why You Went to the Clinic

or in this case:

  I know why you downloaded 97 megabytes from linux-libre.fsfla.org.

Unless I'm mistaken, using TLS does *not* foil passive surveillance for
source downloads in the overwhelming majority of cases, and especially
not in this case.  Even at web sites that serve a larger variety of
software, determining what was downloaded by the amount of data
transferred does not require an active attack.

Anyway, having said this, if using HTTPS for linux-libre downloads makes
you sleep better at night, I'm okay with it.

     Regards,
       Mark

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Is an active attack needed to determine which file we are downloading
> from linux-libre.fsfla.org?  I think not.  The IP address of that host
> reverse resolves to "linux-libre.fsfla.org", which makes it obvious.
> The title of the paper Ludovic cited above makes the point:
>
>   I Know Why You Went to the Clinic
>
> or in this case:
>
>   I know why you downloaded 97 megabytes from linux-libre.fsfla.org.
>
> Unless I'm mistaken, using TLS does *not* foil passive surveillance for
> source downloads in the overwhelming majority of cases, and especially
> not in this case.  Even at web sites that serve a larger variety of
> software, determining what was downloaded by the amount of data
> transferred does not require an active attack.

You’re right, though it’s already more work for github.com (11% of our
packages) or PyPI (17% of our packages).

This discussion is also interesting in the context of
<https://bugs.gnu.org/28659>, where one of the options discussed would
be to favor content-addressable mirrors over upstream sites.

Ludo’.

bug#29046: [PATCH] gnu: linux-libre: Change URL to HTTPS.

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Tue, Nov 07, 2017 at 02:05:24PM -0500, Mark H Weaver wrote:
> Is an active attack needed to determine which file we are downloading
> from linux-libre.fsfla.org?  I think not.  The IP address of that host
> reverse resolves to "linux-libre.fsfla.org", which makes it obvious.
> The title of the paper Ludovic cited above makes the point:

I should clarify that by "active attacker" I mean someone who is doing
anything beyond simply recording the traffic. So, if they are making
lists of file sizes of different kernel tarballs, or keeping a database
of which sites you visited, keyed by your IP / identity, that's
"active".

> Anyway, having said this, if using HTTPS for linux-libre downloads makes
> you sleep better at night, I'm okay with it.

It doesn't affect my rest, but I assume you are speaking metaphorically.
So, I pushed the change as 8420c7a3565b6a984cdd95336f66d555edc87d90.

Thanks Rutger!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]