tor: update to 0.2.9.9

tor: update to 0.2.9.9

[contact.ng0]

This updates tor. I have seen no one prepare or commit a patch for this.

Paste from the announcement email:

Tor 0.2.9.9 fixes a denial-of-service bug where an attacker could
cause relays and clients to crash, even if they were not built with
the --enable-expensive-hardening option. This bug affects all 0.2.9.x
versions, and also affects 0.3.0.1-alpha: all relays running an affected
version should upgrade.

This release also resolves a client-side onion service reachability bug,
and resolves a pair of small portability issues.

Changes in version 0.2.9.9 - 2017-01-23
  o Major bugfixes (security):
    - Downgrade the "-ftrapv" option from "always on" to "only on when
      --enable-expensive-hardening is provided." This hardening option,
      like others, can turn survivable bugs into crashes -- and having
      it on by default made a (relatively harmless) integer overflow bug
      into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001);
      bugfix on 0.2.9.1-alpha.

  o Major bugfixes (client, onion service):
    - Fix a client-side onion service reachability bug, where multiple
      socks requests to an onion service (or a single slow request)
      could cause us to mistakenly mark some of the service's
      introduction points as failed, and we cache that failure so
      eventually we run out and can't reach the service. Also resolves a
      mysterious "Remote server sent bogus reason code 65021" log
      warning. The bug was introduced in ticket 17218, where we tried to
      remember the circuit end reason as a uint16_t, which mangled
      negative values. Partially fixes bug 21056 and fixes bug 20307;
      bugfix on 0.2.8.1-alpha.

  o Minor features (geoip):
    - Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2
      Country database.

  o Minor bugfixes (portability):
    - Avoid crashing when Tor is built using headers that contain
      CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel
      without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix
      on 0.2.9.1-alpha.
    - Fix Libevent detection on platforms without Libevent 1 headers
      installed. Fixes bug 21051; bugfix on 0.2.9.1-alpha.

[PATCH] gnu: tor: Update to 0.2.9.9.

[contact.ng0]

From: ng0 <ng0@libertad.pw>

* gnu/packages/tor.scm (tor): Update to 0.2.9.9.
---
 gnu/packages/tor.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/tor.scm b/gnu/packages/tor.scm
index 6f26f404b..c7f97ab1b 100644
--- a/gnu/packages/tor.scm
+++ b/gnu/packages/tor.scm
@@ -2,7 +2,7 @@
 ;;; Copyright © 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2014, 2015 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2016 Efraim Flashner <efraim@flashner.co.il>
