cargo / windows-sys / audit
cargo : windows-sys @ 0.52.0
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.52.0 is Microsoft's machine-generated raw FFI bindings to the Windows API (~385K LOC, 3,411 extern declarations). VCS byte-equivalence holds. No binary artifacts, no build-time execution, no runtime capability surface in the crate body. No findings.

Report

Subject

windows-sys 0.52.0 is Microsoft's official machine-generated raw FFI bindings to the Windows API, covering the Win32 and WDK (Windows Driver Kit) surfaces. The crate exposes 3,411 extern "system" function declarations and a large set of type aliases, constants, and struct definitions across approximately 385K lines of generated Rust source. Each binding group is gated behind a Cargo feature flag (e.g. Win32_Networking_WinSock), so consumers pay only for the API surface they use.

Methodology

The published crate contents were compared against the upstream Git repository at the commit recorded in .cargo_vcs_info.json using diff -rq. The VCS directory is a symlink to vcs-root/crates/libs/sys, where the repository was checked out at the pinned commit. src/lib.rs, src/core/mod.rs, and src/core/literals.rs were read in full. Three generated modules were sampled: src/Windows/Win32/Foundation/mod.rs, src/Windows/Win32/Networking/WinSock/mod.rs (partial), and src/Windows/Wdk/Foundation/mod.rs. Capability surveys were run with grep -rEn across all source files for: unsafe, extern, network sinks, filesystem sinks, process execution, environment access, cryptographic primitives, and concurrency primitives. The file manifest was inspected for non-source artifacts. The crate has no build.rs and is not a proc macro, so no build-time execution was present to review.

Scope. Due to the machine-generated nature of this crate (~385K LOC, 3,411 extern "system" declarations) and the scoped audit instructions, the unsafe sub-claims (unsafe-safe, unsafe-documented, unsafe-minimal, unsafe-tested) were not evaluated and are left unasserted. The declarations expand to unsafe extern "system" fn items via the windows_targets::link! macro, but no unsafe blocks are authored inside this crate's source. This audit verifies supply-chain integrity (VCS byte-equivalence), the capability surface (uses-*), build and install execution, binary artifact presence, and dependency enumeration.

Results

The diff between published crate contents and VCS shows only a Cargo.toml difference, which is cargo's standard normalisation (path dependency converted to registry dependency, metadata fields reordered). All source files match byte-for-byte.

No pre-compiled binary artifacts are present in the package, justifying has-binaries. The crate has no build.rs and is not a proc macro, so no build-time or install-time code runs on a consumer's machine, justifying has-build-exec and has-install-exec.

The crate body contains no executable logic in the uses-* sense: no unsafe blocks, no network calls, no filesystem access, no process spawning, no environment reads, no cryptographic operations, no concurrency primitives. Every file in src/Windows/ consists exclusively of windows_targets::link! macro invocations (which expand to extern declarations) and pub const definitions. The src/core/ module contains type aliases, a GUID struct with a const constructor, and two compile-time macros for null-terminated string literals. This justifies uses-unsafe, uses-network, uses-filesystem, uses-exec, uses-environment, uses-crypto, uses-concurrency, uses-jit, and uses-interpreter.

The crate implements no algorithms, data structures, protocols, parsers, interpreters, JIT, concurrency primitives, or cryptographic operations of its own, justifying impl-crypto, impl-parser, impl-interpreter, impl-jit, impl-protocol, impl-datastructure, impl-algorithm, and impl-concurrency.

No tests ship with the published crate and none are present in the sys subdirectory of the VCS checkout, justifying has-unit-tests, has-integration-tests, has-fuzz-tests, and has-property-tests. (Integration tests for the windows-rs workspace exist in crates/tests/ under the repo root, but are out of scope for this crate coordinate.)

No obfuscated code, base64 payloads, suspicious network endpoints, or unusual patterns were found. The crate is straightforwardly generated declaration tables, justifying is-benign.

Conclusion

windows-sys 0.52.0 is a large but structurally trivial crate: generated FFI declarations with no hand-written logic. The supply-chain integrity check passes cleanly (VCS byte-equivalence holds). No binary artifacts, no build-time execution, and no runtime capability surface in the crate body itself. No findings were raised.

Findings

No findings.

Annotations(3)

src/Windows

The Windows/ tree contains 233 generated module files (384,514 total lines). Every file consists exclusively of two kinds of items: windows_targets::link! macro invocations that declare extern "system" function signatures, and pub const definitions for Windows API constants and type aliases. No hand-written logic, no unsafe blocks inside the crate itself. The unsafe keyword appears only inside the expanded extern "system" fn declarations, which are generated by the windows-targets macro and not authored in this crate. Justifies has-unit-tests, has-integration-tests, has-fuzz-tests, has-property-tests, has-binaries, has-build-exec, has-install-exec.

src/core

The core module contains two files: mod.rs defines primitive type aliases (HRESULT, PSTR, PWSTR, GUID etc.) and a const fn GUID::from_u128 constructor, all safe Rust with no unsafe. literals.rs defines the s! and w! macros for producing null-terminated UTF-8 and UTF-16 string literal pointers at compile time; decode_utf8_char and utf16_len are const fns that execute at compile time only. No runtime I/O or unsafe code. Justifies is-benign.