Hi,
On Sun, 2008-04-06 at 21:59 -0700, Joshua D. Drake wrote:
For the record. I think this todo is bogus. We are an Open Source
database, let others worry about obfuscation. It isn't like it can't
be done within the facilities that already exist.
+1. IMHO, this patch should live as a
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
o Add ability to obfuscate function bodies
For the record. I think this todo is bogus.
For the record, I think so too ;-). The agreed-on TODO wording makes no
mention of
Added to TODO:
o Add ability to obfuscate function bodies
http://archives.postgresql.org/pgsql-patches/2008-01/msg00125.php
---
Pavel Stehule wrote:
Hello
this patch define new function flag -
On Sun, 6 Apr 2008 22:14:01 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
o Add ability to obfuscate function bodies
http://archives.postgresql.org/pgsql-patches/2008-01/msg00125.php
For the record. I think this todo is bogus. We are an Open Source
Joshua D. Drake [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
o Add ability to obfuscate function bodies
For the record. I think this todo is bogus.
For the record, I think so too ;-). The agreed-on TODO wording makes no
mention of what an acceptable
Hi,
Pavel Stehule írta:
On 29/01/2008, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Montag, 28. Januar 2008 schrieb Pavel Stehule:
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY
On 29/01/2008, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Montag, 28. Januar 2008 schrieb Pavel Stehule:
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security
Am Montag, 28. Januar 2008 schrieb Pavel Stehule:
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where privileged users can access
Am Montag, 28. Januar 2008 schrieb Tom Lane:
My recollection is that certain cryptography laws make hooks for crypto
just as problematic as actual crypto code. We'd have to tread very
carefully --- general purpose hooks are OK but anything narrowly
tailored to encryption purposes would be a
Peter Eisentraut wrote:
Am Montag, 28. Januar 2008 schrieb Pavel Stehule:
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where
On Jan 28, 2008 12:51 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where
On 28/01/2008, Dave Page [EMAIL PROTECTED] wrote:
On Jan 28, 2008 2:26 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
sure, but do you know, Tom dislikes new columns in pg_proc :).
Tom doesn't seem to like the idea of obfuscation of function code much
either :-)
This
patch is usable sample
On 28/01/2008, Gregory Stark [EMAIL PROTECTED] wrote:
Someone along the way suggested doing this as a kind of wrapper PL language.
So you would have a PL language like obfuscate:plperl which would obfuscate
the source code on the way in. Then when you execute a function it would
deobfuscate
On Jan 28, 2008 2:26 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
sure, but do you know, Tom dislikes new columns in pg_proc :).
Tom doesn't seem to like the idea of obfuscation of function code much
either :-)
This
patch is usable sample of one possible solution and doesn't need
initdb. And
On 28/01/2008, Dave Page [EMAIL PROTECTED] wrote:
On Jan 28, 2008 12:51 PM, Pavel Stehule [EMAIL PROTECTED] wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it
Pavel Stehule [EMAIL PROTECTED] writes:
In such a scheme I think you would put the key in an attribute of the
language. Either in pg_lang or some configuration location which the
obfuscate:plperl interpreter knows where to find.
what is advantage?
It wouldn't require any core changes. It
Pavel Stehule wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where privileged users can access system tables with source
Pavel Stehule [EMAIL PROTECTED] writes:
Do you thing some binary module that load some encrypted sources from
files? It can be possible too. But if source code will be stored in
pg_proc, then we need third method. Some like obfuscate (prev. are
validate and call), because we can't to store
Someone along the way suggested doing this as a kind of wrapper PL language.
So you would have a PL language like obfuscate:plperl which would obfuscate
the source code on the way in. Then when you execute a function it would
deobfuscate the source code and then just pass it to the normal plperl.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe a better TODO would be to do this task in the way that has
previously been suggested:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php
I'm certainly not happy about any proposal to put a password/key in a
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe a better TODO would be to do this task in the way that has
previously been suggested:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php
I'm certainly not happy about any proposal to put a password/key in a
GUC var - that
On 28/01/2008, Andrew Dunstan [EMAIL PROTECTED] wrote:
Pavel Stehule wrote:
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
Gregory Stark [EMAIL PROTECTED] writes:
There is a validator function which gets called when you create a
function but I don't think it has any opportunity to substitute its
result for the original in prosrc.
It would have to do a heap_update on the prosrc row, but that doesn't
seem like a
Tom Lane [EMAIL PROTECTED] writes:
My recollection is that certain cryptography laws make hooks for crypto
just as problematic as actual crypto code. We'd have to tread very
carefully --- general purpose hooks are OK but anything narrowly
tailored to encryption purposes would be a hazard.
On 28/01/2008, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Maybe a better TODO would be to do this task in the way that has
previously been suggested:
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00258.php
I'm certainly not happy about any
On 28/01/2008, Gregory Stark [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
In such a scheme I think you would put the key in an attribute of the
language. Either in pg_lang or some configuration location which the
obfuscate:plperl interpreter knows where to find.
Hello
this patch define new function flag - OBFUSCATE. With this flag
encrypted source code is stored to probin column. Password is stored
in GUC_SUPERUSER_ONLY item - it is similar security like SQL Server
does (where privileged users can access system tables with source code
or can use
On 28/01/2008, Gregory Stark [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
Do you thing some binary module that load some encrypted sources from
files? It can be possible too. But if source code will be stored in
pg_proc, then we need third method. Some like obfuscate
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
However, I definitely agree that a separate loadable PL is the way to go
for functionality of this sort. There is no way that a dependency on
pgcrypto is going to be accepted into core, not even in the (ahem)
obfuscated way that it's
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
However, I definitely agree that a separate loadable PL is the way to go
for functionality of this sort. There is no way that a dependency on
pgcrypto is going to be accepted into core, not even in the (ahem)
Andrew Dunstan [EMAIL PROTECTED] writes:
using this example, it seems to me that if we dump the encrypted/encoded
source and restore into another database with a different encoding, the
decoded/decrypted source will still be in the old database encoding,
i.e. not valid in the new database
31 matches
Mail list logo
