rotlegal.blogg.se

1. #SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD DRIVERS#
2. #SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD DRIVER#
3. #SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD WINDOWS 10#
4. #SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD CODE#

It also requires that secure boot should be disabled. For x86 I'm fairly sure it also requires that the user can take control of the platform key and therefore evict Microsoft keys from the firmware. The other side of the coin is the windows logo program, that requires secure boot be turned on by default. I understand why fedora/redhat preferred not to be in a privileged position but I can't help but feel someone ought to have stepped up. That's from Matthew Garrett, who along with Peter Jones, were responsible for the first shim.Ī central authority like the Linux foundation could have stepped up here and could have since, actually. Firstly there's the hardware vendors who make firmware, who decided to incorporate UEFI presumably because intel pushed it hard (original efi booted itanium and is also found in older Macs).īut it was certainly possible for a Linux vendor to have got a key into the kek and dB lists: This is because most CAs won't issue EV certificates to individuals, even if those individuals happen to have detailed knowledge of cryptography and all the pkcs.

#SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD CODE#

I mostly believe this is an attempt to reduce the number of code signing cert leaks that result in people writing malware, and lock down the Windows kernel a bit more, but still. And now hobbyist projects like this run the risk of being rejected by MS. that entails effort and expense for a hobby project. On the other hand, the push to EV certs rules out individual developers like myself.

So on the one hand, they're being quite friendly to open source. Microsoft have their keys in the default keychain because they bothered to be involved in the process, unlike linux companies like Redhat. On the one hand, Microsoft have repeatedly signed the shim maintained by redhat in order to allow Linux distributions to boot directly on secure boot-enabled hardware (UEFI binaries also go through this process and always have). You still require an EV certificate as well, to sign the package.

#SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD DRIVERS#

Microsoft have decided that this mechanism will now be retired, and all drivers must be signed via sysdev from now on. You can't realistically ask users to disable secure boot, even if this is entirely possible on all x86 motherboards.įinally, the cross signed roots expire soon and I think some already have.

#SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD DRIVER#

Thus the only mechanism to realistically get your driver working on all Windows out of the box is to submit via sysdev. IF secure boot were enabled, the kernel would: a) if the driver was signed pre-Win10, accept it, b) if it was signed post win-10 RTM date and by Microsoft, accept otherwise reject. It was technically possible to use the old mechanism at this stage too, provided the end user did not have UEFI secure boot enabled. You would then be required to submit the driver package via and after spending time in Ballmer's Brewery, it would come out signed by Microsoft.

#SYSINTERNALS SUITE NO CHARGE FROM MICROSOFT WORD WINDOWS 10#

Then, around Windows 10 I think, Microsoft announced that one would need to acquire an EV certificate. It was not sufficient to have a certificate capable of signing code, even with MS' OIDs for that. This means that the certificate follows a chain up to a standard CA _and also_ one Microsoft use to approve that CA to issue kernel-mode certificates. Originally for kernel-mode drivers, you needed a code signing certificate cross signed by Microsoft's root. Since Sysinternals were bought by Microsoft many years ago and the tools are distributed directly via Microsoft, such tools are unlikely to have an issue being signed.Ī brief history of the process for those not following it.