All of lore.kernel.org
 help / color / mirror / Atom feed
* b4 v0.7.0 is available
@ 2021-05-26 19:25 Konstantin Ryabitsev
  2021-05-26 19:41 ` Jason Gunthorpe
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Konstantin Ryabitsev @ 2021-05-26 19:25 UTC (permalink / raw)
  To: tools; +Cc: users

Hello, all:

Version 0.7.0 of b4 is now available for use. This release includes mostly
backend changes, but also includes some fixes and adds some oft-requested
features.

# Upgrading

If you've previously installed with pip:

    pip install --user --upgrade b4

If you're using b4 from a git checkout:

    git checkout stable-0.7.y
    git submodule update --init

# What is new

Below is the summary of what is new.

## Patch attestation

This version includes what I hope is the final rewrite of patch attestation
features, which has largely moved into its own tool and library called
"patatt": 

    https://pypi.org/project/patatt/

Patatt allows for end-to-end cryptographic attestation of patches via a
separate X-Developer-Signature email header that is very similar to DKIM. If
you have an hour, you can see my presentation to OpenSSF Digital Attestation
WG here:
https://www.youtube.com/watch?v=no6r1iUqY1A

B4 will check for this header in the messages it retrieves and will invoke
patatt (if found) to perform the attestation check, e.g.:

    $ b4 am -o/tmp 20210521184811.617875-1-konstantin@linuxfoundation.org
    [...]
    Checking attestation on all messages, may take a moment...
    ---
      ✓ [PATCH 1/3] Sign Message-Id header if present
      ✓ [PATCH 2/3] Make header order deterministic
      ✓ [PATCH 3/3] Release as 0.4.0
      ---
      ✓ Signed: openpgp/konstantin@linuxfoundation.org
      ✓ Signed: DKIM/linuxfoundation.org
    ---
    [...]

It is very easy to start signing patches with patatt, so I invite everyone to
test it out. If you are using git-send-email, you can automate the whole thing
to happen behind the scenes via the sendemail-validate hook:
https://pypi.org/project/patatt/#getting-started-as-contributor

If you've been using "b4 attest" for this purpose, you can continue to do so,
just make sure that patatt is installed (it will be automatically pulled in
with pip, or you can "git submodule update --init" if you're using straight
from a git checkout).

## Mailbox and maildir output changes

While troubleshooting some odd DKIM failures, I've discovered that what Git
considers "mbox" and what Python considers "mbox" are two different things,
which resulted in some wrongly escaped ">From" sequences to end up in commits,
as is evidenced here:

    https://git.kernel.org/torvalds/c/137733d08f4a

Starting with version 0.7, "b4 am" will save .mbox files in the format that
git expects. Alternatively, you can set "b4.save-maildirs=yes" or pass -M to
save threads as maildirs, which are also natively supported by git and avoid
any possible ambiguities when it comes to escaping/parsing mbox files.

You can read my full rant about the problem here:
https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?id=4950093c0c3

## Partial-reroll support

This version of b4 will automatically recognize partial series rerolls, e.g.:

    [PATCH v3 1/3] Patch one
    [PATCH v3 2/3] Patch two
     \- [PATCH v4 2/3] Patch two revised
    [PATCH v3 3/3] Patch three

When we see a new revision show up mid-thread, as a child of another patch
with the same numbers, we will automatically generate a new revision, so
retrieving the above thread with b4 will correctly generate a v4 with reused
patches 1 and 3 from v3:

    [PATCH v3->v4 1/3] Patch one
    [PATCH     v4 2/3] Patch two revised
    [PATCH v3->v4 3/3] Patch three

You can disable this for a thread by passing --no-partial-reroll to b4 am.

## Other small fixes

- We will now do a better job parsing [various] [bracketed] [things] in the
  subject.

- Cherry-picking with -P_ does a better job finding the message you want
  regardless of where it is in the thread.

- You can now pass an mbox via stdin using "b4 am -m -", so now you can use
  "b4 am" as a complete pipe-through from mutt to git am. This is handy for
  offline operations. See here for more detail:
  https://lore.kernel.org/tools/20210517220151.b2bmt5f2jjlgmkos@nitro.local/

- b4 am will warn when it finds a message in the thread with an
  "Obsoleted-by:" follow-up trailer. Running "git am -c" will automatically
  retrieve the linked revision, so contributors can now follow-up to the
  obsoleted revisions by sending a follow-up reply with:
  Obsoleted-by: https://lore.kernel.org/r/new-revision-msgid

- b4 pr --explode can now generate archive-ready threads, including a gzipped
  mbox of all discussion threads linked from commits. This feature is mostly
  for the archival project on the kernel.org side of things.

# Acknowledgements

Special thanks to the following people who helped during this release:

- Kyle Meyer 
- Peter Zijlstra
- Dan Williams
- Morten Linderud
- Mark Brown

Best regards,
Konstantin

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-26 19:25 b4 v0.7.0 is available Konstantin Ryabitsev
@ 2021-05-26 19:41 ` Jason Gunthorpe
  2021-05-26 19:56   ` Konstantin Ryabitsev
  2021-05-27  7:56 ` Geert Uytterhoeven
  2021-05-27 10:19 ` Greg KH
  2 siblings, 1 reply; 10+ messages in thread
From: Jason Gunthorpe @ 2021-05-26 19:41 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools, users

On Wed, May 26, 2021 at 03:25:58PM -0400, Konstantin Ryabitsev wrote:

> It is very easy to start signing patches with patatt, so I invite everyone to
> test it out. If you are using git-send-email, you can automate the whole thing
> to happen behind the scenes via the sendemail-validate hook:
> https://pypi.org/project/patatt/#getting-started-as-contributor

Any thoughts about connecting this to the patchwork instances?

As I patchwork user I've been wondering if I should be switching to
fetch patches to apply via b4 instead via patchworks - would
appreciate some clarity :)

Jason

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-26 19:41 ` Jason Gunthorpe
@ 2021-05-26 19:56   ` Konstantin Ryabitsev
  2021-05-26 19:58     ` Konstantin Ryabitsev
  2021-05-26 20:52     ` Jason Gunthorpe
  0 siblings, 2 replies; 10+ messages in thread
From: Konstantin Ryabitsev @ 2021-05-26 19:56 UTC (permalink / raw)
  To: Jason Gunthorpe; +Cc: tools, users

On Wed, May 26, 2021 at 04:41:17PM -0300, Jason Gunthorpe wrote:
> > It is very easy to start signing patches with patatt, so I invite everyone to
> > test it out. If you are using git-send-email, you can automate the whole thing
> > to happen behind the scenes via the sendemail-validate hook:
> > https://pypi.org/project/patatt/#getting-started-as-contributor
> 
> Any thoughts about connecting this to the patchwork instances?
> 
> As I patchwork user I've been wondering if I should be switching to
> fetch patches to apply via b4 instead via patchworks - would
> appreciate some clarity :)

The main difficulties with making it part of patchwork proper is mostly due to
it breaking the end-to-end nature of attestation: if we change patchwork to
perform the attestation check on the backend, we're back to trusting
kernel.org infrastructure. That is specifically something we want to get away
with. :)

We already do use patchwork-style patch hashes in b4, so perhaps a better
approach would be to closer integrate b4 with patchwork -- if simply on the
level of:

- list outstanding series in a patchwork project and retrieve them from lore
- automatically recognize patches that got applied and set their remote state
  to "Accepted"

I think this alone will help closer integrate the two workflows and avoid
needing to perform the attestation check on inherently untrusted
infrastructure.

-K

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-26 19:56   ` Konstantin Ryabitsev
@ 2021-05-26 19:58     ` Konstantin Ryabitsev
  2021-05-26 20:52     ` Jason Gunthorpe
  1 sibling, 0 replies; 10+ messages in thread
