Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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 presented here.
>>>
>
>
>> If we do anything in core it could be to make provision for an
>> obfuscation/encryption hook via a loadable module.
>>
>
> 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. This is one reason
> that I'd prefer to see it as an external PL rather than embedded in core.
>
It could be something other than encryption; any sort of transformation
might fit. For example, one might do something like:
gzip | some-sort-of-shuffle | base64-encode
as a sort or poor man's obfuscation
>
>> Various interesting encoding issues could arise with dumping and
>> restoring transformed program text - I haven't thought that through yet.
>>
>
> I think we have already solved that with md5 passwords, and could easily
> reuse the same kind of approach. You just base64 encode the crypted
> text (or whatever you need to do to avoid funny characters in it), and
> make sure that there's some way to distinguish already-crypted from
> not-already-crypted function bodies.
>
>
>
I don't see how a binary MD5 checksum has any encoding component. But
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 encoding. We've just gone around
closing doors like this.
You might be able to fix it by storing the database encoding name along
with the encrypted/encoded source, so it could be transformed at the
other end.
cheers
andrew
