Hi Stas, Thanks for bringing this up.
> -----Original Message----- > From: Stanislav Malyshev [mailto:smalys...@gmail.com] > Sent: Monday, October 24, 2016 7:16 AM > To: PHP Internals <internals@lists.php.net> > Subject: [PHP-DEV] Security issue handling > > Hi! > > I'd like to discuss an issue about security bugs handling. > > We have a security repo which I and others check into bugs from time to > time. The idea is for these to be reviewed by people having access there > before we merge them, and then merge after the release. > > This, however, is not happening at all. The patches, as far as I know, > are not reviewed at all, and merging a bunch of patches last minute with > no review is extremely dangerous. I am trying my best with my patches, > but I'm only human, and I feel increasingly uncomfortable having so many > unreviewed patches in the release. > > So, how we can fix it? > > a. We could merge some of the patches on RC stage, even though that > might expose some issues. Related to my response in another bug, we could indeed make definitions and partially merge the low severity patches already into RC. Also, with the high severity patches - it'd make sense to define some time range where new patches are acceptable for the next 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 serucity repo, ported and tested 5 days before tag. Fe Thursday/Friday in week before final, it is required to have all the security patches prepared. Until some urgent patch were already disclosed, so it would have to be applied right at the last second, having more buffer will lead to more stability. > b. We could somehow improve review mechanism beyond security repo we > have now - ideas? IMHO it were the best option, indeed building a security response team. We need more people on this. 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. > c. Get some specific people to volunteer to review patches in security > repo regularly - how? Any takers? > 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. 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. On my side, I'm already intended to go deeper into the security patches at least a week before finals. Until it's defined otherwise, I'll be at least preparing the 5.6->7.0 ports and testing so we have some more time to discuss and more chance to avoid tag delays. I might have time to participate on security tickets, when 7.0 goes into security only mode, but unfortunately can't afford full security team participation ATM. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
