Why Microsoft signing?

#1

What do you mean by MSFT signed? Is the upcoming USB driver will pass WHQL certification and properly signed by Microsoft? (I don’t think that is necessary though since Secure Boot is not a thing on Raspberry Pi, at least for now)

1 Like
Will the USB driver possibly work on Windows10 s or s mode?
#2

So we will have to wait for Microsoft to sign them? Will we not get it as soon as it finished?

#3

What do you mean by MSFT signed?

Recently, Microsoft requires that all kernel-mode drivers be signed by their servers (rather than MCCI doing the signing ourselves with an authenticode cert). This is true for all the 64-bit operating systems. The process is automatic, just involves uploading for signing and downloading the results. Has nothing to do with secure boot.

So we will have to wait for Microsoft to sign them? Will we not get it as soon as it finished?

This is an automatic process and adds no appreciable delay. I was just outlining all the steps that have to be taken. MCCI does commercial Windows drivers for OEM customers as a big part of our business, so the process is fairly ponderous. I thought it would help to explain so people understand why things take a little time.

1 Like
#4

If I remembered correctly, this requirement is only for Secure Boot, if Secure Boot is not active, corporate sign is still perfectly adaquate.

Correct me if there is another policy update though.

But of course, if MCCI is already in the process of doing stuff, go for it. It is always great to get drivers signed :).

#5

Alas, we deliver drivers to people (for money, sometimes) – we find that the only thing that reliably works is the corporate signing thing. The problem with signing with Authenticode is that you run into bizarre SHA1/SHA256 variations. Signing at MSFT (or counter-signing, really, we still have to sign) seems to make life easier.