apt/methods/connect.cc, branch 2.2.0

connect: use ServiceNameOrPort, not Port, as the cache key

2020-12-22T23:54:14Z

The "last connection" cache is currently being stored and looked up on the combination of (LastHost, LastPort). However, these are not what the arguments to getaddrinfo() were on the first try: the call is to getaddrinfo(Host, ServiceNameOrPort, ...), i.e. with the port *or if 0, the service name* (e.g. http). Effectively this means that the connection cache lookup for: https://example.org/... i.e. Host = example.org, Port = 0, Service = http would end up matching the "last" connection of (if existed): https://example.org/... i.e. Host = example.org, Port = 0, Service = https ...and thus performing a TLS request over an (unrelated) port 80 connection. Therefore, an HTTP request, followed up by an (unrelated) HTTPS request to the same server, would always fail. Address this by using as the cache key the ServiceNameOrPort, rather than Port.

connect: convert a C-style string to std::string

2020-12-22T23:51:50Z

Convert the fixed-size (300) char array "ServStr" to a std::string, and simplify the code by removing snprintfs in the process. While at it, rename to the more aptly named "ServiceNameOrPort" and update the comment to reflect what this variable is meant to be.

Apply various suggestions by cppcheck

2019-07-08T13:51:17Z

Reported-By: cppcheck

Merge tag '1.8.2'

2019-06-11T12:16:18Z

apt Debian release 1.8.2

methods: https: handle requests for TLS re-handshake

2019-05-21T12:53:01Z

When accessing repository protected by TLS mutual auth, apt may receive a "re-handshake" request from the server, which must be handled in order for download to proceed. This situation arises when the server requests a client certificate based on the resource path provided in the GET request, after the inital handshake in UnwrapTLS() has already occurred, and a secure connection has been established. This issue has been observed with Artifactory-backed Debian repository. To address the issue, split TLS handshake code out into its own method in TlsFd, and call it when GNUTLS_E_REHANDSHAKE error is received. Signed-off-by: Michael Zhivich (merged from Debian/apt#93) LP: #1829861

Fix new gcc-9 warning -Wpessimizing-move

2019-04-16T10:59:54Z

warning: moving a local object in a return statement prevents copy elision [-Wpessimizing-move] Reported-By: gcc-9 Gbp-Dch: Ignore

Handle a missed case of timed out ip addresses

2018-05-24T12:26:16Z

Correctly register timed out IP addresses from a timed out select() call as a bad address so we do not try it again. LP: #1766542

Reword error for timed out read/write on SOCKS proxy

2018-05-19T19:39:08Z

Closes: #898886

Remove obsolete RCS keywords

2018-05-07T11:41:31Z

Prompted-by: Jakub Wilk

Correctly report transient errors again

2018-01-03T15:33:36Z

Commit 47c0bdc310c8cd62374ca6e6bb456dd183bdfc07 ("report transient errors as transient error") accidentally changed some connection failures to become non-transient, because the result of the error checks where being ignored and then fatal error was returned if an error was pending - even if that error was trivial. After the merge of pu/happy-eyeballs2a this becomes a lot clearer, and easy to fix. Gbp-Dch: ignore Regression-Of: 47c0bdc310c8cd62374ca6e6bb456dd183bdfc07