Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20160309212853.GA26775@openwall.com>
Date: Thu, 10 Mar 2016 00:28:53 +0300
From: Solar Designer <solar@...nwall.com>
To: announce@...ts.openwall.com
Subject: [openwall-announce] introducing OVE IDs; (no) GSoC

Hi,

This is to announce two minor items:

1. As many of you are aware, CVE IDs - which are used to uniquely
identify software security vulnerabilities - are often difficult and
slow to obtain, especially lately.

While this doesn't fully replace CVE, we're introducing a trivial
partial alternative, OVE:

http://www.openwall.com/ove/

Anyone can trivially and instantly obtain an OVE ID by clicking a
button on the above web page, with no information required, and include
that number when disclosing a vulnerability.

OVE IDs are short and pretty-looking (unlike e.g. UUIDs) yet are unique.
They include a full date (unlike CVE's inclusion of only a year), which
might provide insight into disclosure timelines, even if unreliable.

The current allocation algorithm is generous in case someone needs IDs
for a large number of vulnerabilities at once, yet when unusually many
IDs are requested it starts to impose per IP address and per network
limits to try and keep the daily IDs within 4 digits while it can.
If on a given day it can't achieve that while still offering a sane
number of IDs per requester, it may proceed to offer 5- and 6-digit IDs,
returning to 4 digits on the next day.  We might revise this approach
later, as needed.

A more complete emerging alternative to CVE is Distributed Weakness
Filing (DWF), currently also linked from the web page above, but in many
cases mere OVE IDs should suffice.

2. We had a successful Google Summer of Code last year, with a total of
7 students - 5 for Openwall and 2 for radare - all 7 successful.
Despite of and due to this success (we're yet to release a version of
JtR -jumbo with last summer's enhancements, even though they're merged
into the development tree), we chose not to apply for Google Summer of
Code this year much like we had skipped 2014.

We appreciate having been in GSoC four times so far (in 2011, 2012,
2013, and 2015), with good results and experience, but we always need to
consider the benefits vs. drawbacks, our mentoring capacity during a
given summer, as well as the fact that there are always more
organizations applying than are getting accepted into the program (so
being accepted is likely keeping some other organization out).

This year, we'd like to encourage prospective GSoC students to consider
other mentoring organizations, and in particular radare (which is
finally in GSoC directly, not under an umbrella) and lowRISC.  Here are
their ideas pages:

http://radare.org/gsoc/2016/
http://www.lowrisc.org/docs/gsoc-2016-ideas/

As always, there's also Nmap, "one of just 7 projects that have
participated in all 12 Summers of Code":

https://nmap.org/soc/

Good luck!

Alexander

Powered by blists - more mailing lists

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