23

While looking into my recent question Sonarcloud failure with Travis, Maven & github I realised that I was asking the wrong question. I was trying to address a symptom rather than the underlying problem.

A project I work on (eclipse/scanning) uses Github as it's repository and Travis with Sonarcloud for continuous integration and code analysis.

While the Sonarcloud analysis runs fine on internal pull requests (pull requests from branches pushed directly to eclipse/scanning) it doesn't work when Travis runs for external pull requests (those from forked repos).

The underlying problem is that the way we are running sonarcloud at the moment relies on environment variables which aren't populated for external pull requests for security reasons:

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions

We have our repository set up to not care whether Sonarcloud is run, but that means that we often merge in changes which break sonarcloud rules because we don't realise they have been broken. We only see that those rules have been broken the next time they are changed by someone who does push directly to the repository. This moves the burden of fixing Sonarcloud discovered problems from collaborators to committers.

So,

  • Is there a way to enable Sonarcloud analysis of pull requests from forked repositories without introducing security issues?

Note that this question seems to be one step beyond In Travis Public Repository how to add a Secure variable that works on Pull requests too which doesn't have an answer yet.

Mark Booth
  • 7,605
  • 2
  • 68
  • 92

3 Answers3

5

This is probably not the easy solution you are looking for but I do not think there is a much easier way to access secrets when building pull requests unless Travis adds support for it in some form. After all, the secret variables are not available for a good reason as pull requests can contain arbitrary code that gets executed during the build. An attacker might use this to create a pull request that changes the build process to read the decrypted environment variables and send them to him.

The underlying problem is that the code that is runs the build and the code that is built come from the same (sometimes untrusted) source. In order to be able to use secrets in the build process, the code that builds and the code that is built need to be separated and the build code needs to come from a trusted source. No code from the untrusted source must be executed unless it is sandboxed so that it cannot access any of the secrets.

To my knowledge Travis does not provide a standard method to achieve this.

By following the idea of separating build code and code being build, it should be possible nonetheless to execute a Sonarqube analysis against external pull requests.

First step would be to create a new repository "build code" on Github that contains only the trusted build scripts. These scripts are responsible for checking out the pull request and performing the Sonarqube analysis. As these are not part of the external pull request, they can access secret variables. Be careful, though, not to run the unit tests in the pull request as these are untrusted.

The second step is to trigger a build of the "build code" repository whenever a pull request is made against the actual source code repository. Travis provides an API to trigger builds. However, this also requires a secret. So we cannot simply trigger a build of the "build code" repository when building the pull request. What we can do, though, is to install a webhook on the source code repository on Github, that calls a small web service when a pull request is made. This service then calls the Travis API to trigger a build of the trusted build code repository.

I hope this makes sense. Please let me know if something is not clear.

I have not yet done this myself. So I cannot provide any code. But I think it shouldn't be too difficult to set up a small web service that turns a webhook from Github request into a build request for Travis.

Christoph Böhme
  • 3,766
  • 1
  • 19
  • 29
  • 5
    It looks to me like SonarCloud needs it's own GitHub integration, rather than relying on being run through another trusted service (i.e. Travis). It is rather silly that it is so much more difficult to get sonarcloud to run on external pull requests, when it is arguably more important for these commits to be analysed (developers with commit access being more likely to adhere to project standards than external collaborators). If you find any projects which already do this, I would be interested to know. – Mark Booth Aug 15 '17 at 10:02
5

As you've perfectly guessed, unless you hard-code your GitHub and SonarCloud tokens (which obviously you don't want, to not publicly unveil them), there is currently no way to analyze external pull requests. This is documented on the official SonarCloud Travis Add-on page.

We are currently actively working on a way to properly support this use case - and I hope we'll come up with something before the end of the year.

Fabrice - SonarSource Team
  • 26,535
  • 3
  • 62
  • 58
  • Sadly, "Support for external pull requests" is still listed under "Upcoming improvements". – Mark Booth Sep 20 '18 at 10:27
  • The link references an anchor that no longer exists, but the [upcoming improvements](https://docs.travis-ci.com/user/sonarcloud/#upcoming-improvements) section is still there. Sadly there doesn't appear to have been any progress on [MMF-1371](https://jira.sonarsource.com/browse/MMF-1371) the past couple of years. – Mark Booth Oct 22 '20 at 11:37
1

There is request for support external pull request:

https://jira.sonarsource.com/browse/MMF-1371

There is new site from Sonar when we can vote:

https://portal.productboard.com/sonarsource/1-sonarcloud/c/50-sonarcloud-analyzes-external-pull-request

I think good idea is vote for this issue.

Slawomir Jaranowski
  • 7,381
  • 3
  • 25
  • 33