Microsoft recently made substantial changes to Get a Code Signing Certificate. A couple of things caught my eye. First, there is the statement that as of Windows 10 1809, drivers that were signed with SHA-1 certs issued prior to July 29, 2015 are no longer supported. I’m not sure in what circumstances this is true (strictly Secure Boot or not), but it caught me by surprise. Has it been announced or discussed anywhere else?
Second, the policy has changed from “you need only sign the CAB file” to “you must sign all the binaries in the submitted CAB file.” No big deal (we do that anyway), but I’m trying to come up with a rationale for that change. Any ideas?
This means drivers signed a long time ago are not valid on 1809? That would
certainly break a lot of legacy shit out there. Great policy combination:
forced upgrades and imposed legacy incompatibility. Do the people at msft
making these decisions actually communicate with each other?
Sometimes I get the feeling someone paid MS to destroy Windows since W10!
I do a fair amount of work in the scientific, embedded, and industrial control world. I can tell you that quite a lot of them have moved to Linux rather than trust Windows 10.
As a share of the market, the numbers are small, of course; as long as Microsoft owns all of the desktops at Boeing and Procter & Gamble, the rest really don’t matter very much.
Yup, the focus is almost entirely on corporate desktops and cloud
services. However there are also huge piles of legacy crap deployed all
over the world doing all sorts of stuff. Just keeping that stuff running is
a challenge.
Mark Roddy
What Microsoft has done over the past 10 years with driver signing is atrocious. They keep making signing more difficult and complex for developers and punish the end users more and more. Surely driver signing has generated more topics and confusion on developer forums than anything else by a wide margin; it is an obstacle that keeps getting in the way of developers trying to do their job adding cost and harming time to market. And I have never met an end user who has perceived value from a pop up dialog asking if you trust so-and-so. It’s just a dialog box that gets between the user and what they need to get done and they just look for that button to make it go away similar to all those “are you sure?” buttons all over the place. This latest gaff of cutting off perfectly good software from running in Windows 10 anymore is sure to create a great deal more disapproval. Compatibility was always a key point that drew the masses to favor Microsoft operating systems. Remember OS/2 and the penalty box? I guess they have forgotten. It’s been interesting to watch Microsoft slowly and deliberately drive the platform into the ground with this signing monstrosity they created and continue to exacerbate.
On Mar 11, 2019, at 5:31 PM, Rourke wrote: > > What Microsoft has done over the past 10 years with driver signing is atrocious.
Well, that’s not quite fair. I totally understand the driver signing requirements instituted in the Vista timeframe. There are justifiable legal liability and traceability aspects to that process that make total sense to me.
However, the new Windows 10 “Microsoft must sign” thing is not justifiable. I don’t see any advantages to either driver writers, consumers, or Microsoft. — Tim Roberts, timr@probo.com Providenza & Boekelheide, Inc.
> What Microsoft has done over the past 10 years with driver signing is
> atrocious.
Well, that’s not quite fair. I totally understand the driver signing
requirements instituted in the Vista timeframe. There are justifiable legal
liability and traceability aspects to that process that make total sense to
me.
However, the new Windows 10 “Microsoft must sign” thing is not justifiable.
I don’t see any advantages to either driver writers, consumers, or
Microsoft.
Mr. Rourke, I think, is a bit extreme in his criticism. Driver signing, as implemented for 64-bit platforms, has turned out to be quite a good thing overall. Even the hobby project problem worked itself out (sort of).
I agree with Mr Roberts that the whole Attestation Signing thing, which has brought with it the need for an EV cert, is a bit extreme. But, it’s not so bad, even. More annoying than evil.
The primary problems with signing have always been down to poor communication by Microsoft. To say that communication has been merely atrocious is understating how bad it’s been by a few factors of magnitude. This dates back to XP 64-bit edition, and how the responsible PM had to be pretty much bludgeoned into writing that “Code Signing Walkthrough” document. That’s another thing the community has Jean Valentine to thank for, by the way. Sigh. I miss Jean.
In fact, I’d argue that —in terms of the health of the driver development ecosystem overall — the one, primary, enduring, problem remains lack of communication. The tools are by and large excellent, the driver models work, the docs provide good descriptions of the parameters. But, even for us here at OSR, keeping abreast of tooling changes, evolving policies, new OS features and architectural changes is amazingly difficult. I understand the reason for some of this: The dev kits team doesn’t have their own architect on staff dedicated to working collaboratively with the OS folks on a daily basis, and tracking OS changes of interest to our Community. But the lack of communication about the rest, the mechanical stuff like how to sign a driver, is baffling to me. So much of this can be solved by some PM writing a blog post. I’m sure there’s a reason, but… I. Just. Don’t. Understand.
Signing doesn’t suck. Not knowing what signing policy your driver requires, or that a given system requires to load your driver? THAT sucks. Big time and a lot. Massive. Huge.
The issue is also that an EV + nonEV (SHA1) are required at this time
to support all OSes (since W7 x64 still does not have SHA2 patch, and
I doubt Visa x64 ever will).
That is money well spent elsewhere. If anyone thinks the process is
really checking identities, I’ll laugh so hard you’ll hear the forum
trembling
Hmmm… with all due respect, even if you choose to pay Symantec (the most expensive vendor) the cost involved for BOTH of these certs for a one year term is about US$1200.
It’s hard, even for me at a small company, to be too concerned about that level of cost. Its not lunch money, to be sure. But it’s less than the cost of ONE DAY of engineering time (fully burdened).
@Dejan_Maksimovic said:
They sure did. They decided this was a great leap forward to cut ties
with the past.
Have you actually seen it happen in practice? I just did a clean install of Windows 10 Pro x64 1809 with Secure Boot enabled. I then installed our full 2015 driver stack, all SHA-1 cross-signed with our certificate issued in 2013. Everything works perfectly. Did I do something wrong, or is this another in a long line of promised breakages that didn’t actually come to pass?
OSR is not a small company LOL
You are forgetting the time it takes to verify the company (maybe a 5
minute work in the US, but far from less than a 2 day work, literally,
over here).
Not to mention how little they really do verify (and the companies
that issue the certificates do no work themselves, again, at least
here, they rely on information available from third parties, and that
is it).
When I say here, I have ties to companies in 4 countries on 3
continents (not mine, but I have seen the process).
That is money well spent elsewhere, by definition even.
And… no, even in Germany/UK, an engineer’s day is not close to
$1200. I would not even have the will to talk about this otherwise
You might be talking a day of actual work, when talking about
freelancers or if there isn’t a full 170 hour work month, in which
case - maybe.
But on average? No.
Mind you, I am not actually complaining about the certification
process for drivers, as a cost (yes, it is organized quite badly, but
testing drivers with provided Kits is a good thing).
> That is money well spent elsewhere.
Hmmm… with all due respect, even if you choose to pay Symantec (the most
expensive vendor) the cost involved for BOTH of these certs for a one year
term is about US$1200.
It’s hard, even for me at a small company, to be too concerned about that
level of cost. Its not lunch money, to be sure. But it’s less than the
cost of ONE DAY of engineering time (fully burdened).
However, I will remind you I said “fully burdened” which means you have to count all employer costs (all taxes, social security, health care, insurance, plus occupancy, utilities, indirect supervision, etc). And I grant you the figure I used was probably more for a principal engineer type, not some newbie JScript graduate hire.
OK…topic, that I should never have started in the first place, closed. At least in regards to what a day of an engineer’s time costs. No further discussion on this here please. From anyone, thank you.
Sorry about that, not my intention.
But my general thought on such comparisons (when one mentions that the price of something is too small to reconsider, talking about the cert prices here) is always: “OK, you pay for it then”
I am however aware of how much it has helped reduce so many malicious drivers, and traced faulty legit ones.
Thanks, I’ve been missing you too. It has to do with a lack of inspiration for future kernel development which was taken away by ridiculous and unexpected policies such as this one.
//Daniel
