pass/pass_test.go:86:6: QF1001: could apply De Morgan's law (staticcheck)
if !(strings.HasSuffix(server, "2376/v1") || strings.HasSuffix(server, "2375/v1")) {
^
pass/pass_test.go:89:6: QF1001: could apply De Morgan's law (staticcheck)
if !(username == "foo" || username == "bar") {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prior to v0.9.0, the osxkeychain creds helper was adding the `atyp`
attribute (ie. authentication type) to its credentials. It was also
specifying this attribute when querying the keychain for credentials.
Since v0.9.0, we don't set this attribute anymore. So, if a credential
is stored with v0.9.0+ and then queried with a v0.8.2 helper, the
atyp attribute will be missing and the credential won't be found.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Commit 4cdcdc2 changed the format of `list` output. Before that commit,
the json keys were containing full URIs (scheme://host/path[:port]),
but afterward, the keys were only containing the path component.
With this commit, the `list` operation now returns full URIs (fixing the
regression), and also fixes the malformed URIs issue when a port is
specified (introduced by 19ec1c3, and affecting >=v0.4.2,<v0.9.0).
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
`osxkeychain` in v0.9.1 still doesn't list credentials as prior versions
did. We're retracting this version too.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Commit 4cdcdc2 introduced two regressions in the `osxkeychain`
credential helper, on `list` and `get` operations. These were addressed
in:
- Commit c7514a0: osxkeychain: list: do not error out when keychain is empty
- Commit f4cdabf: osxkeychain: store: use Apple's proto consts
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Commit 4cdcdc2 swapped consts `kSecProtocolTypeHTTPS` and
`kSecProtocolTypeHTTP` with plain-text "https" and "http" strings.
This is causing a regression where credentials stored with prior
versions (< v0.9.0) can't be fetched anymore.
Unfortunately we can't just revert back to using Objective-C consts, as
these are unsigned integers that need to be converted into `CFStringRef`
and then passed to an helper like `keychain.CFStringToString`.
Although `keychain.CFStringToString` is exported, it takes a C type
`C.CFStringRef` so it's not consumable from other packages due to Cgo
restrictions:
> Cgo translates C types into equivalent unexported Go types. Because
> the translations are unexported, a Go package should not expose C
> types in its exported API: a C type used in one Go package is
> different from the same C type used in another.
We could alternatively copy `keychain.CFStringToString` into the
`osxkeychain` package, but this commit takes a simpler approach: just
hardcode the value of `kSecProtocolTypeHTTPS` and `kSecProtocolTypeHTTP`
as strings. (These consts are very unlikely to ever change since it'd
break all existing consumers.)
This is **NOT** handling backward compatibility with v0.9.0, since it
was released only 12hrs ago. So this fix won't work with credentials
created with v0.9.0.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Commit 4cdcdc2 replaced the in-tree Objective-C code with github.com/keybase/go-keychain
and inadvertently introduced a new failure mode on the `List` operation -
it now fails when the keychain is empty.
Before:
```
$ ./bin/build/docker-credential-osxkeychain list
{}
```
After:
```
$ ./bin/build/docker-credential-osxkeychain list
credentials not found in native keychain
```
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
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>
Sebastiaan van Stijn