search

Homebrew / legacy-homebrew

💀 The former home of Homebrew/homebrew (deprecated)
https://brew.sh
26.99k stars 11.35k forks source link

Death to SSLv3 #34634

Closed DomT4 closed 9 years ago

DomT4 commented 9 years ago

Alright, I'm punting this into public discussion. If there aren't any unworkable rejections of the idea, my desire is to press ahead with this and close it out before December 11th.

I'm proposing, primarily, amongst other things, that we remove SSLv3 support from OpenSSL. This is in part driven by POODLE, which has thankfully hastened the demise of SSLv3, but I don't think anyone is going to deny that SSLv3 has been weak at best for years and years now. SSLv3 was 'birthed' in 1996. It was replaced by TLSv1.0 in 1999. 15 years after the introduction of TLSv1.0 we're still in a world where SSLv3 is a thing, sigh. But POODLE has finally nudged the world into some kind of coordinated action, and I think Homebrew should be part of that.

I'll bullet point things from this point on to avoid making anyone read walls of text and scaring everyone off:

I made the argument at the time we disabled SSLv2, and I'll make it again now:

For better or worse, OpenSSL themselves have largely maintained a position over the years that it is up to distro managers and individual users how they configure OpenSSL. OpenSSL ships with all the ciphers you could possibly imagine (almost), and it's up to you to decide which ones you want to support or not. So it is down to package managers to decide whether to act or not, rather than waiting on OpenSSL to do so. For better or worse, OpenSSL has decided for now not to make that choice for package managers and individuals.

The OpenSSL trunk has started experimenting with the idea of Security Levels, where mandating Security Level 3 at build time would disable x,y,z ciphers, but that has not yet landed in stable and probably won't land until at least 1.0.2 stable.

The only OpenSSL release which is really going to get smacked about by any SSLv3 change is the 0.9.8 branch, which Apple currently uses, but Apple's OpenSSL support is depreciated. As of December 2015 OpenSSL 0.9.8 will cease to be supported entirely, and the last OpenSSL version which supports nothing newer than TLS1.0 will cease to be shipped by everyone, distros included, hopefully.

Sadly, there isn't a huge amount of point in disabling SSLv3 in OpenSSL 0.9.8 because that leaves it with TLS1.0 and that's all. I'd rather Homebrew ditch supporting OpenSSL 0.9.8 entirely, but I'm content to leave it in Homebrew/Versions until the December 2015 expiration date.

So, We'd do the same dance we did when we killed SSLv2, which is essentially:

Yes, Making users bump everything is tedious, but yes, I believe it is worthwhile. The only formulae we had significant issues with last time were:

I seem to recall that all three were bottle issues, although I could be incorrect in that recollection. Now that SSLv3 removal has landed in Ruby stable, and been backported, and there are patches for the two Python versions available that will be in the next stable releases, I feel like those formulae should have a smoother ride this time.

We've had one request to turn SSLv2 back on in the time since we disabled it.

I expect SSLv3 to be slightly more troublesome, but in reality SSLv3 usage is tiny, and servers should not be using SSLv3 any more, and the number of servers out there that can't talk at least TLS1.0 is tiny.

Other things I'd like to deal with whilst we're here:

The most recent OpenSSL release finally properly killed off SSLv3. It turned out that although the option of doing ./configure no-ssl3 had been there for a while it wasn't completely working. As of the latest stable release, which Homebrew is using, that issue has been fixed and no-ssl3 works as expected. There's a slightly odd patch on the current OpenSSL git which I want to ask upstream about first, and pull into our OpenSSL formula if necessary.

Alright, that's me. I open the floor to comments :wink:.

MikeMcQuaid commented 9 years ago

It seems it's incoming on the OpenSSL end so makes sense to do this before we're pushed (e.g. by a security release). I'm :+1: on doing this and really appreciate the long write-up on the justification why.

tdsmith commented 9 years ago

The most important point I see raised when people discuss this elsewhere is that the Internet is not synonymous with the Web; clients also need to be able to communicate with printers and mainframes and refrigerators which may or may not be field-upgradeable. I wonder if we should offer a --with-insecure-ssl3 option.

Python have released two patches that disable SSLv3 in Python 2.7 & Python 3.4.

