Re: DSM segment handle generation in background workers
От | Noah Misch |
---|---|
Тема | Re: DSM segment handle generation in background workers |
Дата | |
Msg-id | 20181114075218.GE1096408@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: DSM segment handle generation in background workers (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: DSM segment handle generation in background workers
|
Список | pgsql-hackers |
On Wed, Nov 14, 2018 at 08:22:42PM +1300, Thomas Munro wrote: > On Wed, Nov 14, 2018 at 6:34 PM Noah Misch <noah@leadboat.com> wrote: > > On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote: > > > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch <noah@leadboat.com> wrote: > > > > What counts is the ease of predicting a complete seed. HEAD's algorithm has > > > > ~13 trivially-predictable bits, and the algorithm that stood in BackendRun() > > > > from 98c5065 until 197e4af had no such bits. You're right that the other 19 > > > > bits are harder to predict than any given 19 bits under the old algorithm, but > > > > the complete seed remains more predictable than it was before 197e4af. > > > > > > However we mix them, given that the source code is well known, isn't > > > an attacker's job really to predict the time and pid, two not > > > especially well guarded secrets? > > > > True. Better to frame the issue as uniform distribution of seed, not > > unpredictability of seed selection. > > What do you think about the attached? You mentioned that you rewrote the algorithm because the new function had a TimestampTz. But the BackendRun() code, which it replaced, also had a TimestampTz. You can reuse the exact algorithm. Is there a reason to change?
В списке pgsql-hackers по дате отправления: