Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
R
Release
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 8
    • Issues 8
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • Release
  • Issues
  • #13

Closed
Open
Opened Jan 02, 2020 by Dmitry Smirnov@onlyjobDeveloper

Please consider using CVE identifies for security issues

Instead of vendor identifiers (e.g. CIVI-SA-2019-24) please consider using standard CVE identifies for security issues.

Here is some reasoning from the Debian Security Team:

The good thing on having a CVE id for the vulnerabilities is helping other vendors to track the issues properly 'cross-vendor' in an unique way. If every upstream would use individual identifiers to track their vulnerabilities, this makes the work of downsteams security teams much harder. Nowdays MITRE has improved a lot on their processes on assigning CVEs, and good filled reports at https://cveform.mitre.org/ get fastly assigned a CVE respectively (this somehow depends though on how good the report is done). I know some upstreams did in past make frustrating experiations, and do not want to try that out again.

See also Debian Upstream Guide.

Thank you.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/release#13