> On Aug 3, 2020, at 23:55, raf <[email protected]> wrote:
>
> On Tue, Aug 04, 2020 at 01:06:28PM +1000, Joshua Root <[email protected]>
> 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_ ...
