fedcode-next: Code, UI and models to curate PURL and VERS package version range for packages affected and fixing a vulnerability
There is some UI design need to make this efficient. We could also display various advisory data sources side by side to help correct the data, and also we should validate correctness of PURLs and VERS and extend to other PURLs when relevant.
At this stage we only miss the UI.
class AdvisoryToDoV2(models.Model):
"""Track the TODOs for advisory/ies that need to be addressed."""
# Since we can not make advisories field (M2M field) unique
# (see https://code.djangoproject.com/ticket/702), we use related_advisories_id
# to avoid creating duplicate issue for same set of advisories,
related_advisories_id = models.CharField(
max_length=64,
help_text="Computed unique content ID that identifies the related advisories.",
)
advisories = models.ManyToManyField(
"AdvisoryV2",
through="ToDoRelatedAdvisoryV2",
related_name="advisory_todos",
help_text="Advisories for this TODO.",
)
issue_type = models.CharField(
max_length=50,
choices=ISSUE_TYPE_CHOICES,
db_index=True,
help_text="The issue type that needs to be addressed.",
)
issue_detail = models.TextField(
blank=True,
help_text="Additional details about the issue.",
)
created_at = models.DateTimeField(
auto_now_add=True,
help_text="Timestamp indicating when this TODO was created.",
)
resolved_at = models.DateTimeField(
null=True,
blank=True,
help_text="Timestamp indicating when this TODO was resolved.",
)
resolution_detail = models.TextField(
blank=True,
help_text="Additional detail on how this TODO was resolved.",
)
curation_advisory = models.ForeignKey(
"AdvisoryV2",
null=True,
blank=True,
on_delete=models.SET_NULL,
related_name="curated_todos",
help_text="The advisory that was created/updated to resolve this TODO.",
)
status = models.CharField(
max_length=20,
default="open",
help_text="The current status of the TODO item.",
)
class Meta:
unique_together = ("related_advisories_id", "issue_type")
According to me, the solution for resolving a Todo should be a "curation_advisory" which is an advisory created by a "staff" user or "admin" user through an authenticated API endpoint. Since a "curation_advisory" is created by staff or admin, we do not need to assign a status such as "pending" or "under consideration".
All "advisories" that had a Todo will have a "curation_advisory" in the UI and API. It's upto users to trust the curation or the advisory provided by other advisory sources.
According to me, the solution for resolving a Todo should be a "curation_advisory" which is an advisory created by a "staff" user or "admin" user through an authenticated API endpoint. Since a "curation_advisory" is created by staff or admin, we do not need to assign a status such as "pending" or "under consideration".
Maybe we can have a git repo where we store these manual curations and folks can propose contributions by opening pull requests. The curation advisory would be attributed to author, we already have source field for that in our advisory data. That way we can import this curation using the importer and it will also be publicly available for others to import into their own private VCIO instances.
Excellent idea to have this repo, advisories coming from this repo would have AdvisoryData and advisories that this Advisory is a curation for.
IMO this shall be an improver pipeline to do all the import and associations.