Re: Closed list

[Josh Bressers <bressers () redhat com>]

----- Original Message -----
> "security updates" and "public advisories" aren't the same thing,
> That's not just a semantic distinction. There's many s vendors who
> release security updates, but not necessarily public advisories on
> them. They may have constituencies that would simply get confused
> by advisories, or they have auto-update mechanisms, or part of their
> support model involves pushing their customers to keep up with all
> fixes, security or otherwise. They may simply thing that advisories
> are a waste of time because customers don't read.
>
> For linux-distros, I think what you really want to go for here are
> *timely* updates. If a distro isn't generally capable of producing a
> security update within, say, a month of when the issue was released,
> then their getting the issue in advance through linux-distros isn't
> going to do them or their distro community a lot of good because they
> have other constraints in getting fixes out the door. Focusing on how
> you think an update ought to *look* (e.g. should the advisories be
> public?) isn't as important as the update getting *out*. Especially
> since you're dealing with GPL'ed code, I think that's something you
> can measure. Just ask the constituency a month or so after some major
> kernel issue who has released updates/fixes and who hasn't, show the
> relevant source, and take it from there.

I think the whole point comes down to how can you prove you've updated what
you claim you have? It doesn't matter *what* is public, just as long as
something is (and it needs to be reasonable, expecting others to dig
through source would be silly). If someone is untrustworthy and using a
private list inappropriately, do you really think they're going to tell the
truth if they're asked about releasing timely updates? Clearly advisories
are the easiest way to verify this, but if someone has a better idea that
includes verifiable information, please speak up.

Thanks.

-- 
    JB