Retrieving artefacts from a server

Hello,

I ran from a CMakeLists.txt an install()command, zipped the result in an archive, and put it on a Nexus server.

Then, in an other project, I want to use that library. So I did :

include(FetchContent)
FetchContent_Declare(MyLibrary
	URL      "https://../../MyLibrary.zip"
	URL_HASH MD5=c61b9256812647bb615bb5e91d045d7c)
	
FetchContent_MakeAvailable(MyLibrary)

Problem : the server needs authentification.
I can’t use HTTP_USERNAME and HTTP_PASSWORD, because I would need a common L/P for all people using this CMakeLists.txt. And also, this file would be versionned. It is clearly a security hole.

If I was using Git, I could rely on the Windows Credential Manager (yes, we work on Windows). Buf for Nexus (or other artefacts server…), how to you manage this need, which appears to me pretty basic ?

Thanks.

There’s no workaround here from my POV.

Our GitLab needs authentication too. Every person working on the project has their own credentials. So I declare things like:

include(FetchContent)

fetchcontent_declare(
    jwtlib
    URL "${REPOSITORY_LOCATION}/jwt/73f23419235661e89a304ba5ab09d6714fb8dd94/jwt-cpp-73f23419235661e89a304ba5ab09d6714fb8dd94.zip"
    URL_HASH SHA256=3723c14cf7115eb7466aabe00cd17977858ddbcd6f3b3bbc48eaeb43320beaa6
    ${REPOSITORY_AUTH}
)
set(JWT_BUILD_EXAMPLES OFF CACHE STRING "JWT-CPP: Build Examples" FORCE)
fetchcontent_makeavailable(jwtlib)

and a setup done elsewhere based on the parameters/env:

if(REPOSITORY_AUTH_TYPE STREQUAL "basic")
    if(NOT REPOSITORY_AUTH_USR STREQUAL "" OR NOT REPOSITORY_AUTH_PSW STREQUAL "")
      set(REPOSITORY_AUTH "HTTP_USERNAME;${REPOSITORY_AUTH_USR};HTTP_PASSWORD;${REPOSITORY_AUTH_PSW}")
    endif()
  elseif(REPOSITORY_AUTH_TYPE STREQUAL "token")
    if(NOT REPOSITORY_AUTH_TOKEN_HEADER STREQUAL "")
      set(REPOSITORY_AUTH "HTTP_HEADER;${REPOSITORY_AUTH_TOKEN_HEADER}: ${REPOSITORY_AUTH_TOKEN}")
    endif()
  endif()

But if you require random people to be able to build your project, you just have to put your dependencies in a publicly accessible place.

1 Like

Thanks for your input.

So, the following variables :

REPOSITORY_AUTH_USR
REPOSITORY_AUTH_PSW
REPOSITORY_AUTH_TOKEN_HEADER
REPOSITORY_AUTH_TOKEN

are stored locally, as in environment variables ?

I get them like:

set(REPOSITORY_AUTH_USR "$ENV{REPOSITORY_AUTH_USR}" CACHE STRING "HTTP User required to access 3rd-party repository")
set(REPOSITORY_AUTH_PSW "$ENV{REPOSITORY_AUTH_PSW}" CACHE STRING "HTTP User password required to access 3rd-party repository")
set(REPOSITORY_AUTH_TOKEN "$ENV{REPOSITORY_AUTH_TOKEN}" CACHE STRING "Token required to access 3rd-party repository")
set(REPOSITORY_AUTH_TOKEN_HEADER "$ENV{REPOSITORY_AUTH_TOKEN_HEADER}" CACHE STRING "Name of the header that transports the token")
set(REPOSITORY_AUTH_TYPE "token" CACHE STRING "Way to authenticate with 3-party repository")
set_property(CACHE REPOSITORY_AUTH_TYPE PROPERTY STRINGS "token" "basic" "none")

So they can be given as -D.... parameters, or exist in the environment.

OK, thank you !
Let’s see if anyone has an other proposal, but yours is OK, and I’ll adopt it there isn’t other solution.

And I forgot to answer that :

But if you require random people to be able to build your project, you just have to put your dependencies in a publicly accessible place.

No, I don’t want random people access my project. It will be only used inside the company where I work.

The HTTP_HEADER and passing credentials via $ENV{}/CACHE is how I would do it myself too, if I had to fetch bare archives from a server that requires authentication. By “bare archives” I mean that usually Nexus and the likes of it (JFrog Artifactory, Azure DevOps Artifacts, etc) are used as registries/repositories for package managers, which is what I would be using, but I guess “crude” downloads of “plain” archives works too.

And if your question was “can I let users somehow bypass server authentication”, then quite naturally the answer is no, and moreover that’s outside of CMake’s scope. As Jakub said, your server is either publicly available to everyone or those who are meant to be using it need to have their own accounts there.

1 Like

Thank you @retif for this second opinion.
So I will adopt the strategy described by both of you.