Rust SIG Meeting 2026-02-03

[PLeVasseur]

Hey folks 👋 welcome to our second meeting of 2026.

Rust SIG Meeting 2026-02-03

Agenda

1. Solicitation of notetaker
   • @PLeVasseur
2. Acceptance of Previous Meeting Minutes
3. Rust Watercooler Chat Topic - Rust + Security
4. Review GitHub repo content and discuss how to enrich (Pete)
   1. Issues
   2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.
5. Office hours - Rust + Automotive questions - come chat! (All)
6. Discuss upcoming events / news related to Rust & Automotive (All)
7. Meeting close

Check-in area

• @PLeVasseur
• xxx

Housekeeping section, please add

• Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
• GitHub repo: https://github.com/rust-sig/rust-sig
• Eclipse SDV Slack channel: #rust-sig

Tasks

• <task>

Meeting Minutes:

Acceptance of Previous Meeting Minutes

• Accepted

Questions
*

Material

Any material to read before the meeting should be included here.

[krucod3]

Great session, @PLeVasseur, thx! 👍

[darkwisebear]

Many thanks 👍

[arnoox]

Rust SIG Meeting 2026-02-03

Agenda

1. Solicitation of notetaker
   • @PLeVasseur
2. Acceptance of Previous Meeting Minutes
3. Rust Watercooler Chat Topic - Rust + Security
4. Review GitHub repo content and discuss how to enrich (Pete)
   1. Issues
   2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.
5. Office hours - Rust + Automotive questions - come chat! (All)
6. Discuss upcoming events / news related to Rust & Automotive (All)
7. Meeting close

Check-in area

• @PLeVasseur
• @darkwisebear
• @arnoox

Housekeeping section, please add

• Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
• GitHub repo: https://github.com/rust-sig/rust-sig
• Eclipse SDV Slack channel: #rust-sig

Tasks

Meeting Minutes: @arnoox

Rust Security by @PLeVasseur

• Rust usage is increasingly growing
• Rust's uniqueness: Safety (Type, Memory, Thread)
• Supply Chain Security
  • Still security is a thing e.g.: malicious package dependency. Same problem than with other language with package managers
    • "cargo add my-crate"
  • Hijacked Package: e.g. liblzma-sys --> malicious crates were yanked: https://crates.io/crates/liblzma-sys/versions
  • Typo squatting: "dependency confusion attack". E.g. rustdecimal vs rust_decimal crates.
  • Legal Traps (license swap). Repo changed incorrectly from Apache 2.0 to BSL 1.1. But crates.io didn't reflect this for a while. This is not malicious, however this can be a serious legal violation.
  • Bugs in Indirect Dependencies: e.g.: the "time" crate was sued to be part of libstd.
  • Indirect Dependency Drift: idna tends to be buried in all web apps. Due to a spec bug, DNS would wrongly match and malicious DNS could be injected.
  • Phishing Attempts: Sept 2025 Email with @rustfoundation.dev containing phishing links.
• How to mitigate: Tooling, Manual audits, Process.
  • Hijacking:
    • commit cargo.lock,
    • cargo audit on each PR and nightly, cargo auditable on binaries
    • use cargo deny
  • Typo squatting:
    • PR template requiring a reason why a crate is good enough to be added,
    • cargo vet and cargo-crev,
    • ban usage of cargo add
  • License Swaps & Legal Traps
    • cargo deny and cargo sbom
  • Bugs & Indirect dependencies:
    • cargo audit
    • avoid semantic versioning ranges
  • Indirect dependency drift
    • cargo audit + pin versions of a crate to have a single version of crates.
    • Make use of the [patch] manifest in own Cargo.toml.
  • Phishing Attempts
    • Enforce 2FA backed by authenticator
    • Token Hygiene: short-lived, least-privileged tokens
    • release-plz
• For internal crate registry: kellnr
  • How to handle dependencies over years/decades.
• Challenges with Stringly-Types APIs
  • TOCTOU --> race condition
  • Externally Parsed API Outputs: use caution with untrusted inputs. E.g. std::fs::process::Command under Windows.
  • Interaction with external resources: e.g.: std::io::Write() isn't marked unsafe, but you can use it to write on your own memory using "/proc/self/mem"
• Using unsafeand its issues
  • e.g. from_raw_parts(...) -> Vec<T> --> highly unsafe! The invariants checked by the compiler are up to an engineer.
  • As far as possible: ban the usage of unsafe! If really required: learn unsafe, read Rustonomicon, ...
  • Ideas:
    • catch unsafe in PR and let a specialized team review the code.
    • put all unsafe stuff in a dedicated crate.
  • Alternatives to "unsafe":
    • use std lib functions
    • use specialized crates
    • use procedural macros
  • General best practices:
    • explore Rust core to check if an unsafe function is already existing
    • keep unsafe things into own module
    • use miri, kani, ...
    • use formal verification
    • dedicated PR templates
  • Summary: Rust is safe but there more things to do.

Acceptance of Previous Meeting Minutes

• Accepted

Questions

Material

Any material to read before the meeting should be included here.

[bharatGoswami8]

Great session!! Thank you!