On 01/01/2017 08:22 PM, Andrew David Wong wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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).
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.
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. We would need some way of obtaining upstream
packages without any invocation of GPG and then verify them somehow
without invoking GPG. 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. 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. 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
--
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/54dcaea0-987b-78c9-4c74-eca8c5406cad%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
