codesigning, it's just a snack

Do not get intimidated by the expert memos and posts about how difficult the
process is, they are unbased. There is no need to read all the lengthy
documentation on the topic such as the ‘kernel mode code signing
walkthough’, instead you can take an ignorants approach and only take the
steps which are really necessary. You just need to know you need the
certicicate imported in the browser and you need a cross certificate (.cer
file). You can forget about test signing the driver with all the complicated
boot options, who needs that anyway ? You can forget about creating a cat
file or signing the inf file, what is that good for if you can just sign the
driver binary ? Am I missing something ? All you need to know is how to
issue the signtool command:

signtool.exe sign /v /ac crosscertificate.cer /s my /n certificatename /t
http://timestamp.verisign.com/scripts/timestamp.dll mydriver.sys

(wildcards also accepted)

Once you got a certificate (not so easy I admit) you can do the whole thing
in 15 minutes and save yourself months of worrying and procrastinating and
hours of reading and testing uninteresting unnecessary documentation. The
only caveat is that you need to know that the personal certificate store is
specified as ‘my’ at the command line.

I was delighted when I realized I had some devices lying around for which
the manufacturer only offered a Windows Xp x64 beta driver (one of which is
a M-Audio firewire sound card) and could get them to work on Vista by
issuing the signtool command.

My conclusion is that the many memos and messages from expert kernel
developers about how difficult the process is are unfounded. If they would
have complaint about how ridiculous it is in the first place that we need to
buy signatures to be able to distribute our drivers I would wholeheartedly
agree. If they would say that this measure is seriously depriving the
developercommunity of innovation, or that codesigning is a very weak
security measure, considering that everybody can go and buy a signature with
a forged passport and a prepaid creditcard, they would have a very good
point. But the codesigning process is easy, simple and straightforward, it’s
just a snack.

/Daniel

On Jun 11, 2007, at 4:40 PM, Daniel Terhell wrote:

You can forget about creating a cat file or signing the inf file,
what is that good for if you can just sign the driver binary ?

The device installer *only* looks at .cat files that are signed for
driver packages. If you don’t mind the blood-red, end-of-the-world
“Please oh please don’t install this evil software” box, then you’re
right, .cat signing doesn’t help.

If, on the other hand, you don’t want your users getting that evil
box, you need to sign the installation package in addition to the
binary/binaries.

http://kernelmustard.com/2007/03/22/some-notes-on-signing/

My conclusion is that the many memos and messages from expert
kernel developers about how difficult the process is are unfounded.

If you mean that it’s not hard to get an individual binary signed,
you’re right, it’s not (if you have a cert). If you mean that the
entire system, including the DMI stuff, is obvious and
straightforward, I disagree. There are overloaded concepts, sketchy
documentation, and general confusion everywhere.

That’s not to say that it’s impossible, certainly, but it’s a pain.

-sd

Daniel,

I personally don’t agree with you about “forgetting about test signing the
driver with all the complicated boot options”.

How are you planning to test your Vista x64 driver? Are you planning to sign
it with your official certificate for testing? I would sign a test driver
with my company official certificate.

Wrt the MS walkthrough document, it’s just a good starting point for people
that start with the driver signing requirements under vista. And that
document usually avoids the usual mails on the various driver dev mailing
lists asking questions like “what do i need to do to sign my driver?”. It’s
***far*** from being perfect (e.g. it doesn’t explain at all where to get
the certificate from), but it’s better than nothing. I sign drivers for
Vista x64, and now i dont usually use that document, I ust have a small memo
on my desk with the signtool.exe command lines I need to use, and that’s it.
But that document was useful.

Just my two cents
GV

----- Original Message -----
From: “Daniel Terhell”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, June 11, 2007 2:40 PM
Subject: [ntdev] codesigning, it’s just a snack

