Pipeline License Compliance on Master not picking up License policies
Summary
License Compliance tab on Pipelines does not appear to be picking up set License policies.
This was noted in failing test on master - #284658 (closed)
I thought maybe this was an issue with my test data, but it looks fine. MR license compliance is fine.
I've raised it with the Composition Analysis team as this looks like an issue with how Pipelines are getting license data
https://gitlab.slack.com/archives/CKWHYU7U2/p1605792050327900
Hi all, investigating License Compliance E2E test failure on Master - is the License Compliance tab in Pipelines treated differently from the likes of MR? I've set a couple of policies that match licenses in my license scanning report, they show up at the MR level but in the pipeline they are returned as unclassified If I call the API I can confirm:
[
{
"id": 5,
"name": "MIT License",
"approval_status": "approved"
},
{
"id": 6,
"name": "zlib License",
"approval_status": "blacklisted"
}
]
The MR shows the appoved/blacklisted licenses (1st screenshot)
The pipeline shows everything as uncategorized,
the response from the licenses endpoint that the Pipeline tab shows is
[{"name":"Apache License 2.0","dependencies":[{"name":"test_package","version":"0.1.0","package_manager":"bundler","blob_path":"Gemfile.lock"}],"url":"http://www.apache.org/licenses/LICENSE-2.0.html","classification":{"id":null,"name":"Apache License 2.0","approval_status":"unclassified"},"count":1},{"name":"MIT License","dependencies":[{"name":"actioncable","version":"6.0.3.3","package_manager":"bundler","blob_path":"Gemfile.lock"}],"url":"https://opensource.org/licenses/MIT","classification":{"id":null,"name":"MIT License","approval_status":"unclassified"},"count":1},{"name":"zlib License","dependencies":[{"name":"zlib","version":"1.2.11","package_manager":"bundler","blob_path":"Gemfile.lock"}],"url":"https://opensource.org/licenses/Zlib","classification":{"id":null,"name":"zlib License","approval_status":"unclassified"},"count":1}]
Steps to reproduce
- Populate a project with https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa/qa/ee/fixtures/secure_license_files files
- go to "License Policies > Add a License" tab
- add new "Denied" policy for a license that is not in the license list drop down (let's pick "foo license v2" because this will be the software license name rather than spdx id)
- create branch and add a license to the report:
{
"id": "foo",
"name": "foo license v2",
"url": "http://foo.bar/baz"
}
The MR view of licenses will show that this license is denied, while the pipeline view will show it as uncategorized.
- View the MR license report, correctly approved/denied licenses
- View the pipeline license tab, all licenses are uncategorized
Example Project
https://gitlab.com/gitlab-org/gitlab/-/tree/master/qa/qa/ee/fixtures/secure_license_files and the above steps for an edit to generate an MR/pipeline
What is the current bug behavior?
Pipeline security tab is getting uncategorized licenses in its data and displaying accordingly
What is the expected correct behavior?
Pipeline security tab should get correctly categorized licenses in its data and display such accordingly
Relevant logs and/or screenshots
See summary
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
rake gitlab:env:info RAILS_ENV=development
System information
System:
Proxy: rvm_proxy:
Current User: willmeek
Using RVM: yes
RVM Version: 1.29.10
Ruby Version: 2.7.2p137
Gem Version: 3.1.4
Bundler Version:2.1.4
Rake Version: 13.0.1
Redis Version: 5.0.7
Git Version: 2.29.2
Sidekiq Version:5.2.9
Go Version: go1.14 darwin/amd64
GitLab information
Version: 13.6.0-pre
Revision: 8aa3973a36c
Directory: /Users/willmeek/gitlab-development-kit/gitlab
DB Adapter: PostgreSQL
DB Version: 11.9
URL: http://192.168.1.78:3000
HTTP Clone URL: http://192.168.1.78:3000/some-group/some-project.git
SSH Clone URL: ssh://willmeek@192.168.1.78:2222/some-group/some-project.git
Elasticsearch: no
Geo: no
Using LDAP: no
Using Omniauth: yes
Omniauth Providers: google_oauth2
GitLab Shell
Version: 13.13.0
Repository storage paths:
- default: /Users/willmeek/gitlab-development-kit/repositories
GitLab Shell path: /Users/willmeek/gitlab-development-kit/gitlab-shell
Git: /usr/local/bin/git
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
% bundle exec rake gitlab:check RAILS_ENV=development SANITIZE=true
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 13.13.0 ? ... OK (13.13.0)
Running /Users/willmeek/gitlab-development-kit/gitlab-shell/bin/check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... no
Try fixing it:
sudo chmod 700 /Users/willmeek/gitlab-development-kit/gitlab/public/uploads
For more information see:
doc/install/installation.md in section "GitLab"
Please fix the error above and rerun the checks.
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... no
Try fixing it:
Install the init script
For more information see:
doc/install/installation.md in section "Install Init Script"
Please fix the error above and rerun the checks.
Init script up-to-date? ... can't check because of previous errors
Projects have namespace: ...
22/1 ... yes
22/2 ... yes
23/3 ... yes
24/4 ... yes
25/5 ... yes
26/6 ... yes
27/7 ... yes
28/8 ... yes
12/9 ... yes
21/10 ... yes
11/11 ... yes
14/12 ... yes
6/13 ... yes
4/14 ... yes
13/15 ... yes
9/16 ... yes
8/17 ... yes
2/18 ... yes
52/19 ... yes
108/20 ... yes
110/23 ... yes
110/24 ... yes
111/25 ... yes
112/26 ... yes
112/27 ... yes
113/28 ... yes
114/29 ... yes
114/30 ... yes
115/31 ... yes
115/32 ... yes
116/33 ... yes
116/34 ... yes
117/35 ... yes
117/36 ... yes
Redis version >= 4.0.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.7.2)
Git version >= 2.29.0 ? ... yes (2.29.2)
Git user has default SSH configuration? ... no
Try fixing it:
mkdir ~/gitlab-check-backup-1605798808
sudo mv /Users/willmeek/.ssh/id_ed25519 ~/gitlab-check-backup-1605798808
sudo mv /Users/willmeek/.ssh/id_ed25519.pub ~/gitlab-check-backup-1605798808
sudo mv /Users/willmeek/.ssh/airgap_cert ~/gitlab-check-backup-1605798808
sudo mv /Users/willmeek/.ssh/google_compute_engine.pub ~/gitlab-check-backup-1605798808
sudo mv /Users/willmeek/.ssh/google_compute_engine ~/gitlab-check-backup-1605798808
sudo mv /Users/willmeek/.ssh/google_compute_known_hosts ~/gitlab-check-backup-1605798808
For more information see:
doc/ssh/README.md in section "SSH on the GitLab server"
Please fix the error above and rerun the checks.
Active users: ... 98
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x (6.4 - 6.x deprecated to be removed in 13.8)? ... skipped (elasticsearch is disabled)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Proposal
The MR widget license matching logic is different from that of the Pipeline Licenses tab: vs https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/controllers/ee/projects/merge_requests_controller.rb#L37 (it uses SCA::LicenseCompliance#diff_with()
method to compare report with HEAD report. https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/controllers/ee/projects/pipelines_controller.rb#L31 )it uses SCA::LicenseCompliance#find_policies()
method.
It seems that the MR widget correctly matches licenses in the branch that are not in the spdx database, while the Pipeline Licenses tab only matches what's in the database.
The Pipeline Licenses tab should be updated to present data in the same way as the MR widget.
Implementation plan
-
add regression test for SCA::LicenseCompliance#find_policies()
with license not from SPDX index. -
align SCA::LicenseCompliance#find_policies()
method with matching inSCA::LicenseCompliance#diff_with()
to match properly licenses that doesn't have SPDX id.