| Age | Commit message (Collapse) | Author |
|---|
|
In order to avoid some of the more obscure charset encoding problems, we
switched to using as_string() for generating messages before saving them
in an mbox file. However, this uncovered a bug where the unixfrom was
not actually generated and saved, despite as_bytes() and as_string()
supposedly behaving identically.
See:
https://docs.python.org/3/library/email.message.html#email.message.EmailMessage.as_string
This commit fixes the problem by properly setting the unixfrom and using
the recommended (and hopefully less buggy) email.generator interface
when saving mailboxes.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Since we're not caring about 2.x compatibility, pytest seems to be a
good candidate for this job. Obviously, there's a lot of ground to
cover, but the goal is to do all future modifications with tests added
so we can reduce regressions.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When returning sloppy trailers, make sure we always return a 4-member
list, which includes the provenant LoreMessage itself.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Returning a simple list of messages from get_am_ready broke a few other
auxiliary functions invoked when run with -o- or -Q.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
This is a kludge that I'm putting in place to avoid hitting an encoding
bug with Python. We really shouldn't be making a fake RFC2822 message
just so we can parse it again right away, so this is a temporary measure
until I refactor how it's done.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
I'm not sure if it's a good strategy to use GitHub usernames and
username@github.com addresses for this purpose, as we really need to be
able to reach someone when we process their submissions. However, for
the time being at least don't output None.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
You can now do "b4 pr https://github.com/foo/bar/pull/NNN" and have it
fetched into FETCH_HEAD. However, this also works when combined with
--explode, which is the main reason for this feature's existence.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
If the FETCH_HEAD is not signed, then keyid is going to be None. Don't
attempt to look up UIDs in such situations.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
I've been working on a way to automatically convert pull requests into
series, complete with mailing them out to arbitrary destinations. This
would allow folks to send a pull request to a dedicated list and have it
automatically converted into a well-formed series.
This is a tentative implementation that relies on git-send-email to do
most of the heavy lifting. I have misgivings about using git-send-email
for this purpose, but it does reduce the amount of duplicated code we
would have otherwise had to write, and allows us to hook into things
like tocmd/cccmd, etc.
For example, adding the following to your .git/config:
[sendemail "autopr"]
smtpserver = [your.server.here]
smtpserverport = 587
smtpencryption = tls
smtpuser = [your-user]
smtppass = [your-pass]
transferEncoding = 8bit
suppressFrom = yes
confirm = never
validate = no
tocmd = "$(git rev-parse --show-toplevel)/scripts/get_maintainer.pl --norolestats --nol"
cccmd = "$(git rev-parse --show-toplevel)/scripts/get_maintainer.pl --norolestats --nom"
This would allow doing the following:
b4 pr -e -f "AutoPR Exploder <autopr@yourdomain.here>" -s autopr [--dry-run]
The pull request will be exploded into a patch series and sent to all
the proper destinations as returned by get_maintainer.pl. We construct
the message headers in a way that allow regular code review and "b4 am"
usage after the auto-exploded series is sent out.
If testing goes well, we'll implement this as a kernel.org service and
then hook a similar implementation via Gitlab/Github.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
This moves maildir saving code into __init__.py so that we can benefit
from it via other subcommands, such as pr.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
PyCharm is unhappy with PEP conformance, so shuffle things around a bit
to satisfy it.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
We can pass a logger object to dkim.verify() which will be used to
report internal errors and debugging info. This can be helpful when
investigating DKIM verification issues but is probably not wanted during
normal operation so the log level of each message is reset to DEBUG.
Each message is also prefixed with 'DKIM: ' to identify its origin when
debug output is enabled.
Signed-off-by: Paul Barker <paul@pbarker.dev>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210607100252.8253-3-paul@pbarker.dev
|
|
As recently found in patatt [1], mail gateways and archivers may mangle
headers like DKIM-Signature if they are sent as an excessively long
line. An example of this occuring was found when the DKIM-Signature
header generated by Microsoft Office 365 collided with the
header re-encoding performed by lists.sr.ht when generating mbox
archive files. This encoding causes dkim.verify() to fail.
The Python email.header module provides the decode_header() and
make_header() functions which can be used to handle MIME encoded-word
syntax or other header manglings which may occur. Fixing up the header
content using these functions before calling dkim.verify() allows the
verification to succeed.
[1]: https://lore.kernel.org/tools/20210531140539.7630-1-paul@pbarker.dev/
Signed-off-by: Paul Barker <paul@pbarker.dev>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210607100252.8253-2-paul@pbarker.dev
|
|
When we discover that a message can only be attested after we trim the
body, we *must* set the body to that version, otherwise an attacker
could append arbitrary content past the l= value boundary. We already do
this in the current form, but we weren't properly handing in-body
headers like From: and Subject: that are used to indicate to git the
patch author vs. committer.
This patch set fixes that and also streamlines a few other places where
we were already relying on git mailinfo calls.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
Before:
✓ [PATCH v2 1/8] selftests/x86: Test signal frame XSTATE header corruption handling
✓ [PATCH v2 2/8] x86/fpu: Prevent state corruption in __fpu__restore_sig()
✓ [PATCH 3/8] x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
✓ [PATCH 4/8] x86/fpu: Limit xstate copy size in xstateregs_set()
✓ [PATCH v2 5/8] x86/fpu: Sanitize xstateregs_set()
✓ [PATCH 6/8] x86/fpu: Add address range checks to copy_user_to_xstate()
✓ [PATCH 7/8] x86/fpu: Clean up the fpu__clear() variants
✓ [PATCH 8/8] x86/fpu: Deduplicate copy_xxx_to_xstate()
After:
✓ [PATCH v2 1/8] selftests/x86: Test signal frame XSTATE header corruption handling
✓ [PATCH v2 2/8] x86/fpu: Prevent state corruption in __fpu__restore_sig()
✓ [PATCH v1->v2 3/8] x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
✓ [PATCH v1->v2 4/8] x86/fpu: Limit xstate copy size in xstateregs_set()
✓ [PATCH v2 5/8] x86/fpu: Sanitize xstateregs_set()
✓ [PATCH v1->v2 6/8] x86/fpu: Add address range checks to copy_user_to_xstate()
✓ [PATCH v1->v2 7/8] x86/fpu: Clean up the fpu__clear() variants
✓ [PATCH v1->v2 8/8] x86/fpu: Deduplicate copy_xxx_to_xstate()
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When a message has a developer signature but is failing the signature
check, rerun it again with trim_body. If that passes, we know that the
signature is failing due to mailing list junk appended to the bottom of
the message. In that case, automatically trim the message body so we
have exactly what the developer attested and signed.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
The cache aging for threads was not running resulting in failures to
fetch new messages in threads. Fix the empty cache check which should
be for no '.msgs' directories.
Fixes: 4950093c0c3e ("Don't use mboxo for anything")
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210601200835.940887-1-robh@kernel.org
|
|
save_git_am_mbox() replaces 'From mboxrd@z ' with 'From git@z ' to
make it clear that the output format is not mboxrd. However, all
occurrences in the message are replaced, corrupting patches that
contain 'From mboxrd@z '. Restrict the replacement to the first line
of the message.
Signed-off-by: Kyle Meyer <kyle@kyleam.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210528042635.24959-1-kyle@kyleam.com
|
|
I think we are ready to go with the 0.7.0 release. There's always more
tweaks to add, but at this point we can benefit from wider usage.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
When the signature is validated using the default keyring, run an
additional check on the UIDs and show the discrepancy if the identity
used in the X-Developer-Signature header is different from the UIDs we
have on the key.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
The newer version of public-inbox is not injecting its own List-Archive
headers, so stop relying on it for any purpose.
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|