Jump to: navigation, search

FLOP:CVE Monitoring

427 bytes removed, 10 months ago
no edit summary
Once a match is made, the <tt>cve-search</tt> collection and the portage package database (via {{package|app-portage/eix}}) can be combined to produce the data appropriate for a report.
The correct pattern for this is probably a <tt>truth table</tt>, with the above exact matching algorithm one example of generalized predicates at are applied to each cve document in the cvedb. A table pairing packages and predicates can they be interpreted via custom logical operations to yields sets of the packages to consider for further discussion or immediate issue creation.
== State ==
The <tt>cver</tt> tool is currently stateless: it takes some bytes and it makes some bytes. Of course, <tt>jira</tt> and <tt>mongoDB</tt> are not, and their states must be kept in sync. Does <tt>cver</tt> require its own set of <tt>mongoDB</tt> collections to maintain the sync? This We should probably the most challenging aspect of the proposalkeep it that way.  * every update A disk cache of the <tt>cveLRU memo-searchized python function </tt> database must trigger an update of <tt>jiraeix_xml</tt>* every CRUD path of <tt>cve-search</tt> must might be nice. It would have an equivalent CRUD path of <tt>jira</tt>* the sync of <tt>cve-search</tt> and <tt>jira</tt> must to be always provable However, we don't need to deal with <tt>cve-search</tt> directly: we can transform it into an intermediate state associated with <tt>cver</tt> that has its own pathswiped when eix was updated, and then make the equivalent <tt>jira</tt> path from those. We may just 'bulk transform' the <tt>cve-search</tt> to a (probably much simpler) schema more directly related to that of a <tt>jira</tt> issue. We just need a collection of what are essentially <tt>jira</tt> records, with meta data to control the synccourse.

Navigation menu