Hi all,
a while ago a ticket about renaming our "hardened" series got filed[1]. There, it is argued we should think about renaming the hardened series to something else as it is probably not as hardened as one would expect and thus misleading our users. Especially shipping that build with Address Sanitizer (ASan) enabled caused some folks to point out that ASan is mainly a debugging tool (which the other goal of the hardened series is) which is very likely at odds with the hardened aspect of the series.
While I still stand to the things we said in our blog post[2] back then when we introduced the hardened series I am fine with picking this discussion up right now and moving on to a decision. The reason for that is that we have Yawning Angel's sandboxed Tor Browser which achieves the goal of preventing harm from our users much better than the hardened aspect of our hardened series could ever do. Moreover, selfrando, one of the noteworthy aspects of our hardened series, is about to get shipped in our regular alphas. If all goes well it will be available in 7.0a2.
So, things we need to decide are
1) What do we want to do with our hardened series? Should we rename it to "debug series" or something similar?
2) Should we expose the renamed thing to the general public as an own, new series or should we just ship the means to create a debugging build whenever we need one?
3) What should we do with users already being on the hardened update channel? Should they get moved to our alpha channel with some notice?
or maybe some fourth or fifth item rendering 1)-3) moot but which I did not come up with?
Georg
[1] https://trac.torproject.org/projects/tor/ticket/20814 [2] https://blog.torproject.org/blog/tor-browser-55a4-hardened-released
Hi,
Georg Koppen:
Hi all,
a while ago a ticket about renaming our "hardened" series got filed[1]. There, it is argued we should think about renaming the hardened series to something else as it is probably not as hardened as one would expect and thus misleading our users. […]
While I still stand to the things we said in our blog post[2] back then when we introduced the hardened series I am fine with picking this discussion up right now and moving on to a decision.
Thank you. At Tails we regularly get requests from users about "please include the 'hardened' Tor Browser it must be more secure", and it's been hard to explain that things are a bit more complicated than that.
- What do we want to do with our hardened series? Should we rename it
to "debug series" or something similar?
Sounds good to me. With some explanation along the lines of what the introduction to your email explains, passed through the filter of a good technical writer, perhaps :)
- Should we expose the renamed thing to the general public as an own,
new series or should we just ship the means to create a debugging build whenever we need one?
FWIW: I suggest you don't expose it unless/until there's substantial and relevant demand for it.
- What should we do with users already being on the hardened update
channel? Should they get moved to our alpha channel with some notice?
Sounds reasonable to me.
Thanks again, cheers,
On 2 February 2017 at 15:28, Georg Koppen gk@torproject.org wrote:
Hi all,
a while ago a ticket about renaming our "hardened" series got filed[1]. There, it is argued we should think about renaming the hardened series to something else as it is probably not as hardened as one would expect and thus misleading our users. Especially shipping that build with Address Sanitizer (ASan) enabled caused some folks to point out that ASan is mainly a debugging tool (which the other goal of the hardened series is) which is very likely at odds with the hardened aspect of the series.
While I still stand to the things we said in our blog post[2] back then when we introduced the hardened series I am fine with picking this discussion up right now and moving on to a decision. The reason for that is that we have Yawning Angel's sandboxed Tor Browser which achieves the goal of preventing harm from our users much better than the hardened aspect of our hardened series could ever do. Moreover, selfrando, one of the noteworthy aspects of our hardened series, is about to get shipped in our regular alphas. If all goes well it will be available in 7.0a2.
So, things we need to decide are
- What do we want to do with our hardened series? Should we rename it
to "debug series" or something similar?
- Should we expose the renamed thing to the general public as an own,
new series or should we just ship the means to create a debugging build whenever we need one?
- What should we do with users already being on the hardened update
channel? Should they get moved to our alpha channel with some notice?
or maybe some fourth or fifth item rendering 1)-3) moot but which I did not come up with?
I have a question about ASAN. Why do we release it? Is it because we think it can sometimes provide security? Or is it for the purposes of debugging? If it's for debugging, do we --enable-debug and --disable-optimize on this build and any other debugging stuff?
It's my hope that we will, in the next year, be able to ship more hardening features on more platforms. Adding in CFI for Linux and Mac; and CFG for Windows. There's jemalloc redzones (are those going in hardened, alpha, or release?)
Will these go into Alpha with the goal of getting them to release? And it would be awesome to move to a 64bit version for Windows. (I'm unclear why we have a 32 bit linux version actually; and when we get a 64 bit Windows version why we would keep a 32 bit version.
I guess what I'm trying to figure out is: if we aggressively move all hardening features we can into Alpha and then release; either the 'Hardened' version is really a Pre-Alpha (with ASAN for catching more bugs) or it's a Debug version. If it's pre-alpha, cool, let's make an alpha, beta, and release channel. If it's Debug, cool, it's Debug. =)
And all of these are separate from Yawning's Sandboxed version
-tom
On 3 Feb 2017, at 08:52, Tom Ritter tom@ritter.vg wrote:
I guess what I'm trying to figure out is: if we aggressively move all hardening features we can into Alpha and then release; either the 'Hardened' version is really a Pre-Alpha (with ASAN for catching more bugs) or it's a Debug version. If it's pre-alpha, cool, let's make an alpha, beta, and release channel. If it's Debug, cool, it's Debug. =)
Core tor just made a similar change in master, expensive hardening is now:
--enable-fragile-hardening enable more fragile and expensive compiler hardening; makes Tor slower
https://trac.torproject.org/projects/tor/ticket/21290
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 3 Feb 2017, at 08:57, teor teor2345@gmail.com wrote:
On 3 Feb 2017, at 08:52, Tom Ritter tom@ritter.vg wrote:
I guess what I'm trying to figure out is: if we aggressively move all hardening features we can into Alpha and then release; either the 'Hardened' version is really a Pre-Alpha (with ASAN for catching more bugs) or it's a Debug version. If it's pre-alpha, cool, let's make an alpha, beta, and release channel. If it's Debug, cool, it's Debug. =)
Core tor just made a similar change in master, expensive hardening is now:
--enable-fragile-hardening enable more fragile and expensive compiler hardening; makes Tor slower
Also, we added this wiki entry:
https://trac.torproject.org/projects/tor/wiki/doc/TorFragileHardening
This change was prompted by TROVE-2016-12-002:
https://trac.torproject.org/projects/tor/ticket/21018
T
On 2/2/17 4:52 PM, Tom Ritter wrote:
I have a question about ASAN. Why do we release it? Is it because we think it can sometimes provide security? Or is it for the purposes of debugging? If it's for debugging, do we --enable-debug and --disable-optimize on this build and any other debugging stuff?
It's my hope that we will, in the next year, be able to ship more hardening features on more platforms. Adding in CFI for Linux and Mac; and CFG for Windows. There's jemalloc redzones (are those going in hardened, alpha, or release?)
Will these go into Alpha with the goal of getting them to release? And it would be awesome to move to a 64bit version for Windows. (I'm unclear why we have a 32 bit linux version actually; and when we get a 64 bit Windows version why we would keep a 32 bit version.
Good questions. We need to be confident about the security benefits (it is usually not too difficult to get to that point, although ASan is a special case) and also the stability anything before anything goes into our release builds... but we use our alpha channel to determine that, right?
As far as 32-bit Linux and Windows builds, we are trading off security vs. compatibility with older OSes and hardware (maybe we are making the wrong tradeoff). For Win64 I am sure there is work to be done as well; see https://trac.torproject.org/projects/tor/ticket/20636
I guess what I'm trying to figure out is: if we aggressively move all hardening features we can into Alpha and then release; either the 'Hardened' version is really a Pre-Alpha (with ASAN for catching more bugs) or it's a Debug version. If it's pre-alpha, cool, let's make an alpha, beta, and release channel. If it's Debug, cool, it's Debug. =)
Maintaining another channel will be a challenge given our small team, but what you say makes a lot of sense. But I also wonder how many alpha and hardened users we have and whether our audience of available testers is too small to support another channel. On the other hand, more people should be willing to run something labeled "beta" instead of "alpha."
Tom Ritter:
On 2 February 2017 at 15:28, Georg Koppen gk@torproject.org wrote:
Hi all,
a while ago a ticket about renaming our "hardened" series got filed[1]. There, it is argued we should think about renaming the hardened series to something else as it is probably not as hardened as one would expect and thus misleading our users. Especially shipping that build with Address Sanitizer (ASan) enabled caused some folks to point out that ASan is mainly a debugging tool (which the other goal of the hardened series is) which is very likely at odds with the hardened aspect of the series.
While I still stand to the things we said in our blog post[2] back then when we introduced the hardened series I am fine with picking this discussion up right now and moving on to a decision. The reason for that is that we have Yawning Angel's sandboxed Tor Browser which achieves the goal of preventing harm from our users much better than the hardened aspect of our hardened series could ever do. Moreover, selfrando, one of the noteworthy aspects of our hardened series, is about to get shipped in our regular alphas. If all goes well it will be available in 7.0a2.
So, things we need to decide are
- What do we want to do with our hardened series? Should we rename it
to "debug series" or something similar?
- Should we expose the renamed thing to the general public as an own,
new series or should we just ship the means to create a debugging build whenever we need one?
- What should we do with users already being on the hardened update
channel? Should they get moved to our alpha channel with some notice?
or maybe some fourth or fifth item rendering 1)-3) moot but which I did not come up with?
I have a question about ASAN. Why do we release it? Is it because we think it can sometimes provide security? Or is it for the purposes of debugging?
Both.
If it's for debugging, do we --enable-debug and --disable-optimize on this build and any other debugging stuff?
No, because we wanted to have the hardened series to be not only a debugging tool. We tried to have the best of both worlds.
It's my hope that we will, in the next year, be able to ship more hardening features on more platforms. Adding in CFI for Linux and Mac; and CFG for Windows. There's jemalloc redzones (are those going in hardened, alpha, or release?)
Regarding redzones: They are for now on the alpha series only (and Linux-only) because we thought we might run into issues with ASan.
Will these go into Alpha with the goal of getting them to release? And it would be awesome to move to a 64bit version for Windows. (I'm unclear why we have a 32 bit linux version actually; and when we get a 64 bit Windows version why we would keep a 32 bit version.
The 64bit Windows version is planned for this year. We need to get our build system capable of doing releases for more platforms/architectures first which we are working on as well. That said we had 32bit Linux bundles e.g. because they were used in Tails. I am fine with opening up a discussion whether we should keep the 32bit versions. I think looking at the recently released Tor Browser stats might be helpful to give some factual background.
Regarding hardening features moving to release: In principle, yes, we want that, although we might want to weigh benefits and costs in every single case. But our policy so far has been that all the things that land in the alpha series are being tested there with the aim to have them at some time in the stable as well.
I guess what I'm trying to figure out is: if we aggressively move all hardening features we can into Alpha and then release; either the
I don't think that is going to happen for various reaons. One of them is the insight Tim pointed out and that got recently addressed by renaming tor's `--enable-expensive-hardening` to `--enable-fragile-hardening`: there are cases in which the hardened versions are more vulnerable to some problems (all the TROVE things found were more problematic for hardened tor versions) while they, at the same time, are providing better defenses against other issues. So, the benefits are way less clear while the costs pile up. :)
'Hardened' version is really a Pre-Alpha (with ASAN for catching more bugs) or it's a Debug version. If it's pre-alpha, cool, let's make an alpha, beta, and release channel. If it's Debug, cool, it's Debug. =)
Well, yes, I am fine with that outcome and that we point to Yawning's sandboxed-tor-browser for a hardened setup for Linux users. We could then think about shipping the Firefox part with `--enable-debug` and `--disable-optimize` and a bunch of other debugging aids.
I guess we could start that one with intrigeri's suggestion to not ship that as a new, separate series which means we have the ability to build bundles if needed (or have it as a regular nightly for which we don't have automatic updates yet anyway) in our tree and keep that up-to-date at least.
And all of these are separate from Yawning's Sandboxed version
Indeed.
Georg
-
Georg Koppen -
intrigeri -
Mark Smith -
teor -
Tom Ritter