Catalina - Verifying "application name" - first time users run application after login

[dlondon]

Hi,

I'm getting a whole lot of software ready for a new set of lab deployments. With Catalina I see this message Verifying "application name" with a progress bar.

Looks like a reasonable thing but it happens every time the users log in and with an Application like Mathematica it's taken a really long time - at least 1/2 an hour

Is there some way to approve these or disable this checking? I know it's a security feature but we can't have the students waiting that long in a lab.

[micmil]

Just started testing Catalina and I agree this is very annoying and not conductive to lab use. I found this solution on another site, but I'm hesitant to apply it. Not sure if I want to disable yet another security feature (currently working on getting Gatekeeper re-enabled after dumping legacy software).

Use Terminal to disable verification on your Mac:
Open Terminal from the Utilities folder in Applications.
Copy and paste the following command into Terminal, then press Return:
defaults write com.apple.LaunchServices LSQuarantine -bool NO
When you want to re-enable verification, enter the same code into Terminal replacing NO at the end with YES instead.

[mm2270]

This often comes down to how the app was deployed, with permissions and such. All apps downloaded from the internet automatically get an Apple quarantine flag on them. Gatekeeper is doing it's job that when it sees an app with that flag, it needs to verify that it's kosher before allowing it to run. This can usually be fixed by removing the quarantine flag before deployment of the app. A simple way to do this is to run the application a couple of times before packaging it up. But in a case like this where it's already installed, you can still remove the flag. It may not be getting removed because of bad permissions on the app. If it's locked down the OS may not be able to effectively remove that quarantine flag after it gets checked, which causes Gatekeeper to check it again and again and again, each time it's launched.

Usually a command like this will fix it:

sudo xattr -dr com.apple.quarantine /Applications/AppName.app

[dlondon]

Hi @micmil defaults write com.apple.LaunchServices LSQuarantine -bool NO
looks to be a global disabling of checking the com.apple.quarantine attribute for app's downloaded. @mm2270 gave a method for disabling it per named app.

I already do this whenever I install something
ls -@l /Applications/AppName.app the output of that command is something like this if the quarantine attribe is set

total 0
drwxr-xr-x@ 8 username admin 256 20 Dec 2018 Contents com.apple.quarantine 58

If I get the com.apple.quarantine showing up, I then do:

sudo xattr -dr com.apple.quarantine /Applications/AppName.app

a repeat ls -@l will show the change. You can then package that App up.

All that being said, it doesn't look like this is related to com.apple.quarantine so your answer made no difference even after a restart. I did see other people saying the same answer you gave in my searches but (at least in my testing) it's not affecting the verifying. The message is about verifying and doesn't require any approval like you get when you download an application and launch it the first time.

[Gaden]

On every new Mac with Catalina I've installed lately its Verifying "Garageband", so its not just downloaded apps...

[claudiogardini]

@Gaden I've seen the Same. Macbook with 10.15 suddenly starts to verify Garageband during the Setup Assistant. We did not Deploy any VPP Apps to the Devices so it must have been the preinstalled App.

[snowfox]

I'm having the same issue recently with Adobe Creative Cloud 2020 apps and only those apps. It must be something to do with Adobe not signing their auto generated CC packages. The apps have to be verified on first run. After that it doesn't happen any more. None of them have the quarantine xattr. I checked all 19 of them after a clean install without running them. I haven't found a solution to this yet. All other apps with signed packages or created by composer etc, work fine. (I did also try running the xattr command against them all but they still go through verifying application on first run.)

[scottb]

FWIW, I get this message on Office 365 apps when downloaded via MAU as well. Doesn't take too long so never really worried about it.

[jeybailey]

We are seeing this on everything, which is particularly frustrating for labs. We can't just put it out like this, and with monolithic imaging not a thing with 10.15, it's really a problem. Launch every program on every Mac before deep freezing for a lab machine with maybe 70 apps? Yeah fun times.

