Re: Attention PL authors: want to be listed in template table?

From: Dave Cramer <dave(at)fastcrypt(dot)com>
To: Thomas Hallgren <thhal(at)mailblocks(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Attention PL authors: want to be listed in template table?
Date: 2005-09-08 13:15:32
Message-ID: 99378E52-47D6-4C64-AD88-44EDD78AE29A@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 8-Sep-05, at 2:18 AM, Thomas Hallgren wrote:

> Peter Eisentraut wrote:
>
>
>> Thomas Hallgren wrote:
>>
>>
>>> Well, yes. But use the word environment in singular please :-) To my
>>> knowledge the security is full-proof with all other VM's since they
>>> all use the standard runtime libraries.
>>>
>>>
>>
>> It's not quite as simple as that. There are a bunch of VMs and a
>> bunch of libraries (and a bunch of compilers), and they can be
>> combined in many permutations. Not all of them work with PL/Java
>> at the moment, but we should not hardcode support for just one of
>> them.
>>
>>
> AFAIK, there are only two flavors of the Java Runtime library out
> there. The one that Sun provides (and small variants of it, such as
> the ones that IBM, HP, and BEA) and the "classpath" clean-room
> implementation. All variants of the former are OK with respect to
> security and only GCJ has a working environment of the latter. In
> particular, only GCJ has a functional standards conformant Java
> Native Interface (JNI) API to the latter and PL/Java is built on JNI.
>
> Should however, someone come up with another Java environment built
> on "classpath" that has JNI support, then there will be another
> potential environment for PL/Java. TMK, there's no such environment
> and none in the making. I have serious doubts that there ever will
> be. IMO it would be perfectly safe to hard code support for a
> trusted "java".
>
Actually the apache guys are doing another one (Harmony), and there
is Kaffe. Hardly relevant to the conversation, just added for completion

>
>>> The GCJ support is as experimental as the GCJ in itself and
>>> cannot be trusted in
>>> production.
>>>
>>>
>>
>> You should not say that too loud when someone from Red Hat is
>> listening. :-) To my knowledge GCJ is Ready(tm) as of version
>> 4.0. And it's being used. Distributions such as Fedora and
>> Ubuntu will ship (or do ship?) with everything compiled using GCJ
>> to the extent possible. And there are people, in particular at or
>> near Red Hat, who have been specifically charged for several years
>> now to make sure that every piece of Java code out there compiles
>> with GCJ.
>>
>>
> Don't get me wrong. I like GCJ and the idea of compiled Java
> executables but I try to look at it's potential and usefulness in a
> realistic way. If Red Hat wants to tout that it's production ready,
> that's up to them. I'm not a marketing guy.
>
> GCJ currently that has limited security. It is 2 years behind
> mainstream in versions (they don't have Java 5 yet and their Java
> 1.4 support is not complete). It is not stable and the performance
> is nowhere close to the commercial implementations. I think the GCJ
> team is aware of this and I seriously doubt that it is surprise to
> the people at Red Hat.
>
> Try using GCJ to run Java applets in a web browser. You can't
> really since such applets cannot be trusted. I doubt the browser
> vendors make attempts to prevent it though ;-)
>
>
>> Regarding the security issue: Word from Andrew Haley of Red Hat is
>> that it has simply been too much work to implement security up to
>> now. This should not affect the judgement of the quality of GCJ,
>> it's simply a missing feature.
>>
>>
> Security is some "feature" to "simply miss". Especially if we talk
> about a VM.
>
>
>> Of course, I don't intend to undermine your judgement as the
>> author about what you consider experimental or not, but you should
>> expect that if you put your code out there, people will use it in
>> whatever way they see fit, and in particular with whatever Java
>> toolchain they see fit.
>>
>>
> I do indeed expect that. But the PostgreSQL community cannot take
> responsibility for all that may happen when people do that.
>
> PL/Java is designed to run perfectly safe with a JVM that has the
> correct features implemented. GCJ has serious issues with security
> and I don't see that PL/Java, nor PostgreSQL should make any
> attempt to fix them. How safe is PostgreSQL running on an unsafe
> operating system?
>
> Regards,
> Thomas Hallgren
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-09-08 13:17:59 Re: PQ versions request message
Previous Message pmagnoli 2005-09-08 13:12:28 Re: Rendezvous/Bonjour broken in 8.1 beta