
Catalina is checking notarization of unsigned executables - robenkleene
https://lapcatsoftware.com/articles/catalina-executables.html
======
mokus
I guess the list of things keeping me off catalina (and, by extension, new Mac
hardware) just got one item longer.

I recently bought a new System76 laptop as a stopgap, but it might end up
becoming permanent. Kind of a sad end for 25+ years of Mac use.

~~~
rayiner
My 16” is a huge disappointment. After swearing off Intel PCs after a disaster
ours X1 Carbon, I switched back to a 2013 15” until this month. Figured after
six months bugs would be ironed out. Wrong. I’m seeing two major glitches that
have macrumors threads dozens of pages long: 1) with an external display
connected, dGPU utilization shoots up to 20W at idle. (The rest of machine
draws well under 10W at idle.) That wouldn’t be a big deal if the CPU and GPU
didn’t share a tight 70W power budget. 2) when connected to an external
monitor or dock—I’ve tried two different TB3 docks—the machine kernel panics
regularly, usually waking up from sleep.

I’m torn. I don’t want to return the machine because everything else is crap.
At least the 16” works well as a laptop so long as you don’t plug anything
into the ports. But Apple’s Q&A has seriously gone down the toilet ever since
Steve Jobs died. Clearly him throwing staplers at people was the glue holding
Apple together.

~~~
nightowl_games
My partner is a graphic designer who loathed her 13" macbook that her work got
her. She finally got an upgrade to a 16", i9, 64 gigs of ram.

It runs adobe software like total shit.

I think it's something to do with Catalina + accessing files in Google Drive
File Stream + Adobe.

It runs illustrator horribly.

It's basically the saddest thing I've ever seen.

I think I'll get her a 17" XPS for christmas this year.

~~~
Ductapemaster
For what it's worth, I have _never_ had good luck with "big vendor" software
(like Adobe) and using any sort of synced cloud-based filestore. I have had
untold issues with things and as soon as I moved files local, everything
magically went away. Might try that!

~~~
oefnak
You can also set the relevant folders to keep the files always available
offline.

------
londons_explore
This must be a blacklist, since it doesn't block my own random scripts which
it has never seen before.

If it's a global blacklist on apple servers, it should instead be downloaded
to the client, and be a local blacklist.

Too big? Use a bloom filter. Now you only end up keeping less than one byte
per blacklisted item. Update the bloom filter with an autoupdater. Any
positive hit you can check against the server just incase it's a false
positive.

~~~
caf
Doesn't a blacklist also work only until the malware authors figure out how to
randomize 8 junk bytes every time they serve an executable?

~~~
dimator
That's the crazy thing about this. There's already obfuscation techniques
against hash blacklists, so what is this even for? There's no earthly way
apple security engineers didn't know that. So what is actually happening?

My guess is that it's strictly for banning app store apps that they pull from
the app store, but would like also to cripple retroactively on installed
machines. But that doesn't explain why it had to run against random shell
scripts? This is all still confusing. We don't have all the info.

------
londons_explore
So you're telling me that every time I install a program in OSX, it pings
apple to let them know what program I'm installing, my IP address, my
location, and my OS version?

Sounds very Orwellian for a privacy focussed company...

~~~
daneel_w
No, that's not what he's telling you. You're getting ahead of yourself with
your question. He's telling us that macOS will consult with Apple regarding
the "fingerprint" of an executable when you run it.

~~~
londons_explore
But the fingerprint of photoshop is the same for everyone. If apple knows what
the fingerprint of photoshop is (which they could easily find out), now they
have a giant list of who installed photoshop and when, and from which IP
address, and which IP location.

That data would be a wet dream for some IP lawyer looking for pirate copies of
software...

~~~
microtherion
The Photoshop binary is signed (presumably; it's been years since I last ran
it), so this check would NOT be conducted.

