Since the URL is passed directly to git clone, and the remote-ext helper
will happily execute shell commands, so by default disallow URLs that
contain a "::" unless a new unsafe_protocols kwarg is passed.
(CVE-2022-24439)

Fixes gitpython-developers#1515

All versions of package gitpython are vulnerable to Remote Code Execution
(RCE) due to improper user input validation, which makes it possible to
inject a maliciously crafted remote URL into the clone command. Exploiting
this vulnerability is possible because the library makes external calls to
git without sufficient sanitization of input arguments.

CVE: CVE-2022-24439

Upstream-Status: Backport

Reference:
gitpython-developers/GitPython#1529
gitpython-developers/GitPython#1518
gitpython-developers/GitPython#1521

(From OE-Core rev: 55f93e3786290dfa5ac72b5969bb2793f6a98bde)

Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Source: poky
MR: 124663
Type: Integration
Disposition: Merged from poky
ChangeID: 0721360
Description:

All versions of package gitpython are vulnerable to Remote Code Execution
(RCE) due to improper user input validation, which makes it possible to
inject a maliciously crafted remote URL into the clone command. Exploiting
this vulnerability is possible because the library makes external calls to
git without sufficient sanitization of input arguments.

CVE: CVE-2022-24439

Upstream-Status: Backport

Reference:
gitpython-developers/GitPython#1529
gitpython-developers/GitPython#1518
gitpython-developers/GitPython#1521

(From OE-Core rev: 55f93e3786290dfa5ac72b5969bb2793f6a98bde)

Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>

The tests of unsafe options are among those introduced originally
in gitpython-developers#1521. They are regression tests for gitpython-developers#1515 (CVE-2022-24439).
The unsafe options tests are paired: a test for the usual, default
behavior of forbidding the option, and a test for the behavior when
the option is explicitly allowed. Both tests use a payload that is
intended to produce the side effect of a file of a specific name
being created in a temporary directory.

All the tests work on Unix-like systems. On Windows, the tests of
the *allowed* cases are broken, and this commit marks them xfail.
However, this has implications for the tests of the default, secure
behavior, because until the "allowed" versions work on Windows, it
will be unclear if either are using a payload that is effective and
that corresponds to the way its effect is examined. (Fortunately,
all are working on other OSes, and the affected code under test
does not appear highly dependent on OS, so the fix is *probably*
fully working on Windows as well.)

The tests of unsafe options are among those introduced originally
in gitpython-developers#1521. They are regression tests for gitpython-developers#1515 (CVE-2022-24439).
The unsafe options tests are paired: a test for the usual, default
behavior of forbidding the option, and a test for the behavior when
the option is explicitly allowed. Both tests use a payload that is
intended to produce the side effect of a file of a specific name
being created in a temporary directory.

All the tests work on Unix-like systems. On Windows, the tests of
the *allowed* cases are broken, and this commit marks them xfail.
However, this has implications for the tests of the default, secure
behavior, because until the "allowed" versions work on Windows, it
will be unclear if either are using a payload that is effective and
that corresponds to the way its effect is examined. (Fortunately,
all are working on other OSes, and the affected code under test
does not appear highly dependent on OS, so the fix is *probably*
fully working on Windows as well.)

The tests of unsafe options are among those introduced originally
in gitpython-developers#1521. They are regression tests for gitpython-developers#1515 (CVE-2022-24439).
The unsafe options tests are paired: a test for the usual, default
behavior of forbidding the option, and a test for the behavior when
the option is explicitly allowed. In each such pair, both tests use
a payload that is intended to produce the side effect of a file of
a specific name being created in a temporary directory.

All the tests work on Unix-like systems. On Windows, the tests of
the *allowed* cases are broken, and this commit marks them xfail.
However, this has implications for the tests of the default, secure
behavior, because until the "allowed" versions work on Windows, it
will be unclear if either are using a payload that is effective and
that corresponds to the way its effect is examined. (Fortunately,
all are working on other OSes, and the affected code under test
does not appear highly dependent on OS, so the fix is *probably*
fully working on Windows as well.)

