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

[Pete Batard]

Hi,

I recently found that some Rock Ridge ISOs processed using the latest 
libcdio were mangling file names. Instead names being returned with the 
expected Rock Ridge data, I found that I got something like 
"FILENAME.EXT;1" from libcdio, which created issues with my downstream 
code. I was also able to confirm that this behaviour wasn't happening 
with some older versions of the library.

Looking further into this, I identified that the commit that brought 
this change was 8b96bd3f ("Guard against malformed rockridge iso" from 
2015.05.08), where the Rock Ridge SUSPs are now being checked against a 
set of supported extensions, and that the issue happened if the ISO 
being processed (such as kali-linux-2017.1-amd64.iso) was using the 
nonstandard Rock Ridge extension 'AL'.

Obviously, as per the switch statement around line 172 of rock.c, 
libcdio does not currently recognize 'AL' as a valid Rock Ridge 
extension (whereas previous code just let it pass through), hence the 
problem observed.

Digging further into this still, I eventually managed to determine that 
the 'AL' Rock Ridge extension is something that the libburnia people 
(the developers behind libisofs & xorriso) introduced as part of their 
custom "Arbitrary Attribute Interchange Protocol" or AAIP, which they 
have documented at 
https://dev.lovelyhq.com/libburnia/libisofs/blob/master/doc/susp_aaip_2_0.txt

From what I gather, they created AAIP along with the 'AL' generic 
extension mostly in order to carry POSIX ACLs into an ISO 9660 
filesystem. These can then get added to the Rock Ridge data with the 
-acl option of xorriso.

My questions therefore are:

- Should libcdio add support for the 'AL' Rock Ridge extension?
- If so, is there anybody on this list willing to do it?

Regards,

/Pete

NB: There also