There was no quarantine flag on the apps/files, tried disabling GK, giving program full disk access, nothing seems to side step it. Using composer I tried to capture what was happening when it does the verify, and it seems like it's writing something to an SQL-Lite DB file, or files. It's per machine too, so verifying an app and then deploying it elsewhere doesn't resolve the issue on the target machine (which used to work when it was just GK we were dealing with). I also tried running the verify codesign and assessment for system policy commands against the apps with no effect. I was hoping to find a way to programmatically run them through the verification process, but the best I came up with was to do a find *.app and execute the app to open. Don't sudo that or it will do it with uninstallers too; as long as it's not sudo'd you should get prompts that you can cancel on those, but you have to be mindful as you click through the mountain of apps and notifications. Yes it still sucks, but it's better than manually clicking everything... If someone finds or develops a fix, please post. I'm hoping a future 10.15.# update either fixes it to work as it used to, or adds a method of doing this through MDM. As of now, I think we'd have to figure out what it's writing to the db file(s) and then build a utility to do that on demand on all, or a selected folder of, applications. I updated from 10.15.5 to 10.15.6 with no change in behavior (though it did fix the bug where the computer would lose its name when updated, which was super awesome for domain binded machines).

I can only assume this will be the basis of how OS 11 will be designed, but who knows what new mouse traps they'll put in there...

[ripple1]

Hi there. Your post describes the maddening situation I have found myself in with school starting only hours away. DID YOU EVER FIND A SOLUTION? I will keep searching but if you could tell me yes or no that would help GREATLY. Thanks!

[jeybailey]

Any updates? This is pretty frustrating on a lab deployment. I've tried all three options without success.

[CancerLeo9324]

me too, this question , any solution thanks?

[dlondon]

We are still getting this. Mathematica is a real pain because of it

[dlondon]

I've just deployed Mac OS 10.15.6 and the message seems to have gone for Mathematica which has been checked/verified previously. Anyone else had a chace to see if that fixes it for them?

[jeybailey]

No change here, was using 10.15.6, with the supplemental update applied. Did you maybe already open the apps on that system on another user account? For the most part, it seems to satisfy it as long as they were opened at some point by some one. After an update, it'll do the verify again though.

[barcollege]

Just tried 10.15.6 and am getting same need to verify every app on first launch tried the sudo xattr -dr com.apple.quarantine and it makes no difference. Has something changed from previous versions off catalina.

[RJH]

also seeing this, for GarageBand at the setup-assistant stage, and GoogleUpdater also triggering the same dialog box, which for an automated build which then holds up the workflow, not great.
Anyone find a fix for this ?

[GetCart3r]

Anyone have luck with figuring this out fro Big Sur? I'm running this for any and all of the Adobe software and it still sits there to verify and takes forever. 

[snowfox]

Its the macOS Gatekeeper application verification service that checks every app if the app is updated, downloaded from the internet or the crc check doesn't match since the last scan.  It's a macOS security service.  We bought machines with solid state drives, problem solved for us.  We got rid of any machines with mechanical HDDs in them.  Not everyone is in a position to do this but it is the way forward.  

[RJH]

@snowfox can you clarify how buying SDD versus spindle disks resolved the issue for you?  Based on your description of the issue the CRC/last scan check issue will still persist, regardless of type of drive.  Are you suggesting that somehow performance comes into play ?

[snowfox]

Yes, for us, ageing 2013 model devices with mechanical HDDs + Antivirus scanning the /Applications and /System directories were working against us.  The gatekeeper service is part of the operating system.  You can either fight Apple or embrace Apple.  On devices with SSDs the gatekeeper service will still do scans but it will fly through them.  You'll also have to whey up performance vs security risk by possibly adding exclusions to your AV for specific large apps.  Some trial and error required if they are causing usage issues in student labs etc.  

Perhaps you just want to exclude the Adobe apps.  It's up to you.  On 2017, 2019 and 2021 iMac models with SSDs in them, our Adobe CC 2021 apps start up super quick and rarely do we see the Gatekeeper scanner running.  When we do, it completes super fast.  So it is no longer an issue and we don't try to disable it any more.

[Jey]

IIRC I used a KEXT app approval to get it working.  Will have to dig and make sure that was the only piece of the puzzle, as it's been a hot minute...  Though they are correct in noting that an SSD is essential for any reasonable performance expectation, which I think is common sense for any computer system today, I disagree with SnowFox's general approach...    I also can't imagine any System Admin or Security Officer worth their salt allowing you to exempt apps from security scans, and it certainly wouldn't be my approach...  Here's the code to the script that I used to generate the KEXT policy file, hope it helps someone:

