go1.22.11 (released 2025-01-16) includes security fixes to the crypto/x509 and
net/http packages, as well as bug fixes to the runtime. See the Go 1.22.11
milestone on our issue tracker for details.
- https://github.com/golang/go/issues?q=milestone%3AGo1.22.11+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.22.10...go1.22.11
Hello gophers,
We have just released Go versions 1.23.5 and 1.22.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- crypto/x509: usage of IPv6 zone IDs can bypass URI name constraints
A certificate with a URI which has a IPv6 address with a zone ID may
incorrectly satisfy a URI name constraint that applies to the certificate
chain.
Certificates containing URIs are not permitted in the web PKI, so this
only affects users of private PKIs which make use of URIs.
Thanks to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2024-45341 and Go issue https://go.dev/issue/71156.
- net/http: sensitive headers incorrectly sent after cross-domain redirect
The HTTP client drops sensitive headers after following a cross-domain redirect.
For example, a request to a.com/ containing an Authorization header which is
redirected to b.com/ will not send that header to b.com.
In the event that the client received a subsequent same-domain redirect, however,
the sensitive headers would be restored. For example, a chain of redirects from
a.com/, to b.com/1, and finally to b.com/2 would incorrectly send the Authorization
header to b.com/2.
Thanks to Kyle Seely for reporting this issue.
This is CVE-2024-45336 and Go issue https://go.dev/issue/70530.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Compiling with Go >= 1.22 on arm/v6 is failing with the following error
message:
27.84 gcc_libinit.c:44:8: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0 bytes) [-Werror,-Watomic-alignment]
For these Go versions, we need to manually link to libatomic as arm/v6
does not support atomic intrinsics and neither the CGo, nor the C
toolchain automatically link to that library.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
- Bump golang.org/x/sys from 0.17.0 to 0.20.0
- Bump github.com/stretchr/testify from 1.8.4 to 1.9.0
- Added missing constant to sys_unsupported.go to avoid breaking builds on non-Windows platforms.
full diff: https://github.com/danieljoos/wincred/compare/v1.2.1...v1.2.2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
secret_item_get_secret() may return null if an item is locked or not loaded.
While we set SECRET_SEARCH_LOAD_SECRETS and SECRET_SEARCH_UNLOCK, there may
still be locked items, for example the user may refuse the unlock request.
So we still need to check if the secret data is NULL before we can try to
reference it.
Signed-off-by: Moritz "WanzenBug" Wanzenböck <moritz@wanzenbug.xyz>
Secretservice entries have a "label". This is intended to be a
human-readable description. It's actually called "Description" in UIs
like seahorse, and the listing of existing secrets shows this as a name
for each one.
The entries stored by the credential helper set this to simply the
repository URL. This is rather unfriendly, since entries like
"gitlab.com" and "index.docker.io/v1" show up. Mixed in with
entries from all other applications, it's hard to figure out what
application owns each entry.
This commit changes the label used when saving entries to be something
human-readable (this is the intent of the "label" field, btw). Because
of the naming scheme, this also results in all entries being shown
together by default (since UIs tend to sort lexicographically).
New entries will now be stores as:
Registry credentials for $REGISTRY_URL
Note that items stored by the secret service have multiple fields inside
of them. One of those fields is called "label", and is used by the
helper to filter items from the secret service. This "label" field is
entirely unrelated to the items' label. The naming is most unfortunate.
Signed-off-by: Hugo Osvaldo Barrera <hugo@barrera.io>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Both NewShellProgramFunc and NewShellProgramFuncWithEnv were using
createProgramCmdRedirectErr under the hood, but NewShellProgramFunc
had an extra indirection through NewShellProgramFuncWithEnv.
Make both a direct wrapper for createProgramCmdRedirectErr instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While the implementation of these is fairly trivial, we want them
to remain the same. This patch adds utilities to handle the encoding
and decoding of the server-URLs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 2fc2313bb1 changed the errors returned
by the pass credentials-helper to use a errCredentialsNotFound. This error
string is used in the client to distinguish a "not found" error from other
errors. (see [client.Get][1]).
However, there were additional second code-paths that returned a custom error,
which would not be detected as a "not found" error, resulting in an error when
logging out;
Removing login credentials for https://index.docker.io/v1/
WARNING: could not erase credentials:
https://index.docker.io/v1/: error erasing credentials - err: exit status 1, out: `error getting credentials - err: exit status 1, out: `no usernames for https://index.docker.io/v1/``
This patch:
- updates Pass.Get() to return a errCredentialsNotFound if no credentials
were found
- updates Pass.List() to not return an error if any of the domains had no
credentials stored.
[1]: https://github.com/docker/docker-credential-helpers/blob/73b9e5d51f8dc9f598e08a0f2171c5d5a828e76b/client/client.go#L51-L55
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sebastiaan van Stijn