[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension
Date: Tue, 25 Jul 2017 09:21:39 +0200


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:
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
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 .

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


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

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]