Re: How to trust setup.exe?

[Joel Rees <joel dot rees at gmail dot com>]

On Sat, Apr 27, 2019 at 6:42 PM Achim Gratz <Stromeko@nexgo.de> wrote:
>
> Am 26.04.2019 um 18:28 schrieb Joel Rees:
> > When bootstrapping a chain of trust, having multiple sources for the
> > checksum values is significantly better than starting blind.
>
> Except that checksums are at best providing evidence of tampering, not
> anchors of trust.

Well, it's clear that I'm not making my case very well. Thanks.

The point is that you really shouldn't have an anchor of trust buried into
something that is not provably free from tampering.

And the current arrangement does not provide clear proof that there has
been no tampering by DNS poisoning or m-i-m with invisible frames and such.

Well, https improves the situation over http significantly, but I know some
theory about how to get around that.Time-consuming, fragile, expensive,
not likely to be used to trap ordinary people, but people who load Cygwin
are already somewhat closer to the fringes of the bell curve, and ordinary
people could get caught in the ripple from a focused attack.

And, yeah, I'm having to re-think that one. People who need to worry about
mim attacks at the level that the https medium-sized wall presently puts up
need a lot more advice than I can squeeze into one or two blog posts.

However, I'm in a prima-donna mood, and I want to talk about multiple
witnesses.

> > I'm writing a blogpost on the use of multiple sources, using cygwin as
> > an example, but the announcements for the updates of setup_xx.exe do
> > not include the checksums.
>
> The root of trust for setup.exe and the whole of the Cygwin installation
> is the GPG key for cygwin@cygwin.com and the integrity of the
> sourceware.org server hosting the original files, not the checksum of
> any of the files.  Those checksum files you are talking about are
> largely an artefact of how the sourceware.org servers are set up and are
> not meant to provide the assurances you seek.
>
> https://cygwin.com/faq.html#faq.setup.install-security

I assume you use gnupg, I use gnupg, many interested people will be able to
buy a commercial alternative that has a face behind it.

But many people do not have means of confirming fingerprints available to
them. They have a chicken-and-egg problem. They have to start somewhere,
but any place they start is somewhat vulnerable to tampering.

The idea that I was working on is that Cygwin, in addition to being a good
way to get access to, say, bc, etc., could, with a little more than it has, be a
good way to get a copy of gnupg with a fairly high level of confidence that
it hasn't been tampered with and compromised.

> > And the mirrors don't seem to keep
> > setup_xx.exe. And the mirrors are all using .bz and .xz compression,
> > which many MSWindowsboxes are not able to open without 3rd party help,
> > which is a vicious cycle.
>
> The mirrors are, as the name implies, mirrors, so any compression used
> is already there in the (non-public) repo the mirrors are distributing.
> The setup.ini file is also available uncompressed, though, expressedly
> so folks can read it without having to decompress anything.

And I was misinterpreting lots of things about the compressed files and such.

I'm properly embarrassed about that. I'm going to take that blog post down,
eventually.

> > The blogpost:
> > https://joels-programming-fun.blogspot.com/2019/04/bootstrapping-your-freedom-cygwin-gpg.html
>
> That would need significant reorganization to become useful, IMHO.  But
> again, you're missing the whole point of what the trust anchor really is
> and how to verify it.  And yes, that bootstrapping step (obtaining and
> vetting setup.exe) would have to be done on a different system than the
> one you intend to install on if you are serious about it; although if
> you suspect that someone manipulates your system, then installing a
> clean Cygwin (assuming you succeed at it) onto that isn't really going
> to help matters.

As I say, I'm looking for a solution to the case where gnupg or equivalent
is simply not available, where there is no way to check the fingerprint
without trusting a stranger.

That's a point I need to focus on when I rework that blog post.

It is a bit of a non-technical solution, but the concept of multiple witnesses
can help. I need to also unpack the visible history part and such. Have to
reorganize the blog post, split it into several more-focused posts, etc.

> > Would it be impossible to ask someone in the project to put the
> > checksums in the announcements for setup?
>
> Are you asking about the possibility of asking?

Well, yeah, I'm trying to raise a flag by stages without bothering everyone
on the developers' list until I have something a bit more concrete than I
had.

> I'm not involved in releasing new setup.exe versions onto the server, so
> I can't comment on how much extra work it'd be to add the checksums to
> the announcement.

Which is pretty much the question I want to ask, whether it would be extra
work, or also whether it would conflict with some policy they have about
the distribution process.

> > And what about putting a regular zip compressed setup on the mirrors,

[ahem. Mea culpa.]

> > so we can run certutil to check the checksum of the setup we run when
> > we grab our first download, then grab gpg with a somewhat trusted
> > system to use when checking the next version of setup that we
> > download?
>
> The way things work right now the mirrors don't need to be trusted with
> anything.  Distributing setup.exe over the mirrors would actually open a
> door to manipulation if a user can be tricked or forced into using only
> (one or a clique of) rogue mirror(s).

This is such a potential policy point.

-- and the reason I specify picking three or more at random from a wide
geographical distribution.

It is not trusting the mirrors, it's using the mirrors against each other.

And setup.exe does not need to be distributed on the mirrors, only the
checksum. Multiple witnesses to the checksum.

> > It would not be a perfect chain, but without that we have nothing but
> > broken links and reverse implications
>
> Perfection is not attainable anyway.

Ah, but one can always try.

Yeah, it's one of my bad habits -- trying harder than most other people.

If it won't work, I may decide that https, combined with the general activity
level of the project and the mailing lists, will be enough for someone
willing to watch, and willing to check the value of the published checksum
over the course of a month or so before actually installing.

Thanks for giving me some help working these ideas out. I'm sure it's
going to take me a couple of months to reorganize my thoughts, and, in
the meantime, I'm wanting to have this conversation about posting the
checksum in more than one place.

-- 
Joel Rees

http://reiisi.blogspot.jp/p/novels-i-am-writing.html

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple