Veracrypt project update

Original Article ↗ Hacker News Discussion ↗

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.