This should reference the earlier discussion of what merits an out of band release. The two should be consistent...

Other considerations would include:

• Does it disclose credentials
• Is data corrupted (local, remote)
• Does it require that the remote server is compromised
• Does it require that the local host is compromised
• What are the effects on server and host? Resource issues that effect other processes? Or just the ones talking?

Some of these are specific examples of the general statements in the proposal. But it's worth having examples to help with interpreting the generalizations.

This should reference the earlier discussion of what merits an out of band release. The two should be consistent...

The Early release text documents when to do early releases and one of the criteria is if there's a High or Critical security issue. I think that alignment suffice.

• Does it disclose credentials

I think it already says. But the question is not only if it can do it, it is also how likely, how often and how hard it is to make it do that.

• Is data corrupted (local, remote)

A curl security issue can hardly be responsible for remote data corruption, can it? How would that work?

• Does it require that the remote server is compromised

No security issue can require that because a server might just as well be plain malicious without being compromised, and then it can do the same damage or tricks.

• Does it require that the local host is compromised

I can't think of a way to get this into text that actually adds value. curl can only work if it has a platform to stand on that plays by established rules. If something changes those fundamentals, then of course all bets are off. But I'm not sure that is what you are talking about?

• What are the effects on server and host?

I don't understand this. Surely effects on servers are not curl issues?

Resource issues that effect other processes? Or just the ones talking?

I'm not sure how this will help our text.

Some of these are specific examples of the general statements in the proposal. But it's worth having examples to help with interpreting the generalizations.

I would be happy to, but I have not been able to come up with specific examples that firmly and always fall into a specific level. There are simply too many factors and moving pieces that can change how we view issues.

Are there any effectual differences between high and critical? Will we or are we expecting our users to act differently on those?

Are there any effectual differences between high and critical? Will we or are we expecting our users to act differently on those?

Good question.

I think in general the practical difference between these two is minimal. Except perhaps in panic level among readers of advisories. I think maybe there is still value in keeping both, if nothing else because those four levels are the exact levels used by our bug-bounty program and the IBB program that pays our bug-bounty rewards. If we would remove critical, we also take away the top-tier reward level. Or we would need to introduce another method to map our severity levels to hackerone levels.

Maybe we can express a better separation between the two highest severity levels?

This said, we have never marked a single curl security vulnerability critical.

Makes sense to keep it then, if bug bounties are classified along this.

I think it would be great, if each security level would contain one or two examples of previous vulnerabilities, that would have fallen into one of these levels.