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. :)