#!/bin/bash

# Script to scan a system for kexts and gather the information needed for Apple whitelisting
# richard at richard - purves dot com

plist="com.apple.syspolicy.kernel-extension-policy.plist"
output="$HOME/Desktop"
override="false"

# Stop IFS linesplitting on spaces
OIFS=$IFS
IFS=$'\n'

# Scan the drive to find 3rd party kexts
# Excluding /System /private ./StagedExtensions and /dev

echo "Searching your drive for kext files"
echo "This may take a while. Please wait ..."
echo "(please enter your password if prompted)"
paths=($( sudo find / \( -type d -name "System" -prune \) -o \( -type d -name "private" -prune \) -o \( -type d -name "StagedExtensions" -prune \) -o \( -type d -name "dev" -prune \) -o \( -name "*.kext" -type d -print \) ))

echo ""

# Report the details of all found

if [ ${#paths[@]} != "0" ];
then
    for (( loop=0; loop<${#paths[@]}; loop++ ))
    do
        # Get the Team Identifier for the kext
        teamid[$loop]=$( codesign -d -vvvv ${paths[$loop]} 2>&1 | grep "Authority=Developer ID Application:" | cut -d"(" -f2 | tr -d ")" )

        # Get the CFBundleIdentifier for the kext
        bundid[$loop]=$( defaults read "${paths[$loop]}"/Contents/Info.plist CFBundleIdentifier )

        echo "Team ID: ${teamid[$loop]}    Bundle ID: ${bundid[$loop]}"
    done
fi

echo ""

# Start to generate a plist file
echo "Processing Team IDs into xml"
echo ""

if [ ${#paths[@]} != "0" ];
then
    # Prune the duplicate ID's from the array
    nodupes=($( echo "${teamid[@]}" | tr ' ' '\n' | sort -u ))

    # Now write out the xml with what we've discovered
    # Header first

echo '<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>' > /private/tmp/tmp.xml

    # Start with the User Override
echo "<key>AllowUserOverrides</key>
<$override/>" >> /private/tmp/tmp.xml

    # Now the Team IDs

echo '<key>AllowedTeamIdentifiers</key>
<array>' >> /private/tmp/tmp.xml

    for (( loop=0; loop<${#nodupes[@]}; loop++ ))
    do
        # Write the team identifier to the file
        echo "<string>"${nodupes[$loop]}"</string>" >> /private/tmp/tmp.xml
    done

    # Now for the Bundle IDs with the Team IDs

echo '</array>
<key>AllowedKernelExtensions</key>
<dict>' >> /private/tmp/tmp.xml

    for (( loop=0; loop<${#nodupes[@]}; loop++ ));
    do
        # Write the team identifier to the file
        echo "<key>"${nodupes[$loop]}"</key>" >> /private/tmp/tmp.xml
        echo '<array>' >> /private/tmp/tmp.xml

        # Parse collected data to write out captured bundle ids that match to the team id
        for (( loopint; loopint<${#teamid[@]}; loopint++ ));
        do      
            if [ "${nodupes[$loop]}" = "${teamid[$loopint]}" ];
            then        
                echo "<string>${bundid[$loopint]}</string>" >> /private/tmp/tmp.xml
            fi
        done

        # Reset internal loop variable and close tags
        loopint=0
        echo '</array>' >> /private/tmp/tmp.xml
    done

    # Close up, we're done

    echo '</dict>
</dict>
</plist>' >> /private/tmp/tmp.xml

fi

# Now format the file nicely and rename

cat /private/tmp/tmp.xml | xmllint -format - > "$output/$plist"
rm /private/tmp/tmp.xml
cat "$output"/"$plist"

# Reset IFS and quit
IFS=$OIFS

exit

[ripple1]

Jey, are you the same person as the username jeybailey earlier in this thread? That person had issues with 10.15.6.  I am confused about this post and script. I don't think anyone had mentioned KEXTs in my reading about stopping repeated verifications until now. I apologize for my ignorance about, well, everything. For which OS is your script above meant? What is the path to where the generated file should be placed to take effect? I used the locate command on a 10.15.7 lab machine and got no hits. On my personal Big Sur machine I got one hit, and that was inside the app iMazing (used with iPhones).  Thanks.

[jeybailey]

Yes, they appeared to change identity management on this site, so my email
no longer was tied to the old ID (though I couldn't reclaim it either...).

It was on 10.15, run as sudo, don't think it matters where it is run from.
In Meraki there is an area for KEXT policy files, I'd imagine Jamf has
something similar.

I was in super rush mode back when I figured everything out back then, and
haven't updated much since (and didn't document unfortunately due to the
time crunch we were under at the time. I'm likely to be circling back to
update some things with our Macs in the next week, so I'll look through
things and see if I can't nail more information down. It was very much a
matter of shooting Zombies at the time... no time to celebrate one thing,
with another clawing at me...

[ripple1]

Thank you. I'm still at a loss about how KEXTs are related to app verification. They only seem to be related to app approval. And how does one execute a plist file??

[Jey]

Here's the article on doing it in JAMF:

https://docs.jamf.com/jamf-school/deploy-guide-docs/Whitelisting_Kernel_Extensions.html

Meraki:

https://documentation.meraki.com/SM/Profiles_and_Settings/Configuration_Settings_Payloads

MS Endpoint Manager (InTune):

https://docs.microsoft.com/en-us/mem/intune/configuration/kernel-extensions-settings-macos

Looks like they've deprecated KEXT in favor or System Extensions though, so that's likely a little different...

Apple articles on System Extensions (SEXTs/sEXTs?  I guess be careful if you offer to share your sEXTs...):

https://developer.apple.com/documentation/systemextensions

https://developer.apple.com/system-extensions

JAMF articles on sEXTs, which is likely where we should be looking moving forward...

https://community.jamf.com/t5/jamf-pro/system-extension-activated-waiting-for-user/td-p/229168

https://community.jamf.com/t5/jamf-pro/how-to-system-extension-in-macos/td-p/160231

I'll update this if I recall anything further, hopefully they don't disable kEXTs for updates to 10.15.

[Jey]

I just updated an image, and with the updated software, all updated software required verification again... so once you update 10.15 beyond one of the early dot releases, the solution doesn't appear to work anymore.  From what I've read, OS 11 *should* work using the above method, but I haven't tested it myself yet.

[ripple1]

Hello all,

Just to be clear, it seems to me that no one was able to resolve the issue of repeated verifications of apps in macOS 10.15 in a sane manner. Right?  I'm working with 10.15.7 (because that is the last supported OS for the classroom labs I support).

My experience in the last few weeks before school started was that:

+ at least some apps were being verified EVERY time one logged in (I tried two users, one administrator, one not)
+ apps were being verified that the user had not started. The user, in fact, could sit there doing nothing after providing login credentials and app-verification dialogs would still appear for, at least, Xcode and Mathematica.
+ these 2017 iMacs with 5400rpm HDD were pretty unresponsive for too many minutes to be acceptable (3-5) after login
+ I tried to remove the com.apple.quarantine extended attribute from the programs' files (recursively, even, despite that not being used in any of the examples I found) (I did find an app which had files deep inside it with that xattr).
+ I had changed Gatekeeper settings to allow apps from any developer
+ I left a user logged in for a few hours (to allow any verifications to complete), then logged out and back in again.
+ I gathered TeamIds and bundle identifiers and tried to whitelist them via a method I do not now remember. No joy.

I had not had this problem on either the laptop or desktop Macs I used for months/a year with 10.15.7. Nor did I have it on the system that I used to develop the master image.

The only way I was able to save the situation was to boot to Recovery mode and run...  three very insecure commands in the Terminal. I have not yet had time to try reverting those three settings to normal (secure) values to see what happens. As the machines are Frozen using Faronics DeepFreeze application and users can only use one non-administrator account, I accepted the solution. Well, I was right out of time, so...

Did anyone you know work around or solve outright this app verification nightmare? Thanks.

[jbutler47]

Whenever I get the "macOS cannot verify the developer" error, not too often these days, I usually modify the affected file with Terminal.  In this instance, let's say it's a screen saver you created and farming out it out to users. 

sudo xattr -c /path/toyourfile/filename.extension

[donmontalvo]

IMO the "Verifying <application>..." dialog isn't a big deal. Users aren't asked to respond to anything.