Google to reward security improvements to some open source projects

[Gervase Markham]

http://googleonlinesecurity.blogspot.co.uk/2013/10/going-beyond-vulnerability-rewards.html

Google are now paying people, retrospectively, for any patch that
improves the security of OpenSSH, BIND, ISC DHCP, libjpeg,
libjpeg-turbo, libpng, giflib, Chromium, Blink, OpenSSL, zlib and
commonly used components of the Linux kernel (including KVM).

Soon, they will also cover Apache httpd, lighttpd, nginx, Sendmail,
Postfix, Exim, GCC, binutils, llvm and OpenVPN.

This includes the core developers of those projects!

Some of this work (e.g. on libjpeg or zlib) will benefit us directly.
Other work (e.g. on OpenSSH) will benefit us indirectly, as we use those
tools and want them to be secure. However, the inclusion of
Chromium/Blink means that this program may steal potential security
contributors from Mozilla and attract them to those projects.

Can we and should we attempt to do anything about that?

Gerv

[Rob Stradling]

Gerv, how about asking Google to add NSS to the list of projects that
are in-scope for this new rewards program?

I believe Chromium still uses NSS for TLS, and so NSS would qualify for
the "Open-source foundations of Google Chrome" category.

Firefox uses NSS, and this alone makes NSS a "high-impact library".

And I think that "down-to-earth, proactive improvements that go beyond
merely fixing a known security bug" describes the insanity::pkix effort
rather well!

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Larissa Shapiro]

Wow. Having worked on BIND and ISC DHCP for many years, I am *cheering* this! Fantastic. Personally while I can see the concern about contributor "theft" I think the way to go is to be aware, paying attention to whats going on with those contributors, and supporting their efforts on our… preferred projects seems like the way to go. And adding NSS, if they are willing, for sure!

Larissa

On Oct 10, 2013, at 3:01 AM, Gervase Markham <ge...@mozilla.org> wrote:

> http://googleonlinesecurity.blogspot.co.uk/2013/10/going-beyond-vulnerability-rewards.html
>
> Google are now paying people, retrospectively, for any patch that
> improves the security of OpenSSH, BIND, ISC DHCP, libjpeg,
> libjpeg-turbo, libpng, giflib, Chromium, Blink, OpenSSL, zlib and
> commonly used components of the Linux kernel (including KVM).
>
> Soon, they will also cover Apache httpd, lighttpd, nginx, Sendmail,
> Postfix, Exim, GCC, binutils, llvm and OpenVPN.
>
> This includes the core developers of those projects!
>
> Some of this work (e.g. on libjpeg or zlib) will benefit us directly.
> Other work (e.g. on OpenSSH) will benefit us indirectly, as we use those
> tools and want them to be secure. However, the inclusion of
> Chromium/Blink means that this program may steal potential security
> contributors from Mozilla and attract them to those projects.
>
> Can we and should we attempt to do anything about that?
>
> Gerv

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

[chris hofmann]

Interesting experiment. We (the mozilla bounty evaluation team) have
paid, on a case by case basis, for vulnerabilities outside the mozilla
code for things affecting any dependencies we have for Firefox 3rd party
libraries, or our core development application or services websites for
some time.

It might be time to make this more explicit.

The one idea that is new here is the idea about paying developers for
fixing vulnerabilities in the code they work on. That could create the
wrong incentives if not managed and tracked properly, setting up the
possibility of writing code that's insecure, then getting paid to patch
or improve that code later on.

-chofmann

[Gervase Markham]

On 10/10/13 11:21, Rob Stradling wrote:
> Gerv, how about asking Google to add NSS to the list of projects that
> are in-scope for this new rewards program?

Good idea.

Gerv

[Gervase Markham]

On 10/10/13 16:35, chris hofmann wrote:
> The one idea that is new here is the idea about paying developers for
> fixing vulnerabilities in the code they work on. That could create the
> wrong incentives if not managed and tracked properly, setting up the
> possibility of writing code that's insecure, then getting paid to patch
> or improve that code later on.

I suspect that Google are thinking they will avoid that problem because
this program doesn't pay out for fixing individual vulnerabilities, it
pays out for security-improving architectural patches. So yes, maybe you
could design an entire feature insecurely, persuade your co-developers
to let you check it in anyway, and then secure it - but again, the
program is at Google's discretion, so I think you'd get busted.

Gerv

[Brian Smith]

Rob Stradling wrote:
> Gerv, how about asking Google to add NSS to the list of projects that
> are in-scope for this new rewards program?
>

> I believe Chromium still uses NSS for TLS, and so NSS would qualify for
> the "Open-source foundations of Google Chrome" category.
>
> Firefox uses NSS, and this alone makes NSS a "high-impact library".

The parts of NSS that Firefox/Gecko and Chromium/Blink use are already covered by Mozilla's bounty program AND Google's bounty program. I believe that one could find a vulnerability in NSS and actually collect on BOTH bounty programs.

> And I think that "down-to-earth, proactive improvements that go beyond
> merely fixing a known security bug" describes the insanity::pkix effort
> rather well!

I agree I should be getting paid more. :)

Cheers,
Brian

[Gervase Markham]

I suggested this to Google; their feedback to this suggestion has been
positive. We should "watch this space" :-)

Gerv