2011-12-13 19:05:07 +00:00
|
|
|
{- git repository configuration handling
|
|
|
|
-
|
deal with git's changes for CVE-2022-24765
Deal with git's recent changes to fix CVE-2022-24765, which prevent using
git in a repository owned by someone else.
That makes git config --list not list the repo's configs, only global
configs. So annex.uuid and annex.version are not visible to git-annex.
It displayed a message about that, which is not right for this situation.
Detect the situation and display a better message, similar to the one other
git commands display.
Also, git-annex init when run in that situation would overwrite annex.uuid
with a new one, since it couldn't see the old one. Add a check to prevent
it running too in this situation. It may be that this fix has security
implications, if a config set by the malicious user who owns the repo
causes git or git-annex to run code. I don't think any git-annex configs
get run by git-annex init. It may be that some git config of a command
does get run by one of the git commands that git-annex init runs. ("git
status" is the command that prompted the CVE-2022-24765, since
core.fsmonitor can cause it to run a command). Since I don't know how
to exploit this, I'm not treating it as a security fix for now.
Note that passing --git-dir makes git bypass the security check. git-annex
does pass --git-dir to most calls to git, which it does to avoid needing
chdir to the directory containing a git repository when accessing a remote.
So, it's possible that somewhere in git-annex it gets as far as running git
with --git-dir, and git reads some configs that are unsafe (what
CVE-2022-24765 is about). This seems unlikely, it would have to be part of
git-annex that runs in git repositories that have no (visible) annex.uuid,
and git-annex init is the only one that I can think of that then goes on to
run git, as discussed earlier. But I've not fully ruled out there being
others..
The git developers seem mostly worried about "git status" or a similar
command implicitly run by a shell prompt, not an explicit use of git in
such a repository. For example, Ævar Arnfjörð Bjarma wrote:
> * There are other bits of config that also point to executable things,
> e.g. core.editor, aliases etc, but nothing has been found yet that
> provides the "at a distance" effect that the core.fsmonitor vector
> does.
>
> I.e. a user is unlikely to go to /tmp/some-crap/here and run "git
> commit", but they (or their shell prompt) might run "git status", and
> if you have a /tmp/.git ...
Sponsored-by: Jarkko Kniivilä on Patreon
2022-05-20 18:18:19 +00:00
|
|
|
- Copyright 2010-2022 Joey Hess <id@joeyh.name>
|
2011-12-13 19:05:07 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2011-12-13 19:05:07 +00:00
|
|
|
-}
|
|
|
|
|
2019-11-27 20:54:11 +00:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
|
|
|
|
2011-12-15 20:04:08 +00:00
|
|
|
module Git.Config where
|
2011-12-13 19:05:07 +00:00
|
|
|
|
|
|
|
import qualified Data.Map as M
|
2019-11-27 20:54:11 +00:00
|
|
|
import qualified Data.ByteString as S
|
|
|
|
import qualified Data.ByteString.Char8 as S8
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
import Data.Char
|
2019-12-09 17:49:05 +00:00
|
|
|
import qualified System.FilePath.ByteString as P
|
2020-01-22 17:20:06 +00:00
|
|
|
import Control.Concurrent.Async
|
2011-12-13 19:05:07 +00:00
|
|
|
|
|
|
|
import Common
|
|
|
|
import Git
|
|
|
|
import Git.Types
|
2015-03-02 20:43:44 +00:00
|
|
|
import qualified Git.Command
|
2018-01-09 19:36:56 +00:00
|
|
|
import qualified Git.Construct
|
2012-10-25 22:17:32 +00:00
|
|
|
import Utility.UserInfo
|
deal with git's changes for CVE-2022-24765
Deal with git's recent changes to fix CVE-2022-24765, which prevent using
git in a repository owned by someone else.
That makes git config --list not list the repo's configs, only global
configs. So annex.uuid and annex.version are not visible to git-annex.
It displayed a message about that, which is not right for this situation.
Detect the situation and display a better message, similar to the one other
git commands display.
Also, git-annex init when run in that situation would overwrite annex.uuid
with a new one, since it couldn't see the old one. Add a check to prevent
it running too in this situation. It may be that this fix has security
implications, if a config set by the malicious user who owns the repo
causes git or git-annex to run code. I don't think any git-annex configs
get run by git-annex init. It may be that some git config of a command
does get run by one of the git commands that git-annex init runs. ("git
status" is the command that prompted the CVE-2022-24765, since
core.fsmonitor can cause it to run a command). Since I don't know how
to exploit this, I'm not treating it as a security fix for now.
Note that passing --git-dir makes git bypass the security check. git-annex
does pass --git-dir to most calls to git, which it does to avoid needing
chdir to the directory containing a git repository when accessing a remote.
So, it's possible that somewhere in git-annex it gets as far as running git
with --git-dir, and git reads some configs that are unsafe (what
CVE-2022-24765 is about). This seems unlikely, it would have to be part of
git-annex that runs in git repositories that have no (visible) annex.uuid,
and git-annex init is the only one that I can think of that then goes on to
run git, as discussed earlier. But I've not fully ruled out there being
others..
The git developers seem mostly worried about "git status" or a similar
command implicitly run by a shell prompt, not an explicit use of git in
such a repository. For example, Ævar Arnfjörð Bjarma wrote:
> * There are other bits of config that also point to executable things,
> e.g. core.editor, aliases etc, but nothing has been found yet that
> provides the "at a distance" effect that the core.fsmonitor vector
> does.
>
> I.e. a user is unlikely to go to /tmp/some-crap/here and run "git
> commit", but they (or their shell prompt) might run "git status", and
> if you have a /tmp/.git ...
Sponsored-by: Jarkko Kniivilä on Patreon
2022-05-20 18:18:19 +00:00
|
|
|
import Utility.Process.Transcript
|
2022-05-31 16:25:11 +00:00
|
|
|
import Utility.Debug
|
2011-12-13 19:05:07 +00:00
|
|
|
|
2019-12-05 18:36:43 +00:00
|
|
|
{- Returns a single git config setting, or a fallback value if not set. -}
|
|
|
|
get :: ConfigKey -> ConfigValue -> Repo -> ConfigValue
|
|
|
|
get key fallback repo = M.findWithDefault fallback key (config repo)
|
2011-12-13 19:05:07 +00:00
|
|
|
|
2019-12-05 18:36:43 +00:00
|
|
|
{- Returns a list of values. -}
|
|
|
|
getList :: ConfigKey -> Repo -> [ConfigValue]
|
2012-04-22 05:13:09 +00:00
|
|
|
getList key repo = M.findWithDefault [] key (fullconfig repo)
|
|
|
|
|
2012-01-10 03:31:44 +00:00
|
|
|
{- Returns a single git config setting, if set. -}
|
2019-12-05 18:36:43 +00:00
|
|
|
getMaybe :: ConfigKey -> Repo -> Maybe ConfigValue
|
2012-01-10 03:31:44 +00:00
|
|
|
getMaybe key repo = M.lookup key (config repo)
|
|
|
|
|
2012-05-18 22:20:53 +00:00
|
|
|
{- Runs git config and populates a repo with its config.
|
2012-05-19 14:22:43 +00:00
|
|
|
- Avoids re-reading config when run repeatedly. -}
|
|
|
|
read :: Repo -> IO Repo
|
|
|
|
read repo@(Repo { config = c })
|
|
|
|
| c == M.empty = read' repo
|
|
|
|
| otherwise = return repo
|
|
|
|
|
|
|
|
{- Reads config even if it was read before. -}
|
|
|
|
reRead :: Repo -> IO Repo
|
2012-10-14 21:23:40 +00:00
|
|
|
reRead r = read' $ r
|
|
|
|
{ config = M.empty
|
|
|
|
, fullconfig = M.empty
|
|
|
|
}
|
2012-05-19 14:22:43 +00:00
|
|
|
|
|
|
|
{- Cannot use pipeRead because it relies on the config having been already
|
2012-07-18 19:30:26 +00:00
|
|
|
- read. Instead, chdir to the repo and run git config.
|
2012-05-18 22:20:53 +00:00
|
|
|
-}
|
2012-05-19 14:22:43 +00:00
|
|
|
read' :: Repo -> IO Repo
|
|
|
|
read' repo = go repo
|
2012-12-13 04:24:19 +00:00
|
|
|
where
|
|
|
|
go Repo { location = Local { gitdir = d } } = git_config d
|
|
|
|
go Repo { location = LocalUnknown d } = git_config d
|
|
|
|
go _ = assertLocal repo $ error "internal"
|
2020-06-04 19:36:34 +00:00
|
|
|
git_config d = withCreateProcess p (git_config' p)
|
2012-12-13 04:24:19 +00:00
|
|
|
where
|
2020-10-23 19:51:38 +00:00
|
|
|
params = ["config", "--null", "--list"]
|
2012-12-13 04:24:19 +00:00
|
|
|
p = (proc "git" params)
|
2020-10-23 19:51:38 +00:00
|
|
|
{ cwd = Just (fromRawFilePath d)
|
|
|
|
, env = gitEnv repo
|
2020-06-04 19:36:34 +00:00
|
|
|
, std_out = CreatePipe
|
2012-12-13 04:24:19 +00:00
|
|
|
}
|
2020-06-04 19:36:34 +00:00
|
|
|
git_config' p _ (Just hout) _ pid =
|
|
|
|
forceSuccessProcess p pid
|
|
|
|
`after`
|
|
|
|
hRead repo ConfigNullList hout
|
|
|
|
git_config' _ _ _ _ _ = error "internal"
|
2011-12-13 19:05:07 +00:00
|
|
|
|
2012-08-08 17:15:35 +00:00
|
|
|
{- Gets the global git config, returning a dummy Repo containing it. -}
|
2012-09-23 16:43:14 +00:00
|
|
|
global :: IO (Maybe Repo)
|
2012-08-08 17:15:35 +00:00
|
|
|
global = do
|
2012-09-23 16:43:14 +00:00
|
|
|
home <- myHomeDir
|
|
|
|
ifM (doesFileExist $ home </> ".gitconfig")
|
2020-06-04 19:36:34 +00:00
|
|
|
( Just <$> withCreateProcess p go
|
2012-09-23 16:43:14 +00:00
|
|
|
, return Nothing
|
|
|
|
)
|
2012-12-13 04:24:19 +00:00
|
|
|
where
|
|
|
|
params = ["config", "--null", "--list", "--global"]
|
|
|
|
p = (proc "git" params)
|
2020-06-04 19:36:34 +00:00
|
|
|
{ std_out = CreatePipe }
|
|
|
|
go _ (Just hout) _ pid =
|
|
|
|
forceSuccessProcess p pid
|
|
|
|
`after`
|
|
|
|
hRead (Git.Construct.fromUnknown) ConfigNullList hout
|
|
|
|
go _ _ _ _ = error "internal"
|
2012-08-08 17:15:35 +00:00
|
|
|
|
2011-12-13 19:05:07 +00:00
|
|
|
{- Reads git config from a handle and populates a repo with it. -}
|
2020-04-13 17:05:41 +00:00
|
|
|
hRead :: Repo -> ConfigStyle -> Handle -> IO Repo
|
|
|
|
hRead repo st h = do
|
2019-11-27 20:54:11 +00:00
|
|
|
val <- S.hGetContents h
|
2020-04-13 17:05:41 +00:00
|
|
|
store val st repo
|
2011-12-13 19:05:07 +00:00
|
|
|
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
{- Stores a git config into a Repo, returning the new version of the Repo.
|
|
|
|
- The git config may be multiple lines, or a single line.
|
|
|
|
- Config settings can be updated incrementally.
|
|
|
|
-}
|
2020-04-13 17:05:41 +00:00
|
|
|
store :: S.ByteString -> ConfigStyle -> Repo -> IO Repo
|
|
|
|
store s st repo = do
|
|
|
|
let c = parse s st
|
2018-01-09 19:36:56 +00:00
|
|
|
updateLocation $ repo
|
2011-12-30 18:07:17 +00:00
|
|
|
{ config = (M.map Prelude.head c) `M.union` config repo
|
|
|
|
, fullconfig = M.unionWith (++) c (fullconfig repo)
|
|
|
|
}
|
2011-12-13 19:05:07 +00:00
|
|
|
|
2019-11-18 20:09:09 +00:00
|
|
|
{- Stores a single config setting in a Repo, returning the new version of
|
|
|
|
- the Repo. Config settings can be updated incrementally. -}
|
2019-12-05 18:36:43 +00:00
|
|
|
store' :: ConfigKey -> ConfigValue -> Repo -> Repo
|
2019-11-18 20:09:09 +00:00
|
|
|
store' k v repo = repo
|
|
|
|
{ config = M.singleton k v `M.union` config repo
|
|
|
|
, fullconfig = M.unionWith (++) (M.singleton k [v]) (fullconfig repo)
|
|
|
|
}
|
|
|
|
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
{- Updates the location of a repo, based on its configuration.
|
|
|
|
-
|
|
|
|
- Git.Construct makes LocalUknown repos, of which only a directory is
|
|
|
|
- known. Once the config is read, this can be fixed up to a Local repo,
|
|
|
|
- based on the core.bare and core.worktree settings.
|
|
|
|
-}
|
2012-10-16 04:02:14 +00:00
|
|
|
updateLocation :: Repo -> IO Repo
|
2012-05-19 14:51:22 +00:00
|
|
|
updateLocation r@(Repo { location = LocalUnknown d })
|
2019-12-09 17:49:05 +00:00
|
|
|
| isBare r = ifM (doesDirectoryExist (fromRawFilePath dotgit))
|
2013-11-23 03:27:15 +00:00
|
|
|
( updateLocation' r $ Local dotgit Nothing
|
|
|
|
, updateLocation' r $ Local d Nothing
|
|
|
|
)
|
|
|
|
| otherwise = updateLocation' r $ Local dotgit (Just d)
|
|
|
|
where
|
2019-12-09 17:49:05 +00:00
|
|
|
dotgit = d P.</> ".git"
|
2012-10-16 04:02:14 +00:00
|
|
|
updateLocation r@(Repo { location = l@(Local {}) }) = updateLocation' r l
|
|
|
|
updateLocation r = return r
|
|
|
|
|
|
|
|
updateLocation' :: Repo -> RepoLocation -> IO Repo
|
|
|
|
updateLocation' r l = do
|
|
|
|
l' <- case getMaybe "core.worktree" r of
|
|
|
|
Nothing -> return l
|
2019-12-05 18:36:43 +00:00
|
|
|
Just (ConfigValue d) -> do
|
2012-10-16 04:02:14 +00:00
|
|
|
{- core.worktree is relative to the gitdir -}
|
2020-10-28 19:40:50 +00:00
|
|
|
top <- absPath (gitdir l)
|
|
|
|
let p = absPathFrom top d
|
|
|
|
return $ l { worktree = Just p }
|
2020-04-13 17:35:22 +00:00
|
|
|
Just NoConfigValue -> return l
|
2012-10-16 04:02:14 +00:00
|
|
|
return $ r { location = l' }
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
|
2020-04-13 17:05:41 +00:00
|
|
|
data ConfigStyle = ConfigList | ConfigNullList
|
|
|
|
|
2011-12-15 16:46:04 +00:00
|
|
|
{- Parses git config --list or git config --null --list output into a
|
|
|
|
- config map. -}
|
2020-04-13 17:05:41 +00:00
|
|
|
parse :: S.ByteString -> ConfigStyle -> M.Map ConfigKey [ConfigValue]
|
|
|
|
parse s st
|
2019-11-27 20:54:11 +00:00
|
|
|
| S.null s = M.empty
|
2020-04-13 17:05:41 +00:00
|
|
|
| otherwise = case st of
|
|
|
|
ConfigList -> sep eq $ S.split nl s
|
|
|
|
ConfigNullList -> sep nl $ S.split 0 s
|
2012-12-13 04:24:19 +00:00
|
|
|
where
|
2019-11-27 20:54:11 +00:00
|
|
|
nl = fromIntegral (ord '\n')
|
|
|
|
eq = fromIntegral (ord '=')
|
|
|
|
|
|
|
|
sep c = M.fromListWith (++)
|
2020-04-13 17:35:22 +00:00
|
|
|
. map (\(k,v) -> (ConfigKey k, [mkval v]))
|
2019-11-27 20:54:11 +00:00
|
|
|
. map (S.break (== c))
|
2020-04-13 17:35:22 +00:00
|
|
|
|
|
|
|
mkval v
|
|
|
|
| S.null v = NoConfigValue
|
|
|
|
| otherwise = ConfigValue (S.drop 1 v)
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
|
2019-12-20 19:01:34 +00:00
|
|
|
{- Checks if a string from git config is a true/false value. -}
|
|
|
|
isTrueFalse :: String -> Maybe Bool
|
2021-08-11 00:45:02 +00:00
|
|
|
isTrueFalse = isTrueFalse' . ConfigValue . encodeBS
|
2019-11-27 20:54:11 +00:00
|
|
|
|
2019-12-20 19:01:34 +00:00
|
|
|
isTrueFalse' :: ConfigValue -> Maybe Bool
|
|
|
|
isTrueFalse' (ConfigValue s)
|
2020-04-13 17:45:40 +00:00
|
|
|
| s' == "yes" = Just True
|
|
|
|
| s' == "on" = Just True
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
| s' == "true" = Just True
|
2020-04-13 17:45:40 +00:00
|
|
|
| s' == "1" = Just True
|
|
|
|
|
|
|
|
| s' == "no" = Just False
|
|
|
|
| s' == "off" = Just False
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
| s' == "false" = Just False
|
2020-04-13 17:45:40 +00:00
|
|
|
| s' == "0" = Just False
|
|
|
|
| s' == "" = Just False
|
|
|
|
|
2020-11-16 14:09:25 +00:00
|
|
|
-- Git treats any number other than 0 as true,
|
|
|
|
-- including negative numbers.
|
|
|
|
| S8.all (\c -> isDigit c || c == '-') s' = Just True
|
|
|
|
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
| otherwise = Nothing
|
2012-12-13 04:24:19 +00:00
|
|
|
where
|
2019-11-27 20:54:11 +00:00
|
|
|
s' = S8.map toLower s
|
2020-04-13 17:35:22 +00:00
|
|
|
isTrueFalse' NoConfigValue = Just True
|
2012-05-19 14:51:22 +00:00
|
|
|
|
2013-01-27 11:43:05 +00:00
|
|
|
boolConfig :: Bool -> String
|
|
|
|
boolConfig True = "true"
|
|
|
|
boolConfig False = "false"
|
|
|
|
|
2019-11-27 20:54:11 +00:00
|
|
|
boolConfig' :: Bool -> S.ByteString
|
|
|
|
boolConfig' True = "true"
|
|
|
|
boolConfig' False = "false"
|
|
|
|
|
2012-05-19 14:51:22 +00:00
|
|
|
isBare :: Repo -> Bool
|
2019-12-20 19:01:34 +00:00
|
|
|
isBare r = fromMaybe False $ isTrueFalse' =<< getMaybe coreBare r
|
2013-11-05 19:31:37 +00:00
|
|
|
|
2019-12-02 14:57:09 +00:00
|
|
|
coreBare :: ConfigKey
|
2013-11-05 19:31:37 +00:00
|
|
|
coreBare = "core.bare"
|
2013-09-24 21:51:12 +00:00
|
|
|
|
|
|
|
{- Runs a command to get the configuration of a repo,
|
|
|
|
- and returns a repo populated with the configuration, as well as the raw
|
2020-11-19 19:34:26 +00:00
|
|
|
- output and the standard error of the command. -}
|
|
|
|
fromPipe :: Repo -> String -> [CommandParam] -> ConfigStyle -> IO (Either SomeException (Repo, S.ByteString, String))
|
2020-06-05 19:16:57 +00:00
|
|
|
fromPipe r cmd params st = tryNonAsync $ withCreateProcess p go
|
2020-06-04 19:36:34 +00:00
|
|
|
where
|
|
|
|
p = (proc cmd $ toCommand params)
|
|
|
|
{ std_out = CreatePipe
|
|
|
|
, std_err = CreatePipe
|
|
|
|
}
|
2020-07-21 20:14:25 +00:00
|
|
|
go _ (Just hout) (Just herr) pid =
|
2020-11-19 19:34:26 +00:00
|
|
|
withAsync (getstderr pid herr []) $ \errreader -> do
|
2020-07-21 20:14:25 +00:00
|
|
|
val <- S.hGetContents hout
|
2020-11-19 19:34:26 +00:00
|
|
|
err <- wait errreader
|
2020-07-21 20:14:25 +00:00
|
|
|
forceSuccessProcess p pid
|
|
|
|
r' <- store val st r
|
|
|
|
return (r', val, err)
|
2020-06-04 19:36:34 +00:00
|
|
|
go _ _ _ _ = error "internal"
|
2013-09-24 21:51:12 +00:00
|
|
|
|
2020-11-19 19:34:26 +00:00
|
|
|
getstderr pid herr c = hGetLineUntilExitOrEOF pid herr >>= \case
|
|
|
|
Just l -> getstderr pid herr (l:c)
|
|
|
|
Nothing -> return (unlines (reverse c))
|
|
|
|
|
2013-09-27 20:21:56 +00:00
|
|
|
{- Reads git config from a specified file and returns the repo populated
|
|
|
|
- with the configuration. -}
|
2020-11-19 19:34:26 +00:00
|
|
|
fromFile :: Repo -> FilePath -> IO (Either SomeException (Repo, S.ByteString, String))
|
2013-09-27 20:21:56 +00:00
|
|
|
fromFile r f = fromPipe r "git"
|
|
|
|
[ Param "config"
|
|
|
|
, Param "--file"
|
|
|
|
, File f
|
|
|
|
, Param "--list"
|
2020-04-13 17:05:41 +00:00
|
|
|
] ConfigList
|
2013-10-01 19:16:20 +00:00
|
|
|
|
2021-11-08 19:55:27 +00:00
|
|
|
{- Changes a git config setting in .git/config. -}
|
|
|
|
change :: ConfigKey -> S.ByteString -> Repo -> IO Bool
|
|
|
|
change (ConfigKey k) v = Git.Command.runBool
|
|
|
|
[ Param "config"
|
|
|
|
, Param (decodeBS k)
|
|
|
|
, Param (decodeBS v)
|
|
|
|
]
|
|
|
|
|
2013-10-01 19:16:20 +00:00
|
|
|
{- Changes a git config setting in the specified config file.
|
|
|
|
- (Creates the file if it does not already exist.) -}
|
2019-12-02 14:57:09 +00:00
|
|
|
changeFile :: FilePath -> ConfigKey -> S.ByteString -> IO Bool
|
|
|
|
changeFile f (ConfigKey k) v = boolSystem "git"
|
2013-10-01 19:16:20 +00:00
|
|
|
[ Param "config"
|
|
|
|
, Param "--file"
|
|
|
|
, File f
|
2021-08-11 00:45:02 +00:00
|
|
|
, Param (decodeBS k)
|
|
|
|
, Param (decodeBS v)
|
2013-10-01 19:16:20 +00:00
|
|
|
]
|
2015-03-02 20:43:44 +00:00
|
|
|
|
|
|
|
{- Unsets a git config setting, in both the git repo,
|
|
|
|
- and the cached config in the Repo.
|
|
|
|
-
|
|
|
|
- If unsetting the config fails, including in a read-only repo, or
|
|
|
|
- when the config is not set, returns Nothing.
|
|
|
|
-}
|
2019-12-02 14:57:09 +00:00
|
|
|
unset :: ConfigKey -> Repo -> IO (Maybe Repo)
|
|
|
|
unset ck@(ConfigKey k) r = ifM (Git.Command.runBool ps r)
|
|
|
|
( return $ Just $ r { config = M.delete ck (config r) }
|
2015-03-02 20:43:44 +00:00
|
|
|
, return Nothing
|
|
|
|
)
|
|
|
|
where
|
2021-08-11 00:45:02 +00:00
|
|
|
ps = [Param "config", Param "--unset-all", Param (decodeBS k)]
|
deal with git's changes for CVE-2022-24765
Deal with git's recent changes to fix CVE-2022-24765, which prevent using
git in a repository owned by someone else.
That makes git config --list not list the repo's configs, only global
configs. So annex.uuid and annex.version are not visible to git-annex.
It displayed a message about that, which is not right for this situation.
Detect the situation and display a better message, similar to the one other
git commands display.
Also, git-annex init when run in that situation would overwrite annex.uuid
with a new one, since it couldn't see the old one. Add a check to prevent
it running too in this situation. It may be that this fix has security
implications, if a config set by the malicious user who owns the repo
causes git or git-annex to run code. I don't think any git-annex configs
get run by git-annex init. It may be that some git config of a command
does get run by one of the git commands that git-annex init runs. ("git
status" is the command that prompted the CVE-2022-24765, since
core.fsmonitor can cause it to run a command). Since I don't know how
to exploit this, I'm not treating it as a security fix for now.
Note that passing --git-dir makes git bypass the security check. git-annex
does pass --git-dir to most calls to git, which it does to avoid needing
chdir to the directory containing a git repository when accessing a remote.
So, it's possible that somewhere in git-annex it gets as far as running git
with --git-dir, and git reads some configs that are unsafe (what
CVE-2022-24765 is about). This seems unlikely, it would have to be part of
git-annex that runs in git repositories that have no (visible) annex.uuid,
and git-annex init is the only one that I can think of that then goes on to
run git, as discussed earlier. But I've not fully ruled out there being
others..
The git developers seem mostly worried about "git status" or a similar
command implicitly run by a shell prompt, not an explicit use of git in
such a repository. For example, Ævar Arnfjörð Bjarma wrote:
> * There are other bits of config that also point to executable things,
> e.g. core.editor, aliases etc, but nothing has been found yet that
> provides the "at a distance" effect that the core.fsmonitor vector
> does.
>
> I.e. a user is unlikely to go to /tmp/some-crap/here and run "git
> commit", but they (or their shell prompt) might run "git status", and
> if you have a /tmp/.git ...
Sponsored-by: Jarkko Kniivilä on Patreon
2022-05-20 18:18:19 +00:00
|
|
|
|
|
|
|
{- git "fixed" CVE-2022-24765 by preventing git-config from
|
|
|
|
- listing per-repo configs when the repo is not owned by
|
|
|
|
- the current user. Detect if this fix is in effect for the
|
|
|
|
- repo.
|
|
|
|
-}
|
|
|
|
checkRepoConfigInaccessible :: Repo -> IO Bool
|
|
|
|
checkRepoConfigInaccessible r = do
|
|
|
|
-- Cannot use gitCommandLine here because specifying --git-dir
|
|
|
|
-- will bypass the git security check.
|
|
|
|
let p = (proc "git" ["config", "--local", "--list"])
|
|
|
|
{ cwd = Just (fromRawFilePath (repoPath r))
|
|
|
|
, env = gitEnv r
|
|
|
|
}
|
2022-05-31 16:25:11 +00:00
|
|
|
(out, ok) <- processTranscript' p Nothing
|
|
|
|
if not ok
|
|
|
|
then do
|
|
|
|
debug (DebugSource "Git.Config") ("config output: " ++ out)
|
|
|
|
return True
|
|
|
|
else return False
|