submodule update fails in some git versions due to protocol.file.allow=user value #619
Assignees
Labels
Comments
|
High prio since it's breaking our own CI -- I expect the real-world impact to users will be low. My expectation is the vast majority of users are updating submodules with 'safe' protocols like https or ssh that are still allowed by default in new git versions. |
mbolivar-nordic
added a commit
to mbolivar-nordic/west
that referenced
this issue
Jan 4, 2023
This option is necessary in some edge cases (including west's own test suite) to work around new git behavior discussed in: https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253 Since 'west update' uses 'git submodule update --init --recursive' to clone submodules, users may run into problems in (likely rare) situations where they are updating a submodule from a "remote" repository which is actually a file on the local host with symlinks under .git. In this case, the 'west update' will fail because the file protocol is disallowed at the 'git submodule update' step. We don't want to force users (including our own test suite...) to allow this protocol globally, since upstream git is telling us that is a security problem. But we do want to allow that protocol to be enabled on a case-by-case basis within west when the repository is known not to be malicious. This option allows us to do exactly that by running: west update --submodule-init-config protocol.file.allow=always ... Fixes: zephyrproject-rtos#619 Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
mbolivar-nordic
added a commit
to mbolivar-nordic/west
that referenced
this issue
Jan 4, 2023
This option is necessary in some edge cases (including west's own test suite) to work around new git behavior discussed in: https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253 Since 'west update' uses 'git submodule update --init --recursive' to clone submodules, users may run into problems in (likely rare) situations where they are updating a submodule from a "remote" repository which is actually a file on the local host with symlinks under .git. In this case, the 'west update' will fail because the file protocol is disallowed at the 'git submodule update' step. We don't want to force users (including our own test suite...) to allow this protocol globally, since upstream git is telling us that is a security problem. But we do want to allow that protocol to be enabled on a case-by-case basis within west when the repository is known not to be malicious. This option allows us to do exactly that by running: west update --submodule-init-config protocol.file.allow=always ... Fixes: zephyrproject-rtos#619 Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
mbolivar-nordic
added a commit
that referenced
this issue
Jan 5, 2023
This option is necessary in some edge cases (including west's own test suite) to work around new git behavior discussed in: https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253 Since 'west update' uses 'git submodule update --init --recursive' to clone submodules, users may run into problems in (likely rare) situations where they are updating a submodule from a "remote" repository which is actually a file on the local host with symlinks under .git. In this case, the 'west update' will fail because the file protocol is disallowed at the 'git submodule update' step. We don't want to force users (including our own test suite...) to allow this protocol globally, since upstream git is telling us that is a security problem. But we do want to allow that protocol to be enabled on a case-by-case basis within west when the repository is known not to be malicious. This option allows us to do exactly that by running: west update --submodule-init-config protocol.file.allow=always ... Fixes: #619 Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is only triggered by new git behavior discussed in:
https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253
West should continue to work on older versions of git without the new behavior discussed there.
Specifically, this issue happens because 'west update' uses 'git submodule update --init --recursive' to clone submodules in some cases like when when when users are updating a submodule from a "remote" repository which is actually a file on the local host which may contain symbolic links under its .git directory. In such cases, the 'west update' will fail because the clone using the file protocol is disallowed at the 'git submodule update' step.
The text was updated successfully, but these errors were encountered: