OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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]