Emails to support get put into a ticket (really just a discussion that has an open / resolved status). The trouble is that any replies go to the reporter, so we don't tend to collect internal information on them, and they disappear into 1 developer's inbox (whoever takes it). Hence proposing a private issue tracker to run alongside it for actually working thru the issues and then reporting back via the ticket.
You might create a specific support ticket just for security. This could automatically create the github issue opaquely. Misplaced ones you could use the manual create gitub issue.
I like letting it go into the main support queue and letting the staff deal with it manually so that there is maximum visibility internally. I could see a security-only email/ticket queue being shunted to developers who are overburdened.
I did add a note to the README a few weeks ago to specify that security issues should go to support at vanillaforums.com.
If you are going to have an internal private repo using the issue tracker for security issues. How about the idea of using webhooks so when you label an issue, it would update a public record of how many issues of that label are open?
Comments
From what you described it is on a single ticket? Would then not make more sense to open a ticket each issue?
grep is your friend.
Emails to support get put into a ticket (really just a discussion that has an open / resolved status). The trouble is that any replies go to the reporter, so we don't tend to collect internal information on them, and they disappear into 1 developer's inbox (whoever takes it). Hence proposing a private issue tracker to run alongside it for actually working thru the issues and then reporting back via the ticket.
ok that makes sense, so each report still get a ticket. Can they comment on the ticket, using that email?
grep is your friend.
Yes, and any reply by them re-opens it regardless of whether it's been marked resolved previously.
Nice. I think this need some awareness. Even on the OS site.
grep is your friend.
You might create a specific support ticket just for security. This could automatically create the github issue opaquely. Misplaced ones you could use the manual create gitub issue.
grep is your friend.
I like letting it go into the main support queue and letting the staff deal with it manually so that there is maximum visibility internally. I could see a security-only email/ticket queue being shunted to developers who are overburdened.
I did add a note to the README a few weeks ago to specify that security issues should go to support at vanillaforums.com.
Nobody reads the README
grep is your friend.
One more question
If you are going to have an internal private repo using the issue tracker for security issues. How about the idea of using webhooks so when you label an issue, it would update a public record of how many issues of that label are open?
https://developer.github.com/webhooks/#events
grep is your friend.