Security & Linting
Relevant source files
The following files were used as context for generating this wiki page:
Security and linting within the rust-battery project are managed through a combination of crate-level attributes, dependency audits, and automated linting configurations. The project enforces strict coding standards to ensure code quality and safety, particularly when dealing with cross-platform FFI (Foreign Function Interface) calls and system-level data.
Dependency Security & Auditing
The project utilizes cargo-deny via the deny.toml configuration file to manage crate security, license compliance, and dependency health. This system ensures that only approved licenses are used and known security vulnerabilities in dependencies are flagged.
Dependency Policy Configuration
The security policy is defined across several categories:
| Category | Policy/Constraint | Description |
|---|---|---|
| Advisories | Version 2 | Tracks security advisories for dependencies. |
| Licenses | Confidence 0.8 | Sets the threshold for license identification accuracy. |
| Bans | Multiple versions allowed | Allows different versions of the same crate in the graph. |
| Bans | Wildcards: "warn" | Issues warnings if wildcard dependencies are used. |
| Sources | Registry allow-list | Restricts crate sources to specific registries. |
Sources: deny.toml:1-33
License Compliance
The project explicitly allows a specific set of open-source licenses to ensure legal safety and compatibility.
- Allowed Licenses: Apache-2.0, ISC, MIT, Unicode-3.0, Unicode-DFS-2016.
- Primary License: The crate itself is licensed under the ISC license.
Sources: deny.toml:13-21, Cargo.toml:11
Automated Linting & Code Quality
The codebase enforces strict linting rules at the library root to prevent common Rust pitfalls and ensure a clean API surface.
Crate-Level Deny Attributes
The project root explicitly denies several categories of code patterns to maintain high standards of quality:
#![deny(unused)]
#![deny(unstable_features)]
#![deny(bare_trait_objects)]
Sources: src/lib.rs:21-23
Clippy Integration
The project actively manages Clippy lints, particularly in platform-specific modules where FFI and non-idiomatic naming conventions are common. For instance, in Windows FFI modules, specific lints are allowed to accommodate the naming conventions of the Windows API while maintaining general code quality.
// Allowing specific lints for Windows Power Information structs
#![allow(non_snake_case, clippy::unreadable_literal)]
Sources: src/platform/windows/ffi/ioctl/info.rs:3, src/platform/windows/ffi/ioctl/mod.rs:1
Development Workflow & CI
The project uses GitHub Actions for Continuous Integration (CI) to automate the verification of security and linting rules.
CI Lifecycle
The following diagram illustrates how security and linting checks are integrated into the build process:
The CI system runs lints, audits, and tests across multiple platforms (Linux, macOS, Windows, etc.) to ensure that platform-specific FFI implementations remain secure and compliant.
Sources: README.md:5-10, CHANGELOG.md:104-105
Security in Platform Implementations
When interacting with operating system APIs, the project takes measures to handle data safely, especially when converting raw system bytes into Rust types.
FFI Data Safety
In the Windows implementation, raw data from BATTERY_INFORMATION is handled using unsafe blocks only where necessary for memory initialization, and string conversions use lossy methods to prevent panics on invalid UTF-8 data.
impl BatteryInformation {
pub fn technology(&self) -> Technology {
// Safe conversion of raw C-string chemistry data
let raw = String::from_utf8_lossy(&self.0.Chemistry);
match Technology::from_str(&raw) {
Ok(tech) => tech,
Err(_) => Technology::Unknown,
}
}
}
Sources: src/platform/windows/ffi/ioctl/info.rs:11-15, src/platform/windows/ffi/ioctl/info.rs:56-62
Summary
The rust-battery project maintains security and code health through a multi-layered approach. By denying unused code and unstable features at the crate level, auditing dependencies for licenses and vulnerabilities with cargo-deny, and carefully managing FFI safety, the project provides a reliable cross-platform interface for battery monitoring. These checks are enforced through CI to maintain stability across the supported Linux, macOS, and Windows platforms.