Satisfies ignores a LicenseRef alternative of an OR
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
Research direction
The bug is in the Satisfies function's handling of LicenseRef within OR and AND expressions. Start by examining the spdxexp package, particularly the Satisfies function and its helpers for evaluating expressions. The provided test cases in the issue body show the exact failure; run them to confirm. Look at how license identifiers are matched, focusing on the logic for OR and AND nodes when a LicenseRef is involved. The fix likely involves adjusting the comparison or normalization step for LicenseRef values.
Written by the indexing model from the issue text.
Description
A LicenseRef that is an alternative of an OR does not count towards Satisfies: MIT OR LicenseRef-x is not satisfied by an allowed list of just LicenseRef-x, and MIT AND (LicenseRef-a OR LicenseRef-b) is satisfied by MIT alone, although neither reference is allowed. The same two shapes with list identifiers in place of the references give the expected answers:
package main
import (
"fmt"
"github.com/github/go-spdx/v2/spdxexp"
)
func main() {
cases := []struct {
expr string
allowed []string
}{
{"MIT OR LicenseRef-x", []string{"LicenseRef-x"}},
{"MIT OR ISC", []string{"ISC"}},
{"MIT AND (LicenseRef-a OR LicenseRef-b)", []string{"MIT"}},
{"MIT AND (ISC OR BSD-3-Clause)", []string{"MIT"}},
}
for _, c := range cases {
ok, err := spdxexp.Satisfies(c.expr, c.allowed)
fmt.Printf("Satisfies(%q, %q) = %v, %v\n", c.expr, c.allowed, ok, err)
}
}
Output:
Satisfies("MIT OR LicenseRef-x", ["LicenseRef-x"]) = false, <nil>
Satisfies("MIT OR ISC", ["ISC"]) = true, <nil>
Satisfies("MIT AND (LicenseRef-a OR LicenseRef-b)", ["MIT"]) = true, <nil>
Satisfies("MIT AND (ISC OR BSD-3-Clause)", ["MIT"]) = false, <nil>
I expected the first call to return true, like the second, and the third to return false, like the fourth. Putting the reference first (LicenseRef-x OR MIT) gives the same false, and the third result means an expression that requires a license absent from the allowed list passes the check.
Tested on v2.7.0 and on current main (48a80b3).
BTW, this was found by an automated program that writes property-based tests for various open source projects using hegel (but it has been reviewed by hand before reporting). We've also potentially found (but not yet hand validated) 15 other bugs in go-spdx. You can see the tests at https://github.com/hegeldev/hegel-zoo/tree/main/targets/go/go-spdx. Let us know if you would like us to file the other bugs found and/or contribute the tests. NB the tests are currently LLM generated and probably not yet suitable for inclusion as is, but we're happy to help get them into a better state if you want them.
- Dominant language
- Go
- Stars
- 53
- Forks
- 16
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/go-spdx
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 3/5 1-2 days Newbie friendliness 65/100
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
maintenance
Difficulty 1/5 1-3 hours Newbie friendliness 45/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Bob Shell support Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
santhosh-tekuri/jsonschema#276 ·