-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-01-05 21:35, Chris Laprise wrote: > On 01/01/2017 08:22 PM, Andrew David Wong wrote: >> On 2017-01-01 15:20, Chris Laprise wrote: >>> On 12/31/2016 11:43 AM, Andrew David Wong wrote: >>>> On 2016-12-30 19:32, Chris Laprise wrote: >>>>> On 12/30/2016 12:58 AM, Andrew David Wong wrote: >>>>>> After meditating on this thread for a little over three >>>>>> years, I'd like to revive it, because I think Marek made >>>>>> an important point here, and I don't quite understand >>>>>> Joanna's response. >>>>>> >>>>>> If we don't trust GPG in our backup system because it >>>>>> does too much parsing of untrusted data before >>>>>> verification (which I believe is correct), then why do >>>>>> we trust it in our dom0 update system? >>>>> Ultimately, only Joanna can decide whether some guardian >>>>> functions are suitable for Qubes. But I don't necessarily >>>>> buy into her assertion about gpg verify: Watch some >>>>> verbose output and declare 'Hark! Complexity!'. Is it >>>>> /that/ worrisome for gpg to iterate over X message segments >>>>> and decide if each is valid? >>>>> >>>> Interesting point. I wish I knew. >>> If Qubes devs are going to start making commitments of time >>> and effort based on such claims, and disrupting the admin >>> aspect of using Qubes as well, I'd advise you to back them up >>> with something rigorous before leading the community down that >>> path. >>> >> You're misinterpreting the nature of this conversation. It's >> just a discussion. No decisions or commitments have been made. >> I'm primarily asking questions. The claims I'm making are >> conditional in nature. It's quite possible that no action is >> warranted, but that's by no means obvious. > > > Given this thread was used to make implementation decisions in > qmv-backup, the suggestion of extending this assumption about GPG > to updates looked more than hypothetical to me (and being about > multi-party transactions, it happens to involve far more effort > and complexity than backups). Thanks for the clarification. :) > > >>> Laboring under the assumption that GPG is bad, you won't even >>> know if your Qubes-curated Fedora/Debian packages are good >>> unless you get those projects to switch to your alternative as >>> well. >>> >> First, I'm not laboring under that assumption. It's one of the >> things about which I'm inquiring. > >> Second, that's not necessarily true. There could be solutions >> that don't require other projects to change anything (for >> example, a hypothetical system in which we first compute the >> hash of a package with minimal pre-parsing, compare the hash >> value to a distributed database, then, if it matches, proceed to >> verify the package's signature with GPG). >
It sounds like you may be focusing exclusively on the hypothetical example at the expense of the general point, but for the sake of discussion: > If the Qubes Project is not authoring some of the packages, it > sounds unlikely to work as a primary step in verifying integrity. > This may /necessarily/ be true until the upstream suppliers for > dom0 change. > I don't see why. Maybe we're thinking of different things. Here's the general idea: https://github.com/QubesOS/qubes-issues/issues/2524 > Assuming GPG is an attack vector (a BIG assumption), I don't think > having users compare hashes with each other over HTTPS links, for > example, is going to suffice in addition to GPG if the former > won't suffice on its own. It's not supposed to. The idea is that hashing with minimal pre-parsing is a safe first-pass that mitigates (but does not eliminate) the risk of GPG verification (with pre-parsing). GPG verification is not replaced; it's still required. > We would need some way of obtaining upstream packages without any > invocation of GPG and then verify them somehow without invoking > GPG. That's the whole idea. Roughly: 1. Download <package>. 2. $ sha512sum <package>. 3. Check hash. If match: 4. $ gpg --verify <package>. If no match: 5. $ rm <package>. > After that point (assuming at least some packages will need to be > compiled) we need to deal with the much more real threat of the > /compiler/ being targeted for attack. This seems like an orthogonal threat that exists either way, though. > That is all /prior/ to the step of generating a hash and uploading > it to a database. > > -- > > I will say that if moving away from GPG does turn out to be > warranted (though I'll make a guess that it won't be), I'd suggest > replacing it in the development procedures first before trying it > with general distribution---fundamental changes should be > practiced by developers first. Indeed, that's why I'm such a fan of this: https://github.com/QubesOS/qubes-issues/issues/2524 > Beyond that, trialling a new verification procedure on the ISO > download page would make sense, since the image taken as a whole > is a work authored by the Qubes Project. > > Chris > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYb35TAAoJENtN07w5UDAwGMwP/03gNojFlXxodsFm6BzRLA5/ Wa/x1Q3N3ZyGoz48adyctybdC1Q97/x6kJiB+sXQE1TGl/uTopOSLXMv4SMlFShy XbUPAXpgz+zUIrz+R+85ODU5RpCbYu+Vw9S2FlIb6ccjFpy82DzXSI/Ew4mA2YHT w+gTMmuIkMqJN4/Vp+XahHpPL6fwOdheXGsrgUQMtZBntsMTkUW6hG9DiTL2vp/V h1dKYV0+VEaZ+7J67HhTELkVddKzAnSVJLKw6T3TDa2QK+CuqGkNAdVZFMYmbdPS gQTy/EFi1Hga+QB9AL+tLaaW/vHk3xC3CRT/f0YPwlwUpM304koCE9VHvUIa1K26 YRYORM/aex76hmUSN+//dAyBiGExi1cUSJe1/pZR6xHli7JLTDvgvLVxHKp5wy/G C/ncvelj6TvZEScpVoCZlxewqZOiL5qOyebHN1aNDAa9tDvUwR5mr7tmfhjt8tvt nntooc8HkrVwg2x2cRIV99Ee9aopzsamF8G5gVtG9Uw6GYwPm2/9l1RaQ7FNohOU j1j0moU2dcL3wfQEJ0mvjff+lE/CxfwTgbLf0bsviLtzHGlvsv3/oNwgDGpxxv6l vXUdfeleQ29P5vD/Cv7tGu/tkbL5AbLUUSAbo2IS3uGl+ucscilZ2SRMdpi5vFQ2 DJdTU3/pKWfao8LXqs/P =ul19 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/1313a10f-852b-6c0c-109f-5a41d053b7af%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
