Usted está haciendo una afirmación audaz de que agregar HTTPS a los duplicados de PPA sobre el mecanismo de firma de código es una mejora de seguridad. Echemos un vistazo a lo que están haciendo esas dos cosas:
Firma de código
No estoy familiarizado con cómo funciona la firma de código en Ubuntu / apt, y no he tenido éxito en encontrarlo en Google. ¿Los paquetes están firmados por los desarrolladores o por el propio espejo? Si alguien tiene un enlace, te lo agradecería. Asumiré que están firmados por el espejo porque eso tiene más sentido.
Por lo tanto, el modelo de seguridad es que usted tiene un archivo .deb que desea instalar (el método por el cual lo obtuvo es irrelevante), y puede verificar la firma en el paquete para asegurarse de que sea genuino. A menos que un atacante robe la clave privada y firme su propia versión, esto parece bastante hermético.
HTTPS / TLS
El valor que esto agrega es que el servidor puede demostrar criptográficamente que es quien dice ser, y que todas las comunicaciones no pueden ser Man-in-the-Middle'd. Veamos esto en detalle:
Caso 1: ni la clave de firma de código PPA ni la clave del servidor HTTPS están comprometidas
Todo está bien. Usted está recibiendo doble protección. HTTPS no está agregando ningún valor.
Caso 2: la clave de firma de código PPA no está comprometida, la clave del servidor HTTPS está comprometida
Esto es equivalente a la práctica actual de no tener HTTPS. Entonces, un atacante puede mitigar su conexión a https://ppa.launchpad.net y, por lo tanto, apt no podrá darle una versión maliciosa del archivo .deb . PERO no podrá instalarlo porque la firma no se verificará correctamente. HTTPS no está agregando ningún valor.
Caso 3: clave de firma de código PPA comprometida, clave de servidor HTTPS no comprometida
El atacante no podrá mitigar tu conexión a https://ppa.launchpad.net . HTTPS está agregando valor.
Caso 4: Ambas claves comprometidas
Estás en problemas. HTTPS no está agregando ningún valor.
El único caso en el que HTTPS agrega valor es si la clave de firma de PPA está comprometida, pero la clave TLS del servidor no lo está. ¿Qué tan probable es que esto suceda? Claramente, los responsables del diseño de este sistema no lo consideran una amenaza significativa. Como dijo @kay en esa respuesta, si desea ejercer presión sobre este problema, presente un error.
Como nota aparte, el patrón de diseño de usar HTTP para los protocolos que tienen criptografía incorporada es bastante común y aceptado. Este es un diseño de protocolo muy similar a, por ejemplo, CMP o AIA para administrar certificados: no es necesario que estos protocolos revisen TLS porque el protocolo en sí mismo tiene protección criptográfica incorporada. Además, la entidad de origen que desea autenticar es la CA (o, en este caso, el firmante del código), cuyo reflejo en particular del que obtuvo el archivo es casi irrelevante. (compare esto con el caso de uso en el que TLS está diseñado, por ejemplo, para conectarse a www.facebook.com donde la identidad del servidor es la parte importante).