On 2020-01-31 08:49, yarl-bau...@mailoo.org wrote:
> Please Maya and Mr Billquist, can you be more specific about how it is
> insecure?
There are different domains to consider.
*Assuming you can trust the build environment (which includes the
signing process)*, and assuming that you can trust the underlying crypto:
- HTTPS protects the connection between you and the server (assuming
server authentication, and not just encryption). So if you trust the
remote server, your client, and the HTTPS implementation, then HTTPS is
sufficient for the entire chain.
- If you don't know if:
o the server storage can be trusted
o you can fully trust the link
o you can trust your local storage up until the point at which you
install the package
.. then you need the binary package to be signed.
Note that as long as the "trust the build environment" holds, the
signed packages cover both these cases, while "use HTTPS" doesn't cover
most of the second case.
Depending on what kind of security work one does, relying on HTTPS
may not be sufficient, as it covers less of the chain. Or to put it
another way: If you're screwed in a way that your HTTPS can't be
trusted, you can still trust the signed packages. If you're screwed in
a way that you can't trust the signed packages, then HTTPS won't help you.
--
Kind Regards,
Jan
