libcdio-devel
[Top][All Lists]
Advanced

[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 13:49:32 +0200

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. address@hidden
(or via address@hidden 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




reply via email to

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