From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 271C2138359 for ; Sun, 11 Oct 2020 13:40:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B655E0CB6; Sun, 11 Oct 2020 13:40:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 12C4AE0CB1 for ; Sun, 11 Oct 2020 13:40:48 +0000 (UTC) To: gentoo-dev@lists.gentoo.org References: <20201006095814.101719-1-mgorny@gentoo.org> <8d0c19ec-55cd-222f-998d-ec82c87df4f2@gentoo.org> From: Thomas Deutschmann Organization: Gentoo Foundation, Inc Subject: Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Message-ID: <730e452e-26cf-28db-1079-a4d4b0cd7d65@gentoo.org> Date: Sun, 11 Oct 2020 15:40:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/78.3.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uIuRmgl9imv5Jf1NcHeMWshCAPC6EYPQE" X-Archives-Salt: baff655b-710d-4bf6-97ba-f8c57b5bbe2a X-Archives-Hash: d5a020362e6929ceeae3ad234a62b489 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uIuRmgl9imv5Jf1NcHeMWshCAPC6EYPQE Content-Type: multipart/mixed; boundary="q7y1NVXbYYnmBT6vch7QjXl3bTjsAzSXw"; protected-headers="v1" From: Thomas Deutschmann To: gentoo-dev@lists.gentoo.org Message-ID: <730e452e-26cf-28db-1079-a4d4b0cd7d65@gentoo.org> Subject: Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs References: <20201006095814.101719-1-mgorny@gentoo.org> <8d0c19ec-55cd-222f-998d-ec82c87df4f2@gentoo.org> In-Reply-To: --q7y1NVXbYYnmBT6vch7QjXl3bTjsAzSXw Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2020-10-10 22:36, Micha=C5=82 G=C3=B3rny wrote: > On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote: >> Another example for something that was not thought to the end and >> which was rushed and pushed to our users. >=20 > You start this mail with an insult to me. Why do you keep doing > this? Do you feel that there is some special need for you to try to > diminish me in order to reach your goal? You seem to be obsessed with the idea that I am your perfect enemy... I=20 cannot help you with that. >> The whole idea started with assumption that not every developer >> will verify the distfile (an assumption I share). But why should we >> trust these developers that they will keep an eye on upstream=E2=80=99= s >> used certificate instead? That does not make any sense for me. >=20 > This sounds like 'perfect is the enemy of good'. If we can't get > this done perfectly good, we should just lie down and do not put any > effort into making things better. Sort of. >> Another point I just want to mention was patch 5 of 6 for=20 >> net-libs/miniupnpc. Did you notice that the ebuild will fetch >> public key via HTTP instead of HTTPS? >=20 > Is this question to me or to the public? Because if it's to me, > then yes, I've noticed I couldn't use HTTPS there. I'm sorry, I'm > not as incompetent as you'd repeatedly trying to prove, you won't win > your argument this way. See the first paragraph. I really don't understand why you believe I=20 want to show world how incompetent anyone is. I am very sure that people = active in Gentoo know very well that you are *not* incompetent. I am just showing a design flaw without any judgement. This is a=20 technical mailing list. It should be possible to focus on technical=20 aspects. One way to respond to that would maybe a discussion how we can=20 do that better (see robbat2 mail for example). I am fully aware that this is still a draft, which is also part of my=20 problem but I will address that later. >> This will create a chicken-egg problem here: We will record key >> information metadata the same way we store information about >> distfiles which is temper proofed. But because this is happening in >> an automatic way there is not just a theoretical chance that we >> will store an attacker=E2=80=99s key in our metadata because who is go= ing >> to verify they key? The same developer we distrust (or where we=20 >> just want to avoid to trust) that he/she verified the distfile? >=20 > What's the alternative? Ignoring upstream signatures entirely unless > we can securely fetch the key? Shoving the problem under the carpet=20 > and assuming that the developer will have safely set up the key on > his devbox while being totally incompetent at putting it in an > ebuild? My point here is: You had the idea to improve something. Which is good. Improvement is=20 always appreciated. But it must be an improvement. I expect that during the process, "Hey, I = think we can do X better... what do you think about doing it that way... = which will address problem Z..." we are all open minded. That means that = if we come to the conclusion that something isn't really an improvement=20 or so minor that the complexity and everything belongs to that isn't=20 worth it, that we all realize, "OK, didn't work as expected. Withdraw=20 the idea (maybe just until we find a better way) and move on". > Theories are all nice but do you have any proof of that? Preferably > one that involves developers who *actually carefully* checked > distfiles. Because my theory says developers don't have infinite time > to audit everything. I don't think I need a proof for that. I am just picking up your initial = argument for this new eclass saying "I don't want to need to trust=20 developer that distfile was checked carefully, if we would add=20 automatism we wouldn't need to trust..." (something I share). I hoped I would have shown everyone that in the end we are only *moving* = that trust we don't want to give developers that they carefully checked=20 distfiles to keys. In other words: We haven't changed anything -- we=20 gained nothing. We still have to trust developers that they carefully=20 check something, now just keys instead of distfiles. The previous=20 'problem' this eclass wanted to improve (solve?) is still there. =2E..and from my POV we got an additional problem because we now have a=20 system which will tell user, "No... distfile looks good, signature is=20 fine" which weighs the user in a false sense of security (even Google=20 had to learn that when they replaced padlock with "Secure" in browsers=20 -- suddenly users stopped using their own brain because they trusted=20 system too much which was telling them that the site which looks like=20 their bank but wasn't their bank's site was secure). Not to mention when this system will force users to connect to arbitrary = key servers... > Are you arguing that we should remove commit signatures as well? Or=20 > does it happen that with roughly the same technology and the same=20 > people, one layer is secure and another similar layer is totally=20 > bonkers? No. First you need to understand Gentoo's threat model. Once you=20 understand why we are using signatures you need to understand the=20 boundaries (limits) of signatures. The way how we are using signatures=20 is for example different because we are operating our own key=20 infrastructure and revocation process, we aren't affected by the=20 previous outlined issues. >> The purpose of this email is to get this addition removed ASAP. >=20 > Why do you claim to have the power to removed somebody's work just=20 > because it doesn't fit your view of the world? I am gonna merge this with my answer to first paragraph. First of all, calm down. You are reading too much into this. Just revert = your own logic: You obviously like your idea, worked on this and pushed=20 it to repository. Don't you see that anyone could ask the same? Who are=20 you? Why do believe that you can force something like that down to=20 everyone's system? That feature got enabled in developers profiles by=20 default, it will blow up distfiles with useless data (a view you can=20 have when you share my concerns and don't see any problems with current=20 Manifest system; For example we banned stuff in $FILESDIR before and=20 asked developers to move them to d.g.o when >25kb in total arguing that=20 large distfile is affecting *any* user... I am not comparing this 1:1=20 but to repeat your question: Who are you that you can decide to force=20 something similar down to everyone). Of course I don't have any power to remove somebody's work (and I am=20 still wondering why you assume I have), but you obviously had the power=20 to just push your 'idea' which is still a draft to everyone and also=20 forces everyone to participate in your beta testing... I hope to get a majority decision on that topic with the result to kill=20 it unless it will add any significant improvement we all want. From my point of view the current implementation is only creating=20 security problems due to giving anyone a false sense of security and=20 ultimately resources are wasted by everyone because there is no benefit. Sure, if I am the only having that opinion and most people see a value=20 in this and disagree with me... --=20 Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 --q7y1NVXbYYnmBT6vch7QjXl3bTjsAzSXw-- --uIuRmgl9imv5Jf1NcHeMWshCAPC6EYPQE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEExKRzo+LDXJgXHuURObr3Jv2BVkFAl+DC1kFAwAAAAAACgkQRObr3Jv2BVl2 Cgf+IylsOG2KTIq1bSlxvmApevsCCzizhbrxDX+nPDqWMoQAR+6NIc2/eBtsO4wcWPUOeAIaAR7E h/mNAkTUV/eKysCERsxPyXXuXDiOi1ZDGMZCD1Vk60wqeJbNmrojAO2009m7bMreRgo9qQHuVrEF joe9e1H/ong0RcefuZqNDK1Vp1kBm10mg2FRya09NzwEodAPqOAGqcigGiZlFPeYrMPsWxxwlNPd 2qVaYyalMKz4Pm5AXAi538dq5VJgpTKjN6WxPt9ScyGENYdWse9GH69928lsOmQyC9vem7/eLCed Eh/EW7PDhtb3brQKcBqS9ufd0M6OPLhetsyT04qrrw== =/R66 -----END PGP SIGNATURE----- --uIuRmgl9imv5Jf1NcHeMWshCAPC6EYPQE--