Source file audit - 2013-11-17

[Björn Persson]

Ville Skyttä wrote:
>On Wed, Nov 20, 2013 at 6:44 PM, Till Maas <opensource at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131121/32212e62/attachment.sig>