| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
If the RPM name is missing a .nonfree or .tainted suffix, warn the user
that this might be the reason.
|
| |
|
|
|
| |
The modified value starts off from SVN, but if a more recent value is
found in the status file, use that instead.
|
| |
|
|
|
|
| |
The parsing overhead is now spread over multiple cores when available,
dramatically reducing the time to read them all. mgaadv list is twice as
fast now on one test machine, for example.
|
| |
|
|
|
| |
Lacking a newline corrupts the file when the ID is appended. Return an
error if this case is detected.
|
| |
|
|
|
|
|
|
|
| |
The modification date helps track if an advisory was changed after
initial publication. This is especially important for OSV users who need
the modification date in the vulns.json index to determine whether an
existing advisory was updated so they can download the update. Also,
keep "ref" (pointing to bug number) in all advisories, not just the TODO
ones.
|
| |
|
|
|
| |
An argument to output_pages() was missing. This command probably never
worked.
|
| | |
|
| |
|
|
| |
An advisory must come with at least one fixed package.
|
| |
|
|
|
|
|
|
|
|
| |
This generates templated files using some parallelism, reducing the
total mksite time to less than half in my tests. Increasing parallelism
even further is possible, but would make the code harder to understand.
The obvious technique of generating each templated file in its own
process is actually far slower because the overhead of process creation
dwarfs the time spent processing the template, which is on average very
small and quick.
|
| |
|
|
|
|
| |
The JSON schema is simple and compatible with the one published in the
Go Vulnerability Database. Security advisories and bugfix advisories
each have their own index.
|
| | |
|
| |
|
|
|
|
| |
Open Source Vulnerability format is a standard for publishing
vulnerabilities in Open Source projects and is defined at
https://ossf.github.io/osv-schema/
|
| | |
|
| |
|
|
|
| |
This is now possible since 'advisory' was made a keyword,
while it used to be written in the Whiteboard field.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
I'm forever missing this information and having to manually find which
advisory I'm actually looking at, let's just print it out.
|
| | |
|
| |
|
|
|
|
| |
Allow the operator to optionally post to Bugzilla (and remove the
validated_update keyword) if the id assignment fails during cross
checks.
|
| |
|
|
|
|
| |
This will allow QA team to post automated messages to BZ when trying
to assign IDs and the cross check fails for whatever reason
(typically deependent bugs or SRPM check failures).
|
| |
|
|
| |
The intention is to post this to bugzilla.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes a batch of updates will contain some updates dependent
on other updates to be pushed at the same time.
Until the update is actually pushed, the bug will not be closed.
Thus a chicken and egg scenario. While we could evaluate which bugs
are in the update queue to be processed and make sure we process them
first and add them to an internal whitelist, this would require talking
to bugzilla for all bugs first, then processing them.
This approach is definitely possible and desirable and when a
'process-all' verb is added, this will likely be done.
But in the short term, deferring to the user is easier!
|
| | |
|
| | |
|
| |
|
|
| |
This is thanks to a small, but simple API available via http://repository.mageia.org/
|
| | |
|
| |
|
|
|
| |
Very minor issue but we may as well close the bugs in order
of advisory.
|
| |
|
|
|
| |
This currently integrates with subversion, but it will be trivial
to switch it to git.
|
| | |
|
| |
|
|
| |
mga#13859
|
| |
|
|
| |
mga#13859
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently this no longer works with BZ 4.4 and it now relies on a token
to authenticate future requests.
We now maintain this token and ensure we pass it in with future
requests.
Also strip of the xmlrpc.cgi part of the BZ URL so we can use it
to validate bug URLs in the future.
mga#13859
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This shells out to a separate command that actually implements this.
Such a tool exists already in mgatools called 'mga-move-pkg'
|
| |
|
|
| |
This should mean that emails are sent out in sequential order
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Possible filters are :
- advisory type
- distribution release
- package name
- CVE
- media
|
| | |
|