-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Improvers #701
Labels
Comments
Current problem
Proposed solution
class Improver:
@classproperty
def qualified_name(cls):
"""
Fully qualified name prefixed with the module name of the improver used in logging.
"""
return f"{cls.__module__}.{cls.__qualname__}"
@property
def interesting_queryset(self) -> QuerySet:
"""
Return QuerySet for the advisories this improver is interested in
"""
raise NotImplementedError
def improve(self, args) -> isImproved?:
"""
Generate and return Inferences for the given advisory data
"""
raise NotImplementedError
def process(self, args) -> isProcessed?:
"""
Entrypoint for the improver. Consume ``interesting_queryset`` and use ``improve`` to
process improvement.
"""
raise NotImplementedError
class AdvisoryImprover(Improver):
def process(record):
"""
An atomic transaction that updates both the Advisory (e.g. date_improved)
and processes the given inferences to create or update corresponding
database fields.
This avoids failing the entire improver when only a single inference is
erroneous. Also, the atomic transaction for every advisory and its
inferences makes sure that date_improved of advisory is consistent.
"""
# This is somewhat the same method that exists currently in the framework for processing all improvers
# Although, it takes care of TOCTOU as stated above
... Now different improvers can be written by implementing the This way we have a concrete design for improvers, independent ways of handling different kinds of improvements (via the |
Related: #1068 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Improvers are constraining.
For eg: Improving reference id to reference URL, improving vuln data (not an advisory).
The problem is with both
interesting_advisories
andget_inferences
where both of them expectAdvisoryData
.Improvers cloud be split in
TOCTOU conditions are also present, we check at
interesting_advisories
and use the value atget_inferences
. Could do https://docs.djangoproject.com/en/4.0/ref/models/querysets/#select-for-update to avoid TOCTOU closer where things are going to change. This would mean returning a QuerySet frominteresting_advisories
might not be an ideal case.Current implementation could become a subclass which is a advisory based improver.
(via: https://github.com/nexB/vulnerablecode/wiki/WeeklyMeetings#meeting-on-tuesday-2022-04-19-at-1000-utc)
The text was updated successfully, but these errors were encountered: