Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NaCl SDK downloaded from centralized source in CMake #306

Viech opened this issue Jun 2, 2014 · 1 comment

NaCl SDK downloaded from centralized source in CMake #306

Viech opened this issue Jun 2, 2014 · 1 comment


Copy link

@Viech Viech commented Jun 2, 2014

The NaCl SDK which is necessary for compiling parts of the gamelogic gets downloaded as a binary package from a single server (currently by CMake.

This has a few drawbacks:

  • The successful compilation depends on the server in question being online.
  • The connection to the server in question can be blocked (see this comment from 2014-05-10) or rate limited.
  • The downloaded package contains binaries, which can lead to both trust and ideological issues (think of source-only linux distributions).
  • Downloading binary packages during compile time might be disallowed for security reasons on the official build servers of linux distributions (see this forum post).
  • From what I see, the downloaded package isn't checksum-verified, allowing for (un)intentional corruption.
  • The downloaded binaries appear to be a part of the build and can therefor be shipped as a part of a release/package, which amplifies the significance of the last point.

My proposal is to add different CMake options for retreiving the dependency. Possible options are:

  • Use the dependency as installed on the system, if detected.
  • Allow to compile from source which is shipped as part of the main repository or as a git submodule.
  • Allow to compile from source which gets downloaded, ideally from the official repository of the SDK.
@Viech Viech added A-Build labels Jun 2, 2014
@Viech Viech assigned Amanieu and Kangz and unassigned Amanieu and Kangz Jun 2, 2014

This comment has been minimized.

Copy link

@dsalt dsalt commented Jun 8, 2014

From a packaging perspective, the SDK needs to be separate, so the first option is preferred, followed by use of a git submodule; regardless, we need to allow for use of separately-installed binaries. Whichever options we allow, allowing download of binaries should be retained as a matter of convenience.

Including the SDK code in our main repository is a bad idea. It needs to be separate and, ideally, minimal – I see no point in building it every time I do a build. I do builds for two architectures for several OS releases each month, so it rapidly becomes a large compile job; I'd rather build exactly what we need and do so less often.

@t4im t4im added the T-Security label Nov 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.