On Fri, 10 Aug 2007, Gregory Stark wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
Obfuscation doesn't really work, it just makes big wigs in companies
*think* it's not easily reversible.
There is no real security. With enough time and experience, anything
can be broken.
But that said
On 8/10/07, Decibel! <[EMAIL PROTECTED]> wrote:
> As I said before, I don't care what security you come up with, *it can
> be broken*. The point of security measures isn't to make it impossible
> to break the security, it's to make it more difficult than it's worth.
I agree... but this type of sec
On Fri, Aug 10, 2007 at 12:11:01PM -0700, Steve Atkins wrote:
> >If someone just went and did "select * from pg_proc" they could
> >claim they
> >weren't violating their EULA or any protection you had put in
> >place. If they
> >went through the trouble having to de-obfuscate it then you would
On 8/10/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> If someone just went and did "select * from pg_proc" they could claim they
> weren't violating their EULA or any protection you had put in place. If they
> went through the trouble having to de-obfuscate it then you would have a
> strong DMCA c
On Aug 10, 2007, at 12:00 PM, Gregory Stark wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
Obfuscation doesn't really work, it just makes big wigs in companies
*think* it's not easily reversible.
There is no real security. With enough time and experience, anything
can be broken.
But
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Obfuscation doesn't really work, it just makes big wigs in companies
> *think* it's not easily reversible.
>
> There is no real security. With enough time and experience, anything
> can be broken.
But that said, I wonder if having something may be
On 8/9/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
> If I remember correctly Oracle wrap generates something like bytecode and
> each Oracle installation is able to understand them. But It is not possible
> decode it back to original form.
Regardless of what Oracle tells you, it has always been r
Ühel kenal päeval, N, 2007-08-09 kell 16:54, kirjutas Hans-Juergen
Schoenig:
> >
> > Of course, if your goal is to hide the code from someone snooping
> > through the pg_proc relation (on disk), then encryption will
> > certainly help (provided the key is properly protected).
> >
> >
>
>
>
>
Ühel kenal päeval, N, 2007-08-09 kell 16:42, kirjutas Hans-Juergen
Schoenig:
>
>
> well, the complete analysis is easy - the solution is not.
> currently we have basically no option to reduce access to the system
> tables. this would be hard anyway as we need those tables for
> basically all kin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans-Juergen Schoenig wrote:
>
> On Aug 9, 2007, at 5:03 PM, Greg Smith wrote:
>
>> On Thu, 9 Aug 2007, Andrew Dunstan wrote:
>>
>>> There are also some fairly impressive code obfuscators about, that
>>> your clients might find useful.
>>
>> All they
On Thu, Aug 09, 2007 at 11:41:02AM -0400, Andrew Dunstan wrote:
>
>
> Decibel! wrote:
> >This is also related to the desire to be able to restrict access to the
> >catalog tables. Doing so could potentially solve this problem; it
> >solves other issues (such as being able to see all the database
On Thursday 09 August 2007 11:30, Joshua D. Drake wrote:
> Andrew Sullivan wrote:
> > On Thu, Aug 09, 2007 at 04:42:19PM +0200, Hans-Juergen Schoenig wrote:
> >> the problem here is that vendors of appliances don't want people to
> >> spider their codes. this is a fact - it is not the idea of open
Make a loadable PL "plpgsqlsec" or something like that that's just
a thin wrapper around the plpgsql call handler, and all it does is
decrypt the source text.
perfect idea, simple perfect.
i did not consider that yet.
i was hoping for some enlightenment like that.
would be a nice module for
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> ... IIRC the general
> conclusion was that if you want to truly encrypt the sources for your
> functions, the basic idea is to create a new stored procedure language
> that wraps pl/pgsql and handles encryption there.
> This would be relatively easy t
On 8/9/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Decibel! wrote:
> > This is also related to the desire to be able to restrict access to the
> > catalog tables. Doing so could potentially solve this problem; it
> > solves other issues (such as being able to see all the databases that
> > exis
Decibel! wrote:
This is also related to the desire to be able to restrict access to the
catalog tables. Doing so could potentially solve this problem; it
solves other issues (such as being able to see all the databases that
exist on a server, something that hosting environments care about).
Andrew Sullivan wrote:
And they can always write it in C and deliver only compiled
object code; although whether anyone would be foolish enough to run
such object code without inspecting its safety is an excercise in
speculation I don't care to pursue.
The intended use for this is an app
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Sullivan wrote:
> On Thu, Aug 09, 2007 at 04:42:19PM +0200, Hans-Juergen Schoenig wrote:
>
>> the problem here is that vendors of appliances don't want people to
>> spider their codes. this is a fact - it is not the idea of open
>> source t
On Thu, Aug 09, 2007 at 05:16:43PM +0200, Hans-Juergen Schoenig wrote:
> we are shipping appliances - users can only use SQL; no compilers and
> no SSH logins allowed ...
If you have shipped a physical thing to someone else, then they can
do what they want with it irrespective of what "rules" yo
On Thu, Aug 09, 2007 at 04:42:19PM +0200, Hans-Juergen Schoenig wrote:
> the problem here is that vendors of appliances don't want people to
> spider their codes. this is a fact - it is not the idea of open
> source to do so but bloody reality. in addition to that people are
> not willing to
On Thu, Aug 09, 2007 at 04:50:53PM +0200, Zdenek Kotala wrote:
> Hans-Juergen Schoenig napsal(a):
> >the idea is basically to hide codes - many companies want that and ask
> >for it again and again.
> >
> >i would suggest keys to reside in $PGDATA. we do this for SSL and so
> >already.
> >
> >ini
The basic problem is this: if you have to decrypt the code in order
to give it to a compiler (PL/pgSQL, Java, Perl, ...) then there is
a point in time where the source code is in plaintext form - it
would be trivial to add an fprintf( stderr, "%s", plainTextForm )
to the PL handler to ste
My suggestion is to extend PL API and each PL language should offer
wrap or encrypt function which generate encrypted code and this code
will be store in the pg_proc. PL language will be responsible to
detect if it raw or crypted code. PG_Dump will dump crypted procedure
and author is respons
On Aug 9, 2007, at 5:03 PM, Greg Smith wrote:
On Thu, 9 Aug 2007, Andrew Dunstan wrote:
There are also some fairly impressive code obfuscators about, that
your clients might find useful.
All they really need is to find a sufficiently clever PL/Perl
programmer.
we should make this a PL
On Thu, Aug 09, 2007 at 04:34:48PM +0200, Peter Eisentraut wrote:
> Am Donnerstag, 9. August 2007 16:09 schrieb Hans-Juergen Schoenig:
> > the idea is basically to hide codes - many companies want that and ?
> > ask for it again and again.
>
> If you want to design a security feature, you need to
On Thu, 9 Aug 2007, Andrew Dunstan wrote:
There are also some fairly impressive code obfuscators about, that your
clients might find useful.
All they really need is to find a sufficiently clever PL/Perl programmer.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
On Aug 9, 2007, at 4:47 PM, korry.douglas wrote:
the idea is basically to hide codes - many companies want that and
ask for it again and again.
Hide code from who (or is that whom?)?
the code should be hidden from the guy who is actually executing the
function.
so:
some user i
Hans-Juergen Schoenig napsal(a):
the idea is basically to hide codes - many companies want that and ask
for it again and again.
i would suggest keys to reside in $PGDATA. we do this for SSL and so
already.
initdb could create such keys so that they are unique to every database
instance.
dec
the idea is basically to hide codes - many companies want that and ask
for it again and again.
Hide code from who (or is that whom?)? The PL compiler(s) will need to
decrypt the code. If a compiler can decrypt it, then anyone can decrypt
it (because the compilers are open-source).
And the
On Aug 9, 2007, at 4:34 PM, Peter Eisentraut wrote:
Am Donnerstag, 9. August 2007 16:09 schrieb Hans-Juergen Schoenig:
the idea is basically to hide codes - many companies want that and
ask for it again and again.
If you want to design a security feature, you need to offer a
threat and ris
Wouldn't it be better just to hide prosrc from the users you want to
hide it from? (Note: my SOC student is working on column level privs,
although unfortunately his work doesn't currently work with SELECT
privs). In fact, in many cases, depending on the app, you can simply
remove SELECT priv
Am Donnerstag, 9. August 2007 16:09 schrieb Hans-Juergen Schoenig:
> the idea is basically to hide codes - many companies want that and
> ask for it again and again.
If you want to design a security feature, you need to offer a threat and risk
analysis, not just the whining of customers.
--
P
the idea is basically to hide codes - many companies want that and
ask for it again and again.
i would suggest keys to reside in $PGDATA. we do this for SSL and so
already.
initdb could create such keys so that they are unique to every
database instance.
decrypting could be avoided as muc
Hans-Juergen Schoenig wrote:
hello everybody,
one of our customers wants to store the code of interpreted procedures
(PL/pgSQL, PL/Perl) and so in an encrypted way.
so the idea we had to add one more column to pg_proc telling us
whether prosrc is encrypted or not. people could chose then whe
On Thu, Aug 09, 2007 at 03:39:06PM +0200, Hans-Juergen Schoenig wrote:
>so the idea we had to add one more column to pg_proc telling us whether
>prosrc is encrypted or not. people could chose then whether to crypt codes
>there or not (speed of decryption can be an issue).
>should no
hello everybody,
one of our customers wants to store the code of interpreted
procedures (PL/pgSQL, PL/Perl) and so in an encrypted way.
so the idea we had to add one more column to pg_proc telling us
whether prosrc is encrypted or not. people could chose then whether
to crypt codes there or
36 matches
Mail list logo
