Verifying the signatures gets you two out of the three main security features that HTTPS would provide: integrity and authenticity. It can be argued for this use that there is not a strict requirement for the third, confidentiality — though knowledge of specific patches could lead to disclosure of information possibly of use to an attacker, CWE-200.
If this is being permitted through a firewall which must meet PCI DSS, the use of an insecure protocol must be documented (PCI-DSS v3.0):
1.1.6 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.
The answer then is no, HTTPS is not required for this purpose. But, the process should be documented, and if required any manual steps such as maintaining certificates included, noting also that §6.2 requires you to patch, and that §6.4.5 and subordinates require change control processes for patching.
Further mitigative measures that could be recommended are
- lock down outbound HTTP firewall rule to limited destinations if appropriate (delivery though CDNs makes this largely pointless though)
- lock down the firewall rule to time-based, or manual enable/disable
- instead use a HTTP proxy in a different network zone, in addition to auditable logging and future scope for DLP, this removes the need for outbound HTTP and DNS on the clients