Version build discrepancy vs. canonical list (v0.5.11 and others)

[brianmcmichael]

Description

The solc v0.5.11 that has been distributed widely does not appear to be the same version that is defined on the solc-bin list.txt

The snap distribution and the docker image both appear to be running 0.5.11+commit.22be8592, while the canonical version of 0.5.11 appears to be 0.5.11+commit.c082d0b4

The ReadTheDocs versions page also seems to be based on 22be8592

This discrepancy can become a problem because programmatic etherscan contract verification via the api relies on a compiler string matching one of the entries on the solc-bin/bin/list.txt source. A contract compiled on the command line using one of the distributed binaries version output would not match a compatible version and fail verification.

I also noticed a similar discrepancy with v0.5.9 and a few earlier versions. v0.5.12 (7709ece9) and v0.5.10 (5a6ea5b1) match as expected.

Environment

• Compiler version: v0.5.11, v0.5.9, others
• Target EVM version (as per compiler settings): N/A
• Framework/IDE (e.g. Truffle or Remix): N/A
• EVM execution environment / backend / blockchain client: N/A
• Operating system: Linux/OSX

Steps to Reproduce

$ snap run solc --version
solc, the solidity compiler commandline interface
Version: 0.5.11+commit.22be8592.Linux.g++

$ docker run ethereum/solc:0.5.11 --version
solc, the solidity compiler commandline interface
Version: 0.5.11+commit.22be8592.Linux.g++

Compare with list.txt entry.

[chriseth]

Thanks for opening this issue! You are indeed right, the solc-js version seems to be behind by one commit. This commit is only a change in the build scripts, but we should still point solc-js at the proper tag.

Note that source verification has to fail anyway if you are not using exactly the same compiler because the metadata includes the commit and platform of the compiler and thus the metadata hash will be different.

[brianmcmichael]

FWIW, only the binary output needs to match to do source verification, since the service regenerates the artifacts on the other end from the source and compares the bin with the contract code on-chain. In this case, I was able to verify a contract compiled with 0.5.11+commit.22be8592 using solc.js 0.5.11+commit.c082d0b4, probably because of the difference only being in the build scripts, but in the case of other compiler tag mismatches the bin may not match.

We're trying to programatically verify on this end though by stripping the platform and sending the version off that way, etherscan bases their list of supported compilers on the js versions though.

[chriseth]

@brianmcmichael etherscan does not do full source verification, it strips the metadata hash and only compares the opcodes. This is fine most of the time, but it can fool you with regards to variable names, comments and even worse: Code that uses codecopy to access the metadata hash.

My comment above is partly wrong, though, only the commit hash is part of the metadata, not the platform.

[chriseth]

@ekpyron is this related to what you are doing? :)

[ekpyron]

@chriseth For the rebuilds in ethereum/solc-bin#22 I specifically used the version defined in https://github.com/ethereum/solc-bin/blob/gh-pages/bin/list.txt - so I generated a new soljson-v0.5.11+commit.c082d0b4.js, not a soljson-v0.5.11+commit.22be8592.js. If we change the list in solc-bin, I'll need to change the respective release in ethereum/solc-bin#22 as well.

[chriseth]

It's maybe not so important what is in the list, but we should not delete a previously available compiler binary.

[chriseth]

@ekpyron can this be closed?

[ekpyron]

I don't think so - as far as I know, we only ever messed around with the soljson.js releases on solc-bin so far - this issue is about the commit hashes there being different from those of the same compiler version released elsewhere e.g. as docker image or as snap releases (the latter we don't control, though, do we?). So depending on where you get e.g. 0.5.11 you'll end up with different commit hashes... which is bad, but I'm not sure what to do about it, especially retrospectively...

[chriseth]

We could at least add a new binary to solc-bin, but not sure if this would do more harm than good.

[cameel]

