[Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
Panu Matilainen
notifications at github.com
Tue Feb 20 11:52:24 UTC 2024
Based on the feedback on the [initial draft](https://github.com/rpm-software-management/rpm/discussions/2374) and work in the background, here's a major update to the v6 package format draft. Starting a new topic as the original one is getting bogged down in details that are no longer relevant. There are still some open questions and details but by now the scope is much clearer, and this should give the reader a fair idea of what to expect in the final spec.
----
# RPM v6 package format (draft v0.8)
## Summary
RPM v6 is a face-lift on the existing RPM package v4 format, not a radical
redesign. The primary motivations for v6 are to bring RPM to this millenium
technology-wise: eliminate long obsolete crypto, ensure sufficiently large
sizes everywhere and shed compatibility babbage from the last 20 years.
## Format
The following mainly describes differences to the [v4 format](https://rpm-software-management.github.io/rpm/manual/format_v4.html). The fundamental file-format in v6 remains the same: an rpm package consists of
- lead
- signature header
- main header
- payload, optionally compressed
"Dropped" in the following sections means: no longer generated or accepted in the v6
format itself. As part of v4 packages, they will remain accepted as long
as v4 is relevant (ie, a long long time).
### Compatibility
As the v6 format is largely built from extensions to the v4 format, it is largely compatible with later rpm 4.x versions. Roughly, v6 format packages can be
- read and queried by rpm >= 4.6
- unpacked by rpm >= 4.12
- verified by rpm >= 4.14.2
- installability varies based on used feature set, tracked via rpmlib() dependencies
### Headers
- tag entries are always sorted
- tag numbers are unique across signature and main header
- duplicate tags are not permitted
- all padding must be zeros
- 64 bit sizes everywhere
- package-level sizes
- file sizes
- crypto modernization:
- MD5 and SHA1 dropped everywhere
- DSA1 dropped everywhere
### Lead
- major version is 4 (rpm 4.x used 3)
- os and arch are zeros
### Signature header
- header+payload digests and signatures (aka V3 signatures) are dropped
(v3 signatures are no longer generated by default since 4.16)
- RPMSIGTAG_MD5
- RPMSIGTAG_PGP
- RPMSIGTAG_GPG
- RPMSIGTAG_PGP5
- all size tags are dropped:
- RPMSIGTAG_SIZE
- RPMSIGTAG_LONGSIZE
- RPMSIGTAG_PAYLOADSIZE
- RPMSIGTAG_LONGARCHIVESIZE
- signature reservation moved to a new tag number 999 (RPMSIGTAG_RESERVED)
- eliminate tag value conflicts between signature and header tags - happens
when all of the above is done: all signature tags are between 256 and 999
- drop RPMTAG_SHA1HEADER
- open questions:
- protect ima + fsverity signatures somehow (separate signature?)
- use RPMSIGTAG_RESERVED also for signature self-padding?
### Main header
- file sizes are always 64bit:
- RPMTAG_LONGFILESIZES
- RPMTAG_LONGSIZE
- RPMTAG_LONGARCHIVESIZE
- 32bit size tags are dropped:
- RPMTAG_SIZE
- RPMTAG_FILESIZES
- RPMTAG_ARCHIVESIZE
- new payload size tags (always 64bit):
- RPMTAG_PAYLOADSIZE
- RPMTAG_PAYLOADSIZEALT
- new tag to carry package format version (RPMTAG_FORMAT or such)
- always utf-8 encoded
- group tag is made optional
### Payload
- always in the "new" large file format, never cpio
- this *cannot* be reflected in PAYLOADFORMAT as that would be a gratituous compatibility break
## Metadata level
- rpmlib() dependencies on v3 compatibility are dropped:
- PayloadFilesHavePrefix
- CompressedFileNames
- PartialHardlinkSets
- proper multiarch dependencies (instead of ()(64bit) markers)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/repo-discussions/2919 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240220/711d579d/attachment.html>
More information about the Rpm-maint
mailing list