Not really; these patches force you to ask for SSLv3 when you want it when instantiating a server from the standard library, which is in practice rare AFAICT. Python still lets you build servers and clients that use SSLv3. It looks from that thread that Python 2.7.8 may need a patch to compile against an OpenSSL with ssl3 disabled, though.

DomT4 commented 9 years ago

The most important point I see raised when people discuss this elsewhere is that the Internet is not synonymous with the Web.

Agreed, but I think I covered some of that in my post. I tried to focus on things that weren't web-orientated as well as things that were. But the death to SSLv3 has been pushed on servers as well as web browsing in a coordinated way that SSLv2 never really was. With GnuTLS, PolarSSL, LibreSSL and Debian's OpenSSL slamming the door shut on SSLv3 frankly the world is moving to a place where no SSLv3 is the default, and insecure mechanisms are getting left out in the cold.

You have to work quite hard to find many situations where at least TLS1.0 isn't accepted, even in ancient tech. TLS1.0 was out there in the late 90s, so even if for some reason you've built your piece of tech to use only OpenSSL 0.9.7 and haven't updated since it was released your piece of technology can still talk TLS1.0, even if nothing newer. TLS1.0 was released as an option way back on 9th July 2001.

Focusing on Server-Side, Linode have been encouraging people to turn off SSLv3, Amazon AWS said to disable completely where possible, Digital Ocean said to turn off SSLv3, as have Digicert.

I appreciate there's a web beyond server and client, beyond server and website, but I'd question how many of those Homebrew serves or should particularly fret about serving. It's a niche element, and if Debian feel safe enough to kill it off on Jessie and above, I wouldn't expect Homebrew to be serving a broader populous than Debian Jessie and above.

Touching briefly on the web side of things again for a moment, there are more stats on SSLv3 deployment via that link.

I wonder if we should offer a --with-insecure-ssl3 option.

I would be against this. It adds an additional layer of complication to the formula, and to maintaining OpenSSL for us, and I tend to strongly share the Debian point of view that "If you want insecure defaults, go compile them yourself", which is what Debian pretty much said here. If there's a really, really strong demand for this I wouldn't necessarily object to shipping something called _"Really_InsecureOpenSSL" in Homebrew/dupes or Homebrew/versions. But I personally feel it's a fireball not worth playing with.

It looks from that thread that Python 2.7.8 may need a patch to compile against an OpenSSL with ssl3 disabled, though.

Yeah, sorry, I pointed to the wrong patch thread. I meant to point towards this one, which contains the Python 2.7 patch. Apologies for the wrong set of links there. You are our resident Python expert, so I bow to you on Python handling :grinning:.

tdsmith commented 9 years ago

Server platforms, client platforms, and client applications have different needs for interoperability. I don't believe Homebrew is viewed as a production server environment and advice to individual server operators is not necessarily good advice to Homebrew. Statistics on popular, public-facing websites don't provide any data about things that are not popular, public-facing websites; numbers for consumer and intranet environments are hard to come by. The "but I need to talk to my toaster" problem is probably unquantifiable so we're necessarily arguing without data, which is frustrating.

I agree that disabling sslv3 by default is prudent but I'm not confident about the timeline. If Debian's only made changes in unstable we'll be ahead of the curve if we deploy it to all our users, and developers are probably still responding. Beyond breaking interoperability there's a question of simply breaking software; it looks like the Debian Python patch removes a public, documented Python API constant, which makes the popular gevent package raise and die on import, so I don't think we should accept that. Being a guinea pig is a lousy user experience.

DomT4 commented 9 years ago

Statistics on popular, public-facing websites don't provide any data about things that are not popular, public-facing websites; numbers for consumer and intranet environments are hard to come by.

Agreed. But should we be attempting to dance for the most popular use-case, or should we be attempting to dance for niche use-cases at the cost of exposing users to greater risk? In my opinion, and I'm content accepting this is purely my opinion, Homebrew should attempt to serve the greatest use-case, the most public-facing use-case as possible. Frankly, anyone who is using a package manager in a mission-critical situation is doing something fairly obviously wrong, because you just shouldn't be entrusting your mission-critical software and updates to a group of people who can make decisions on whim or are potentially vulnerable to infiltration or misdirection. If talking to your toaster is that critical, nobody is advising that you should lean on any package manager to do so.