While adding Linux/Mac/Win binaries to solc-bin I compared all the soljson files with the ones on github (see the table in ethereum/solc-bin#42 (comment)) and only three versions are actually affected by this:

• 0.4.15
• 0.5.9
• 0.5.11

With 0.6.12 we have switched to adding release binaries to solc-bin manually and I'm also preparing a PR check to ensure that they always match those on the release page so this should not happen in the future.

What to do about those three cases? Would just adding both variations to solc-bin be acceptable? And if so, should they both be included in file lists or just the one from the release page.

Another problem is that we have three cases where binaries were built from the same exact commit but are not byte-for-byte identical:

• 0.2.0
• 0.2.1
• 0.4.11

Maybe I should just replace them in the repo with the ones from the release page?

[cameel]

Decision from today's call:

• We don't want to remove binaries that were already distributed via solc-bin so for 0.4.15, 0.5.9, 0.5.11 we're going to include both variants there.
• For 0.2.0, 0.2.1 and 0.4.11 we will keep just one. We don't want to touch the one in solc-bin because that would change the hash of the binary, possibly making verification fail for people who are checking that. That's not a problem with the one on the release page so we're going to change that one.

[cameel]

0.4.15, 0.5.9 and 0.5.11

For the first part, here's a PR that adds the binaries built on different commits to solc-bin: ethereum/solc-bin#57

0.2.0, 0.2.1 and 0.4.11

For the second, I have edited the releases (0.2.0, 0.2.1, 0.4.11) to remove the old soljson.js files and add the ones from solc-bin.

By the way, in 0.2.0 and 0.2.1 the file name included also the date and commit hash, now they're all soljson.js like in newer releases; this is not consistent between releases anyway.

Original files

In case we ever need them (or want to roll back this change), here are the original files: original-0.2.0-0.2.1-0.4.11-releases.zip

And their hashes (both old and new):

Version	keccak256 (github)	keccak256 (solc-bin)
0.2.0	0x75c4aec16b19b148720cc889dec60f639bf5b31b5456bede69c7756d74f35804	0x7d8ea0312905d250ec7554bd84526c3d97d05f6d5748888e6ec00629bd3ea7a6
0.2.1	0x8f5a019f1aeda91cbcb20ddd512253a66babb63450c07e53d907c923d5059148	0x7067e5792a88111c06a7078a23358641a64d0fa273b5220bfa5212029352dbe9
0.4.11	0xae353b2d1da5ec2acb1bb54c35cf06bb2312d8f69f527f183d5b980d7afcb67a	0xde17e284da94d3d600c1096f05d83af794eef746d2aba2e4e066e3d3efce7abf

Versions reported by replaced files

Just in case I also used solc-js to check what the executables actually report as version:

Version	Output from version()
0.2.0 (github)	0.2.0-4dc2445e/.-Emscripten/clang/int linked to libethereum-1.1.0-c9886e9e/.-Emscripten/clang/int
0.2.0 (solc-bin)	0.2.0-4dc2445e/.-Emscripten/clang/int linked to libethereum-1.1.0-34716679/.-Emscripten/clang/int
0.2.1 (github)	0.2.1-91a6b35f/.-Emscripten/clang/int linked to libethereum-
0.2.1 (solc-bin)	0.2.1-91a6b35f/.-Emscripten/clang/int linked to libethereum-
0.4.11 (github)	0.4.11-nightly.2017.5.3+commit.68ef5810.Emscripten.clang
0.4.11 (solc-bin)	0.4.11+commit.68ef5810.Emscripten.clang

So it looks like 0.4.11 is a nightly built from the tagged release commit, just like 0.4.15 for windows (#9545).
I checked soljson.js from 0.4.12 and 0.4.15 just in case but they all identify as release builds so (hopefully) those are just some individual cases.

The other two seem to have been built with libethereum checked out at a different commit.

[cameel]

Closing since the PR in solc/bin has been merged and the changes to github releases are done too.

[kuzdogan]

We encountered a contract with the version v0.5.11+commit.c082d0b4 while verifying a contract on Sourcify, and noticed the mentioned versions are not added to the linux-amd64 binaries (as well as win, macos etc.), but is included in the .js list.

I was able to track down the issue here but couldn't find any further information. From what I understood from the conversation here, both versions ( v0.5.11+commit.c082d0b4 and v0.5.11+commit.22be8592) should have been existing. Am I missing something?

[cameel]

Emscripten builds for both exist, but v0.5.11+commit.c082d0b4 was there only by accident and v0.5.11+commit.22be8592 is the canonical one. For that reason we kept c082d0b4 but did not add builds for that version on other platforms (and weren't planning to do it for new platforms we'll add in future).

Now, the question is how much of an issue that is. The wrong binary has been in the wild for quite a while so naturally we can expect to find contracts built with it. I guess the problem is that you'd like to run Sourcify completely with native binaries? How much of a burden is it to keep a fallback to the emscripten binary for rare cases like this?

[kuzdogan]

It's not an issue and actually, it would have already used the fallback, if we hadn't had a wrong read-only setting for the solc-js folder.

So not an issue for us.