golang-google-grpc - Debian Package Tracker

general

source: golang-google-grpc (main)
version: 1.66.3-2
maintainer: Debian Go Packaging Team (DMD)
uploaders: Dmitry Smirnov [DMD] – Tim Potter [DMD] – Martina Ferrari [DMD]
arch: all any
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.27.1-1
oldstable: 1.33.3-2
stable: 1.64.0-7
testing: 1.66.3-2
unstable: 1.66.3-2
exp: 1.75.1-1

versioned links

1.27.1-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1.33.3-2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1.64.0-7: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1.66.3-2: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]
1.75.1-1: [.dsc, use dget on this link to retrieve source package] [changelog] [copyright] [rules] [control]

binaries

golang-google-grpc-dev (1 bugs: 0, 1, 0, 0)
protoc-gen-go-grpc

action needed

A new upstream version is available: 1.80.0 high

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

Created: 2025-11-27 Last update: 2026-04-04 15:02

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-12-29 Last update: 2026-03-31 20:00

1 security issue in trixie high

There is 1 open security issue in trixie.

1 important issue:

CVE-2026-33186: gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.