plugin hook to verify rpms

[JanZerebecki]

For end-to-end supply chain integrity before a download returns as successful, zypper should verify that some rebuilders attested with their signature that they could reproduce the to be downloaded rpms.

As the transport and format are not settled, my idea was to use a plugin hook, so that zypper does not need to be released for trying different implementations. AFAIK none of the currently available hooks work for this. As the transport could be complex like Certificate Transparency the plugin must take on the task of downloading the necessary signatures. As verification could be complex (like in in-toto-verify) verification and its configuration must be the task of the plugin.

Detached signature support in rpm is a related feature request of rpm. Until that is supported, a temporary copy of the rpm with the original signature replaced with the reproducer signature could be used to verify.

Requirements for the hook:

• run before downloaded rpms are returned or stored to be used
• run also before using cached downloads
• as input have list of
  • one or more hash-algorithm and hash of the file taken from the repo index (this is the only piece of information necessary to find the signatures, the others are just for flexibility; and the only one that is unique as all the others could in certain cases identify different file content under the same name, e.g. when reproducing the build has a chance to produce a different output)
  • repository
  • file
  • package name
  • arch
  • version
• as output zero or more of the files that passed verification
• zypper must not make use of any file that did not pass verification
• run plugin to clear cache of downloaded signatures when cached rpms get cleared (do we need finer granularity to only prune some cached entries?)
• batching is probably useful for parallel download of signatures
• it might be useful to additionally run the plugin earlier while omitting the file from the input to give the plugin the chance to already have the signatures cached by the time the verification is asked for

The configuration of the implemented plugin will likely have (though there are more complex configurations that make sense)

• list of rebuilders with
  • https url prefix where to find its signatures
  • fingerprint
• threshold of required signatures

[JanZerebecki]

(edit: add hash-algorithm and hash as input for hook)

[mlandres]

Well, rebuilders may attest this by signing their metadata. In this case strong digests within the signed metadata secure the contained packages. We're about to provide a similar hook, but for externally verifying the repo metadata themselves. ATM this seems to be the more efficient and reasonable approach, so we focus on this.

A package based approach is doable, but currently has no priority for the team.

[msmeissn]

yes i also think this is at the wrong place of abstraction layers to do it at libzypp level.

[JanZerebecki]

We're about to provide a similar hook, but for externally verifying the repo metadata themselves. ATM this seems to be the more efficient and reasonable approach, so we focus on this.

My proposed requirements for a hook also allow for verifying the repo metadata as a whole.

Compared to a hook that also allows to verify a subset of packages because it has the information which package are going to be used this has the following consequences:

• Prevents incremental improvements. Thus if you still have one package non-reproducible that is inherited from SP0, you can never verify anything.
• Makes any partial failure, into a full failure. One temporary failure makes the whole zypper repo unavailable. E.g. if everything worked before, but just one package now temporarily fails (which we do not want to completely prevent for performance reasons) the whole repo is now offline. Thus this may delay important security fixes that are unrelated to the failing package.
• Enforces head of line blocking. While there is some inherent constraint on package verification order due to the dependency tree, now it is strictly ordered in a list. E.g. a new Libreoffice taking hours to build can now block the verification of the ssh package.
• You need to publish and archive repo meta data for each build step that is not a leaf in the build dependency even if you currently would only batch publish the repo meta data after the OBS project is stable. As for verification the dependencies need to be verified and if you can not do that on a per package level then you need to have a repo to have repo meta data. This also increases the archive size.
• Our mirroring needs to get much more consistent, as we currently have partial temporary failures by inconsistency. But with this these would be full repo failures.
• Requires partial verifiers to publish a subset of the original repo to be able to have zypper make use of them.

Thus, while just the hook would be much simpler the over all complexity is much bigger. It also induces additional requirements. And you can also not have a partial success.

But if we really give enough people the time to work on this as their highest priority task, then I can live with it.

yes i also think this is at the wrong place of abstraction layers to do it at libzypp level.

What is the right place? What is wrong with doing it in libzypp?