nm...@netcourrier.com ("Saleem EDAH-TALLY") writes:
> OK guys, I would never have thought about modifying libpq to steal
> confidential
> data, and I have never used debuggers in this respect at all.
>
> So super gurus can yet do the bad thing.
Since this thread was published, anyone capable of writing a bit of C
code into libpq (which wasn't written to be opaque to development) can
readily search for this message thread and discover the approach.
> Nevertheless 99% of users are not super gurus who could do such nasty things
> but a few of them could use an unencrypted private key. These few at least
> would have been frustrated if libpq could manage an encrypted private key.
> The
> server can manage such a key and the admin starting the server is prompted
> for
> the password. Ironically, it is generally accepted that it's better that the
> server private key be unencrypted so that any admin can start the server
> anytime.
If we added such an interface into libpq, then it would become a
valuable thing for someone to add a libpq "extension" to capture the
data in unencrypted form, and publish it publicly enough to make it
accessible to rather more than the "1% of supergurus."
If you're trying to design something, intending it to be
tamper-resistant, then you *have* to consider the "supergurus,"
particularly because they might blaze a trail for others to follow...
--
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
Christopher Browne
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
