V OpenVet
cargo / windows-sys / audit
cargo : windows-sys @ 0.61.2
PE Patrick Elsen signed 2026-05-28 published 2026-05-28

Claims

has-binarieshas-build-exechas-fuzz-testshas-install-exechas-integration-testshas-property-testshas-unit-testsimpl-algorithmimpl-concurrencyimpl-cryptoimpl-datastructureimpl-interpreterimpl-jitimpl-parserimpl-protocolis-benignuses-concurrencyuses-cryptouses-environmentuses-execuses-filesystemuses-interpreteruses-jituses-networkuses-unsafe

Summary

windows-sys 0.61.2 is Microsoft's raw FFI binding crate for the Windows API, consisting almost entirely of machine-generated extern "system" declarations and constants. No findings were raised; unsafe sub-claims were left unasserted due to 8,925 generated unsafe items (scoped audit).

Report

Subject

windows-sys 0.61.2 is Microsoft's official raw FFI binding crate for the Windows API and WDK, published as part of the microsoft/windows-rs workspace. It exposes ~12,500 Windows functions as extern "system" declarations, thousands of Win32/NTSTATUS/HRESULT constants, and #[repr(C)] structs and unions matching Windows SDK and WDK layouts. Almost all content is machine-generated by the windows-bindgen tool from Windows SDK metadata. The crate declares a no_std library; consumers call the declared functions in their own unsafe blocks. The only hand-written code is a thin core module with type aliases, a GUID struct, and compile-time UTF-8-to-UTF-16 literal macros.

Methodology

Tools used: openvet 0.6.0, ripgrep, diff, git. The workspace was initialized with the published .crate file as contents/ and the microsoft/windows-rs repository checked out as VCS. VCS byte-equivalence was attempted by diffing contents/ against vcs-root/crates/libs/sys/; the result is documented below. All 249 source files were surveyed with grep passes for unsafe, FFI, network, filesystem, process, environment, crypto, and concurrency patterns. The two hand-written source files (src/lib.rs, src/core/mod.rs, src/core/literals.rs) were read in full. Six representative generated binding modules were sampled (Foundation, WinSock, Gdi, Wdk/Storage/FileSystem, Wdk/Foundation, System/IO).

Scope. Due to the size of this crate (334K LOC, 8,925 unsafe occurrences across 249 generated files), the following claims were not evaluated and are left unasserted -- they must not be read as either satisfied or violated: unsafe-safe, unsafe-documented, unsafe-minimal, unsafe-tested. This audit verifies supply-chain integrity (VCS diff), the capability surface (uses-*), build/install-time execution, test presence, implementation categorization, and dependency enumeration.

Results

VCS byte-equivalence. The published .cargo_vcs_info.json records commit 32c3144490c016fe496a0aed769bce60987a2e9d at path_in_vcs = "crates/libs/sys". The checked-out VCS is at HEAD (2269e0512, post-0.62.0); the exact publish commit is not present in the local clone's history, so byte-level equivalence at the publish commit cannot be confirmed. A diff against VCS HEAD shows two patterns: the HEAD contains additional constant definitions absent from 0.61.2 (additive, normal bindgen evolution), and ERROR_INVALID_CONFIG_VALUE differs by value (479u32 published vs 519u32 in HEAD, with a new ERROR_MEMORY_DECOMPRESSION_FAILURE = 479u32 added). These differences are fully consistent with expected bugfix and expansion between a patch release and a later development snapshot; no anomalous modification pattern was found. The workspace limitation prevents definitive byte-equivalence confirmation, but the observed delta is benign.

Build and binary surface. There is no build.rs and no pre-compiled binary assets, so has-build-exec, has-install-exec, and has-binaries all hold false. The [lib] section sets test = false and doctest = false, and there are no tests/ or fuzz/ directories and no #[test] annotations in source, so has-unit-tests, has-integration-tests, has-fuzz-tests, and has-property-tests hold false.

Capability surface. All grep surveys returned zero hits for network I/O, filesystem operations, process execution, environment variable access, RNG, and concurrency primitives. The crate is #![no_std], depends only on core and the single windows-link companion crate, and contains no executable Rust logic beyond the compile-time UTF-16 transcoder macros. uses-network, uses-filesystem, uses-exec, uses-environment, uses-crypto, uses-concurrency all hold false.

