51–60 of 182 posts
Earlier quoted context omitted.
In prior article "slow by design", this was reported to Apple and the bug was closed that it works like that by design.
I did see the previous article (another comment of mine should be easy to find on its HN post). Do you know how to find the issue that was referenced? There was an ID given but I have no clue what tracker that was on.
Earlier quoted context omitted.
I did see the previous article (another comment of mine should be easy to find on its HN post). Do you know how to find the issue that was referenced? There was an ID given but I have no clue what tracker that was on.
It's probably Radar, which is Apple's internal issue tracker, which isn't public (you can see issues you submitted, but nothing else). Sometimes people cross-post issues they submit to http://openradar.appspot.com , so you might be able to find it there.
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...
Earlier quoted context omitted.
In prior article "slow by design", this was reported to Apple and the bug was closed that it works like that by design.
I did see the previous article (another comment of mine should be easy to find on its HN post). Do you know how to find the issue that was referenced? There was an ID given but I have no clue what tracker that was on.
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…
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 ca…
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.
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...
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?
Edit: Checked and double checked: When I run a new shell script, syspolicyd just makes a connection with no application data
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.
This is no longer true. It is a very similar and annoying experience for me.
I use OSX, Windows and various versions of Linux.
The browser is the real platform at this point and is the shared experience between all three.
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 i…
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?
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.