Edit: What I should have said is that the binary is signed, notarized, and the
notarization stapled to it, as described here:
[https://developer.apple.com/documentation/xcode/notarizing_m...](https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow?language=objc)

~~~
lloeki
The author of the article mentioned explicitly that he signed a binary, and
the check still occurred.

~~~
tcoff91
Did he staple the notarization though? They are 2 separate steps.

------
thih9
The article mentioned at the beginning is already discussed here:
[https://news.ycombinator.com/item?id=23273247](https://news.ycombinator.com/item?id=23273247)

------
usmannk
There is so much confusion here. The OP and most others are missing one of the
biggest points: Look at the packet trace. There is _no data_, not even a hash,
being sent. It's a TLS negotiation and then the connection ends. I have to
suspect it's a bug...

~~~
lapcatsoftware
I'm not sure what you're seeing, but that's not what I'm seeing. When I
Wireshark both app notarization and script notarization, I see 2 packets of
encrypted Application Data sent to Apple (567 and 101 bytes), and 1 packet of
Application Data (varying length) returned from Apple, in each case. What do
you see when you trace a regular app notarization check?

~~~
usmannk
This is odd, my proxy doesn't seem to show this. I will try to load my root
cert into Wireshark and check.

Edit: Checked and double checked: When I run a new shell script, syspolicyd
just makes a connection with no application data

~~~
lapcatsoftware
I'd recommend trying this: Download a notarized Mac app, delete any stapled
notarization ticket (.app/Contents/CodeResources), and then trace the launch.
What do you see, and does the system let you open the app? Does it say it
checked for malware?

~~~
usmannk
Ah I see, looks like we're not running quite the same experiment. I suspect
that anything including an app bundle ID is going to see some more interesting
traffic.

~~~
lapcatsoftware
Don't suspect, test. ;-)

I'm running both experiments. I've tested and compared script notarization to
app notarization.

You're getting apparently unusual results with script notarization. So the
natural next step would be to compare against app notarization.

~~~
usmannk
Agh, I think it was cert pinning. Looks like the connection is terminated if
you're snooping. I see the same results as you now. Thanks!

------
LeoPanthera
I can't reproduce the exact test specified in the article:

    
    
      $ echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
      $ time /tmp/test.sh && time /tmp/test.sh
      Hello
      
      real 0m0.016s
      user 0m0.002s
      sys 0m0.010s
      Hello
      
      real 0m0.006s
      user 0m0.002s
      sys 0m0.004s
    

I don't believe the 0.01s difference is long enough, and could easily
explained by filesystem caching. The article says:

> Some people try to explain away the delay, e.g., "I would put the 300 vs 5
> ms down to filesystem caching", but such hand waving doesn't stand up to
> further scrutiny.

...but does not provide any "further scrutiny", so for me, occam's razor
applies.

~~~
abathur
A few ideas:

1\. confirm the checks are enabled:

    
    
        spctl --status
    

2\. Make sure your terminal/shell/etc aren't already exempted System
Preferences > Security & Privacy > Developer Tools.

3\. If you already ran something that could generate a check in the last
minute, the connection is still open. Most of the overhead people are
recording is negotiation/handshake. If you're fairly close to the server, it
seems plausible your observed time could be enough for the communication minus
the negotiation. You can open Console.app and search `process:syspolicyd` in
the device log to see the entries for the negotiation; wait for it to
terminate.

4\. Try removing and re-creating a new file as in the test you did before and
check it a little more directly:

    
    
        spctl --assess -v --ignore-cache --no-cache /tmp/test.sh
    

If it's working, you should see a log entry with the text "summary for task
success" in it with a detailed breakdown of the request (times taken per
phase, bytes sent/received, etc).

~~~
userbinator
I don't have a system to check this on, but Apple seriously named an option
"asses"?

~~~
abathur
Ha, no. I'm the ass, here. Fixed :)

------
sjellis
It has to be said: if Apple published their source code, we wouldn't have to
rely on reverse-engineering and speculation.

------
TheRealPomax
Little Snitch is a god-send for users of MacOS, be they voluntary users or
forced into using it because their employer won't allow them to use anything
else.

~~~
mindfulhack
I've found Objective-See's LuLu to be even better in catching every
application and obscure binary daemon that ever makes a connection to the
network and allowing me to set a temp or permanent block/allow rule for it -
and it's FOSS. Try it out:

[https://objective-see.com/products/lulu.html](https://objective-
see.com/products/lulu.html)

~~~
brigandish
I didn't know about LuLu, thanks. I'm trying it out now and it's not been too
bothersome (so far), which is always nice. I used Little Snitch for a few
years but not only was it always in my face with the pop-up dialog (poor UI
choice) but because it uses plist files for its database it became
_incredibly_ slow. Had to give up on it.

I tried Murus/Vallum[1] too for a while but it was still a bit too complicated
and demanding. There's still a space for a firewall with a decent UI
available.

Won't be a Mac for me after this machine though.

[1] [https://www.vallumfirewall.com/](https://www.vallumfirewall.com/)

------
nojito
What's the exact data being sent?

There is a lot of arguing going on here, but what is the data?

~~~
azinman2
Seems to be a hash of the executable.

------
kimi
I am not sure of what is the whole point of this notarization thing. It would
be great (ahem, let's say so) if there was a big and closed list of
executables, but every shell / ruby / perl / python script can do many funny
things, and you cannot notarize them all. Often, as in bash, by design. So?

------
rvnx
It's great tool for mass-surveillance. Since Apple has a database of all the
apps the user has run on their device (but no worries, Google has the same).

For your security ;)

~~~
jmull
> great tool for mass-surveillance

It’s not really that great for mass-surveillance. It “phone’s home” only on
first run. And it doesn’t look like it sends data about your identity, device
or location. They can have your IP address but another mechanism would be
needed to relate that to you. (I doubt they are logging the IP address anyway.
The only purpose would be to surveil you, but if they wanted to do that they
would surely use a more capable mechanism . That makes keeping the IP
addresses a burden and risk.)

~~~
yyyk
>It “phone’s home” only on first run.

Do we know that? The cache may well have an expiration date. Does the cache
stay after an OS upgrade? I suspect further research will discover it's not
just 'first time'.

>They can have your IP address but another mechanism would be needed to relate
that to you.... if they wanted to do that they would surely use a more capable
mechanism.

The app profile would already tell a great deal. Once enough of these 'non-
capable' surveillance mechanisms add up, you end up with a very capable
surveillance mechanism.

------
abathur
late edit (2): added 3 notes including performance impact observation

I'm concerned about this behavior (both from privacy and performance
perspectives), but I'm also not (quite) convinced this is working as
described/implied here.

Before I get started: If you poke at this, open Console.app first. You can see
recent logged "assessment" checks logged in "Mac Analytics Data" with the
search "process:syspolicyd". You can use the same search to watch log messages
(including all of the TLS negotiation etc.) for the checks in the device log.

The part that seems weird is that, if it is transmitting a hash (which seems
possible/logical) the caching behavior doesn't appear to care or respect it?

The article suggests the following test:

    
    
        echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
        time /tmp/test.sh && time /tmp/test.sh
    

I tried this test and got real runtimes of 0m0.289s and 0m0.006s. Then, I
changed the file:

    
    
        echo $'#!/bin/sh\necho Hellok' > /tmp/test.sh && chmod a+x /tmp/test.sh
    

When I re-ran the script, both runs are under 10ms. The content changed, but
it didn't bother re-checking. I wrote the original script to a new file path:

    
    
        echo $'#!/bin/sh\necho Hello' > /tmp/test2.sh && chmod a+x /tmp/test2.sh
    

This ran with runtimes similar to the original (0m0.232s and 0m0.006s). Same
content, new path, new check. Here too, if it cares about the hash, it either
isn't bothering to use it for caching decisions or the hash includes the path.

Then I tried rming the file, writing it again, and running it. Once again, it
checks on the first request. I think this suggests it may be caching the
result by inode? The author said they saw new checks after saving changes in
TextEdit--I don't know much about TextEdit, but I'd guess it is doing atomic
write/rename here.

Other random details I noticed:

1\. it holds the connection open for a minute, presumably to minimize
connection overhead for executions that'll generate many checks. My first
checks were all in the 280-300ms range, but I tried one additional check
within the minute and it only took 72ms. Making multiple requests in less than
a minute may make it harder to notice

2\. The device log has a "summary for task success" entry with pretty precise
timing details on all parts of the request.

3\. On my system, each of these attempts produces a "os_unix.c:43353: (2)
open(/var/db/DetachedSignatures) - No such file or directory" error in the log
from the libsqlite3 subsystem after the response comes back.

4\. The "Mac Analytics Data" log entry for each request has a good summary
that looks like:

    
    
        assessment denied for test.sh
        com.apple.message.domain: com.apple.security.assessment.outcome2
        com.apple.message.signature2: bundle:UNBUNDLED
        com.apple.message.signature3: test.sh
        com.apple.message.signature5: UNKNOWN
        com.apple.message.signature4: 1
        com.apple.message.signature: denied:no usable signature
        SenderMachUUID: ...snip...
    

5\. When I add Terminal to the Developer Tools exemption on the privacy tab it
does appear to kill the check. I'm not sure if there's genuine protection this
check provides at some level, but I'll be considering adding either Terminal
or at least some specific build tools to the exemptions I add on a new system.

6\. After adding the Developer Tools exemption, if you have the app open,
it'll ask if it can quit it for you. I took the hint and restarted Terminal.
It'll do the same thing when you remove it from the list. But I didn't see the
checks actually return until I rebooted. Also, my system froze during reboot.
Hopefully a coincidence. :)

