Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension

[Thomas Schmitt]

Hi,

AL is my invention. It is legitimized by SUSP 1.12, paragraph 6.3:

  "Any System Use Entry which the receiving system does not recognize
   shall be ignored and skipped.
   Any System Use Entry, with the exception of the set of System Use Entries
   defined in this document, following an "ES" System Use Entry that
   indicates an extension specification which the receiving system does
   not recognize shall be ignored and skipped."

Rock Ridge is an application of SUSP, as is AAIP:
  https://dev.lovelyhq.com/libburnia/web/wikis/aaip
So taking an AL entry as reason to refuse reading is a violation of SUSP.

AAIP does not only carry ACL and extended file attributes but also
some internal enhancements of libisofs, like pointers from data file
directory entries to MD5 checksums of the data files.
The list of predefined names in AAIP namespace "isofs." is in
  doc/susp_aaip_isofs_names.txt 
and also at the end of the wiki article.


Pete Batard wrote:
> - Should libcdio add support for the 'AL' Rock Ridge extension?

It is not urgently necessary. An ISO with AAIP can well be interpreted
as pure Rock Ridge ISO or as pure ISO 9660 without SUSP.


> - If so, is there anybody on this list willing to do it?

I would help, although my own implementation in libisofs is not the
nicest possible one. Maybe one can derive a leaner one from libcdio's
handling of the Rock Ridge symbolic link entry SL, which has the same
structure as AL.


Rocky Bernstein wrote:
> It looks like I added this in response to a heap overflow of malformed ISO
> images, See https://savannah.gnu.org/bugs/?45015 .

Well, that was too heavy handed.
There's not only AAIP, but also Apple and Amiga entries.
But hpa's ZF extension made into the list of commit 8b96bd3.
(Does libcdio interpret it to uncompress files ?)

Especially the ban will not protect against malformed known RR+SUSP
entries.

-------------------------------------------------------------------

What is actually the bad SUSP thing in the submitted 50 KB ISO ?
I just ran

  valgrind xorriso -indev libcdio-heapoverflow-get_rock_ridge_filename.iso \
                   -find / --

without a complaint.

A hex editor does not show me any recognizable SUSP or RR entries.
(It it is about RR names, then an NM entry should be present.
 The mkisofs spy block lists some options, but -R or -r are not among
 them.)


Have a nice day :)

Thomas