Proposal - Codesigning

[NewsArchive]

Codesigning is a pretty important issue, and SB is a gem to make it.
But, iI have +100 dll's etc that has to be codesignet every time i make
an install.

Its pretty frequent, that one (or more) comes back with a Errorcode 0.

Caused as I understand it by my not allways 100% good internet
connection to the time stamp server.

What about trying a (configurable) number of times before giving up and
sending an error. First tries with a warning, and the last with an
error, which stops the process.

Best regards

Edvard Korsbæk

[NewsArchive]

That would be cool.

But if you don't always modify ALL of those DLLs, maybe you could just
make the code-sign "permanent"?

Jeff Slarve
www.jssoftware.com
www.twitter.com/jslarve
I'll search help files & Google for you.

Grammar troll's, are the worse.

[NewsArchive]

The problem is that in most cases, a failed code-signing process "damages"
the file. I always re-compile the original file to be on the super safe
side. I never use a file if the 1st code-signing process failed.

Friedrich

[NewsArchive]

That was really bad news.

I make setup's on allmost dayly basis, and I allways use 'Permanent' for
the code signing.
The setups are made on new compiled dll's (most of), where i Copy from
my \BIN folder (Clarion C9.1) to the place, where i make the code signing.

Its more common than not, that one or more fails.
I understand that the failure comes from the call to the time stamp server.

Possibility - Make the call, tjek that its valid, if not do it again and
first codesign when you have a valid timestamp?

Best regards
'
Edvard Korsbæk

[NewsArchive]

You never know when and if a failed code-signing process "damages" a file
(code-signing modifies the PE Header of your application files). It depends
on a lot of factors (Authenticate tool and version, AV product, etc.).
Microsoft Authenticode only tells you success or not. It does not tell you
what went wrong. When this happens I *always* do a fresh start to be on the
safe side. A retry is not an option at all.

I am code-signing 100+ times per day and I have added the Authenticode tool
to the exclusion list of my AV and Firewall.

If timestamping fails often then something on the machine randomly "blocks"
access to the timestamp server (the trusted timestamp servers themselves are
very powerful and reliable). Because Authenticode modifies existing
application files, in most cases it's caused by a false-positive AV action.

Friedrich

[NewsArchive]

Thanks - Then i know a bit more on the process.

I have not looked, but this pretty important issue, is it documented in
SB Help?

As I remember, its certainly not a part of Janes papers.

Best regards

Edvard Korsbæk

[NewsArchive]

Edvard,

No, it's not part of the SB documentation because Authenticode is a
Microsoft technology. It's not even part of the MS Authenticode
documentation and you will not get much information if you contact MS
support. No link, no knowledge base. It's only based on my own experiences
and observations.

My advise is to always re-compile a file if Authenticode failed on it (in
this case you see a changed file time/date stamp; you don't have your
original file anymore). Sometimes you have no other choice because the PE
Header is so badly broken after a failed code-signing process that a re-sign
is impossible. And sometimes a re-sign works 100% (at runtime).

If code-sign worked okay on your original file then you deploy a code-signed
version of your original file. If code-signing failed and you simply
re-sign then you do not deploy your original file.

Friedrich

[NewsArchive]

Friedrich,

My pont is, that this important knowledge shold be spread among theese,
who uses SB.

A way could be, to add a line in the error description:

'For your own safety, replace this file with a fresh one'

OK - Its a bit too blunt, i know!

'SB recommands to replace this file before another sign code is done'

Got my point?

You could of cause write:

'MS has made another idiotic, not supported or documented bug. Replace
this file with a fresh one, and pray to your selection of goods, that MS
not fails one time more...'

But I am not sure, that I will recommand that!

Edvard

[NewsArchive]

Hi Edvard,

Yes, I got your point. I'll add a note to the documentation. Microsoft
introduced Authenticode 19 years ago, so this is there since 1996 and there
are no plans to change this behavior. But if a binary file manipulation
program fails (Authenticode, resource manipulation, version stamping, EXE
protection, etc.) then it is always a good idea to replace the changed file
with a fresh copy.