-;;; Copyright © 2016 ng0 <ng0@we.make.ritual.n0.is>
+;;; Copyright © 2016, 2017 ng0 <contact.ng0@cryptolab.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -39,14 +39,14 @@
 (define-public tor
   (package
     (name "tor")
-    (version "0.2.9.8")
+    (version "0.2.9.9")
     (source (origin
              (method url-fetch)
              (uri (string-append "https://dist.torproject.org/tor-"
                                  version ".tar.gz"))
              (sha256
               (base32
-               "0sklgmx4nikcfhqd606kvpwy1l8840w24ikli1xjjx25739k7pgv"))))
+               "0hqdk5p6dw4bpn7c8gmhyi8jjkhc37112pfw5nx4gl0g4lmmscik"))))
     (build-system gnu-build-system)
     (native-inputs
      `(("python" ,python-2)))  ; for tests
-- 
2.11.0

Re: [PATCH] gnu: tor: Update to 0.2.9.9.

[Leo Famulari]

On Tue, Jan 24, 2017 at 11:19:34AM +0000, contact.ng0@cryptolab.net wrote:
> From: ng0 <ng0@libertad.pw>
> 
> * gnu/packages/tor.scm (tor): Update to 0.2.9.9.

Thanks! Applied as 7c04154940b746fb872536ea6833f5ef8ddbe288

Re: tor: update to 0.2.9.9

[Leo Famulari]

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

On Tue, Jan 24, 2017 at 11:19:33AM +0000, contact.ng0@cryptolab.net wrote:
> Changes in version 0.2.9.9 - 2017-01-23
>   o Major bugfixes (security):
>     - Downgrade the "-ftrapv" option from "always on" to "only on when
>       --enable-expensive-hardening is provided." This hardening option,
>       like others, can turn survivable bugs into crashes -- and having
>       it on by default made a (relatively harmless) integer overflow bug
>       into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001);
>       bugfix on 0.2.9.1-alpha.

I'm not familiar with Tor's build system.

Should we build Tor with "--enable-expensive-hardening"?

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

Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

Leo Famulari <leo@famulari.name> writes:

> On Tue, Jan 24, 2017 at 11:19:33AM +0000, contact.ng0@cryptolab.net wrote:
>> Changes in version 0.2.9.9 - 2017-01-23
>>   o Major bugfixes (security):
>>     - Downgrade the "-ftrapv" option from "always on" to "only on when
>>       --enable-expensive-hardening is provided." This hardening option,
>>       like others, can turn survivable bugs into crashes -- and having
>>       it on by default made a (relatively harmless) integer overflow bug
>>       into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001);
>>       bugfix on 0.2.9.1-alpha.
>
> I'm not familiar with Tor's build system.
>
> Should we build Tor with "--enable-expensive-hardening"?

I will take a look later what can be applied other than the
default configure flags.

I'm all for hardening, but it seems that the first basic ideas
for Guix are stuck in the idea state.
It would be great to see some movement on this during this
year. I volunteer to help with it, though I don't have as much
experience with SELinux (and only basic experience with
GrSecurity without a modular kernel like GuixSD uses).
-- 
♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[Leo Famulari]

On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
> Leo Famulari <leo@famulari.name> writes:
> > Should we build Tor with "--enable-expensive-hardening"?
> 
> I will take a look later what can be applied other than the
> default configure flags.
> 
> I'm all for hardening, but it seems that the first basic ideas
> for Guix are stuck in the idea state.

As far as I can tell, --enable-expensive-hardening is specific to Tor,
so it's not relevant to the project of hardening all Guix packages.

> It would be great to see some movement on this during this
> year. I volunteer to help with it, though I don't have as much
> experience with SELinux (and only basic experience with
> GrSecurity without a modular kernel like GuixSD uses).

Yes, this effort needs a champion.

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

Leo Famulari <leo@famulari.name> writes:

> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>> Leo Famulari <leo@famulari.name> writes:
>> > Should we build Tor with "--enable-expensive-hardening"?
>> 
>> I will take a look later what can be applied other than the
>> default configure flags.
>> 
>> I'm all for hardening, but it seems that the first basic ideas
>> for Guix are stuck in the idea state.
>
> As far as I can tell, --enable-expensive-hardening is specific to Tor,
> so it's not relevant to the project of hardening all Guix packages.

Yes.

I'm building this change right now:

+    (arguments
+     `(#:configure-flags (list "--enable-expensive-hardening"
+                               "--enable-gcc-hardening"
+                               "--enable-linker-hardening")))

Taken from Gentoo, I trust their hardening project to debug and
discover good usage.

>> It would be great to see some movement on this during this
>> year. I volunteer to help with it, though I don't have as much
>> experience with SELinux (and only basic experience with
>> GrSecurity without a modular kernel like GuixSD uses).
>
> Yes, this effort needs a champion.

-- 
♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

