[Pidgin] #14565: Link to .asc file and offer download over TLS

[Pidgin]

#14565: Link to .asc file and offer download over TLS
-------------------------------------------------+-------------------------
 Reporter:  ioerror                              |       Owner:  rekkanoryo
     Type:  task                                 |      Status:  new
Milestone:                                       |   Component:
  Version:                                       |  unclassified
 Keywords:  security https tls pgp signature     |  Resolution:
  win32                                          |
-------------------------------------------------+-------------------------

Comment (by elb):

 This thread has a lot of things in it on a lot of topics, and quote are
 getting long; I'm going to take a stab at addressing some of the things I
 find most important with minimal context.  Please ask for clarification if
 anything is unclear.

 == HTTPS downloads should be used to provide protection against MITM ==

 I see where this is coming from, but I'm not personally much motivated by
 it.  I have no problem with offering HTTPS downloads (and even think it's
 a good idea, in the sense that I'd like to see the ''entire web'' use
 HTTPS), but I don't buy that it makes users ''any safer whatsoever'', for
 several reasons.  The most important of which are that an HTTPS download
 of a corrupted file is just as corrupt as an HTTP download of a corrupted
 file, and that the CAs aren't exactly shining stars of reliability these
 days.  However, provided that we can solve the following problems:

  1. It's all well and good to say "2.8TB per month plus other downloads
 not included in that figure isn't much", but the reality is that, no, it's
 a lot.  It's a huge ton.  The reason isn't because 2.8TB/mo is difficult
 or expensive to support in terms of service infrastructure, but because
 ''we have no dedicated admins''.  We're lucky to support the
 infrastructure we have now, and it mostly gets by on administrator time
 from people who don't have the time to give in the first place.  We really
 do have to solve the infrastructure problem in a cheap way to make this a
 reality.  SourceForge, for whatever faults it may have (including the
 recent backdoored PHPMyAdmin download on one of their mirrors) makes
 providing a global network of mirrors easy.
  1. Trusting third-party volunteers to provide SSL downloads is a Big
 Deal.  We don't admit third-party builds into our downloads for the same
 reason.  I don't know you from Adam; why should I trust you to provide
 good faith service to our users?  Even if I trust you, what about other
 people who may offer to serve downloads?  I haven't looked at the TUF
 mentioned above, but I am familiar with some of Justin's work, and in
 particular his Seattle (which does automated updates, and is possibly
 related), it may help on this front.  In any event, I don't want to
 ''develop'' a solution to solve this problem -- we don't have time.
 Browsing the secure mirrors and verifying files is a lot harder than it
 sounds, because if the mirrors know who is browsing for verification they
 can simply supply good content to suspected verifiers and corrupt content
 to other users.
  1. Once third-party volunteers are trusted, we have to have a way to
 distribute packages quickly and reliably.  Ideally, in a semi-synchronized
 fashion.  One of the things that's bit us even with SF in the past is that
 some mirrors can take quite a while to catch up to the files offered on
 the primary site.  This leads to bug reports and IRC support requests.
 They've made this a lot better in recent years (or so it seems), and we've
 taken to uploading files some time before announcing their presence to
 combat this.  With a network of volunteer mirrors, I fear regression on
 this front.
  1. Integrating both HTTPS and the current SourceForge mirrored downloads
 on the Pidgin site in a way that is not confusing to users, or else
 satisfying the entire demand for downloads via a secure download method,
 is a must.  We already have users who can't figure out how to download
 Pidgin, and we've spent ''a lot of time'' trying to make our Download
 pages as clear as possible.  This is not a made up problem.  I see that
 ioerror has volunteered to help us with that, and that's great.

 All things considered, I'd strongly prefer offering HTTPS downloads off
 servers we provide, or via a single trusted third-party service (such as
 SourceForge, compromised download servers notwithstanding), '''provided
 that''' the administrative burden can be reduced sufficiently.  I don't
 have a problem with proposing that IMF money be spent on this (for
 example, to purchase the bandwidth) if I am convinced that the
 administrative overhead is small enough.

 == Signatures should be offered up front on the download page ==

 I entirely agree with this.  As I understand our download interface, if we
 add a link to the Windows download instructions and the source download
 instructions, possibly including a secondary link to instructions such as
 datallah has suggested above (which I have not yet read), we can solve
 this concern.  The other download links either suggest various package
 managers (which have their own verification methods) or ultimately wind up
 at the source download page.

 == There should be an easy way to download and verify binaries,
 particularly on Windows ==

 I agree with this, but it's not our problem.  Or rather, we can't afford
 to make it our problem.  If a solution to this problem exists, we can
 evaluate using it.

 == Is there a way to fetch content (perhaps via rsync) directly from the
 Pidgin project? ==

 No.  We can arrange that, but there's no current way.  We're not likely to
 arrange it for individual users, the burden is just too high.  We would
 need to arrange it on a broader scale, which is what this conversation is
 all about.

 == We need a way to trust the Pidgin developers' signatures ==

 I am well signed into the web of trust, as are several of the other Pidgin
 developers, and there is an incomplete core of Pidgin developers well
 cross-signed.  That core includes (but is probably not limited to) myself,
 Gary, Richard, Mark, and John.  I am always happy to exchange key
 signatures with anyone who can present me with proof of ID and proof that
 they own the email addresses in their associated UIDs.  (We can discuss
 proof of ID depending on circumstance; personal introductions ''plus''
 government issued ID preferred, but that is of course not always
 possible.)  I no longer travel as much as I used to, but I do travel from
 time to time, and I am willing to arrange meetups in remote locations when
 feasible.

 == Secure magnet URIs ==

 As I understand it, a magnet URI is simply a collection of hashes of the
 data to be downloaded.  I see no reason we could not or should not provide
 this.  It will require some effort to automate the generation and
 uploading of this data (we don't want uploaders to have to do a lot of
 extra work), but as we already have ways to distribute version numbers
 throughout our download pages I see no reason that we cannot add and
 include hashes.  Is there more effort required for this?

-- 
Ticket URL: <https://developer.pidgin.im/ticket/14565#comment:19>
Pidgin <http://pidgin.im>
Pidgin