From: Konstantin Ryabitsev @ 2021-05-26 19:58 UTC (permalink / raw)
  To: Jason Gunthorpe; +Cc: tools, users

On Wed, May 26, 2021 at 03:56:42PM -0400, Konstantin Ryabitsev wrote:
> The main difficulties with making it part of patchwork proper is mostly due to
> it breaking the end-to-end nature of attestation: if we change patchwork to
> perform the attestation check on the backend, we're back to trusting
> kernel.org infrastructure. That is specifically something we want to get away
> with. :)

From. Get away *from*.

Totally not a Freudian slip.

-K

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-26 19:56   ` Konstantin Ryabitsev
  2021-05-26 19:58     ` Konstantin Ryabitsev
@ 2021-05-26 20:52     ` Jason Gunthorpe
  1 sibling, 0 replies; 10+ messages in thread
From: Jason Gunthorpe @ 2021-05-26 20:52 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools, users

On Wed, May 26, 2021 at 03:56:42PM -0400, Konstantin Ryabitsev wrote:

> We already do use patchwork-style patch hashes in b4, so perhaps a better
> approach would be to closer integrate b4 with patchwork -- if simply on the
> level of:

It would be a nice feature for b4 to be able to fetch "from"
patchworks, for instance

 $ b4 am https://patchwork.kernel.org/project/linux-rdma/list/?series=487923

"from" means b4 would go out and query patchworks for the list of
message IDs that constitute series 487923 and then b4 fetch exactly
those IDs in the usual way.

I have a script already that does the patchworks side of the above
using it's JSON API so it isn't too difficult

Jason

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-26 19:25 b4 v0.7.0 is available Konstantin Ryabitsev
  2021-05-26 19:41 ` Jason Gunthorpe
