Security issue handling View as Markdown

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.

Yes, in the end this is about getting Stas some help here. He has been
doing an incredible job for years now handling all these annoying
off-by-one and >2gb string bugs. I occasionally read through the patches,
but I haven't been doing it consistently and even though there are a few
other people on security@ who occasionally look through the patches, it
obviously isn't enough.

As a first step perhaps we just need to expand security@ a bit with the
specific call for volunteers to help review security patches?

I would be happy to help with review / fixes especially for json that I
maintain and openssl that I sort of try to maintain too. But I could also
help with review of some other exts if time allows.

Cheers

Jakub

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.

Yes, in the end this is about getting Stas some help here. He has been
doing an incredible job for years now handling all these annoying
off-by-one and >2gb string bugs. I occasionally read through the patches,
but I haven't been doing it consistently and even though there are a few
other people on security@ who occasionally look through the patches, it
obviously isn't enough.

As a first step perhaps we just need to expand security@ a bit with the
specific call for volunteers to help review security patches?

I'm gladly willing to help with GD related security issues (at least).
It's also okay for me to get assigned to these, when Pierre is busy. :-)

--
Christoph M. Becker

2016-10-24 17:19 GMT+02:00 Rasmus Lerdorf rasmus@lerdorf.com:

As a first step perhaps we just need to expand security@ a bit with the
specific call for volunteers to help review security patches?

Maybe we should make the security issues available to those who
actively contributes to PHP, like Jakub, Christoph who both replied,
Yasuo for session stuff (I'm sure he is interested) and others who are
apart of the development team with regular commits. RMs already are on
the security list.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Hi,

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.

I'm gladly willing to help with some security issues if you need and want.

Hi Stas,

-----Original Message-----
From: Stanislav Malyshev [mailto:smalyshev@gmail.com]
Sent: Sunday, October 30, 2016 11:01 PM
To: Anatol Belski anatol.php@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

Morning,

Stas, consider Leigh vouched for, please add him to sec lists and private
bugs.

I've given him karma to look at the security (private) bugs.

cheers,
Derick

Hi!

c. Get some specific people to volunteer to review patches in security
repo regularly - how? Any takers?

I'd be happy to help with reviewing and also setting up a private C.I.
to build and run the test suite regularly, if you think that's a good
idea.

I think it's a great idea, how could this be done? I'd be happy to run
CI on security branch, it probably would remove 95% of the issues we had
with merges.

Travis can be run in local docker containers, so given the infrastructure
to run the container, it shouldn't be a problem to use the existing travis
configuration for private CI

Hi,

-----Original Message-----
From: Stanislav Malyshev [mailto:smalyshev@gmail.com]
Sent: Saturday, November 5, 2016 8:13 PM
To: Matteo Beccati php@beccati.com; PHP Internals
internals@lists.php.net
Subject: Re: [PHP-DEV] Security issue handling

Hi!

c. Get some specific people to volunteer to review patches in
security repo regularly - how? Any takers?

I'd be happy to help with reviewing and also setting up a private C.I.
to build and run the test suite regularly, if you think that's a good idea.

I think it's a great idea, how could this be done? I'd be happy to run CI on
security branch, it probably would remove 95% of the issues we had with merges.

At this point, what were our course of action? Seems there might be multiple tasks

• granting the willing devs security karma
• setting up a private CI
• organizing a security team

It probably would make sense, to make some plan on what is to be done, to come to the point.

Regards

Anatol