Bug 207567

Summary:	Go package for libcap is not "go get"-able and not a module
Product:	Tools	Reporter:	thediveo
Component:	libcap	Assignee:	Andrew G. Morgan (morgan)
Status:	RESOLVED CODE_FIX
Severity:	enhancement	CC:	kernel, morgan
Priority:	P4
Hardware:	All
OS:	Linux
Kernel Version:	5.3.0	Subsystem:
Regression:	No	Bisected commit-id:

Description thediveo 2020-05-03 21:01:56 UTC

1. As of libcap 2.33 its Go package cannot be automatically be fetched and installed as a dependency package, for instance using "go get ...".

To be "go get"-able only the Go package needs to be downloadable via a go-supported vcs protocol, especially git. At this time, libcap 2.33 cannot be downloaded in this way, as it lacks some Go files which are only generated on the fly. This forces potential user of the package through a complex and error-prone building and vendoring process. Worse, it basically prohibits CI, so no automated build and tests of Go software which wants to import the libcap Go package.

Please provide a libcap Go package this is go getable and can be directly imported into other projects without the need to build a local package with complex integration and vendoring needs.

2. As of libcap 2.33 its Go package has no module support (i.e., go.mod and go.sum). Module support is available since Go 1.11 and has officially fully landed in Go 1.12. A the time of writing, Go 1.14.x is GRA.

Please provide a Go module-enabled version of a go getable libcap package.

Comment 1 Andrew G. Morgan 2020-05-03 22:04:12 UTC

As of the present time, the way the packages are built is dependent on whether or not you are running a golang build with or without https://go-review.googlesource.com/c/go/+/210639/ applied (ie., with cgo-less support for capabilities).

I don't plan to pursue go get support until I have an official golang version number to key this kind of build dependency off.

If anyone wants to offer a patch, we can see where that gets us.

Comment 2 Andrew G. Morgan 2020-07-02 23:58:04 UTC

I'm exploring support for this. It looks as if my Go runtime patch (see Comment 1) is not to being included in go1.15, so I'm exploring other ways to conditionally build the non-CGo support - likely a dev build tag or somesuch.

As a first step, I'm going to attempt to modularize the CGo "psx" package. This is mt first commit towards that effort:

   https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=a3e844af8976dc7397f272eade1bb609050220eb

Plenty of unknowns for me in this effort.

Comment 3 Andrew G. Morgan 2020-07-04 02:13:39 UTC

Numerous attempts later. This should be fixed in libcap-2.37. Go module release v0.2.37.

The official import paths for the "cap" and the "psx" packages are:

    "kernel.org/pub/linux/libs/security/libcap/cap"
    "kernel.org/pub/linux/libs/security/libcap/psx"

Note, for go build tools prior to go1.15beta1, you will need to manually supply:

    export CGO_LDFLAGS_ALLOW="-Wl,-?-wrap[=,][^-.@][^,]*"

To be able to build the "psx" package, which is needed for the "cap" package since Go does not yet include this patch:

    https://go-review.googlesource.com/c/go/+/210639

or anything equivalent to it. If you want to explore building with a Go toolchain including that patch, please report issues or success via:

    https://github.com/golang/go/issues/1435

Building the "cap" package against such a Go toolchain currently requires

    CGO_ENABLE=0 go build -tags allthreadssyscall ...

to coax the "cap" package into not requiring CGo.