kcode-gemini-api 0.3.0

Gemini inference, multimodal generation, and session spending limits
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

# Credential-Bearing Dependency Audit

Audit date: 2026-07-20 UTC.

This record covers the exact third-party crates that directly receive or retain
the Gemini API key through `kcode-gemini-api` APIs. Any version change invalidates
the corresponding conclusion and requires a fresh source audit before use.

## reqwest 0.13.4

- Crates.io archive SHA-256:
  `219c5811de6525e5416c7d5d53bb656d3afdbc6c5af816e0802bcfa42dbdc1c3`.
- Enabled features: `json` and `rustls`; default features are disabled.
- Reviewed material: the complete published archive, including both manifests,
  every `src/**/*.rs` module, licenses, repository metadata, and all unsafe,
  environment, filesystem, logging, redirect, retry, proxy, request-debug,
  header, TLS, and outbound-network paths. The crate has no build script.
- Findings: no telemetry or autonomous destination exists. Runtime network
  destinations come from caller requests or explicitly configured proxies.
  Request `Debug` includes headers, so `kcode-gemini-api` supplies the API key as a
  `HeaderValue` marked sensitive. Reqwest can discover proxies, follow
  redirects, send referrers, retry requests, or emit wire bytes when explicitly
  configured; `kcode-gemini-api` disables all five behaviors and enables HTTPS-only
  mode. Ordinary logs contain connection/retry metadata, not request headers or
  bodies. Error values can retain request URLs but not header values; the
  library additionally reduces transport errors to fixed classifications.
  Filesystem-capable blocking/multipart APIs, cookies, system-proxy support,
  compression, HTTP/2, HTTP/3, and verbose wire logging are not enabled or used.
- Conclusion: acceptable for passing the API key solely to the fixed Google
  Interactions endpoint under the client configuration above.

## zeroize 1.9.0

- Crates.io archive SHA-256:
  `e13c156562582aa81c60cb29407084cdb54c4164760106ab78e6c5b0858cf64e`.
- Enabled features: default `alloc`; derive and Serde support are not enabled.
- Reviewed material: the complete published archive, including both manifests,
  every source and test file, licenses, repository metadata, architecture
  barriers, volatile writes, collection/string implementations, and unsafe
  blocks. The crate has no build script.
- Findings: the crate performs no network, filesystem, environment, logging,
  telemetry, process, or dynamic-code operations. `Zeroizing<String>` invokes
  the audited `String`/`Vec` implementation on drop, overwriting initialized and
  spare capacity before clearing the allocation. The crate documents that
  reallocations and compiler-created copies cannot be retroactively erased.
- Conclusion: acceptable for best-effort in-memory clearing of the owned API
  key, with the documented limits of software zeroization.

## Re-audit rule

Both versions are exact-pinned in `Cargo.toml` and checksum-pinned by
`Cargo.lock`. Before changing either exact version, compare and review the full
new published source and replace this record. Automated vulnerability scanning
may supplement but cannot replace that review.