On Wed, 21 Aug 2002, Christopher Kings-Lynne wrote:
> > Should someone from the core team perhaps get in contact with this guy
> > and ask if he could get in contact with the development team before
> > publicizing any further security holes? AFAIK that is standard
> > operating procedure in most cases...
> >
> > Second, it might be worth pushing a 7.2.2 release containing the fix
> > for this bug, as well as the datetime problem. If that sounds
> > reasonable to the people who have to do the most work on a new release
> > (e.g. Marc), I can volunteer to backport a fix for the datetime
> > problem.
>
> It'd be better to contact the dude and get all his bugs out of him, fix them
> all and issue a 7.2.2 with all the fixes.
That wouldn't work because it seems he is making advisories at the
time he discovers a bug/flaw. That is, he is not directly interested in
the robustness of Postgres -- rather, another poster put it, his
reputation on bugtraq. That's fine but it doesn't mesh well with the
co-ordinated effort you describe.
I still do not see this as being a serious security problem unless you are
providing access to postgres to untrusted users. The advisory's
recommendation of killing the postmaster as a solution to these bugs is
akin to saying 'kill ssh if there's a libc bug'. If you are providing
access to untrusted users, that advice is worthwhile. But if your users
are trusted and could produce the same effect in any other number of
reasons, the advice is useless.
As for making a 7.2.2 release for the sake of form and for those users who
do provide access to untrusted users (universities, ISPs, say) this would
be pointless without the changes to opaque which Tom has put forward and
may/may not work on before 7.3 beta. I'm not sure that the core guys would
be too happy doing that *and* requiring an initdb for a minor release (as
I presume Tom's changes will require one).
Gavin