Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add the concept of "trusted" vendors / frameworks / SDKs #5105

Open
sschuberth opened this issue Feb 25, 2022 · 4 comments
Open

Add the concept of "trusted" vendors / frameworks / SDKs #5105

sschuberth opened this issue Feb 25, 2022 · 4 comments
Labels
analyzer About the analyzer tool enhancement Issues that are considered to be enhancements

Comments

@sschuberth
Copy link
Member

When scanning code for e.g. Android or iOS apps, there are some reoccurring fundamental SDK dependencies which usually contains a lot of source code. It makes little sense to scan these dependencies over and over again for (small) version changes.

To address the issue, I believe it's fair to assume that if a company decided to develop e.g. Android / iOS apps, the (business) decision to accept the use of the required SDKs has effectively already been made. With that in mind, it would be nice if ORT had a concept of "trusted vendors" where a copyright holder and license need to be specified for whole SDK / framework, and then scanning for all belonging / matching packages would be skipped.

This is conceptually similar to the existing mechanism of curating authors and concludedLicense in conjunction with enabling skipConcluded. A reason why this existing mechanism is not sufficient is that curations can only use ranges / wildcards as part of the version. However, in order to trust e.g. the Amazon AWS SDK as a whole, which includes a component like Maven:com.amazonaws:aws-java-sdk-models:1.12.162, we'd also need to allow wildcards for the name (at least), so that authors and concludedLicense could be curated for something like Maven:com.amazonaws:aws-*:*.

So a proposal to support the concept of "trusted" vendors / frameworks / SDKs would be to extend the curation logic to also accept wildcards / regexes for the name.
@sschuberth sschuberth added enhancement Issues that are considered to be enhancements analyzer About the analyzer tool labels Feb 25, 2022
@sschuberth
Copy link
Member Author

Another proposal just came to my mind: "Trusted" in this context should mean that we trust the declared license, and thus also do not need to scan to get the detected licenses, even if no explicit concluded license is present.

@sschuberth
Copy link
Member Author

sschuberth commented Apr 25, 2022 •
edited

It has slipped my mind that we allow the name of a package curation to be empty, so we can conclude the license (and set authors) for whole namespaces like Maven:com.amazonaws or Maven:com.android.tools, and then leverage skipConcluded to express "trust".

So, it that mechanism maybe already good enough?

Note that this would still require separate curations for e.g. Maven:com.google.android.datatransport and Maven:com.google.android.gms etc., and we could not say Maven:com.google.android.* (or similar).

sschuberth added a commit that referenced this issue Oct 19, 2022
@sschuberth
PackageCurationTest: Test applicability with an empty name / version
c20865b 
This is in context of [1].

[1]: #5105 (comment)

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
@sschuberth
Copy link
Member Author

So, it that mechanism maybe already good enough?

I believe yes. Also see #5971.

sschuberth added a commit that referenced this issue Oct 20, 2022
@sschuberth
PackageCurationTest: Test applicability with an empty name / version
a949115 
This is in context of [1].

[1]: #5105 (comment)

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
@sschuberth sschuberth mentioned this issue Oct 20, 2022
Merged
sschuberth added a commit that referenced this issue Oct 20, 2022
@sschuberth
PackageCurationTest: Test applicability with an empty name / version
bdc2f9c 
This is in context of [1].

[1]: #5105 (comment)

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
sschuberth added a commit that referenced this issue Oct 20, 2022
@sschuberth
PackageCurationTest: Test applicability with an empty name / version
e63f12b 
This is in context of [1].

[1]: #5105 (comment)

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
sschuberth added a commit that referenced this issue Oct 20, 2022
@sschuberth
PackageCurationTest: Test applicability with an empty name / version
82993c1 
This is in context of [1].

[1]: #5105 (comment)

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
@sschuberth
Copy link
Member Author

sschuberth commented Nov 7, 2022 •
edited

So, it that mechanism maybe already good enough?

I believe yes. Also see #5971.

Turns out that curations with empty name / version are not enough to fully support this use-case, so I'm reopening this.

A problem arises e.g. with NuGet packages which generally don't have a namespace as part of their id (same for Go, Cargo, Conan, and more). See for example this list of ids:

  • id: "NuGet::System.AppContext:4.1.0"
  • id: "NuGet::System.Buffers:4.0.0"
  • id: "NuGet::System.Collections:4.0.11"
  • id: "NuGet::System.ComponentModel:4.0.1"
  • id: "NuGet::System.Console:4.0.0"
  • id: "NuGet::System.Diagnostics.Contracts:4.0.1"
  • id: "NuGet::System.Dynamic.Runtime:4.0.11"
  • ...

The actual goal would be to conclude the license and set the author for all "System" packages. Having individual curations, even with empty versions, is not feasible as there are a lot of these packages. Also, leaving both the name and version empty is no option, as that would result in NuGet::: which would match all NuGet ids, also non-"System" ones.

So we would either need to

@sschuberth sschuberth reopened this Nov 7, 2022
This was referenced Nov 8, 2022
Merged
Closed
This was referenced Apr 25, 2023
Closed
Merged
@sschuberth sschuberth mentioned this issue May 19, 2023
Open
@sschuberth sschuberth mentioned this issue Aug 17, 2023
Closed
@sschuberth sschuberth pinned this issue Jan 11, 2024
sschuberth added a commit to oss-review-toolkit/ort-config that referenced this issue Jan 30, 2024
@sschuberth
feat: Allow namespace-level package curations
b45aa63 
This is required to support e.g. the use-case described at [1]. The
`toCurationPath()` function already supports empty package names and
uses `_.yml` as a file name in that case.

[1]: oss-review-toolkit/ort#5105 (comment)

Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth added a commit to oss-review-toolkit/ort-config that referenced this issue Jan 31, 2024
@sschuberth
feat: Allow namespace-level package curations
fb271bf 
This is required to support e.g. the use-case described at [1]. The
`toCurationPath()` function already supports empty package names and
uses `_.yml` as a file name in that case.

[1]: oss-review-toolkit/ort#5105 (comment)

Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
analyzer About the analyzer tool enhancement Issues that are considered to be enhancements
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sschuberth