> Do not get intimidated by the expert memos and posts about how difficult
> the process is, they are unbased. There is no need to read all the lengthy
> documentation on the topic such as the ‘kernel mode code signing
> walkthough’, instead you can take an ignorants approach and only take the
> steps which are really necessary. You just need to know you need the
> certicicate imported in the browser and you need a cross certificate (.cer
> file). You can forget about test signing the driver with all the
> complicated boot options, who needs that anyway ? You can forget about
> creating a cat file or signing the inf file, what is that good for if you
> can just sign the driver binary ? Am I missing something ? All you need to
> know is how to issue the signtool command:
>
> signtool.exe sign /v /ac crosscertificate.cer /s my /n certificatename /t
> http://timestamp.verisign.com/scripts/timestamp.dll mydriver.sys
>
> (wildcards also accepted)
>
> Once you got a certificate (not so easy I admit) you can do the whole
> thing in 15 minutes and save yourself months of worrying and
> procrastinating and hours of reading and testing uninteresting unnecessary
> documentation. The only caveat is that you need to know that the personal
> certificate store is specified as ‘my’ at the command line.
>
> I was delighted when I realized I had some devices lying around for which
> the manufacturer only offered a Windows Xp x64 beta driver (one of which
> is a M-Audio firewire sound card) and could get them to work on Vista by
> issuing the signtool command.
>
> My conclusion is that the many memos and messages from expert kernel
> developers about how difficult the process is are unfounded. If they would
> have complaint about how ridiculous it is in the first place that we need
> to buy signatures to be able to distribute our drivers I would
> wholeheartedly agree. If they would say that this measure is seriously
> depriving the developercommunity of innovation, or that codesigning is a
> very weak security measure, considering that everybody can go and buy a
> signature with a forged passport and a prepaid creditcard, they would have
> a very good point. But the codesigning process is easy, simple and
> straightforward, it’s just a snack.
>
> /Daniel
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

“Gianluca Varenni” wrote in message
news:xxxxx@ntdev…
> Daniel,
>
> I personally don’t agree with you about “forgetting about test signing the
> driver with all the complicated boot options”.
>
> How are you planning to test your Vista x64 driver? Are you planning to
> sign it with your official certificate for testing? I would sign a test
> driver with my company official certificate.

Yes, in my batch file which copies the binary to the system32\drivers
directory that I need to excecute anyway I added a command for signing the
driver, this takes 6 seconds extra per binary. With an alias for the 4NT
command line processor it only takes a few characters to type. Why should I
need test signing at all, what could it possibly be good for and why would
one need a separate machine for code signing ?

/Daniel

Daniel Terhell wrote:

Do not get intimidated by the expert memos and posts about how
difficult the process is, they are unbased. There is no need to read
all the lengthy documentation on the topic such as the ‘kernel mode
code signing walkthough’, instead you can take an ignorants approach
and only take the steps which are really necessary. …

I agree almost entirely with everything you say here, except for this
sentence. You’re implying that there is a way to “guess” the right
recipe without using the document. I say “bunk”. The proper signtool
command requires 7 or 8 parameters, and I would never have guessed the
right set without the document, nor would I have recognized which names
are required and which are intended to be invented by me.

The walkthrough covers a lot of material other than this, so the key may
be figuring out what the keys are, but I don’t think it’s possible to do
this without a rather detailed guide.

All you need to know is how to issue the signtool command:

Yes, once you have gone through the one-time effort of installing the
certificate, and once someone tells you what parameters to use on
“signtool”.

Once you got a certificate (not so easy I admit) you can do the whole
thing in 15 minutes and save yourself months of worrying and
procrastinating and hours of reading and testing uninteresting
unnecessary documentation. The only caveat is that you need to know
that the personal certificate store is specified as ‘my’ at the
command line.

Yes, here I agree with you. I had allowed myself to be intimidated, but
it was easy.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

On Jun 11, 2007, at 5:17 PM, Daniel Terhell wrote:

Why should I need test signing at all, what could it possibly be
good for and why would one need a separate machine for code signing ?

The main problem is that you risk an officially signed test driver
making it into the wild. This may or may not matter to you.

-Steve

----- Original Message -----
From: “Daniel Terhell”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, June 11, 2007 3:17 PM
Subject: Re:[ntdev] codesigning, it’s just a snack

> “Gianluca Varenni” wrote in message
> news:xxxxx@ntdev…
>> Daniel,
>>
>> I personally don’t agree with you about “forgetting about test signing
>> the driver with all the complicated boot options”.
>>
>> How are you planning to test your Vista x64 driver? Are you planning to
>> sign it with your official certificate for testing? I would sign a test
>> driver with my company official certificate.
>

Oops, big typo in my msg (I should stop re-editing my emails).
It was supposed to be

I would never sign a test driver with my company official certificate.

In general, the official certificate is to “bless” a good binary, not a test
binary. Test signing doesn’t require a separate test-signing machine.

Have a nice day
GV

