The `SonarSource/sonarqube-scan-action@7.1.0` build output is not reproducible

SonarQube Cloud
1

I run a project where I test the reproducibility of GitHub Actions and found that v7.1.0 of the `SonarSource/sonarqube-scan-action` action is not reproducible. I confirmed this locally based on the contributing guidelines of the project by running these commands:

git clone git@github.com:SonarSource/sonarqube-scan-action.git
cd sonarqube-scan-action
git checkout v7.1.0 # 299e4b793aaa83bf2aba7c9c14bedbb485688ec4 as of writing
nvm install 20
nvm use 20
npm clean-install
npm run build
git status

and observing the output

[...]
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   dist/index.js
	modified:   dist/index.js.map
	modified:   dist/install-build-wrapper.js

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	dist/exec-1yxyZL_0.js
	dist/exec-1yxyZL_0.js.map

no changes added to commit (use "git add" and/or "git commit -a")
2

Hi,

Can you help me understand what you mean here by “reproducible”?

 
Thx,
Ann

3

Hi,

Apologies for not elaborating on that aspect. The term originates(?) from the https://reproducible-builds.org/ project. Intuitively it just means that given the same build input you get back “exactly” the same output. For the purposes of my original description I meant byte-for-byte identical, which would mean that `git status` reports no changes at all. If you follow the steps I took and run `git diff` you will be able to see more details about how things differ (assuming my report itself is reproducible :upside_down_face:), which I omitted here because the full diff is quite large.

The reason this property is useful is that it creates trust about the build output. If I am able to produce the identical build output from the same build input it means at least (with high probability) that the build was carried out honestly. If this is not possible it might mean (not implying it does in this case) the build input is benign but the build output is not.

To add some additional context, previous version of the action (v6.0.0 and v7.0.0) were reproducible.

Regards,

Eric

4

Hi Eric,

Thanks for the details. I’m gonna need more. :sweat_smile:

Let’s start with what differed from run to run?

And could you perhaps provide the analysis logs of the two runs?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.

 
Thx,
Ann

5

Apologies for the misunderstanding Ann,

I’m not having trouble running the action, I’m having trouble (re)building the action build artifact from its source code. This is a meta-question, I’m not here as a user of the action but rather as a contributor (of sorts).

As illustrated in my original post, what I’m trying to do is clone the `SonarSource/sonarqube-scan-action` Action source code and reproduce the build artifact independently (for the purposes described in my previous response).

Eric

6

Hi Eric,

You’re saying that when you build our action code independently, you don’t get something with an identical checksum to what we published?

 
Ann

7

Hi Ann,

Probably yes? Given that the build artifact bytes changed, when I compute the checksums before and after they differ. However, I don’t know if you publish checksums for the build artifact anywhere (or if you publish the build artifact elsewhere too).

Eric

8

Hi Eric,

Thanks for clarifying. I’m going to flag this for the team that owns the build.

 
Ann