[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110303224920.GA22311@openwall.com>
Date: Fri, 4 Mar 2011 01:49:20 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Vendor-sec hosting and future of closed lists
Hi Marcus, all -
Thank you for making this public!
On Thu, Mar 03, 2011 at 07:12:24PM +0100, Marcus Meissner wrote:
> So I would like to open up a discussion with _all_ OSS Security folks present.
>
> - Is a closed vendor coordination like vendor-sec still needed at this time?
Yes, there's some need for it.
> Meaning: does the benefit of a closed group really outweigh the
> "left out feeling" of non members and its annoyances?
In that meaning, I am not sure. These things are not possible to
compare, and there are other things to consider as well.
> - If yes, would it be an idea to confine or split into lists of focus groups?
> (like Linux vendors, BSD vendors, all OSS source using vendors, etc?)
My current proposal is: split into several sub-lists. I'd start with
three: Linux vendors, *BSD vendors, security "researchers". The vendor
groups would be for externally submitted reports (by non-members) and
for cross-vendor discussions.
The Linux vendors group should include distro vendors. I am unsure
whether it should also include Linux kernel-only folks or not. Maybe we
should be CC'ing security@k.o on relevant messages instead, or maybe we
need a separate group for Linux distros+kernel. It feels wrong to
expose userland-only issues to the kernel-only folks.
The researchers group would (probably) rarely receive external reports
directly, but could be involved in Linux and/or *BSD vendors discussions
by CC'ing them when their expertise is needed. Alternatively, the
researchers may be included on the vendor lists, which will enable and
encourage them to contribute a lot more, but then we need to define some
stricter requirements for them (some minimum activity level?) We don't
want a lot of inactive members on any of these private lists.
As to projects such as, say, Samba and X.org, I'd exclude them.
There's no difficulty for a researcher to notify one of these directly,
and there's not much difficulty in CC'ing the proper one of these on a
discussion.
> - Or of course the old option is open:
> Should we proceed with the current state as-is,
Probably not, although we could do it temporarily if there's a need -
such as to continue some discussions that are already started.
> but throw a bit more GPG encryption on top?
I think we should have the new list(s), if we do set them up,
GPG-encrypting to the members. They should also accept encrypted
messages (to the list's key).
This will reduce the likelihood of leaks somewhat - from the members'
mail servers, from their unattended mailboxes, etc.
That said, leaks would nevertheless be quite likely - or at least we
should assume so. For this reason, I think these lists should be used
for medium severity issues only, and CRDs should be set not too far into
the future (say, up to 2 weeks, with an attempt to make embargoes
shorter than that whenever possible).
Anything low severity is best made public right away - such as via
oss-security. Anything high severity may need to be approached more
carefully, identifying just the affected distro vendors before initial
notification by the reporter (then these lists won't be needed).
Of course, not everyone is willing to do that... If we do receive a
high severity issue notification via one of the "expander" lists, we'd
need to apply an even shorter embargo period.
I'd appreciate any comments on the above.
Thanks again,
Alexander
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.