@ 2021-05-27  7:56 ` Geert Uytterhoeven
  2021-05-27 12:00   ` Konstantin Ryabitsev
  2021-05-27 10:19 ` Greg KH
  2 siblings, 1 reply; 10+ messages in thread
From: Geert Uytterhoeven @ 2021-05-27  7:56 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools, users

Hi Konstantin,

Thanks for the new release!

On Wed, May 26, 2021 at 9:26 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> - b4 am will warn when it finds a message in the thread with an
>   "Obsoleted-by:" follow-up trailer. Running "git am -c" will automatically

"b4 am -c"?

>   retrieve the linked revision, so contributors can now follow-up to the
>   obsoleted revisions by sending a follow-up reply with:
>   Obsoleted-by: https://lore.kernel.org/r/new-revision-msgid

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-26 19:25 b4 v0.7.0 is available Konstantin Ryabitsev
  2021-05-26 19:41 ` Jason Gunthorpe
  2021-05-27  7:56 ` Geert Uytterhoeven
@ 2021-05-27 10:19 ` Greg KH
  2 siblings, 0 replies; 10+ messages in thread
From: Greg KH @ 2021-05-27 10:19 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools, users

On Wed, May 26, 2021 at 03:25:58PM -0400, Konstantin Ryabitsev wrote:
> ## Patch attestation
> 
> This version includes what I hope is the final rewrite of patch attestation
> features, which has largely moved into its own tool and library called
> "patatt": 
> 
>     https://pypi.org/project/patatt/
> 
> Patatt allows for end-to-end cryptographic attestation of patches via a
> separate X-Developer-Signature email header that is very similar to DKIM. If
> you have an hour, you can see my presentation to OpenSSF Digital Attestation
> WG here:
> https://www.youtube.com/watch?v=no6r1iUqY1A
> 
> B4 will check for this header in the messages it retrieves and will invoke
> patatt (if found) to perform the attestation check, e.g.:
> 
>     $ b4 am -o/tmp 20210521184811.617875-1-konstantin@linuxfoundation.org
>     [...]
>     Checking attestation on all messages, may take a moment...
>     ---
>       ✓ [PATCH 1/3] Sign Message-Id header if present
>       ✓ [PATCH 2/3] Make header order deterministic
>       ✓ [PATCH 3/3] Release as 0.4.0
>       ---
>       ✓ Signed: openpgp/konstantin@linuxfoundation.org
>       ✓ Signed: DKIM/linuxfoundation.org
>     ---
>     [...]
> 
> It is very easy to start signing patches with patatt, so I invite everyone to
> test it out. If you are using git-send-email, you can automate the whole thing
> to happen behind the scenes via the sendemail-validate hook:
> https://pypi.org/project/patatt/#getting-started-as-contributor

Hey, it "just works!":

	Looking up https://lore.kernel.org/r/20210527101426.3283214-1-gregkh%40linuxfoundation.org
	Grabbing thread from lore.kernel.org/linux-usb/20210527101426.3283214-1-gregkh%40linuxfoundation.org/t.mbox.gz
	Analyzing 1 messages in the thread
	Checking attestation on all messages, may take a moment...
	---
	  ✓ [PATCH] USB: gr_udc: remove dentry storage for debugfs file
	  ---
	  ✓ Signed: openpgp/gregkh@linuxfoundation.org
	  ✓ Signed: DKIM/linuxfoundation.org
	---
	Total patches: 1
	---
	 Link: https://lore.kernel.org/r/20210527101426.3283214-1-gregkh@linuxfoundation.org
	 Base: not found (applies clean to current tree)
	Applying: USB: gr_udc: remove dentry storage for debugfs file


