On Wed, Dec 26, 2018 at 6:39 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > The point here is not to be cryptographically strong at every single > place where the backend might want a random number; I think we're > all agreed that we don't need that. To me, the point is to ensure that > the user-accessible random sequence is kept separate from internal uses, > and the potential security exposure in the new random-logging patch is > what justifies getting more worried about this than we were before.
I agree that that's the point here. > Now, we could probably fix that with some less intrusive patch than > #define'ing random() --- in particular, if we give drandom and setseed > their own private PRNG state, we've really fixed the security exposure > without need to change anything else anywhere. So maybe we should > just do that and be happy. +1. I don't like the idea of #define'ing random() myself. We're already making fairly broad assumptions about our having control of the backend's PRNG state within InitProcessGlobals(). How should this affect the new drandom()/setseed() private state, if at all? -- Peter Geoghegan
