unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ryan Prior <rprior@protonmail.com>
To: Guix Devel <guix-devel@gnu.org>
Subject: Fw: Re: Concerns/questions around Software Heritage Archive
Date: Sat, 16 Mar 2024 23:40:13 +0000	[thread overview]
Message-ID: <lNfBYmEVnFhVOMmMknrmSZHY7ltr_NEYCyktnsoHocUHNhcLaBhSdafXOUBShFviAotsEESFbsJQ3zIYm_Fs89bOROF_VPPREHvrKm0ohBA=@protonmail.com> (raw)
In-Reply-To: <EoCuAq3N681mOIAh7ptCyXiyscM9R0iPDBWId1eS4EbTJ2-ARWNfGuqtXIvmqcJNBl1SQvMM4X6-GiC5LiUv4TJv6J4ritPA3uZ2JBwkAzQ=@protonmail.com>

[I intended to CC the following to guix-devel but forgot:]

------- Forwarded Message -------
From: Ryan Prior <rprior@protonmail.com>
Date: On Saturday, March 16th, 2024 at 6:36 PM
Subject: Re: Concerns/questions around Software Heritage Archive
To: Vivien Kraus <vivien@planete-kraus.eu>


> 
> 
> On Saturday, March 16th, 2024 at 6:13 PM, Vivien Kraus vivien@planete-kraus.eu wrote:
> 
> > 2. is more difficult, because Guix contributors sometimes change their
> > names too, and a commit reading “update my name” is not the best
> > solution. If I understand correctly, rewriting the history would be
> > understood as a “downgrade attack”, contrary to the ftfy case where the
> > developer could rewrite the history without such consequences. Is my
> > understanding correct?
> 
> 
> It's only a problem IMO because we make the decision to treat Guix as an append-only series of commits and treat any other outcome as a potential attack. One alternate solution would be to allow provision of an authenticated alternate-history data structure, which indicates a set of (old commit hash, new commit hash) tuples going back to the first rewritten commit in the history, and the whole thing would be signed by a Guix committer. That way, the updating Guix client can rewind history, apply the new commit(s), verify that the old chain and new chain match what's provided in the alternate-history structure & that its signature is valid. Thus verified, the Guix installation could continue without needing to allow a downgrade exception.
> 
> Perhaps there are much better ways of handling this, but I propose it in hopes of clarifying that there are technical solutions which preserve integrity while permitting history rewrites in situations where it is desirable.
> 
> I have requested previously that some commits I've provided be rewritten to update my name. In my case, it's because I've sometimes misconfigured my email software such that some commits by me are signed just "ryan" or "Ryan Prior via Protonmail" or similar, rather than my preference which is "Ryan Prior".
> 
> In my case this causes me no harm and is simply an annoyance, so when I encountered resistance to rewriting the offending commits, I dropped the matter, and I still consider it dropped and settled. Even if we developed the capability to securely present a rewritten history, I wouldn't demand that such be used to address small concerns like mine.
> 
> However, I know we have at least two trans Guix contributors. Do they have any commits with their deadnames on them? Not that this is an invitation to go look; they can tell us if this is a concern worth raising. I include the detail to clarify that this is not a distant concern. Perhaps they have been silent thus far for the same reason that I have, because the policy against rewrites presents too high a barrier? (Or it may not bother them, or maybe they used their initials which are the same etc?) In any case I think it would be courteous to develop a procedure by which we could remove deadnames from old commits, or otherwise remove harmful information from Guix's development history, should this become a necessity.
> 
> Ryan


  parent reply	other threads:[~2024-03-16 23:41 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-16 15:52 Concerns/questions around Software Heritage Archive Ian Eure
2024-03-16 17:50 ` Christopher Baines
2024-03-16 18:24   ` MSavoritias
2024-03-16 19:08     ` Christopher Baines
2024-03-16 19:45     ` Tomas Volf
2024-03-17  7:06       ` MSavoritias
2024-03-16 19:06   ` Ian Eure
2024-03-16 19:49     ` Tomas Volf
2024-03-16 23:16   ` Vivien Kraus
2024-03-16 23:27     ` Tomas Volf
     [not found]     ` <EoCuAq3N681mOIAh7ptCyXiyscM9R0iPDBWId1eS4EbTJ2-ARWNfGuqtXIvmqcJNBl1SQvMM4X6-GiC5LiUv4TJv6J4ritPA3uZ2JBwkAzQ=@protonmail.com>
2024-03-16 23:40       ` Ryan Prior [this message]
2024-03-16 17:58 ` MSavoritias
2024-03-18  9:50   ` Please hold your horses Simon Tournier
2024-03-16 21:37 ` Concerns/questions around Software Heritage Archive Ryan Prior
2024-03-17  9:39   ` Lars-Dominik Braun
2024-03-17  9:47     ` MSavoritias
2024-03-17 11:53       ` paul
2024-03-17 11:57         ` MSavoritias
2024-03-17 14:57           ` Richard Sent
2024-03-17 16:28           ` Ian Eure
2024-03-17 12:51         ` Tomas Volf
2024-03-17 23:56           ` Attila Lendvai
2024-03-20 15:25         ` contributor uuid (was Re: Concerns/questions around Software Heritage Archive) bae66428a8ad58eafaa98cb0ab2e512f045974ecf4bf947e32096fae574d99c6
2024-03-17 16:20       ` Concerns/questions around Software Heritage Archive Ian Eure
2024-03-17 16:55         ` MSavoritias
2024-03-18 14:04     ` pinoaffe
2024-03-17 13:03 ` Olivier Dion
2024-03-17 17:57 ` Ludovic Courtès
2024-03-20 17:22   ` the right to rewrite history to rectify the past (was Re: Concerns/questions around Software Heritage Archive) Giovanni Biscuolo
2024-03-21  6:12     ` MSavoritias
2024-03-21 10:49       ` Attila Lendvai
2024-03-21 11:51       ` pelzflorian (Florian Pelz)
2024-03-21 11:52       ` pinoaffe
2024-03-21 15:08         ` Giovanni Biscuolo
2024-03-21 15:11           ` MSavoritias
2024-03-21 22:11             ` Philip McGrath
2024-03-21 16:17           ` pinoaffe
2024-03-21 15:23       ` Hartmut Goebel
2024-03-21 15:27         ` MSavoritias
2024-03-21 15:54           ` Ekaitz Zarraga
2024-03-22  4:33           ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-03-21 16:18         ` Efraim Flashner
2024-03-21 16:23         ` pinoaffe
2024-03-18  9:28 ` Concerns/questions around Software Heritage Archive Simon Tournier
2024-03-18 11:47   ` MSavoritias
2024-03-18 13:12     ` Simon Tournier
2024-03-18 14:00       ` MSavoritias
2024-03-18 14:32         ` Simon Tournier
2024-03-18 16:27   ` Kaelyn
2024-03-18 17:39     ` Daniel Littlewood
2024-03-18 20:38     ` Olivier Dion
2024-03-18 19:38   ` Ian Eure
2024-03-18 22:02     ` Ludovic Courtès
2024-03-19 10:58     ` Simon Tournier
2024-03-19 15:37       ` Ian Eure
2024-03-18 11:14 ` Content-Addressed system and history? Simon Tournier
2024-04-20 18:48 ` Concerns/questions around Software Heritage Archive Ian Eure
2024-05-01 15:29   ` Ian Eure
2024-05-01 15:41     ` Tomas Volf
2024-05-02 10:28   ` Ludovic Courtès
2024-05-09 16:00     ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='lNfBYmEVnFhVOMmMknrmSZHY7ltr_NEYCyktnsoHocUHNhcLaBhSdafXOUBShFviAotsEESFbsJQ3zIYm_Fs89bOROF_VPPREHvrKm0ohBA=@protonmail.com' \
    --to=rprior@protonmail.com \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).