I agree that disabling sslv3 by default is prudent but I'm not confident about the timeline.

We have been talking about this on and off for... 5 months now. This isn't a sudden rush to determination, but rather an acceptance that if we are ever going to get this done, using the post-POODLE world as a horse to ride isn't the worst thing to do. We killed SSLv3 in PolarSSL. The next .x release of GnuTLS will kill SSLv3. Everyone is clambering towards a world without SSLv3, and it is about time. Secure defaults are the way forwards, and everyone is starting to embrace those. How many more small, yappy, bitey dogs does the world have to go through before we accept that we can't wait for things to be completely and utterly broken before we fix them? I don't accept the argument that we wait and wait and wait until suddenly it's something that has to be done.

If Debian's only made changes in unstable we'll be ahead of the curve if we deploy it to all our users, and developers are probably still responding.

I struggle with this. Homebrew is far more Sid than Wheezy. We use the same version numbers as Sid. We look at sid for dependency information, a lot. But the OpenSSL change isn't even in Sid, It's in Jessie which Debian are on the record as This will be the next Debian release post-wheezy and SSLv3 is not coming back. Do not expect it to come back. This will not be reverted. If Debian was truly panicked by this change, and didn't see it as necessary we'd see it in experimental, or even sid, but the fact it went directly into Jessie screams at me that they are rock solid serious about this. And they killed SSLv3 off in October. We haven't moved till now, December. Debian's own description of Jessie is:

That means that things should not break as badly as in unstable or experimental distributions, because packages are allowed to enter this distribution only after a certain period of time has passed, and when they don't have any release-critical bugs filed against them.

removes a public, documented Python API constant

You're the Python expert, and I respect that completely; I'm not going to attempt to die on your hill. If you want to keep Python compiled with an SSLv3-enabled OpenSSL, I bow to you. If necessary I'll bow to having two OpenSSLs in the main distro here, one with SSLv3 and one without. But if this change works with everything but Python, I'm wary of delaying on everything else.

At the end of the day, this comes down to the maintainers. If there's a clear consensus against it I'll go away and leave it, and keep testing it locally, but I struggle to not believe if we tuck this away for another day there's no guarantee we'll ever get back to that day, because that's more often than not what happens in projects this vast and broad.

MikeMcQuaid commented 9 years ago

Basically: let's start making PRs for things and discussing them on a case-by-case basis. Trying to do this in lots of small PRs seems like the way forward for review, testing and our users. I'm open to disabling SSLv3 everywhere that doesn't require a patch (i.e. is a officially supported build option) and adding back SSLv3 as options to formulae when requested by users.

DomT4 commented 9 years ago

Alright, I'm content with compromise. My disagreements with Tim here are only filled with respect, as grouchy as I sound at times it's never a personal thing, I'm just a grouchy person :wink:.

I'm open to disabling SSLv3 everywhere that doesn't require a patch (i.e. is a officially supported build option)

Could you clarify this a wee bit for me? As in, officially supported upstream explicitly, or officially supported in the sense that if we no-ssl3 it that piece of software doesn't dramatically break and need uber-patching?

adding back SSLv3 as options to formulae when requested by users.

How do we want to handle this? Do we want to rock two OpenSSL versions, and then essentially do depends_on "ssl3openssl" in for example, Python, or do we do depends_on "openssl" => [with-ssl3] and essentially only support either not using ssl3 on the system, or using it everywhere? I'm not really sure what the best dance is to do on that balance, so I defer to you here.

MikeMcQuaid commented 9 years ago

Could you clarify this a wee bit for me? As in, officially supported upstream explicitly, or officially supported in the sense that if we no-ssl3 it that piece of software doesn't dramatically break and need uber-patching?

