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

[Thomas Schmitt]

Hi,

First a more exposed form of my question to Rocky:

  Am i right that the libcdio function iso9660_have_rr() in iso9660_fs.c
  does not look in the "/." directory record for the SUSP "SP" at byte
  offset 0 (or 15) of the System Use Area (i.e. at offset 34 after the end
  of the special ISO 9660 name for ".") ?

If so:

  What do you think about relying on SUSP entry "SP" instead of the
  currently implemented traversal ?
  I hope that this prevents the bug and makes the whitelist of SUSP
  entries obsolete.

  Do you, or anybody else here, have a copy of SUSP 1.10 ?
  Is "SP" declared mandatory already there ?
  I have only SUSP 1.12. But RRIp has a version 1.10. So i expect that
  for SUSP, too.


-----------------------------------------------------------------------

Second a short distraction over the Wikipedia topic. :))
Third section will be about interaction with Kali.


Natalia Portillo wrote:
> If you create an interesting tool and/or structure specification whatever,
> YOU CANNOT create the wikipedia page yourself,

The advantage of this rule is that the one or two levels of quotation
can filter out the idiosyncrasies of manuals written by the developers
or very experienced users.
The disadvantage is that misunderstandings can sneak in, to which the
original experts would never come.

Maybe i would have tried to tunnel underneath that rule if i had suspected
that AAIP causes problems with readers.


> I'm in the same situation having done DiscImageChef

Yeah. Sometimes it is painful to see under-representation or even
mis-representation of one's work.

Apropos:
Looking at https://github.com/claunia/DiscImageChef i miss a reference
to the El Torito boot pointers of ISO images. Is this included in the
topic "ISO 9660" ?
(One may also find MBR, GPT, Sun Disklabel, APM, MIPS Volume Header,
 DEC Bootblock, PReP, CHRP, or HP-PA PALO inside ISO 9660 images.
 I have a byte-level description in
   https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt
)


Pete Batard wrote:
> Would you have a conflict of interest in editing the pages that aren't
> related to AAIP and 'AL'?

Not really. But i am the paragon of idiosyncrasy. Nearly 10000 lines of
indigestible man pages.

At least zisofs entry "ZF" should be mentioned. I wrote byte-level
documentation doc/zisofs_format.txt. If GitLab lets you, see:
  https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/zisofs_format.txt
So the second party publication exists.
Now we'd need somebody to quote it into Wikipedia.

Is there a way to approach moderators in advance ? I could submit a plan
how to restructure the Rock Ridge article and disclose my conflicts of
interest.


> I wasn't clear whether AAIP was to be
> considered as a something that might fall outside established standards.

I am all in for written interfaces and established standards.


-----------------------------------------------------------------------
Now for Kali:

Pete Batard wrote:
> I can try to get back to the Kali maintainers on that, but I'm not
> sure how much they're gonna like being asked about this for the 3rd time in
> a row...

Is that conversation public ? I would chime in. After all they use my
software and the statement that their ISOs are like Debian's is not
really realistic. (cough) (cough)


> I was hoping the Kali people could point me in the right direction first.

If the difference is indeed the use of option --hardlinks, then i am
to blame, too. The man page of xorrisofs gives no direct hint that it is
related to extended attributes inside the ISO.

Again, i would have been more verbous if i ever suspected that a whitelist
would be implemented for SUSP fields.


> I'll take that as a cue to point out
> that, from what they reported, xorriso and genisoimage decided to drop what
> they considered one of the most useful feature from mkisofs, which was to
> store the options being passed to the commandline application into the ISO
> itself.

Funnily i am just today busy with explaining to an ISOLINUX user why
i decided against publishing the xorrisofs options without explicit
consent by the user.
The Debian based genisoimage developers decided for the same, independently.

Kali stems from Debian and still does not have a file /.disk/mkisofs inside
the ISO 9660.
How did they cut this out of Debian ISO production ?

Hrmmpf. Ubuntu does not have that file either.


> Maybe something that could be added to xorriso in the future? ;)

Very firmly, with my GNU xorriso maintainer hat on: Not by default.

I dimly remember to have read statements by FSF that we do not rat out
our users. They have to do this themselves. We may help, of course.
Any user of xorriso can fill the desired info into some data file
and let xorriso record it into the ISO. 

I propose that everybody uses the Debian protocol of /.disk/mkisofs.
Maybe with some extra info from
  xorriso -version
Especially if the default Preparer Id of xorriso gets overwritten.

Kali's ISO bears as preparer
  LIVE-BUILD 1:20170213KALI1; HTTP://LIVE-SYSTEMS.ORG/DEVEL/LIVE-BUILD

But e.g. debian-live-8.4.0-i386-standard.iso has
  LIVE-BUILD 4.0.5-1; HTTP://LIVE-SYSTEMS.ORG/DEVEL/LIVE-BUILD
and no AAIP in it.

http://www.live-systems.org redirects to landing.premiumsale.com and
yields a 504 time-out.


> > Trying to read e.g. 
> > http://git.kali.org/gitweb/?p=live-build-config.git [...]

> I'm not sure there's much to find in live-build-config.
> http://files.akeo.ie/live-build-config/

Hrmpf, nothing to see of mkisofs options or a xorriso run.


Have a nice day :)

Thomas