You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should discuss releasing details about vulnerabilities.
Something like this:
The main goal in fixing vulnerabilities is to minimize harm. Developers should try to fix the problem expeditiously, and normally should not make the vulnerability public until it's fixed (aka "coordinated disclosure" with the reporters). Once a fix is available to users, in most cases the fix effectively becomes known to the general public. In commercial software (both open and closed source) it's typically hard to prevent attackers from downloading or buying software & software updates, so trying to distinguish between "users" and "general public" is typically impractical. It can be good to hide the details on "how to exploit this" for a short while, but this quickly becomes ineffective. Attackers can easily review the changes made to fix the vulnerability & then create the attack. It doesn't matter if the change is released as source code (if open source) or as executables (if closed course) - attackers have long worked out how to figure out attacks from security updates. So it's better to focus on privately create good fixes that are trustworthy & don't break APIs, then get the update released & deployed as rapidly as possible.
The text was updated successfully, but these errors were encountered:
We should discuss releasing details about vulnerabilities.
Something like this:
The main goal in fixing vulnerabilities is to minimize harm. Developers should try to fix the problem expeditiously, and normally should not make the vulnerability public until it's fixed (aka "coordinated disclosure" with the reporters). Once a fix is available to users, in most cases the fix effectively becomes known to the general public. In commercial software (both open and closed source) it's typically hard to prevent attackers from downloading or buying software & software updates, so trying to distinguish between "users" and "general public" is typically impractical. It can be good to hide the details on "how to exploit this" for a short while, but this quickly becomes ineffective. Attackers can easily review the changes made to fix the vulnerability & then create the attack. It doesn't matter if the change is released as source code (if open source) or as executables (if closed course) - attackers have long worked out how to figure out attacks from security updates. So it's better to focus on privately create good fixes that are trustworthy & don't break APIs, then get the update released & deployed as rapidly as possible.
The text was updated successfully, but these errors were encountered: