intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> CC: pgsql-general@postgresql.org
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Obfuscated stored procedures (was Re: [GENERAL] Oracle and
> Postgresql)
>
On Sep 25, 2008, at 1:16 PM, Christophe wrote:
Without getting into the argument as to the level of security
provided, it strikes me that a reasonable approach would be a non-
core pluggable language which accepts encrypted strings as
functions, decrypts them (using a key compiled into the la
On Thu, 25 Sep 2008, Christophe wrote:
it strikes me that a reasonable approach would be a non-core pluggable
language which accepts encrypted strings as functions, decrypts them
(using a key compiled into the language module), and passes them on to
PL/pgSQL for execution...This would, of cour
On Thu, Sep 25, 2008 at 01:25:25PM -0700, Casey Allen Shobe wrote:
> Gee, I wonder why companies that support these antics grow to insane
> sizes of employees?
Meetings. Lots and lots of meetings.
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
S
On Sep 25, 2008, at 1:14 PM, David Fetter wrote:
On Thu, Sep 25, 2008 at 01:05:26PM -0700, Casey Allen Shobe wrote:
On Sep 15, 2008, at 7:19 PM, Tom Lane wrote:
The problem is that the people who ask for this type of feature are
usually imagining that they can put their code on
customer-control
On Sep 24, 2008, at 6:12 PM, Scott Ribe wrote:
the sort of person who
thinks re-using someone else's undocumented code is easier than
writing it from scratch is probably not going to be able to learn
the code
via debugging tools.
There are two distinct extremes here, and I think most people
On Sep 24, 2008, at 8:05 AM, David Fetter wrote:
C is not magic obfuscation gear. Anybody with a debugger can expose
what it's doing.
Yes, but you don't get original code, comments, etc. and it takes a
lot of effort to refine it back down into something maintainable.
People looking to pro
On Sep 16, 2008, at 6:39 AM, Jonathan Bond-Caron wrote:
After some research, I found this article that I believe will make a
stronger use case:
http://www.iosn.net/network/news/Managing%20the%20insider%20threat%20through
%20code%20obfuscation
I can tell without even clicking the link that it wo
On Sep 25, 2008, at 1:05 PM, Casey Allen Shobe wrote:
As for the expectation above - could pl/pgsql be made compilable?
Without getting into the argument as to the level of security
provided, it strikes me that a reasonable approach would be a non-
core pluggable language which accepts encr
On Thu, Sep 25, 2008 at 01:05:26PM -0700, Casey Allen Shobe wrote:
> On Sep 15, 2008, at 7:19 PM, Tom Lane wrote:
>> The problem is that the people who ask for this type of feature are
>> usually imagining that they can put their code on
>> customer-controlled machines and it will be safe from the
On Sep 15, 2008, at 7:19 PM, Tom Lane wrote:
The problem is that the people who ask for this type of feature are
usually
imagining that they can put their code on customer-controlled machines
and it will be safe from the customer's eyes.
That's a broken expectation. All that can realisticall
> the sort of person who
> thinks re-using someone else's undocumented code is easier than
> writing it from scratch is probably not going to go to the trouble of
> really learning the code via debugging tools.
Fixed that for you:
the sort of person who
thinks re-using someone else's undocumented
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Wed, Sep 24, 2008 at 08:05:18AM -0700, David Fetter wrote:
>> C is not magic obfuscation gear. ...
> To be fair, one of the points that others are trying to make is not
> "secure this function for real" but "secure this function enough to
> make it
> C is not magic obfuscation gear. Anybody with a debugger
> can expose
> what it's doing. There have been math papers showing
> that it's
> impossible to hide the functionality of a piece of software
> based only
> on the ability to run it, so the entire prospect of
> obscuring the
> software's
On Wed, Sep 24, 2008 at 08:05:18AM -0700, David Fetter wrote:
> C is not magic obfuscation gear. Anybody with a debugger can expose
> what it's doing. There have been math papers showing that it's
> impossible to hide the functionality of a piece of software based only
> on the ability to run it,
David Fetter wrote:
> On Wed, Sep 24, 2008 at 02:12:19PM +, Glyn Astill wrote:
> > I'm not sure what the policy is on putting stuff in the docs, but
> > how about putting that in the relevant place, as well as a note
> > about the other option; using C and SPI.
>
> C is not magic obfuscation g
On Wed, Sep 24, 2008 at 02:12:19PM +, Glyn Astill wrote:
> I'm not sure what the policy is on putting stuff in the docs, but
> how about putting that in the relevant place, as well as a note
> about the other option; using C and SPI.
C is not magic obfuscation gear. Anybody with a debugger ca
I'm not sure what the policy is on putting stuff in the docs, but how about
putting that in the relevant place, as well as a note about the other option;
using C and SPI.
> Added to TODO under features not wanted:
>
> Incomplete itemObfuscated function source code (not
> wanted)
>
Added to TODO under features not wanted:
Incomplete itemObfuscated function source code (not wanted)
Obfuscating function source code has minimal protective benefits
because anyone with super-user access can find a way to view the code.
To prevent non-
On Tue, Sep 16, 2008 at 09:39:03AM -0400, Jonathan Bond-Caron wrote:
>
> I agree here. I hope there's a consensus that it does offer some level of
> protection.
There is not, in fact, in the security community a consensus that it
offers some level of protection. There are some security people w
> One big reason why nothing hasn't been done is that
> there is a decent
> 'low tech' obfuscation tactic already: remove
> select access from
> pg_proc to the user accounts in question and
> 'public'. This will
> essentially disable casual browsing of procedure code from
> user
> accounts.
Neat
Nice trick ... thanks!
> One big reason why nothing hasn't been done is that there is a decent
> 'low tech' obfuscation tactic already: remove select access from
> pg_proc to the user accounts in question and 'public'. This will
> essentially disable casual browsing of procedure code from user
>
On Tue Sep 16 08:40 AM, Bill Moran wrote:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>
>> Bill Moran <[EMAIL PROTECTED]> writes:
>>> What I'm _asking_ is why would extending SECURITY DEFINER to include
>>> preventing unauthorized users from viewing code _not_ be a valid
>>> method of securin
On Tue, Sep 16, 2008 at 9:15 AM, Glyn Astill <[EMAIL PROTECTED]> wrote:
>
> As much as I'm impressed with the "we do it properly or not at all" attitude,
> it'd be nice if there was an option to stop the casual user from viewing code.
>
> I'll admit to obfusicating bits and pieces using C, even th
> Because it's so full of obvious loopholes. Yes,
> it might slow down
> > someone who didn't have superuser access to the
> database or root access
> > to the machine it's on; but that doesn't count
> as secure really. The
> > problem is that the people who ask for this type of
> feature are usu
25 matches
Mail list logo
