Date: Wed, 11 Mar 2015 11:48:06 -0400 From: Kurt Seifried <kseifried@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777 On 03/10/2015 08:05 PM, Michael Samuel wrote: > Hi Kurt, > > Your corporate pissing match with Oracle is not helpful. I think there's probably some cultural disconnect here that is causing issues, a big part of Red Hat is "upstream first" and doing things the open source way. Let's look at who wrote PEP 466 and who he works for. Hint: it's Red Hat. We're obviously interested in fixing this, BUT we also have the challenge of fixing this without breaking any software, software which again, we haven't seen and will never see. Read the sections: Rejected alternative: just advise developers to migrate to Python 3 Rejected alternative: create and release Python 2.8 Rejected alternative: distribute the security enhancements via PyPI Rejected variant: provide a "legacy SSL infrastructure" branch Rejected variant: synchronise particular modules entirely with Python 3 Rejected variant: open ended backport policy this is non trivial stuff. However here's the cool thing. If Oracle thinks they have a good solution they can participate with upstreams, or simply try it. Build some RPMs, make them available and gather test data (e.g. we ran these test suites/apps and X percent broke/didn't break/etc.). Working code and experimental data is (almost) hugely more valuable then discussions on a mailing list. At least we'll find out what doesn't work if it doesn't work (that's the experimental data part). Personally what I'm more interested in right now is better testing/reproducers for SSL/TLS issues for the community rather then playing random whack-a-mole with specific issues (especially ones that we already have smart people working on). Much like /tmp issues the solution that will save us is not to fix every /tmp issue but rather do more intelligent things like poly instantiated tmp or systemd per process tmp. Sadly I don't see such an easy possibility with TLS/SSL, but if we have a decent test framework/reproduction ability it will make finding, fixing and verifying these things a whole lot easier long term. > On 11 March 2015 at 02:56, Kurt Seifried <kseifried@...hat.com> wrote: >> My experience is a lot of people propose a LOT of things on email lists, >> but when it actually comes down to them doing the work, nothing happens >> because quite often the people proposing the work don't have the >> expertise or ability to do it. oss-security@ archives are littered with >> such examples (e.g. the whole code audit thing). > > I proposed this in the context of me giving up reporting these sorts of bugs > to RedHat (go search my BZ account), and frankly since you don't have > the resources to perform simple tests against your main products (RHEV, > Satellite, RHN), then a blanket solution seems reasonable. > >> So it's not that I'm unwilling, I simply don't see why you need massive >> corporate/community buy in at this point, premature optimization and all >> that. Build a solution, or more than one solution and try them out, then >> report back to oss-security@ with what works/doesn't work. In general >> the best way to determine what the best solution is for a problem is to >> try several solutions out. Prototype code and experimental data is worth >> 1000 meetings. > > It's not a problem because nobody's looking. Holy crap, just look at > Satellite 6 and tell me you think that product doesn't need more than an > audit. I am actually working on something that will hopefully provide a better solution (for values of speed and ease of fixing flaws) than a traditional audit/code fix, (I'd rather address entire classes of security flaw rather than one instance of the flaw at a time). But like all things security infinite workload delays specific projects. > Regards, > Michael > -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