7\. To put a better number on how this performance impact can compound for the
kinds of builds I do all of the time, I ran `nix-build ci.nix` in the local
directory for one of my projects before and after enabling the Developer Tools
exemption for ~/.nix-profile/bin/nix. The run took 1m22s before, 45.5s after.

8\. Looks like this is the same check as is run by `spctl --asses -v <path>`
(at least, per the Console.app logs). That may make it easier to play with.

~~~
lapcatsoftware
> I think this suggests it may be caching the result by inode?

You may very well be right. I used TextEdit simply because it was easiest for
me to guarantee a new notarization check every time, but I don't know the
exact criteria that macOS uses to identify an executable as "the same".
There's probably some combination of path and/or inode in addition to the
hash.

------
mthoms
Does anyone know if adding the Apple domain in question to piHole (or your
hosts file pointing to 0.0.0.0) will suppress these checks?

~~~
TheRealPomax
If you're on MacOS, you want Little Snitch installed at all times, even if you
have a pihole: a process that is denied network access is far stronger than
juping DNS requests.

------
david-cako
macOS has quite a few built-in antivirus features:

[https://support.apple.com/guide/security/app-security-
overvi...](https://support.apple.com/guide/security/app-security-overview-
sec35dd877d0/1/web/1)

IMO, you have to pick a security vendor to trust (only as far as you can throw
them). Apple is incentivized to provide better end-user experiences as a
matter of having end to end authority for their products. They’ve built a
robust (albeit prescriptive) security/sandboxing ecosystem to avoid just
pointing at software vendors if a customer is unhappy.

