The main obstacle in making issues visible is our lack of knowledge of how to configure JIRA to do that. It is rumored to be doable, but it is non trivial, and someone needs to spend some time to figure that out.
The inability to control who can see SECURITY-* issues on individual issue basis is causing a lot of other problems, such as merging two duplicate issues together, or tracking vulnerabilities in plugins. Disclosure of vulnerabilities is a big one, too. Incidentally I've been lately working on containerizing JIRA <http://lists.jenkins-ci.org/pipermail/jenkins-infra/2015-March/000276.html> to simplify upgrades, and as a side effect of this, it's a lot easier now to create a clone of issues.jenkins-ci.org and experiment with the potentially dangerous setting changes like this. I agree with Jesse that advisories not informative is a separate problem. If you or anyone knows some better written advisories that we should mimic, please let me know. When I originally started doing it, I looked around and just tried to follow the model, I do remember looking at advisories from Atlassian, like this one <https://confluence.atlassian.com/display/DOC/Confluence+Security+Advisory+2010-09-21> . I do try to cover who can mount an attack (an attack that can be done by anonymous user vs an attack that requires a certain existing permission in Jenkins), Whether it's safe for people who are running Jenkins inside firewall is a bit strange question to me --- if you trust people who have access to your network, then you don't care about any vulnerabilities, no? But perhaps there are several important questions like that, for which we can provide Yes/No answers. 2015-03-27 4:46 GMT-07:00 Jesse Glick <[email protected]>: > On Fri, Mar 27, 2015 at 5:09 AM, Christopher Orr <[email protected]> wrote: > > The security advisories themselves tend to be very short, making it hard > to > > make a judgement on how urgent it really is to update (e.g. if I don't > allow > > anonymous access, or my instance isn't publicly-visible, perhaps certain > > issues aren't critical). > > If this kind of judgment is not possible given the current advisories, > then that is a problem in the advisories. The intent is that > everything you need to know to judge whether or not *you* need to > accept this update is contained within the text of the advisory. > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr39BSSjXSoF3mbYi2LF1PpKyVmxmY1571APuJxNt_BvjA%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4yEatbJD%3DwFKKfYSRg__1Qrre1cWutb4yYB1_GQmupSQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