>
> Yes, in my batch file which copies the binary to the system32\drivers
> directory that I need to excecute anyway I added a command for signing the
> driver, this takes 6 seconds extra per binary. With an alias for the 4NT
> command line processor it only takes a few characters to type. Why should
> I need test signing at all, what could it possibly be good for and why
> would one need a separate machine for code signing ?
>
> /Daniel
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

“Gianluca Varenni” wrote in message
news:xxxxx@ntdev…
>
> Oops, big typo in my msg (I should stop re-editing my emails).
> It was supposed to be
>
> I would never sign a test driver with my company official certificate.
>
> In general, the official certificate is to “bless” a good binary, not a
> test binary. Test signing doesn’t require a separate test-signing machine.
>

What are you afraid for, some weird spyware targeted at kernel developers
which uploads unfinished binaries to the public ? Since this test signing
feature only ‘protects’ you on Vista x64 and code signing for me is some
necessary evil rather than a blessing I can safely say that I don’t care. I
did not choose it.

/Daniel

I don’t get what you’re complaining about Daniel.

Since they fixed the walk-through document (cited previously) a few months after LAST YEAR’s WinHEC, it’s both correct and easy to follow. AND you can actually sign drivers with it.

I DO agree: About 10 minutes is all it takes – Once you’ve done it.

Peter
OSR

My points were that it takes 10 minutes if you’ve never done it, and 6
seconds to do it again, that’s what you also said I hope, right ? The other
point that I’m making is that test signing is a complete waste of time and
good for nothing unless I am missing something that I yet need to hear
about. I am encouraging potential code signers to not get intimidated and
also give suggestions how they can prevent wasting their time.

Yet another point I was making is that is the many complainings from the
experts about how difficult is the process are baseless. And now you are
asking me what I am complaining about ? That’s funny.

/Daniel

wrote in message news:xxxxx@ntdev…
>I don’t get what you’re complaining about Daniel.
>
> Since they fixed the walk-through document (cited previously) a few months
> after LAST YEAR’s WinHEC, it’s both correct and easy to follow. AND you
> can actually sign drivers with it.
>
> I DO agree: About 10 minutes is all it takes – Once you’ve done it.
>
> Peter
> OSR
>
>

Daniel Terhell wrote:

Yet another point I was making is that is the many complainings from
the experts about how difficult is the process are baseless. And now
you are asking me what I am complaining about ? That’s funny.

Keep in mind a lot of that complaining was being done when there was a
broken version of signtool.exe on the loose… Shitty docs combined
with a broken tool
would fustrate anyone.

> My points were that it takes 10 minutes if you’ve never done it

10 minutes, ARGGGGGGGGGGGGGHHHHHHHHH!!! I went through that blasted 55 page walk through document, the 70 page code signing best practices document, the 20 page 64-bit driver signing document, enrolled in the WDK beta program, tracked down and installed the winqual submission tools–hand copying files into the wdk tree as required, went through the process of finding how to obtain a digital signature, tried getting ahold of as many of these companies I could to evaluate them only to discover their contact details and what exactly to buy are sketchy as there are many kinds of certificates and similar company names, was lectured by VeriSign that none of their certificates work for drivers and crossed my fingers and purchased anyway, obtained + notarized + faxed all the necessary official docs, shelled out the 500 buck annual fee for the privilege of something that used to be free, and eventually discovered the driver signing tools don’t even work with class filters. This is just wrong to create such a farcical process and force small companies to go through these hoops.

And all of this for what? So someone can see I made the driver? Big deal, my products already have the company name on them so this tells the customer absolutely NOTHING. It is a distraction that takes away from more important issues like code quality and time to market.

And people are worried about using their certificate on a test driver? You are making up a problem that does not exist! Up until the signing appendage, every driver in the world could (and still can) easily be distinguished by its version. Expecting joe user can connect the two and surmise “gee, this thing doesn’t have a certificate therefore I conclude it must be beta” is dreaming. There are more applicable ways already in existence to indicate beta such as the architected area of the version resource and an appropriate message to the user!

Look: I find driver signing annoying, too. But let’s not become insane:

ntdev stuff:

That’s just not technically correct. Signing the install kit (a) absolutely identifies you as the origin of the driver, (b) indicates that the driver, INF, etc have not been tampered with by a third party.

Maybe neither of these mean anything TO YOU. But they certainly mean something TO ME and our clients. Many settings in the INF are *positively critical* to the security or proper functioning of certain products. Consider device object protection, as just one example.

