[georgemcbay]

Wouldn't it make somewhat more sense to branch to a private repo without telling the public, make the required changes there, create the packages from that branch, and then later push the changes into the public repo?

The way they are doing it now entices hackers who don't know the exploit but happen to have a recent clone of the repo to look for the big hole in hopes of finding it ahead of the fix. Granted, hackers are probably already doing that sort of thing on high profile services like Postgresql to begin with, but in my experience it is easier to find something exploitable when you already know something exploitable exists than it is when you're just randomly poking around. At the very least it makes it easier to stay motivated and focused.

[trotsky]

Just knowing there is a preauth RCE in the code base buys you very, very little. Statistically speaking there are probably quite a few unexposed flaws right now in any compact, core linux distribution. The fact that no one yet knows what they are is precisely what prevents the exploitation. Security holes are numerous and the ones that have escaped detection generally continue to do so - the rate of co-discovery is very low in the field.

Warning ahead of time is thus often very useful - it allows the infrastructure to prepare to make the changes quickly. This is the same reason that folks like Microsoft consolidate most patches into standardized cycles.

[lawnchair_larry]

> Just knowing there is a preauth RCE in the code base buys you very, very little.

I disagree with that. That information is highly valuable. Auditing is a risky time investment; you may not find anything useful. Audit time is a finite resource and you want to allocate it where there are vulnerabilities that are useful. There is no way to know that ahead of time.

> Security holes are numerous and the ones that have escaped detection generally continue to do so - the rate of co-discovery is very low in the field.

The rate of co-discovery is fairly high once a second party has been tipped off to the general location and nature of a bug. Most competent auditors will spot the same bugs, especially if the second one already got confirmation that it does in fact exist.

[ibejoeb]

Yes, folks are already attempting to find exploitable weakness in these projects. We can assume they exist. Just mentioning that one is confirmed doesn't really lend any insight. The surface area is pretty huge on that project.

If I had to guess where it is, though, I'd bet it was in a PL module. I'm sure there is quite a bit of activity around finding NativeHelper-like situations.

[brokenparser]

It has to be something severe for this scenario to come into play. A broken procedure can only be exploited if such a procedure exists and can be invoked as the definer. This model is well understood by all, to the point a vulnerable PL may not be a critical issue for most users.

Given the precautions that have been implemented, my bets are on authentication. This would mostly affect TCP/IP enabled hosts, which is fortunately not a default configuration (tested on Ubuntu).

[shardling]

>Yes, folks are already attempting to find exploitable weakness in these projects. We can assume they exist. Just mentioning that one is confirmed doesn't really lend any insight.

You say that now, then one day, you wake up and all the blue-eyed islanders are gone!

[roryokane]

(This is a reference to a logic puzzle about islanders who are able to tell whether they have blue eyes due to someone telling the world that someone has blue eyes. Puzzle at http://xkcd.com/blue_eyes.html , solution at http://xkcd.com/solution.html .)

[Cyranix]

The repo is only being hidden for a week ("until Thursday morning"), which to me implies that the fix is localized and/or well understood. That's a pretty small window of time, so I'm not sure that it will provide any additional impetus for exploit developers.