2013-01-01 17:52:47 +00:00
|
|
|
{- git-annex configuration
|
|
|
|
|
-
|
2019-11-11 20:15:05 +00:00
|
|
|
- Copyright 2012-2019 Joey Hess <id@joeyh.name>
|
2013-01-01 17:52:47 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2013-01-01 17:52:47 +00:00
|
|
|
-}
|
|
|
|
|
|
2019-11-27 20:54:11 +00:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
|
|
|
|
|
2013-01-01 17:52:47 +00:00
|
|
|
module Types.GitConfig (
|
2017-02-03 17:40:14 +00:00
|
|
|
Configurable(..),
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
ConfigSource(..),
|
2013-01-01 17:52:47 +00:00
|
|
|
GitConfig(..),
|
|
|
|
|
extractGitConfig,
|
2017-02-03 17:40:14 +00:00
|
|
|
mergeGitConfig,
|
2013-01-01 17:52:47 +00:00
|
|
|
RemoteGitConfig(..),
|
|
|
|
|
extractRemoteGitConfig,
|
2017-08-17 16:26:14 +00:00
|
|
|
dummyRemoteGitConfig,
|
2013-01-01 17:52:47 +00:00
|
|
|
) where
|
|
|
|
|
|
|
|
|
|
import Common
|
|
|
|
|
import qualified Git
|
|
|
|
|
import qualified Git.Config
|
2015-02-12 19:44:10 +00:00
|
|
|
import qualified Git.Construct
|
removal of the rest of remoteGitConfig
In keyUrls, the GitConfig is used only by annexLocations
to support configured Differences. Since such configurations affect all
clones of a repository, the local repo's GitConfig must have the same
information as the remote's GitConfig would have. So, used getGitConfig
to get the local GitConfig, which is cached and so available cheaply.
That actually fixed a bug noone had ever noticed: keyUrls is
used for remotes accessed over http. The full git config of such a
remote is normally not available, so the remoteGitConfig that keyUrls
used would not have the necessary information in it.
In copyFromRemoteCheap', it uses gitAnnexLocation,
which does need the GitConfig of the remote repo itself in order to
check if it's crippled, supports symlinks, etc. So, made the
State include that GitConfig, cached. The use of gitAnnexLocation is
within a (not $ Git.repoIsUrl repo) guard, so it's local, and so
its git config will always be read and available.
(Note that gitAnnexLocation in turn calls annexLocations, so the
Differences config it uses in this case comes from the remote repo's
GitConfig and not from the local repo's GitConfig. As explained above
this is ok since they must have the same value.)
Not very happy with this mess of different GitConfigs not type-safe and
some read only sometimes etc. Very hairy. Think I got it this change
right. Test suite passes..
This commit was sponsored by Ethan Aubin.
2018-06-05 18:23:34 +00:00
|
|
|
import Git.Types
|
2017-02-17 18:04:43 +00:00
|
|
|
import Git.ConfigTypes
|
2019-11-11 22:20:35 +00:00
|
|
|
import Git.Branch (CommitMode(..))
|
2013-01-01 17:52:47 +00:00
|
|
|
import Utility.DataUnits
|
2013-03-13 20:16:01 +00:00
|
|
|
import Config.Cost
|
2016-01-20 20:55:06 +00:00
|
|
|
import Types.UUID
|
2013-11-22 20:04:20 +00:00
|
|
|
import Types.Distribution
|
2014-01-13 18:41:10 +00:00
|
|
|
import Types.Availability
|
2018-10-04 16:47:27 +00:00
|
|
|
import Types.Concurrency
|
2014-01-21 21:08:49 +00:00
|
|
|
import Types.NumCopies
|
2015-01-27 21:38:06 +00:00
|
|
|
import Types.Difference
|
2015-05-14 19:44:08 +00:00
|
|
|
import Types.RefSpec
|
2018-10-25 21:23:53 +00:00
|
|
|
import Types.RepoVersion
|
2017-08-17 16:26:14 +00:00
|
|
|
import Config.DynamicConfig
|
assistant unused file handling
Make sanity checker run git annex unused daily, and queue up transfers
of unused files to any remotes that will have them. The transfer retrying
code works for us here, so eg when a backup disk remote is plugged in,
any transfers to it are done. Once the unused files reach a remote,
they'll be removed locally as unwanted.
If the setup does not cause unused files to go to a remote, they'll pile
up, and the sanity checker detects this using some heuristics that are
pretty good -- 1000 unused files, or 10% of disk used by unused files,
or more disk wasted by unused files than is left free. Once it detects
this, it pops up an alert in the webapp, with a button to take action.
TODO: Webapp UI to configure this, and also the ability to launch an
immediate cleanup of all unused files.
This commit was sponsored by Simon Michael.
2014-01-23 02:48:56 +00:00
|
|
|
import Utility.HumanTime
|
2015-09-09 22:06:49 +00:00
|
|
|
import Utility.Gpg (GpgCmd, mkGpgCmd)
|
2015-11-12 21:47:31 +00:00
|
|
|
import Utility.ThreadScheduler (Seconds(..))
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
import Utility.Url (Scheme, mkScheme)
|
2013-01-01 17:52:47 +00:00
|
|
|
|
2017-08-17 16:26:14 +00:00
|
|
|
import Control.Concurrent.STM
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
import qualified Data.Set as S
|
2017-08-17 16:26:14 +00:00
|
|
|
|
|
|
|
|
-- | A configurable value, that may not be fully determined yet because
|
|
|
|
|
-- the global git config has not yet been loaded.
|
2017-02-03 17:40:14 +00:00
|
|
|
data Configurable a
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
= HasGitConfig a
|
|
|
|
|
-- ^ The git config has a value.
|
|
|
|
|
| HasGlobalConfig a
|
|
|
|
|
-- ^ The global config has a value (and the git config does not).
|
2017-02-03 17:40:14 +00:00
|
|
|
| DefaultConfig a
|
|
|
|
|
-- ^ A default value is known, but not all config sources
|
|
|
|
|
-- have been read yet.
|
2017-02-03 18:31:17 +00:00
|
|
|
deriving (Show)
|
2017-02-03 17:40:14 +00:00
|
|
|
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
data ConfigSource = FromGitConfig | FromGlobalConfig
|
|
|
|
|
|
2013-01-01 17:52:47 +00:00
|
|
|
{- Main git-annex settings. Each setting corresponds to a git-config key
|
|
|
|
|
- such as annex.foo -}
|
|
|
|
|
data GitConfig = GitConfig
|
2018-10-25 21:23:53 +00:00
|
|
|
{ annexVersion :: Maybe RepoVersion
|
2016-01-20 20:55:06 +00:00
|
|
|
, annexUUID :: UUID
|
2014-01-21 21:08:49 +00:00
|
|
|
, annexNumCopies :: Maybe NumCopies
|
2013-01-01 17:52:47 +00:00
|
|
|
, annexDiskReserve :: Integer
|
|
|
|
|
, annexDirect :: Bool
|
2017-05-09 19:04:07 +00:00
|
|
|
, annexBackend :: Maybe String
|
2013-01-01 17:52:47 +00:00
|
|
|
, annexQueueSize :: Maybe Int
|
|
|
|
|
, annexBloomCapacity :: Maybe Int
|
|
|
|
|
, annexBloomAccuracy :: Maybe Int
|
|
|
|
|
, annexSshCaching :: Maybe Bool
|
|
|
|
|
, annexAlwaysCommit :: Bool
|
2018-08-02 18:06:06 +00:00
|
|
|
, annexCommitMessage :: Maybe String
|
2018-02-22 18:25:32 +00:00
|
|
|
, annexMergeAnnexBranches :: Bool
|
2013-01-01 17:52:47 +00:00
|
|
|
, annexDelayAdd :: Maybe Int
|
|
|
|
|
, annexHttpHeaders :: [String]
|
|
|
|
|
, annexHttpHeadersCommand :: Maybe String
|
2017-02-03 17:40:14 +00:00
|
|
|
, annexAutoCommit :: Configurable Bool
|
2017-06-01 16:46:36 +00:00
|
|
|
, annexResolveMerge :: Configurable Bool
|
2017-02-03 18:31:17 +00:00
|
|
|
, annexSyncContent :: Configurable Bool
|
2013-06-18 00:41:17 +00:00
|
|
|
, annexDebug :: Bool
|
2013-01-27 13:33:19 +00:00
|
|
|
, annexWebOptions :: [String]
|
2017-11-29 19:49:05 +00:00
|
|
|
, annexYoutubeDlOptions :: [String]
|
2014-12-17 03:22:46 +00:00
|
|
|
, annexAriaTorrentOptions :: [String]
|
2013-02-14 18:10:36 +00:00
|
|
|
, annexCrippledFileSystem :: Bool
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
, annexLargeFiles :: Configurable (Maybe String)
|
2019-10-23 19:20:00 +00:00
|
|
|
, annexGitAddToAnnex :: Bool
|
2016-01-28 18:04:32 +00:00
|
|
|
, annexAddSmallFiles :: Bool
|
2013-10-29 20:48:06 +00:00
|
|
|
, annexFsckNudge :: Bool
|
2013-11-22 20:04:20 +00:00
|
|
|
, annexAutoUpgrade :: AutoUpgrade
|
2014-01-23 03:10:51 +00:00
|
|
|
, annexExpireUnused :: Maybe (Maybe Duration)
|
2014-01-24 16:58:52 +00:00
|
|
|
, annexSecureEraseCommand :: Maybe String
|
2014-02-23 04:08:29 +00:00
|
|
|
, annexGenMetaData :: Bool
|
2014-03-01 04:31:17 +00:00
|
|
|
, annexListen :: Maybe String
|
2014-03-05 21:44:14 +00:00
|
|
|
, annexStartupScan :: Bool
|
2014-09-05 17:44:09 +00:00
|
|
|
, annexHardLink :: Bool
|
2015-12-27 19:59:59 +00:00
|
|
|
, annexThin :: Bool
|
2015-09-09 22:06:49 +00:00
|
|
|
, annexDifferences :: Differences
|
|
|
|
|
, annexUsedRefSpec :: Maybe RefSpec
|
Do verification of checksums of annex objects downloaded from remotes.
* When annex objects are received into git repositories, their checksums are
verified then too.
* To get the old, faster, behavior of not verifying checksums, set
annex.verify=false, or remote.<name>.annex-verify=false.
* setkey, rekey: These commands also now verify that the provided file
matches the key, unless annex.verify=false.
* reinject: Already verified content; this can now be disabled by
setting annex.verify=false.
recvkey and reinject already did verification, so removed now duplicate
code from them. fsck still does its own verification, which is ok since it
does not use getViaTmp, so verification doesn't happen twice when using fsck
--from.
2015-10-01 19:54:37 +00:00
|
|
|
, annexVerify :: Bool
|
2015-11-12 21:47:31 +00:00
|
|
|
, annexPidLock :: Bool
|
|
|
|
|
, annexPidLockTimeout :: Seconds
|
2019-12-20 19:01:34 +00:00
|
|
|
, annexAddUnlocked :: Configurable (Maybe String)
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
, annexSecureHashesOnly :: Bool
|
2018-03-24 14:37:25 +00:00
|
|
|
, annexRetry :: Maybe Integer
|
|
|
|
|
, annexRetryDelay :: Maybe Seconds
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
, annexAllowedUrlSchemes :: S.Set Scheme
|
2019-05-30 16:43:40 +00:00
|
|
|
, annexAllowedIPAddresses :: String
|
2018-06-21 17:34:11 +00:00
|
|
|
, annexAllowUnverifiedDownloads :: Bool
|
2018-09-24 16:07:46 +00:00
|
|
|
, annexMaxExtensionLength :: Maybe Int
|
2018-10-04 16:47:27 +00:00
|
|
|
, annexJobs :: Concurrency
|
2018-12-04 18:16:56 +00:00
|
|
|
, annexCacheCreds :: Bool
|
2019-09-01 17:29:55 +00:00
|
|
|
, annexAutoUpgradeRepository :: Bool
|
2019-11-11 22:20:35 +00:00
|
|
|
, annexCommitMode :: CommitMode
|
2013-02-15 20:02:35 +00:00
|
|
|
, coreSymlinks :: Bool
|
2015-05-19 19:04:24 +00:00
|
|
|
, coreSharedRepository :: SharedRepository
|
2017-02-17 18:04:43 +00:00
|
|
|
, receiveDenyCurrentBranch :: DenyCurrentBranch
|
2013-09-24 21:25:47 +00:00
|
|
|
, gcryptId :: Maybe String
|
2015-09-09 22:06:49 +00:00
|
|
|
, gpgCmd :: GpgCmd
|
2013-01-01 17:52:47 +00:00
|
|
|
}
|
|
|
|
|
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
extractGitConfig :: ConfigSource -> Git.Repo -> GitConfig
|
|
|
|
|
extractGitConfig configsource r = GitConfig
|
2018-10-25 21:23:53 +00:00
|
|
|
{ annexVersion = RepoVersion <$> getmayberead (annex "version")
|
2016-01-20 20:55:06 +00:00
|
|
|
, annexUUID = maybe NoUUID toUUID $ getmaybe (annex "uuid")
|
2014-01-21 21:08:49 +00:00
|
|
|
, annexNumCopies = NumCopies <$> getmayberead (annex "numcopies")
|
2013-01-01 17:52:47 +00:00
|
|
|
, annexDiskReserve = fromMaybe onemegabyte $
|
2013-02-15 20:02:35 +00:00
|
|
|
readSize dataUnits =<< getmaybe (annex "diskreserve")
|
|
|
|
|
, annexDirect = getbool (annex "direct") False
|
2017-05-09 19:04:07 +00:00
|
|
|
, annexBackend = maybe
|
|
|
|
|
-- annex.backends is the old name of the option, still used
|
|
|
|
|
-- when annex.backend is not set.
|
|
|
|
|
(headMaybe $ getwords (annex "backends"))
|
|
|
|
|
Just
|
|
|
|
|
(getmaybe (annex "backend"))
|
2013-02-15 20:02:35 +00:00
|
|
|
, annexQueueSize = getmayberead (annex "queuesize")
|
|
|
|
|
, annexBloomCapacity = getmayberead (annex "bloomcapacity")
|
|
|
|
|
, annexBloomAccuracy = getmayberead (annex "bloomaccuracy")
|
|
|
|
|
, annexSshCaching = getmaybebool (annex "sshcaching")
|
|
|
|
|
, annexAlwaysCommit = getbool (annex "alwayscommit") True
|
2018-08-02 18:06:06 +00:00
|
|
|
, annexCommitMessage = getmaybe (annex "commitmessage")
|
2018-02-22 18:25:32 +00:00
|
|
|
, annexMergeAnnexBranches = getbool (annex "merge-annex-branches") True
|
2013-02-15 20:02:35 +00:00
|
|
|
, annexDelayAdd = getmayberead (annex "delayadd")
|
|
|
|
|
, annexHttpHeaders = getlist (annex "http-headers")
|
|
|
|
|
, annexHttpHeadersCommand = getmaybe (annex "http-headers-command")
|
2017-02-03 17:40:14 +00:00
|
|
|
, annexAutoCommit = configurable True $
|
|
|
|
|
getmaybebool (annex "autocommit")
|
2017-06-01 16:46:36 +00:00
|
|
|
, annexResolveMerge = configurable True $
|
|
|
|
|
getmaybebool (annex "resolvemerge")
|
2017-02-03 18:31:17 +00:00
|
|
|
, annexSyncContent = configurable False $
|
|
|
|
|
getmaybebool (annex "synccontent")
|
2013-06-18 00:41:17 +00:00
|
|
|
, annexDebug = getbool (annex "debug") False
|
2013-02-15 20:02:35 +00:00
|
|
|
, annexWebOptions = getwords (annex "web-options")
|
2017-11-29 19:49:05 +00:00
|
|
|
, annexYoutubeDlOptions = getwords (annex "youtube-dl-options")
|
2014-12-17 03:22:46 +00:00
|
|
|
, annexAriaTorrentOptions = getwords (annex "aria-torrent-options")
|
2013-02-15 20:02:35 +00:00
|
|
|
, annexCrippledFileSystem = getbool (annex "crippledfilesystem") False
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
, annexLargeFiles = configurable Nothing $
|
|
|
|
|
fmap Just $ getmaybe (annex "largefiles")
|
2019-10-23 19:20:00 +00:00
|
|
|
, annexGitAddToAnnex = getbool (annex "gitaddtoannex") True
|
2016-01-28 18:04:32 +00:00
|
|
|
, annexAddSmallFiles = getbool (annex "addsmallfiles") True
|
2013-10-29 20:48:06 +00:00
|
|
|
, annexFsckNudge = getbool (annex "fscknudge") True
|
2013-11-22 20:04:20 +00:00
|
|
|
, annexAutoUpgrade = toAutoUpgrade $ getmaybe (annex "autoupgrade")
|
2014-01-23 03:10:51 +00:00
|
|
|
, annexExpireUnused = maybe Nothing Just . parseDuration
|
|
|
|
|
<$> getmaybe (annex "expireunused")
|
2014-01-24 16:58:52 +00:00
|
|
|
, annexSecureEraseCommand = getmaybe (annex "secure-erase-command")
|
2014-02-23 04:08:29 +00:00
|
|
|
, annexGenMetaData = getbool (annex "genmetadata") False
|
2014-03-01 04:31:17 +00:00
|
|
|
, annexListen = getmaybe (annex "listen")
|
2014-03-05 21:44:14 +00:00
|
|
|
, annexStartupScan = getbool (annex "startupscan") True
|
2014-09-05 17:44:09 +00:00
|
|
|
, annexHardLink = getbool (annex "hardlink") False
|
2015-12-27 19:59:59 +00:00
|
|
|
, annexThin = getbool (annex "thin") False
|
2015-01-27 21:38:06 +00:00
|
|
|
, annexDifferences = getDifferences r
|
2015-05-14 19:44:08 +00:00
|
|
|
, annexUsedRefSpec = either (const Nothing) Just . parseRefSpec
|
|
|
|
|
=<< getmaybe (annex "used-refspec")
|
Do verification of checksums of annex objects downloaded from remotes.
* When annex objects are received into git repositories, their checksums are
verified then too.
* To get the old, faster, behavior of not verifying checksums, set
annex.verify=false, or remote.<name>.annex-verify=false.
* setkey, rekey: These commands also now verify that the provided file
matches the key, unless annex.verify=false.
* reinject: Already verified content; this can now be disabled by
setting annex.verify=false.
recvkey and reinject already did verification, so removed now duplicate
code from them. fsck still does its own verification, which is ok since it
does not use getViaTmp, so verification doesn't happen twice when using fsck
--from.
2015-10-01 19:54:37 +00:00
|
|
|
, annexVerify = getbool (annex "verify") True
|
2015-11-12 21:47:31 +00:00
|
|
|
, annexPidLock = getbool (annex "pidlock") False
|
|
|
|
|
, annexPidLockTimeout = Seconds $ fromMaybe 300 $
|
|
|
|
|
getmayberead (annex "pidlocktimeout")
|
2019-12-20 19:01:34 +00:00
|
|
|
, annexAddUnlocked = configurable Nothing $
|
|
|
|
|
fmap Just $ getmaybe (annex "addunlocked")
|
annex.securehashesonly
Cryptographically secure hashes can be forced to be used in a repository,
by setting annex.securehashesonly. This does not prevent the git repository
from containing files with insecure hashes, but it does prevent the content
of such files from being pulled into .git/annex/objects from another
repository.
We want to make sure that at no point does git-annex accept content into
.git/annex/objects that is hashed with an insecure key. Here's how it
was done:
* .git/annex/objects/xx/yy/KEY/ is kept frozen, so nothing can be
written to it normally
* So every place that writes content must call, thawContent or modifyContent.
We can audit for these, and be sure we've considered all cases.
* The main functions are moveAnnex, and linkToAnnex; these were made to
check annex.securehashesonly, and are the main security boundary
for annex.securehashesonly.
* Most other calls to modifyContent deal with other files in the KEY
directory (inode cache etc). The other ones that mess with the content
are:
- Annex.Direct.toDirectGen, in which content already in the
annex directory is moved to the direct mode file, so not relevant.
- fix and lock, which don't add new content
- Command.ReKey.linkKey, which manually unlocks it to make a
copy.
* All other calls to thawContent appear safe.
Made moveAnnex return a Bool, so checked all callsites and made them
deal with a failure in appropriate ways.
linkToAnnex simply returns LinkAnnexFailed; all callsites already deal
with it failing in appropriate ways.
This commit was sponsored by Riku Voipio.
2017-02-27 17:01:32 +00:00
|
|
|
, annexSecureHashesOnly = getbool (annex "securehashesonly") False
|
2018-03-24 14:37:25 +00:00
|
|
|
, annexRetry = getmayberead (annex "retry")
|
|
|
|
|
, annexRetryDelay = Seconds
|
|
|
|
|
<$> getmayberead (annex "retrydelay")
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
, annexAllowedUrlSchemes = S.fromList $ map mkScheme $
|
2018-06-18 19:36:12 +00:00
|
|
|
maybe ["http", "https", "ftp"] words $
|
limit url downloads to whitelisted schemes
Security fix! Allowing any schemes, particularly file: and
possibly others like scp: allowed file exfiltration by anyone who had
write access to the git repository, since they could add an annexed file
using such an url, or using an url that redirected to such an url,
and wait for the victim to get it into their repository and send them a copy.
* Added annex.security.allowed-url-schemes setting, which defaults
to only allowing http and https URLs. Note especially that file:/
is no longer enabled by default.
* Removed annex.web-download-command, since its interface does not allow
supporting annex.security.allowed-url-schemes across redirects.
If you used this setting, you may want to instead use annex.web-options
to pass options to curl.
With annex.web-download-command removed, nearly all url accesses in
git-annex are made via Utility.Url via http-client or curl. http-client
only supports http and https, so no problem there.
(Disabling one and not the other is not implemented.)
Used curl --proto to limit the allowed url schemes.
Note that this will cause git annex fsck --from web to mark files using
a disallowed url scheme as not being present in the web. That seems
acceptable; fsck --from web also does that when a web server is not available.
youtube-dl already disabled file: itself (probably for similar
reasons). The scheme check was also added to youtube-dl urls for
completeness, although that check won't catch any redirects it might
follow. But youtube-dl goes off and does its own thing with other
protocols anyway, so that's fine.
Special remotes that support other domain-specific url schemes are not
affected by this change. In the bittorrent remote, aria2c can still
download magnet: links. The download of the .torrent file is
otherwise now limited by annex.security.allowed-url-schemes.
This does not address any external special remotes that might download
an url themselves. Current thinking is all external special remotes will
need to be audited for this problem, although many of them will use
http libraries that only support http and not curl's menagarie.
The related problem of accessing private localhost and LAN urls is not
addressed by this commit.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-06-15 20:52:24 +00:00
|
|
|
getmaybe (annex "security.allowed-url-schemes")
|
2019-05-30 16:43:40 +00:00
|
|
|
, annexAllowedIPAddresses = fromMaybe "" $
|
|
|
|
|
getmaybe (annex "security.allowed-ip-addresses")
|
|
|
|
|
<|>
|
|
|
|
|
getmaybe (annex "security.allowed-http-addresses") -- old name
|
2018-06-21 17:34:11 +00:00
|
|
|
, annexAllowUnverifiedDownloads = (== Just "ACKTHPPT") $
|
|
|
|
|
getmaybe (annex "security.allow-unverified-downloads")
|
2018-09-24 16:07:46 +00:00
|
|
|
, annexMaxExtensionLength = getmayberead (annex "maxextensionlength")
|
2019-05-10 17:24:31 +00:00
|
|
|
, annexJobs = fromMaybe NonConcurrent $
|
|
|
|
|
parseConcurrency =<< getmaybe (annex "jobs")
|
2018-12-04 18:16:56 +00:00
|
|
|
, annexCacheCreds = getbool (annex "cachecreds") True
|
2019-09-01 17:29:55 +00:00
|
|
|
, annexAutoUpgradeRepository = getbool (annex "autoupgraderepository") True
|
2019-11-11 22:20:35 +00:00
|
|
|
, annexCommitMode = if getbool (annex "allowsign") False
|
|
|
|
|
then ManualCommit
|
|
|
|
|
else AutomaticCommit
|
2015-09-09 22:06:49 +00:00
|
|
|
, coreSymlinks = getbool "core.symlinks" True
|
|
|
|
|
, coreSharedRepository = getSharedRepository r
|
2017-02-17 18:04:43 +00:00
|
|
|
, receiveDenyCurrentBranch = getDenyCurrentBranch r
|
2015-09-09 22:06:49 +00:00
|
|
|
, gcryptId = getmaybe "core.gcrypt-id"
|
|
|
|
|
, gpgCmd = mkGpgCmd (getmaybe "gpg.program")
|
2013-01-01 17:52:47 +00:00
|
|
|
}
|
|
|
|
|
where
|
2015-01-28 20:11:28 +00:00
|
|
|
getbool k d = fromMaybe d $ getmaybebool k
|
2019-12-20 19:01:34 +00:00
|
|
|
getmaybebool k = Git.Config.isTrueFalse' =<< getmaybe' k
|
2013-01-01 17:52:47 +00:00
|
|
|
getmayberead k = readish =<< getmaybe k
|
2019-12-05 18:36:43 +00:00
|
|
|
getmaybe = fmap fromConfigValue . getmaybe'
|
2019-11-27 20:54:11 +00:00
|
|
|
getmaybe' k = Git.Config.getMaybe k r
|
2019-12-05 18:36:43 +00:00
|
|
|
getlist k = map fromConfigValue $ Git.Config.getList k r
|
2013-01-27 13:33:19 +00:00
|
|
|
getwords k = fromMaybe [] $ words <$> getmaybe k
|
2013-01-01 17:52:47 +00:00
|
|
|
|
2017-02-03 17:40:14 +00:00
|
|
|
configurable d Nothing = DefaultConfig d
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
configurable _ (Just v) = case configsource of
|
|
|
|
|
FromGitConfig -> HasGitConfig v
|
|
|
|
|
FromGlobalConfig -> HasGlobalConfig v
|
2017-02-03 17:40:14 +00:00
|
|
|
|
2019-12-02 14:57:09 +00:00
|
|
|
annex k = ConfigKey $ "annex." <> k
|
2013-01-01 17:52:47 +00:00
|
|
|
|
|
|
|
|
onemegabyte = 1000000
|
|
|
|
|
|
2017-02-03 17:40:14 +00:00
|
|
|
{- Merge a GitConfig that comes from git-config with one containing
|
|
|
|
|
- repository-global defaults. -}
|
|
|
|
|
mergeGitConfig :: GitConfig -> GitConfig -> GitConfig
|
|
|
|
|
mergeGitConfig gitconfig repoglobals = gitconfig
|
|
|
|
|
{ annexAutoCommit = merge annexAutoCommit
|
2017-02-03 18:31:17 +00:00
|
|
|
, annexSyncContent = merge annexSyncContent
|
2019-12-20 14:55:23 +00:00
|
|
|
, annexResolveMerge = merge annexResolveMerge
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
, annexLargeFiles = merge annexLargeFiles
|
2019-12-20 19:01:34 +00:00
|
|
|
, annexAddUnlocked = merge annexAddUnlocked
|
2017-02-03 17:40:14 +00:00
|
|
|
}
|
|
|
|
|
where
|
|
|
|
|
merge f = case f gitconfig of
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
HasGitConfig v -> HasGitConfig v
|
2017-02-03 17:40:14 +00:00
|
|
|
DefaultConfig d -> case f repoglobals of
|
git-annex config annex.largefiles
annex.largefiles can be configured by git-annex config, to more easily set
a default that will also be used by clones, without needing to shoehorn the
expression into the gitattributes file. The git config and gitattributes
override that.
Whenever something is added to git-annex config, we have to consider what
happens if a user puts a purposfully bad value in there. Or, if a new
git-annex adds some new value that an old git-annex can't parse.
In this case, a global annex.largefiles that can't be parsed currently
makes an error be thrown. That might not be ideal, but the gitattribute
behaves the same, and is almost equally repo-global.
Performance notes:
git-annex add and addurl construct a matcher once
and uses it for every file, so the added time penalty for reading the global
config log is minor. If the gitattributes annex.largefiles were deprecated,
git-annex add would get around 2% faster (excluding hashing), because
looking that up for each file is not fast. So this new way of setting
it is progress toward speeding up add.
git-annex smudge does need to load the log every time. As well as checking
the git attribute. Not ideal. Setting annex.gitaddtoannex=false avoids
both overheads.
2019-12-20 16:12:31 +00:00
|
|
|
HasGlobalConfig v -> HasGlobalConfig v
|
|
|
|
|
_ -> HasGitConfig d
|
|
|
|
|
HasGlobalConfig v -> HasGlobalConfig v
|
2017-02-03 17:40:14 +00:00
|
|
|
|
2013-01-01 17:52:47 +00:00
|
|
|
{- Per-remote git-annex settings. Each setting corresponds to a git-config
|
|
|
|
|
- key such as <remote>.annex-foo, or if that is not set, a default from
|
removal of the rest of remoteGitConfig
In keyUrls, the GitConfig is used only by annexLocations
to support configured Differences. Since such configurations affect all
clones of a repository, the local repo's GitConfig must have the same
information as the remote's GitConfig would have. So, used getGitConfig
to get the local GitConfig, which is cached and so available cheaply.
That actually fixed a bug noone had ever noticed: keyUrls is
used for remotes accessed over http. The full git config of such a
remote is normally not available, so the remoteGitConfig that keyUrls
used would not have the necessary information in it.
In copyFromRemoteCheap', it uses gitAnnexLocation,
which does need the GitConfig of the remote repo itself in order to
check if it's crippled, supports symlinks, etc. So, made the
State include that GitConfig, cached. The use of gitAnnexLocation is
within a (not $ Git.repoIsUrl repo) guard, so it's local, and so
its git config will always be read and available.
(Note that gitAnnexLocation in turn calls annexLocations, so the
Differences config it uses in this case comes from the remote repo's
GitConfig and not from the local repo's GitConfig. As explained above
this is ok since they must have the same value.)
Not very happy with this mess of different GitConfigs not type-safe and
some read only sometimes etc. Very hairy. Think I got it this change
right. Test suite passes..
This commit was sponsored by Ethan Aubin.
2018-06-05 18:23:34 +00:00
|
|
|
- annex.foo.
|
|
|
|
|
-
|
|
|
|
|
- Note that this is from the perspective of the local repository,
|
|
|
|
|
- it is not influenced in any way by the contents of the remote
|
|
|
|
|
- repository's git config.
|
|
|
|
|
-}
|
2013-01-01 17:52:47 +00:00
|
|
|
data RemoteGitConfig = RemoteGitConfig
|
2017-08-17 18:04:29 +00:00
|
|
|
{ remoteAnnexCost :: DynamicConfig (Maybe Cost)
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexIgnore :: DynamicConfig Bool
|
|
|
|
|
, remoteAnnexSync :: DynamicConfig Bool
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
The former can be useful to make remotes that don't get fully synced with
local changes, which comes up in a lot of situations.
The latter was mostly added for symmetry, but could be useful (though less
likely to be).
Implementing `remote.<name>.annex-pull` was a bit tricky, as there's no one
place where git-annex pulls/fetches from remotes. I audited all
instances of "fetch" and "pull". A few cases were left not checking this
config:
* Git.Repair can try to pull missing refs from a remote, and if the local
repo is corrupted, that seems a reasonable thing to do even though
the config would normally prevent it.
* Assistant.WebApp.Gpg and Remote.Gcrypt and Remote.Git do fetches
as part of the setup process of a remote. The config would probably not
be set then, and having the setup fail seems worse than honoring it if it
is already set.
I have not prevented all the code that does a "merge" from merging branches
from remotes with remote.<name>.annex-pull=false. That could perhaps
be done, but it would need a way to map from branch name to remote name,
and the way refspecs work makes that hard to get really correct. So if the
user fetches manually, the git-annex branch will get merged, for example.
Anther way of looking at/justifying this is that the setting is called
"annex-pull", not "annex-merge".
This commit was supported by the NSF-funded DataLad project.
2017-04-05 17:04:02 +00:00
|
|
|
, remoteAnnexPull :: Bool
|
|
|
|
|
, remoteAnnexPush :: Bool
|
2014-01-02 17:12:32 +00:00
|
|
|
, remoteAnnexReadOnly :: Bool
|
Do verification of checksums of annex objects downloaded from remotes.
* When annex objects are received into git repositories, their checksums are
verified then too.
* To get the old, faster, behavior of not verifying checksums, set
annex.verify=false, or remote.<name>.annex-verify=false.
* setkey, rekey: These commands also now verify that the provided file
matches the key, unless annex.verify=false.
* reinject: Already verified content; this can now be disabled by
setting annex.verify=false.
recvkey and reinject already did verification, so removed now duplicate
code from them. fsck still does its own verification, which is ok since it
does not use getViaTmp, so verification doesn't happen twice when using fsck
--from.
2015-10-01 19:54:37 +00:00
|
|
|
, remoteAnnexVerify :: Bool
|
2018-01-10 18:21:18 +00:00
|
|
|
, remoteAnnexCheckUUID :: Bool
|
2019-02-23 19:48:25 +00:00
|
|
|
, remoteAnnexTrackingBranch :: Maybe Git.Ref
|
2013-01-01 17:52:47 +00:00
|
|
|
, remoteAnnexTrustLevel :: Maybe String
|
|
|
|
|
, remoteAnnexStartCommand :: Maybe String
|
|
|
|
|
, remoteAnnexStopCommand :: Maybe String
|
2014-01-13 18:41:10 +00:00
|
|
|
, remoteAnnexAvailability :: Maybe Availability
|
2018-08-01 18:22:52 +00:00
|
|
|
, remoteAnnexSpeculatePresent :: Bool
|
2014-01-26 17:03:25 +00:00
|
|
|
, remoteAnnexBare :: Maybe Bool
|
2018-03-24 14:37:25 +00:00
|
|
|
, remoteAnnexRetry :: Maybe Integer
|
|
|
|
|
, remoteAnnexRetryDelay :: Maybe Seconds
|
2018-09-25 19:32:50 +00:00
|
|
|
, remoteAnnexAllowUnverifiedDownloads :: Bool
|
2019-10-10 16:12:22 +00:00
|
|
|
, remoteAnnexConfigUUID :: Maybe UUID
|
2013-01-01 17:52:47 +00:00
|
|
|
|
2013-04-04 19:46:33 +00:00
|
|
|
{- These settings are specific to particular types of remotes
|
|
|
|
|
- including special remotes. -}
|
2014-05-16 11:34:43 +00:00
|
|
|
, remoteAnnexShell :: Maybe String
|
2013-01-01 17:52:47 +00:00
|
|
|
, remoteAnnexSshOptions :: [String]
|
|
|
|
|
, remoteAnnexRsyncOptions :: [String]
|
2014-02-02 20:06:34 +00:00
|
|
|
, remoteAnnexRsyncUploadOptions :: [String]
|
|
|
|
|
, remoteAnnexRsyncDownloadOptions :: [String]
|
2013-04-13 22:10:49 +00:00
|
|
|
, remoteAnnexRsyncTransport :: [String]
|
2013-03-11 01:33:13 +00:00
|
|
|
, remoteAnnexGnupgOptions :: [String]
|
2016-05-10 17:03:56 +00:00
|
|
|
, remoteAnnexGnupgDecryptOptions :: [String]
|
2013-01-01 17:52:47 +00:00
|
|
|
, remoteAnnexRsyncUrl :: Maybe String
|
|
|
|
|
, remoteAnnexBupRepo :: Maybe String
|
2014-01-08 20:14:37 +00:00
|
|
|
, remoteAnnexTahoe :: Maybe FilePath
|
2013-01-01 17:52:47 +00:00
|
|
|
, remoteAnnexBupSplitOptions :: [String]
|
|
|
|
|
, remoteAnnexDirectory :: Maybe FilePath
|
2018-03-27 16:41:57 +00:00
|
|
|
, remoteAnnexAndroidDirectory :: Maybe FilePath
|
|
|
|
|
, remoteAnnexAndroidSerial :: Maybe String
|
2013-09-24 21:25:47 +00:00
|
|
|
, remoteAnnexGCrypt :: Maybe String
|
2019-08-01 19:11:45 +00:00
|
|
|
, remoteAnnexGitLFS :: Bool
|
2014-05-15 18:44:00 +00:00
|
|
|
, remoteAnnexDdarRepo :: Maybe String
|
2013-01-01 17:52:47 +00:00
|
|
|
, remoteAnnexHookType :: Maybe String
|
external special remotes mostly implemented (untested)
This has not been tested at all. It compiles!
The only known missing things are support for encryption, and for get/set
of special remote configuration, and of key state. (The latter needs
separate work to add a new per-key log file to store that state.)
Only thing I don't much like is that initremote needs to be passed both
type=external and externaltype=foo. It would be better to have just
type=foo
Most of this is quite straightforward code, that largely wrote itself given
the types. The only tricky parts were:
* Need to lock the remote when using it to eg make a request, because
in theory git-annex could have multiple threads that each try to use
a remote at the same time. I don't think that git-annex ever does
that currently, but better safe than sorry.
* Rather than starting up every external special remote program when
git-annex starts, they are started only on demand, when first used.
This will avoid slowdown, especially when running fast git-annex query
commands. Once started, they keep running until git-annex stops, currently,
which may not be ideal, but it's hard to know a better time to stop them.
* Bit of a chicken and egg problem with caching the cost of the remote,
because setting annex-cost in the git config needs the remote to already
be set up. Managed to finesse that.
This commit was sponsored by Lukas Anzinger.
2013-12-26 22:23:13 +00:00
|
|
|
, remoteAnnexExternalType :: Maybe String
|
2013-01-01 17:52:47 +00:00
|
|
|
}
|
|
|
|
|
|
removal of the rest of remoteGitConfig
In keyUrls, the GitConfig is used only by annexLocations
to support configured Differences. Since such configurations affect all
clones of a repository, the local repo's GitConfig must have the same
information as the remote's GitConfig would have. So, used getGitConfig
to get the local GitConfig, which is cached and so available cheaply.
That actually fixed a bug noone had ever noticed: keyUrls is
used for remotes accessed over http. The full git config of such a
remote is normally not available, so the remoteGitConfig that keyUrls
used would not have the necessary information in it.
In copyFromRemoteCheap', it uses gitAnnexLocation,
which does need the GitConfig of the remote repo itself in order to
check if it's crippled, supports symlinks, etc. So, made the
State include that GitConfig, cached. The use of gitAnnexLocation is
within a (not $ Git.repoIsUrl repo) guard, so it's local, and so
its git config will always be read and available.
(Note that gitAnnexLocation in turn calls annexLocations, so the
Differences config it uses in this case comes from the remote repo's
GitConfig and not from the local repo's GitConfig. As explained above
this is ok since they must have the same value.)
Not very happy with this mess of different GitConfigs not type-safe and
some read only sometimes etc. Very hairy. Think I got it this change
right. Test suite passes..
This commit was sponsored by Ethan Aubin.
2018-06-05 18:23:34 +00:00
|
|
|
{- The Git.Repo is the local repository, which has the remote with the
|
|
|
|
|
- given RemoteName. -}
|
|
|
|
|
extractRemoteGitConfig :: Git.Repo -> RemoteName -> STM RemoteGitConfig
|
2017-08-17 16:26:14 +00:00
|
|
|
extractRemoteGitConfig r remotename = do
|
2017-08-17 18:04:29 +00:00
|
|
|
annexcost <- mkDynamicConfig readCommandRunner
|
|
|
|
|
(notempty $ getmaybe "cost-command")
|
|
|
|
|
(getmayberead "cost")
|
2017-08-17 16:26:14 +00:00
|
|
|
annexignore <- mkDynamicConfig unsuccessfullCommandRunner
|
|
|
|
|
(notempty $ getmaybe "ignore-command")
|
|
|
|
|
(getbool "ignore" False)
|
|
|
|
|
annexsync <- mkDynamicConfig successfullCommandRunner
|
|
|
|
|
(notempty $ getmaybe "sync-command")
|
|
|
|
|
(getbool "sync" True)
|
|
|
|
|
return $ RemoteGitConfig
|
2017-08-17 18:04:29 +00:00
|
|
|
{ remoteAnnexCost = annexcost
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexIgnore = annexignore
|
|
|
|
|
, remoteAnnexSync = annexsync
|
|
|
|
|
, remoteAnnexPull = getbool "pull" True
|
|
|
|
|
, remoteAnnexPush = getbool "push" True
|
|
|
|
|
, remoteAnnexReadOnly = getbool "readonly" False
|
2018-01-10 18:21:18 +00:00
|
|
|
, remoteAnnexCheckUUID = getbool "checkuuid" True
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexVerify = getbool "verify" True
|
2019-02-23 19:48:25 +00:00
|
|
|
, remoteAnnexTrackingBranch = Git.Ref <$>
|
2019-03-11 17:56:59 +00:00
|
|
|
( notempty (getmaybe "tracking-branch")
|
2019-02-23 19:48:25 +00:00
|
|
|
<|> notempty (getmaybe "export-tracking") -- old name
|
|
|
|
|
)
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexTrustLevel = notempty $ getmaybe "trustlevel"
|
|
|
|
|
, remoteAnnexStartCommand = notempty $ getmaybe "start-command"
|
|
|
|
|
, remoteAnnexStopCommand = notempty $ getmaybe "stop-command"
|
|
|
|
|
, remoteAnnexAvailability = getmayberead "availability"
|
2018-08-01 18:22:52 +00:00
|
|
|
, remoteAnnexSpeculatePresent = getbool "speculate-present" False
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexBare = getmaybebool "bare"
|
2018-03-24 14:37:25 +00:00
|
|
|
, remoteAnnexRetry = getmayberead "retry"
|
|
|
|
|
, remoteAnnexRetryDelay = Seconds
|
|
|
|
|
<$> getmayberead "retrydelay"
|
2018-09-25 19:32:50 +00:00
|
|
|
, remoteAnnexAllowUnverifiedDownloads = (== Just "ACKTHPPT") $
|
|
|
|
|
getmaybe ("security-allow-unverified-downloads")
|
2019-10-10 16:12:22 +00:00
|
|
|
, remoteAnnexConfigUUID = toUUID <$> getmaybe "config-uuid"
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexShell = getmaybe "shell"
|
|
|
|
|
, remoteAnnexSshOptions = getoptions "ssh-options"
|
|
|
|
|
, remoteAnnexRsyncOptions = getoptions "rsync-options"
|
|
|
|
|
, remoteAnnexRsyncDownloadOptions = getoptions "rsync-download-options"
|
|
|
|
|
, remoteAnnexRsyncUploadOptions = getoptions "rsync-upload-options"
|
|
|
|
|
, remoteAnnexRsyncTransport = getoptions "rsync-transport"
|
|
|
|
|
, remoteAnnexGnupgOptions = getoptions "gnupg-options"
|
|
|
|
|
, remoteAnnexGnupgDecryptOptions = getoptions "gnupg-decrypt-options"
|
|
|
|
|
, remoteAnnexRsyncUrl = notempty $ getmaybe "rsyncurl"
|
|
|
|
|
, remoteAnnexBupRepo = getmaybe "buprepo"
|
|
|
|
|
, remoteAnnexTahoe = getmaybe "tahoe"
|
|
|
|
|
, remoteAnnexBupSplitOptions = getoptions "bup-split-options"
|
|
|
|
|
, remoteAnnexDirectory = notempty $ getmaybe "directory"
|
2018-03-27 16:41:57 +00:00
|
|
|
, remoteAnnexAndroidDirectory = notempty $ getmaybe "androiddirectory"
|
|
|
|
|
, remoteAnnexAndroidSerial = notempty $ getmaybe "androidserial"
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexGCrypt = notempty $ getmaybe "gcrypt"
|
2019-08-01 19:11:45 +00:00
|
|
|
, remoteAnnexGitLFS = getbool "git-lfs" False
|
2017-08-17 16:26:14 +00:00
|
|
|
, remoteAnnexDdarRepo = getmaybe "ddarrepo"
|
|
|
|
|
, remoteAnnexHookType = notempty $ getmaybe "hooktype"
|
|
|
|
|
, remoteAnnexExternalType = notempty $ getmaybe "externaltype"
|
|
|
|
|
}
|
2013-01-01 17:52:47 +00:00
|
|
|
where
|
2015-01-28 20:11:28 +00:00
|
|
|
getbool k d = fromMaybe d $ getmaybebool k
|
2019-12-20 19:01:34 +00:00
|
|
|
getmaybebool k = Git.Config.isTrueFalse' =<< getmaybe' k
|
2013-01-01 17:52:47 +00:00
|
|
|
getmayberead k = readish =<< getmaybe k
|
2019-12-05 18:36:43 +00:00
|
|
|
getmaybe = fmap fromConfigValue . getmaybe'
|
2019-11-27 20:54:11 +00:00
|
|
|
getmaybe' k = mplus (Git.Config.getMaybe (key k) r)
|
2013-04-03 07:52:41 +00:00
|
|
|
(Git.Config.getMaybe (remotekey k) r)
|
2013-01-01 17:52:47 +00:00
|
|
|
getoptions k = fromMaybe [] $ words <$> getmaybe k
|
|
|
|
|
|
2019-12-02 14:57:09 +00:00
|
|
|
key k = ConfigKey $ "annex." <> k
|
|
|
|
|
remotekey k = ConfigKey $
|
|
|
|
|
"remote." <> encodeBS' remotename <> ".annex-" <> k
|
2013-01-01 17:52:47 +00:00
|
|
|
|
|
|
|
|
notempty :: Maybe String -> Maybe String
|
|
|
|
|
notempty Nothing = Nothing
|
|
|
|
|
notempty (Just "") = Nothing
|
|
|
|
|
notempty (Just s) = Just s
|
|
|
|
|
|
2017-08-17 16:26:14 +00:00
|
|
|
dummyRemoteGitConfig :: IO RemoteGitConfig
|
|
|
|
|
dummyRemoteGitConfig = atomically $
|
|
|
|
|
extractRemoteGitConfig Git.Construct.fromUnknown "dummy"
|