| Age | Commit message (Collapse) | Author |
|---|
|
Normally, -f would be 'Some Service <service@example.org>', but in case
it's just "service@example.org", wrap it in angle brackets properly.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When we're retrieving linked messages, make sure we don't clash with the
variable holding the overall mbox.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
This version returns a failure early when body modification is
recognized. This is especially useful if we have to shell out to gnupg
for validation.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Calling b4-am with --use-local=MBOX is supposed to abort with "Could
not find MID in MBOX" if the mbox doesn't contain the specified
message ID. As of 4950093c0 (Don't use mboxo for anything,
2021-05-18), a type error is signaled because get_strict_thread()
returns None when there are no matches, and get_msgs() feeds this
result to len().
Update get_msgs() to instead check whether the returned value
evaluates to false.
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210523025812.26456-1-kyle@kyleam.com
|
|
Minor bugfix release with better error messages for installs without any
keys and unconfigured git.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Be a bit more discerning about the header matches for lore.kernel.org.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If we haven't been able to retrieve any messages, then exit early.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Our version of public-inbox still adds List-* headers of its own. This
is gone in the newer version, so strip these in hopes that this helps
verify more DKIM signatures.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
We only really need 0.2, but 0.4 implements DKIM slightly more properly.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
There will be more keyring operations supported in the future, probably,
but for now just move the --show-keys subcommand from "mbox" to "kr".
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
A series may not have a cover letter, so properly handle that situation.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Not really necessary, but let's keep them synced across major versions.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
We may not have an lmsg[0], so check for that.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If we come across an obsoleted-by trailer, and we're not running with
--checknewer, then output a warning that there is a newer revision.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When processing -P_, filter by that msgid (and its follow-ups) early on,
instead of parsing the entire thread and only then looking for matches.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Per discussion on the users list, add initial support for the
"Obsoleted-by" trailer that points at the new revision for the series
instead of doing a blind match by subject+from.
Probably buggy and needs better support for series number collisions
(right now we don't check if the newly retrieved series has a revision
number greater than the revision we already have).
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When cherrypicking by msgid and with multiple revisions available, make
sure that we pick the series revision that actually contains the msgid
being cherrypicked.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
It probably doesn't matter for b4 usage, but the maildir standard
requires that files are written to tmp first and then moved into new (or
hardlinked, really, then removed from tmp). Since nothing is reading the
dir we're writing to, it's not as important to fully follow the
standard when it comes to hardlinking, but let's at least move them into
place once writing is completed.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Group patch output inside the indented ---, and all processing messages
before the indent.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Properly handle situation where we can get a None as well as an empty
message list.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Save am-able maildirs as .eml files, as this is more likely to be
properly recognized format-wise by vim and friends.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Update the manpage to record the new flags.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
While trying to figure out some odd DKIM failures, I've discovered that
there is an important incompatibility between git's idea of what "mbox"
format is, and Python's mboxo implementation -- at least when it comes
to treating "\nFrom " escapes.
According to the "original mbox" standard, when a message body contains
a "\nFrom " sequence, it should be converted to "\n>From " in order not
to confuse the parser. When reading messages in that format, clients are
supposed to back-convert "\n>From " into their original form. This is
the so-called "mboxo" format, which is what Python's mailbox.mbox
supports:
https://docs.python.org/3/library/mailbox.html#mailbox.mbox
The "mboxrd" format was created to avoid a corruption problem whereas a
body that legitimately contains "\n>From " would be wrongly converted
into "\nFrom " upon parsing the mailbox, so mboxrd standard requires
that, when saving a mailbox, "\n>From " sequences are additionally
escaped as "\n>>From ". This is the format public-inbox supports, so
when we grab mailboxes from remote, they are in mboxrd format.
Git will try to guess the format of the mbox file, but it will ONLY
back-convert "\n>From " sequences when you specifically tell it that
it's "mboxrd" format, even when it's in fact "mboxo":
git am --patch-format=mboxrd
If you don't force the mboxrd format, git-am will preserve all escaped
"\n>From " lines as-is.
We've been previously operating on the assumption that git-am's mbox
support properly implements "mboxo", but this was wrong, resulting in
some commits like the following:
https://git.kernel.org/torvalds/c/137733d08f4a
This large-ish change ditches all internal use of Python's mboxo. When
asked to save mbox files, we will save them without any escaping, the
way git-am (i.e. git-mailsplit) espects them. The same goes when we're
outputting to stdout.
There is also a way now to pass -M to both "b4 am" and "b4 mbox" that
will save things as maildirs -- git-am supports this natively and thus
avoids any possible parsing ambiguities. You can set a config option
b4.save-maildirs=yes to make this the default behaviour.
The fallout of this is fairly benign, if annoying. There is no situation
in which a patch would have "\nFrom " as part of its body, so the
problem only affected commit messages. We will have a handful of these
sprinkled around the trees, and will hopefully not introduce any new
ones once everyone switches to the b4 version that outputs things in the
format git-am expects.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Per request, allow passing entire mbox files via stdin, allowing fully
pipe-through operation from something like mutt:
b4 am -sl -m - -o -
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/tools/YFETLu8TKWI2WlSF@hirez.programming.kicks-ass.net
|
|
Python's mailbox will not automatically remove mboxo escaping, so
perform this manually before passing the message to dkim for
verification.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
It has been a common request to support partial series rerolls where
someone sends an amended patch as a follow-up to a previous series,
e.g.:
[PATCH v3 1/3] Patch one
[PATCH v3 2/3] Patch two
\- Re: [PATCH v3 2/3] Patch two
Looks good, but please fix this $small_thing
\- [PATCH v4 2/3] Patch two
[PATCH v3] Patch three
Previously, b4 refused to consider v4 as a complete new series, but now
it will properly perform a partial reroll, but only in the cases where
such patches are sent as follow-ups to the exact same patch number in
the previous series:
[PATCH v3->v4 1/3] Patch one
[PATCH v4 2/3] Patch two
[PATCH v3->v4 3/3] Patch three
Reported-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/CAPcyv4ggbuHbqKV33_TpE7pqxvRag34baJrX3yQe-jXOikoATQ@mail.gmail.com
|
|
With multiple entry points for calling get_msgid(), we may end up trying
to read stdin multiple times. Call it once to ensure that this doesn't
happen.
Suggested-by: Morten Linderud <foxboron@archlinux.org>
Improved-by: Kyle Meyer <kyle@kyleam.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/tools/87im4fi55o.fsf@kyleam.com
|
|
Seems we have lost this check in the rewrite, so restore it to make sure
that we only check dkim if b4.attestation-check-dkim == 'yes' (default).
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Look in all of the brackets and reconstitute the subject based on what
we find there. This way we properly handle even the following:
Subject: [foo-list] [PATCH [RFC] v1 x/n] [RESEND] foo: do foo
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When we aggregate trailers, make sure that we track their originating
messages so we can properly check attestation on all of them.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Nothing really different in 0.3.0, just a few cleanups.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
The h= field headers may not be lowercased, so make sure we handle that
when looking if the date header is signed.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Fix logic error where we incorrectly reported "No key" when it was
actually "BADSIG".
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
We always want the datetime object to be tz-aware, but certain Date:
header formats result in timezone-naive variants. For those cases, just
pretend it's UTC, as that's sufficiently accurate for our purposes.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Catch KeyError instead of backtracing.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Remember to remove the temporary mbox if we're done with it.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
I expect that we'll have better keyring management tooling in the
future, but for now show some rudimentary information about patatt keys
used in a thread via --show-keys, e.g.:
b4 mbox --show-keys 20210511143536.743919-1-konstantin@linuxfoundation.org
b4 mbox --show-keys 20210507181322.172569-1-konstantin@linuxfoundation.org
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Many DKIM signatures just sign the Date: field and do not include the t=
timestamp. Properly handle this situation when we're checking for drift.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Looks like we lost this feature in the rewrite, so reimplement it again.
This commit also removes obsolete configuration options and sets the
default attestation check level at "softfail".
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Looks like subscripting list[] and dict[] for typing hints is not
supported in python-3.6.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
This has moved into patatt, so no need to duplicate functionality.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Move end-to-end attestation code into its own library: patatt. See
https://git.kernel.org/pub/scm/utils/patatt/patatt.git/about/
It is included into b4 as a submodule, but you will need to init it
first:
git submodule update --init
This change significantly simplifies our attestation code, dropping
thousands of lines of rather hairy code. Notably, patatt-style
attestation is incompatible with previous attestation implementations
done directly in b4, but that's just as well -- we've always marked it
as "experimental" and the lack of adoption was proving that we weren't
on the right path.
Next to come is keyring management and documentation.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
The install_requires entries use a compatible release operator. As an
example, "requests~=2.24.0" maps to a requirement of ">= 2.24.0 and ==
2.24.*". With the current version of requests (2.25.1), this leads to
a ContextualVersionConflict failure at runtime.
Allowing only Z to tick in version X.Y.Z seems unnecessarily strict
unless there are known problems with a particular release, and it
makes it more difficult for distributions to package b4. Drop the
trailing digit from all of the version identifiers, allowing both Y
and Z to increase.
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If we clean the to/cc headers to get rid of all unicode escaping, we run
into a Python bug that is unable to properly parse addresses, e.g.:
In [5]: from email import utils
In [6]: utils.getaddresses(['foo <foo@bar.com>'])
Out[6]: [('foo', 'foo@bar.com')]
In [7]: utils.getaddresses(['Shuming [范書銘] <shumingf@realtek.com>'])
Out[7]:
[('', 'Shuming'),
('', ''),
('', '范書銘'),
('', ''),
('', 'shumingf@realtek.com')]
If we store the headers as-is from the original message, we are less
likely to run into this bug, as all non-ascii sequences should be
qp-escaped in the original headers:
=?big5?B?U2h1bWluZyBbrVOu0bvKXQ==?= <shumingf@realtek.com>
This doesn't fix the underlying bug in Python, but works around it.
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When saving to a maildir, add option to filter out dupes. Note, that
this requires going through the entire maildir to collect message-ids,
so it's not going to be a great experience on large maildirs.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When -o is a valid maildir, then instead of saving an .mbox file add
messages to the maildir instead. This should allow "b4 mbox" to quickly
add threads to existing mail spools.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When we come across a pull request that doesn't list its base (i.e. not
generated using git-request-pull), we try to figure out the base
ourselves by doing merge-base. However, if the pull request is already
merged, then that is going to be a useless operation, so recognize this
situation and bail out early.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
It's a bad habit to exit anywhere other than from main() anyway. I
should fix all cases of that in order to be both more pythonic and
library-friendly.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Public-inbox emits mboxrd, but Python only understands mboxo, so we need
to convert from mboxrd to mboxo before passing the retrieved results to
mailbox.mbox.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/CAHk-=whRm2sKHeY-YQqxEJF=d9fGhnU2ajJs9i7CKC4feuPMTA@mail.gmail.com
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
We probably want to be able to tweak the output of git-format-patch
based on which list we're running it for (e.g. passing --minimal or
--histogram), so make it possible to pass extra parameters to the git
command.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|