ng0 <contact.ng0@cryptolab.net> writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>>> Leo Famulari <leo@famulari.name> writes:
>>> > Should we build Tor with "--enable-expensive-hardening"?
>>> 
>>> I will take a look later what can be applied other than the
>>> default configure flags.
>>> 
>>> I'm all for hardening, but it seems that the first basic ideas
>>> for Guix are stuck in the idea state.
>>
>> As far as I can tell, --enable-expensive-hardening is specific to Tor,
>> so it's not relevant to the project of hardening all Guix packages.
>
> Yes.
>
> I'm building this change right now:
>
> +    (arguments
> +     `(#:configure-flags (list "--enable-expensive-hardening"
> +                               "--enable-gcc-hardening"
> +                               "--enable-linker-hardening")))
>
> Taken from Gentoo, I trust their hardening project to debug and
> discover good usage.
>
>>> It would be great to see some movement on this during this
>>> year. I volunteer to help with it, though I don't have as much
>>> experience with SELinux (and only basic experience with
>>> GrSecurity without a modular kernel like GuixSD uses).
>>
>> Yes, this effort needs a champion.

No, I would say this needs an effort of more than one person. At
best a team of people who either are willing to learn about
system hardening or already know enough, maybe even a combination
of both to share knowledge :)

-- 
♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[Leo Famulari]

On Tue, Jan 24, 2017 at 09:18:55PM +0000, ng0 wrote:
> ng0 <contact.ng0@cryptolab.net> writes:
> > Leo Famulari <leo@famulari.name> writes:
> >>> It would be great to see some movement on this during this
> >>> year. I volunteer to help with it, though I don't have as much
> >>> experience with SELinux (and only basic experience with
> >>> GrSecurity without a modular kernel like GuixSD uses).
> >>
> >> Yes, this effort needs a champion.
> 
> No, I would say this needs an effort of more than one person. At
> best a team of people who either are willing to learn about
> system hardening or already know enough, maybe even a combination
> of both to share knowledge :)

Sure, the more people the better. But so far, not a single person has
begun working on it, so I'd be happy with just one.

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

Leo Famulari <leo@famulari.name> writes:

> On Tue, Jan 24, 2017 at 09:18:55PM +0000, ng0 wrote:
>> ng0 <contact.ng0@cryptolab.net> writes:
>> > Leo Famulari <leo@famulari.name> writes:
>> >>> It would be great to see some movement on this during this
>> >>> year. I volunteer to help with it, though I don't have as much
>> >>> experience with SELinux (and only basic experience with
>> >>> GrSecurity without a modular kernel like GuixSD uses).
>> >>
>> >> Yes, this effort needs a champion.
>> 
>> No, I would say this needs an effort of more than one person. At
>> best a team of people who either are willing to learn about
>> system hardening or already know enough, maybe even a combination
>> of both to share knowledge :)
>
> Sure, the more people the better. But so far, not a single person has
> begun working on it, so I'd be happy with just one.

I feel confident enough to do it, but I also know that I am
overloaded with packages and services I work on.

For starters, I think we could have an "hardened-wip" branch on
savannah (I can't commit anyway directly) and that we can target
SELinux for now, look at Hardened-gentoo and other systems how
they solve issues.  Afterwards we need to address the toolchain
level, which to our advantage can be an make and break by hydra
and everyone who wants to contribute to fixing issues can run
their system from the hardening-toolchain-wip branch to
contribute to fixing all the breaking applications.

Then we need to discuss wether we want to provide this by default
(my choice) OR if we want to offer a branch-choice model.
Supporting both vanilla and hardened might take some more burden
on fixing issues, that's why I'm all for forming a team of people
who work on this, and when they no longer want to, other people
join the rest of the old team, etc.

Right now I'm trying to get uclib-ng done for a while, and when
this is added, we could at some point handle more than one
toolchain (and hardened), where it gets complicated.
-- 
♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

ng0 <contact.ng0@cryptolab.net> writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Tue, Jan 24, 2017 at 09:18:55PM +0000, ng0 wrote:
>>> ng0 <contact.ng0@cryptolab.net> writes:
>>> > Leo Famulari <leo@famulari.name> writes:
>>> >>> It would be great to see some movement on this during this
>>> >>> year. I volunteer to help with it, though I don't have as much
>>> >>> experience with SELinux (and only basic experience with
>>> >>> GrSecurity without a modular kernel like GuixSD uses).
>>> >>
>>> >> Yes, this effort needs a champion.
>>> 
>>> No, I would say this needs an effort of more than one person. At
>>> best a team of people who either are willing to learn about
>>> system hardening or already know enough, maybe even a combination
>>> of both to share knowledge :)
>>
>> Sure, the more people the better. But so far, not a single person has
>> begun working on it, so I'd be happy with just one.
>
> I feel confident enough to do it, but I also know that I am
> overloaded with packages and services I work on.
>
> For starters, I think we could have an "hardened-wip" branch on
> savannah (I can't commit anyway directly) and that we can target
> SELinux for now, look at Hardened-gentoo and other systems how
> they solve issues.  Afterwards we need to address the toolchain
> level, which to our advantage can be an make and break by hydra
> and everyone who wants to contribute to fixing issues can run
> their system from the hardening-toolchain-wip branch to
> contribute to fixing all the breaking applications.
>
> Then we need to discuss wether we want to provide this by default
> (my choice) OR if we want to offer a branch-choice model.
> Supporting both vanilla and hardened might take some more burden
> on fixing issues, that's why I'm all for forming a team of people
> who work on this, and when they no longer want to, other people
> join the rest of the old team, etc.
>
> Right now I'm trying to get uclib-ng done for a while, and when
> this is added, we could at some point handle more than one
> toolchain (and hardened), where it gets complicated.

Actually, the statement about more libcs (musl, glibc, uclibc)
making it all more complicated isn't true. In 99% of cases
uclibc-ng just works as good as glibc and musl is the one odd
bird you have to patch applications for sometimes, but even there
enough work has already been done by other systems.

-- 
♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Hardening (was: Re: tor: update to 0.2.9.9)

[Ricardo Wurmus]

Leo Famulari <leo@famulari.name> writes:

> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>> Leo Famulari <leo@famulari.name> writes:
>> > Should we build Tor with "--enable-expensive-hardening"?
>>
>> I will take a look later what can be applied other than the
>> default configure flags.
>>
>> I'm all for hardening, but it seems that the first basic ideas
>> for Guix are stuck in the idea state.
>
> As far as I can tell, --enable-expensive-hardening is specific to Tor,
> so it's not relevant to the project of hardening all Guix packages.
>
>> It would be great to see some movement on this during this
>> year. I volunteer to help with it, though I don't have as much
>> experience with SELinux (and only basic experience with
>> GrSecurity without a modular kernel like GuixSD uses).
>
> Yes, this effort needs a champion.

I know SELinux and I have a couple of almost-ready packages for it.  The
bigger problem for us is writing SELinux policies, because we cannot
just use those from Fedora.

SELinux policies are applied to file paths (which are not stable in
Guix) and are “remembered” using extended file attributes.  This means
we’d have to write policies that can deal with arbitrary prefixes and
we’d have to add an optional service to automatically label all store
items (that’s expensive but maybe it can be done incrementally).

However, this is completely separate from enabling a configure flag for
Tor.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Hardening

[ng0]

Ricardo Wurmus <rekado@elephly.net> writes:

> Leo Famulari <leo@famulari.name> writes:
>
>> On Tue, Jan 24, 2017 at 08:56:48PM +0000, ng0 wrote:
>>> Leo Famulari <leo@famulari.name> writes:
>>> > Should we build Tor with "--enable-expensive-hardening"?
>>>
>>> I will take a look later what can be applied other than the
>>> default configure flags.
>>>
>>> I'm all for hardening, but it seems that the first basic ideas
>>> for Guix are stuck in the idea state.
>>
>> As far as I can tell, --enable-expensive-hardening is specific to Tor,
>> so it's not relevant to the project of hardening all Guix packages.
>>
>>> It would be great to see some movement on this during this
>>> year. I volunteer to help with it, though I don't have as much
>>> experience with SELinux (and only basic experience with
>>> GrSecurity without a modular kernel like GuixSD uses).
>>
>> Yes, this effort needs a champion.
>
> I know SELinux and I have a couple of almost-ready packages for it.  The
> bigger problem for us is writing SELinux policies, because we cannot
> just use those from Fedora.

Oh, this is good to hear!

> SELinux policies are applied to file paths (which are not stable in
> Guix) and are “remembered” using extended file attributes.  This means
> we’d have to write policies that can deal with arbitrary prefixes and
> we’d have to add an optional service to automatically label all store
> items (that’s expensive but maybe it can be done incrementally).

Oh.

> However, this is completely separate from enabling a configure flag for
> Tor.

That's why I changed the subject of the email, I am aware that
this has nothing to do with tor configure-flags.

-- 
♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Hardening

[Ludovic Courtès]

Hi!

ng0 <contact.ng0@cryptolab.net> skribis:

> For starters, I think we could have an "hardened-wip" branch on
> savannah (I can't commit anyway directly) and that we can target
> SELinux for now, look at Hardened-gentoo and other systems how
> they solve issues.  Afterwards we need to address the toolchain
> level, which to our advantage can be an make and break by hydra
> and everyone who wants to contribute to fixing issues can run
> their system from the hardening-toolchain-wip branch to
> contribute to fixing all the breaking applications.
>
> Then we need to discuss wether we want to provide this by default
> (my choice) OR if we want to offer a branch-choice model.
> Supporting both vanilla and hardened might take some more burden
> on fixing issues, that's why I'm all for forming a team of people
> who work on this, and when they no longer want to, other people
> join the rest of the old team, etc.

Before creating a branch, I think we need a plan.  :-)

Alex Vong proposed ways to achieve it a while back:

  https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00702.html

I suggest taking a look at the discussion and starting from there.

The best option is probably to start small (limited set of
features/flags/options) and then incrementally improve that.

Ludo’.

Re: Hardening

[ng0]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> ng0 <contact.ng0@cryptolab.net> skribis:
>
>> For starters, I think we could have an "hardened-wip" branch on
>> savannah (I can't commit anyway directly) and that we can target
>> SELinux for now, look at Hardened-gentoo and other systems how
>> they solve issues.  Afterwards we need to address the toolchain
>> level, which to our advantage can be an make and break by hydra
>> and everyone who wants to contribute to fixing issues can run
>> their system from the hardening-toolchain-wip branch to
>> contribute to fixing all the breaking applications.
>>
>> Then we need to discuss wether we want to provide this by default
>> (my choice) OR if we want to offer a branch-choice model.
>> Supporting both vanilla and hardened might take some more burden
>> on fixing issues, that's why I'm all for forming a team of people
>> who work on this, and when they no longer want to, other people
>> join the rest of the old team, etc.
>
> Before creating a branch, I think we need a plan.  :-)
>
> Alex Vong proposed ways to achieve it a while back:
>
>   https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00702.html
>
> I suggest taking a look at the discussion and starting from there.

Okay, I did and I don't see right now how this new (guix build
build-flags) module would be applied to the gnu build system for
example.
Would the (gnu build system) just use it somehow? I'd like to
test it, but I didn't write it.

I also would like to rename it to (guix build build-flags-glibc)
(or -gcc) as I want to see a point where we have more than just
glibc. We don't have to build them (the substitutes,packages) all
on hydra. musl and uclibc-ng can be without substitutes as long
as the means of distribution or diskspace are not working out for us.
And both can (and will) get hardened builds aswell.

> The best option is probably to start small (limited set of
> features/flags/options) and then incrementally improve that.
>
> Ludo’.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Hardening

[ng0]

ng0 <contact.ng0@cryptolab.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi!
>>
>> ng0 <contact.ng0@cryptolab.net> skribis:
>>
>>> For starters, I think we could have an "hardened-wip" branch on
>>> savannah (I can't commit anyway directly) and that we can target
>>> SELinux for now, look at Hardened-gentoo and other systems how
>>> they solve issues.  Afterwards we need to address the toolchain
>>> level, which to our advantage can be an make and break by hydra
>>> and everyone who wants to contribute to fixing issues can run
>>> their system from the hardening-toolchain-wip branch to
>>> contribute to fixing all the breaking applications.
>>>
>>> Then we need to discuss wether we want to provide this by default
>>> (my choice) OR if we want to offer a branch-choice model.
>>> Supporting both vanilla and hardened might take some more burden
>>> on fixing issues, that's why I'm all for forming a team of people
>>> who work on this, and when they no longer want to, other people
>>> join the rest of the old team, etc.
>>
>> Before creating a branch, I think we need a plan.  :-)
>>
>> Alex Vong proposed ways to achieve it a while back:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00702.html
>>
>> I suggest taking a look at the discussion and starting from there.
>
> Okay, I did and I don't see right now how this new (guix build
> build-flags) module would be applied to the gnu build system for
> example.
> Would the (gnu build system) just use it somehow? I'd like to
> test it, but I didn't write it.

Sorry, correction:
I must have skipped the explanation at the beginning, I do
understand it.
And it makes sense… it's in the interest of my blend of GuixSD,
so unless someone really has a burning desire to work on this, I
will try to produce something functional with changes to the
build system(s) to use hardened flags by default, with opt-out
for: other build-systems I do not understand, and whatnot.
There's no harm in not providing something like:

  #:hardened? #f

for those applications which still need to be patched, but I
prefer to fix rather than provide the easy way out.

> I also would like to rename it to (guix build build-flags-glibc)
> (or -gcc) as I want to see a point where we have more than just
> glibc. We don't have to build them (the substitutes,packages) all
> on hydra. musl and uclibc-ng can be without substitutes as long
> as the means of distribution or diskspace are not working out for us.
> And both can (and will) get hardened builds aswell.
>
>> The best option is probably to start small (limited set of
>> features/flags/options) and then incrementally improve that.
>>
>> Ludo’.
>
> -- 
> ng0 -- https://www.inventati.org/patternsinthechaos/

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/