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
