Lars-Dominik Braun <l...@6xq.net> writes: >> I have heard folks in the Guix maintenance sphere claim that we >> never rewrite git history in Guix, as a matter of policy. I believe we >> should revisit that policy (is it actually written anywhere?) with an >> eye towards possible exceptions, and develop a mechanism for securely >> maintaining continuity of Guix installations after history has been >> rewritten so that we maintain this as a technical possibility in the >> future, even if we should choose to use it sparingly. > > the fallout of rewriting Guix’ git history would be devastating. It > would break every single Guix installation, because > > a) `guix pull` authenticates commits and we might lose our trust anchor > if we rewrite history earlier than the introduction of this feature, > b) `guix pull` outright rejects changes to the commit history to prevent > downgrade attacks. > > Additionally it would break every single existing usage of the > time machine and thereby completely defeat the goal of providing > reproducible software environments since the commit hash is used to > identify the point in time to jump to. > > I doubt developing “mechanisms” – whatever they look like – would > be worth the effort. Our contributors matter, but so do our users. Never > ever rewriting our git history is a tradeoff we should make for our users.
There may come a time where we don't really have another option but to rewrite (part of) history (e.g., if someone vandalizes the repository using incriminating/illegal files) - I hope that such vandalism would be caught quickly so that most guix installations would not be infected, but it may be a good idea to plan what to do in the unfortunte event that it is necessary to rewrite guix history
