com.apple.quarantine attribute on MacPorts files?

[Richard L. Hamilton]

> On Aug 3, 2020, at 23:55, raf <macports at raf.org> wrote:
> 
> On Tue, Aug 04, 2020 at 01:06:28PM +1000, Joshua Root <jmr at macports.org> wrote:
> 
>>> Out of curiosity, looking for files that seemingly without good cause had the com.apple.quarantine extended attribute on them, I noticed that almost all (417 out of 425) of the files installed for port libsdl had it on them (as well as two files for xephem:  /opt/local/share/xephem/auxil/wmm.cof and  /opt/local/share/xephem/lo/lodb.xml).
>>> 
>>> That was on a system running Mojave, with not as many ports installed as some of my other systems.
>>> 
>>> On a system running Catalina, in addition to those, I saw the attribute on about 155 of the 962 files installed by wxPython-3.0.
>>> 
>>> Nothing bit me in the eyeballs looking at the Portfile for libsdl, so I don't know why this happened. But it happened consistently on at least two systems, and I didn't do anything particularly strange installing MacPorts on them. But since _most_ ports don't leave that sort of mess around, I'm thinking it shouldn't have happened.
>>> 
>>> AFAIK, it hasn't caused any problems (give or take that extended attributes do consume a slight amount of disk space); but all oddities are IMO suspect that they might be suggestive of something not being done in the usual or correct manner (with the possibility of additional un-noticed repercussions), so I thought that having noticed this, I'd mention it.
>> 
>> For libsdl it would be a side effect of how I generated the distfile.
>> It's installing a snapshot of the hg repo because there have been a lot
>> of important fixes since the last release of the 1.2 branch, and the
>> next release may be a long way off still (if it ever happens; 1.2 is
>> only kept around to support projects that haven't moved to SDL2). I
>> re-made the tarball myself because there is no suitable tarball
>> available from upstream (the hg web interface generates tarballs that
>> differ depending on when you generate them, and the directory name is
>> not what MacPorts expects).
>> 
>> As you say, it shouldn't cause any serious problems, but I'll try to
>> avoid it in future tarballs.
>> 
>> - Josh
> 
> A command like this should fix it:
> 
>  xattr -rd com.apple.quarantine *
> 
> cheers,
> raf
> 

Yes, I'd done that already on some other things, just left this one for now in case the details are of interest in determining why it happened.

FWIW, I've noticed that the xattr command (a python script, actually) can be cranky about the use of multiple options. I've had best luck keeping them separate, and putting all the other options before -d, so I end up with

xattr -r -s -d com.apple.quarantine _pathname1_ ...

(-s is to act on a symlink rather than what it points to, usually safer and more thorough with that

Other variations of how the options are combined may work; but in general, putting options together that don't take arguments with those (like -d) that do, is not thought to be a good idea. Some implementations of getopt() or something similar can handle that, some can't.  So I could probably get away with xattr -rs -d com.apple.quarantine _pathname1_ ...