OSTree's code for testing predates the `glib-tap.mk` making its
way into GLib. Let's switch to it, as it provides a number
of advantages.
By far the biggest advantage is that `make check` can start to run
most of the tests *in addition* to having them work installed.
This commit keeps the installed tests working, but `make check` turns
out to be really broken because...our TAP usage has bitrotted to say
the least. Fix that all up.
Do some hacks so that the tests work uninstalled as well - in
particular, `glib-tap.mk` and the bits encoded into
`g_test_build_filename()` assume *recursive* Automake (blah). Work
around that by creating a symlink when installed to loop back.
I noticed in the static deltas tests, there were some tests that
should have been under `-o pipefail` to ensure we properly propagate
errors.
There were a few places where we were referencing undefined variables.
Overall, this is clearly a good idea IMO.
If fetching GPG-signed commits over plain HTTP, a MitM attacker can
fill up the drive of targets by simply returning an enormous stream
for the commit object.
Related to this, an attacker can also cause OSTree to perform large
memory allocations by returning enormous GVariants in the metadata.
This helps close that attack by limiting all metadata objects to 10
MiB, so the initial fetch will be truncated.
But now the attack is only slightly more difficult as the attacker
will have to return a correctly formed commit object, then return a
large stream of < 10 MiB dirmeta/dirtree objects.
https://bugzilla.gnome.org/show_bug.cgi?id=725921
Colin Walters
Giuseppe Scrivano