Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96662
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.179 as permitted sender)
To: Anatol Belski <anatol.php@belski.net>,
 'PHP Internals' <internals@lists.php.net>
References: <3a5408bc-b71d-920c-45e4-b9be02350b6c@gmail.com>
 <01a901d22e06$ca4e3450$5eea9cf0$@belski.net>
Message-ID: <d8d88f58-a632-45d6-ba02-b9f9582eb30b@gmail.com>
Date: Sun, 30 Oct 2016 15:00:51 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <01a901d22e06$ca4e3450$5eea9cf0$@belski.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Security issue handling
From: smalyshev@gmail.com (Stanislav Malyshev)

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
smalyshev@gmail.com