apt/methods/connect.cc, branch 2.7.10

Use https config on https proxies for http servers

2021-09-13T14:09:19Z

The settings used for unwrapping TLS connections depend on the access and hostname we connect to more than what we eventually unwrap. The bugreport mentions CaInfo, but all other https-settings should also apply (regardless of generic or hostname specific) to an https proxy, even if the connection we proxy through it is http-only. Closes: #990555

Turn TLS handshake issues into transient errors

2021-05-12T11:06:11Z

This makes them retriable, and brings them more into line with TCP, where handshake is also a transient error. LP: #1928100

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