I'm working on some code that creates/extracts Zip files and I want to propagate the extended attributes the way Apple compress/uncompress utilities do including the attribute apple.com.quarantine. The Apple compress/uncompress utilities store attribute data in "hidden" AppleDouble files under __MACOSX in the Zip file. In an AppleDouble file, the extended attributes are stored in an extension to the FinderInfo entry following the magic keyword ATTR. The details of the attribute representation are described in Apple's open source copyfile.c.
For most attributes, the binary data exactly matches what one would get viewing the attributes from the command line like:
xattr -px some.attribute file
However... digging through the code of copyfile one finds that it special cases some attributes, specifically:
com.apple.quarantine (XATTR_QUARANTINE_NAME)
com.apple.FinderInfo (XATTR_FINDERINFO_NAME)
com.apple.acl.text (XATTR_SECURITY_NAME)
For com.apple.quarantine, copyfile calls qtn_file_to_data to construct the binary and this routine doesn't appear in the open source.
For a typical quarantine attribute like:
xattr -l file.png
com.apple.quarantine: 0082;632a39ad;Preview;
xattr -px com.apple.quarantine file.png
30 30 38 32 3B 36 33 32 61 33 39 61 64 3B 50 72
65 76 69 65 77 3B
In the corresponding AppleDouble file, the actual binary data (152-176) is:
0000144 71 2f 30 30 38 32 3b 36
0000160 33 32 61 33 39 61 64 3b 50 72 65 76 69 65 77 3b
0000176 00
The 30 30 38 32... is just the characters starting with "0082.." but 2 extra bytes (71 2f) have been pushed in front and the 00 appended at the end.
Can anyone shed some light on this representation?
In copyfile.c, the corresponding decoding method is qtn_file_init_with_data. I guess I can just call this like copyfile does but I'd like to better understand what's going on.
Use of quarantine is an important part of Apple security and has figured in previous Mac vulnerabilities such as CVE-2021-1810 so I'm trying prevent my application introducing a potential vulnerability.