I searched the archives and found a few references to people -doing- so, but
not clear on -how- they were doing it. I have a driver project that I build
with DDKBUILD from within VS2010, and all works well. However, I?m not sure
how to add a post-build step so that I can run signtool.exe after a
successful build.
Can someone point me in the right direction? I?m not sure if it?s in the
sources, makefile.inc, passed through ddkbuild, etc?.
Thanks,
Davepl
It’s in the makefile.inc, like this .
KMDF_VERSION_MAJOR=1
KMDF_VERSION_MINOR=9
_LNG=$(LANGUAGE)
_PKG=Packages
_INX=.
WIN7=Win7_
VISTA=Vista_
STAMP=stampinf -f $@ -a $(_BUILDARCH) -k
$(KMDF_VERSION_MAJOR).$(KMDF_VERSION_MINOR) -d * -v *
$(OBJ_PATH)$(O)$(INF_NAME).inf: $(_INX)$(INF_NAME).inx
copy $(_INX)$(@B).inx $@
$(STAMP)
symstore add /f $(OBJ_PATH)$(O)* /s c:\symbols /t “Driver symbols” /v
“1.1.19”
! if “$(_NT_TARGET_VERSION)” == “0x600”
@echo Replaceing $(_NT_TARGET_VERSION) files for Vista
replace $(OBJ_PATH)$(O)*
$(OBJ_PATH)$(_PKG)$(VISTA)$(_BUILDARCH) /u
cd $(OBJ_PATH)$(_PKG)$(VISTA)$(_BUILDARCH)
! endif
! if “$(_NT_TARGET_VERSION)” == “0x601”
@echo Replaceing $(_NT_TARGET_VERSION) files for Win7
replace $(OBJ_PATH)$(O)*
$(OBJ_PATH)$(_PKG)$(WIN7)$(_BUILDARCH) /u
cd $(OBJ_PATH)$(_PKG)$(WIN7)$(_BUILDARCH)
! endif
@echo Signing the SYS file.
…\SignBat.cmd
Caution, the spaces between “! if”, while silly do seem to be needed, at
least I had problems getting it to work without them and finally said to
hell with it and left them.
Gary G. Little
H (952) 223-1349
C (952) 454-4629
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dave Plummer
Sent: Saturday, July 16, 2011 6:42 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Integrating SignTool with DDKBUILD
I searched the archives and found a few references to people -doing- so, but
not clear on -how- they were doing it. I have a driver project that I build
with DDKBUILD from within VS2010, and all works well. However, I’m not sure
how to add a post-build step so that I can run signtool.exe after a
successful build.
Can someone point me in the right direction? I’m not sure if it’s in the
sources, makefile.inc, passed through ddkbuild, etc…
Thanks,
Davepl
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
__________ Information from ESET Smart Security, version of virus signature
database 6297 (20110715) __________
The message was checked by ESET Smart Security.
>
I searched the archives and found a few references to people -doing-
so, but
not clear on -how- they were doing it. I have a driver project that I
build
with DDKBUILD from within VS2010, and all works well. However, I’m
not sure
how to add a post-build step so that I can run signtool.exe after a
successful
build.Can someone point me in the right direction? I’m not sure if it’s in
the
sources, makefile.inc, passed through ddkbuild, etc…
What is the collective wisdom on the list of automating the signing like
this? Unless you are just testsigning for during development, signing
automatically as part of the build means having the key on your build
machine…
Also, if you are like me and 10 or 11 hours ahead of UTC, then signing
(test signing) doesn’t work until 10 or 11 in the morning due to a bug,
so I don’t do it automatically, even testsigning.
James
> What is the collective wisdom on the list of automating the signing like this? Unless you are just testsigning for
during development, signing automatically as part of the build means having the key on your build
machine…
Doing this during testing helps not miss it when you ship the product 
And also not needing to enable test
signing on test machines, some of which are not set up VMs.
–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.
I notice some will argue to the last against anything done differently than what they do. Automatic release signing drivers as part of the build is good practice that many of us have known and performed for years and will continue to do so indefinitely. It’s also an efficient shortcut for those learning drivers that wish to skip over test signing completely and instead have build pop out a real driver each time. Anytime you simplify driver development, I think that’s a good thing.
> I notice some will argue to the last against anything done differently than what
they do.
Agree with James. Flies should be separated from cutlets.
(These who like flies and cutlets conviniently integrated, will be sooner or later enligtened by a friendly release manager
Regards,
–pa
+1
Throwing the key around is not really the best idea, in my opinion.
Mm
On Jul 16, 2011 10:50 PM, wrote:
>> I notice some will argue to the last against anything done differently
than what
> they do.
>
> Agree with James. Flies should be separated from cutlets.
> (These who like flies and cutlets conviniently integrated, will be sooner
or later enligtened by a friendly release manager
>
> Regards,
> --pa
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@gmail.com wrote:
I notice some will argue to the last against anything done differently than what they do.
Err … yes, but as far as I can see you’re the first and only one doing
that in this discussion.
Automatic release signing drivers as part of the build is good practice that many of us have known and performed for years and will continue to do so indefinitely. It’s also an efficient shortcut for those learning drivers that wish to skip over test signing completely and instead have build pop out a real driver each time. Anytime you simplify driver development, I think that’s a good thing.
But one that conflicts absolutely with Microsoft’s principles and best
practices for code signing, unless you go and get the USB key out of the
safe every time you build, and put it back afterwards (along with lots
of other hassles if I remember correctly, long time since I read the docs).
Aside from Microsoft’s extreme recommendations, that approach does
undermine some of the side-benefits of code signing. Having every buggy
interim development build of a driver release-signed means you can’t use
a simple “is it release-signed” to mean “is it a well-controlled version
whose exact history I know”.
On 17/07/2011 01:42, James Harper wrote:
Also, if you are like me and 10 or 11 hours ahead of UTC, then signing
(test signing) doesn’t work until 10 or 11 in the morning due to a
bug, so I don’t do it automatically, even testsigning.
Does the problem occur even if you don’t timestamp the signature?
–
Bruce Cran
>
On 17/07/2011 01:42, James Harper wrote:
> Also, if you are like me and 10 or 11 hours ahead of UTC, then
signing
> (test signing) doesn’t work until 10 or 11 in the morning due to a
> bug, so I don’t do it automatically, even testsigning.Does the problem occur even if you don’t timestamp the signature?
I first reported the problem here
http://www.osronline.com/showthread.cfm?link=151398 and there seems to
be some disagreement over whether the bug is in stampinf (which stamps
the inf file with the local date), or inf2cat (which compares the UTC
date with the date in the inf file).
So the bug actually occurs before the signing is done, but if you don’t
use stampinf or inf2cat then you won’t have a problem.
James
It completely depends on what you judge the impact of (a) having a piece of software signed with your release key “in the wild” and (b) having multiple employees with access to your release key.
Let’s say you ship commercial products that are signed with your key. You fire a dev who a week later out of spite decides to sign some malware using the copy of your company’s release signing key.
Microsoft revokes the cert.
Your real software at your real customers is impacted.
Ooooops.
It’s not one size fits all.
Peter
OSR
Well, frankly, for internal development use (in test-signing mode) I
sign the binaries in my private build procedure - but in an outer
script, not via the WDK build & its related makefiles.
Am not smart enough to ever remember what all these makefiles do,
so resort to stone-age .bat or .js files whenever possible.
And if MS breaks these makefiles in the next WDK release, I probably
won’t care.
Regards,
–pa
On 17-Jul-2011 05:56, Martin O’Brien wrote:
+1
Throwing the key around is not really the best idea, in my opinion.
Mm
On Jul 16, 2011 10:50 PM, > mailto:xxxxx> wrote:
> >> I notice some will argue to the last against anything done
> differently than what
> > they do.
> >
> > Agree with James. Flies should be separated from cutlets.
> > (These who like flies and cutlets conviniently integrated, will be
> sooner or later enligtened by a friendly release manager
> >
> > Regards,
> > --pa
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>
Um - I know exactly which of my drivers are official and which aren’t
based on the version strings I embed in the drivers, certainly not on
the quality of their signatures. One official build machine generates
official build versions, everyone else generates versions that
indicate they are development builds, and identify the system that
built them.
But to each his own.
Mark Roddy
On Sat, Jul 16, 2011 at 11:10 PM, J. J. Farrell wrote:
> xxxxx@gmail.com wrote:
>>
>> I notice some will argue to the last against anything done differently
>> than what they do.
>
> Err … yes, but as far as I can see you’re the first and only one doing
> that in this discussion.
>
>> Automatic release signing drivers as part of the build is good practice
>> that many of us have known and performed for years and will continue to do
>> so indefinitely. It’s also an efficient shortcut for those learning drivers
>> that wish to skip over test signing completely and instead have build pop
>> out a real driver each time. Anytime you simplify driver development, I
>> think that’s a good thing.
>
> But one that conflicts absolutely with Microsoft’s principles and best
> practices for code signing, unless you go and get the USB key out of the
> safe every time you build, and put it back afterwards (along with lots of
> other hassles if I remember correctly, long time since I read the docs).
>
> Aside from Microsoft’s extreme recommendations, that approach does undermine
> some of the side-benefits of code signing. Having every buggy interim
> development build of a driver release-signed means you can’t use a simple
> “is it release-signed” to mean “is it a well-controlled version whose exact
> history I know”.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
I do something similar with less control of the embedded versioning. One
official build machine builds only from the repository, does release
signing, and uses strictly controlled version numbers. Informal builds
can be done anywhere from any source and are neither release signed nor
have tightly controlled version numbers. In principle, everything which
goes outside the development lab is built on the official build machine.
This is a long way from Microsoft’s recommendations, but allows maximum
flexibility to developers and a simple “if it’s not release signed, it’s
very wrong” test. If anything release signed escapes to the wild, then
it’s at least reasonably close to what was expected to be released, and
we know exactly what it is.
Mark Roddy wrote:
Um - I know exactly which of my drivers are official and which aren’t
based on the version strings I embed in the drivers, certainly not on
the quality of their signatures. One official build machine generates
official build versions, everyone else generates versions that
indicate they are development builds, and identify the system that
built them.But to each his own.
Mark Roddy
On Sat, Jul 16, 2011 at 11:10 PM, J. J. Farrell wrote:
>> xxxxx@gmail.com wrote:
>>> I notice some will argue to the last against anything done differently
>>> than what they do.
>> Err … yes, but as far as I can see you’re the first and only one doing
>> that in this discussion.
>>
>>> Automatic release signing drivers as part of the build is good practice
>>> that many of us have known and performed for years and will continue to do
>>> so indefinitely. It’s also an efficient shortcut for those learning drivers
>>> that wish to skip over test signing completely and instead have build pop
>>> out a real driver each time. Anytime you simplify driver development, I
>>> think that’s a good thing.
>> But one that conflicts absolutely with Microsoft’s principles and best
>> practices for code signing, unless you go and get the USB key out of the
>> safe every time you build, and put it back afterwards (along with lots of
>> other hassles if I remember correctly, long time since I read the docs).
>>
>> Aside from Microsoft’s extreme recommendations, that approach does undermine
>> some of the side-benefits of code signing. Having every buggy interim
>> development build of a driver release-signed means you can’t use a simple
>> “is it release-signed” to mean “is it a well-controlled version whose exact
>> history I know”.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>Also, if you are like me and 10 or 11 hours ahead of UTC, then signing
(test signing) doesn’t work until 10 or 11 in the morning due to a bug,
This bug is in STAMPINF and I’ve worked it around by writing a .vbs script which will print the correct UTC date/time, allowing the use of STAMPINF in “the time is explicitly provided” mode.
To answer the OP: MAKEFILE.INC helps a lot, you can make a target there which will generate the BAT file on the fly and the second target which will invoke this BAT file, which will invoke STAMPINF and INF2CAT.
Signing with the build seems to be a bad thing to do (though one can add “signtool” there too), due to the requirement of having the private keys on the build machine.
But .CAT file generation seems to be a good idea.
Also: GNU “sed” is a good tool for such make scripts.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>be some disagreement over whether the bug is in stampinf (which stamps
the inf file with the local date), or inf2cat (which compares the UTC
Below is my .VBS file used to work it around. It is named "utcdate.vbs".
====
' Prints the "set STAMPINF_DATE=UTCDate" command, which is used to
' work around the StampInf/Inf2Cat incompatibility
Set oShell = CreateObject("WScript.Shell")
tzBias = oShell.RegRead("HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias")
tmNowUTC = DateAdd("n", tzBias, now())
' STAMPINF mandates the leading zeroes
strMonth = CStr(Month(tmNowUTC))
If Len(strMonth) < 2 Then strMonth = "0" + strMonth
strDay = CStr(Day(tmNowUTC))
If Len(strDay) < 2 Then strDay = "0" + strDay
WScript.Echo "set STAMPINF_DATE=" + strMonth + "/" + strDay + "/" + CStr(Year(tmNowUTC))
====
and now the cite from MAKEFILE.INC which invokes this (and also explains that STAMPINF without the STAMPINF_DATE env var uses local time, not UTC, and INF2CAT wants UTC one):
Note that I also embed the SVN revision version of the source to the INF file.
VERSION.INC is the manually edited file which contains the explicitly set build version (corresponding to the features implemented and tested). It is in the format of major.minor.build, like:
VER_DOTS=2.2.58.
VER_COMMAS=2,2,58,
the version in the INF will be major.minor.build.SVNRevision
====
!INCLUDE VERSION.INC
$(OBJ_PATH)$(O)\svnver.h.template:
svnversion ..\ | sed "-e s/([0-9]*):(.*)/\2/g" "-e s/([0-9]*)[MSP].*/\1/g" > $(OBJ_PATH)$(O)\svnver.h.template
$(OBJ_PATH)$(O)\makeinf.bat: $(OBJ_PATH)$(O)\svnver.h.template VERSION.INC
cscript /NoLogo utcdate.vbs > $(OBJ_PATH)$(O)\makeinf.bat
sed "-e s/.*/stampinf -f %1 -v $(VER_DOTS)&/g" $(OBJ_PATH)$(O)\svnver.h.template >> $(OBJ_PATH)$(O)\makeinf.bat
$(OBJ_PATH)$(O)\MyDriver.inf: MyDriver.inx $(OBJ_PATH)$(O)\makeinf.bat
echo Generating INF file...
copy MyDriver.inx $(OBJ_PATH)$(O)\MyDriver.inf
$(OBJ_PATH)$(O)\makeinf.bat $(OBJ_PATH)$(O)\MyDriver.inf
====
This does not include INF2CAT invocation, I can do that manually. Also, if the tree being built is not under SVN control, then one should just add "svnversion.bat" file to the source dir which will just @echo some sane version number.
Who will say BUILD is bad after the above? Can MSVC's build env do such things? 
--
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
If you want to sign things during the build, why not just use a test signing certificate (and test with test signing enabled)?
A self-signed test signing certificate isn’t particularly valuable and it won’t allow the driver to load on a customer machine in the default configuration. This gets you a driver that you can load on your test systems (provided you enable test signing on said machines) without the risks of placing your private key on every build machine.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, July 18, 2011 9:55 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Integrating SignTool with DDKBUILD
Also, if you are like me and 10 or 11 hours ahead of UTC, then signing
(test signing) doesn’t work until 10 or 11 in the morning due to a bug,
This bug is in STAMPINF and I’ve worked it around by writing a .vbs script which will print the correct UTC date/time, allowing the use of STAMPINF in “the time is explicitly provided” mode.
To answer the OP: MAKEFILE.INC helps a lot, you can make a target there which will generate the BAT file on the fly and the second target which will invoke this BAT file, which will invoke STAMPINF and INF2CAT.
Signing with the build seems to be a bad thing to do (though one can add “signtool” there too), due to the requirement of having the private keys on the build machine.
But .CAT file generation seems to be a good idea.
Also: GNU “sed” is a good tool for such make scripts.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> A self-signed test signing certificate…won’t allow the driver
to load on a customer machine in the default configuration.
Actually that is another reason not to use test certificates IMhO. And like others I use the driver version to know everything I need to about a driver. My goal has always been to make signing as insignificant as possible since all of our customers to date have found the signature meaningless anyway. For many developers, signing drivers is just a road block that you need to spend time and money clearing away quickly so you can get back to your job.
While I am cognisant that the issue of code signing is one of the most often
discussed on this forum, I fail to see what all the fuss is about. There
are legitimate advantages to code & package signing and well documented
procedures from Microsoft to accomplish the signing. It is true that it
does not do everything that the marketing propaganda claims, but even if
used for nothing more than an extended crc it is an effective and simple way
to prevent corrupt or trivially tampered images from loading. The strange
part that I see is that more devs don’t run a local CA that can issue
locally trusted certificates. This avoids the F8 or self-signed problems,
without exposing any public keys. And once the ‘gold code’ version is
ready, then break out the publically trusted certificate and use it as a
trivial replacement for the local key.
wrote in message news:xxxxx@ntdev…
A self-signed test signing certificate…won’t allow the driver
to load on a customer machine in the default configuration.
Actually that is another reason not to use test certificates IMhO. And like
others I use the driver version to know everything I need to about a driver.
My goal has always been to make signing as insignificant as possible since
all of our customers to date have found the signature meaningless anyway.
For many developers, signing drivers is just a road block that you need to
spend time and money clearing away quickly so you can get back to your job.