Aryeh Gregor wrote:
I'm not actually sure what problem is being solved by restricting commits to core, though. If someone can commit a backdoor without anyone noticing, then they could almost as easily get one committed from a Bugzilla patch without anyone noticing. Except that no one looks at Bugzilla patches, but in that case the argument becomes "less changes means less security risk", which is throwing out the baby with the bathwater. Extensions authors might have occasion to adjust core code occasionally; that's one of the advantages of being able to commit your extension to Wikimedia SVN.
I think the point is on giving write access to untrusted people that only want to mantain its insecure pet extension. A commit to core by any of them *should* raise quite more eyebrows than a commit by a core dev, getting a deeper scrutiny, but some additional layer isn't necessarily bad. It's not too friendly to take back someone with svn access to bugzilla for a tiny core edit, though. The typical case for an extension author to touch core would be adding a hook, but he may also want to start contributing at an higher level.
If a vulnerability gets committed, it would be for ignorance, not for malice. Yesterday's issue with bug 21140 cames to me, where code got via several hops until svn. OTOH if badguy tried to trick us, he would have problems to get someone for reviewing and committing it.
ialex has been doing a good work recently, and there are some periods when bugs are reviewed easier than others, but once a bug has crossed the head, the tail can be quite long (perhaps becasue they are the hardest?).
But I don't see the point in an enforced extensions/core distinction. Especially if extensions used on Wikimedia are counted as extensions and not core!
The same permissions as core should be set to them as they get enabled.
PS: I still have a number of patches awaiting on BZ in case someone feels remorses for this thread. :)