Hi, I work with Buster, this is our notary log (please see below). The complaint we are receiving is that the files are returning with "The binary is not signed." and "The signature does not include a secure timestamp.", etc. Despite our pipeline (and code) not changing between the successful and unsuccessful runs. It only seems to fail on files that are contained within jars (again, despite working previously). We have checked that our certificates are valid. For future reference, is there anywhere we can see the notary service release notes? We had hypothesized a change on Apples side, requiring a change within our process, but could not find anything relevant. Let us know how we can assist further towards fixing this. Thanks, Bradley notarylog.json

Hi Quinn, No problem, its good to hear from you! For some additional context we are unpacking jars and signing them before repacking. We rely on these libraries for various functions within the program and can't just remove the code. For example we are using jffi-1.3.10-native.jar for which we need to sign the libjffi-1.2.jnilib binary. Our code was doing this correctly but as of September 4th we are now unable to successfully sign these. We have found various PR's from a few years ago about Apple dropping support for java compiled against MacOS 10.9 and earlier. Is there possibly something to do with this and is there any official docs we can read in order to keep up to date with these changes if so? Thanks, Bradley

Hi Quinn, The jar we are trying to sign is jffi from https://github.com/jnr/jffi/releases/tag/jffi-1.3.10. We are extracting the libjffi-1.2.jnilib from the jar and signing before re-packing them. This step goes fine with nothing going wrong. We then get issues when trying to notarize the application where it says the binary isn't signed, the signature isn't valid and there isn't a valid timestamp. sign-jar-force "./Contents/Resources/xx/drivers/jffi-1.3.10-native.jar" "jni/Darwin/libjffi-1.2.jnilib" sign-jar() { if [ -e $"$app_path/$1" ]; then echo "Signing (jar): $1 $2" unzip "$app_path/$1" "$2" -d "$temp_path" || echo "(jar $1): unzipping $2 failed" > "$temp_path/.failed" codesign --sign "$sign_identity" --timestamp "$temp_path/$2" || echo "(jar $app_path/$1): $temp_path/$2" > "$temp_path/.failed" jar -ufv "$app_path/$1" "$temp_path/$2" || echo "(jar $1) zipping $temp_path/$2" > "$temp_path/.failed" rm -f "$temp_path/$2" else echo "Skipping: $1 (path not found)" fi } This is our method for signing the jar. We have also tried it with putting --force on the codesign method. Thanks, Bradley

Good Morning, Sorry about that, we are using Maven so I believe this would be the link where the Jar we are getting is from https://repo1.maven.org/maven2/com/github/jnr/jffi/1.3.10/ , specifically the "jffi-1.3.10-native.jar". Thanks, Bradley

Hi, We found the solution in our pipeline which turned out to be using ditto in place of jar. We think when repackaging using jar this was modifying the file and therefore removing its signature. Unsure as to why this has hit us now, we couldn't find any material online that hints to Apples requirements getting stricter to include these unsigned files. Thanks for all the help, Bradley