i.e. if Python needs patching to disable SSLv3 support (I don't know either way) I'm not up for disabling SSLv3 in it. If its dependencies need patched I'm a bit easier on that.

How do we want to handle this? Do we want to rock two OpenSSL versions, and then essentially do depends_on "ssl3openssl" in for example, Python, or do we do depends_on "openssl" => [with-ssl3] and essentially only support either not using ssl3 on the system, or using it everywhere? I'm not really sure what the best dance is to do on that balance, so I defer to you here.

The latter.

DomT4 commented 9 years ago

i.e. if Python needs patching to disable SSLv3 support (I don't know either way) I'm not up for disabling SSLv3 in it. If its dependencies need patched I'm a bit easier on that.

Cool. I've got a Debian VM that I use pretty regularly, so I'm going to bump that from Wheezy to Jessie later and see if I can poke around.

The latter.

You mentioned on a per formulae basis earlier, on that did you mean brew install Python will always lead to an automatic installation of OpenSSL with sslv3 or did you mean that we should handle it actually in the formulae themselves? i.e, brew install python --with-ssl3 which then triggers a depends_on "openssl" => [with-ssl3] but otherwise brew install python triggers an installation of OpenSSL without SSLv3 and builds Python with that?

That's just an example. Taking Tim's words into account, It seems likely that Python by default would be built with SSLv3 and only available without SSLv3 on request.

Hopefully that question made some kind of sense. It sounded like it made more sense in my head than it did when I actually typed it here :grinning:.

DomT4 commented 9 years ago

so I'm going to bump that from Wheezy to Jessie later and see if I can poke around.

Heads up to anyone else considering this... Expect to have to download 2.5GB of data when switching between distros :sweat_smile:.

alex commented 9 years ago

With Python 2.7.9 (which is now in homebrew) no patching should be necessary to compile with SSLv3 disabled. If you hit any troubles, please let me know and I'm happy to work to make sure any fixes are upstreamed correctly.

(Big +1 from me, thanks for working on this!)

DomT4 commented 9 years ago

I ducked this onto the backburner a little to address Tim's comments about the timeline. I still would like to get it done before Christmas, but I'd like to work out the implementation of it before we move forwards, whether we deal with things on a per-formulae basis or something more like "Well, if you want to install Python, you're stuck using an OpenSSL with SSLv3 enabled for now".

I don't think the second option is particularly great, but I appreciate the first option may not be something the maintainers love because it's not consistently low-maintenance. I'd prefer something like:

class Python < Formula
  homepage "https://www.python.org"
  head "https://hg.python.org/cpython", :using => :hg, :branch => "2.7"
  url "https://www.python.org/ftp/python/2.7.9/Python-2.7.9.tgz"
  sha1 "7a191bcccb598ccbf2fa6a0edce24a97df3fc0ad"

  bottle do
    revision 4
    sha1 "12f246ccb25d1024864916f643d819ff7572afdf" => :yosemite
    sha1 "453c0c36a69059d2746628d468a67572adc94100" => :mavericks
    sha1 "3bc89dbc02095d229b05a5c82bc11b4081211182" => :mountain_lion
  end

  # Please don't add a wide/ucs4 option as it won't be accepted.
  # More details in: https://github.com/Homebrew/homebrew/pull/32368
  option :universal
  option "quicktest", "Run `make quicktest` after the build (for devs; may fail)"
  option "with-brewed-tk", "Use Homebrew's Tk (has optional Cocoa and threads support)"
  option "with-poll", "Enable select.poll, which is not fully implemented on OS X (http://bugs.python.org/issue5154)"
  option "with-dtrace", "Experimental DTrace support (http://bugs.python.org/issue13405)"
  option "with-ssl3", "Enable SSLv3 support. This will be a system-wide change"

  depends_on "pkg-config" => :build
  depends_on "readline" => :recommended
  depends_on "sqlite" => :recommended
  depends_on "gdbm" => :recommended
  depends_on "homebrew/dupes/tcl-tk" if build.with? "brewed-tk"
  depends_on :x11 if build.with? "brewed-tk" and Tab.for_name("tcl-tk").with? "x11"

  if build.with? "sslv3"
     depends_on "openssl" => [with-ssl3]
  else
    depends_on "openssl"
  end

But there are downsides with that, the largest being @mikemcquaid has previously expressed a desire to move firmly away from if blah depends_on blah else depends_on blah statements outside of def install, and I don't want to push something through that just leaves the maintainers feeling dissatisfied.

Ultimately, what I'd like to do is just kill SSLv3 dead completely and tell software that depends on those insecure ciphers to go whistle, but evidently, that has its fair share of concerns and Tim has expressed a firm desire to not see that happen just yet. But Tim & I could have probably argued that out for weeks on end, and Mike's intervention and suggestion of a middle ground is probably the way to go right now.

No hate to Tim or any of the maintainers for wanting to find a middle ground. That's why they are the maintainers, at the end of the day, that's why they get the final say over what goes in and what doesn't, because they have that experience and deeper understanding.

The status on this is largely the second we agree on a way to implement it, I'll set 6 hours aside and do it, and then ping the maintainers for review, thoughts, adjustments, etc.

MikeMcQuaid commented 9 years ago

But there are downsides with that, the largest being @mikemcquaid has previously expressed a desire to move firmly away from if blah depends_on blah else depends_on blah statements outside of def install, and I don't want to push something through that just leaves the maintainers feeling dissatisfied.

Yeh, this stuff is currently a bit buggy so we're trying to move away from it.

Ultimately, what I'd like to do is just kill SSLv3 dead completely and tell software that depends on those insecure ciphers to go whistle, but evidently, that has its fair share of concerns and Tim has expressed a firm desire to not see that happen just yet.

I don't think that's going to happen ever, unfortunately. We wanted to do the same thing with Clang support, X11 support, etc. and ultimately it came down to "we won't accept any new formulae that do this and we'll nag old formulae to fix this".

I think it's OK to just build Python by default without SSLv3 support and not add the option and let people add that later if they want it. Really, though, in cases like that it seems like something they should/could just build from source (same with the OpenSSL formula itself).

DomT4 commented 9 years ago

Yeh, this stuff is currently a bit buggy so we're trying to move away from it.

Understandable. No complaints here.

I don't think that's going to happen ever, unfortunately.

Probably not, sadly. After all, It's taken the world the best part of two decades to even start wandering towards getting rid of SSLv3, It's fair to assume the transition away won't come immediately. There has been an enormous push to ditch SSLv3, but of course there are situations where that isn't possible and so on, so forth. It'll be good to whittle that number down over time, and eventually remove an SSLv3 option in OpenSSL, but I accept that day may be a little less soon than I otherwise would hope :grinning:.

So, we're okay to go ahead to rebuilding OpenSSL without SSLv3 but with an option to turn SSLv3 back on, which would require a from-source build? And for everything to be left as depends_on "openssl", with a new revision?

I'd be content throwing a temporary message in the OpenSSL caveats to say SSLv3 has been turned off by default and if you need it back do brew install openssl --with-sslv3 or similar, if that's useful?

alex commented 9 years ago

Why are we so quick to dismiss an OpenSSL without SSLv3 as an option? As far as I understand it, that's exactly what Debian Jessie is doing.

On Sun Dec 14 2014 at 1:47:02 PM Dominyk Tiller notifications@github.com wrote:

Yeh, this stuff is currently a bit buggy so we're trying to move away from it.

Understandable. No complaints here.

I don't think that's going to happen ever, unfortunately.

Probably not, sadly. After all, It's taken the world the best part of two decades to even start wandering towards getting rid of SSLv3, It's fair to assume the transition away won't come immediately. There has been an enormous push to ditch SSLv3, but of course there are situations where that isn't possible and so on, so forth. It'll be good to whittle that number down over time, and eventually remove an SSLv3 option in OpenSSL, but I accept that day may be a little less soon than I otherwise would hope [image: :grinning:].

So, we're okay to go ahead to rebuilding OpenSSL without SSLv3 but with an option to turn SSLv3 back on, which would require a from-source build? And for everything to be left as depends_on "openssl", with a new revision?

I'd be content throwing a temporary message in the OpenSSL caveats to say SSLv3 has been turned off by default and if you need it back do brew install openssl --with-sslv3 or similar, if that's useful?

— Reply to this email directly or view it on GitHub https://github.com/Homebrew/homebrew/issues/34634#issuecomment-66931380.

DomT4 commented 9 years ago

The default will be OpenSSL without SSLv3. I'd love to go OpenSSL without SSLv3 regardless, but I'm not going to ram it down Tim's throat, and I accept the concerns he raised are very real concerns, and even if a hard change would affect a tiny minority of users I still don't want to give a tiny minority of users a massive unexpected headache one day soon.

I agree that we tend to follow Debian Jessie or even Sid far more than we do Wheezy, but if the no-ssl3 option making it into Wheezy or Jessie becomes Wheezy, whichever happens first, is dependent on us getting this change merged in with maintainer consent, I'm content to meet on a middle ground, and disable it by default now, and review the option over a longer period of time as we get reaction and depending on how Debian and the other Linux distros roll.

I'm content that this is better security than the status quo, even with an option to turn SSLv3 back on, for now. The vast majority of users won't turn SSLv3 back on, and the ones that do are likely to have a better idea of why they want/need it, and that's an important factor here.

tdsmith commented 9 years ago

My objections aren't definitive; I believe in them but if I'm overruled I'll live to fight another day.

My concerns are mostly not specific to Python, though as far as that goes, I'm glad that Python 2.7.9 doesn't need patching to build against a SSLv3-less openssl; thanks for that news, @alex. I don't think we need to add sslv3 options to everything that links against openssl; adding an option to openssl should be sufficient.

With respect to timeline, my feeling is just that we'll be responsible for less anguish if we follow rather than lead Linux distributions here because they command more developer mind-share and have opportunities to do better integration testing. I don't believe that the mere availability of SSLv3 in OpenSSL constitutes an important security risk in the meantime.

It's helpful that Debian has the resources to take firmer editorial positions. Homebrew has a mechanism for supplying build time options that Debian lacks; I know we don't want them to proliferate but it's not hard to provision escape hatches for users who need them. I think there are advantages to being pragmatic and that, for better and for worse, is not always an idea that Debian embodies.

DomT4 commented 9 years ago

I'll live to fight another day.

I prefer not to fight at all :wink:.

I don't think we need to add sslv3 options to everything that links against openssl; adding an option to openssl should be sufficient.

Oh, No disagreement here. The suggestion was largely offered as a ponder towards reaching a middle group that everyone was happy enough with, but certainly, if we can just stick an option in OpenSSL it's a lot less maintenance for everyone to keep on top of over time. I was just grumbly about the idea of forcing everyone who wants to use our Python, which is a decent chunk of Homebrew users, onto an OpenSSL with SSLv3 enabled. That seemed like quite a heavy cost on both OpenSSL and Python, and I tried to mitigate it a little. But if Python now functions patchless without SSLv3 (Thanks for the heads-up to @alex), we can simplify that back into an OpenSSL option rather than a Python (or any similar formula) option.

With respect to timeline, my feeling is just that we'll be responsible for less anguish if we follow rather than lead Linux distributions here

My position is that we kinda are following the Linux distros here, or at least, the one Linux distro Homebrew prefers to share a boat with. Fedora also turned SSLv3 off AFAIK. Ubuntu haven't followed Debian yet, and I'm sure Ubuntu have their reasons for that, but we typically follow Debian rather than Arch or Ubuntu or Gentoo or any of the others. I'm not sure we're leading any horses to new water here, we're still following the usual Linux distro and usual distro tag that we check and lean against most heavily.

I think there are advantages to being pragmatic and that, for better and for worse, is not always an idea that Debian embodies.

I guess it could be argued that Debian is more ideologically driven than Homebrew is, and consequently feels less obligated to bend certain directions for users, in a way, perhaps. Debian take a pretty firm position in a whole chunk of places along the lines of "Well, if you want x with x, go compile it yourself. We won't support that via apt/etc". I tend to agree with Debian on a lot of that stuff, secure defaults, etc etc, but I appreciate that a lot of people aren't comfortable with a package manager, whether that's Brew, MacPorts, Fink, Apt, Pacman, etc making firm ideological choices for them. And there's merit to that argument, Debian's hiccup with OpenSSL years ago being an obvious warning point for anyone who favours stronger ideological decisions. But I don't necessarily think Homebrew making these decisions on a very narrow category of formulae is similar to Debian's more broad ideological nudges, whether people think that's a good thing or a bad thing, Homebrew deliberately narrows its scope over decisions like these largely to the cryptographic formulae, and even then, in a limited fashion.

MikeMcQuaid commented 9 years ago

I'd rather we didn't have an option until there's at least a few requests. It's essentially "enable a protocol that looks secure but isn't at all". There's always the system OpenSSL if people want SSLv3 support and given we've outright blocked some formulae in the past for encouraging poor security practises I don't think this is necessary.

DomT4 commented 9 years ago

I'll be starting work on this tonight, with the aim of having a PR ready for maintainer review within 24 hours. It's likely to take a few days for all the maintainers to look it over, and for us to resolve any bot hiccups that occur with every mass revision session. I'll pen this change without the option for now, per Mike's comments, but if there becomes a consensus against leaving the option out in the PR it'll be easy enough to add back in. Hopefully, after appeasing the bot, and taking any remaining maintainer feedback and suggestions, we can get this merged and done before we all get roaringly drunk for Christmas. OpenSSL, Zlib pkg-config & apr were all on my to-tee-up-for-discussion-and/or-action before Christmas list, and Zlib is done, apr is an open PR, and OpenSSL will be within the next 24 hours. After that, I'll try to ease off and let everyone enjoy the holidays ;)

Sent from my iPhone

On 15 Dec 2014, at 07:49, Mike McQuaid notifications@github.com wrote:

I'd rather we didn't have an option until there's at least a few requests. It's essentially "enable a protocol that looks secure but isn't at all". There's always the system OpenSSL if people want SSLv3 support and given we've outright blocked some formulae in the past for encouraging poor security practises I don't think this is necessary.

— Reply to this email directly or view it on GitHub.

azet commented 9 years ago

try to compile common dependencies with Google's boringssl and see if there are any failures. Seems more hardened.

DomT4 commented 9 years ago

^ We're three+ months down the line, post-POODLE (i.e. in a world where there's actual mainstream movement against SSLv3 finally), and OpenSSL have made the necessary changes upstream to properly support this change. As we discussed at the time of your PR, there was a lot of work still to be done by upstream to actually properly turn off the SSLv3 tap. OpenSSL have done that work now, and the new 1.0.2 branch is the ideal place for us to merge a change like this in.

