Feature Request Code signing
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
Re: Feature Request Code signing
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
Re: Feature Request Code signing
Re: Feature Request Code signing
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
Re: Feature Request Code signing
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
Re: Feature Request Code signing
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
Re: Feature Request Code signing
> 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
Re: Feature Request Code signing
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/
Re: Feature Request Code signing
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
Re: Feature Request Code signing
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