From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id ILYiL01D+GVFIgAAqHPOHw:P1 (envelope-from ) for ; Mon, 18 Mar 2024 14:36:13 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id ILYiL01D+GVFIgAAqHPOHw (envelope-from ) for ; Mon, 18 Mar 2024 14:36:13 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; 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"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710768973; 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; bh=MdtYtvbgKqgiNtQ4D146UYWYnWepTzyNVdOQF5xJ0CM=; b=jARr6m+obyzjHKY6rJOfBRhiKuDvacU0rGmnAWGKxzv5MaGF+9ls38CLO3pJvtvmdBnu0/ PrBTuO5m5uvCwRtJWrTMHWjLJugA9eiQ01G7deLpu5nDHscGjPHP5IuoqD3dNsOlNc3PGH he+3AGEmFvHRNLNDZibUHKQH2AGVgBBwLfjYFFlt2fiflbIlUTIaHGJv1CAu7NrAOWhBB0 2+EiHb0nqfTbJnwJgMJ8iYXQd8enfPua+uBDR3Z+ArydomvtKXLFfJdK+T+N7FxBumtoCy gL1DMd3kpenfi/qX8DvUzjRC+nEXDIz9J3pxsL25P4/6tAj19mc/J+XPrESF8g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1710768973; a=rsa-sha256; cv=none; b=nfoz2ZUA0Z/DG4rts2OkIwxvGceihUnd1j1FflUYVJcfgQLkWeumbzYkW4EZvd4R+LfzwD QS/UKDLQrjLdCViBO5LgbSZJeeL0RBbmQjCm52GxZF8KPutsyoVjBe8TH/+JwVG/H1YLsh W+GOBtwGqk8nSREzCFP3WmvAjBQyrVuLwEiQLA8bgEI4/srnTEpttZlWZdmjlhl4bPgcxc sHZPYaMjQBOIaKgTr+5abGfNX+xpWzyp9m5dKalb2sTyQ3Fv3zrfkmO4UzLCpseDw/SaS8 MzcN/7vCsDKwMJOBPUIJziFcSHDFFW926Rs5jc089SaVTOtBMCKSYIW/eOgilg== 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 69C6432EE1 for ; Mon, 18 Mar 2024 14:36:13 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmD9Q-0005zp-HL; Mon, 18 Mar 2024 09:35:40 -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 1rmD9P-0005zT-3m for guix-devel@gnu.org; Mon, 18 Mar 2024 09:35:39 -0400 Received: from hera.aquilenet.fr ([2a0c:e300::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmD9N-0007Wg-7E for guix-devel@gnu.org; Mon, 18 Mar 2024 09:35:38 -0400 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id C4768FFA; Mon, 18 Mar 2024 14:35:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hera.aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoXq2fUKbFe2; Mon, 18 Mar 2024 14:35:30 +0100 (CET) Received: from jurong (unknown [147.210.246.189]) by hera.aquilenet.fr (Postfix) with ESMTPSA id A9E16C91; Mon, 18 Mar 2024 14:35:29 +0100 (CET) Date: Mon, 18 Mar 2024 14:35:26 +0100 From: Andreas Enge To: Simon Tournier Cc: MSavoritias , Attila Lendvai , Ian Eure , guix-devel Subject: Re: rewriting history; Was: Concerns/questions around Software Heritage Archive Message-ID: References: <645b9b21-4923-eb23-7213-1c2cf5fe6850@fannys.me> <87sf0nwzl1.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87sf0nwzl1.fsf@gmail.com> Received-SPF: pass client-ip=2a0c:e300::1; envelope-from=andreas@enge.fr; helo=hera.aquilenet.fr X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -4.31 X-Spam-Score: -4.31 X-Migadu-Queue-Id: 69C6432EE1 X-TUID: 8iLUe0R05P+F Hello all, Am Mon, Mar 18, 2024 at 12:26:18PM +0100 schrieb Simon Tournier: > Therefore, it would be more constructive if you come with a > proof-of-concept allowing “history rewrite” and strong “software > identification” property the one thing I can think of, and which would allow time travel to coexist with history rewriting, is an additional layer of metainformation. First of all, when rewriting history, all commits from the bifurcation to an alternate universe must be signed again by the person doing the "time split"; so there is a loss of information there. Second, we need to create a table that associates every old, lost commit hash to the corresponding new commit hash; this should also be signed by the person rewriting history. Of course this will have to be continued to the future: If Guix has n commits and m history rewrites, then the m-th rewrite may have to create a table of n entries that link commit hashes of the m-th rewrite to those of the (m-1)-th rewrite. Total memory would become m*n entries. When doing time travel to a commit hash, one would need to check whether it is available in the current, m-th history rewrite; if not, one would need to look for it in the (m-1)-th rewrite and map it to a commit hash in the m-th rewrite; if not, one would have to look for it in the (m-2)-th rewrite and map it to a hash in the (m-1)-th rewrite, and then check whether or not it has been overwritten in the m-th rewrite. The total time complexity would be m look-ups in tables of size n each. It is a lot of effort; and probably for little gain, since we cannot eradicate each and every fork of the Guix git repo. The old data will still be available at SWH, and probably at random forks on lots of random forges all over the world. As Simon, I think that history, fundamentally, cannot be rewritten: What has happened in the past, has happened in the past. If you have done some public activity as the person known as X, and then change your name to Y, you cannot prevent your past activity to be known under identity X. Also, the time split would have to be publicly documented somehow; if we add as rationale for a history rewrite "person X is now known as Y", not much is gained compared to just keeping the old commits. Not documenting the rationales for history rewrites would not help to instill trust in the codebase, and probably not solve the problem either, since it is quite likely that the request by person X to now be addressed as Y will have been made on the mailing list or some other public forum. So my impression is that the .mailmap approach in the Guix project is a good compromise between acknowledging the wish of people to be known under identity Y, and what can reasonably be achieved to hide identity X. Well, there are things people can do individually: 1) Use a pseudonym P from the start instead of X (which is admitted in the Guix community, just look at a few of the names: there are pseudo- nyms with clearly made-up first and last names, there are very obvious one-word pseudonyms, and maybe some of the names that look like real names are not from the persons' passports, who would know). 2) This does not help, of course, if you are already known as X and want to be known as Y. Then either you can somehow make the change publicly, and transfer your reputation and also the information that you used to be known as X, or disappear as X and reappear as a new person Y and lose X's reputation. Doing both is impossible, I would say. Andreas