We received reports from users no longer being able to clone Git
repositories using libgit2 because of errors during the cloning
attempt: `error: Failed to authenticate SSH session: Unable to extract
public key from private key.`
After an extensive scavenger hunt I was able to pinpoint the issue to
`libssh2` being linked against `libgcrypt` instead of `openssl`. The
problem with this is that the libgcrypt backend in libssh2 contains
a hand written slimmed down ASN.1 parser to read out keys, while the
OpenSSL backend in libssh2 uses OpenSSL, which supports a lot more
formats (and more specifically, most PKCS* formats).
As Debian's bullseye/testing repository has been frozen, and a
backport has not been made available yet, fetching the dependency from
"unstable" seems to be the best option for now, as this has `libssh2`
available including OpenSSL.
Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668271
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit changes the base image for the build and controller
container images to Debian slim.
Reason for this is that it has proven to be hard to produce working
executables for AMD64, ARM64 and ARMv7 at all times using Alpine,
due to them being dynamically linked and compiled using CGO, and
Alpine having constraints like musl that create an extra barrier,
especially in combination with our exotic set of dependency
constraints.
There are a number of trade-offs we have to live with by doing this,
not limited to:
* An increased build time, the full release pipeline used to take 25-35
minutes, based on the images we have build for testing purposes this
seems to have become 35-40 minutes.
* An increased image size of roughly two times the (compressed) size of
the Alpine based image.
Signed-off-by: Hidde Beydals <hello@hidde.co>
There seems to have been a change in the dependencies that now causes
ARMv7 builds to fail:
```
sigs.k8s.io/kustomize/kyaml/yaml/merge3=$WORK/b742/_pkg_.a
sigs.k8s.io/kustomize/kyaml/yaml/internal/k8sgen/pkg/util/errors=$WORK/b678/_pkg_.a
-importcfg $WORK/b001/importcfg.link -buildmode=exe
-buildid=YHfd11eGufJ7RVGSGz2z/H9JgY3lbjsdhQ8_r06Gz/HiYQEtSgCAIHJ7rrNYN6/YHfd11eGufJ7RVGSGz2z
-extld=gcc $WORK/b001/_pkg_.a
exit status 1
-c CGO_ENABLED=1 go build -x -o source-controller main.go]: exit
code: 2
```
After trying various things, including downgrading Go, using
packages from `edge`, using `gcc-go` to get a "grouped" version of
the dependencies, it seems that using `binutils-gold` solves the issue
and produces a working build for all our target architectures.
Signed-off-by: Hidde Beydals <hello@hidde.co>
This commit updates Go to 1.16, a required change because of the use of
`os.WriteFile` in one of the tests introduced by commit
b5004a93bc.
Normally _just_ this would not justify the change, but given the
introduction of breaking changes (and thereby forcing a MINOR update
anyway), and the various file{system, path} improvements introduced in
Go 1.16 like
[`filepath#WalkDir`](https://golang.org/pkg/path/filepath/#WalkDir),
going ahead with this should be fine.
Signed-off-by: Hidde Beydals <hello@hidde.co>
* Use semver tidles to deal with future patch releases
* Install just `libgit2` in runtime container
* Add TODO / explanation for `musl` `1.2.x` dependency
Signed-off-by: Hidde Beydals <hello@hidde.co>
As other controllers depend on source-controller because of the API
package, but this pulls in obsolete dependencies for the controllers.
By publishing the API package as a dedicated module while
using a (local) replace for the project itself, this should be
prevented.
Hidde Beydals
Stefan Prodan
Philip Laine
Philip Laine