Do you REALLY not get this?

You create an INTERNAL test version of your driver. It’s got private symbols. It’s got all sorts of debugging crap. Maybe it only partially works. You sign this driver with a TEST SIGNING certificate… which is just a cert from makecert. As a result, if this buggy, debug-enabled, crap code accidentally finds its way into the wild, your customers cannot load it on 64-bit Vista (without themselves putting a weird, unknown, cert in their trusted root CA store). Further, the binary is clearly not signed by your company, and is therefore clearly not an authorized version.

Duh!

Peter
OSR

No I am not getting it. What are you afraid for, I already asked before.
Some weird spyware targeted at kernel developers which uploads signed driver
binaries to the public ? If I understand right, you think you need driver
signing to protect yourself accidentally releasing test versions into the
wild ? You are not in control of what you release yourself ? On any other OS
than Vista x64 your test signed or unsigned driver will load anyway on your
customers machine so where is the protection ? There is better ways of
letting your customer know it is not a release version, like specifying this
in the version resource.

/Daniel

wrote in message news:xxxxx@ntdev…
> Do you REALLY not get this?
>
> You create an INTERNAL test version of your driver. It’s got private
> symbols. It’s got all sorts of debugging crap. Maybe it only partially
> works. You sign this driver with a TEST SIGNING certificate… which is
> just a cert from makecert. As a result, if this buggy, debug-enabled,
> crap code accidentally finds its way into the wild, your customers cannot
> load it on 64-bit Vista (without themselves putting a weird, unknown, cert
> in their trusted root CA store). Further, the binary is clearly not
> signed by your company, and is therefore clearly not an authorized
> version.
>
> Duh!

Mistakes do happen. Ask whoever released he 5270 WDK. Another way of
looking at the protection issue is that if your buggy driver does hit
the street, it won’t be as easy to trace it back to you unambiguously,
especially with all the interesting things, speaking of 5270, that
private symbols can tell an RE. I don’t really think that is much of an
issue either, but why would you want to identically sign something that
isn’t ready for prime time accruing, I would agree, minimal risk, but
risk nonetheless that can be avoided by test signing which is, by any
standard, no more difficult? I don’t really see much difference between
arguing for never test signing and always marking a version resource as
released. Either way, there is basically no difference in cost, and one
way accrues more risk than the other. Also, I test signed my first
driver yesterday, knowing nothing about the process other than the link
Tim provided, in about ten minutes. I certainly couldn’t acquire an
actual certificate in that time period, and I frankly have exactly zero
interest in every knowing the first thing about what goes in to that
process; should I ever need to, this will be someone else’s job to whom
this stuff is important. No client wants to pay me by the hour to
research this subject.

mm

>> xxxxx@resplendence.com 2007-06-12 13:26 >>>
No I am not getting it. What are you afraid for, I already asked
before.
Some weird spyware targeted at kernel developers which uploads signed
driver
binaries to the public ? If I understand right, you think you need
driver
signing to protect yourself accidentally releasing test versions into
the
wild ? You are not in control of what you release yourself ? On any
other OS
than Vista x64 your test signed or unsigned driver will load anyway on
your
customers machine so where is the protection ? There is better ways of

letting your customer know it is not a release version, like specifying
this
in the version resource.

/Daniel

wrote in message news:xxxxx@ntdev…
> Do you REALLY not get this?
>
> You create an INTERNAL test version of your driver. It’s got private

> symbols. It’s got all sorts of debugging crap. Maybe it only
partially
> works. You sign this driver with a TEST SIGNING certificate… which
is
> just a cert from makecert. As a result, if this buggy,
debug-enabled,
> crap code accidentally finds its way into the wild, your customers
cannot
> load it on 64-bit Vista (without themselves putting a weird, unknown,
cert
> in their trusted root CA store). Further, the binary is clearly not

> signed by your company, and is therefore clearly not an authorized
> version.
>
> Duh!

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I left out and important part. In the part about “tracing back
unambigously,” I failed to add “with the impression that this was by
design.”

mm

