On Wed, Jul 16, 2003 at 12:42:49PM +0200, Marc A. Lehmann wrote:

What happens if in the future someone writes a gimp-java interface (like gimp-perl)? Would there be any security issues there?

No.

"I do not believe people like you."

Sorry, but how can you so bluntly claim this? These things happened before, and often times, so instead of a simple "No" there *should* be very good arguments of why it should be different...

And yes, java byte code *is* getting executed without having to kick it off, at least, in netscape, ie, mozilla, opera, konquereor....

- you can turn it off
- it's inside a sandbox (no access to local files) - to be able to execute some Java code out of a (virus-altered) GIMP image (Gimp Graphics Archive) takes: * a person running "java -jar picture.gga" * some "smart" program looking inside the image, recognizing the manifest etc (which makes the JAR "executable"), running this (probably requirng user interaction) * a Java machine

I think, the security argument against JAR is very far-fetched. A JAR is basically a ZIP with a META-INF directory containing a MANIFEST.MF file. That's it.

There is a lot of code around for creating / reading ZIP files - I'm a bit worried about robustness though; if the directory at the end of the ZIP is broken or missing, things get complicated.

But a hierarchical structure would be cool too. What about mapping big parts of the file format to the file system? This way, a lot of information can be stored in the hierarchy and it wouldn't be a big difference whether to read a file from file system or from archive.

Bye, Tino.

Date: Wed, 16 Jul 2003 16:12:37 +0200 From: tino.schwarze@informatik.tu-chemnitz.de (Tino Schwarze)

On Wed, Jul 16, 2003 at 12:42:49PM +0200, Marc A. Lehmann wrote:

> > >What happens if in the future someone writes a gimp-java interface > > >(like gimp-perl)? Would there be any security issues there? > >
> > No.
>
> "I do not believe people like you." >
> Sorry, but how can you so bluntly claim this? These things happened > before, and often times, so instead of a simple "No" there *should* be > very good arguments of why it should be different... >
> And yes, java byte code *is* getting executed without having to kick it > off, at least, in netscape, ie, mozilla, opera, konquereor....

- you can turn it off

But the default configuration of most browsers is for it to be turned on.

- it's inside a sandbox (no access to local files)

That depends upon the JVM configuration.

- to be able to execute some Java code out of a (virus-altered) GIMP image (Gimp Graphics Archive) takes: * a person running "java -jar picture.gga" * some "smart" program looking inside the image, recognizing the manifest etc (which makes the JAR "executable"), running this (probably requirng user interaction) * a Java machine

Not necessarily. If the appropriate MIME type isn't set up for .gga files, a browser might helpfully run "file" on the file, identify it as a JAR, and run java on it. That requires a spot of misconfiguration (or social engineering), but it's a bad idea to assume that other things are configured correctly.

I think, the security argument against JAR is very far-fetched. A JAR is basically a ZIP with a META-INF directory containing a MANIFEST.MF file. That's it.

There is a lot of code around for creating / reading ZIP files - I'm a bit worried about robustness though; if the directory at the end of the ZIP is broken or missing, things get complicated.

But a hierarchical structure would be cool too. What about mapping big parts of the file format to the file system? This way, a lot of information can be stored in the hierarchy and it wouldn't be a big difference whether to read a file from file system or from archive.

What properties are you assuming in the filesystem?

On Wed, Jul 16, 2003 at 08:27:12PM -0400, Robert L Krawitz wrote:

- to be able to execute some Java code out of a (virus-altered) GIMP image (Gimp Graphics Archive) takes: * a person running "java -jar picture.gga" * some "smart" program looking inside the image, recognizing the manifest etc (which makes the JAR "executable"), running this (probably requirng user interaction) * a Java machine

Not necessarily. If the appropriate MIME type isn't set up for .gga files, a browser might helpfully run "file" on the file, identify it as a JAR, and run java on it. That requires a spot of misconfiguration (or social engineering), but it's a bad idea to assume that other things are configured correctly.

So you are basically saying: Do not use ZIP files for anything but Java stuff. Your argument holds for any ZIP file. It might get executed somewhere. But I think this is purely academical and has nothing to do with the GIMP file format.

But a hierarchical structure would be cool too. What about mapping big parts of the file format to the file system? This way, a lot of information can be stored in the hierarchy and it wouldn't be a big difference whether to read a file from file system or from archive.

What properties are you assuming in the filesystem?

Probably too many. I imagined something like Image_name/
image.xml (meta-data)
comment.txt
Layers/
Layer1/
Layer1/
layer.xml (opacity, mode etc.) comment.txt
data.png
Layer2/
layer.xml
comment.txt
data.png
Layer3/
Layer1/
...
Layer2/
...
Layer2/
Layer1/
layer.xml
data.png
Paths/
path1.xml
path2.xml

But there are probably lots of issues with this design.

Bye, Tino.