Commit Graph

6 Commits

Author SHA1 Message Date
Colin Walters f81e3c6f03 lib/commit: Use more direct path for regfile commits
In the non-`CONSUME` path for regfiles (which happens currently for
`bare-user`), we go to a lot of contortions to make an "object stream",
only to immediately parse it again.

Fixing this will also enable the `G_IS_FILE_DESCRIPTOR_BASED()` fast path in
commit, since the input stream will actually reference the file descriptor and
not be an `_OstreeChainInputStream`.

There's a slight concern here in that we're no longer checksumming *literally*
the object stream passed in for the stream case, but I mention in the comment,
the data should be the same, and if it's not somehow we're not adding risk,
since the checksum is still covering the data we actually care about.

Prep for further changes to break up the `write_content_object()` path into
separate paths for archive, as well as regfile vs symlink in non-archive.

Closes: #1371
Approved by: jlebon
2017-12-12 14:17:20 +00:00
Colin Walters 1c9975cbd1 lib: Add a lighter weight internal checksum wrapper
The faster (OpenSSL/GnuTLS) code lived in a `GInputStream` wrapper, and that
adds a lot of weight (GObject + vtable calls). Move it into a simple
autoptr-struct wrapper, and use it in the metadata path, so we're
now using the faster checksums there too.

This also drops a malloc there as the new API does hexdigest in place to a
buffer.

Prep for more work in the commit path to avoid `GInputStream` for local file
commits, and ["adopting" files](https://github.com/ostreedev/ostree/pull/1255).

Closes: #1256
Approved by: jlebon
2017-10-10 21:25:40 +00:00
Jussi Laako f91acf5226 Add --with-crypto=gnutls
Introduce support for GnuTLS for computing cryptograpic
hashes, similar to the OpenSSL backend.  A reason to do
this is some distributors want to avoid GPLv3, and GPG
pulls that in.

A possible extension of using GnuTLS would be replacing the GPG signing
with `PKCS#7` signatures and `X.509` keys.

We also support `--with-crypto=openssl`, which has the same effect
as `--with-openssl`, and continues to be supported.

Changes by Colin Walters <walters@verbum.org>:

 - Drop libgcrypt option for now
 - Unify buildsystem on --with-crypto

Link: https://mail.gnome.org/archives/ostree-list/2017-June/msg00002.html

Signed-off-by: Jussi Laako <jussi.laako@linux.intel.com>

Closes: #1189
Approved by: cgwalters
2017-09-25 12:58:54 +00:00
Colin Walters 6e4146a354 tree-wide: Remove Emacs modelines
We added a `.dir-locals.el` in commit: 9a77017d87
There's no need to have it per-file, with that people might think
to add other editors, which is the wrong direction.

Closes: #1206
Approved by: jlebon
2017-09-21 21:38:34 +00:00
Colin Walters df5cbc9be9 core: Support building with OpenSSL for checksums
Add an OpenSSL backend to the checksum input stream, which is where we do a lot
of checksumming (object commit, static deltas).

The raw OpenSSL performance is
[approximately double](https://gist.github.com/cgwalters/169349fd1c06fd4fb4d3a7ce33303222) on
my laptop; not only does OpenSSL have e.g. hand-tuned x86_64 assembly, the
current implementation uses the
[Intel SHA extensions](https://en.wikipedia.org/wiki/Intel_SHA_extensions).

Another reason to do this is I was idly thinking about adding
[Curve25519](https://en.wikipedia.org/wiki/Curve25519) signatures (like e.g.
Alpine does) instead of/in addition to GPG.  The rationale for that is
that GPG is pretty heavyweight, both in code footprint and the simple
fact that EC keys are way smaller.

I didn't benchmark ostree with this; we have bigger performance problems
really like the fact we just malloc way too much.  But, it's a step
in the right direction I think in combination with the libcurl work
where we're linking to openssl anyways.

Closes: #738
Approved by: jlebon
2017-03-20 18:32:40 +00:00
Colin Walters c2f5a999bf lib: Add a private copy of checksum-instream
The current `OstreeChecksumInputStream` is public due to a historical
mistake.  I'd like to add an OpenSSL checksum backend, but that's
harder without breaking this API.

Let's ignore it and create a new private version, so it's easier to do the
GLib/OpenSSL abstraction in one place.

Closes: #738
Approved by: jlebon
2017-03-20 18:32:40 +00:00