- Rust 100%
| LICENSES | feat: initial implementation and tests | |
| src | chore: base on minipgp6-frame | |
| tests | feat: initial implementation and tests | |
| .gitignore | feat: initial implementation and tests | |
| Cargo.toml | chore: base on minipgp6-frame | |
| README.md | feat: initial implementation and tests | |
| REUSE.toml | feat: initial implementation and tests | |
| rustfmt.toml | feat: initial implementation and tests | |
minipgp6-upframe
A special-purpose companion module for minipgp6.
This crate normalizes OpenPGP packet headers by reframing "old style" packet headers into the equivalent "new style" headers.
Note: While this normalization may be useful in rare edge cases, it should not be required for regular use of minipgp6.
Context
The OpenPGP format has historically used two different generations of packet headers. RFC 9580 refers to them as "OpenPGP format" (new style headers) and "Legacy format" (old style headers).
minipgp6's core modules only support the newer "OpenPGP format" packet headers.
Timeline
Early versions of PGP in the 1990s used "old style" packet headers (which are now considered a legacy format).
The newer header format was introduced in RFC 2440 (1998). RFC 4880 (2007) recommends always emitting new style packet headers (except in special cases, when interoperability with old software is an issue).
Differences between the header versions
The old header format has two practical limitations:
- Packet type ids are encoded using only 4 bits (so they are limited to values between 0 and 15).
- Packets with a size that is not known while writing the packet header (or that exceeds the maximum encodable fixed length) can only occur as the final packet in a sequence of packets.
The new packet header format has neither of these limitations. It acts as a strict superset of the old header format:
All packet sequences that can be encoded with old headers can also be expressed with new headers. The converse is not generally true.
Support for new headers
All OpenPGP software of the last 25+ years can read both header formats. A majority of implementations has emitted new style packet headers by default for decades1 .
Packet headers in minipgp6
RFC 9580 (which minipgp implements) forbids emitting old style headers for modern OpenPGP data. No OpenPGP implementation should ever produce old style packet headers for the RFC 9580 formats that minipgp6 supports.
Therefore, minipgp's core modules contain no support for "Legacy format" packet headers.
The minipgp6-upframe packet header converter
This crate is a companion module for the modular minipgp6 set of libraries.
minipgp6-upframe normalizes arbitrary binary OpenPGP packet streams to consistently use new style headers. Input streams may contain any mix of old and new style headers.
The Upframer adapter takes a Read as its (streaming) input.
The adapter can in turn be consumed as a Read, which yields the equivalent packet sequence, reframed to consistently use new style headers.
In any modern OpenPGP environment, this adapter should not be needed.
However, for edge cases where legacy OpenPGP data needs to be processed, minipgp6-upframe allows handling such data, while keeping explicit support for the legacy header format out of the core minipgp6 codebase.
-
The GnuPG software is alone in still emitting old style headers by default. It only emits new style headers where they are unavoidable (for packets with type id over 15, and for arbitrary sized data packets that are followed by additional packets). GnuPG's output is not a practical concern for minipgp6, though, since GnuPG can't currently produce any of the modern RFC 9580 OpenPGP formats that minipgp supports. ↩︎