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: <CAGXu5jL+0B6tcfe-TLAeZ+SraWscqe2_R5mWTenxdSNuAhs3_g@mail.gmail.com>
Date:   Wed, 24 Oct 2018 15:21:55 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Boris Brezillon <boris.brezillon@...tlin.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Christoph Hellwig <hch@....de>,
        Guenter Roeck <linux@...ck-us.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Jens Axboe <axboe@...nel.dk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Mark Brown <broonie@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Git pull ack emails..

On Tue, Oct 23, 2018 at 1:41 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> So I've got a few options:
>
>  - just don't do it

As with other folks, this is what we're used to, but it does cause a
lot of "polling" your tree to see what's landed. (And your "Pulled"
email to pstore today scared the crap out of me briefly -- it made me
go look for this thread...)

I enjoyed getting Greg's "Pulled" emails for post-rc4, since it closes
the loop. I've always hugely preferred getting "Applied" etc emails,
and I try to make sure I always send them too.

>  - acking the pull request before it's validated and finalized.

While this can work, I would find it personally only a little useful
since it doesn't actually contain the information I (and any folks
contributing to the pulled patches) need: has it landed? When I send a
pull request for security hardening things, I'm mentally wearing my
seasoned asbestos suit until I see the PR has landed. (Other trees of
mine like pstore don't tend to trigger rants, so those are likely just
fine for this notification method.)

>  - starting the reply when doing the pull, leaving the email open in a
> separate window, going on to the next pull request, and then when
> build tests are done and I'll start the next one, finish off the old
> pending email.

This sounds like an annoying fragmentation of your workflow. I thought
Mark and Kirill's suggestion to stash the PR Message-Id in your merge
commit would be pretty easy to automate, though. (And may just be a
good bit of record-keeping anyway...)

On the balance, I think since most things you start to pull are, in
fact, pulled, the "send at start" method covers most cases and does
let people know when you've gotten to their PR. And I can spend less
time wearing my preparatory asbestos -- just from "Pulled" email until
I see it land. ;)

-- 
Kees Cook

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