search

ossf / osv-schema

Open Source Vulnerability schema.
https://ossf.github.io/osv-schema/
Apache License 2.0
176 stars 75 forks source link

Add SwiftURL ecosystem. #188

Closed oliverchang closed 1 year ago

oliverchang commented 1 year ago

Per

https://developer.apple.com/documentation/packagedescription/package/dependency https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html#package-dependency

Putting "URL" in the name to make this consistent with how it's actually defined using Package.Dependency.

There are some changes coming as part of https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md, and we'll likely need to define a new ecosystem for that once it's finalized, as it looks like the identifiers are moving to a Scope.Name format.

Fixes #170.

oliverchang commented 1 year ago

@darakian PTAL :)

darakian commented 1 year ago

I think we should add some language about versioning

https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html#package-dependency-requirement states

The version rule requires Swift packages to conform to semantic versioning. To learn more about the semantic versioning standard, visit semver.org.

My understanding is that there is no hard enforcement of that requirement https://github.com/github/advisory-database/issues/460#issuecomment-1177169685 but perhaps stating something like unless otherwise specified versions conform to semver 2.0 would work

Otherwise 👍

oliverchang commented 1 year ago

I think we should add some language about versioning

https://docs.swift.org/package-manager/PackageDescription/PackageDescription.html#package-dependency-requirement states

The version rule requires Swift packages to conform to semantic versioning. To learn more about the semantic versioning standard, visit semver.org.

My understanding is that there is no hard enforcement of that requirement github/advisory-database#460 (comment) but perhaps stating something like unless otherwise specified versions conform to semver 2.0 would work

Otherwise 👍

Thanks for the additional context @darakian ! I just added a sentence on versions being git tags that conform to Semver 2.0. Judging by the thread you linked it seems like the only reasonable approach is to just ignore all non-SemVer versions, and I think the current wording suffices there.

darakian commented 1 year ago

I'm not going to go as far as saying it's the ONLY reasonable course, but I've got no complaints on assuming semver 2.0 for all advisories in the ecosystem. 😄

oliverchang commented 1 year ago

Yeah, but I do think it's the only practical approach. Without strict or well defined versioning schemes, we can't do much other than making older/non-conforming versions out of scope.

@chrisbloom7 WDYT?