Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 10 Feb 2017 19:37:48 +0000
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: MITRE is adding data intake to its CVE ID process

On Fri, 10 Feb 2017 at 13:09:43 -0500, Stiepan wrote:
> By the way, I have just tried the OVE ID alternative:
> good idea, but perhaps one button is a bit too frugal.

The purpose of OVE IDs is literally only creating a unique identifier
that no other maintainer or security researcher will be using to
identify a different vulnerability. That's all they are. How you
publish the vulnerability for which you have used the identifier
is up to you.

They're slightly more readable and memorable than using
/proc/sys/kernel/random/uuid to allocate identifiers, and they give
you some vague idea of how old the vulnerability report is. That's about
the only difference.

(Hmm, now I'm tempted to use /proc/sys/kernel/random/uuid next
time I need a unique ID for a vulnerability that's already public...)

> P.S.: While we're at it, let's use the two OVEs I have just wasted,
> OVE-20170210-0001 (forward CVE web request+ID to oss-sec)
> OVE-20170210-0002 (add a title option field to OVE web form),
> for the two aforementioned issues!

I'm pretty sure those aren't security vulnerabilities in any product :-P

    S

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.