Clear the PEM parser's internal base64 buffers when the section is a private key
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
Research direction
Start by locating SliceIter and pem::from_buf in the PEM parser, then trace how their buffers grow and are dropped for private key sections. Clear sensitive buffer contents before those operations, using the crate's existing zeroize support where it fits. Done when parser-owned buffers no longer retain private key text after clearing, regrowth, or drop; the reporter offers a probe for validation.
Written by the indexing model from the issue text.
Description
The PEM parser's internal buffers are dropped without being cleared. This holds for SliceIter's b64_buf and for the line and b64buf buffers in pem::from_buf. When the section is a private key, those buffers held the key's base64 text. Each reallocation as a buffer grows, and the final drop, return a block that still holds part of the encoded key to the allocator.
We measured this at 1.15.1 with a counting allocator that forces every growth to move. For a private key of about RSA-4096 size, from_pem_slice left 2–3 freed blocks containing a base64 marker, and the from_buf loop up to 5. In both runs our own input buffer and the decoded DER were wiped, so these blocks are the parser's. A forced move over-counts compared with an allocator that can grow in place, so these figures are upper bounds.
This is separate from #114 (clearing PrivateKeyDer on drop), which notes that adding Drop to a public type is a breaking change. These buffers are internal, so clearing them before they are dropped or regrown changes no public API. The decoding is already constant-time for private keys (decode_secret), so this would extend the same care to the buffers around it.
A possible shape, for whatever fits the crate best: when the section kind is a private key, clear the buffer (for example with zeroize, which the alloc feature already pulls in) before it is cleared, regrown or dropped. A pre-sized buffer would avoid regrowth copies.
We are happy to test a change against our probe.
Thank you,
Tim
Founder, Synergy Geeks
- Dominant language
- Rust
- Stars
- 42
- Forks
- 55
- Avg merge
- 3d 7h
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rustls/pki-types
-
next-major-release
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
next-major-release
Difficulty 4/5 3-5 days Newbie friendliness 25/100
-
next-major-release
Difficulty 2/5 1-3 hours Newbie friendliness 48/100
-
next-major-release
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
next-major-release
Difficulty 4/5 3-5 days Newbie friendliness 25/100
All issues in rustls/pki-types
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
pop-os/cosmic-settings#2296 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Eyevinn/open-live-ingest#36 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
superradcompany/microsandbox#2071 ·
Maintainers usually reply within 1 day
-
app
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
bug bug jury peripheral:i2s
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
esp-rs/esp-hal#6828 · 1 comment ·
Maintainers usually reply within 1 day