Avoid usage of github.com/mtrmac/gpgme

[hferentschik]

This library only compiles on Linux, since it uses C extensions which won't compile on OS X and Windows. This makes it for example hard/impossible to use image as a library for a cross compiled CLI applications.

Could one not use Go's golang.org/x/crypto/openpgp?

For now I removed github.com/mtrmac/gpgme and commented its use out from mechanism.go. If there is no way to make without C extensions, one can maybe only build them for Linux, whereas for OS X and Windows it particular feature would not be available (not 100% for what it is actually used).

[runcom]

you can use build tag containers_image_openpgp to not use gpgme but getting only a limited signing features, @mtrmac could you chime in here?

[hferentschik]

Yes, I've seen

Optionally, you can use the containers_image_openpgp build tag (using go build -tags …, or make … BUILDTAGS=…). This will use a Golang-only OpenPGP implementation for signature verification instead of the default cgo/gpgme-based implementation;

I have not got this to work yet though. Also from a user point of view it would be nice, if the default would work for all OS types.

That said, there is another problem with:

vendor/github.com/containers/storage/storage/lockfile.go:136: st.Mtim undefined (type syscall.Stat_t has no field or method Mtim)

The call to syscall.Stat_t is OS specific and returns different structs depending on the target OS. I guess that's an issue for storage.

[hferentschik]

containers_image_openpgp tag aside, I still cannot compile this out of the box. mtrmac/gpgme is a defined dependency which gets downloaded into the vendor directory. When I then try to build, I get:

# github.com/containers/image/vendor/github.com/mtrmac/gpgme
vendor/github.com/mtrmac/gpgme/data.go:4:11: fatal error: 'gpgme.h' file not found
#include <gpgme.h>
          ^
1 error generated.

# github.com/containers/image/vendor/github.com/containers/storage/storage
vendor/github.com/containers/storage/storage/lockfile.go:136: st.Mtim undefined (type syscall.Stat_t has no field or method Mtim)
vendor/github.com/containers/storage/storage/lockfile.go:136: not enough arguments in call to time.Unix

So even if containers/image has some build tags to avoid the usage of gpgme, gpgme will cause compilation errors.

The second error is the mentioned system specific call to syscall.Stat_t in containers/storage.

[mtrmac]

Also from a user point of view it would be nice, if the default would work for all OS types.

The openpgp backend is limited (verification only, no signing), so there are two dimensions of “work” which may be in conflict.

Though, AFAICT, the situation for macOS and Linux is pretty much the same: GPGME development libraries have to be installed. In neither it is a part of the mandatory base system, so it may need to be installed by the user. I suppose with Linux it may be a little easier when using a container to isolate a prepared build environment, but then a container runtime is not a part of the mandatory base system either…

[mtrmac]

containers_image_openpgp tag aside, I still cannot compile this out of the box. mtrmac/gpgme is a defined dependency which gets downloaded into the vendor directory. When I then try to build, I get:

# github.com/containers/image/vendor/github.com/mtrmac/gpgme
vendor/github.com/mtrmac/gpgme/data.go:4:11: fatal error: 'gpgme.h' file not found
#include <gpgme.h>
          ^
1 error generated.

What exact command are you using to build this? This should only happen when the build tag is not present. (Alternatively, install a GPGME development library + headers, via brew or whatever cgo can find.)

# github.com/containers/image/vendor/github.com/containers/storage/storage
vendor/github.com/containers/storage/storage/lockfile.go:136: st.Mtim undefined (type syscall.Stat_t has no field or method Mtim)
vendor/github.com/containers/storage/storage/lockfile.go:136: not enough arguments in call to time.Unix

This is the same thing as containers/skopeo#310 , where the supposed fix containers/skopeo#331 lacks a macOS tester. Could you verify that PR works, please? If it does, we can update the vendored version in this repo similarly.

[hferentschik]

What exact command are you using to build this? This should only happen when the build tag is not present

Let me double check

This is the same thing as containers/skopeo#310 , where the supposed fix containers/skopeo#331 lacks a macOS tester. Could you verify that PR works, please?

Will do. Btw, I really would need this to cross compile to Windows as well.

[hferentschik]

So there is the thing. If I do:

$ make vendor
$ go build -tags="containers_image_openpgp" ./...
# github.com/containers/image/vendor/github.com/containers/storage/storage
vendor/github.com/containers/storage/storage/lockfile.go:136: st.Mtim undefined (type     syscall.Stat_t has no field or method Mtim)
vendor/github.com/containers/storage/storage/lockfile.go:136: not enough arguments in call to time.Unix
# github.com/containers/image/vendor/github.com/mtrmac/
vendor/github.com/mtrmac/gpgme/data.go:4:11: fatal error: 'gpgme.h' file not found
#include <gpgme.h>
      ^
1 error generated.

If I then manually delete the mtrmac:

$ rm -rf vendor/github.com/mtrmac/gpgme
$ go build -tags="containers_image_openpgp" ./...
# github.com/containers/image/vendor/github.com/containers/storage/storage
vendor/github.com/containers/storage/storage/lockfile.go:136: st.Mtim undefined (type syscall.Stat_t has no field or method Mtim)
vendor/github.com/containers/storage/storage/lockfile.go:136: not enough arguments in call to time.Unix

storage issue aside, if I don't want to use gpgme, I not only have to specify the containers_image_openpgp tag, but I also need to make sure not to get the gpgme dependency. Using make vendor I will get it per default though. So at the very least this needs to be documented.

In the REAMDE it says regarding gpgme:

the primary downside is that creating new signatures with the Golang-only implementation is not supported.

So where is that really an issue. What is the use case for creating signatures?

[hferentschik]

Updating to the latest version of storage by adding:

github.com/containers/storage d10d8680af74070b362637408a7fe28c4b1f1eff
github.com/tchap/go-patricia/patricia v2.2.6
github.com/opencontainers/selinux ba1aefe8057f1d0cfb8e88d0ec1dc85925ef987d

to vendor.conf, gets me past compilation errors.

[mtrmac]

If I then manually delete the mtrmac:

Good catch, ./... includes all of the vendor subdirectory. That documentation needs to be fixed.

Also thanks for testing the storage update. I’ll work on on the necessary updates.

What is the use case for creating signatures?

Well, a signature has to exist in order to be verifiable :) If you mean that your intended use of containers/image does not involve signing container images, sure, that’s not inherently required. Much of the library does not actually require the containers/image/signature subpackage and can be used completely independently (but the full copy.Image pipeline does depend on the signature subpackage).

[rhatdan]

@hferentschik @mtrmac @vrothberg I believe this is fixed, Closing. Reopen if I am mistaken.

[mtrmac]

Yes, this was fixed by #271 and #272.