Posted by klausi on September 28, 2014 at 7:35am
If we have promoted a user with the git vetted user role and find security issues in their code afterwards we should not remove the git vetted user role. This can always happen and we have a process to deal with security issues.
If the project has no stable release yet please report the problem as critical issue in the public queue.
If the project already has a stable release please please report the problem with the "Rport a security vulnerability" link on the project page. That will create a private issue on security.drupal.org where the coordination with the security team happens.
Comments
Oversee newly git vetted users
That would be the nice idea to oversee the promoted projects code for quite some time and other projects that they may promote in that time.I suggest for next ~ 3 months for security review only. I know this may increase the load on the git admins but its a simple check after 2-4 weeks and will not take > 5-10 minutes. What do you think ?
Security issues can also happens in the existing projects but there are less chance than the new projects of newly git vetted users with more releases coming soon.
Thanks
Naveen Valecha
Naveen Valecha
https://www.valechatech.net
I don't think that is
I don't think that is necessary, other users and developers can report security issues as usual when they work with the projects.
Ditto.
I don't think this is a real need. There is a process already in place.
I will also mention that a security audit isn't a simple 5-10 min thing. Most times it involves tracing out user input to output, which means jumping around a lot in code, which can be time consuming if you aren't / can't use an automated tester (which I made).
Not to digress too much and
Not to digress too much and not downplay your automated tester, but...I would say it is useful for finding most of the cases of persistent xss. That's our biggest problem in contrib and is a great thing to catch.
There's still access bypass, reflected xss, csrf, sql injection, and a few dozen other less common issues to worry about.
More broadly: thanks to klausi for posting this. I agree we should just follow the normal process for security issues.
knaddison blog | Morris Animal Foundation
Please don't increase the work load of git admins
@naveenvalecha, is there any evidence that newly promoted projects have more security issues than other projects?
If the answer is not a clear "yes", then there is no need to establish such a procedure.
As you point out yourself: The downside of doing this is that it will increase the work load of gits admins. Git admins is a scarce resource (just now: 314 open issues in the review queue - 63 with status RTBC). We should be wary of asking them to do more tasks until this situation changes (which is not likely to happen soon).
there was just probability of security issues
@gisle,
I suggested the probability in my earlier reply but there is not any evidence for that.
Naveen Valecha
https://www.valechatech.net
@naveenvalecha, also since
@naveenvalecha, also since this is all volunteer, nothing stops you or anyone else from tracking/following up and opening issues as per security guidelines.