From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2Oqs-0004MR-Q7 for qemu-devel@nongnu.org; Thu, 25 Jul 2013 12:57:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2Oqo-00082o-OG for qemu-devel@nongnu.org; Thu, 25 Jul 2013 12:57:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2Oqo-00082T-H7 for qemu-devel@nongnu.org; Thu, 25 Jul 2013 12:57:14 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6PGvDYc021082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Jul 2013 12:57:13 -0400 Message-ID: <51F158E8.8040907@redhat.com> Date: Thu, 25 Jul 2013 10:57:12 -0600 From: Eric Blake MIME-Version: 1.0 References: <1374530960-22031-1-git-send-email-imain@redhat.com> <1374530960-22031-2-git-send-email-imain@redhat.com> <20130724105543.GA3623@dhcp-200-207.str.redhat.com> <51F039F5.90109@redhat.com> <51F13804.4060906@redhat.com> In-Reply-To: <51F13804.4060906@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0lLLrKWtvm70MdOqnIsamM62hD247iL74" Subject: Re: [Qemu-devel] [PATCH V6 1/3] Implement sync modes for drive-backup. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , famz@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, Ian Main , stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0lLLrKWtvm70MdOqnIsamM62hD247iL74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/25/2013 08:36 AM, Paolo Bonzini wrote: >> Furthermore, I'm proposing that for 1.6, we should make the format=20 >> argument mandatory for drive-backup. We made it optional for=20 >> drive-mirror, to allow for probing, but there have been CVEs in the >> past due to probing of a raw file gone wrong. We can always relax >> a mandatory argument into an optional one in 1.7, if we decide >> that probing can be done safely, but we can never turn an optional >> argument into a mandatory one once the initial release bakes in the >> option. It would make the code a lot simpler to just have a >> mandatory format argument, instead of having to bake in and >> document hueristics on which format is picked when the caller >> doesn't provide one. >=20 > Probing is unsafe by definition, on the other hand we should allow it > for consistency with the rest of the API. Shouldn't security trump consistency? My argument is that if probing can be abused, it is better to have 1.6 be conservative and mandate a format argument always; if we can later argue that some forms of probing are safe, then for 1.7 we can relax the argument to optional in the qapi-schema.json file and add code checks that still mandate the argument in the instances where it is needed, but allow probing in the remaining cases. But why are we so concerned about allowing probing in the first place? Libvirt will ALWAYS be passing a format, because that is the only way to avoid a security bug; it is easier to design the format to be mandatory than it is to reason about when probing might be safe, and there's no need to be consistent with the security holes that are permanently baked into older commands. >=20 > Making the format mandatory for mode !=3D 'existing' is fine, though. > We can relax it later. >=20 > For mode =3D 'existing' we should allow both probing, and using an > explicit format. But if you insist on allowing probing for mode=3D'existing', then qapi-schema.json must leave it as '*format':'str', and we are stuck implementing the code for when format is mandatory in the C code. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --0lLLrKWtvm70MdOqnIsamM62hD247iL74 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJR8VjoAAoJEKeha0olJ0Nq2joH/iGh40MHwDXdClfJcB5J8KyU BkD+e5lZA0weKmiz2l/JoPXlD2463FknqKeVEyUbvI96muqhjMl/a+/27GBKKE3j BmT5CKL5Fr/wS5fZrLdvdCNChegOSUXvLcTsLGOgzb3bcfOoPgkporwf0CbXHNxQ eoeAvgzrvpeRLyScLx1lGduNNXYxMeWWn+7kmgRq9nRvppGvflSEySVJxEWsMpF/ UtkhUcwBHhR9aBOvDXEmBb9gMm9kUfjHNmEG42d3r4+gOBIqjZu1YZnJrSDEDfZB s3ZWZGr0rxUejlkDBggMGhmawvhumgU/IvKxa0VU5UoqAhLTEt73pijNAfBdHd0= =cQeS -----END PGP SIGNATURE----- --0lLLrKWtvm70MdOqnIsamM62hD247iL74--