Repository navigation
Replies: 3 comments
|
I feel that the most concrete threat against projects like this at the moment is the whole way Microsoft is handling driver signing requirements and issues they leave developers with regarding it and the almost non-existing support options available for solving issues. In the long term, projects like Dokan could suddenly be without important updates and bugfixes for months, maybe years without any way of predicting when and where that will happen. Uncertainty like this over driver signing requirements, who is allowed to sign and when and where is really bad also for projects using Dokan and similar open-source projects. For example, recently, I myself and probably hundreds of other driver developers got locked out of driver signing portal without any explanation and a very unclear and uncertain path to get access back to it. We simply do not know when and how we can sign drivers again. This shows that it is not getting an EV certificate or getting help from someone with an EV certificate that is the biggest problem now, it is what kind of organizations Microsoft accept signing drivers and for what purpose. So, I guess it is crucial for projects like Dokan to always have several alternative ways forward for driver signing to keep this risk as little as possible. |
|
This is a great topic! Thanks @onidio for bringing this up.
Yes! I actually did start the process to get Google support to get the funding to renew the certificate through Leosac. I will update here when I get some news.
Yes, the driver is already submitted through attestation signing. It has no issue running on April 2026 update. BUT since the last release, the Microsoft hardware portal might now require to attach a CodeQL report. I haven't tried it yet but I have planned to do that and make the required changes in the coming weeks.
There is none and I don't expect we would have issues if we follow the rules. VeraCrypt has to sign their EFI bootloader which is another process.
Years ago I was requesting the community for funding to get the certificate but when I joined the Google Drive team I preferred to avoid getting funding from possible competitors (legally questionable and complex). If we had to go through this, we would need another maintainer to handle this. |
|
Thanks for your update on this @Liryna. I have got access back to code signing for my company now and I am happy to provide a backup alternative should there be any issues in the future with code signing. |
Uh oh!
There was an error while loading. Please reload this page.
Hi Dokan team,
First of all, thank you for the incredible work you've been doing on this project for so many years. Maintaining a Windows kernel driver as an open source project is a massive undertaking, and the community really appreciates it.
I wanted to open a discussion about something that's been on my mind regarding the long-term sustainability of Dokan on Windows, specifically around driver signing.
Looking back, the project already went through a difficult period when the previous EV certificate expired, which led to more than a year without a new release until the new certificate could be acquired thanks to Google's contribution and Leosac's support. That certificate was obtained in 2023 and is valid for 3 years, so renewal should be coming up soon.
On top of that, Microsoft announced that starting with the April 2026 Windows update, the legacy cross-signed driver trust path is being phased out on Windows 11 (24H2, 25H2, 26H1) and Windows Server 2025. Going forward, drivers will need to be signed through the WHCP (Windows Hardware Compatibility Program) or be on an explicit Microsoft allow list to be trusted by default.
This raises a few questions I'd love to hear the maintainers' thoughts on:
I'm asking because Dokan is a critical dependency for many open source and commercial projects, and the signing infrastructure feels like a single point of failure that's worth discussing openly.
Thanks again for everything!
All reactions