[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550063B6.4010707@redhat.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
