iotivity
Update workflows for forks
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
No Duplication information
![sonarqubecloud[bot] avatar](https://avatars.githubusercontent.com/in/12526?v=4 "Published by a pub.dev verified publisher"){kind=small}
@ondrejtomcik Is it ok to run CTT tool for PR from the fork?
No. This is a security issue, as whoever could be able to execute code on OCF VM or make a mess with many runs.
@ondrejtomcik Is it ok to run CTT tool for PR from the fork?
ctt-bot.yml isn't the job that runs CTT tool. The workflow posts a comment when PR is opened or removes the "CTT conformance testing" label when a PR is updated. Using pull_request_target for these actions is OK. It's expected not to do anything sensitive in a "pull_request_target" job, but I can add a warning at the beginning of the file just to be sure.
No. This is a security issue, as whoever could be able to execute code on OCF VM or make a mess with many runs.
Wouldn't it be possible to make it work like other jobs for PRs from forks? That is they run only a maintainer clicks on "Aprove and Run" button. I wouldn't want to merge a PR from a fork without knowing the result of a CTT tool run. Giving everyone write permissions or manually migrating the PR to repository myself seem like worse options than making it (securely) work for PRs from a fork.
@ondrejtomcik Is it ok to run CTT tool for PR from the fork?
ctt-bot.yml isn't the job that runs CTT tool. The workflow posts a comment when PR is opened or removes the "CTT conformance testing" label when a PR is updated. Using pull_request_target for these actions is OK. It's expected not to do anything sensitive in a "pull_request_target" job, but I can add a warning at the beginning of the file just to be sure.
No. This is a security issue, as whoever could be able to execute code on OCF VM or make a mess with many runs.
Wouldn't it be possible to make it work like other jobs for PRs from forks? That is they run only a maintainer clicks on "Aprove and Run" button. I wouldn't want to merge a PR from a fork without knowing the result of a CTT tool run. Giving everyone write permissions or manually migrating the PR to repository myself seem like worse options than making it (securely) work for PRs from a fork.
Once you enabled the remote execution of scripts on that PC - in Powershell. If you disable it, should be okay. Only that one, which is there, triggering CTT can be executed. Otherwise whoever can in his fork add his own script and start mining through your PC :)