Codesign fails with Timestamp error

Question

Created Mar ’23

Replies 3

Boosts 0

Views 1.4k

Participants 2

I have been using the following commands for codesign, for two apps in my script:

sudo codesign -f --deep --options=runtime --strict -s $CODE_SIGN_CERTIFICATE $BUNDLE_DIR&#x2F;APP1.app --timestamp --verbose

sudo codesign --timestamp -f --deep --options=runtime --strict -s $CODE_SIGN_CERTIFICATE $OUTPUT_DIR&#x2F;APP2.app --verbose

APP1 gets signed, and staple and validate action for it says successful. However, APP2 fails every time with the error:

> A timestamp was expected but was not found

This was working fine until a few days ago but it fails every time since yesterday morning. I looked around and tried following things but nothing worked:

timestamp=none or removing timestamp flag altogether
timestamp=http://timestamp.apple.com/ts01 [and several other free timestamp urls]
removing strict flag.

I'm working on Ventura, and the apps were created with QT 5.9.0. Xcode version = 14.1. Requesting any kind of help at the earliest. Thanks in advance

Answered by DTS Engineer in 748360022

> do you think there is any other reason/s why this must be happening?

It’s hard to say without a lot more investigation. Normally I’d tell you to open a DTS tech support incident but, if you open one right now, I’ll just turn around and tell you to stop using --deep after which we can talk more, and I’ve already done that here (-:

> Has it got to do with the fact this is an older QT version (5.9.0)?

No idea.

Folks using Qt are regular customers at the DTS code signing help desk because Qt doesn’t follow the rules in Placing Content in a Bundle [1]. It’s possible that newer versions are better at this but I don’t track that technology closely.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] In their defence, that article is relatively recent, from Oct 2021, and our docs prior to that were less than stellar.

Boost

Answer 1

DTS Engineer OP

Apple

Mar ’23

Don’t sign with --deep. See --deep Considered Harmful for an explanation of why not, and the following posts for an explanation of how to correctly sign code for the Mac:

I suspect what’s going on here is that your third-party tooling is not following the rules in Placing Content in a Bundle, so --deep is not finding all the code to sign, so some of the code ends up missing a timestamp, and so you get this error. However, it’s hard to be sure without looking at the specifics of your app and there’s no point doing that until you’re off --deep.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

KBHere OP

Mar ’23

Thank you @eskimo for the prompt reply. I tried without the deep option but it failed right in the beginning saying:

> code object is not signed at all

However, when I reused --deep and attempted again the next day, the installer was created smoothly. As I have alluded to in the beginning, this is an intermittent issue. I will definitely follow the recommendations in your links in my future attempts but do you think there is any other reason/s why this must be happening? Has it got to do with the fact this is an older QT version (5.9.0)?

0

Answer 3

DTS Engineer OP

Apple

Mar ’23

Accepted Answer

> do you think there is any other reason/s why this must be happening?

It’s hard to say without a lot more investigation. Normally I’d tell you to open a DTS tech support incident but, if you open one right now, I’ll just turn around and tell you to stop using --deep after which we can talk more, and I’ve already done that here (-:

> Has it got to do with the fact this is an older QT version (5.9.0)?

No idea.

Folks using Qt are regular customers at the DTS code signing help desk because Qt doesn’t follow the rules in Placing Content in a Bundle [1]. It’s possible that newer versions are better at this but I don’t track that technology closely.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] In their defence, that article is relatively recent, from Oct 2021, and our docs prior to that were less than stellar.

0