Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcLa0-0005KG-TR for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Dec 2018 02:39:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gcLZz-0003Qt-EH for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Dec 2018 02:39:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcLZz-0003Qm-3t for pgsql-hackers@lists.postgresql.org; Thu, 27 Dec 2018 02:39:23 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gcLZs-0005UE-0r for pgsql-hackers@postgresql.org; Thu, 27 Dec 2018 02:39:21 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wBR2d0Qh002821; Wed, 26 Dec 2018 21:39:00 -0500 From: Tom Lane To: Peter Geoghegan cc: Michael Paquier , Alvaro Herrera , Adrien Nayrat , Thomas Munro , Dmitry Dolgov <9erthalion6@gmail.com>, Tomas Vondra , Vik Fearing , Robert Haas , David Rowley , Pg Hackers Subject: Re: random() (was Re: New GUC to sample log queries) In-reply-to: References: <20181129214850.kiq6mvofsgplqjdr@alvherre.pgsql> <3859.1545849900@sss.pgh.pa.us> <20181227013458.GF2106@paquier.xyz> <32696.1545875185@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Wed, 26 Dec 2018 18:20:20 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2819.1545878340.1@sss.pgh.pa.us> Date: Wed, 26 Dec 2018 21:39:00 -0500 Message-ID: <2820.1545878340@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Peter Geoghegan writes: > It's always possible to make a change that might stop someone from > introducing a bug. The question ought to be: why this change, and why > now? 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. 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. regards, tom lane