David Fetter <david@xxxxxxxxxx> wrote: > > On Mon, Sep 15, 2008 at 08:29:22PM -0400, Bill Moran wrote: > > Greg Smith <gsmith@xxxxxxxxxxxxx> wrote: > > > > > > The problem here is that the PostgreSQL community is fully aware > > > how bogus any encryption method is and doesn't even bother, while > > > Oracle is perfectly happy selling a solution that is easily > > > bypassed. Don't get me wrong--the work involved is just difficult > > > enough that I'm sure most PL/SQL procedures are quite safe from > > > being reversed, and what you get back again will be kind of crummy > > > code, so that's good enough for your typical ISV. But the > > > security doesn't stand up to simple scrutiny, and a highly visible > > > open-source project doing the same quality of implementation would > > > receive seriously bad press for releasing something so shoddy. > > > PostgreSQL would be compelled to name it something like > > > "half-assed obfuscation" in order to make it clear just how > > > limited the protection actually is, and then you've kind of lost > > > the sales pitch that motivated the feature in the first place. > > > > I don't understand why this is so bloody difficult to implement: > > First, make a case for implementing PL obfuscation under any > circumstances. The fact that it comes up every now and again on this list and creates a thread of discussion eight miles long ... But that's not even important, I'm not asking anyone to _do_ it, I'm asking why, every time this topic comes up, it provokes such a long, painful thread of argument. > While you are making your case, please bear in mind that security by > obscurity is in effect an attack launched from that nastiest of places > to have an attacker, the inside of your trust boundaries. Since when am I asking for security through obscurity? I'm not telling you to move ssh to an unusual port in the hopes that nobody will notice that your root password is "password1". What I'm _asking_ is why would extending SECURITY DEFINER to include preventing unauthorized users from viewing code _not_ be a valid method of securing the code. Whether or not enough people want it to justify the manpower to do it is a different discussion altogether. -- Bill Moran Collaborative Fusion Inc. wmoran@xxxxxxxxxxxxxxxxxxxxxxx Phone: 412-422-3463x4023
