linux-kernel - Re: [GIT PULL] KVM changes for Linux 6.3-rc7

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Apr 2023 09:45:55 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     linux-kernel@...r.kernel.org, KVM list <kvm@...r.kernel.org>,
        "oliver.upton@...ux.dev" <oliver.upton@...ux.dev>
Subject: Re: [GIT PULL] KVM changes for Linux 6.3-rc7

On Mon, Apr 10, 2023 at 11:34 PM Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> Out of curiosity, do you have some kind of script that parses the "git
> request-pull" messages and does these checks?  Or was it just the
> mismatch between diffstat and tag message?

For me, it's manual - I check that the diffstat matches, but also
check that the description matches the shortlog I get.

And if anything looks weird, I dig deeper (the diffstat often doesn't
match - some people use "--patience" for the diff which can generate
small differences, or there are other changes nearby so that the
merged end result diffs differently from the pre-merge state etc etc).

But "git request-pull" should actually have warned you about the SHA's
not matching. When it generates that

  "are available in the Git repository at:

     https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

   for you to fetch changes up to 0bf9601f8ef0703523018e975d6c1f3fdfcff4b9:"

verbiage, it should actually have verified that the tag matches
locally, and it generates that commit ID and the shortlog from the
local tag.

And the fact that the shortlog (and commit ID) you had was the
expected one, but the tag pointed to something else makes me suspect
that you are mis-using "git request-pull".

I strongly suspect that you did the request-pull *without* pointing at
the tag (in fact, you cannot possibly have pointed at the correct tag,
since the request-pull contents did *not* match the tag contents), and
then fixed things up manually later when you created the tag.

So you must have explicitly avoided all the automation that "git
request-pull" does.

              Linus