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


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office-comment] ODF security hazard? (ODF all versions)

Michael hi

> One could do so, but I'm not convinced that this is reasonable. With
> the
> same argument we may have to forbid that an application tries to
> resolve
> namespace URIs to check whether they can locate XSD schemas there, or
> would have to forbid them to evaluate any xsi:schemaLocation
> and so and and so on.

I agree that in general there are more issues that external entities to
worry about.

However, the two examples you give are not a problem for ODF are they?
An XML processor won't normally try and dereference Namespace URIs, and
by not using XSD, ODF has sidestepped the various xsi:schemaLocation

DTDs - or more particularly external entities in DTDs - remain a more
harmful than helpful feature, I think.

I had a play with entities in OO.o 3, and it appears to process internal
entities okay but does not dereference external ones. This is perfectly
sane behaviour, but is also unusual (at least) for an XML processor...
> Having that said: The issue is a general XML issue, and not something
> specific to ODF. If we want to add security consideration to ODF, then
> I
> would just say that ODF implementors should follow the security
> consideration that do exist for the standards it uses (if there are
> such), but I would not list them itself within the ODF specification.

Agreed - maybe a note with a reference to RFC 3023 would do the trick
... I suppose that leaves maximum flexibility for the users ...


- Alex.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]