In the spirit of release early and often, here goes the (admittedly rough)
first public draft of the rpm v6 package format that people have seen mentions
of here and there. As you'll notice, this will be a relatively conservative
update to the format, a facelift if you like, rather than a radical redesign.
Feedback and discussion are welcome and expected. We plan on keeping this
thread open for several months to give the relevant parties sufficient time to
participate. Please keep in mind that this draft is strictly about the concrete
package format of .rpm files, and not a wishlist for rpm v6.0 features.
This initial post and the associated draft version number will be updated as
the items get added and the plan grow more detailed.
----
# RPM v6 package format (draft v0.1)
## 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.
The following mainly describes differences to the undocumented v4 format,
the v6 format has to, and will be properly and thoroughly documented.
"Dropped" in the below 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).
The last rpm 4.x version will be able to read + install v6 packages.
Rpm v6 will be able to read and install v4 packages, but v3 support
will be dropped.
The fundamental file-format remains the same: an rpm package consists of
- lead
- signature header
- main header
- optional payload, optionally compressed
### Headers
- tag entries are always sorted
- tag numbers are unique across signature and main header
- 64 bit sizes everywhere
- package-level sizes
- file sizes
- crypto modernization:
- MD5 and SHA1 dropped everywhere
- DSA1 dropped everywhere
### Lead
- except for the rpm magic, the lead will be zeros only
### 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
- sizes are always 64bit:
- RPMSIGTAG_LONGSIZE
- RPMSIGTAG_LONGARCHIVESIZE
- 32bit size tags are dropped:
- RPMSIGTAG_SIZE
- RPMSIGTAG_PAYLOADSIZE
- signature reservation moved to some other mechanism (TBD):
- RPMSIGTAG_RESERVEDSPACE
- eliminate tag value overlap between signature and header tags - happens
when all of the above is done
- drop RPMTAG_SHA1HEADER
- protect ima + fsverity signatures somehow (separate signature?)
### Main header
- file sizes are always 64bit:
- RPMTAG_LONGFILESIZES
- RPMTAG_LONGSIZE
- RPMTAG_LONGARCHIVESIZE
- 32bit size tags are dropped:
- RPMTAG_SIZE
- RPMTAG_FILESIZES
- RPMTAG_ARCHIVESIZE
- always utf-8 encoded
- compression?
### Payload
- always in the "new" large file format, never cpio
- reflect this in the PAYLOADFORMAT tag too
## Metadata level
- rpmlib() dependencies are reset (ideally they'd be replaced by a better
mechanism but that's probably out of scope)
- 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/2374
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/repo-discussions/2...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
