Ville Skyttä wrote:
On Wed, Nov 20, 2013 at 6:44 PM, Till Maas
<opensource(a)till.name>
wrote:
> On Wed, Nov 20, 2013 at 11:50:17AM +0200, Ville Skyttä wrote:
>> I think I'll make spectool tell curl not to verify SSL certs by
>> default in the next release.
I don't think there's any need for the connection where publicly
available sources are fetched from without supplying any credentials
to be encrypted in the first place.
Encryption isn't needed in that case, no, but TLS also authenticates.
Certificates are for authentication, not for encryption.
Checking the downloaded content
matters, and that has nothing to do with whether the certificate of
the transfer connection is expired or not or if it's issued by a
trusted party or not or if it passes common name/hostname checks.
spectool is not a source verification tool nor a certificate
validation one, and I'm not going to help people get the misconception
that it might be something like that.
So how do you think the verification should be done?
If an upstream project doesn't PGP-sign the tarballs but does make them
available over HTTPS, then the TLS connection is the only thing that
ensures that the tarball you receive is the one that the developers
published. When I write https: rather than http: in a spec file, it's
because I want it verified that the source code hasn't been tampered
with. By disabling the certificate verification you sabotage HTTPS,
turning it into HTTP with extra waste of electricity. What other
verification method are you replacing it with?
The current system with a plethora of CAs that everybody trusts by fiat
is problematic, but it's better than no security at all. A bolt cutter
does not strengthen a weak link.
--
Björn Persson
Sent from my computer.