>> xxxxx@evitechnology.com 2007-06-12 15:25 >>>
Mistakes do happen. Ask whoever released he 5270 WDK. Another way of
looking at the protection issue is that if your buggy driver does hit
the street, it won’t be as easy to trace it back to you unambiguously,
especially with all the interesting things, speaking of 5270, that
private symbols can tell an RE. I don’t really think that is much of
an
issue either, but why would you want to identically sign something
that
isn’t ready for prime time accruing, I would agree, minimal risk, but
risk nonetheless that can be avoided by test signing which is, by any
standard, no more difficult? I don’t really see much difference
between
arguing for never test signing and always marking a version resource
as
released. Either way, there is basically no difference in cost, and
one
way accrues more risk than the other. Also, I test signed my first
driver yesterday, knowing nothing about the process other than the
link
Tim provided, in about ten minutes. I certainly couldn’t acquire an
actual certificate in that time period, and I frankly have exactly
zero
interest in every knowing the first thing about what goes in to that
process; should I ever need to, this will be someone else’s job to
whom
this stuff is important. No client wants to pay me by the hour to
research this subject.

mm

>> xxxxx@resplendence.com 2007-06-12 13:26 >>>
No I am not getting it. What are you afraid for, I already asked
before.
Some weird spyware targeted at kernel developers which uploads signed
driver
binaries to the public ? If I understand right, you think you need
driver
signing to protect yourself accidentally releasing test versions into
the
wild ? You are not in control of what you release yourself ? On any
other OS
than Vista x64 your test signed or unsigned driver will load anyway on
your
customers machine so where is the protection ? There is better ways of

letting your customer know it is not a release version, like
specifying
this
in the version resource.

/Daniel

wrote in message news:xxxxx@ntdev…
> Do you REALLY not get this?
>
> You create an INTERNAL test version of your driver. It’s got
private

> symbols. It’s got all sorts of debugging crap. Maybe it only
partially
> works. You sign this driver with a TEST SIGNING certificate…
which
is
> just a cert from makecert. As a result, if this buggy,
debug-enabled,
> crap code accidentally finds its way into the wild, your customers
cannot
> load it on 64-bit Vista (without themselves putting a weird,
unknown,
cert
> in their trusted root CA store). Further, the binary is clearly not

> signed by your company, and is therefore clearly not an authorized
> version.
>
> Duh!

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Nope Peter, just like multi-processors and race conditions, Daniel really
does not get it.

–
The personal opinion of
Gary G. Little

wrote in message news:xxxxx@ntdev…
> Look: I find driver signing annoying, too. But let’s not become insane:
>
> ntdev stuff:
>
>

>
> That’s just not technically correct. Signing the install kit (a)
> absolutely identifies you as the origin of the driver, (b) indicates that
> the driver, INF, etc have not been tampered with by a third party.
>
> Maybe neither of these mean anything TO YOU. But they certainly mean
> something TO ME and our clients. Many settings in the INF are positively
> critical to the security or proper functioning of certain products.
> Consider device object protection, as just one example.
>
>

>
> Do you REALLY not get this?
>
> You create an INTERNAL test version of your driver. It’s got private
> symbols. It’s got all sorts of debugging crap. Maybe it only partially
> works. You sign this driver with a TEST SIGNING certificate… which is
> just a cert from makecert. As a result, if this buggy, debug-enabled,
> crap code accidentally finds its way into the wild, your customers cannot
> load it on 64-bit Vista (without themselves putting a weird, unknown, cert
> in their trusted root CA store). Further, the binary is clearly not
> signed by your company, and is therefore clearly not an authorized
> version.
>
> Duh!
>
> Peter
> OSR
>

At my prior company, tech support/QA, despite me telling them not to, would distribute intermediate builds to customers because the customer was yelling on the phone and wanted a fix right now. I can easily imagine a new hire doing the same by accident. Or maybe a coworker who doesn’t really understand kernel-level stuff does a “quick fix” while I’m on vacation and sends it out.

Again using my prior company as an example, this would lead to problems that I couldn’t reproduce in-house because it didn’t match with any released versions. Over time, I devised a sophisticated one-ahead auto-increment-on-build versioning scheme and user-mode utility for logging the versions of all installed components, but I imagine the test certificate would be a more straightforward option.

So you have checked builds, release builds, builds with the right code,
builds with the wrong code, test signed drivers, release signed drivers.
With every new variation factor the number of things that can go wrong with
your release binary increases exponentially. That the release does or does
not run on one particular version of an OS does not seem the most important.

The only two lines of the kernel mode walkthrough that I could not do
without was the example of how to issue the command line parameters to the
signtool command. Considering the many complaints about how difficult is the
signing process, I was assuming a lot of the pain would lie in the test
signing process. The difficult configuration of the boot parameters, the
tediousness of the process and the extra testing efforts involve do not
sound attractive to me. If code signing is really such a pain as many say it
is, it looks like a logical step to avoid to decrease the hassles involved.

