Gatekeeper Issues

You need to notarise the dmg. Notarising is the last step that you do. Codesign the app, do dmg, codesign that and finally notarise the dmg.

Ok, thank you very much!

I’m getting the “Unnotarized Developer ID” error, but not after notarising; not sure I should do your suggestion in this case.
Actually, I can notarise my apps, but it’s using some workarounds:
•I compile the Xojo app (add icons, fill the various fields, add a dummy “About” menu item to show the about box (necessary?), etc.).
•I drag the app to AppWrapper (Dock icon); I define fields. AppWrapper doesn’t recognise the icon from the app, so I must drag the icon file (png) again (not sure it’s intended).
•For “Packing”, I set to “None”: I don’t plan to buy “DMG Canvas” and it looks to be the only supported tool here for making dmg files.
•I press the “Diagnose” button to see if I’ve missed something. Then, I click the “Wrap” button.
•Wrapping goes… At the end, I get the “Unnotarized Developer ID” error (AppWrapper stops here because of this error; however, the app has actually been signed fine, so I can continue).
•In the Finder, I’ve a stationary folder; I replace the previous app by the newly signed one and have an alias to the applications folder. I also change the folder’s name and make sure the window’s size is small. I then go in “Disk Utility” to make a dmg file from that folder.
•I then drag the dmg file to AppWrapper. It asks me for the version and bundle information and puts it in the window made to submit to Apple. I’m confused for the differences between that window and the “Notarize” button in the “Wrap” step; do they do the same?
•The dmg is sent to Apple. Contrary to some beliefs, the dmg has not been signed along the steps; it gets straight to the “notarisation” step (well, I assume it gets signed along the way, but I don’t do it explicitly). I receive a confirmation and can distribute the dmg file.

That’s 100% reproductible with the apps I’ve notarised so far (for now, 5, excluding re-notarised ones). I must always follow these steps.

That will not work anymore from 1 February 2020. Apple allowed this way of notarising but signing the dmg from 2/1 will be mandatory before sending it to the Apple server.

Interesting, I’d like to understand this a little better, do you get an error or does the icon not show up?

I intend to add support for DropDMG, but I am hesitant to create my own DMG functions as both Seth & Michel create pretty darn good DMG apps, and I don’t want to take away their business.

The important thing here, is do you continue to get this message even after you’ve Notarized? Because as far as I am aware, once you’ve Notarized, you should no longer get this message. I have a contact in Apple’s Security team whose pretty keen to get as much information on this as possible.

This is because the code signing API returns an error, and at which point App Wrapper abandons, because it’s an error.

Yes, it’s just when it’s handled directly from App Wrapper, it already knows what the information is and doesn’t need it to be entered.

Yup, App Wrapper handles this, when you add the DMG to the Notarizer window, you select which signature to sign the DMG with (if it’s unsigned).

So you’re saying that for the last 5 apps you’ve Notarized, each time it gives you the Unnotarized Developer ID error?

No error. The image well just shows the “Drag&Drop a ICNS or Image File to set icon” text.

I understand. It’s true an integrated solution into AppWrapper would be great, but it’s also true well done apps need to be kept used.
Perhaps their DMG apps could include AppleEvents/AppleScript support so you can control them from within AppWrapper?
Or ask them if you can, by some other means, link to their apps?
If DropDMG is free, I’d consider using it rather than the Finder and Disk Utility (always renaming the existing folder and replacing and aligning the new app is needless, and the disk image is still not created yet…).

Well, I’ve done my 5 notarisations in a mixed fashion: notarised two apps, then two others, then a single one (speaking of the “submit” window). I’ve done all the steps I’ve enumerated in my previous post in order (each app after the other; only the “submit” window was used in group of two so I could make something else while the upload/checking process took place).
So, yes, after one app gets notarised, the following app gets the Unnotarised developer ID error on signing.

Yes, I understand that. However, since signing and notarising are different processes (one can sign without notarising), I’d think a “unnotarised developer ID” would not stop a sign-only step…

OK, makes sense… Just wondering whether I’m alone in not understanding this by myself.

Exactly. I’ve notarised one app last year (december 2019 :stuck_out_tongue: ) without this error (see one thread where I said it worked for the first time for me), but since then, always getting the unnotarised developper ID error.

Thanks.

Strange I’m not receiving these informations… Are we supposed to receive them by e-mail? (I guess “no”, but I expected it that way).

Anyway, AppWrapper does that automatically (signing the dmg while notarising), so that’s not a concern if we use that very useful app.
Thanks.

@Arnaud Nicolet
Thank you for taking the time to answer my questions, I know you must be very busy also.

Okay, I can see how this could be confusing and I am sorry about this, at this point App Wrapper hasn’t actually check the App’s icon. So you can safely ignore this. You only use this if you want App Wrapper to make and add the icon for you. Sorry about that.

For me it’s a battle of ethics v.s. business, I’ve known Seth for 20 odd years and I have great respect for Michel, so ethically I feel bad about stealing their business. I also see the benefit to App Wrapper customers of building a solution in.

[quote=470466:@Arnaud Nicolet]Perhaps their DMG apps could include AppleEvents/AppleScript support so you can control them from within AppWrapper?
Or ask them if you can, by some other means, link to their apps?[/quote]
There is already DMG Canvas integration, whereby App Wrapper has limited control over DMG Canvas to create the DMG. I expect it will be the same with DropDMG.

