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 ma
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 pgf
"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 accept
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
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 - OBF
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_ONL
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
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 priv
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 b
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 datab
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)
"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 h
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 t
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 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
G
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
"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 t
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
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, 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
"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
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
> deo
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 plpe
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
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
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
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.
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_ON
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 p
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 debugger)
31 matches
Mail list logo
