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

[Rocky Bernstein]

Comments in line.

On Tue, Jul 25, 2017 at 3:21 AM, Thomas Schmitt <address@hidden> wrote:

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

 Feel free to correct as you see fit.


(Does libcdio interpret it to uncompress files ?)
>

Probably not, unless someone else added. I don't any such thing.



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

If this is a question for me, I don't remember much about the bug. What's
in the Savannah tracker has
all the information I am aware of.


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