[jmvoodoo]

I think the point is that adding https over http for the current system would always improve security. At it's most broken, https is at least as secure as http and therefore wouldn't reduce the security of the overall system. It adds one more hurdle for an attacker to clear.

Similarly, the apt team ignoring a bug like this "because it's protected by https anyway." Is an invalid argument.

[moviuro]

> adding https over http for the current system would always improve security

No.

If an attacker can inject packets that break your SSL lib, but wouldn't have broken your package manager, you added a vuln.

Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545

[jmvoodoo]

Fair. There are specific library attacks that could result in RCE. However that is also true against curl, ssh, and for that matter could be introduced into your http library at some point. The question then becomes what library do you trust most? OpenSSL is attacked and tested constantly. Things have been found (in your example in 2003!). They have been fixed. Apt can choose to stand on it's shoulders, or go through the entire process themselves by putting together a patchwork of their own solutions that will no doubt get less testing by whitehats and be a juicy target for blackhats.

[giovannibajo1]

Even ignoring the fact that there are far better libraries than OpenSSL today (eg: BoringSSL), apt already implements a sandbox-like approach (as the article explains); I'm not sure if the subprocesses are actually sandboxed, but obviously they should and at that point, a vulnerability like the one you cited shouldn't let the attacker escape the very narrow sandbox.