Skip to content

Avoid exposing password and token from git repositories #105220

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

Merged
merged 5 commits into from
Sep 11, 2024

Conversation

tuliom
Copy link
Contributor

@tuliom tuliom commented Aug 20, 2024

Try to detect if the git remote URL has a password or a Github token and
return an error teaching the user how to avoid leaking their password or
token.

Restrict the URL that is exposed to the official LLVM repository at
Github in order to avoid exposing usernames, passwords or even private
URLS unintentionally.

Users willing to expose different Git repositories can continue to do so
by setting LLVM_FORCE_VC_REPOSITORY or CLANG_REPOSITORY_STRING.
@llvmbot llvmbot added the cmake Build system in general and CMake in particular label Aug 20, 2024
@kbeyls kbeyls requested review from tstellar and petrhosek August 21, 2024 07:53
@kbeyls
Copy link
Collaborator

kbeyls commented Aug 21, 2024

I added @tstellar and @petrhosek as reviewers. Would one of you be able to help review this? Or do you otherwise have suggestions for who would be good to review this PR?

@petrhosek
Copy link
Member

While I understand the concern, I'm a bit concerned that this could be undesirable to many vendors and there should be an RFC to raise the awareness and get more feedback. If we decide to go forward with this change, I also think there should be a CMake option controlling this behavior rather than relying on LLVM_FORCE_VC_REPOSITORY.

SLTozer added a commit to SLTozer/llvm-project that referenced this pull request Aug 21, 2024
Currently the output of dexter --version contains the raw output of
`git remote get-url origin`, which may contain a username and password.
This patch adds a small change to remove these from the output string.
A similar patch for LLVM's default version string[0] also removes the git
URL altogether unless opted-in to; it's not clear whether this is a necessary
or desirable step yet, but if so we can trivially remove the URL from Dexter
as well.

[0]: llvm#105220
SLTozer added a commit that referenced this pull request Aug 22, 2024
…105533)

Currently the output of dexter --version contains the raw output of `git
remote get-url origin`, which may contain a username and password. This
patch adds a small change to remove these from the output string. A
similar patch for LLVM's default version string* also removes the git
URL altogether unless opted-in to; it's not clear whether this is a
necessary or desirable step yet, but if so we can trivially remove the
URL from Dexter as well.

*PR here: #105220
cjdb pushed a commit to cjdb/llvm-project that referenced this pull request Aug 23, 2024
…lvm#105533)

Currently the output of dexter --version contains the raw output of `git
remote get-url origin`, which may contain a username and password. This
patch adds a small change to remove these from the output string. A
similar patch for LLVM's default version string* also removes the git
URL altogether unless opted-in to; it's not clear whether this is a
necessary or desirable step yet, but if so we can trivially remove the
URL from Dexter as well.

*PR here: llvm#105220
@tuliom
Copy link
Contributor Author

tuliom commented Aug 29, 2024

While I understand the concern, I'm a bit concerned that this could be undesirable to many vendors and there should be an RFC to raise the awareness and get more feedback.

@petrhosek I've just created the RFC at https://discourse.llvm.org/t/rfc-avoid-exposing-unknown-git-repositories/80962

If we decide to go forward with this change, I also think there should be a CMake option controlling this behavior rather than relying on LLVM_FORCE_VC_REPOSITORY.

Could you please share your proposal in the Discourse topic, please?
I would also appreciate if you could elaborate how this new option would work, because it isn't clear to me.

@joker-eph
Copy link
Collaborator

LGTM, but please get more approvals.

@tuliom tuliom changed the title Avoid exposing unknown git repositories Avoid exposing password and token from git repositories Sep 3, 2024
@tuliom
Copy link
Contributor Author

tuliom commented Sep 3, 2024

I updated this PR based on the feedback received on Discourse.

Title and description have been updated accordingly.

@tuliom
Copy link
Contributor Author

tuliom commented Sep 10, 2024

As mentioned in the Forum, the discussion on this has been going down.
I believe the current change doesn't change the behavior as the original one did.
So, I plan to merge it later today if nobody objects.

@tuliom tuliom merged commit 5904448 into llvm:main Sep 11, 2024
8 checks passed
@llvm-ci
Copy link
Collaborator

llvm-ci commented Sep 12, 2024

LLVM Buildbot has detected a new failure on builder lld-x86_64-win running on as-worker-93 while building llvm at step 7 "test-build-unified-tree-check-all".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/146/builds/1129

Here is the relevant piece of the build log for the reference
Step 7 (test-build-unified-tree-check-all) failure: test (failure)
******************** TEST 'LLVM-Unit :: Support/./SupportTests.exe/43/86' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe-LLVM-Unit-10868-43-86.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=86 GTEST_SHARD_INDEX=43 C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe
--

Script:
--
C:\a\lld-x86_64-win\build\unittests\Support\.\SupportTests.exe --gtest_filter=ProgramEnvTest.CreateProcessLongPath
--
C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp(160): error: Expected equality of these values:
  0
  RC
    Which is: -2

C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp(163): error: fs::remove(Twine(LongPath)): did not return errc::success.
error number: 13
error message: permission denied



C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp:160
Expected equality of these values:
  0
  RC
    Which is: -2

C:\a\lld-x86_64-win\llvm-project\llvm\unittests\Support\ProgramTest.cpp:163
fs::remove(Twine(LongPath)): did not return errc::success.
error number: 13
error message: permission denied




********************


@danilaml
Copy link
Collaborator

Adding -DLLVM_FORCE_VC_REPOSITORY doesn't achieve the intended effect. It overrides the repository but also no revision is generated either, i.e. VCSRevision.h becomes

#undef LLVM_REVISION
#define LLVM_REPOSITORY "test"

Considering LLVM_REPOSITORY is only really used by lld, clang and flang, it seems to create unnecessary friction with no easy workaround for other projects.

@tuliom
Copy link
Contributor Author

tuliom commented Sep 17, 2024

@danilaml could you elaborate, please? What kind of friction was created by the merged commit?

@danilaml
Copy link
Collaborator

danilaml commented Sep 17, 2024

@tuliom the error is triggered in certain configs/machines we use but

  1. we do not use anything that'd require LLVM_REPOSITORY define so those configs were not affected by the security issue anyway
  2. using -DLLVM_FORCE_VC_REPOSITORY to override the error unsets LLVM_REVISION which is actually used by llvm.

@tuliom
Copy link
Contributor Author

tuliom commented Sep 18, 2024

@danilaml I'm afraid I still don't fully understand the impact you're seeing, but let me try to suggest a solution anyway: do you think that setting -DLLVM_FORCE_VC_REPOSITORY=<url> -DLLVM_FORCE_VC_REVISION=<revision> helps?
Depending on what you're trying to achieve, you may only need -DLLVM_FORCE_VC_REVISION=<revision>.

@danilaml
Copy link
Collaborator

@tuliom setting them both (or just LLVM_FORCE_VC_REVISION) means we'd have to manually duplicate the logic the old cmake was already doing to get the revision (and hope it matches whatever is used on other machines).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmake Build system in general and CMake in particular
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants