My goal in building ostree for Debian unstable was that we would
have good coverage of "new code" paths. However, it was removed
for #571 as too much of a moving target. Debian testing is less of
a moving target, and in particular is always internally consistent
(packages are co-installable), which Debian unstable is not guaranteed
to be.
Debian 'stretch' is the future Debian 9, which should be released
next year.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Closes: #600
Approved by: cgwalters
Documentation and similar files are stripped from this image, making
it quicker to install.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Closes: #600
Approved by: cgwalters
This reduces the diff when comparing these scripts with similar glue
in dbus or elsewhere.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Closes: #600
Approved by: cgwalters
This is deliberately permissive: a lot of it is generic, and I'm
using similar scripts in dbus.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Closes: #600
Approved by: cgwalters
Otherwise, we'll fail (due to set -u) if this parameter variable isn't
passed.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Closes: #600
Approved by: cgwalters
This is necessary for "make distcheck" on Travis-CI.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Closes: #600
Approved by: cgwalters
glnx_make_lock_file requires that the dfd passed in survives the
lifetime of the lock. Since dfd_iter.fd gets cleaned up after the
function returns, this isn't the case. dfd_iter.fd should be equivalent
to tmpdir_dfd, since we iter on ".", and that survives past the
function, so just use that instead.
Closes: #591
Approved by: cgwalters
I find myself often wanting to debug interactively failing tests.
This makes it more convenient to keep around the temporary directories
just for those tests, rather than accumulating tons of tempdirs from
the successful tests as well.
Closes: #588
Approved by: jlebon
The fact that we weren't doing this is at best an oversight, and
for some deployment models a security vulnerability. Having both
`gpg-verify` and `gpg-verify-summary` shows that we were intending
them to be orthogonal/independent.
Lately I've been advocating moving towards pinned TLS instead of
gpg-signed summaries, and if we follow that path, performing GPG
verification of commit objects even if using deltas is more important,
as it provides an at-rest verifiable authenticity and integrity
mechanism.
Content providers which are signing their summary files and/or using
TLS (particularly pinned TLS) for transport should treat this as a
nice-to-have. However, for providers which are serving content over
plain HTTP and relying on GPG, this is a critical update.
Closes: https://github.com/ostreedev/ostree/issues/517Closes: #589
Approved by: jlebon
- d/p/dist/Retrieve-some-missing-test-files-from-upstream-git.patch:
remove, 2016.13 was released with a fixed "make dist"
- d/p/Filter-bootloader-supplied-kernel-cmdline-options.patch:
remove, merged upstream
`-fsanitize=address` complained that the `refcount > 0` assertions
were reading without atomics. We can fix this by reworking them
to read the previous value.
Closes: #582
Approved by: jlebon
It turns out this is basically racy with the presence of other
threads. It was really cosmetic so let's stop doing it and make
`-fsanitize=thread` happy.
Closes: #582
Approved by: jlebon
This is actually fine in practice, but it triggers this
`-fsanitize=undefined` warning I saw in the test suite log:
```
src/libostree/ostree-repo-static-delta-compilation.c:160:10: runtime error: null pointer passed as argument 1, which is declared to never be null
```
Closes: #584
Approved by: jlebon
You'd expect
ostree commit --tree=ref=A --tree=ref=B
to produce a commit with the union of the trees given. Instead you'd get
a commit with the contents of just the latter commit. This was due to an
optimisation where we'd skip filling out the `files` and `subdirs`
members of the mtree, just filling in the metadata instead. This backfires
becuase this same code relies on checking the `files` and `subdirs` members
itself to work out whether the mtree is empty.
This commit removes the optimisation, fixing the bug. Maybe there's a way
to keep the optimisation and still fix the bug but it's not obvious to
me.
Closes: #581
Approved by: cgwalters
Conceptually we've been moving towards having our GPG verification
paths be per-remote. The code internally supports this, but we
didn't expose an API to use it conveniently.
This came up when trying to add a new `gpgkeypath` option, since
right now rpm-ostree manually finds keyrings for the remote, and
hence it wasn't looking at the keypath, and said "Unknown key"
in status.
Adding an API fixes this nicely.
Closes: #576
Approved by: giuseppe