Releases: GoogleCloudPlatform/artifact-registry-apt-transport
Releases · GoogleCloudPlatform/artifact-registry-apt-transport
20250123.00
Cleanup owners file. (#32)
20241121.00
fix: `apt update` stuck when fields contain trailing \n (#29)
* fix: `apt update` stuck when fields contain trailing \n
Before this commit, there were a few scenarios where this apt transport
would format a message containing a field that had a trailing newline,
which resulted in a message looking like:
```
400 URI Failure
Message: Get "https://us-central1-apt.pkg.dev/projects/<redacted>/dists/<redacted>/InRelease": oauth2/google: status code 503: {
"error": {
"code": 503,
"message": "Authentication backend unavailable.",
"status": "UNAVAILABLE"
}
}
URI: ar+https://us-central1-apt.pkg.dev/projects/<redacted>/dists/<redacted>/InRelease'
```
As the above indicates, this can happen when this apt transport
encounters an error when doing the underlying oauth2 token exchange; it
directly puts the error message into the response on L199:
https://github.com/GoogleCloudPlatform/artifact-registry-apt-transport/blob/main/apt/method.go#L190-L201
Unfortunately, this causes apt update to treat this response as two
separate messages, and since the first message does not contain a URI,
it also doesn't realize that the InRelease fetch failed. This causes apt
to hang indefinitely.
Here are a snippet of some logs that demonstrate this:
```
1712435831 2494987 <- ar+https:400%20URI%20Failure%0aMessage:%20Get%20"https://us-central1-apt.pkg.dev/projects/<redacted>/dists/<redacted>/InRelease":%20oauth2/google:%20status%20code%20503:%20{%0a%20%20"error":%20{%0a%20%20%20%20"code":%20503,%0a%20%20%20%20"message":%20"Authentication%20backend%20unavailable.",%0a%20%20%20%20"status":%20"UNAVAILABLE"%0a%20%20}%0a}
1712435831 2494987 <- ar+https:URI:%20ar+https://us-central1-apt.pkg.dev/projects/<redacted>/dists/etsy-ubuntu-jammy/InRelease
1712435831 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435831 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435832 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435832 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435833 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435833 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435834 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435834 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435835 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435835 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435836 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
...
```
In the above log, each `<-` is a message received by apt. It thinks it
received two separate messages, cannot match them to any download, and
waits forever.
After this commit, the message struct encodes newlines as literal "\n"
characters, so it prevents both trailing newlines and any accidental
double newlines in the response.
* refactor: use ` ` instead of `\n`
20241108.00
fix: `apt update` stuck when fields contain trailing \n (#29)
* fix: `apt update` stuck when fields contain trailing \n
Before this commit, there were a few scenarios where this apt transport
would format a message containing a field that had a trailing newline,
which resulted in a message looking like:
```
400 URI Failure
Message: Get "https://us-central1-apt.pkg.dev/projects/<redacted>/dists/<redacted>/InRelease": oauth2/google: status code 503: {
"error": {
"code": 503,
"message": "Authentication backend unavailable.",
"status": "UNAVAILABLE"
}
}
URI: ar+https://us-central1-apt.pkg.dev/projects/<redacted>/dists/<redacted>/InRelease'
```
As the above indicates, this can happen when this apt transport
encounters an error when doing the underlying oauth2 token exchange; it
directly puts the error message into the response on L199:
https://github.com/GoogleCloudPlatform/artifact-registry-apt-transport/blob/main/apt/method.go#L190-L201
Unfortunately, this causes apt update to treat this response as two
separate messages, and since the first message does not contain a URI,
it also doesn't realize that the InRelease fetch failed. This causes apt
to hang indefinitely.
Here are a snippet of some logs that demonstrate this:
```
1712435831 2494987 <- ar+https:400%20URI%20Failure%0aMessage:%20Get%20"https://us-central1-apt.pkg.dev/projects/<redacted>/dists/<redacted>/InRelease":%20oauth2/google:%20status%20code%20503:%20{%0a%20%20"error":%20{%0a%20%20%20%20"code":%20503,%0a%20%20%20%20"message":%20"Authentication%20backend%20unavailable.",%0a%20%20%20%20"status":%20"UNAVAILABLE"%0a%20%20}%0a}
1712435831 2494987 <- ar+https:URI:%20ar+https://us-central1-apt.pkg.dev/projects/<redacted>/dists/etsy-ubuntu-jammy/InRelease
1712435831 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435831 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435832 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435832 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435833 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435833 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435834 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435834 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435835 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435835 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
1712435836 2494987 [0.000] Bytes: 0 / 1 # Files: 24 / 28
...
```
In the above log, each `<-` is a message received by apt. It thinks it
received two separate messages, cannot match them to any download, and
waits forever.
After this commit, the message struct encodes newlines as literal "\n"
characters, so it prevents both trailing newlines and any accidental
double newlines in the response.
* refactor: use ` ` instead of `\n`
20241017.00
CVE bumps: Update go.mod and dependencies (#27) Bump to golang 1.23 and bump oauth2 dependency. Signed-off-by: Roman Mohr <[email protected]>
20241008.00
CVE bumps: Update go.mod and dependencies (#27) Bump to golang 1.23 and bump oauth2 dependency. Signed-off-by: Roman Mohr <[email protected]>
20241004.00
CVE bumps: Update go.mod and dependencies (#27) Bump to golang 1.23 and bump oauth2 dependency. Signed-off-by: Roman Mohr <[email protected]>
20241003.01
CVE bumps: Update go.mod and dependencies (#27) Bump to golang 1.23 and bump oauth2 dependency. Signed-off-by: Roman Mohr <[email protected]>
20241003.00
CVE bumps: Update go.mod and dependencies (#27) Bump to golang 1.23 and bump oauth2 dependency. Signed-off-by: Roman Mohr <[email protected]>
20240924.00
Provde the expected AR scopre for default credential lookup (#26) In case that apt is not sending over a `Config-Item` like `Acquire::gar::Service-Account-JSON`, the code falls back to default credential lookup. If it finds a metadata service, then it will automatically inherit the default `cloud-plaform` scope, but if it fins a service account json over the `GOOGLE_APPLICATION_CREDENTIALS` environment variable, no scope will be requested, therefore always add the required AR scope explicitly. This fixes errors like ``` oauth2: cannot fetch token: 400 Bad Request ``` if the service account json is detected over the default credential lookup paths. Signed-off-by: Roman Mohr <[email protected]>
20240607.00
Forked from adsr/debug_and_eof, pull request #21: finish responding t…