| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Track base crashes for (commit hash, config, arch) tuples.
|
| |
|
|
|
|
|
|
|
|
| |
Permit the following scenario: a finding is first submitted without a C
reproducer and then resubmitted again, now with one.
Ensure that it's only possible as long as the session is still in
progress.
Refactor Finding repository and service and adjust the tests.
|
| |
|
|
|
| |
Sometimes the patch series directly hint at the kernel tree they should
be applied to. Extract and remember this information.
|
| |
|
|
|
|
|
|
| |
Share not just the tree name (mainline, net, etc), but also the full URL
to check out the repository.
For that, add one more field to the Build entity and adjust email
reporting templates.
|
| |
|
|
|
| |
Take web dashboard URL from the config and use it to generate links for
logs, reproducers, etc.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The archive would be a useful source of debugging information.
Provide an HTTP endpoint that accepts a multipart form request with
the archived data.
Provide an *api.Client method to encapsulate the encoding of the data.
Add a test.
|
| |
|
|
|
|
| |
Once a new kernel revision becomes available, build it to figure out
whether it's buildable. This information will be used in the triage step
to figure out the right base kernel revision.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Provide an API to set up the reporting of finished sessions for which
syz-cluster collected reportable findings.
The actual sending of the results is to be done in a separate component
that would:
1) Call Next() to get the next report to send.
2) Call Confirm() to confirm that the report has been sent.
3) Call Upstream() if the report has been moderated and needs to be sent
to e.g. public mailing lists.
|
|
|
This will facilitate its reuse in tests.
|
