- Jan 18, 2024
-
-
It's been deprecated officially for a week or so, but hasn't been actually wired into Advisories, as we've had deps.dev's data which is superior. By removing this, we'll also hopefully reduce the time it takes folks to build their databases, as osv.dev lookups were fairly slow.
-
Jamie Tanna authored
As raised in #421, it'd be handy to announce whether the release introduces breaking changes, until we've got to a point where we're a stable release. To do this is temporarily a bit of a hack, as we're waiting for upstream to support this - via some contributions I've raised upstream - so in the meantime we can pin to a pre-built binary and overwrite the downloaded `hooks-goreleaser` with my fork. This flags whether a major-inducing change is part of the release, automagically detected by go-semantic-release. Closes #421.
-
Jamie Tanna authored
-
- Jan 17, 2024
-
-
Jamie Tanna authored
For instance with `internal/endoflifedate/db/schema.sql`, where it's the Dependabot-related tables that are deprecated.
-
-
-
-
-
-
-
-
-
Jamie Tanna authored
As it hasn't actually been working as expected
😅 -
Jamie Tanna authored
We can use `blocks` as a slightly nicer way of formatting output. This will release to the DMD Slack, and be an improved notification compared to the GitLab/RSS feed options.
-
Jamie Tanna authored
-
Jamie Tanna authored
-
- Jan 16, 2024
-
-
Similar to the `policy_violations` table, this introduces a single view of all Advisories data that affects the dependencies in the database. This makes it simpler to query all package advisories by "simply" querying the `advisories` table, which includes all relevant information for package advisories. This allows us to remove a lot of duplication in our SQL queries for looking up advisories data, making sure that it's a much simpler process for querying data. We can still directly query the tables as before - following the example from `RetrievePackageAdvisoriesFromSeparateTables` - if we need to. We can also remove the references in `policy_violations` that indicates that `policy_violations` is better than `advisories`, as it no longer is! Because we want to make it easier to surface the `eol_from` and `supported_until` dates, too, we should add them as nullable fields to `advisories` - and defaulting it as `NULL` for tables that don't surface the data. Closes #414.
-
BREAKING CHANGE: For some time, I've regretted the naming choice, as it can be a little confusing because the `advisories` table doesn't include all the advisories present in the dependency trees. This now makes it more explicit by using the new name `custom_advisories`.
-
It's not necessary, especially as we now have better database schema documentation, so we can remove it.
-
Jamie Tanna authored
-
Jamie Tanna authored
-
Jamie Tanna authored
This has been accidentally misaligned for some time, and will cause some confusion when querying the data. To keep this more consistent, we should make sure we return a known `advisory_type`.
-
Jamie Tanna authored
Closes #413.
-
Jamie Tanna authored
-
Jamie Tanna authored
-
Jamie Tanna authored
-
Jamie Tanna authored
-
Jamie Tanna authored
-
Jamie Tanna authored
-
Jamie Tanna authored
-
Jamie Tanna authored
-
As part of #412, it is noted that GitHub validates the pURL types[0] that are sent to it, only allowing "known" pURL types to be consumed. To make `renovate-to-sbom` a little more strict, we can use a new flag, `only-include-known-purl-types`, which will trim the dependency output to ensure that This also adds a log notification to make sure it's visible that they're being skipped. We can use a `map` of `struct{}` to: - make sure we have an indication of the pURL `type`s that are skipped - are removing duplicates in the list of names - reduce the allocations with a `struct{}` Closes #412. [0]: https://github.com/package-url/purl-spec/issues/286
-
- Jan 15, 2024
-
-
Jamie Tanna authored
Closes #402.
-
- Jan 12, 2024
-
-
Jamie Tanna authored
-
Jamie Tanna authored
To allow us to more appropriately target organisational policies around i.e. whether a repository is public, used for sensitive purposes, or otherwise, we can now consume the data available in `repository_metadata` with our Policies.
-
Jamie Tanna authored