[Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)

[Lukier1316]

> 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 grows more detailed.
> 
> ----
> 
> # RPM v6 package format (draft v0.2)
> 
> ## 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
> - 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
> - 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
> - size tags are dropped:
>   - RPMSIGTAG_SIZE
>   - RPMSIGTAG_LONGSIZE
>   - RPMSIGTAG_PAYLOADSIZE 
>   - RPMSIGTAG_LONGARCHIVESIZE (move to main header or drop?)
> - 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?)
> - the signature header is self-padded, ie doesn't require special actions from reader
> 
> ### 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
> - group tag is made optional
> - 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)
> 
> ## Open questions
> - how to irrevocably set and detect v6 format? must not be "downgradeable" to v4 for more relaxed checks



-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-13578132
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/repo-discussions/2374/comments/13578132 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20250625/6c396d9b/attachment.htm>