Choosing Between FetchContent and ExternalProject_Add for Secure Integration Tests

Answer the exact question first

• Which approach guarantees that temporary tokens are not written to the CMake cache or generated files? ExternalProject_Add – it runs the clone in a dedicated build directory and accepts credentials only via command‑line options or a temporary file, so no token ends up in CMakeCache.txt or in any CMake‑generated file.
• Does ExternalProject_Add offer a cleaner way to inject a temporary .netrc or environment variable without altering the global Git configuration? Yes. By passing a GIT_ARGS string that points to a temporary .netrc or by exporting GIT_ASKPASS, you keep the main project’s global Git settings untouched.
• How does FetchContent react to stale source checks when a new token is supplied on subsequent runs? It may reuse the cached source directory. If the repository was already cloned, FetchContent will skip a new clone unless you change the GIT_TAG or explicitly delete the source directory, meaning a stale or revoked token could still be used.

Why ExternalProject_Add is safer for temporary tokens

1. All git operations happen in ExternalProject_Add’s own build sub‑directory, isolated from the main build tree.
2. Credentials are supplied only to the git clone command via GIT_ARGS or a temporary .netrc; they never appear in any CMake cache entry.
3. The temporary .netrc can be created in a unique /tmp location and deleted immediately after the clone, ensuring no residue.
4. Logs produced by ExternalProject_Add are local to its build directory; you can purge them after the test run.

Practical steps for a secure integration test

# 1. Create a temporary .netrc with the short‑lived token
set( NETRC_PATH "${CMAKE_CURRENT_BINARY_DIR}/tmp_netrc_${PROJECT_NAME}.netrc" )
file( WRITE ${NETRC_PATH} "machine github.com\n  login <dummy_user>\n  password <YOUR_TEMP_TOKEN>\n" )

# 2. Configure ExternalProject_Add with GIT_ARGS that use the temp .netrc
ExternalProject_Add( my_private_repo
  GIT_REPOSITORY "https://github.com/yourorg/privaterepo.git"
  GIT_TAG "main"
  GIT_ARGS "-c credential.helper=store -c netrc=${NETRC_PATH}"
  SOURCE_DIR "${CMAKE_CURRENT_BINARY_DIR}/src/privaterepo"
  CONFIGURE_COMMAND ""
  BUILD_COMMAND ""
  INSTALL_COMMAND ""
)

# 3. Delete the .netrc after the clone succeeds
add_custom_command(
  TARGET my_private_repo POST_BUILD
  COMMAND ${CMAKE_COMMAND} -E remove ${NETRC_PATH}
  COMMENT "Clean up temporary .netrc"
)

Because the GIT_ARGS string is passed only to the git clone command, the token never reaches CMakeCache.txt. The temporary .netrc is removed in a POST_BUILD step, leaving no trace.

Verifying that no token is persisted

1. Run cmake -S . -B build and inspect build/CMakeCache.txt – no reference to YOUR_TEMP_TOKEN should be present.
2. Check build/_deps/my_private_repo-src (the clone location). The .netrc file should not exist there.
3. Review build/my_private_repo.log; it will contain the git command but the token is only passed via the -c netrc=… option, not echoed.

What if you prefer FetchContent?

FetchContent can still be used securely by:

• Setting GIT_ASKPASS to a script that returns the temporary token, and ensuring GIT_ASKPASS is unset after configure.
• Deleting the source directory between configure runs or changing the GIT_TAG to force a fresh clone.
• Verifying that CMakeCache.txt contains no token, which is guaranteed by CMake’s design.

However, because FetchContent inherits the global Git configuration, any inadvertent change to the user’s ~/.gitconfig could expose the token to other projects. ExternalProject_Add’s isolation makes it the safer choice for integration tests that must keep credentials strictly temporary.

Missing diagnostic detail

If you are using a custom GIT_ASKPASS script or have a non‑standard Git helper, let us know so we can adjust the recommendation accordingly.