From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93435 invoked by alias); 29 Apr 2019 01:01:42 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 93428 invoked by uid 89); 29 Apr 2019 01:01:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_40,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=announcement, seek, evidence, clique X-HELO: mail-wm1-f49.google.com Received: from mail-wm1-f49.google.com (HELO mail-wm1-f49.google.com) (209.85.128.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Apr 2019 01:01:39 +0000 Received: by mail-wm1-f49.google.com with SMTP id h18so13170961wml.1 for ; Sun, 28 Apr 2019 18:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DNUxMfo6g+sJz5T7HIVbTP/mfmNDIYlQPIv1njgBIho=; b=gAOttxcOxQvOWrMVvHtRlsrUSyjyRGhJY5SiCgTzgwTL4A56V6RibM/qYzfLfmTu/K nHatpOWFwQlSqRBwxAz/3G6kgg0/emYOu0SZ0inbg+w2mdI+xeInNB+xndEi2ugH2q9N MzmEf68mqz4esFP93asQGjTaFfO5SgQxp/MSP6mWDT06wmpfQidvaSQDMuWl9EyX+Kwz 1w6CzOCF8IhvNoXPoUPIC7hQxE8fga3ZmQVZd/OW2MGf9Cn4q9zgOpG8GW/fGHufR3XP prqO2h8V5UXsu3sGNEYDLpr98kuJWs2+LVqSP4AEGGFvGEG0J2hIAmldxV0sJexjWRe9 vx6Q== MIME-Version: 1.0 References: In-Reply-To: From: Joel Rees Date: Mon, 29 Apr 2019 01:01:00 -0000 Message-ID: Subject: Re: How to trust setup.exe? To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00212.txt.bz2 On Sat, Apr 27, 2019 at 6:42 PM Achim Gratz 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