search

nodejs / TSC

The Node.js Technical Steering Committee
591 stars 134 forks source link

Drop bounties for experimental features #1538

Open mcollina opened 5 months ago

mcollina commented 5 months ago

Even though we treat experimental features part of our security reporting program, we are attracting the wrong kind of contributions that report vulnerabilities instead of bugs, and they are getting paid significant money from IBB.

I think we should change this and put them to zero: no bounties for experimental features.

RafaelGSS commented 5 months ago

FWIW Currently, the bounty for experimental features is 50% less:

Project Modifiers. Bounty amounts for this project are adjusted based on the following criteria: -50% : Vulnerability is not exploitable in a default configuration of Node.js -25%: A proposed patch was not provided for the issue

But, I feel we could expand a bit on this request. What if we provide bounties only for reports that receive at least Medium severity?

4xpl0r3r commented 5 months ago

FWIW Currently, the bounty for experimental features is 50% less:

Project Modifiers. Bounty amounts for this project are adjusted based on the following criteria: -50% : Vulnerability is not exploitable in a default configuration of Node.js -25%: A proposed patch was not provided for the issue

But, I feel we could expand a bit on this request. What if we provide bounties only for reports that receive at least Medium severity?

Agree with you, I don't think it a good idea to start research after releasing a stable version. I have another proposal maybe you will like. Move the scope of experimental features to a private program so that only trusted researchers could work on it.

I believe this could significantly reduce your triaging workload.

mhdawson commented 5 months ago

The counter argument might be that we want to fix the issues before we mark a feature stable. Having said that we really don't want people looking for/submitting vulnerabilities if the motivation is only the bounty so I'd be ok with setting it to 0 for experimental features.

GeoffreyBooth commented 5 months ago

The counter argument might be that we want to fix the issues before we mark a feature stable.

We have a stability index, and experimental is subdivided into multiple levels. What if we set the bounty to zero for 1.0 and 1.1, early and active development, but kept it at something motivating for 1.2, release candidate? Then we reduce the noise of premature reports but still get the review we want for things that are nearly stable.

RafaelGSS commented 5 months ago

We have a stability index, and experimental is subdivided into multiple levels. What if we set the bounty to zero for 1.0 and 1.1, early and active development, but kept it at something motivating for 1.2, release candidate? Then we reduce the noise of premature reports but still get the review we want for things that are nearly stable.

It does make sense for me! +1

GeoffreyBooth commented 5 months ago

It does make sense for me! +1

We'll also need to finally get around to updating the various experimental features that are still just labeled "experimental" rather than a more specific level.