From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Ryan Prior <rprior@protonmail.com>
Cc: guix-devel@gnu.org, "Ludovic Courtès" <ludovic.courtes@inria.fr>
Subject: Re: Tricking peer review
Date: Sat, 16 Oct 2021 00:45:23 +0200 [thread overview]
Message-ID: <dd3703e394afa8fd9a9b90e4c0feda1b9e25f469.camel@gmail.com> (raw)
In-Reply-To: <VAvsM8o3G8NsMwxf60R5TjHWhT0BYCZfqmybzP80u0acH_kGnqF2v7CK4y-DQAe28R5zSYhs1MqblSj67SuXNhVo64KJCngG-1_gwGyUMpc=@protonmail.com>
Am Freitag, den 15.10.2021, 22:28 +0000 schrieb Ryan Prior:
> On Friday, October 15th, 2021 at 10:03 PM, Liliana Marie Prikler <
> liliana.prikler@gmail.com> wrote:
>
> > > On the plus side, such an attack would be recorded forever in Git
> > >
> > > history.
> >
> > On the minus side, time-machine makes said record a landmine to
> > step
> >
> > into.
>
> I've suggested this before and this seems like a good time to bring
> it up again: can we create a database of known "bad" Guix commit
> hashes, and make time-machine fetch the list and warn before it'll
> visit one of those hashes? This would resolve the land-mine problem
> and generally de-risk our git tree, which is maintained by fallible
> volunteers who will occasionally push tragic commits.
I don't think things would be quite as simple. A "bad" commit might
still be perfectly fine to fetch certain things from if they're
unaffected by it, plus you're now tasked with the job of keeping the
list of bad commits safe somehow. In some situations resetting a
branch might work, but obviously not for months old sleeper commits.
next prev parent reply other threads:[~2021-10-15 22:45 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-15 18:54 Tricking peer review Ludovic Courtès
2021-10-15 22:03 ` Liliana Marie Prikler
2021-10-15 22:28 ` Ryan Prior
2021-10-15 22:45 ` Liliana Marie Prikler [this message]
2021-10-15 22:59 ` Ryan Prior
2021-10-18 7:40 ` Ludovic Courtès
2021-10-18 19:56 ` Ryan Prior
2021-10-19 8:39 ` zimoun
2021-10-20 23:03 ` Leo Famulari
2021-10-21 8:14 ` zimoun
2021-10-15 23:13 ` Thiago Jung Bauermann
2021-10-18 7:47 ` Ludovic Courtès
2021-10-18 7:34 ` Ludovic Courtès
2021-10-19 8:36 ` zimoun
2021-10-19 12:56 ` Ludovic Courtès
2021-10-19 14:22 ` zimoun
2021-10-19 15:41 ` Incentives for review Ludovic Courtès
2021-10-19 16:56 ` zimoun
2021-10-19 19:14 ` Ricardo Wurmus
2021-10-19 19:34 ` Christine Lemmer-Webber
2021-10-19 19:50 ` Joshua Branson
2021-10-21 20:03 ` Ludovic Courtès
2021-10-20 21:37 ` Thiago Jung Bauermann
2021-10-21 13:38 ` Artem Chernyak
2021-10-22 20:03 ` Thiago Jung Bauermann
2021-10-23 1:43 ` Kyle Meyer
2021-10-23 3:42 ` Thiago Jung Bauermann
2021-10-23 7:37 ` zimoun
2021-10-23 16:18 ` public-inbox/elfeed -> Maildir bridge (was: Incentives for review) Kyle Meyer
2021-10-24 12:18 ` Jonathan McHugh
2021-10-21 16:06 ` Incentives for review Ricardo Wurmus
2021-10-21 16:32 ` zimoun
2021-10-22 20:06 ` Thiago Jung Bauermann
2021-10-21 15:07 ` Katherine Cox-Buday
2021-10-21 16:10 ` Ricardo Wurmus
2021-10-21 17:52 ` Katherine Cox-Buday
2021-10-21 18:21 ` Arun Isaac
2021-10-21 19:58 ` Ludovic Courtès
2021-10-21 21:42 ` Ricardo Wurmus
2021-10-22 10:48 ` Arun Isaac
2021-10-22 11:21 ` zimoun
2021-10-23 6:09 ` Arun Isaac
2021-10-22 10:56 ` Jonathan McHugh
2021-10-22 7:40 ` zimoun
2021-10-22 11:09 ` Arun Isaac
2021-10-22 8:37 ` Jonathan McHugh
2021-10-22 9:15 ` zimoun
2021-10-22 10:40 ` Jonathan McHugh
2021-10-22 11:32 ` zimoun
2021-10-21 21:18 ` Jonathan McHugh
2021-10-22 10:44 ` Arun Isaac
2021-10-22 11:06 ` Jonathan McHugh
2021-10-21 21:22 ` zimoun
2021-10-28 14:57 ` Katherine Cox-Buday
2021-10-21 17:51 ` Vagrant Cascadian
2021-10-24 11:47 ` Efraim Flashner
2021-10-20 8:22 ` Tricking peer review Giovanni Biscuolo
2021-10-20 9:10 ` zimoun
2021-10-20 8:29 ` patches for new packages proper workflow (Re: Tricking peer review) Giovanni Biscuolo
2021-10-20 23:09 ` Tricking peer review Leo Famulari
2021-10-21 7:12 ` Ludovic Courtès
2021-10-25 13:09 ` Christine Lemmer-Webber
2021-10-28 8:38 ` Ludovic Courtès
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=dd3703e394afa8fd9a9b90e4c0feda1b9e25f469.camel@gmail.com \
--to=liliana.prikler@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludovic.courtes@inria.fr \
--cc=rprior@protonmail.com \
/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).