RPM package invariants?

[DemiMarie]

What are the invariants that must hold in a valid RPM package? I am
especially interested in the ones that RPM does not currently check
properly. This includes ones that it cannot check due to backwards
compatibility. I would like to see RPM check all of them in v6 packages, and check as many as possible for v4 packages.

Here is my current understanding of package invariants. I would consider
a violation of any of these grounds to consider a package broken.
The ones marked with a (*) are the ones that I know RPM cannot
currently enforce for compatibility reasons. Are there any others that
RPM cannot enforce safely? For those that it can enforce safely, would
patches to enforce them be accepted? From my perspective, enforcement
should ideally take the form of rejecting the package at load time,
but a warning (such as “your package is broken and will be rejected
in the future”) could be an acceptable compromise. For RPMv6 I would
like to enforce all of these invariants.

1. Padding must be minimal and zeroed.

2. Regions must be internally consistent. That is, the region trailer
   must come after the number of entries the region header says it
   does.

3. (*) Header tag data entries must be sorted.

4. The signature header must not include any i18string or i18table
   entries.

5. The main header must have an i18table if it has any i18string
   entries.

6. All i18string entries must be of the same length as each other and
   the i18ntable.

7. The Filelangs, Dirindexes, Fileinodes, Filedevices, Basenames,
   Fileclass, Fileusername, Filegroupname, Fileflags, Filelinktos,
   Filedigests, Filerdevs, Filemodes, Filestates, Filesizes,
   Filecolors, Filedependsx, Filedependsn, file signature, and verity
   signature arrays must all be the same length if they exist at all.

8. The entries in Basenames must not contain "/".

9. Every entry in Fileclass must correspond to an entry in the
   Classdict array.

10. Every entry in Classdict must be the Fileclass entry of at least
    one file.

11. Same as above, but with Dirnames instead of Classdict and
    Dirindexes instead of Fileclass.

12. The Requireflags, Requirename, and Requireversion entries must be
    the same length.

13. The Changelongname, Changelogtime, and Changelogtext entries must
    be the same length.

14. The Encoding entry must exist, be of length 1, and contain the
    literal string "utf-8".

15. The Payloaddigest and Payloaddigestalt entries must each be a
    single string with a length matching the Payloaddigestalgo entry.

16. The Filelinktos must have one non-empty entry for every symlink and
    one empty entry for every non-symlink.

17. For each regular file, the corresponding entry in Filedigests
    must have a length that corresponds to the Filedigestalgo entry.
    For all other files, the corresponding entry in Filedigests must
    be empty.

18. The Version, Release, Summary, Description, Buildtime, Buildhost,
    Size, Distribution, License, Packager, Group, Url, Os, Arch, and
    Bugurl entries must be single strings.

19. The IMA signature, Filedigest, Payloaddigest, and Payloaddigestalt
    entries must be valid hex.

20. Verity signatures must be valid base64, properly padded. The last
    byte before the padding must not encode bits that will not occur in
    the decoded result. That is, if there is one = for padding, the
    byte before it must encode a 6-bit value with the bottom two bits
    zero, and if there are two =, the byte before the first one must
    encode a 6-bit value with the bottom four bits zero. Whitespace is
    not permitted. These rules should apply to anywhere base64-encoded
    data appears in an RPM package and is interpreted by RPM.

21. All strings in the signature header must be printable ASCII.

22. All strings in the main header must be valid UTF-8 and not include
    non-printable ASCII characters. Spaces, tabs, and newlines are
    allowed, though the latter two are not permitted in paths.

23. The signature header must not contain any duplicate tags: tags
    in its dribble are not allowed to duplicate tags in its immutable
    region, and entries in both the immutable region and the dribble
    must be unique. For v6, I would like to require it to not contain any dribble at all.

24. The immutable header must not contain any duplicate tags.

[pmatilai]

Well I'm glad you're not asking for much 😂

[DemiMarie]

I admit that this is a long list 🤣

As a security researcher, I like to know what the invariants of a system are, because security holes tend to happen when they get broken.

[pmatilai]

On a random related note, many of these things (such as the tag relations) should really be defined through data structure(s) that can be validated rather than these implementation driven checks wherever somebody remembered to check for anomalies.

[DemiMarie]

That would be nice, but load-time checks are a good start.

[pmatilai]

What I mean is that the format, tag relations etc needs to be defined in abstract terms. Implementing any particular checks is a different matter.

[DemiMarie]

Agreed! These invariants need to be added to the spec first, then added to the implementation.

[dralley]

Is there an external tool capable of checking these invariants currently? Is this something rpmlint partially does or can do, or is this a bit too low level?

[dralley]

Also is there some way to make discoverable implementation "quirks" reportable / discoverable even in cases where RPM is permissive of those quirks for compatibility reasons?

e.g. e2f1f19

[DemiMarie]

rpm-oxide should check all of them. The ones that it does not check are limitations of the tool.

[dralley]

(*) Header tag data entries must be sorted.

I'm unclear on what this means, do you mean

1. We cannot require tags to be sorted at parse time for compatibility reasons, or
2. There are certain tags which must be in certain positions in a sort-order violating way?

[DemiMarie]

v4 cannot require this because of backwards compatibility. v6 does require it.

[dralley]

So, not really a question about packages themselves - parseEVR() is extremely lax on doing any kind of validation. For example all of these are parsed without complaint (there is not actually a mechanism for error reporting anyway)

• :
• -
• .
• :-
• asdf:
• ~:
• ^foo:
• -^

(and so on). Would doing such validation be useful or appropriate? Is there a restriction on "what an EVR can look like" outside of the implementation and just "packaging guidelines"?

[DemiMarie]

Anything starting with a - should probably be rejected because option injection is a thing.

[pmatilai]

Historically parseEVR() has only looked at packaged data, so the validation is assumed to be done at build-time.

As it's now exposed through a public API it should optimally do a better job of sanity checking, but the original use-case of version comparison simply has no notion of errors at all, the outcome is always -1,0 or 1 no matter what crap you throw at it.