apt/methods/connect.cc, branch 1.5_alpha1

Introduce Acquire::AllowTLS to turn off TLS support

2017-06-28T15:34:51Z

As requested by Henrique de Moraes Holschuh, here comes an option to disable TLS support. If the option is set to false, the internal TLS layer is disabled.

methods: http: Drain pending data before selecting

2017-06-28T13:52:38Z

GnuTLS can already have data pending in its buffers, we need to to drain that first otherwise select() might block indefinitely. Gbp-Dch: ignore

methods: Add HTTPS support to http method, using GnuTLS

2017-06-28T13:52:38Z

The http method will eventually replace the curl-based https method, but for now, this is an opt-in experiment that can be enabled by setting Dir::Bin::Methods::https to "http". Known issues: - We do not support HTTPS proxies yet - We do not support proxying HTTPS connections yet (CONNECT) - IssuerCert and SslForceVersion are unsupported Gbp-Dch: Full

methods: connect: Switch from int fds to new MethodFd

2017-06-28T13:52:38Z

Use std::unique_ptr everywhere we used an integer-based file descriptor before. This allows us to implement stuff like TLS support easily. Gbp-Dch: ignore

methods: connect: Change PkgAcqMethod to aptMethod

2017-06-28T13:52:38Z

This will allow us to access ConfigFind() and stuff which makes it possible for us to implement TLS support. Gbp-Dch: ignore

abort connection on '.' target replies in SRV

2016-09-04T20:00:48Z

Commit 3af3ac2f5ec007badeded46a94be2bd06b9917a2 (released in 1.3~pre1) implements proper fallback for SRV, but that works actually too good as the RFC defines that such an SRV record should indicate that the server doesn't provide this service and apt should respect this. The solution is hence to fail again as requested even if that isn't what the user (and perhaps even the server admins) wanted. At least we will print a message now explicitly mentioning SRV to point people in the right direction. Reported-In: https://bugs.kali.org/view.php?id=3525 Reported-By: Raphaël Hertzog

methods/connect.cc: Only use AI_IDN if defined

2016-08-26T13:49:14Z

Gbp-Dch: ignore

block direct connections to .onion domains (RFC7687)

2016-08-10T23:34:39Z

Doing a direct connect to an .onion address (if you don't happen to use it as a local domain, which you shouldn't) is bound to fail and does leak the information that you do use Tor and which hidden service you wanted to connect to to a DNS server. Worse, if the DNS is poisoned and actually resolves tricking a user into believing the setup would work correctly… This does block also the usage of wrappers like torsocks with apt, but with native support available and advertised in the error message this shouldn't really be an issue. Inspired-by: https://bugzilla.mozilla.org/show_bug.cgi?id=1228457

keep trying with next if connection to a SRV host failed

2016-07-06T13:53:59Z

Instead of only trying the first host we get via SRV, we try them all as we are supposed to and if that isn't working we try to connect to the host itself as if we hadn't seen any SRV records. This was already the intend of the old code, but it failed to hide earlier problems for the next call, which would unconditionally fail then resulting in an all around failure to connect. With proper stacking we can also keep the error messages of each call around (and in the order tried) so if the entire connection fails we can report all the things we have tried while we discard the entire stack if something works out in the end.

Do not remove a not working SrvRecords server twice

2016-01-05T19:49:19Z

The PopFromSrvRecs() already removed the entry from the active list, so the extra SrvRecords.erase() was incorrect. Git-Dch: ignore