Hi, Pete Batard wrote: > Without trying to sound passive-aggressive
I would not perceive any technical discussion as that. So my replies are not to be seen as the wish of starting a quarrel. :)) > if you create a Rock Ridge > extension and produce a relatively popular utility that uses it can you at > least try to add a mention of it on the relevant Wikipedia page, That would be "original research" which Wikipedia forbids. Needed would be a publication which mentions the issue, and then a person who puts the info into Wikipedia quoting the publication. In any case, the author of a software is not the one who is supposed to write the Wikipedia article.i Whatever, the problem is not in xorriso but in libisofs, which - to my current suspicion - does not properly check for the presence of SUSP. Further the SUSP specs demand that a reader software must ignore what it does not understand. It shall only depend on the common chaining fields of SUSP entries in order to skip them. Of course, there should, even with confirmed SUSP presence, be checks during the hopping along the chain which prevent memory mishaps in the reading software. > Considering that you are basically trying to establish a new standard, I use the prepared extension opportunity of SUSP. Any SUSP compliant software should have no problem with this. Further it was the decision of Kali developers to record the device and inode numbers of the input files on hard disk. (Possibly by xorrisofs option --hardlinks, if not by xorriso command -disk_dev_ino.) In a Debian ISO i do not get any match from xorriso -indev $iso -find / -has_any_xattr -exec get_any_xattr -- So AAIP in published distro ISOs is rather exotic. Neither fast incremental backup preparations nor hardlink recording are of much use in an installation ISO. Hardlinks rather serve for high backup fidelity. > Even if libcdio should not have been choking on 'AL', I must say it took me > quite while to figure out where exactly that extension came from, You can ask me about ISO 9660 at any time on e.g. [email protected] (or via [email protected] if it's somewhat confidential). > Google was no help at all in linking > 'AL' usage in Rock Ridge with the AAIP proposal. AAIP is not a Rock Ridge extension but a System Use Protocol payload, as Rock Ridge is too. For the sorting of Google, i am not to blame. All i can do is to choose terms which are not ubiquitous. > I have since edited the Wikipedia Rock Ridge page [2] The Wikipedia article structure is misleading. SUSP is the boss of Rock Ridge, not a part of it. So SUSP should have its own article, which may mention RR and the five non-RR payloads i am aware of: zisofs, Apple, Amiga, mkisofs XA, AAIP. (zisofs ZF is currently missing in the article.) In any case, AAIP belongs to the paragraph "Variants", where Amiga is mentioned. (The Apple link about "AA" and "BA" in doc/susp_aaip_2_0.txt is dead, i fear. The mkisofs link about "XA" too.) Further, AAIP does not only record ACL but arbitrary extended file attributes. > I'm attaching a patch proposal for review, which I'll be happy to commit to > libcdio if everyone agrees. I think we should first re-investigate the bug which led to the list of known SUSP entry names, which by the triggered program reaction actually violates the specs. Especially i doubt that the bug will stay muted if you do not bail out on the non-SUSP bytes which libcdio reads from the 50 KB test ISO. - /* Something got screwed up here */ - goto out; + /* Warn about unsupported SUSPs */ + cdio_warn("Unsupported Rock Ridge extension: '%c%c'\n", *chr, *(chr+1)); + break; I say "muted" because i believe that it is not fixed yet. An unrecognized SUSP entry is not really a reason for a warning. The code looks like it could flood the screen with the warnings if isoinfo option -f is used. A variable which prevents more than one warning would be nice to the users. My current starting point for a bug fix would rather be iso9660_have_rr() in iso9660_fs.c , where i would check the "/." directory entry for a "SP" entry at offset 0 of the System Use Area. (Offset 15 is prescribed for CD-ROM XA, which is a recording state of CD, but not DVD, BD, disk file, or general block device.) Another starting point would be to harden libcdio against wrong or even malicious bytes in the chaining of SUSP fields. Regardless whether the field's name is known or not. > [1] https://bugs.kali.org/view.php?id=4109 It would be interesting to see the xorriso command line they use. (Currently i suspect option --hardlinks to be the difference to Debian and the other distros which use xorrisofs.) Trying to read e.g. http://git.kali.org/gitweb/?p=live-build-config.git;a=blob;f=build.sh;h=e97709799b9408374777895f5cbedbd9098886a3;hb=HEAD yields "Reading blob failed." (git is ok, but its web frontends do suck.) Do you have a link for me which works ? Have a nice day :) Thomas
