Main navigation

Have you had Gatekeeper problems with my apps?

A few people have complained that when they download my free apps from here and try to run them, they are informed that there is a problem with their signatures, and Gatekeeper won’t allow them to be run. This is in spite of my signing them, and testing myself that they pass Gatekeeper’s full checks.

(You can of course bypass this by using Finder’s Open command when you need to.)

I think that I may have got to the bottom of this problem. To help me fix this, I’d be grateful if you could download, decompress, and try running any of the following three freshly signed apps. These are the latest versions which should run sweetly on both Sierra and High Sierra:

LockRattler, for checking the version numbers of security data files, and other key information: lockrattler35a

The Time Machine Mechanic (T2M2), for checking that Time Machine is making automatic backups correctly: t2m211bp

Please comment to let me know whether you experience Gatekeeper’s cold shoulder, or whether the new signature fixes this problem. If it does, I will do the same with all my other apps as soon as I can.

Thank you.

I am also looking at reported problems running LockRattler and KeychainCheck on El Capitan – I am not sure that is something that I can fix, it may be an issue with Xcode (still).

Hi, I don’t have issues opening apps.
But i have a comment about app links. I’m trying to create some autopkg recipes to ease the update of your apps in munki by autopkg.
With the links you post your apps, it’s very difficult to stay up-to-date and be able to choose between the release and tests versions.
It would be great if for a software you had a app name-latest.zip link and a appname-test.zip link. (example : keychaincheck-latest.zip instead of keychaincheck12.zip and keychaincheck-test.zip instead of keychaincheck13.zip)
Thanks in advance. (Please contact me if you want to discuss more about this)

Please link to the Downloads page.
Unfortunately, uploaded media including Zip archives are stored in a path which is determined according to when they are uploaded. If I upload a new version, I cannot overwrite the old one, or even store it in the same directory, AFAIK.
If you know of a way around this, please explain it to me!
Howard.

I’m linking to the download page, and i apply a regex to find the right download URL for an app.
I see you changed the page to have only one link for every app, so it makes things simpler. I have now the regex ([0-9]+/[0-9]+/keychaincheck(.+)\.zip). The issue is when you have a “current” release and a “beta” release.

The path is not an issue, it’s the zip file that is. Thing to think about next time you will have a beta, maybe add “-test” in the name of the archive file ? (for example when we had 2 versions of keychaincheck, you could have keychaincheck12.zip and keychaincheck13-test.zip. This way, if i want the beta, i can just change my regex to add -test before .zip)

OK, thanks, that is not difficult for me to do. I must try to remember to do so!
It would be much easier if there was a permanent directory into which I could put the release versions. I will check to see if there is a better way, but will append -test in the way that you suggest.
Howard.

My AutoPkg recipes are done for those of your readers that use it. They are available at https://github.com/jpiel/jpiel-recipes for now. (i asked to include them in the main repo of autopkg, waiting for an answer)

I’ve put only tools that i use myself but i can create recipes for your other tools if some people are asking for it.