The crate does carry uses-unsafe = true because the windows_link::link!() macro expands to extern "system" blocks, which are inherently unsafe to call. The crate body contains 8,925 such items across 247 generated modules. These are declarations, not call sites -- the crate itself does not invoke any of the declared functions.

Implementation categorization. The crate declares external API surfaces; it does not implement any algorithm, data structure, parser, protocol, cryptographic primitive, concurrency abstraction, interpreter, or JIT. All impl-* claims hold false.

Benign assessment. No obfuscated code, base64 blobs, suspicious network endpoints, telemetry, or deobfuscation routines were found. The two hand-written files contain only type aliases, a GUID constructor, and compile-time string literal macros. Generated modules contain only plausible Windows API declarations sourced from public SDK metadata. is-benign holds true.

Conclusion

windows-sys 0.61.2 is a declarations-only crate with no hand-written logic beyond type primitives and compile-time literal macros. It has no build-time execution, no I/O, no concurrency, and a single dependency (windows-link) from the same upstream workspace. The 8,925 unsafe items are extern "system" declarations generated from Windows metadata; the unsafe sub-claims unsafe-safe, unsafe-documented, unsafe-minimal, unsafe-tested were not evaluated and are left unasserted as documented in Methodology. VCS byte-equivalence at the exact publish commit could not be confirmed due to the workspace containing only a post-release HEAD, but the observed delta between published content and VCS HEAD matches normal bindgen-driven evolution. No findings were raised.

Findings

No findings.

Annotations(4)

.cargo_vcs_info.json

.cargo_vcs_info.json records commit 32c3144490c016fe496a0aed769bce60987a2e9d at path_in_vcs = "crates/libs/sys". The VCS workspace is the microsoft/windows-rs repository, currently checked out at HEAD (2269e0512, post-0.62.0). The publish commit is not present in the checked-out history (the repo has 2,647 commits, none matching 32c314), so byte-level equivalence between contents/ and a known-good VCS tree at the publish commit could not be verified by diff.

A diff against the current VCS HEAD (crates/libs/sys/) shows two categories of difference: (1) the VCS HEAD contains additional constant definitions not present in 0.61.2 (additive, consistent with ongoing bindgen output), and (2) ERROR_INVALID_CONFIG_VALUE has value 479u32 in the published crate and 519u32 in VCS HEAD, with a new ERROR_MEMORY_DECOMPRESSION_FAILURE = 479u32 added in HEAD -- consistent with a bugfix that corrected a constant value and added a new one. These differences match expected evolution between a patch release and a later development HEAD; there is no pattern suggesting tampering.

src/Windows

All 247 module files under src/Windows/ are machine-generated by windows-bindgen from Windows SDK metadata. Each file consists entirely of:

  • windows_link::link!("foo.dll" "system" fn Name(...) -> ...) declarations that expand to extern "system" blocks -- these are unsafe to call but contain no executed Rust code.
  • pub const NAME: TYPE = VALUE; constant definitions.
  • #[repr(C)] struct and union definitions with named fields matching Windows SDK layouts.
  • pub type Alias = OriginalType; type aliases.

Sampling confirmed: src/Windows/Win32/Foundation/mod.rs (function declarations for kernel32.dll, ntdll.dll, etc.; thousands of Win32 error code constants), src/Windows/Win32/Networking/WinSock/mod.rs (socket API declarations for ws2_32.dll, mswsock.dll), and src/Windows/Wdk/Storage/FileSystem/mod.rs (WDK struct definitions including FAST_MUTEX, FILE_OBJECT, etc.). All are plausible Win32/WDK surface; no logic beyond declarations.

Justifies is-benign, impl-crypto, impl-parser, impl-protocol, impl-datastructure, impl-algorithm, impl-concurrency, impl-interpreter, impl-jit.

src/core/literals.rs

The core module defines primitive type aliases (BOOL, HRESULT, PSTR, PCWSTR, etc.), the GUID struct with a const fn from_u128 constructor, IUnknown_Vtbl and IInspectable_Vtbl vtable structs, and two macros: s! (null-terminated UTF-8 literal) and w! (null-terminated UTF-16 literal with a compile-time UTF-8-to-UTF-16 transcoder in literals.rs). All of this is hand-written, pure-Rust, const fn code -- no I/O, no unsafe blocks.

Justifies impl-algorithm (no algorithm implemented -- the UTF-8 transcoder is a trivial const helper, not a public algorithmic API), impl-datastructure.