Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Mar 2015 12:37:17 -0400
From: Donald Stufft <>
Subject: Re: Another Python app (rhn-setup: rhnreg_ks) not checking hostnames in certs properly CVE-2015-1777

> On Mar 11, 2015, at 12:28 PM, Kurt Seifried <> wrote:
> On 03/11/2015 10:18 AM, John Haxby wrote:
>> I think there's a misunderstanding here.  I was asking for cooperation
>> to come up with a solution, participating with other people who, like,
>> I assumed, Red Hat, have an interest in solving this specific problem
>> without breaking existing (admitedly flawed) applications.  I know it's
>> not straightforward, if it was I'd've just produced a patch.  I'm still
>> happy to work with anyone to sort this out.
> Me too. But I trust Nick and he's smart. I don't stick my finger into
> every security pie because 1) I'm not an expert in all things and 2) I
> have a finite life span and need to sleep.
> So again my advice is: work with upstream/the community. You don't need
> my input yet. Nick has spent far, far, far more time thinking about how
> to fix Python/SSL/TLS then I ever will. Once you have a definitive
> solution that you are pretty sure works, then please, by all means poke me.
>> [snip]
>>> 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.
>> If this fixes the specific problem as a side effect that would be
>> great.  Details are lacking though, and there's no obvious link here
>> to making adapting PEP-466 for backwards compatibility (and I have
>> absolutely no arguments with the rejected solutions for Python).
> This is a different project and related to web interfaces (which are a
> growing pain point security wise).
>> This is my last message on the list on the subject.
>> jch
> --
> Kurt Seifried -- Red Hat -- Product Security -- Cloud
> PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

If you want opt in better security, a little bit of monkey patching and
a module on PyPI would fix that. The reason PEP 466 rejected something on
PyPI is because it was opt in and we didn’t consider opt in to be a good
enough fix for upstream Python.

Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