I like these features, but the fact that they’re not always optional is
frustrating. Note also that soon macOS will be running on Apple ARM SoCs;
similar trade off.

Buy any other computer, and you now have Microsoft or Google, a CPU vendor, a
consumer hardware vendor, and possibly also an antivirus company installing
background services.

------
crazygringo
I'm still trying to understand what the problem here is.

Nobody seems to have an issue with checking this for apps -- it's a good
security feature to protect from malware, right? And which everyone knows
about? And it only happens the first time you run something, so it's not a
performance issue in everday usage.

And the article even states that there seems to be a valid reason for checking
shell scripts, because they can be used to compile malware.

The original complaint was about slowness, but how often do you run something
for the first time? The only scenario in which I can imagine this would become
a practical peformance problem is if, somehow, you have an app that spawns new
shell scripts all day long to execute, every few seconds, and a really flaky
internet connection. Or new shell scripts hundreds of times a second, even
with a good internet connection.

Is that something anyone ever needs to do? Programs can run shell commands
directly, without a file, so it seems unlikely. Also, another comment here
suggests that even if a shell script is modified, it isn't re-verified, so
there would seem to be a trivial workaround _anyways_.

Or is the issue just that this is undocumented behavior? Or what am I missing
here?

------
jbverschoor
Great! They can block malware as soon as they find out. Love it!

------
HugoDaniel
Im running my dev environment in a OpenBSD vm. This makes me wanna use it for
more stuff besides dev.

------
MintelIE
Why don't companies come out and tell people what they're doing these days?
Telemetry is getting to the point where people such as doctors and lawyers
might be violating the law by using a modern computer. And people in the
defense industry? Doesn't Apple employ thousands of forns? Who's audited their
datasystems and ensured that this stuff stays private?

