Skip to content

Need to discuss releasing vulnerability details #17

@david-a-wheeler

Description

@david-a-wheeler

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions