Re: [Gimp-developer] GIMP GBR format spec
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. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
At 5:35 PM +0200 7/16/03, Sven Neumann wrote: I don't think we should use a compressed archive. Instead the binary data in the archive should be compressed. I agree - and that's what ZIP/JAR allow for - some files/blobs are compressed, and some are not. You could either use the built-in methods to specify this, OR use the XML manifest. That allows to choose the best compression scheme for the data and to combine different compression techniques in the archive. Exactly! As I pointed out in an earlier mail, I am not sure if a hierarchical structure in the archive is a good idea. In my opinion the hierarchy should only be defined in the XML part that describes how the contents of the archive should be put together. If we apply the document hierarchy to the archive, it will become painful to keep the XML description and the archive hierarchy in sync. It's an interesting tradeoff. If you leave it flat, that means that it's not possible to establish relationships between objects WITHOUT parsing the XML - so that standard archiving tools wouldn't be helpful. On the other hand, you are right, that syncing the two could be a pain. LDR -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
On Mon, Jul 14, 2003 at 10:16:28AM -0400, Leonard Rosenthol [EMAIL PROTECTED] wrote: At 08:38 AM 7/14/2003 -0400, Robert L Krawitz 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 -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
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. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
new-xcf (was:Re: [Gimp-developer] GIMP GBR format spec)
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote:
Well, ar's limitations with respect to name length etc. are in practise
not every severe (nobody will have 1 character file names (the ar
limit), and even antique ar implemnentations will support up to 255
characters).
Technically I don't know if that's true. From my ar man page:
GNU ar can maintain archives whose members have names of
any length; however, depending on how ar is configured on
your system, a limit on member-name length may be imposed
(for compatibility with archive formats maintained with
other tools). If it exists, the limit is often 15 charac-
ters (typical of formats related to a.out) or 16 charac-
ters (typical of formats related to coff).
But, that is of no consequence -- we wouldn't need to keep
meaningful names, we just need unique resource ids that the XML
structure can refer to... these could quite simply be numbers
counting up from zero, or hash strings. In either case just
15 characters could be fine.
I am not opposed to uncompressed jar files, but compression is certainly a
bad idea (the jar compression algorithm is rather ineffective)
I like the idea of ar files. Compression then happens by
[un]{b,g}zipping the ar via a compression plugin in the usual
GIMP style.
HOWEVER, this might be a good time to think about whether we'd
prefer a compressed format that we can random-access de/compress
on the fly instead of going via a huge (and with image data we
can easily be talking HUGE) temporary intermediate file. In
this case something like a ZIP (or okay, equivilently, a compressed
jar, whatever you want to call it) is a better (and still
exceedingly standard in its most basic form) choice of
wrapper for the hierarchy-file-plus-linked-resources.
--Adam
--
Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
Hi, [EMAIL PROTECTED] (Tino Schwarze) writes: 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. I don't think we should use a compressed archive. Instead the binary data in the archive should be compressed. That allows to choose the best compression scheme for the data and to combine different compression techniques in the archive. Compressing the whole archive again would probably only reduce the size marginally and would add unneccessary complexity. You robustness argument is also a very good argument against compressing the whole archive. 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. As I pointed out in an earlier mail, I am not sure if a hierarchical structure in the archive is a good idea. In my opinion the hierarchy should only be defined in the XML part that describes how the contents of the archive should be put together. If we apply the document hierarchy to the archive, it will become painful to keep the XML description and the archive hierarchy in sync. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
On Wed, Jul 16, 2003 at 05:35:42PM +0200, Sven Neumann wrote: I don't think we should use a compressed archive. Instead the binary data in the archive should be compressed. That allows to choose the best compression scheme for the data and to combine different compression techniques in the archive. Yes! Just in case anyone taking part in this discussion didn't know, the compression routines used by gzip and ZIP are generic text compression techniques, they don't understand interleaved formats (commonly used for RGB data, stereo audio etc.) nor multi-byte representations such as the 32-bit IEEE floats we might be using in a few years in The GIMP so they produce rather poor results compared to specialised compression techniques which The GIMP could inherit from existing Free Software. Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: new-xcf (was:Re: [Gimp-developer] GIMP GBR format spec)
On Wed, Jul 16, 2003 at 04:28:18PM +0100, Adam D. Moss [EMAIL PROTECTED] wrote: Technically I don't know if that's true. From my ar man page: GNU ar can maintain archives whose members have names of any length; however, depending on how ar is configured on your system, a limit on member-name length may be imposed (for compatibility with archive formats maintained with other tools). If it exists, the limit is often 15 charac- ters (typical of formats related to a.out) or 16 charac- ters (typical of formats related to coff). But, that is of no consequence -- we wouldn't need to keep The archive formats that the ar manpage above refers to are what mortla people call object files. Since ar is part of binutils it tries to be compatible to other object formats which often have severe limitations. ar also handles hierarchical structures within ar files, but for compatibility it doesn't create them. (and there are common extensions that allow unlimited name lengths, these are also handled by ar). can easily be talking HUGE) temporary intermediate file. In this case something like a ZIP (or okay, equivilently, a compressed jar, whatever you want to call it) is a better (and still exceedingly standard in its most basic form) choice of wrapper for the hierarchy-file-plus-linked-resources. something like zip is the key. zip won't do, of course, since it's lousy at compression and also doesn't support random access like we want. Also, I think compression at the file level (whole file) is not a good idea anyway, so we could keep a simple wrapper format (like ar) and implement a more intelligent block structure within the constituent files. However, the reason why people propose ar, jar, cpio etc... as formats is that they cna be handled by users with ease, being well established. If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important we could get away with an extremely simple format, say, cat files*, index at end which could be just offset and length, indexed by number, meta-info is all handled by an xml sub-file. The question is simply wether it should be a standard format or not. If we want to implement a kind-of tile cache within the image to speed up loadign and operations, using a format like ar/jar/etc. would just be a hindrance, as users wouldn't be able to deal with the files within them anyways. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
Date: Wed, 16 Jul 2003 16:12:37 +0200 From: [EMAIL PROTECTED] (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? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
Sven Neumann wrote: Excuse me?!?! JAR is used by every Java implementation in existence, and since it is 100% compatible with ZIP, means you have all of those implementations as well. Java is not exactly what I would call well established, but that's not a relevant argument here. One issue we should at least think about with JAR is that since it *is* the JAVA library mechanism, there is perhaps a risk of allowing virus writers to attach bits of JAVA executable in what *appears* to be a GIMP image. This is the kind of thing that email virus writers *love*. Whilst I can't quite see how this would be a problem, it might be better to just avoid the risk. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
At 7:16 AM -0500 7/14/03, Stephen J Baker wrote: One issue we should at least think about with JAR is that since it *is* the JAVA library mechanism, there is perhaps a risk of allowing virus writers to attach bits of JAVA executable in what *appears* to be a GIMP image. If you don't open up the JAR file with a Java-based tool - you can't have Java executing. And even if you DO use Java to open up the JAR, nothing auto-executes - you'd have to manually kick it off. SO even if someone were to put Java bytecodes into a GIMP image file, it would never get executed... Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
At 02:34 PM 7/11/2003 +0200, Sven Neumann wrote: XML is very well suited to describe the structure of a multi-layered, multi-framed image/animation and it can be used perfectly to embed meta information as well as vector layers, paths and the like. XML namespaces make it easy to add application-specific extensions later. You bet! We discussed to bundle one XML file with a set of files that store the image data. These files would preferably be known image formats or perhaps even strict subsets of known image formats. Agreed. I would suggest that these files are then put together in an ar archive. Such an uncompressed archive has the advantage that the XML metadata can easily be extracted. You just described a JAR file, which is not unlike the OpenOffice file format ;). A JAR is a special type of ZIP archive, which contains one or more data files along with an XML manifest about the contents. I've worked on a number of projects (both commercial and open) that have used such a format - it works quite nicely and is compatible with existing tools and technologies. Always better than reinventing the wheel!! I think the approach of a JAR-like file for the future GIMP (and possibly CinePaint) file format is an excellent choice and allows for many avenues of expansion. Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
On Fri, Jul 11, 2003 at 10:08:55AM -0400, Leonard Rosenthol [EMAIL PROTECTED] wrote: A JAR is a special type of ZIP archive, which contains one or more data files along with an XML manifest about the contents. I've worked on a number of projects (both commercial and open) that have used such a format - it works quite nicely and is compatible with existing tools and technologies. Always better than reinventing the wheel!! the ar file format is much better established then jar, quick to access (unlike jar), and very very very much simpler. a complex container format like jar is not very helpful, as the added complexity just gets in the way (we just need to bundle files...) I think the approach of a JAR-like file for the future GIMP (and possibly CinePaint) file format is an excellent choice and allows for many avenues of expansion. i think jar-like is backwards. tar-like is much better (but tar itself is unsuitable due to the lack of rigid definitions and a multitude of different formats, the same is true for cpio). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