■■■■■■; this is what I was worried about. So my contact has asked if you could please use the Feedback (Apple’s Feedback) App to file a report with Apple and then give me the case number, so I can forward it to my contact, who is on Apple’s Security team, so we’re going straight to the correct team.

Unfortunately the error is reported while code signing. Until your account is unlocked (which it is supposed to be done when you Notiarize), the code signature of the app will appear as invalid. I really have idea what they were thinking when they did this. Sure block an app because it’s not Notarized, but to block all the developers apps because (at this point I assume it’s an Apple bug) is just insane.

No you are not alone, I am working on some code to read DMG files, Zip file and PKG files and extract this information, to save you having to enter it, but as I am sure you can imagine, it is a lot of work.

Which is in line with what other developers are saying, Jan 1st and boom, they now get this error again.

  • John McKernon

Is there a consensus that this is literally true with Catalina (come February)? I have not made the jump to Catalina myself. I am familiar with the “unknown developer” dialogue that pops up with Mojave but the user can override this.

Wouldn’t that mean if I wrote a Xojo program on my Mac desktop running Catalina and tried to run it on my portable running Catalina I would not be able to do so?

That I would require it be notarized with Apple and that I have an Apple developer account? Simply to run it on two machines that I own?

This seems extraordinary if true.

Citizen developer No commercial aspirations etc.

Again: nothing really will change next February. The dialog about not being able to check for malicious code is already there. If you open a not-notarised app with a right mouse click then you can bypass the dialog.

That will continue to work without Notarization. And it’s fine for that situation.

But as soon as one is going to distribute an application (making it available for download from the Internet) - then you don’t want to explain that “right-click and ‘open’” to all your (potential) customers. That’s when one should really go through this notarization process.

Thanks BW & JO for clarification.

[quote=470553:@Sam Rowlands]@Arnaud Nicolet
Thank you for taking the time to answer my questions, I know you must be very busy also.[/quote]
You’re welcome. It’s true I’m very busy, but I cycle thru all my tasks (the reason why I may respond “lately” sometimes). Anyway, I like App Wrapper and I’d also be happy if we can solve this problem (or make it even better, when available).

Ah, OK. Thanks for clarifying that.

Yes, I understand that. That’s why if they chose to add AppleEvents/AppleScript support to their apps, one would be able to make DMG files from another app without stealing their work nor making an extra built-in solution. As DMG and AppleEvents are Mac-only, this solution would fit.

Promising! I can hardly wait!

I wasn’t aware there’s an Apple Feedback app. In my memory, one used to send reports to Apple using radars URL, but I always thought it was “over complicated when you don’t know about that” and never used that.
I saw one Feedback app when I tried the Catalina beta (Apple’s survey app), but it was only for the beta testing.
OK, I’ll search for it and use it.

Granted.
Are all developers facing this issue, actually?

Yes, I imagine. It’s tied with all the time you’ve already spent with App Wrapper; that’s really a successful app you’ve made well, and it looks like it’s continuing on that line!

So either it’s a bug with the new year (the 2000 year “expected” bug striking Apple 20 years too late?) or it’s a wanted change from Apple (your contact seems to be unaware of that, but it’s perhaps not from the “security” area in Apple, who knows?).

Thank you.

At the moment, there are at least 4 categories of apps to consider:

  1. unsigned
  2. signed before the cutoff date (either April or June 2019, depending ?) see Notarization in Mojave and Catalina – The Eclectic Light Company
  3. signed after the mid 2019 cutoff date
  4. signed and notarized

At the moment, on the latest Catalina beta, I can still run any app (including category #1, unsigned) by Right-clicking and choosing “open”.

Does anyone know what really changes after Feb 3? Will you be able to still manually bypass the rules for unsigned apps by right-clicking?

As far as I know the right click/open will still work after 2/3

OK, it’s done: FB7527543 (I used the feedback website, as the app is only for Catalina).
My configuration isn’t officially supported (10.14 on a 2008 Mac Pro). Since Apple shows a dialog telling they collect various data (including devices), I just hope they won’t close the report because of “unsupported configuration”…

Thank you Arnaud, I’ll get this over asap. I really appreciate you taking the time out here to help.

You’re welcome. Glad there’s a way to progress on this issue.

In the meantime I’ve discussing the ramifications of ignoring this particular error. My contact will need to do some research into where in the process this error is actually reported so I can make a safe judgment call on how critical it is just ignore it.

I’ve also requested more information about what Apple does at their end, again to confirm if it a safe assumption to ignore this particular error.

In the meantime, I’ve modified App Wrapper, it will still report this error, but in the case of this particular error, it will complete the rest of the wrapping.

You can download the latest alpha from https://www.ohanaware.com/appwrapper/appWrapper3update311.dmg

AppWrapper 3.10 under Mojave - problem: I code-sign my app, then build a dmg with Disk Utility. I leave the default as “Compressed” and the dmg is created.

But when I come to notarise with AppWrapper, it rejects it as “not compressed, Apple only accepts compressed dmg’s”. What am I doing wrong?

I tried the 3.11 version mentioned above, same behaviour.