All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Kees Cook <keescook@chromium.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	tools@linux.kernel.org, users@linux.kernel.org
Subject: Re: merging pull requests
Date: Fri, 1 Oct 2021 13:01:37 -0400	[thread overview]
Message-ID: <20211001130137.3c83dfee@oasis.local.home> (raw)
In-Reply-To: <202109301630.C2646F8B5@keescook>

On Thu, 30 Sep 2021 16:42:58 -0700
Kees Cook <keescook@chromium.org> wrote:

> Now I publish my tree, and sign a tag for it for a pull request. Whoever
> does that pull can only check my tag and has to trust I checked what
> went into my tree. At the end of the day, that's exactly what the
> tag signature is for: whoever is pulling must trust the PR sender for
> all kinds of reasons. But there isn't a way to mechanically perform an
> integrity check on the components of those results: the merged mbox with
> the signature headers or the remote tag signature aren't associated
> with the resulting branch any more.

As I've mentioned before, I have a personalized patchwork instance that
runs against my inbox. I pull from that patchwork to pull into my git
tree (which all patches must at least go to LKML). I also subscribe to
all commits that go into Linus's tree, and those patches run against
the patches in my inbox patchwork database. If a match is found, the
patch changes from "Under Review" (which gets set to that when it's
posted as my "for-next" or "for-linus" emails) to "Accepted", and they
no longer appear in my default view.

Thus, if the patch changes for the time I reviewed it, to the time it
gets into Linus's tree, that patch will not be removed from my
patchwork database. Which causes me to examine further.

> 
> But given that maintainers may tweak what was sent to them or squash
> fixes, there's likely no point in that kind of integrity chain...

I sometimes make slight changes, usually do to conflicts with other
changes. In these cases, I have to manually set the patches in my
database to "Accepted", but I don't do that without manually examining
what is in Linus's tree and what is in patchwork.

-- Steve

  parent reply	other threads:[~2021-10-01 17:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 17:33 merging pull requests Kees Cook
2021-09-30 20:00 ` Konstantin Ryabitsev
2021-09-30 23:09   ` Kees Cook
2021-09-30 23:22     ` Stephen Rothwell
2021-09-30 23:29       ` Kees Cook
2021-09-30 23:29     ` Stephen Rothwell
2021-09-30 23:42       ` Kees Cook
2021-10-01 11:59         ` Jason Gunthorpe
2021-10-02  0:15           ` Kees Cook
2021-10-01 17:01         ` Steven Rostedt [this message]
2021-10-01 17:07         ` James Bottomley
2021-10-02  0:17           ` Kees Cook
2021-10-01 17:19         ` Konstantin Ryabitsev
2021-10-02  2:35           ` Kees Cook
2021-09-30 23:31     ` Olof Johansson
2021-10-01  0:09       ` Kees Cook
2021-10-01  0:27         ` Olof Johansson
2021-10-01 17:05           ` Steven Rostedt
2021-10-02  0:12             ` Kees Cook
2021-10-01 18:26     ` Konstantin Ryabitsev
2021-10-01 18:47       ` Linus Torvalds
2021-10-01 19:30         ` Konstantin Ryabitsev
2021-10-02  0:08           ` Kees Cook
2021-10-02  6:22         ` Willy Tarreau
2021-10-02  0:11       ` Kees Cook

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=20211001130137.3c83dfee@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=keescook@chromium.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tools@linux.kernel.org \
    --cc=users@linux.kernel.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. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.