[Distutils] a plea for backward-compatibility / smooth transitions
donald at stufft.io
Tue Jul 30 13:53:33 CEST 2013
On Jul 30, 2013, at 7:40 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Donald Stufft <donald <at> stufft.io> writes:
>>> You don't happen to be a random security professional, you are actually part
>>> of that upstream project and you have access to non-public (possibly
>>> data about its infrastructure, which gives you responsibilities towards your
>>> I don't think I would be the only one to be angry if an infrastructure
>>> starting publishing working exploits for unfixed vulnerabilities in the pdo
>>> infrastructure. It is a completely irresponsible way to act when you are
>>> of a project or community.
>> I don't really care if you'd be angry.
> Great to hear. This mindset is typical of many "security specialists":
> you're ready to tell everyone to go f*** themselves (I don't know how to
> voice this differently) if you think you have a higher mission to
> denounce some vulnerability.
Keeping an issue secret doesn't make people more secure, it only prevents
them from making an informed decision about the things they use.
>> The point of Full Disclosure (and it's cousin
>> Responsible Disclosure) is to A) Inform everyone involved that they are taking
>> a huge risk by using a particular thing and B) Provide incentive to people to
>> fix their shit.
> This does not necessarily involve publishing working exploits. By giving out
> code that can immediately attack and bring down the pdo infrastructure, you
> would be doing something else than merely "informing the public".
> (neither Bruce Schneier nor Wikipedia states that Full Disclosure implies
> publishing working exploits, btw. I suppose it means there is at the
> minimum some contention, rather than consensus, over the issue.)
Partial disclosure is typically publishing enough information to allow people
to make an informed choice but (hopefully) not enough information to allow
others to attack it.
Full Disclosure implies laying out the full details of the vulnerability. It doesn't
necessarily mean wrapping it up in ready to run code but they almost always
provide enough information so that anyone with a cursory understanding of
programming (or the area it affects depending on how hard it is to replicate)
can implement the attack and reproduce it.
The problem with Partial Disclosure is that often times vendors/upstream/whatever
will simply call the problem theoretical and still attempt to not fix things.
>> If I can find a vulnerability then so can someone else.
> You may (and probably do) have domain knowledge and inside knowledge that
> others don't.
There's not really any inside knowledge. Everything is OSS.
Domain knowledge? Sure, but I really hope we aren't relying on people not
knowing enough about how the tooling works to exploit it.
>> If you feel I'd be
>> overstepping my bounds then complain to my superiors, Richard/Nick on the
>> packaging side of things and Noah on the Infrastructure team side of things.
> "Superiors"? Are you making things up, or do you have an org chart to back that
> up? :-)
> (regardless, I would be surprised if any of those ordered *you* to publish an
> exploit, rather than take the responsibility of doing it themselves - or,
> rather, not doing it at all)
Nick is the BDFL delegate for packaging tooling and Richard is the same for PyPI
and I generally consider my involvement as a PyPI admin to be under him.
Noah is in charge of the Infra team of which I am a member.
> Distutils-SIG maillist - Distutils-SIG at python.org
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Distutils-SIG