BTW You do want to test your released signed driver as well on top of your
test signed driver, don’t you ? Release signing during the development
process also minimizes the risk that at the time of release you will face
unexpected surprises if it appears that the signing process does not work
out the way you expected and you suddenly fail to load your driver.

/Daniel

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Mistakes do happen. Ask whoever released he 5270 WDK. Another way of
> looking at the protection issue is that if your buggy driver does hit
> the street, it won’t be as easy to trace it back to you unambiguously,
> especially with all the interesting things, speaking of 5270, that
> private symbols can tell an RE. I don’t really think that is much of an
> issue either, but why would you want to identically sign something that
> isn’t ready for prime time accruing, I would agree, minimal risk, but
> risk nonetheless that can be avoided by test signing which is, by any
> standard, no more difficult? I don’t really see much difference between
> arguing for never test signing and always marking a version resource as
> released. Either way, there is basically no difference in cost, and one
> way accrues more risk than the other. Also, I test signed my first
> driver yesterday, knowing nothing about the process other than the link
> Tim provided, in about ten minutes. I certainly couldn’t acquire an
> actual certificate in that time period, and I frankly have exactly zero
> interest in every knowing the first thing about what goes in to that
> process; should I ever need to, this will be someone else’s job to whom
> this stuff is important. No client wants to pay me by the hour to
> research this subject.
>
> mm
>
>>>> xxxxx@resplendence.com 2007-06-12 13:26 >>>
> No I am not getting it. What are you afraid for, I already asked
> before.
> Some weird spyware targeted at kernel developers which uploads signed
> driver
> binaries to the public ? If I understand right, you think you need
> driver
> signing to protect yourself accidentally releasing test versions into
> the
> wild ? You are not in control of what you release yourself ? On any
> other OS
> than Vista x64 your test signed or unsigned driver will load anyway on
> your
> customers machine so where is the protection ? There is better ways of
>
> letting your customer know it is not a release version, like specifying
> this
> in the version resource.
>
> /Daniel
>
>
>
> wrote in message news:xxxxx@ntdev…
>> Do you REALLY not get this?
>>
>> You create an INTERNAL test version of your driver. It’s got private
>
>> symbols. It’s got all sorts of debugging crap. Maybe it only
> partially
>> works. You sign this driver with a TEST SIGNING certificate… which
> is
>> just a cert from makecert. As a result, if this buggy,
> debug-enabled,
>> crap code accidentally finds its way into the wild, your customers
> cannot
>> load it on 64-bit Vista (without themselves putting a weird, unknown,
> cert
>> in their trusted root CA store). Further, the binary is clearly not
>
>> signed by your company, and is therefore clearly not an authorized
>> version.
>>
>> Duh!
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

What do multiprocessors and race conditions have to do with code signing ?
What is your argument ?

/Daniel

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> Nope Peter, just like multi-processors and race conditions, Daniel really
> does not get it.
>
> –
> The personal opinion of
> Gary G. Little
>
>
> wrote in message news:xxxxx@ntdev…
>> Look: I find driver signing annoying, too. But let’s not become insane:
>>
>> ntdev stuff:
>>
>>

>>
>> That’s just not technically correct. Signing the install kit (a)
>> absolutely identifies you as the origin of the driver, (b) indicates that
>> the driver, INF, etc have not been tampered with by a third party.
>>
>> Maybe neither of these mean anything TO YOU. But they certainly mean
>> something TO ME and our clients. Many settings in the INF are
>> positively critical to the security or proper functioning of certain
>> products. Consider device object protection, as just one example.
>>
>>

>>
>> Do you REALLY not get this?
>>
>> You create an INTERNAL test version of your driver. It’s got private
>> symbols. It’s got all sorts of debugging crap. Maybe it only partially
>> works. You sign this driver with a TEST SIGNING certificate… which is
>> just a cert from makecert. As a result, if this buggy, debug-enabled,
>> crap code accidentally finds its way into the wild, your customers cannot
>> load it on 64-bit Vista (without themselves putting a weird, unknown,
>> cert in their trusted root CA store). Further, the binary is clearly not
>> signed by your company, and is therefore clearly not an authorized
>> version.
>>
>> Duh!
>>
>> Peter
>> OSR
>>
>
>
>