golang-go.crypto - Debian Package Tracker

general

source: golang-go.crypto (main)
version: 1:0.25.0-1
maintainer: Debian Go Packaging Team (DMD)
uploaders: Anthony Fok [DMD] – Michael Hudson-Doyle [DMD] – Michael Stapelberg [DMD]
arch: all
std-ver: 4.7.0
VCS: Git (Browse, QA)

versions [more versions can be listed by madison] [old versions available from snapshot.debian.org]

[pool directory]

o-o-stable: 1:0.0~git20181203.505ab14-1
o-o-sec: 1:0.0~git20181203.505ab14-1+deb10u1
oldstable: 1:0.0~git20201221.eec23a3-1
old-bpo: 1:0.0~git20220829.c86fa9a-1~bpo11+1
stable: 1:0.4.0-1
stable-bpo: 1:0.25.0-1~bpo12+1
testing: 1:0.25.0-1
unstable: 1:0.25.0-1
exp: 1:0.36.0-1~exp1

versioned links

1:0.0~git20181203.505ab14-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:0.0~git20181203.505ab14-1+deb10u1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:0.0~git20201221.eec23a3-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:0.0~git20220829.c86fa9a-1~bpo11+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:0.4.0-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:0.25.0-1~bpo12+1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:0.25.0-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1:0.36.0-1~exp1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

golang-golang-x-crypto-dev

action needed

A new upstream version is available: 0.39.0 high

A new upstream version 0.39.0 is available, you should consider packaging it.

Created: 2024-06-06 Last update: 2025-07-12 18:30

The VCS repository is not up to date, push the missing commits. high

vcswatch reports that the current version of the package is not in its VCS.
Either you need to push your commits and/or your tags, or the information about the package's VCS are out of date. A common cause of the latter issue when using the Git VCS is not specifying the correct branch when the packaging is not in the default one (remote HEAD branch), which is usually "master" but can be modified in salsa.debian.org in the project's general settings with the "Default Branch" field). Alternatively the Vcs-Git field in debian/control can contain a "-b <branch-name>" suffix to indicate what branch is used for the Debian packaging.

Created: 2025-02-14 Last update: 2025-07-07 16:03

2 security issues in trixie high

There are 2 open security issues in trixie.

2 important issues:

CVE-2024-45337: Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
CVE-2025-22869: SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

Created: 2024-12-12 Last update: 2025-03-27 15:27

2 security issues in sid high

There are 2 open security issues in sid.

2 important issues:

CVE-2024-45337: Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
CVE-2025-22869: SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

Created: 2024-12-12 Last update: 2025-03-27 15:27

3 low-priority security issues in bookworm low

There are 3 open security issues in bookworm.

3 issues left for the package maintainer to handle:

CVE-2023-48795: (needs triaging) The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.
CVE-2024-45337: (needs triaging) Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
CVE-2025-22869: (needs triaging) SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted.

You can find information about how to handle these issues in the security team's documentation.

Created: 2024-02-10 Last update: 2025-03-27 15:27

debian/patches: 2 patches to forward upstream low

Among the 3 debian patches available in version 1:0.25.0-1 of the package, we noticed the following issues:

2 patches where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update the metadata to document its real status.

Created: 2023-02-26 Last update: 2024-09-02 09:05

Standards version of the package is outdated. wishlist

The package should be updated to follow the last version of Debian Policy (Standards-Version 4.7.2 instead of 4.7.0).

Created: 2025-02-21 Last update: 2025-02-27 13:25

news

[rss feed]

[2025-03-18] Accepted golang-go.crypto 1:0.36.0-1~exp1 (source) into experimental (Santiago Ruano Rincón)
[2025-02-14] Accepted golang-go.crypto 1:0.33.0-1~exp1 (source) into experimental (Santiago Ruano Rincón)
[2024-09-08] Accepted golang-go.crypto 1:0.25.0-1~bpo12+1 (source all) into stable-backports (Debian FTP Masters) (signed by: John Goerzen)
[2024-09-05] golang-go.crypto 1:0.25.0-1 MIGRATED to testing (Debian testing watch)
[2024-09-01] Accepted golang-go.crypto 1:0.25.0-1 (source) into unstable (Anthony Fok)
[2024-08-13] golang-go.crypto 1:0.24.0-2 MIGRATED to testing (Debian testing watch)
[2024-08-10] Accepted golang-go.crypto 1:0.24.0-2 (source) into unstable (Anthony Fok)
[2024-08-04] golang-go.crypto 1:0.24.0-1 MIGRATED to testing (Debian testing watch)
[2024-07-31] Accepted golang-go.crypto 1:0.24.0-1 (source) into unstable (Anthony Fok)
[2024-05-27] golang-go.crypto 1:0.23.0-1 MIGRATED to testing (Debian testing watch)
[2024-05-21] Accepted golang-go.crypto 1:0.23.0-1 (source) into unstable (Anthony Fok)
[2024-05-04] golang-go.crypto 1:0.22.0-1 MIGRATED to testing (Debian testing watch)
[2024-04-26] Accepted golang-go.crypto 1:0.22.0-1 (source) into unstable (Anthony Fok)
[2024-04-09] golang-go.crypto 1:0.21.0-1 MIGRATED to testing (Debian testing watch)
[2024-03-25] Accepted golang-go.crypto 1:0.21.0-1 (source) into unstable (Anthony Fok)
[2024-02-27] golang-go.crypto 1:0.19.0-1 MIGRATED to testing (Debian testing watch)
[2024-02-24] Accepted golang-go.crypto 1:0.19.0-1 (source) into unstable (Anthony Fok)
[2024-02-08] golang-go.crypto 1:0.18.0-1 MIGRATED to testing (Debian testing watch)
[2024-01-29] Accepted golang-go.crypto 1:0.18.0-1 (source) into unstable (Anthony Fok)
[2024-01-17] golang-go.crypto 1:0.17.0-1 MIGRATED to testing (Debian testing watch)
[2024-01-07] Accepted golang-go.crypto 1:0.17.0-1 (source) into unstable (Anthony Fok)
[2023-12-11] golang-go.crypto 1:0.16.0-1 MIGRATED to testing (Debian testing watch)
[2023-12-07] Accepted golang-go.crypto 1:0.16.0-1 (source) into unstable (Anthony Fok)
[2023-11-05] golang-go.crypto 1:0.14.0-1 MIGRATED to testing (Debian testing watch)
[2023-11-05] golang-go.crypto 1:0.14.0-1 MIGRATED to testing (Debian testing watch)
[2023-11-01] Accepted golang-go.crypto 1:0.14.0-1 (source) into unstable (Anthony Fok)
[2023-10-22] golang-go.crypto 1:0.13.0-1 MIGRATED to testing (Debian testing watch)
[2023-10-22] golang-go.crypto 1:0.13.0-1 MIGRATED to testing (Debian testing watch)
[2023-10-12] Accepted golang-go.crypto 1:0.13.0-1 (source) into unstable (Anthony Fok)
[2023-10-10] Accepted golang-go.crypto 1:0.12.0-1 (source) into unstable (Anthony Fok)

bugs [bug history graph]

all: 1
RC: 0
I&N: 1
M&W: 0
F&P: 0
patch: 0

links

homepage
lintian
buildd: logs, exp, reproducibility
popcon
browse source code
edit tags
other distros
security tracker
debian patches
debci

ubuntu

[Information about Ubuntu for Debian Developers]

version: 1:0.25.0-1
1 bug