This sets the stage for more advanced signature management. (Also, talking to GPG over pipes sucks.) Previously we were spawning gpgv2 with a bunch of --keyring options for /usr/share/ostree/trusted.gpg.d/ and whatever other keyring files were explicitly added. GPGME has no public API for multiple keyrings, so we work around the issue by setting up a temp directory to serve as a fake "home" directory for the crypto engine and then concatenate all the keyring files into a single public keyring (pubring.gpg). Unfortunately at present we do this on every signature verification. There's a desire to cache this concatenation, but the problem is the user may be unprivileged. So it seems the cache would have to be per user under $XDG_CACHE_HOME, which OSTree doesn't otherwise use. I'm open to suggestions. We do at least clean up the temp directory when finished, and I have further API changes planned to OstreeGpgVerifier to help mitigate the performance impact.
OSTree is a tool for managing bootable, immutable, versioned filesystem trees. While it takes over some of the roles of tradtional "package managers" like dpkg and rpm, it is not a package system; nor is it a tool for managing full disk images. Instead, it sits between those levels, offering a blend of the advantages (and disadvantages) of both.
For more information, see:
https://live.gnome.org/Projects/OSTree
Submitting patches
You can:
- Send mail to ostree-list@gnome.org, with the patch attached
- Submit a pull request against https://github.com/GNOME/ostree
- Attach them to https://bugzilla.gnome.org/
Please look at "git log" and match the commit log style.
Running the test suite
Currently, ostree uses https://wiki.gnome.org/GnomeGoals/InstalledTests To run just ostree's tests:
./configure ... --enable-installed-tests
gnome-desktop-testing-runner -p 0 ostree/
Coding style
Indentation is GNU. Files should start with the appropriate mode lines.
Use GCC __attribute__((cleanup))
wherever possible. If interacting
with a third party library, try defining local cleanup macros.
Use GError and GCancellable where appropriate.
Prefer returning gboolean
to signal success/failure, and have output
values as parameters.
Prefer linear control flow inside functions (aside from standard
loops). In other words, avoid "early exits" or use of goto
besides
goto out;
.
This is an example of an "early exit":
static gboolean
myfunc (...)
{
gboolean ret = FALSE;
/* some code */
/* some more code */
if (condition)
return FALSE;
/* some more code */
ret = TRUE;
out:
return ret;
}
If you must shortcut, use:
if (condition)
{
ret = TRUE;
goto out;
}
A consequence of this restriction is that you are encouraged to avoid deep nesting of loops or conditionals. Create internal static helper functions, particularly inside loops. For example, rather than:
while (condition)
{
/* some code */
if (condition)
{
for (i = 0; i < somevalue; i++)
{
if (condition)
{
/* deeply nested code */
}
/* more nested code */
}
}
}
Instead do this:
static gboolean
helperfunc (..., GError **error)
{
if (condition)
{
/* deeply nested code */
}
/* more nested code */
return ret;
}
while (condition)
{
/* some code */
if (!condition)
continue;
for (i = 0; i < somevalue; i++)
{
if (!helperfunc (..., i, error))
goto out;
}
}