brl fetch should eventually cryptographically verify the software it is bootstrapping. As preliminary research for this effort, we'll need to populate the information in the table below.
Feel free to comment with additional information and I'll update the table accordingly.
The fields are:
distro: self explanatory
bootstrap resource: whatever it is brl fetch grabs directly which we'll need to verify. This includes things like packages, tarballs, and ISO9660 files. The reason we need to know this is that different public keys might be used to verify different things. ISOs might use a different key from packages, for example.
public key location: we need some public key to bootstrap the process. Where do we find it? This could be a project website that hosts it, or a distro provided package that contains it.
key update method: I don't want to have to roll out brl updates every time any distro updates its keys. We'll need to have brl fetch be able to use existing keys to grab new ones. How do we do this?
portable resource validation method: how do we actually use the key to validate the resource, particularly when we don't have any of the distro-specific tooling (yet).
brl fetch
should eventually cryptographically verify the software it is bootstrapping. As preliminary research for this effort, we'll need to populate the information in the table below.Feel free to comment with additional information and I'll update the table accordingly.
The fields are:
brl fetch
grabs directly which we'll need to verify. This includes things like packages, tarballs, and ISO9660 files. The reason we need to know this is that different public keys might be used to verify different things. ISOs might use a different key from packages, for example.brl update
s every time any distro updates its keys. We'll need to havebrl fetch
be able to use existing keys to grab new ones. How do we do this?centos-pkg-keys
packagefedora-pkg-keys
package