Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop bounties for experimental features #1538

Open
mcollina opened this issue Apr 24, 2024 · 6 comments
Open

Drop bounties for experimental features #1538

mcollina opened this issue Apr 24, 2024 · 6 comments

Comments

@mcollina
Copy link
Member

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
Copy link
Member

RafaelGSS commented Apr 24, 2024

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
Copy link

4xpl0r3r commented Apr 25, 2024

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants