Comments in line. On Tue, Jul 25, 2017 at 3:21 AM, Thomas Schmitt <[email protected]> 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 > > >