Friedrich

[NewsArchive]

Friedrich,

If I may jump in<g>.

Would it be possible for SB to make a copy of the exe before it tries
to code sign it. Then if it fails, delete the failed copy and rename
the safety copy to the original name. If signing was OK, just delete
the safety copy?

At least in my case, I am compiling the programs on another computer
and then uploading them to the office computer where SB is installed.
If a failure occurs, then I have to recompile on my local computer,
upload and try again. Doable but would be nicer if ....<g>

Barton Whisler
Prosoft Inc.
Tampa, Florida

[NewsArchive]

Hi Barton,

>
> If I may jump in<g>.
>

<g> ;-)

Yes, this is done if the "Permanent" option is not enabled ;-) Then the SB
compiler does a code-sign on a temporary file.

But please note that quite a few (buggy <g>) AV tools do NOT like such
actions. Doing a temporary copy, then manipulations on an existing
application file and on top of this the replacement of the original with a
changed copy, that's too much for most of them <g>.

Friedrich

[NewsArchive]

BTW, and what I do to "automate" the failed code-sign scenario is that I use
the "#copy file(s)..." directive in my project to copy a fresh set of the
latest DLL and EXE files and after that I do the embed manifest and
code-sign actions. If it fails (manifest embedding or code-signing), I just
recompile and the SB script copies again a fresh set of DLLs/EXEs. No
manual step required. I always have "Permanent" enabled.

Friedrich

[NewsArchive]

I did not know this, thanks for the tip. I don't think I've ever had
*my* binaries fail code-signing. Just the installer (time stamp
failure) <g>. In that case, I just recompile and it goes through that time.

> Hi Edvard,
>
> Yes, I got your point. I'll add a note to the documentation. Microsoft
> introduced Authenticode 19 years ago, so this is there since 1996 and there
> are no plans to change this behavior. But if a binary file manipulation
> program fails (Authenticode, resource manipulation, version stamping, EXE
> protection, etc.) then it is always a good idea to replace the changed file
> with a fresh copy.
>
> Friedrich
>
>
>

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

For years I've always done a 2 step procedure.. first copy my exe's and
dlls to another folder.. then my install uses those files... so, if
there is an issue, I just re-copy.. no recompile needed for my programs.

Although, I can't remember getting an error signing my software..
usually the error happens when signing the install program.. and then
it's just a recompile of the installation.

Ray
VMT


On 8/6/2015 9:16 AM, Friedrich Linder wrote:
> But if a binary file manipulation
> program fails (Authenticode, resource manipulation, version stamping, EXE
> protection, etc.) then it is always a good idea to replace the changed file
> with a fresh copy.


--
Ray Rippey
VMT Software

[NewsArchive]

> For years I've always done a 2 step procedure.. first copy my exe's and
> dlls to another folder.. then my install uses those files... so, if
> there is an issue, I just re-copy.. no recompile needed for my programs.

+1

I use Arnor's Build Automator to do the same thing.

:-)

Charles


--
-------------------------------------------------------------------------------------------------------
Charles Edmonds

cjeByteMeSpammers@lansrad.com (remove the "ByteMeSpammers" to email me)
www.clarionproseries.com - ProScan, ProImage, ProPath and other Clarion
developer tools!
www.seal-soft.com - The xProduct Clarion templates - xWordCOM, xToolTip,
xDataBackup Manager and more!
www.ezchangelog.com - "Free ChangeLog software to manage your projects!"
www.setupcast.com - "A revolutionary new publishing system for software
developers - enhanced for SetupBuilder users!"
www.pagesnip.com - "Print and Save the Web, just the way you want it!"
www.ezround.com - "Round Corner HTML tables with matching Banners, Buttons
and Forms - Now with PNG support!
www.lansrad.com - "Intelligent Solutions for Universal Problems"
www.fotokiss.com - "World's Best Auction Photo Editor"
-------------------------------------------------------------------------------------------------------