The tests of unsafe options are among those introduced originally
in gitpython-developers#1521. They are regression tests for gitpython-developers#1515 (CVE-2022-24439).
The unsafe options tests are paired: a test for the usual, default
behavior of forbidding the option, and a test for the behavior when
the option is explicitly allowed. In each such pair, both tests use
a payload that is intended to produce the side effect of a file of
a specific name being created in a temporary directory.

All the tests work on Unix-like systems. On Windows, the tests of
the *allowed* cases are broken, and this commit marks them xfail.
However, this has implications for the tests of the default, secure
behavior, because until the "allowed" versions work on Windows, it
will be unclear if either are using a payload that is effective and
that corresponds to the way its effect is examined.

Specifically, the "\" characters in the path seem to be treated as
escape characters rather than literally. Also, "touch" is not a
native Windows command, and the "touch" command in Git for Windows
maps disallowed occurrences of ":" in filenames to a separate code
point in the Private Use Area of the Basic Multilingual Plane.

The tests of unsafe options are among those introduced originally
in gitpython-developers#1521. They are regression tests for gitpython-developers#1515 (CVE-2022-24439).
The unsafe options tests are paired: a test for the usual, default
behavior of forbidding the option, and a test for the behavior when
the option is explicitly allowed. In each such pair, both tests use
a payload that is intended to produce the side effect of a file of
a specific name being created in a temporary directory.

All the tests work on Unix-like systems. On Windows, the tests of
the *allowed* cases are broken, and this commit marks them xfail.
However, this has implications for the tests of the default, secure
behavior, because until the "allowed" versions work on Windows, it
will be unclear if either are using a payload that is effective and
that corresponds to the way its effect is examined.

What *seems* to happen is this: The "\" characters in the path are
treated as shell escape characters rather than literally, with the
effect of disappearing in most paths since most letters lack
special meaning when escaped. Also, "touch" is not a native Windows
command, and the "touch" command provided by Git for Windows is
linked against MSYS2 libraries, causing it to map (some?)
occurrences of ":" in filenames to a separate code point in the
Private Use Area of the Basic Multilingual Plane. The result is a
path with no directory separators or drive letter. It denotes a
file of an unintended name in the current directory, which is never
the intended location. The current directory depends on GitPython
implementation details, but at present it's the top-level directory
of the rw_repo working tree. A new unstaged file, named like
"C\357\200\272UsersekAppDataLocalTemptmpc7x4xik5pwn", can be
observed there (this is how "git status" will format the name).

Fortunately, this and all related tests are working on other OSes,
and the affected code under test does not appear highly dependent
on OS. So the fix is *probably* fully working on Windows as well.

The tests of unsafe options are among those introduced originally
in gitpython-developers#1521. They are regression tests for gitpython-developers#1515 (CVE-2022-24439).
The unsafe options tests are paired: a test for the usual, default
behavior of forbidding the option, and a test for the behavior when
the option is explicitly allowed. In each such pair, both tests use
a payload that is intended to produce the side effect of a file of
a specific name being created in a temporary directory.

All the tests work on Unix-like systems. On Windows, the tests of
the *allowed* cases are broken, and this commit marks them xfail.
However, this has implications for the tests of the default, secure
behavior, because until the "allowed" versions work on Windows, it
will be unclear if either are using a payload that is effective and
that corresponds to the way its effect is examined.

What *seems* to happen is this: The "\" characters in the path are
treated as shell escape characters rather than literally, with the
effect of disappearing in most paths since most letters lack
special meaning when escaped. Also, "touch" is not a native Windows
command, and the "touch" command provided by Git for Windows is
linked against MSYS2 libraries, causing it to map (some?)
occurrences of ":" in filenames to a separate code point in the
Private Use Area of the Basic Multilingual Plane. The result is a
path with no directory separators or drive letter. It denotes a
file of an unintended name in the current directory, which is never
the intended location. The current directory depends on GitPython
implementation details, but at present it's the top-level directory
of the rw_repo working tree. A new unstaged file, named like
"C\357\200\272UsersekAppDataLocalTemptmpc7x4xik5pwn", can be
observed there (this is how "git status" will format the name).

Fortunately, this and all related tests are working on other OSes,
and the affected code under test does not appear highly dependent
on OS. So the fix is *probably* fully working on Windows as well.