Python's documentation should make it clear at the most important entry points that the appropriate place to report possible security issues is security@python.org, not the tracker.  In particular, the tracker's top page (the one you get from http://bugs.python.org/) 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 http://mail.python.org/pipermail/python-dev/2011-April/110722.html.

Closing with an “invalid” resolution would certainly be appropriate.

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.

If some member of security@python.org 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.

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.

Another alternative is to add security@python.org 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).

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.

Judging from the response, it certainly seems there's no actice security team :)

I wrote them to see if there's someone on the other side.
In http://bugs.python.org/issue12792 I proposed a doc patch to document security@python.org.
If they don't reply I'll just commit that patch and close this.

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.

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/>

> 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?

> In http://bugs.python.org/issue12792 I proposed
> a doc patch to document security@python.org.

This is now documented in the devguide, the attached patch also adds a note that appears when the "security" type is selected.