rpm-ostree

History

Jonathan Lebon b68209b6d4 daemon: start with one commit only when resolving versions During a deploy operation, we would fetch commit objects from the remote to resolve the version string. If gpg-verify was turned on, we would fail to pull them if some of the commits were not signed. This is because we pulled them in batches. We partially address this by only fetching the HEAD commit on the first pass. This allows `upgrade` operations to work just as well as `deploy` operations. Though there is still an issue if we have to traverse farther back than when signed commits become unsigned (unless they happen to fall on a batch boundary). We leave that unsolved for now, since that would likely require a more complex solution and it's not clear whether it's a real world issue (signers can just retroactively sign commits). Copy the gpghome from ostree so that we can test GPG-related cases in our suite. Closes: #527 Closes: #557 Approved by: cgwalters	2016-12-24 12:28:48 +00:00
..
pubring.gpg

Jonathan Lebon b68209b6d4 daemon: start with one commit only when resolving versions

During a deploy operation, we would fetch commit objects from the remote
to resolve the version string. If gpg-verify was turned on, we would
fail to pull them if some of the commits were not signed. This is
because we pulled them in batches. We partially address this by only
fetching the HEAD commit on the first pass. This allows `upgrade`
operations to work just as well as `deploy` operations.

Though there is still an issue if we have to traverse farther back than
when signed commits become unsigned (unless they happen to fall on a
batch boundary). We leave that unsolved for now, since that would likely
require a more complex solution and it's not clear whether it's a real
world issue (signers can just retroactively sign commits).

Copy the gpghome from ostree so that we can test GPG-related cases in
our suite.

Closes: #527

Closes: #557
Approved by: cgwalters

2016-12-24 12:28:48 +00:00

pubring.gpg