Clean up and expand tests

[dralley]

📜 Checklist

• Commits are cleanly separated and have useful messages
• A changelog entry or entries has been added to CHANGELOG.md
• Documentation is thorough
• Test coverage is excellent and passes
• Works when tests are run --all-features enabled

[dralley]

@DemiMarie I would like to build some nice test RPMs to use (which you are also welcome to use), do you have any recommendations of other things to exercise? e.g.

• symlinks
• patches
• scriptlets
• triggers

Or overall feedback, or if you know of a good set of existing ones that won't cause licensing issues.

[DemiMarie]

Some of the things that should be rejected during parsing:

• INT32_MIN trailer offset
• Dribbles in the main header
• Immutable region is not self-consistent
• Wrong amount of padding (too large or too small)
• Misaligned header tag data entry
• Header tag data entry with count 0
• Header tag data entry count too large
• Tag appears in both signature and main headers
• Too many header tag data entries
• Header too large
• Tag that should only be in the signature header is found in the main header (this was an exploit in the past)
• Header-only signature but neither a header+payload signature nor a payload digest (another exploit)
• Invalid tag (such as the one used by RPM internally for public keys) in the signature or main header
• Tag data entry of wrong type

Some things that I reject but librpm does not:

• Dribbles in the signature header.
• Header tags not sorted
• Padding not zeroed
• i18nstring tag has a length more than the i18ntable
• Weak hash algorithms
• Invalid UTF-8 in a string tag
• Suspicious OpenPGP signature
• Non-ASCII string in the signature header

Things that rpm-oxide should reject:

• Inconsistent fsverity or IMA signatures (invalid base64, largest one too big, etc)

A simple way to implement this would be to use rpm-oxide for parsing; its API should be able to handle all of this.

[dralley]

I was thinking more about the happy path at the moment. Basically - assuming the file is well constructed, how should I exercise as much surface area as possible in terms of parsing and then querying information about the package.

It will make sense to test invalid packages too but it's not my immediate focus.

[DemiMarie]

That makes sense. rpm-oxide was initially written to make sure that invalid packages cannot exploit a potentially-vulnerable version of RPM, so rejecting invalid packages was the single highest priority. As a result, it follows the “when in doubt, error out” approach, with large-scale testing on entire repositories used to ensure that it really does accept valid packages. On the other hand, rpm-oxide does not implement package building or installation, as that is simply out of scope for it. From my perspective, it would make sense for rpm-rs to use rpm-oxide for parsing and cryptographic tasks, while implementing a higher-level API itself. rpm-oxide does require librpm for cryptography but I am happy to make that configurable via a trait.

As far as package installation is concerned, I suspect the three trickiest parts are likely to be Lua scriptlets, chroot, and dependency solving, but I have never implemented this code myself so I have no idea. You would be better off asking the rpm-ostree developers, as they have (or in the case of Lua scriptlets, need to) implement this. This would also be a very good opportunity for cooperation.

[dralley]

Well rpm-rs doesn't (and might not ever) handle package installation, because that would involve working with the system rpmdb, which is a lot more scope given that details may differ between operating systems and across long timeframes. I think it actually makes a lot of sense to just use bindings to librpm in that case.

Anyway, to the original question, we don't need to be concerned with e.g. running scriptlets or doing dependency solving (etc.), but we do want to produce and parse packages with scriptlets or %ghost files or %config or %defattr or patches or different kinds of signatures or all different kinds of dependencies ... (etc.) So along those lines, any ideas of what to add to the spec file and tests?

[dralley]

@drahnr This is ready for a review pass. It could be merged as-is but I think I would like to address a few of the things I called out in comments first. Also open to feedback on the questions I asked

[drahnr]

I just rebased your PR in bernhard-foo.

[dralley]

@drahnr Could you just git revert a408803b13 and push that? It should still be in your local git history

[drahnr]

bernhard-bar

[dralley]

To add a bit more specificity to what was going wrong earlier,

without the "mkdir" it yields an error "No such file or directory" if there is a trailing slash, or "Not a directory" if there is not. With the "mkdir" it succeeds but the symlink is placed inside of "symlink_dir" instead of at that path.

I still find this confusing, because when I create that symlink manually without "mkdir" it works fine. Only inside of rpm does it seem to fail. 🤷

[drahnr]

Could you add that as an information nugget, it will be lost if it's only in the PR

[dralley]

I've cleaned up the commits a bit and made some adjustments to the specfiles. There are a few other simple cleanups as well but nothing significant.