1 |
On Mon, Jul 4, 2016 at 11:26 PM, Aaron Bauman <bman@g.o> wrote: |
2 |
> |
3 |
> The subject of this particular mailing list post is a little alarming and |
4 |
> over reactive. We are not running around p.masking everyone's packages, but |
5 |
> issues that have been outstanding for years often result in such courses of |
6 |
> action. I personally told Anthony I should have requested his assistance |
7 |
> initially on the matter, and I do apologize for that. He is an active |
8 |
> developer who would respond in a timely manner. So once again, I do |
9 |
> apologize. |
10 |
|
11 |
Thanks, and my intent wasn't to suggest that I thought there was any |
12 |
kind of a trend here. I just wanted to agree that this shouldn't be |
13 |
how it happens. It sounds like we're already on the same page, which |
14 |
isn't surprising since this was the first complaint I've heard in a |
15 |
while. |
16 |
|
17 |
> Finally, that does not dissolve the developer of providing usable, |
18 |
> substantiated, and verifiable information regarding the vulnerabilities. |
19 |
> The idea that a developer gets to choose whether or not they do so should |
20 |
> not be considered. |
21 |
|
22 |
Also agree. I think we need to have a reasonable security policy, but |
23 |
clearly there can't be unresolved questions about whether a particular |
24 |
package-version is vulnerable or not. If we don't get a question like |
25 |
that resolved in a timely manner then the version should be masked. |
26 |
Users can then make an informed decision as to whether they want to |
27 |
take the risk in unmasking it. |
28 |
|
29 |
Our security policies are a tree-wide QA commitment that our users |
30 |
rely on. We shouldn't advertise a security policy that we aren't |
31 |
willing to enforce. |
32 |
|
33 |
-- |
34 |
Rich |