Title Security policy should be visible on top page of tracker, maybe every page
Priority bug Status chatting
Superseder Nosy List eric.araujo, ezio.melotti, gbrandl, loewis, pitrou, stephen
Assigned To ezio.melotti Topics

Created on 2011-04-17.13:52:04 by stephen, last changed 2012-05-23.16:37:25 by ezio.melotti.

File name Uploaded Type Edit Remove
issue393.diff ezio.melotti, 2012-05-23.16:37:13 text/plain
issue393.png ezio.melotti, 2012-05-23.16:37:25 image/png
privacy.patch stephen, 2011-08-21.07:56:50 text/plain
msg2013 (view) Author: stephen Date: 2011-04-17.13:52:04
Python's documentation should make it clear at the most important entry points that the appropriate place to report possible security issues is, not the tracker.  In particular, the tracker's top page (the one you get from should make that clear.
See the News/Security Advisories on Python's main pages and Brian Curtin's 2011-04-14 post for reasonable descriptions of the de facto policy.

The Tracker documentation probably should be updated with this as well.

It might be a good idea to have a way for triagers to suppress display of security issues by classifying them as security (eg, via priority, keyword, or possibly even resolution).

Xref thread starting at
msg2014 (view) Author: eric.araujo Date: 2011-04-18.15:48:20
Closing with an “invalid” resolution would certainly be appropriate.
msg2015 (view) Author: stephen Date: 2011-04-18.16:32:18
That would help, and is available now.

However, a search of closed issues with "security" or "exploit" or "overrun" somewhere in their text would bring most of them up.
msg2016 (view) Author: loewis Date: 2011-04-18.19:46:49
If some member of could speak up: that would be appreciated. It certainly possible to implement any hiding/deletion/obfuscation that is desired. However, I'd like to hear some "official" statement as to what policy the tracker should follow exactly.
msg2018 (view) Author: ezio.melotti Date: 2011-04-18.20:02:58
Some warning message could be shown when type:"security" is selected, but if security issues are not supposed to go through the tracker maybe that type shouldn't exist in the first place.
A fixed message in the issue creation page might be OK too, as long as it is not too invasive.  Adding some instructions to the devguide is definitly OK.

BTW, a more effective and already available way to "hide" those messages is to mark them as spam -- but that's just an ugly workaround.
msg2019 (view) Author: ezio.melotti Date: 2011-04-18.20:16:47
Another alternative is to add to the nosy automatically when a "security" issue is created (this can be done anyway) and make the issue visible only to a limited group of person (e.g. core developers and the OP).
msg2020 (view) Author: loewis Date: 2011-04-18.20:20:47
Because of all these options I'd like some of the security team to state how they actually want it. There is no point in changing something proactively that is then still undesired.
msg2229 (view) Author: pitrou Date: 2011-08-20.12:51:20
Judging from the response, it certainly seems there's no actice security team :)
msg2230 (view) Author: ezio.melotti Date: 2011-08-20.13:02:44
I wrote them to see if there's someone on the other side.
In I proposed a doc patch to document
If they don't reply I'll just commit that patch and close this.
msg2231 (view) Author: gbrandl Date: 2011-08-21.06:52:43
Another way would be to find out if Roundup supports "private" issues that are not visible to default users. Then security could use these to track the security issues.
msg2232 (view) Author: stephen Date: 2011-08-21.07:56:50
It's possible to do this, although I don't have a patch offhand.  The basic idea is that given in the attached patch, which uses the existing concepts of "assigned to" and "admin role" rather than a separate configurable group.  Probably you can just create a security role and substitute that check for "assigned to".

I don't know if deleting "admin" makes sense or not.  Of course admins can add the security role to themselves anyway, so convenience in dealing with security issues that need to be deleted because they're spam etc is one consideration.  OTOH, "if I don't need to know I don't wanna see it" is another factor.

Note that the patch defaults to privacy (which is appropriate in my situation).  Probably for Python you would want this dependent on the issue type or priority of "security".

I also don't know how secure this really is.  I know it's more secure than the people who are using it, which is good enough for me.<wink/>
msg2233 (view) Author: pitrou Date: 2011-08-21.11:58:04
> Another way would be to find out if Roundup supports "private" issues that are 
> not visible to default users. Then security could use these to track the
> security issues.

Who would it be visible to? If the security team is pining for the trees, isn't this proposal unconstructive?
msg2525 (view) Author: ezio.melotti Date: 2012-05-23.16:37:13
> In I proposed
> a doc patch to document

This is now documented in the devguide, the attached patch also adds a note that appears when the "security" type is selected.
Date User Action Args
2012-05-23 16:37:25ezio.melottisetfiles: + issue393.png
2012-05-23 16:37:13ezio.melottisetfiles: + issue393.diff
messages: + msg2525
2011-08-21 11:58:04pitrousetmessages: + msg2233
2011-08-21 07:56:50stephensetfiles: + privacy.patch
messages: + msg2232
2011-08-21 06:52:44gbrandlsetnosy: + gbrandl
messages: + msg2231
2011-08-20 13:02:44ezio.melottisetassignedto: ezio.melotti
messages: + msg2230
2011-08-20 12:51:20pitrousetnosy: + pitrou
messages: + msg2229
2011-04-18 20:20:48loewissetmessages: + msg2020
2011-04-18 20:16:48ezio.melottisetmessages: + msg2019
2011-04-18 20:02:58ezio.melottisetmessages: + msg2018
2011-04-18 19:46:49loewissetstatus: unread -> chatting
nosy: + loewis
messages: + msg2016
2011-04-18 16:32:18stephensetstatus: chatting -> unread
messages: + msg2015
2011-04-18 15:48:21eric.araujosetstatus: unread -> chatting
nosy: + ezio.melotti, eric.araujo
messages: + msg2014
2011-04-17 13:52:04stephencreate