Much easier and better to just stop using it all and move to a system like
Linux or BSD. 99% of people do everything in a browser these days anyhow.

~~~
ancarda
If only moving to Linux were an option for everyone.

The other day I tried for the 100th time to move to Linux. I installed a
recent build of a maintained, popular distribution (no it doesn't matter which
one - I have tried them all), on hardware that is famous for it's Linux
support.

Everything worked for a day and a half, then the sound just fucking died. No
input or output.

I get millions of people use Linux daily, and are happy with it -- I'm
genuinely grateful that's a thing. I would love to also use Linux, but I
really don't have the time to diagnose why it broke yet again.

Any suggestions for people stuck on macOS? I guess I could block all Apple
domains in my DNS resolver? Other than app updates, I can't think of anything
that would stop working. That still sounds less painful than trying to deal
with Linux's atrocious UX.

~~~
nine_k
I had sound drivers die on me on famous brands laptops under Windows.

I had OSX lock up or lose any display on MBPs with NVidia chips.

On my wife's old windows desktop I had to plug a USB audio dongle, because of
audio glitches.

Some of it is sloppy drivers, some, faulty or poorly designed hardware.

"Sound just died" is, unfortunately, not specific to Linux in any way.

~~~
ancarda
Sure, though I am describing my latest attempt in like 15 years of using Linux
on and off. At some point "every OS has its problems" just stopped being true
for me.

Linux really sucks for anything other than servers. I hate to say that because
I badly wish it weren't true, but it is.

~~~
pjmlp
How could it be any different actually?

A Linux conference is usually focused on the Linux kernel, drivers,
filesystems, networking, more or less everything POSIXy.

If you want to learn about improvements at the UI level, there are XDG,
GUADEC, Kacademy, each focused on their own silo, and other parts of the stack
or UI tooling don't have any at all.

Meanwhile WWDC, Google IO, BUILD / Ignite are about all levels of the stack.

------
msie
I was watching a Linus YouTube video on the upgradeability of Alienware
Laptops. So envious! Now you can't upgrade anything on the newest MacBook
Pros.

[https://www.youtube.com/watch?v=J-RXqNafscs](https://www.youtube.com/watch?v=J-RXqNafscs)

And if something breaks on your MacBook Pro, most likely you will have to
replace the entire motherboard or display.

PS: I own lots of Macs but sad to see the direction Apple is heading in.

------
huslage
This is a specious problem _at best_. We have a very secure operating system
doing things that others don't even try to do (notary) and we are complaining
because our shell scripts take _n_ seconds to run? Really people? If you are
running signed and notarized (stapled) binaries, the system never even reports
them to Apple in the first place.

This is the height of insanity to think that Apple or anyone else would want
this data or use it for some nefarious purposes...anonymous hashes of junk
data are essentially useless outside of this purpose. It's fine to claim not
to trust anyone for anything, but most of us aren't willing or able to build
our own hardware, write our own operating system, and write our own
applications. We have asked our vendors for devices and code that are more
trustworthy, and when they give them to us we COMPLAIN about it incessantly.
This makes no sense to me.

~~~
saagarjha
> We have a very secure operating system doing things that others don't even
> try to do

Perhaps because such a system is extremely centralized?

> we are complaining because our shell scripts take n seconds to run?

Yes? If I buy a computer and it spends time doing stupid stuff, then I think I
am fairly justified in being angry.

> If you are running signed and notarized (stapled) binaries, the system never
> even reports them to Apple in the first place.

Great, let's notarize and staple tickets to every little piece of software you
write…

> This is the height of insanity to think that Apple or anyone else would want
> this data or use it for some nefarious purposes...anonymous hashes of junk
> data are essentially useless outside of this purpose.

Executable hashes tell you if someone is running a specific piece of code.

> It's fine to claim not to trust anyone for anything, but most of us aren't
> willing or able to build our own hardware, write our own operating system,
> and write our own applications.

That's why I buy them from other people and would desire them to be good.

> We have asked our vendors for devices and code that are more trustworthy,
> and when they give them to us we COMPLAIN about it incessantly.

How exactly does this make the device more trustworthy?

