* Greg Sabino Mullane (greg@turnstep.com) wrote:
> Still sounds like a huge mess. Who gets put on the committee?
The initial suggestion was to put -core on it.
> Wouldn't the
> committee need to have a huge database of potential people to notify, including
> details of their systems (e.g. do they use tsearch, if this is a tsearch bug).
No; if it's that specific, then it's not a high-exposure security bug.
There will certainly be some amount of trial-and-error associated with
this, but that's the nature of security issues- they aren't all going
to be the same.
> Would they be deciding on people on a case by case basis, or just deciding
> on what class of people get notified. If the latter, why not just have
> core continue to do it?
My comments around "-core or a committee" was more geared towards if
-core felt a seperate committee would be better. I'm fine with it being
left with -core, but I do feel that we should publicize and perhaps
formalize a bit more that policy.
> If the former, how can that be agile enough for a
> quick turnaround? Would companies have to be requested to be added to
> this database, in the hopes they get notified of a serious bug before it
> is released?
Yes, organizations which felt they met the requirements outlined in the
policy would need to request to be added and then a decision by -core
(or whatever group it is) would need to be made regarding that request.
> Perhaps we can just agree that the way this was handled was a mistake, and
> strive for more transparency and egalitarianism next time? Sure, Heroku has
> a huge list of servers listening on 5432, but do did that place in Poland,
> and apparently they did not get a early warning.
I agree that, in hindsight, we could have done better. That's what this
discussion is about- figuring out how to do better in the future. I
don't think that means we should give up on having a security policy
which allows early access to trusted organizations.
Thanks,
Stephen
