-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-01-06 12:27, Chris Laprise wrote: > On 01/06/2017 06:24 AM, Andrew David Wong wrote: >> >> 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. > > If neither GPG nor 'collaborative hashing' is considered safe on > its own, and if GPG is a supposed attack vector, then the > weaknesses of the two procedures could *increase* risk
How so? > instead of canceling it out. I never said anything about "canceling it out." > This 'great new idea' may be unique for good reasons, Why did you put that in quotation marks? I never said it was a "great new idea." It's just a hypothetical example that I used to illustrate a more general point in the foregoing discussion. > the primary one being that simple GPG verification is considered > safe. Well, there are many things that are considered safe by the general public (and even by the general computer security community) that are not considered safe in Qubes. For example, our position of distrusting the infrastructure seems to regard as unsafe (or at least insufficiently trustworthy) much of what most people consider safe (e.g., HTTPS). It's at least *possible* that the GPG pre-parsing issue indicates a genuine risk. A lot of security software is considered safe until bugs are later discovered. >> >>> 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>. > > What happens if you're the first one to hash a package? You don't > get to use GPG at all? I suppose it depends on what your goals are. If you're the package maintainer, maybe you're providing the first hash to the database. If you're trying to be helpful, maybe you're finding packages without hashes in the database so that you can contribute them. If you're an end user, maybe you decide to wait a few hours to see if any hashes for that package get added. > Or the order gets reversed... GPG is used before hashing and > exploit might ensue? > If there's a script performing this sequence of operations, it's hard to see why the order would get reversed. In general, in any security-sensitive software, very bad things can happen if the sequence of operations somehow start getting arbitrarily reversed. > Is the hash uploaded before or after running GPG? > That depends on the implementation. Perhaps something like: 1. Download the database. 2. Hash your package. 3. Check your hash against the database. 4. If you find a match, gpg --verify the package. 5. If verification is successful, upload your hash from step 2 to the database. > >>> 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. > > It doesn't really exist either way, does it? Why not? Assume the verification scheme of your choice. A package either succeeds verification under that scheme, or it does not. If it succeeds, then it should be trustworthy (since you've verified it as originating from a source you've decided to trust). If it proceeds to attack your compiler, then you've misplaced your trust, and you should no longer trust that source. If it does not succeed verification, then you should not attempt to compile it, since it does not originate from a source you've decided to trust. > A big reason why I'm debating the thinking behind this is that its > based on a low-quality assessment done here: > > https://groups.google.com/d/msg/qubes-devel/TQr_QcXIVww/SHLNsoPgWTAJ > > That is the whole 'I don't trust GPG' rationale right there. My > takeaway from it could be that verbose mode gives me super-powers > of perception with hardly any effort ...or not. > I don't follow your reasoning. Would you mind laying out your argument more explicitly? >> >>> 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 > > I didn't see where hashes are shared and compared. Are they? > No, #2524 has to come first. The part about sharing and comparing hashes is just a hypothetical example inspired by #2524. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYcKRQAAoJENtN07w5UDAwqxAP/0RtFEHz3F6PoK9xSH+V5qX5 821US8y9AWRjhC93/KbkKzpnHgyzUU7h4ed6Iw01pqW/24uhDr3gyo9bTebmmDhj jiB9w4we2sgVs0kzGzE1T5fELJ/g6fTsgCUEOJmKEmQl0S22Nh7XxS/i3gl6Fx5k gx0KebdY7/XyvPgx74JnrFdRe4XukB5uRE7p4gteBLzLbXtvepZk27gh0j9mZcT+ +H76LcrTioYqoepCEjx8hGEmfbOMZTpKd4MiVk3orpmy9Xu8fcbi4vH5AegxUpgt Nes18alCRve4n5rdclEVZ3yS11Vxh02YdxiHCIC6MHGZdhWZPh6yFrQdT0U/MPE0 FQngphinS7F+SwVHWJTRcc2uj4EsCIUsbq6IvqS8I971Y5BF1MElAPK9Nri9e/Yj T8QnaHvEbRcoBQi67P6uR8RXePA5xhW+kHggWRDlGe5GnqQ9Gljy1sZbA8v2TSLk iwJWeEHZZyXNZ0os83OVFU2a97XbiFPwbqHVFDRGRofleiFHbSn89//MOTjUropo mPwj6RK0ga++SHLs39PxqYZcB1aG3rVQIK3WFpts+xdV+GoVUYyZFJgsgW39ciKp 78dRNOKAzg7Yy9hkF8AODu4UtgNV/1OXVnVLSIxW6NpgWc9wCRUEABkBGPI6ghFd ozQ1m6H5G8t3/Y/ttcuA =HEUu -----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/d046624b-15bc-5ad8-7e88-a3fb3d19e6a8%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
