Microsoft no longer signs Windows drivers for Process Hacker

Post by dvhh » Mon, Oct 25, 2021, 2:18 AM UTC

Oddskar wrote: post #58

Gargyle wrote: post #8

Earlier quoted context omitted.

Where did they actually do nice things? VSCode is still not entirely open source and the official builds have spyware included.

It's honestly weird to see "Telemetry" labeled as "Spyware" by a technical people that, quite frankly, should know better. Spyware is NOT the same as gathering Telemetry data. You can also just turn off Telemetry in VSCode in the settings. I think a vast majority of people on HN gather data on customer usage of the products that they build. Because it ultimately makes us able to tailor the products better for our cus…

Post by easygenes » Mon, Oct 25, 2021, 2:27 AM UTC

zahllos wrote: post #23

The article mentions Process Explorer. 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. A brief history of the process for those not following it. Originally for kernel-mode drivers, you needed a code signing certificate cross signed by Microsoft's root . This means that the certificate follows a cha…

Post by ddingus » Mon, Oct 25, 2021, 2:36 AM UTC

rossy wrote: post #466

ddingus wrote: post #369

Earlier quoted context omitted.

Exactly right. The move to ARM will highlight the hardware freedom in a big way. People are used to ARM being different and are that much more likely to forget open, general purpose computing right along with that "old" x86... Heh, I always disliked x86. But now? I look at it fondly. Strange times. Edit: It is the IBM PC lineage I speak of here, not just the ISA.

No, I don't think it will. I hate this trend of pretending that our relative freedom on PCs has anything to do with the platform. Our freedom on UEFI Secure Boot PCs was hard fought and could be taken away at Microsoft's whim*. They literally hold the keys. Remember the drama about whether Linux would be allowed to run under Secure Boot at all? That was last decade's reminder about hardware freedom and it had nothing…

Post by ddingus » Mon, Oct 25, 2021, 2:50 AM UTC

rossy wrote: post #476

ddingus wrote: post #475

Earlier quoted context omitted.

Also, I am curious about your findings Re: ARS Article, which I need to read. Frankly, I am learning how to build more things. Probably will need to.

To be honest I don't know if it came to pass or not. I'm still trying to find more info on what the current Windows logo requirements for Secure Boot on x86 actually are.

Post by ryanlol » Mon, Oct 25, 2021, 3:04 AM UTC

cma wrote: post #469

ryanlol wrote: post #342

Earlier quoted context omitted.

This is a terribly dishonest take. There was no “unrelated iOS business dispute”, Epic was simply using their keys to sign software that they had agreed not to sign. Epic made it clear that they can not be trusted with signing keys, you can’t claim that this is unrelated. Epic could have sued Apple and proceeded with their business dispute without abusing their signing keys, but instead they made a calculated decisio…

> Epic was simply using their keys to sign software that they had agreed not to sign. Epic never abused their desktop signing keys, which are stated to be for security only, what are you talking about? Apple did more than that too, they also briefly pulled their Apple logins, which they had surprise mandated on everyone who allowed third party logins. They went full mask off.