Hi Stas, > -----Original Message----- > From: Stanislav Malyshev [mailto:smalys...@gmail.com] > Sent: Sunday, October 30, 2016 11:01 PM > To: Anatol Belski <anatol....@belski.net>; 'PHP Internals' > <internals@lists.php.net> > Subject: Re: [PHP-DEV] Security issue handling > > 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. > That was the exact idea. I, at least, am going for ports a week before release, as mentioned. But even otherwise - having a cut a week before is what addresses the QA concerns in first place, that Remi and you also expressed. Say, if there is a vulnerability, which is not disclosed and present for years - while it's not good it'd go into release a month later, still it's better than a possible another bug introduced because of the last minute or unreviewed patch. It wouldn't of course affect a situation, where a fix is urgent.
> > 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. > What I had in mind, in first place involving the karma holders and ext maintainers. Like Jakub and Christoph already expressed the willingness to do fixing regularly, other active core commiters or any other trusted person could be asked to help on demand. Of course, we don't know how it would work, until it's started to be done this way. It could be, that asking some random active and known contributor to review just one patch would be more effective, that asking the same person to do it regularly as in security team. > > 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. > Just as a loud thought - when seeing same person makes authentic reports, using good tools, there's no premature disclosure, so it is a meaningful behavior. What i've mentioned earlier and plea for - it were great to have a constant security response team, some structure that allows to ensure fixes, reviews and QA on security patches regularly. It is absolutely clear, that it is much better to involve only people with the karma and contributing actively. But I've an impression, and see it on my example as well :), that people currently contributing on the constant frequency, have not necessarily interest or time on pure security patches handling. IMHO it indeed makes sense what Rasmus said, to send a dedicated call for security team participation and see what happens. And as a fallback, if no enough reaction is to see, check other ways to achieve more QA. With the binary only testing - it's likely that good people are to find in the PHP projects, and I could take on the builds but would require a machine where it could be done and shared. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
