From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id lIPWEREHj2BdhQEAgWs5BA (envelope-from ) for ; Sun, 02 May 2021 22:09:53 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 8If9DBEHj2AgMAAA1q6Kng (envelope-from ) for ; Sun, 02 May 2021 20:09:53 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 90C2315455 for ; Sun, 2 May 2021 22:09:52 +0200 (CEST) Received: from localhost ([::1]:36256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldIPX-0003cC-FA for larch@yhetil.org; Sun, 02 May 2021 16:09:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldIPK-0003c3-Nz for guix-devel@gnu.org; Sun, 02 May 2021 16:09:38 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:60775) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldIPG-0002dn-Te; Sun, 02 May 2021 16:09:38 -0400 Received: from nijino.local (91-114-247-246.adsl.highway.telekom.at [91.114.247.246]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4FYHJ53VxWz1LBRt; Sun, 2 May 2021 22:09:25 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4FYHJ53VxWz1LBRt DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1619986165; bh=HO7kzfBvYFG2tt9gya/77I6NcRBpDCTb0Iftl+uIXI4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=T8bH5ZdJwpTjGGll1cq8Kx5hXYZ+9neV+OBfX63zSd6zn1yXcB5G/h7fYiRn7uuI6 yP2NY2H05Dw9TU0QMuCoSbC5G41iIHCy/a5kIoxpkYgohNRnbuqpNxVNPCC/vf6zU9 oUWUHA4KmQat/Y63pgCW+qWUEG6vWYYsmyUAtJDY= Message-ID: Subject: Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes) From: Leo Prikler To: Mark H Weaver , =?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?= Date: Sun, 02 May 2021 22:09:24 +0200 In-Reply-To: <87k0ohorww.fsf@netris.org> References: <87tunz11mf.fsf@netris.org> <87y2daz13x.fsf@netris.org> <87r1j2z079.fsf@netris.org> <87a6pqypf9.fsf@netris.org> <87wnsp7yo9.fsf@gnu.org> <87v986pdej.fsf@netris.org> <874kfm75fl.fsf@biscuolo.net> <1bbb100c34c660eaa697ae7ea9ea7ea3638c4c50.camel@student.tugraz.at> <87wnsije63.fsf@netris.org> <8df20a7d869d5bdca47aaf044ac9b229b020aea2.camel@student.tugraz.at> <87k0ohorww.fsf@netris.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 Received-SPF: pass client-ip=129.27.2.202; envelope-from=leo.prikler@student.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Guix Devel , GNU Guix maintainers Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1619986192; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=HO7kzfBvYFG2tt9gya/77I6NcRBpDCTb0Iftl+uIXI4=; b=uE3dLxerYAskIySWUeYlmD40R4ZY75K7KN85xEKgbfDoW1H2vRenlmMjwGCs61n5oFs9Vy F4Ia0gNoA9TKHWCBGf5PKHX533HYmiNUQf6UiHxtmQmdmWDYRMzkN5K4dwgJpMUM+NqHlp jBe583BeR9yZxHT14bj6xzaf1awHG7NW1AYhvbhaEWruRjJOVSfGsGONf8/Jluqay0o8sl mIaH//FY5ZC4LItKeh5JQaQoNlMVyRDTNLD+pel1UNaRqVRF49B+DD5FN6GBep+34NKJ+Q LN6epjhkTN3dFCm94S1cwHfv4G9yZwcKxoD5squIJXPdhmx/43zUmZ0KbyjtDQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1619986192; a=rsa-sha256; cv=none; b=ow7OERD9JyXZUK6iGAyGxjFfvqf/XZgFFRSJm9WwiQiA2KKgPTV/rm4x5r+SU0Di8obFqd EWgC8z7SvAY1Bs+LdkjSgDBJq8U8aBiPgSqDAL8CoPKY1qXmMW+AT0j7aiWW0msJtVQNJ1 wpSNEQ/VKlEUYH1aIZmUL2IShiI+KbbBFCu5gm846GZRMc+xci5LxZy/IGWWRM0NNfVmyu 1htVDpi+/7TSTZrH79HWdROX3C24rKnKylN0DdPa6tFRXUBsziq3o360mtQSDgINLdzjUj z2q481n3Cwhs/Nvwoq/+EFWhOHUkyWJuEdSpYuEjP1w6pyZXKmPQ2Oitf6i1QA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=T8bH5ZdJ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.36 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=T8bH5ZdJ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 90C2315455 X-Spam-Score: -1.36 X-Migadu-Scanner: scn0.migadu.com X-TUID: gdwsWxuZtRUr Hi Mark, Am Sonntag, den 02.05.2021, 15:29 -0400 schrieb Mark H Weaver: > Hi Leo, > > Leo Prikler writes: > > > Let us assume for > > the sake of argument I were to introduce a bug into Guix. There > > are a > > number of ways this can happen, but let's focus on the important > > distinction here, which is me purposefully introducing that bug vs. > > it > > happening due to oversight. > > > > Let us imagine the following four scenarios: > > 1. You assume I'm acting in bad faith and I indeed am. > > 2. You assume I'm acting in bad faith and I am not. > > 3. You assume I'm acting in good faith and I am not. > > 4. You assume I'm acting in good faith and I am. > > This is a false dilemma > ;, > because you've missed a very important case, namely: > > 5. You assume *nothing*. I think you're nitpicking here. If "good faith vs. bad faith" is not a boolean value, I could also be acting without one or the other, but clearly I either have evil intentions or I don't – there's no middle ground. Likewise, there's no middle ground on assuming evil intentions, you either assume they exist or you don't. Of course, we could get into technicalities of how evil you assume my intentions to be, but that's not going to help us here. > This is, in fact, the current scenario. I'm not making any > assumptions. > That is truly the state of my mind on this question, and I think it's > the only rational position to take. Which one is the rational position now? Not assuming evil intentions or assuming them? > In particular, I don't feel the need to introduce assumptions in > order to justify my question in the opening email of this thread, > namely whether someone who pushed a "cosmetic changes" commit that > removes security fixes should have commit access. > > That question does _not_ imply that anyone acted in bad faith. From > my perspective, it doesn't matter for our purposes. (Of course, it > would be good to know, but I'd rather not be distracted by questions > that we have little hope of ever answering.) IIRC I already answered that question as one of the first things in this thread (before it got renamed), so I don't want to repeat myself at lengths here. > My primary concern here is to protect our users, and the integrity of > our systems and of Guix itself. I don't know how to do that if we > tolerate committers who repeatedly push commits with misleading > commit messages. > > In order for meaningful oversight of Guix to be practical, it is of > *paramount* importance that the summary lines of commits be > reasonably accurate. I have neither the time nor the interest in > scrutinizing _every_ commit pushed to our repository, just in case > the summary lines are misleading. Therefore, I claim that we *must > not* tolerate committers who repeatedly push commits with misleading > commit logs. > > We are lucky that this incident was discovered. There's no guarantee > that the next one will be. I'm not sure what you're trying to say here, but if it's something along the lines of "Raghav must not be trusted", I disagree. They themselves have stated, that they have since learned from their past mistakes and the only reason this commit was even introduced at this point was because one of their older commits did not receive careful review. > This is _not_ about being a beginner. No technical expertise should > have been required to avoid this incident, only some basic care > before pushing commits. Even the most cursory glance at the commit > log should have immediately raised red flags, because its summary > line clearly contradicts the next few lines of the commit log itself: > > --8<---------------cut here---------------start------------->8--- > gnu: cairo: Make some cosmetic changes. > > * gnu/packages/patches/cairo-CVE-2018-19876.patch, > gnu/packages/patches/cairo-CVE-2020-35492.patch: Remove patches. > * gnu/local.mk (dist_patch_DATA): Unregister them. > * gnu/packages/gtk.scm (cairo): Make some cosmetic changes. > [replacement]: Remove. > (cairo/fixed): Remove. > --8<---------------cut here---------------end--------------->8--- > > I don't know what went wrong here, but it doesn't really matter to > me. Whatever the reason, I don't want someone who pushes commits > like this to have commit access. If people want to condemn me for > saying that, so be it. I don't know why your rehashing this at this point, we went over this already. Please refer to Raghav's messages at the time, they were helpful in clearing up the matter. Regards, Leo