Hi! > release. Say, as we do it now, we tag two days before. It could be > defined, for example, that any security patches intended for release > inclusion, have to be merged into security repo, ported and tested 5 > days before tag. Fe Thursday/Friday in week before final, it is
That's nice but most patches right now are in security repo long before, and still nobody reviews them. Also, the reality is that I mostly work on patches on weekends, so that means either any of the patches I work on one of the 4 weekends can't be merged for a month or we need a better model. > Maybe, it'd make sense also to have a finer privileges system on BT. > Fe, several people could be allowed to review some selected tickets > on BT, without having the actual security repo access. Say, any > security team participant would be able to assign some new reviewer > to a particular ticket. That probably can be done, but let's say it's done now. Who I would be assigning to the new issue? I have no idea who wants/can review it. > OFC it'd be ideal to have some karma holders to participate. And > another option, which is IMHO eligible - we could invite several > reporters. There is already a couple of people, who regularly report > security issues and keep them confident until they're publicly > disclosed. IMHO it is a good base for trust. The reporter is asked to review the patch anyway. I don't think I feel comfortable inviting other reporters - unless I know who they are, which right now is not true for most of them. > Also, having people even without iternals knowledge, that could just > test, were useful as well. For that case, we could find more people > even without php-src karma or access to the security repos. Providing > some test binaries only wouldn't be that hard. In that case, while we > couldn't disclose the actual security issues, the "blind testing" > could have a positive effect in determining unforeseen issues, too. Hmm I don't know. I certainly won't have time to arrange binary builds usable for people with no dev knowledge, but if somebody volunteers to organize it, fine. But that again means a) disclosing security issues to people before fix is available, so this should be people we know and b) that should be people that want to commit substantial amount of time. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
