From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: Geert Uytterhoeven <email@example.com> Cc: firstname.lastname@example.org, Konstantin Ryabitsev <email@example.com> Subject: Re: Patch attestation RFC + proof of concept Date: Thu, 27 Feb 2020 21:30:35 +0800 Message-ID: <CAHmME9pLHMM=Bkw2Kd4wk7Q=rboBRvnNVaC8fBE9yCm2VJZwMA@mail.gmail.com> (raw) In-Reply-To: <CAMuHMdXiVO8Lkg-qk1VQmp8opfoOXfurgkaqQcA5DdK78RBWow@mail.gmail.com> On Thu, Feb 27, 2020 at 6:05 PM Geert Uytterhoeven <firstname.lastname@example.org> wrote: > How would the commit base help here? It would indicate this is an old > patch, which would be indicated by the signature date, too. For email, not much, since the patch is always disconnected. The point is that this isn't a problem when verifying commits inside of git itself because the signatures are over the commit's position in the tree, so you can't reorder or rearrange commits. Not necessarily an applicable solution here, but worth noting that other setups don't encounter the same problem due to other, larger, design decisions. > The only thing that would help is time-limiting the window between > attestation and application. Sure, one can draw up a few bandaids for this, such as: big red text saying "warning, this commit is kind of old", which of course means its date needs to be included in the metadata signature, and accurate too. Maybe there are other bandaids. Or this is just a fundamental issue with disconnected by-email patches that we'll have to live with.
next prev parent reply index Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-26 17:25 Konstantin Ryabitsev 2020-02-26 17:50 ` Kees Cook 2020-02-26 18:47 ` Konstantin Ryabitsev 2020-02-26 20:11 ` Jason Gunthorpe 2020-02-26 20:42 ` Konstantin Ryabitsev 2020-02-26 21:04 ` Jason Gunthorpe 2020-02-26 21:18 ` Konstantin Ryabitsev 2020-02-27 1:23 ` Jason Gunthorpe 2020-02-27 4:11 ` Jason A. Donenfeld 2020-02-27 10:05 ` Geert Uytterhoeven 2020-02-27 13:30 ` Jason A. Donenfeld [this message] 2020-02-27 14:29 ` Konstantin Ryabitsev 2020-02-28 1:57 ` Jason A. Donenfeld 2020-02-28 2:30 ` Jason A. Donenfeld 2020-02-28 18:33 ` Konstantin Ryabitsev 2020-02-28 17:54 ` Konstantin Ryabitsev 2020-03-06 16:53 ` Geert Uytterhoeven
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 * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHmME9pLHMM=Bkw2Kd4wk7Q=rboBRvnNVaC8fBE9yCm2VJZwMA@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Workflows Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/workflows/0 workflows/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 workflows workflows/ https://lore.kernel.org/workflows \ email@example.com public-inbox-index workflows Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.workflows AGPL code for this site: git clone https://public-inbox.org/public-inbox.git