Veracrypt project update

Original Article ↗ Hacker News Discussion ↗

Microsoft’s termination of VeraCrypt’s long‑standing Windows driver signing account has halted new signed releases of the popular open‑source disk encryption tool, raising alarms about the fragility of independent developers’ access to closed platforms. Commenters link this incident to similar problems faced by other projects like WireGuard and LibreOffice, arguing that opaque automated enforcement, centralized code‑signing, and app‑store style controls make Windows increasingly hostile and risky for both developers and users. Many advocate moving to Linux and other open systems, or regulating dominant vendors as utilities, while noting that Microsoft staff have since indicated the VeraCrypt issue may stem from account‑verification paperwork rather than an intentional ban.

Microsoft driver-signing account suspension

  • VeraCrypt’s Windows driver-signing account was terminated, blocking new signed Windows releases (especially kernel drivers and bootloader).
  • Similar issues reported by other major open‑source projects (e.g., VPN software, office suite), sometimes with 60‑day “appeal” windows and no human contact.
  • Later, a Microsoft executive publicly framed this as missed/failed identity verification and promised to get affected projects unblocked, calling it “paperwork” rather than conspiracy.
    • Many commenters see this as still unacceptable: opaque, fragile, and dangerous for critical security software.

Impact on users and maintainers

  • Existing signed releases continue to install; signatures aren’t retroactively invalidated, but they won’t receive security updates.
  • For unsigned/new drivers, users must disable driver signature enforcement / Secure Boot, which now triggers intrusive “Test Mode” watermarks.
  • Devs depending on Microsoft’s ecosystem (Store, driver signing, GitHub) feel they operate under constant risk of arbitrary lockout.

Critique of centralized signing and app‑store control

  • Strong concern that OS vendors and a shrinking set of CAs function as de‑facto gatekeepers for software distribution, especially for kernel‑level code.
  • Many argue the current code‑signing model mainly burdens honest developers and users while attackers obtain leaked or abused certificates anyway.
  • Several note that automated abuse/scam detection plus no‑appeal policies have become a systemic problem across big platforms.

Alternatives, workarounds, and developer experience

  • Suggestions:
    • Avoid Microsoft Store; use independent code‑signing certs and distribute installers directly.
    • Obtain HSM‑backed individual code‑signing certs from non‑Microsoft CAs; experiences vary from “annoying but doable” to “effectively iced out.”
    • Move users off Windows entirely; run Windows in a VM on Linux if necessary.
  • Some point to technical hacks (e.g., loading via older vulnerable signed drivers), but these are seen as undesirable.

Security, trust, and regulation debates

  • Split between “incompetence and bad processes” vs “intentional pressure on strong encryption and VPN tools,” with several raising state‑influence concerns.
  • Many call for regulation treating major platforms and app stores like utilities with due‑process requirements and human appeal paths.
  • Others argue deeper fixes require open OSes (Linux/BSD), better sandboxing/VM isolation models, and possibly decentralized / web‑of‑trust style signing.