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]
Message-ID: <CAHk-=whSZViPSuwTv02P34ncDJNFdZS4RoDxN4C2EEoff-W7Ew@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