From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 0PomJ5SS+GX5dwEAqHPOHw:P1 (envelope-from ) for ; Mon, 18 Mar 2024 20:14:28 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 0PomJ5SS+GX5dwEAqHPOHw (envelope-from ) for ; Mon, 18 Mar 2024 20:14:28 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mpp7N+D6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710789268; a=rsa-sha256; cv=none; b=JO5vafhgcWA4OpMl9j13i5vCir/yycfX6MQyTkmROYPlkf/SAa7mHlj5kGMEgpSw0HuMmO WEbP/Qk0dbyq89cxNJ/4X8/damS2pm0SiWn4Cx3u9EEAeRb2mY+z5xTUnDRuL1la1PTn7H cD685XD338k8Tbbs6Ld+r7D80e3hpT9aMklmfXT8RgBImAlsqBh8PrPMngis2DzGxPlzZ9 2NF1ku/Acm5DU1y4YvOxklw5RAq2QLUVWww5EiJa74uQ1LqGlVTnVnhpDGkjfnooSGlzaa SC45qERnfPO0cSNpDHvM+K0GG/us819quygSBEJXJxwymo67OuCUUmCODPYHuA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mpp7N+D6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710789268; 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=1ovrp4PvowlAxZBqblY5KEgEb0EpXF5TLU6VPFDar7o=; b=EVIwxYbMQMWdPjN4cb9uA9mBrWmKm30UTMlaJzGYLNdakFoh2ybZ76wEp4BFnrFWTRNeNA Og9F4QUPye3lCzlSNlORcPTPvZZgVhz43gWDTxkGe7gjN7I6KkPhvtRV9ufBfNpxCJi+tw 5ZAy6oTSSDO6494goFrZ0DzURFNNgNWJDqdK6H4/QN19eytwjhEcfuydcHHglKmBQiRtqG bkP0dhGkbqrNEmTTB6tfWgYLMhi/fJRJ2nYUBfK1uz6n5KdMz4Cf/xl8YpHt+TN9Dk/swP D/szXyhwcHlUaxR+Rz4tSUQiBELU5gsytUPyyuR2nRWewh6P22GoXTBBv/RW4g== 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 2B6D87B5C8 for ; Mon, 18 Mar 2024 20:14:28 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmIQs-0000Ki-J8; Mon, 18 Mar 2024 15:14:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmBnj-000348-By for guix-devel@gnu.org; Mon, 18 Mar 2024 08:09:11 -0400 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rmBnb-0005VI-6p for guix-devel@gnu.org; Mon, 18 Mar 2024 08:09:11 -0400 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-512f54fc2dbso3869945e87.1 for ; Mon, 18 Mar 2024 05:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710763740; x=1711368540; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1ovrp4PvowlAxZBqblY5KEgEb0EpXF5TLU6VPFDar7o=; b=mpp7N+D6b/ER4C+bwwqy5WqUgdjQlDbozCirfmwuRKiIJOpgdzm5ZGXwV8fPGON6sJ to84NFjUttSq6sV+QFZdSk+Uslycfbrf5Rj4zaqOZRlgbV7Odfbry+afPilNAfPMgvS5 nTdCM1GGK62oo0NfY48+JAVg2JZdMw4qNh8iCiKP0vJ1a0IrEPxv/Tj4xK/orNDHT3zq eVvY/4J7Oj3G7WfSi/+NpFO02PwUrLLcKan0yWX9oM/SVET5hCh9YV+gVZnUPqn4CKch imch0/9mc58Uvm0gqmZ+b2ni4CjpVtHnFPARfkaRfc5ifo2otxzhgU7dpwjjd1DMU/y+ ohDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710763740; x=1711368540; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1ovrp4PvowlAxZBqblY5KEgEb0EpXF5TLU6VPFDar7o=; b=JFFRd+PeizsDTgwkAQVsx5ZLfKgIanLFqmN40pUM007AOQwPD1UL7gXOf7KbWG7JC6 sNlqhBZzYFPLGiHUz/JFi7wVdAGhBoH86qIYBmnww6UzFfn1U7gd8Kn9gDeAOc24TM3Q 2oNj0j55iAfkUBgp69LUPCo1yPUukbk+vL9KetHVLPaj05QbZBPntMnUMSENPs1irYrG 26PJIIezlPwhlJG2mOrajPjmNq1w5YCJaiWwH4I60+kKBKhaEC3O+GVD4wjzXyrmPNCQ QQ3cFanL+9ektdXGjtCGmp/M6qmlvn8zH8rVoqK27NYRWVEONUIVFbXEZL8/5CI0WBow kVDw== X-Forwarded-Encrypted: i=1; AJvYcCWJFh+oA7BeoybsNI0dMXM8XZI25M+KAy/d2PaY6Tx8Xc4khb0/NgfbB3JkHgb/y4UYRBrMYKXrrBJzTa4rxMRU/Y4= X-Gm-Message-State: AOJu0YyL0ZSaNHWPItdds2MEknE+2R/29Gno8I6RVAw6ZHQQhEVFIwrP P7bkfma3+Q4yMjpYbMEXKtUPYgi8yNllMUBVPP8hkI1jLhqNTcmkrI7QqIrf103eh97aMBjFg/h nLcHFCW0RONTxPobibWC28LlHcBg= X-Google-Smtp-Source: AGHT+IHSh5e4UqcEW4qexSvq9PWNDhDriUb7W0ADN40ZpYHAnyBKAcl5d+l3VoPd6gRQtXR0Pi+0wQslGL7A9Ds9RMU= X-Received: by 2002:a05:6512:3d0b:b0:513:ed0f:36c4 with SMTP id d11-20020a0565123d0b00b00513ed0f36c4mr1761560lfv.43.1710763739436; Mon, 18 Mar 2024 05:08:59 -0700 (PDT) MIME-Version: 1.0 References: <645b9b21-4923-eb23-7213-1c2cf5fe6850@fannys.me> <87sf0nwzl1.fsf@gmail.com> In-Reply-To: <87sf0nwzl1.fsf@gmail.com> From: Daniel Littlewood Date: Mon, 18 Mar 2024 12:08:48 +0000 Message-ID: Subject: Re: rewriting history; Was: Concerns/questions around Software Heritage Archive To: Simon Tournier Cc: MSavoritias , Attila Lendvai , Ian Eure , guix-devel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::135; envelope-from=danielittlewood@gmail.com; helo=mail-lf1-x135.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 18 Mar 2024 15:14:01 -0400 X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -8.09 X-Spam-Score: -8.09 X-Migadu-Queue-Id: 2B6D87B5C8 X-TUID: d0oDGbWS+bam Hi everyone, I think the discussion so far splits into "should something be done" and "what can be done". The "should something be done" is easier to address, I think, so I'll deal with it first. I particularly have Attila's reply in mind. > let's put aside the trans aspect of this question for a moment, > is it reasonable for me to demand from somebody else to change their memo= ry of my past actions? > if so, then where is the line? what's the principle here? and what are it= s implications? > i sure see some actors out there who can hardly wait to start erasing cer= tain records at the barrel of the law I do not doubt that there are bad actors who might misuse the ability to rewrite history generally. However, this only allows us to dismiss the technical challenge if there is *no* legitimate use case for rewriting history, ever, in any circumstance. So rather than removing the trans aspect of the question to consider every possible use case (good or bad) of rewriting history, it seems like we only need to come up with a single case that's sufficient to justify altering someone's identity, for it to be worth considering if the technical restriction could be avoided. But then the answer is obvious: Someone might just sign their commits wrong for whatever reason. Is it valuable for a user or for guix generally to preserve metadata in the case where a commit is signed incorrectly? Obviously not. So whether you are sympathetic to the deadnaming issue or not (personally I am) it seems like we can dismiss the question "should we do something about it". As for what could be done, if I understand the discussion so far (I'm not an expert in guix internals) the only reason we care about identity is that it's part of git commits. If that's really all it is, then I wonder if the following scheme would resolve the issue? * Start with git repo A, signed with an identity now considered incorrect for some reason. * Rewrite history to replace the old signer with the new signer. Make no other changes to the content of any commit. This produces repository A'. * Repository A and A' should have identical numbers of commits, and identical content of the code at each commit. Therefore we can set up a one-to-one mapping from the commits of A to the commits of A'. * Store this mapping of "deprecated commits" (pairs of commit hashes, pointing from the deprecated commit to its corrected version) in a database somewhere, and discard repository A. * Whenever we attempt to look up a commit, if the lookup fails, try to look in the deprecated commits database. Perhaps emit a warning that the commit hash is deprecated and should be updated. Note that point 3 (that the content is identical in each commit) could be violated. e.g. perhaps there is a "CONTRIBUTORS" file which also needs to be scrubbed. This would present an algorithmic difficulty (if we actually tried to verify the code is unchanged) but if a trusted maintainer of the project is authorising the deprecation, then we don't actually need to know that the code is unchanged. Note also that this deprecation mechanism would fix the problem for simple forks too. e.g. in the case referenced, if someone packaged a fork of the deadnamed repo, then looking up a commit that was created pre-fork and included the old identity, then looking up that commit could notify the user that the repo should be updated. Does this sound at all sane? Best wishes, Dan On Mon, Mar 18, 2024 at 11:26=E2=80=AFAM Simon Tournier wrote: > > Hi, > > On lun., 18 mars 2024 at 12:10, MSavoritias wrote: > > > The right of a trans person to ask a project to not advertise their > > deadname was never in question. > > > > Guix is a place that supports trans people and anybody else that wants > > to change their name. > > There is a difference between =E2=80=9Cadvertise=E2=80=9D and =E2=80=9Cpa= rt of the history=E2=80=9D. > > Do not take me wrong. The right to be forgotten is one topic. However, > as many people are saying: it is not an easy question. There is legal > questions, technical questions, social questions, etc. > > For what it is worth, Guix is built around the concept of immutability. > This is a core concept and deep in Guix internals. > > Therefore, it would be more constructive if you come with a > proof-of-concept allowing =E2=80=9Chistory rewrite=E2=80=9D and strong = =E2=80=9Csoftware > identification=E2=80=9D property [1]. Else, the discussion is leading no= where, > IMHO. > > 1: https://guix.gnu.org/en/blog/2024/identifying-software/ > > Cheers, > simon >