| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
If the author of a patch series provides a base-commit tag, extract and store the hash.
|
| |
|
|
|
| |
It's not done transparently by the email library.
Add a test that verifies the result.
|
| |
|
|
| |
./tools/syz-env bin/golangci-lint run ./... --fix
|
| |
|
|
| |
These will be necessary to properly route emails in dashboard.
|
| |
|
|
| |
This will allow us to easily identify them.
|
| |
|
|
|
|
| |
For some specified inboxes, forward the emails that contain syz
commands.
Add tests to verify the behavior.
|
| |
|
|
|
|
| |
It changed recently and it broke our email discussion link extraction.
Closes #5431.
|
| |
|
|
| |
This is not needed for the actual operation.
|
| |
|
|
|
| |
We used to support this only for external reportings, but let's
auto-guess these parameters for all incoming patch testing commands.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let bug labels come in three flavours:
1) Bug labels with multiple values (e.g. `subsystems`).
2) Bug labels with only one value (e.g. `prio`).
3) Flags.
Let users configure bug labels via email by issuing the following
commands:
#syz set subsystems: abc, def
#syz set no-reminders
#syz unset no-reminders
Also let users set tags for invididual bugs in reported bug lists:
#syz set <1> some-tag
|
| |
|
|
|
|
|
|
|
|
| |
It's not always convenient that we can receive only one command per
email.
Update pkg/email parsing code to extract everything which there is.
Update reporting_email.go to handle multiple email commands. Set
different limits for bug email commands and bug list commands.
|
| |
|
|
|
| |
We anyway already extract this information, there's no sense in
extracting it again in other places.
|
| |
|
|
|
| |
Even though the standard seems to prohibit it, there are real world
cases of messages with multiple IDs in an "In-Reply-To" header.
|
| |
|
|
|
|
|
|
|
| |
Extract Date and InReplyTo.
Extract not just one, but multiple BugIDs from multiple sources:
1) Email addresses in From/To/Cc.
2) Email addresses in Body.
3) Dashboard links in Body.
|
| |
|
|
|
|
| |
If the `#syz regenerate` command is sent in response to a bug list,
dashboard will schedule its regeneration the next time the corresponding
cron job is run.
|
| |
|
|
| |
For now this command will be used to manually set bug's subsystems.
|
| | |
|
| | |
|
| |
|
|
|
| |
Currently the function returns the values that are not being used
anywhere. Refactor it.
|
| |
|
|
| |
It look like email clients can insert newlines there if the line is too long.
|
| |
|
|
|
|
| |
Handle two types of mailing list responses:
* From contains the original author.
* From is replaced by the mailing list.
|
| |
|
|
|
|
|
| |
Sometimes we call it before accessing emails, sometimes we do not. This
is prone to errors.
Always canonicalize From and Cc, this should somewhat reduce the problem.
|
| | |
|
| |
|
|
|
|
| |
There was a precedent of using:
syz fix: repo \t commit
This was rejected as error. Support \t between tokens.
|
| |
|
|
|
| |
Add "#syz unfix" command that undoes "#syz fix" effects
and resets any existing fixing commits.
|
| |
|
|
|
| |
Some users spell the command as "#syz-dup:".
Support this and few more variations.
|
| |
|
|
|
|
| |
Several users attempted this and there does not seem
to be any reason to not allow this.
So parse out command from subject as well.
|
| |
|
|
|
|
|
| |
After commit 9ad9ef29caa52714dd5faff167e4b61643e40a7e
we started saying "your command '3' is accepted"
because we use numbers now. Keep string representation
of the command when parsing and use it in reply emails.
|
| |
|
|
|
| |
Users have misspelled test: multiple times.
Accept commands without the colon.
|
| |
|
|
|
|
|
|
|
| |
Add "#syz uncc" command as a safety handle.
The command allows sender to unsubscribe from all future communication on the bug.
Linus mentioned possibility of saying "I'm not the right person for this report"
in the context of bug reminders:
https://groups.google.com/d/msg/syzkaller/zYlQ-b-QPHQ/AJzpeObcBAAJ
|
| |
|
|
|
|
|
| |
This just cleans up existing warnings.
vetshadow is not enabled yet because it crashes.
Update #538
|
| |
|
|
|
|
| |
We did not handle quoted-printable because mime package handles it.
But we can have a non-mime email in quoted-printable.
Simply handle it always, it's not hard.
|
| |
|
|
|
|
|
| |
120 columns looks like a reasonable limit
and requires few changes to existing code.
Update #538
|
| |
|
|
|
| |
git-send-email sends emails without Content-Type,
let's assume it's text.
|
| |
|
|
| |
Just unnecessary clutter.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Support the new scheme of associating fixing commits with bugs.
Now we provide a tag along the lines of:
Reported-by: <syzbot+a4a91f6fc35e102@syzkaller.appspotmail.com>
The tag is supposed to be added to the commit.
Then we parse commit logs and extract these tags.
The final part on the dashboard is not ready yet,
but syz-ci should already parse and send the tags.
|
| |
|
|
|
|
|
|
|
|
| |
Allow:
full-commit-title-on-next-line
This allows commit titles between 70 and 80 cols with gmail.
Also be more permissive wrt spaces and tabs.
|
| |
|
|
| |
We've got such email.
|
| | |
|
| |
|
|
|
| |
We currently handle base64 only for attachments,
but text/plain body can also be base64-encoded.
|
| |
|
|
|
|
|
| |
1. Allows sending emails upstream.
2. Filter out duplicate emails coming from our mailing lists.
3. Increase retry attempts for email commands
(don't want them to fail due to concurrent crash reports from managers).
|
| |
|
|
|
|
|
|
|
| |
- save Message-ID and use In-Reply-To in subsequent messages
- remember additional CC entries added manually
- don't mail to maintainers if maintainers list is empty
- improve mail formatting and add a footer
- implement upstream/fix/dup/invalid commands over email
- add tests
|
| |
|
|
| |
Compare email addresses without full name.
|
| |
|
|
| |
Replace extractBugID function with more general AddAddrContext/RemoveAddrContext.
|
| |
|
|
| |
Otherwise we we send each reply to ourselves and receive it again.
|
| | |
|
|
|
Parse extracts all potentially interesting info from an incoming email.
|