Pushed Docker Images to ECR

3.11.7

Fix version pipeline

Build on Bullseye so not to bump GLIBC too high

Test build with bullseye (#61)

* Test build with bullseye

* Install netcat

* Sans sudo

* Auto accept

Bumped Go to 1.20

What's Changed

• Bump to Go 1.20 by @nsmithuk in #57
• Bump golang.org/x/net from 0.2.0 to 0.7.0 by @dependabot in #54

New Contributors

• @dependabot made their first contribution in #54

Full Changelog: 3.12.0...3.11.5

Add KeySpec output when getting pubkey

Thanks to @zacscoding.

Bumped to latest version of Go 1.17

Replace vulnerable satori/go.uuid with gofrs/uuid (#43)

The satori/go.uuid library has a known vulnerability described in
[CVE-2021-3538](https://www.cvedetails.com/cve/CVE-2021-3538/),

> A flaw was found in github.com/satori/go.uuid in versions from commit
> 0ef6afb2f6cdd6cdaeee3885a95099c63f18fc8c to
> d91630c8510268e75203009fe7daf2b8e1d60c45. Due to insecure randomness in the
> g.rand.Read function the generated UUIDs are predictable for an attacker.

and [gofrs/uuid](https://github.com/gofrs/uuid#project-history) is a fork of
satori that was created to fix the vulnerabilities, as the original project
is no longer maintained.

A detail to take into account is that the gofrs forces error handling when UUID
creation fails, which only happens for v4 UUIDs when a random number couldn't be
obtained from the source. This should be a very low percentage and in practice
shouldn't happen (even less for this project as it is something you run locally
or in tests), but nevertheless the error *should* be handled.

As with satori this problem still existed, but it panicked when it failed, to
maintain the behaviour uuid.Must is used, which panics when an error occurs.

Satori panic reference:
[1](https://github.com/satori/go.uuid/blob/v1.2.0/generator.go#L153)
[2](https://github.com/satori/go.uuid/blob/f58768cc1a7a7e77a3bd49e98cdd21419399b6a3/generator.go#L199)

Moved to new package for generating UUIDs

Replace vulnerable satori/go.uuid with gofrs/uuid (#43)

The satori/go.uuid library has a known vulnerability described in
[CVE-2021-3538](https://www.cvedetails.com/cve/CVE-2021-3538/),

> A flaw was found in github.com/satori/go.uuid in versions from commit
> 0ef6afb2f6cdd6cdaeee3885a95099c63f18fc8c to
> d91630c8510268e75203009fe7daf2b8e1d60c45. Due to insecure randomness in the
> g.rand.Read function the generated UUIDs are predictable for an attacker.

and [gofrs/uuid](https://github.com/gofrs/uuid#project-history) is a fork of
satori that was created to fix the vulnerabilities, as the original project
is no longer maintained.

A detail to take into account is that the gofrs forces error handling when UUID
creation fails, which only happens for v4 UUIDs when a random number couldn't be
obtained from the source. This should be a very low percentage and in practice
shouldn't happen (even less for this project as it is something you run locally
or in tests), but nevertheless the error *should* be handled.

As with satori this problem still existed, but it panicked when it failed, to
maintain the behaviour uuid.Must is used, which panics when an error occurs.

Satori panic reference:
[1](https://github.com/satori/go.uuid/blob/v1.2.0/generator.go#L153)
[2](https://github.com/satori/go.uuid/blob/f58768cc1a7a7e77a3bd49e98cdd21419399b6a3/generator.go#L199)

Publish an ARM64 (v8) Docker Image

3.11.1

Ensure tags are pushed

Add KeySpec on Input and Output

Add KeySpec Input and Output (#35)

* Amended tests to check for KeySpec amend

* One extra check

* Added KeySpec naming

And moved to use it as the main record of the selected key spec.

* Output KeySpec in logging

Build Docker images for tag

3.10.1

Push Docker images on tag

Added ECC_SECG_P256K1 support

And moved to Go 1.17.