On 30 Jul 2013 21:41, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
Donald Stufft <donald <at> stufft.io> writes:
You don't happen to be a random security professional, you are
of that upstream project and you have access to non-public (possibly confidential) data about its infrastructure, which gives you responsibilities towards your peers.
I don't think I would be the only one to be angry if an infrastructure member starting publishing working exploits for unfixed vulnerabilities in
infrastructure. It is a completely irresponsible way to act when you are part 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.
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
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.)
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.
If you feel I'd be overstepping my bounds then complain to my superiors, Richard/Nick on
packaging side of things and Noah on the Infrastructure team side of
actually part the pdo people to the 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
Effectively he does, yes. Richard is responsible for approving PyPI API changes (including PyPI specific PEPs), I'm BDFL delegate for other packaging PEPs and Noah has final say over the operation of the python.orginfrastructure. One or more of us are the ones that need to say yes on potentially controversial changes, so the responsibility for any mistakes ultimately lies with us, rather than Donald (and I'm greatly appreciative of the huge amount of work he is putting into improving the PyPI security story). publish an
exploit, rather than take the responsibility of doing it themselves - or, rather, not doing it at all)
If Donald informed us of a vulnerability and we refused to allow him (or anyone else) to take the necessary steps to close it, then he would be *completely* justified in publishing full details of the vulnerability, up to and including working exploit code. It won't come to that though, because we're taking this seriously and closing security holes as quickly as is feasible while still ensuring a reasonable level of backwards compatibility :) Cheers, Nick.
Regards
Antoine.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig