Feature Request Code signing

[NewsArchive]

Hi Friedrich,

as we all know, code signing sometimes fails, because the timestamp
server does not answer. You try to compile again and everything is okay.

Is it possible, that you add the following behaviour:

If code signing fails, SB wait 10 seconds and repeat code signing. If it
fails three times, SB aborts build process.

Markus

[NewsArchive]

Markus,

> as we all know, code signing sometimes fails, because the timestamp server
> does not answer. You try to compile again and everything is okay.
>
> Is it possible, that you add the following behaviour:
>
> If code signing fails, SB wait 10 seconds and repeat code signing. If it
> fails three times, SB aborts build process.

The problem is that there is no way to find out (from the Authenticode
return codes) whether the code signing process failed because the timeserver
was not accessible. I think it would not be a problem to add an option
(global IDE settings) to wait for 10 seconds, then try again up to three
times. But this option will also be executed if the certificate expired or
the password is incorrect, etc.

Thank you for your suggestion.

Friedrich

[NewsArchive]

Thanks

Markus Zander

[NewsArchive]

Hi Friedrich,

> The problem is that there is no way to find out (from the Authenticode
> return codes) whether the code signing process failed because the timeserver
> was not accessible. I think it would not be a problem to add an option
> (global IDE settings) to wait for 10 seconds, then try again up to three
> times. But this option will also be executed if the certificate expired or
> the password is incorrect, etc.

Could you ping the server that is specified in the #code sign function
_before_ you execute the code signing?

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com - www.altawebworks.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> Could you ping the server that is specified in the #code sign function
> _before_ you execute the code signing?

The problem is that there is more going on behind-the-scenes of a "timestamp
server". Even if the timestamp server cannot timestamp your application,
it's always accessible (e.g. a "temporarily down" message comes up, etc.).
I have never ever seen a Verisign or Comodo timestamp server that is really
"down". Even if timestamp does not work, ping would return "OK".

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

As long as folks are offering suggestions, let me try <g>:

Is there some way to measure the CRC of an unsigned EXE, do the time
stamping/code sign and check to see if the CRC changed? If not, a warning
might suffice or a 2nd attempt.

--
Russell B. Eggen
www.radfusion.com
Clarion developers: www.radfusion.com/devs.htm

[NewsArchive]

> As long as folks are offering suggestions, let me try <g>:
>
> Is there some way to measure the CRC of an unsigned EXE, do the time
> stamping/code sign and check to see if the CRC changed? If not, a warning
> might suffice or a 2nd attempt.

If the timestamp server is not "accessible" (e.g. they are doing
maintenance, timestamp server crashed, etc.) then the .exe or .dll or
whatever is not touched at all ;-) and the CRC does not change. If the
timestamp server is not accessible, the Microsoft code-signing tool
returns -1. Well, it always returns -1 if there was a failure <g>

Similar to a Microsoft server address, a Comodo and/or Verisign timeserver
will always be "pingable". They are never completely down.

Friedrich

[NewsArchive]

Friedrich,

> If the timestamp server is not "accessible" (e.g. they are doing
> maintenance, timestamp server crashed, etc.) then the .exe or .dll or
> whatever is not touched at all ;-) and the CRC does not change.

I think Russ was banking on this. In other words if there is NO change
in the CRC the signing failed, try again.

--
Lee White

Enroll Today at http://CWaddons.com

Reports....: http://www.cwaddons.com/products/rpm/
Free Review: http://www.clarionmag.com/cmag/v11/v11n06rpm.html
Faxing.....: http://www.cwaddons.com/products/afe/

[NewsArchive]

Right - a warning condition for a non-changing CRC and -1 return code, try
again or warn us that time stamping might not have worked, please try again.

I don't see SB doing anything beyond this due to the lack of data from tools
outside his control.

--
Russell B. Eggen
www.radfusion.com
Clarion developers: www.radfusion.com/devs.htm

[NewsArchive]

Something like this might help:

WARNING: Time stamping might not have succeeded due to a short lived
communication outage with the time stamp server. Re-compiling is
recommended.

That is when the CRC does not change as expected and a -1 return code
exists.
--
Russell B. Eggen
www.radfusion.com
Clarion developers: www.radfusion.com/devs.htm

[NewsArchive]

Russ,

> Something like this might help:
>
> WARNING: Time stamping might not have succeeded due to a short lived
> communication outage with the time stamp server. Re-compiling is
> recommended.
>
> That is when the CRC does not change as expected and a -1 return code
> exists.

But what happens if, say, the code-signing certificate expired? Or the
password for the certificate was incorrect? Or the exe header of the
"to-be-signed" application was damaged and code-signing is not possible
without an application recompile. In this case, CRC does not change and
return code is -1. The "...Time stamping might not have succeeded..."
message would appear ;-) But it's NOT the cause of the problem. The user
would check, recheck and check again his Internet connection, then change
the timestamp server (which gives the same error) and then fires a nice
support email to us because he is 100% sure that his Internet connection is
fine and the timestamp server also works.

Do you see what I mean (or am I completely wrong and need vacation or more
coffee <g>).

Friedrich

[NewsArchive]

Hi Friedrich,

> If the timestamp server is not "accessible" (e.g. they are doing
> maintenance, timestamp server crashed, etc.) then the .exe or .dll or
> whatever is not touched at all ;-) and the CRC does not change. If the
> timestamp server is not accessible, the Microsoft code-signing tool
> returns -1. Well, it always returns -1 if there was a failure <g>

Does the compile abort if there is a code signing error? I don't remember
and I don't want to risk triggering one<bg>

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com - www.altawebworks.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

> Does the compile abort if there is a code signing error? I don't remember
> and I don't want to risk triggering one<bg>

<BG>

Yes, this is a "fatal error" and the compilation process is aborted
immediately.

Friedrich

[NewsArchive]

Hi Friedrich,

> I have never ever seen a Verisign or Comodo timestamp server that is really
> "down". Even if timestamp does not work, ping would return "OK".

Yeah I figured as much, just an idea:)

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com - www.altawebworks.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Good point. Hey! At least I tried <g>

Seriously, with just a generic failure code that could point to all sorts of
reasons for failure, I don't know how you could narrow it any further. Best
course of action is to make sure that all the most common reasons are easily
found in the help.

BTW - I'm DCC'ing you a fresh cup of coffee, because it can only help! <g>

--
Russell B. Eggen
www.radfusion.com
Clarion developers: www.radfusion.com/devs.htm

[NewsArchive]

Hi Friedrich,

> Yes, this is a "fatal error" and the compilation process is aborted
> immediately.

That's what I thought. Hmm...<g>

Best regards,

--
Arnór Baldvinsson - Icetips Alta LLC
Port Angeles, Washington
www.icetips.com - www.buildautomator.com - www.altawebworks.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Friedrich,

some news about this?

Markus

[NewsArchive]

Hi Markus,

>
> some news about this?
>

No. It is not possible to find our why a code-signing process failed. The
MS Authenticode command line tool does not return this kind of information,
sorry.

Friedrich

[NewsArchive]

Final-Builder has a solution for that and SB forced me to sign our files
with finalbuilder instead of setupbuilder: They splitted signing and
time-stamping in two seperate actions and add the possibility to repeat
the time stamping action. For me, this is a solution, but as you can
see, this is a problem for other people too, which perhaps do not use
final builder.See attached screen shot.

Markus

[NewsArchive]

Hi Markus,

> Final-Builder has a solution for that and SB forced me to sign our files
> with finalbuilder instead of setupbuilder: They splitted signing and
> time-stamping in two seperate actions and add the possibility to repeat
> the time stamping action. For me, this is a solution, but as you can
> see, this is a problem for other people too, which perhaps do not use
> final builder.See attached screen shot.

The question is, why do you have a general "timestamp server" problem?

I believe that we code-sign and timestamp more than 15,000 files per month
without any problem. It only fails if the timestamp server is down (very
rarely) or one of the anti-spyware definition updates decided that it should
block access to Comodo.

BTW, the Microsoft Authenticode tool does the code-signing, not
SetupBuilder. I checked our records and there are nearly zero support
requests for code-signing problems.

Friedrich

[NewsArchive]

Because we are "am A.... der Welt" if you understand, what I mean.

Markus Zander

[NewsArchive]

>
> Because we are "am A.... der Welt" if you understand, what I mean.
>

Yes, I understand :)

I had a similar problem last Sunday. I had to code-sign files via a
HSDPA/UMTS connection and the code-signing process failed 50/50 (both
VeriSign and Comodo).

Of course, manually code-signing via signtool.exe and signcode.exe also
failed. So the Internet connection is an important factor here.

Friedrich