cargo / windows-sys / audit
cargo : windows-sys @ 0.60.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.60.2 is Microsoft's machine-generated crate of raw FFI bindings to the Windows API and WDK (~334K LOC). No build script, no install hooks, no binaries, no tests, and no I/O in the Rust body; unsafe appears only in FFI type signatures. The unsafe-safe, unsafe-documented, and unsafe-minimal claims were not evaluated due to the volume (~8,925 occurrences). VCS diff couldn't be made against the pinned commit. No findings.

Report

Subject

windows-sys 0.60.2, published by Microsoft, is a machine-generated Rust crate of raw FFI bindings to the Windows API and Windows Driver Kit (WDK). It exposes approximately 334K lines of extern function declarations, C-compatible struct and union definitions, and integer constants grouped into a feature-flag hierarchy. No convenience wrappers or trait impls are provided; callers invoke Windows APIs directly through unsafe extern blocks. The single runtime dependency is windows-targets, which supplies the link! macro used throughout the generated code to emit DLL import directives.

Methodology

The published crate contents were examined with the following tools: openvet 0.6.0, diff, and grep. Cargo.toml, Cargo.toml.orig, readme.md, and .cargo_vcs_info.json were read in full. The source was surveyed for network, filesystem, process, environment, crypto, and concurrency usage using grep -rEn patterns from the runbook. src/lib.rs, src/core/mod.rs, and src/core/literals.rs were read in full. Sample modules src/Windows/Win32/Graphics/Gdi/mod.rs, src/Windows/Wdk/Storage/FileSystem/mod.rs, src/Windows/Win32/UI/Controls/mod.rs, and src/Windows/Win32/mod.rs were sampled to confirm the uniform generated structure.

VCS: .cargo_vcs_info.json records commit 4b8893b307719ec23cce698269ca572ef301dc5c in the microsoft/windows-rs repository at path crates/libs/sys. The vcs-root/ checkout exists (HEAD 2269e05124a) but the pinned commit 4b8893b is not present in the shallow clone, so a VCS diff couldn't be made against the pinned commit.

Scope. Due to the scale of this crate (~334K LOC, ~8,925 unsafe occurrences in machine-generated declarations), the following claims were not evaluated and are left unasserted: unsafe-safe, unsafe-documented, unsafe-minimal, unsafe-tested. This audit verifies supply-chain integrity (VCS state noted above), the capability surface (uses-* flags), build/install-time execution, and dependency enumeration.

Results

No build script is present (build = false in Cargo.toml) and the library target has test = false, so cargo executes no code at build or install time. Justifies has-build-exec, has-install-exec.

The crate ships no binary assets. Justifies has-binaries.

No test files exist in the published crate and no #[test] annotations appear anywhere in the source. The Cargo.lock present in the package records the build-time dependency graph for the crate itself but has no bearing on downstream users. Justifies has-unit-tests, has-integration-tests, has-fuzz-tests, has-property-tests.

The source survey found no network, filesystem, process, environment, crypto, or concurrency usage in the Rust-side code body. All apparent hits (Mutex, Arc, eval*) are Windows API struct field names or function names in the generated declarations, not Rust API calls. Justifies uses-network, uses-filesystem, uses-exec, uses-environment, uses-crypto, uses-concurrency, uses-jit, uses-interpreter.

unsafe appears throughout the generated code in FFI function pointer type signatures and extern "system" declarations, which is the expected form for raw Windows API bindings. The crate body itself executes no unsafe operations; callers are required to wrap any invocations in their own unsafe blocks. Justifies uses-unsafe.

The crate declares no parser, interpreter, JIT, protocol, data structure, algorithm, or concurrency primitive implementations. The hand-written src/core/literals.rs contains const fn UTF-8/UTF-16 decode logic for the s! and w! macros; this is compile-time string-literal processing with no runtime dispatch. Justifies impl-crypto, impl-parser, impl-interpreter, impl-jit, impl-protocol, impl-datastructure, impl-algorithm, impl-concurrency.

No obfuscated code, base64 blobs, hidden payloads, or suspicious patterns were found. Justifies is-benign.

Conclusion

windows-sys 0.60.2 is a feature-flag-gated collection of machine-generated Windows API declarations with a single small hand-written support module. The crate body performs no I/O, spawns no processes, reads no environment, and executes no unsafe code at the Rust level; unsafe appears only in FFI type signatures that delegate all execution to Windows DLLs at caller call sites. The unsafe-safe, unsafe-documented, unsafe-minimal, and unsafe-tested claims were not evaluated due to the volume of generated declarations (approximately 8,925 occurrences). No build-time or install-time code execution occurs. A VCS byte-equivalence check could not be completed because the pinned commit is absent from the available repository clone.

Findings

No findings.

Annotations(2)

src/core

The core module contains hand-written support code: type aliases for Windows primitive types (BOOL, HRESULT, PSTR, PWSTR, PCSTR, PCWSTR, BSTR, HSTRING), the GUID struct with a const constructor, vtable structs for IUnknown and IInspectable, and two utility macros (s! and w!) for constructing null-terminated UTF-8 and UTF-16 string literals at compile time. The macro implementations in literals.rs are const fn computations over byte slices with no unsafe code. The vtable function pointer fields use unsafe extern "system" fn types, which is consistent with the FFI-only nature of the crate. Justifies uses-unsafe (unsafe appears in FFI function pointer type signatures throughout the generated declarations).