Keka 1.1.26 is messing up the "com.apple.quarantine" extended attribute

[MaxPower85]

I'm not sure does this affect the previous versions too... I've noticed it now with the 1.1.26 version on Sierra.

Multiple issues related to what's probably just one bug.

So... just download some app that comes in a .zip archive... as you know, when you unzip it and open it, macOS should say which browser downloaded it and when... but if you unzip it with Keka 1.1.26 it says "Keka created this file on an unknown date".

You can use xattr in Terminal to read and write extended attributes
Trying "man xattr" explains how it's used

xattr path_to_file lists all extended attributes for a specific file
xattr -l path_to_file lists all extended attributes with their values for that file
xattr -rl path_to_some_directory would list it for all files in a directory (because different files could have different extended attributes)

In this case, we are interested in "com.apple.quarantine" only
If a file has com.apple.quarantine extended attribute set, you can read it with:
xattr -p com.apple.quarantine path_to_file
You can write extended attributes to all files in a directory with:
xattr -rsw 'attribute_name' 'attribute_value' path_to_the_directory

Keka does set com.apple.quarantine extended attributes for files it extracts from an archive, but the value of the extended attribute is not the same as what the archive had and it also seems to add that extended attribute to files that were extracted from an archive that didn't have any extended attributes set... it also seems to add it to files and archives you compress with Keka when you are using 7zip... so Keka seems to be adding that attribute as if Keka downloaded all the files it compressed or extracted... so even if you try extracting something you compressed with Keka with another app, that Keka's attribute would still be there (keep that in mind when fixing the bug, so it would not confuse you... after the bug is fixed, when you do the testing start with files that have no extended attributes set and check that extended attributes don't get added as they get compressed/uncompressed... and if the files had extended attributes set that they stay the same after compressing/uncompressing them... and if the archive had the "com.apple.quarantine" extended attribute set that it gets applied to the files when they are uncompressed).

Keka should not try to add any extended attributes of it's own to files, since it's not downloading the files itself from the Internet... if files had some extended attributes set, it should keep them as they are when it compresses them, unless "Exclude Mac resource forks" was selected (then it should not include any extended attributes when it compresses files and not add it's own attributes too)... and if an archive had the "com.apple.quarantine" extended attribute set, it should copy it to all files extracted from it, as other archivers do, but if the archive didn't have that attribute set, then it should just keep the attributes as they are and not try to add it's own.

If the archive had that attribute set, you can copy the value you get from xattr -p com.apple.quarantine path_to_the_archive
and you can set that attribute with that same value to all files that you previously extracted with:
xattr -rsw 'com.apple.quarantine' 'attribute_value' the_app_that_was_extracted_from_the_archive

[aonez]

@MaxPower85 can you check if this is fixed for you in the 1.2.0 betas? Be sure to have "Inherit quarantine..." in the Preferences.

Most probably this is a dupe of #176.

[MaxPower85]

OK... I'm testing the beta as I'm writing this...

As I opened it, I first tried to see would Keka add its own "com.apple.quarantine" attribute when extracting from an archive with no extended attributes... and it does.

I then tried compressing an image with no extended attributes... and Keka added its own "com.apple.quarantine" attribute to the archive...

I then tested it with an archive downloaded from Internet (so it did have "com.apple.quarantine" set and macOS should say that it was downloaded by Safari)... again, Keka seemed to just replace it with its own "com.apple.quarantine" attribute and trying to extract an app from a .zip with Keka makes macOS show a message "Keka created this file on an unknown date" when you try running it.

I checked Keka's preferences and "inherit quarantine from downloaded files" is selected.

Turning it off and trying again doesn't seem to make a difference.

I'll look do maybe some older versions have that issue.

[aonez]

Keka add its own "com.apple.quarantine"

This really is done by macOS. When a file is created within a sandboxed app macOS adds that quarantine information. There's nothing the sandboxed app can do about that. You can read more about that in #405.

As for inheriting the original file quarantine, note this will not be fixed in 1.1.x branch but it's fixed in 1.2.x branch.

Just in case I've checked again using the latest beta and the latest stable release as the ZIP with download quarantine. The extraction of that ZIP with the beta inherits the download quarantine, as shown:

[MaxPower85]

Then it probably just doesn't work on Sierra (and maybe on some other version too)

After the "Extraction complete" notification appears and Keka closes like it usually would after extraction, several seconds later macOS shows "Keka quit unexpectedly"... Maybe that's why it's not working... maybe the "helper" isn't compatible with Sierra and maybe it just crashes instead of trying to change the extended attributes.

And as I mentioned, Keka's "com.apple.quarantine" extended attribute gets applied to the archive too upon compression... that could create an issue upon extraction (either for Keka or for another archiver), as the app is trying to apply the "com.apple.quarantine" that the archive had to the files it extracted from it and then it would still say "created by Keka" even if the option to "inherit" the "com.apple.quarantine" extended attribute was selected because the archive had it too.

Either all compression/extraction should be done by a "helper" that isn't trying to conform to AppStore restrictions to avoid that, or a "helper" should copy the "com.apple.quarantine" from the directory/file it is compression and apply it back to the archive after the compression (and if it didn't have "com.apple.quarantine" to clear it).

[aonez]

The quarantine code is available for Mac OS X 10.10 and up.

For the helper that removes the creation tool quarantine flag: #405

Note that the download information from the quarantine has priority over the creation tool. I'm consistently getting the message shown here #544 (comment) if the original file has that quarantine information.

several seconds later macOS shows "Keka quit unexpectedly"...

This is due some changes in the sound played after a process. You can disable the extraction sound and you should see no crash. Anyway this code executes after the operation completed.

[aonez]

Closing this one in favor of #405. Let me know there if you still have problems.