[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] RE: Directories in Zip packages
It should also be noted that there are two ways two store A/B/C in a ZIP, where C is a file: Some ZIP apps store this as three entries: A/ A/B/ A/B/C And some ZIP apps store it as a single entry: A/B/C and then rely on unzipping logic to know to create the appropriate parent directories. Both are legal and you'll see both. -Rob Bob Jolliffe <bobjolliffe@gmail.com> wrote on 09/27/2010 06:18:53 PM: > Re: [office] RE: Directories in Zip packages > > On 27 September 2010 22:11, Dennis E. Hamilton > <dennis.hamilton@acm.org> wrote: > > -1 > > > > Unless there is a proposal for how to accomplish the signing of > > "directories" via XML Digital Signature (and also directory entries for > > package files, which we don't sign either). > > > > Please include a specific rule for knowing what is a directory entry in the > > Zip, because there is no help in APPNOTE 6.2.0 that I can find. > > Not sure whether this should make me laugh or cry. Given that it > seems you are right that the appnote is not helpful, and given that I > know the java ZipEntry class has a method called isDirectory(), I > thought I'd quickly look up how the openjdk implements it: > > public boolean isDirectory() { > return name.endsWith("/"); > } > > well there you have it. Make of that what you will :-) > > In practice, besides the trailing '/', it does look empirically like > you can spot a directory by the fact that the local file header of the > entry is followed immediately by the next local file header ie. there > is no file data section. Note this is unlike the zero length file > (which has a file data section of 2 bytes worth of compression > infrastructure). So as far as 'directory' entries are concerned there > really really doesn't seem to be anything to sign. So I guess I would > go along with Bart's suggestion but minus the "directories". And if > we do find these things in an odf zip package (which we'd rather not) > the consumer could and should simply ignore them. > > Cheers > Bob > > > > > - Dennis > > > > -----Original Message----- > > From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] > > Sent: Monday, September 27, 2010 10:42 > > To: dennis.hamilton@acm.org; 'Svante Schubert' > > Cc: ODF TC List > > Subject: RE: [office] RE: Directories in Zip packages > > > > Arrgh :-) Folks, this is going back and forth, while I really would like to > > see some work on XAdES :-) > > > > My suggestion: > > > > - discourage (but not forbid) the use of empty directories and empty files > > in ODF packages > > - sign everything in the zip (including empty directories and empty files) > > - change the 1.2 draft about document signatures and mention "sign every > > entry" instead of > > "sign every file" > > > > This means there's no impact on unsigned ODF docs (because every > > implementation can still > > use empty things, although it is discouraged) > > > > There is impact on signed implementations signing/verifying signeddocs, but > > those products > > probably have to be updated anyway (to support correct prefixes, version > > attributes etc) > > > > > > Bart > > > > > > ________________________________________ > > From: Dennis E. Hamilton [dennis.hamilton@acm.org] > > Sent: Monday, September 27, 2010 7:30 PM > > To: 'Svante Schubert' > > Cc: ODF TC List > > Subject: RE: [office] RE: Directories in Zip packages > > > > Svante, a sub-document doesn't have to be an "actual" directory in any > > literal sense. This was clear in ODF 1.0/1.1 and I know of nothing that > > requires us to change that. > > > > The sub-document <manifest:file-entry> simply has to specify a "path" prefix > > that some of the package files share and that are treated as a collection > > with respect to the manifest:media-type. Otherwise we would be in a world > > of hurt with manifest:full-path="/". > > > > We don't have nor require that "META-INF/" be declared as a sub-document or > > have a directory entry in the package, nor do we do so for "Thumbnail/" and > > so on. > > > > When there is an ODF Package-significant use for declaring empty > > directories, we should treat it as an extension case. In the meantime, I > > think we should give consumers a break here, especially around document > > security issues. A speculative future scenario is no help to a consumer who > > stumbles on one of these now because of some inscrutable producer behavior. > > > > - Dennis > > > > -----Original Message----- > > From: Svante Schubert [mailto:Svante.Schubert@oracle.com] > > Sent: Monday, September 27, 2010 09:20 > > To: office@lists.oasis-open.org > > Subject: Re: [office] RE: Directories in Zip packages > > > > On 27.09.2010 16:57, Bob Jolliffe wrote: > > > > ... > > > > So I would say that an odf producer should only produce entries in > > the > > zipfile for non-zero-length streams (this would by default also > > excludes directories). And that each of these shall be referenced > > in > > a full document signature. > > > > May I remind the TC, that from the perspective of the package (ODF 1.2 part > > 3 - which can be seen as the base layer of ODF 1.2) an entity called a > > document is defined by a directory related with a media type (in the > > manifest.xml). > > > > In general I believe when a generic functionality does not hurt, it should > > not be forbidden nor dropped as other yet unknown user scenarios might rely > > on it. > > > > Regards, > > Svante > > > > > > -- > > > > > > <http://www.oracle.com/> > > Svante Schubert | ODF Standardization > > Phone: +49 40 23646 965 > > Oracle Office GBU > > > > ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg > > Hauptverwaltung: Riesstr. 25, D-80992 München > > Registergericht: Amtsgericht München, HRA 95603 > > > > Komplementärin: ORACLE Deutschland Verwaltung B.V. > > Rijnzathe 6, 3454PV De Meern, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven > > > > <http://www.oracle.com/commitment> > > > > Oracle is committed to developing practices and products that help protect > > the environment > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]