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
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 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
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
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
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 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
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/
--
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
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
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)
Date: Thu, 25 Sep 2008
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)
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 can
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 gear.
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, so
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
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 a little
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
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
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 usually
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 though the
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 securing the code.
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
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 :-)
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 who
25 matches
Mail list logo
