Test that we can successfully clone a repository that is namespace
scoped to a bare repository locally. We need not specify a checkout
branch in this case (obviously, since we do not check anything out in a
bare clone).
Only allow the remote default branch checking to fail when the remote
default branch doesn't exist (`git_remote__default_branch` returns
`GIT_ENOTFOUND`). If there was any other type of error - for example, an
allocation failure - we should not swallow that and continue to fail.
This allows us to support the case when a remote has not advertised a
HEAD -- this is possible, for example, when the remote has constrained
the caller to a particular namespace. But other remote failures remain
as failures.
We previously (correctly) cleaned up the git daemon and SSH server, but
failed to clean up our bespoke HTTP server and HTTP proxies. Capture
their PIDs on process creation and kill them when we shut down.
In commit 6bb358786 ("clone: set refs/remotes/origin/HEAD to default
branch when branch is specified, attempt 2") libgit2 was changed to set
the default remote branch when one was copied.
But it makes update_head_to_branch() return an error if the origin
doesn't even *have* a HEAD in the first place, since
git_remote_default_branch() will fail.
That's entirely wrong, and means that you cannot do "git_clone()" of a
particular branch on a remote repository when that remote doesn't have a
default branch at all.
So don't set the error code.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
slide_hash knowingly reads (possibly) uninitialised memory, see comment
lower down about prev[n] potentially being garbage. In this case, the
result is never used - so we don't care about MSAN complaining about
this read.
By adding the no_sanitize("memory") attribute, clients of zlib won't
see this (unnecessary) error when building and running with
MemorySanitizer. An alternative approach is for clients to build zlib
with -fsanitize-ignorelist=... where the ignorelist contains something
like 'fun:slide_hash'. But that's more work and needs to be redone
for any and all CI systems running a given project with MSAN. Adding
this annotation to zlib's sources is overall more convenient - but
also won't affect non-MSAN builds.
This specific issue was found while running git's test suite, but has
also been reported by other clients, see e.g. #518.
In the ownership checks implemented for CVE-2022-24765, we disallowed
users to access their own repositories when running with `sudo`.
Examine the `SUDO_UID` environment variable and allow users running
with `sudo`. This matches git's behavior.
To match git's behavior with CVE 2022-29187, validate not only the
working directory, but also the gitdir and gitlink (if it exists). This
a follow up to CVE-2022-24765 that was fixed earlier.
Allow the user ownership to match if the file is owned by the admin
group and the user is in the admin group, even if the current process is
not running as administrator directly.
The file ownership concepts can reflect the actual file ownership, they
are not necessarily limited to mocking the interface. Rename them so
that they can be more broadly applicable.
This reverts commit cdff2f0237.
This change erroneously allowed system users to own a worktree; this
should only be allowed when the current user is in the Administrator
group on Windows as well.