[NewsArchive]

Hi!

Exactly the same way i do it.

If this process is not automatic (Have you heard about Build
Automator?) - it's very easy to forget something.

Now i have to add something to my BA's, to minimize the number of
codesignings (Untill now, i have just set SB to compile again if errors)

Best regards

Edvard

[NewsArchive]

Hi Ray,

> For years I've always done a 2 step procedure.. first copy my exe's
> and dlls to another folder.. then my install uses those files... so,
> if there is an issue, I just re-copy.. no recompile needed for my
> programs.
>
> Although, I can't remember getting an error signing my software..
> usually the error happens when signing the install program.. and then
> it's just a recompile of the installation.

Once in a blue moon I have got connection errors on the code signing.
But I use the same method, everything that I deploy get's copied into a
folder where the install is built from. Been doing that for the past 14
years and it has worked very well for me:)

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Hi Charles,

> I use Arnor's Build Automator to do the same thing. :-) Charles

Even if it wasn't my own tool, I don't know how I'd deal with this stuff
without BA! Probably .bat files like I did before, but heck, BA looks
much better than the dos window<g>

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Not a bad idea.

When I compile, the binaries are produced in a sub folder. This is
where SetupBuilder gets the files. No copy needed (my drive is messy
enough already! <g>). If my environment can't reliably code sign them
(Friedrich listed common causes of failures), then I would think the
copy step is warranted.

The only failures I get, and its rare, is adding the time stamp on the
installer.

On 8/6/2015 3:31 PM, Ray Rippey wrote:
> For years I've always done a 2 step procedure.. first copy my exe's and
> dlls to another folder.. then my install uses those files... so, if
> there is an issue, I just re-copy.. no recompile needed for my programs.
>
> Although, I can't remember getting an error signing my software..
> usually the error happens when signing the install program.. and then
> it's just a recompile of the installation.
>
> Ray
> VMT
>
>
> On 8/6/2015 9:16 AM, Friedrich Linder wrote:
>> But if a binary file manipulation
>> program fails (Authenticode, resource manipulation, version stamping, EXE
>> protection, etc.) then it is always a good idea to replace the changed
>> file
>> with a fresh copy.
>
>

--

Russ Eggen
RADFusion International, LLC

[NewsArchive]

Hi Russ,

> When I compile, the binaries are produced in a sub folder. This is
> where SetupBuilder gets the files. No copy needed (my drive is messy
> enough already! <g>).

What I do is I have separate development and production folders. Each
product has a separate folder in each of those root folders (C:\dev and
C:\Products) In the production folder I have a folder called "Latest"
where I build the folder structure and where the install scripts are,
i.e. pretty much everything related to the product build is in the
Latest folder. When I do a new build, I copy everything from that
folder to a "Version xxx.xxx.xxx.xxx) folder and then copy from the
development folder into the latest. This way I always have a complete
track of each build I do and each version folder contains all the files
so it's easy to do any kind of code/binary comparisons if ever needed.
Of course I use BA to handle all this, I just press a button;)

This works really well for me and I have been doing things this way for
many years - long before BA came around. It separates development from
production and I really like that as the production folders contain
_everything_ that went into that build. There are some very static
files that I keep in the production folder that are not pulled from
development every time, most notably images, C++ dlls which change
rarely, and some other files for RED updates in the old IDE that never
change.

Best regards,

--
Arnor Baldvinsson
Icetips Alta LLC

[NewsArchive]

Excellent idea - thanks!

Bart

Barton Whisler
Prosoft Inc.
Tampa, Florida

[NewsArchive]

+1
Edvard

[NewsArchive]

I use IQ-Sync by Robert Paresi to copy my files.. great program.
http://www.paresi.net/iqsync/

Ray

--
Ray Rippey
VMT Software