By all means, feel free to contribute to the discussion, but there were valid reasons for rejecting the idea months ago and valid reasons for accepting the idea now - One of the biggest being the relatively new mainstream rejection of the protocol.

DomT4 commented 9 years ago

With respect, we've had this discussion before. Yes, It is well known TLS1.2 is the last really secure protocol - Yes, Google and AGL have acknowledged and said this much. However, TLS1.2 adoption sucks server-side. Adam L has said (repeatedly) that TLS1.2 adoption sucks - It currently sits at an all-time high of 52% global adoption across SSL/TLS available sites. That is a whole 48% of servers that will not talk TLS1.2.

Look, I would love to disable everything but TLS1.2 right now, would love to. I'd love to get the world suddenly using TLS1.2 and PFS everywhere, but it's not happening overnight, and no package manager is going to break SSL/TLS for over 50% of their users' connections. Nobody. TLS1.0 has 99.7% adoption support; that is, right now, the comfortable limit.

At some point, you have to draw a line between ultimate security and users being able to do anything, and this is the line that Debian is adopting, and various other Linux distros are working towards adopting, and Homebrew is not going to suddenly pole-vault over those distros and break absolutely everything for end users.

MikeMcQuaid commented 9 years ago

For anyone following/linked to this thread: @azet has been pointed to our code of conduct multiple times and seems to be unwilling or unable to behave politely. Homebrew welcomes criticism but most of all we welcome well-implemented improvements that don't break more than they fix. There are relatively few maintainers, none of us have ever received any money for working on Homebrew and all of us work on it in our free time. As a result we're happy to help people contribute to the project but we have no interest in moderating a forum for mudslinging. As a result, comments may be edited or deleted for moderation purposes. You do not have the right to say whatever you want on our issue tracker. If you have something you really need to tell the world may I suggest you do so on Twitter or your personal blog.

All previous and any further comments by @azet in this thread will be immediately deleted. He is well within his rights to delete the previous comments I've edited if he feels they no longer represent his position.

MikeMcQuaid commented 9 years ago

This thread has been locked temporarily as @azet continues to try and post in it.

MikeMcQuaid commented 9 years ago

Unlocked the issue as @azet has apologised privately and we've sorted a bunch of stuff out. Thanks @azet.

DomT4 commented 9 years ago

Thanks guys. Appreciate the unlocking, and glad things have been resolved to a happier ground :+1:

DomT4 commented 9 years ago

Per the open PR at #35060, closing this. No point having the discussion in two places I guess. In around 10 days, we get to make a decision as to whether to go ahead with this idea or postpone it indefinitely.