Nice job!

greg k-h

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-27  7:56 ` Geert Uytterhoeven
@ 2021-05-27 12:00   ` Konstantin Ryabitsev
  2021-05-27 12:05     ` Geert Uytterhoeven
  0 siblings, 1 reply; 10+ messages in thread
From: Konstantin Ryabitsev @ 2021-05-27 12:00 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: tools, users

On Thu, May 27, 2021 at 09:56:25AM +0200, Geert Uytterhoeven wrote:
> On Wed, May 26, 2021 at 9:26 PM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> > - b4 am will warn when it finds a message in the thread with an
> >   "Obsoleted-by:" follow-up trailer. Running "git am -c" will automatically
> 
> "b4 am -c"?

Yes indeed. Sometimes I wonder if naming it "b4 am" was a good idea, as half
the time I type "git am" when I meant "b4 am" and vice-versa. Brains are
terrible.

-K

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-27 12:00   ` Konstantin Ryabitsev
@ 2021-05-27 12:05     ` Geert Uytterhoeven
  2021-05-27 13:19       ` Konstantin Ryabitsev
  0 siblings, 1 reply; 10+ messages in thread
From: Geert Uytterhoeven @ 2021-05-27 12:05 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools, users

Hi Konstantin,

On Thu, May 27, 2021 at 2:00 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
> On Thu, May 27, 2021 at 09:56:25AM +0200, Geert Uytterhoeven wrote:
> > On Wed, May 26, 2021 at 9:26 PM Konstantin Ryabitsev
> > <konstantin@linuxfoundation.org> wrote:
> > > - b4 am will warn when it finds a message in the thread with an
> > >   "Obsoleted-by:" follow-up trailer. Running "git am -c" will automatically
> >
> > "b4 am -c"?
>
> Yes indeed. Sometimes I wonder if naming it "b4 am" was a good idea, as half
> the time I type "git am" when I meant "b4 am" and vice-versa. Brains are
> terrible.

Glad to discover I'm not the only one doing this ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: b4 v0.7.0 is available
  2021-05-27 12:05     ` Geert Uytterhoeven
@ 2021-05-27 13:19       ` Konstantin Ryabitsev
  0 siblings, 0 replies; 10+ messages in thread
From: Konstantin Ryabitsev @ 2021-05-27 13:19 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: tools, users

On Thu, May 27, 2021 at 02:05:30PM +0200, Geert Uytterhoeven wrote:
> <konstantin@linuxfoundation.org> wrote:
> > On Thu, May 27, 2021 at 09:56:25AM +0200, Geert Uytterhoeven wrote:
> > > On Wed, May 26, 2021 at 9:26 PM Konstantin Ryabitsev
> > > <konstantin@linuxfoundation.org> wrote:
> > > > - b4 am will warn when it finds a message in the thread with an
> > > >   "Obsoleted-by:" follow-up trailer. Running "git am -c" will automatically
> > >
> > > "b4 am -c"?
> >
> > Yes indeed. Sometimes I wonder if naming it "b4 am" was a good idea, as half
> > the time I type "git am" when I meant "b4 am" and vice-versa. Brains are
> > terrible.
> 
> Glad to discover I'm not the only one doing this ;-)

By the way, it's easy to set up a git alias command that wraps b4. E.g. in
~/.gitconfig:

    [alias]
        b4am = "!sh -c 'b4 am -sl -o- $1 | git am' -"

This way you can run: 

    git b4am <msgid>

-K

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-05-27 13:20 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-26 19:25 b4 v0.7.0 is available Konstantin Ryabitsev
2021-05-26 19:41 ` Jason Gunthorpe
2021-05-26 19:56   ` Konstantin Ryabitsev
2021-05-26 19:58     ` Konstantin Ryabitsev
2021-05-26 20:52     ` Jason Gunthorpe
2021-05-27  7:56 ` Geert Uytterhoeven
2021-05-27 12:00   ` Konstantin Ryabitsev
2021-05-27 12:05     ` Geert Uytterhoeven
2021-05-27 13:19       ` Konstantin Ryabitsev
2021-05-27 10:19 ` Greg KH

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.