2012-11-14 23:32:27 +00:00
|
|
|
{- Credentials storage
|
|
|
|
-
|
2020-01-14 17:18:15 +00:00
|
|
|
- Copyright 2012-2020 Joey Hess <id@joeyh.name>
|
2012-11-14 23:32:27 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2012-11-14 23:32:27 +00:00
|
|
|
-}
|
|
|
|
|
2014-02-11 18:06:50 +00:00
|
|
|
module Creds (
|
|
|
|
module Types.Creds,
|
|
|
|
CredPairStorage(..),
|
|
|
|
setRemoteCredPair,
|
2020-01-15 17:01:22 +00:00
|
|
|
setRemoteCredPair',
|
2014-02-11 18:06:50 +00:00
|
|
|
getRemoteCredPair,
|
2015-06-05 20:23:35 +00:00
|
|
|
getRemoteCredPairFor,
|
S3: Improve diagnostics when a remote is configured with exporttree and versioning, but no S3 version id has been recorded for a key.
When public access is used for the remote, it complained that the user
needed to set creds to use it, which was just wrong.
When creds were being used, it fell back from trying to use the version ID
to just accessing the key in the bucket, which was ok for non-export
remotes, but wrong for buckets.
In both cases, display a hopefully useful warning.
This should only come up when an existing S3 remote has been exported
to, and then later versioning was enabled.
Note that it would perhaps be possible to fall back from trying to use
retrieveKeyFile when it fails and instead use retrieveKeyFileFromExport,
which may work when S3 version ID is missing. But there are problems
with that approach; how to tell when retrieveKeyFile has failed due to this
rather than a network problem etc? Anyway, that approach would only work
until the file in the export got overwritten, and then it would no
longer be accessible. And with versioning enabled, the user wants old
versions of objects to remain accessible, so it seems better to warn
about the problem as soon as possible, so they can go back and add S3
version IDs.
This work is supported by the NIH-funded NICEMAN (ReproNim TR&D3) project.
2018-12-06 17:43:18 +00:00
|
|
|
missingCredPairFor,
|
2014-02-11 18:06:50 +00:00
|
|
|
getEnvCredPair,
|
2018-12-04 18:02:37 +00:00
|
|
|
writeCreds,
|
|
|
|
readCreds,
|
|
|
|
credsFile,
|
2014-04-20 16:46:33 +00:00
|
|
|
removeCreds,
|
2014-10-21 19:09:40 +00:00
|
|
|
includeCredsInfo,
|
2014-02-11 18:06:50 +00:00
|
|
|
) where
|
2012-11-14 23:32:27 +00:00
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2015-09-09 22:06:49 +00:00
|
|
|
import qualified Annex
|
2014-02-11 18:06:50 +00:00
|
|
|
import Types.Creds
|
2020-01-13 16:35:39 +00:00
|
|
|
import Types.RemoteConfig
|
2020-01-14 16:35:08 +00:00
|
|
|
import Annex.SpecialRemote.Config
|
2012-11-14 23:32:27 +00:00
|
|
|
import Annex.Perms
|
|
|
|
import Utility.FileMode
|
|
|
|
import Crypto
|
2019-10-10 19:31:10 +00:00
|
|
|
import Types.Remote (RemoteConfig, RemoteConfigField)
|
2020-01-10 18:10:20 +00:00
|
|
|
import Types.ProposedAccepted
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
import Remote.Helper.Encryptable (remoteCipher, remoteCipher', embedCreds, EncryptionIsSetup, extractCipher)
|
2014-02-11 18:06:50 +00:00
|
|
|
import Utility.Env (getEnv)
|
2012-11-14 23:32:27 +00:00
|
|
|
|
|
|
|
import qualified Data.ByteString.Lazy.Char8 as L
|
2020-06-16 21:03:19 +00:00
|
|
|
import qualified Data.ByteString.Char8 as S
|
2012-11-14 23:32:27 +00:00
|
|
|
import qualified Data.Map as M
|
|
|
|
import Utility.Base64
|
|
|
|
|
2018-12-04 17:37:43 +00:00
|
|
|
{- A CredPair can be stored in a file, or in the environment, or
|
2012-11-14 23:32:27 +00:00
|
|
|
- in a remote's configuration. -}
|
|
|
|
data CredPairStorage = CredPairStorage
|
|
|
|
{ credPairFile :: FilePath
|
|
|
|
, credPairEnvironment :: (String, String)
|
2019-10-10 19:31:10 +00:00
|
|
|
, credPairRemoteField :: RemoteConfigField
|
2012-11-14 23:32:27 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 21:32:58 +00:00
|
|
|
{- Stores creds in a remote's configuration, if the remote allows
|
2014-10-22 18:28:25 +00:00
|
|
|
- that. Also caches them locally.
|
|
|
|
-
|
|
|
|
- The creds are found from the CredPairStorage storage if not provided,
|
|
|
|
- so may be provided by an environment variable etc.
|
glacier, S3: Fix bug that caused embedded creds to not be encypted using the remote's key.
encryptionSetup must be called before setRemoteCredPair. Otherwise,
the RemoteConfig doesn't have the cipher in it, and so no cipher is used to
encrypt the embedded creds.
This is a security fix for non-shared encryption methods!
For encryption=shared, there's no security problem, just an
inconsistentency in whether the embedded creds are encrypted.
This is very important to get right, so used some types to help ensure that
setRemoteCredPair is only run after encryptionSetup. Note that the external
special remote bypasses the type safety, since creds can be set after the
initial remote config, if the external special remote program requests it.
Also note that IA remotes never use encryption, so encryptionSetup is not
run for them at all, and again the type safety is bypassed.
This leaves two open questions:
1. What to do about S3 and glacier remotes that were set up
using encryption=pubkey/hybrid with embedcreds?
Such a git repo has a security hole embedded in it, and this needs to be
communicated to the user. Is the changelog enough?
2. enableremote won't work in such a repo, because git-annex will
try to decrypt the embedded creds, which are not encrypted, so fails.
This needs to be dealt with, especially for ecryption=shared repos,
which are not really broken, just inconsistently configured.
Noticing that problem for encryption=shared is what led to commit
fbdeeeed5fa276d94be587c8916d725eddcaf546, which tried to
fix the problem by not decrypting the embedded creds.
This commit was sponsored by Josh Taylor.
2014-09-18 21:07:17 +00:00
|
|
|
-
|
|
|
|
- The remote's configuration should have already had a cipher stored in it
|
|
|
|
- if that's going to be done, so that the creds can be encrypted using the
|
2019-04-27 18:08:11 +00:00
|
|
|
- cipher. The EncryptionIsSetup is witness to that being the case.
|
glacier, S3: Fix bug that caused embedded creds to not be encypted using the remote's key.
encryptionSetup must be called before setRemoteCredPair. Otherwise,
the RemoteConfig doesn't have the cipher in it, and so no cipher is used to
encrypt the embedded creds.
This is a security fix for non-shared encryption methods!
For encryption=shared, there's no security problem, just an
inconsistentency in whether the embedded creds are encrypted.
This is very important to get right, so used some types to help ensure that
setRemoteCredPair is only run after encryptionSetup. Note that the external
special remote bypasses the type safety, since creds can be set after the
initial remote config, if the external special remote program requests it.
Also note that IA remotes never use encryption, so encryptionSetup is not
run for them at all, and again the type safety is bypassed.
This leaves two open questions:
1. What to do about S3 and glacier remotes that were set up
using encryption=pubkey/hybrid with embedcreds?
Such a git repo has a security hole embedded in it, and this needs to be
communicated to the user. Is the changelog enough?
2. enableremote won't work in such a repo, because git-annex will
try to decrypt the embedded creds, which are not encrypted, so fails.
This needs to be dealt with, especially for ecryption=shared repos,
which are not really broken, just inconsistently configured.
Noticing that problem for encryption=shared is what led to commit
fbdeeeed5fa276d94be587c8916d725eddcaf546, which tried to
fix the problem by not decrypting the embedded creds.
This commit was sponsored by Josh Taylor.
2014-09-18 21:07:17 +00:00
|
|
|
-}
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
setRemoteCredPair :: EncryptionIsSetup -> ParsedRemoteConfig -> RemoteGitConfig -> CredPairStorage -> Maybe CredPair -> Annex RemoteConfig
|
|
|
|
setRemoteCredPair encsetup pc = setRemoteCredPair' id (const pc) encsetup (unparsedRemoteConfig pc)
|
2020-01-15 17:01:22 +00:00
|
|
|
|
|
|
|
setRemoteCredPair'
|
|
|
|
:: (ProposedAccepted String -> a)
|
|
|
|
-> (M.Map RemoteConfigField a -> ParsedRemoteConfig)
|
|
|
|
-> EncryptionIsSetup
|
|
|
|
-> M.Map RemoteConfigField a
|
|
|
|
-> RemoteGitConfig
|
|
|
|
-> CredPairStorage
|
|
|
|
-> Maybe CredPair
|
|
|
|
-> Annex (M.Map RemoteConfigField a)
|
|
|
|
setRemoteCredPair' mkval parseconfig encsetup c gc storage mcreds = case mcreds of
|
|
|
|
Nothing -> maybe (return c) (setRemoteCredPair' mkval parseconfig encsetup c gc storage . Just)
|
2020-01-13 16:35:39 +00:00
|
|
|
=<< getRemoteCredPair pc gc storage
|
2016-05-23 21:03:20 +00:00
|
|
|
Just creds
|
2020-01-13 16:35:39 +00:00
|
|
|
| embedCreds pc -> do
|
2019-10-10 19:31:10 +00:00
|
|
|
let key = credPairRemoteField storage
|
2020-01-13 16:35:39 +00:00
|
|
|
localcache creds
|
|
|
|
storeconfig creds key =<< remoteCipher pc gc
|
|
|
|
| otherwise -> do
|
|
|
|
localcache creds
|
|
|
|
return c
|
2013-12-27 20:01:43 +00:00
|
|
|
where
|
2020-01-13 16:35:39 +00:00
|
|
|
localcache creds = writeCacheCredPair creds storage
|
2012-11-19 21:32:58 +00:00
|
|
|
|
2016-05-23 21:03:20 +00:00
|
|
|
storeconfig creds key (Just cipher) = do
|
2015-09-09 22:06:49 +00:00
|
|
|
cmd <- gpgCmd <$> Annex.getGitConfig
|
2020-01-13 16:35:39 +00:00
|
|
|
s <- liftIO $ encrypt cmd (pc, gc) cipher
|
2012-11-19 21:32:58 +00:00
|
|
|
(feedBytes $ L.pack $ encodeCredPair creds)
|
2020-06-16 21:03:19 +00:00
|
|
|
(readBytesStrictly $ return . S.unpack)
|
2020-01-15 17:01:22 +00:00
|
|
|
return $ M.insert key (mkval (Accepted (toB64 s))) c
|
2016-05-23 21:03:20 +00:00
|
|
|
storeconfig creds key Nothing =
|
2020-01-15 17:01:22 +00:00
|
|
|
return $ M.insert key (mkval (Accepted (toB64 $ encodeCredPair creds))) c
|
2020-01-13 16:35:39 +00:00
|
|
|
|
2020-01-15 17:01:22 +00:00
|
|
|
pc = parseconfig c
|
2012-11-19 21:32:58 +00:00
|
|
|
|
2012-11-14 23:32:27 +00:00
|
|
|
{- Gets a remote's credpair, from the environment if set, otherwise
|
2012-11-19 21:32:58 +00:00
|
|
|
- from the cache in gitAnnexCredsDir, or failing that, from the
|
2012-11-14 23:32:27 +00:00
|
|
|
- value in RemoteConfig. -}
|
2020-01-13 16:35:39 +00:00
|
|
|
getRemoteCredPair :: ParsedRemoteConfig -> RemoteGitConfig -> CredPairStorage -> Annex (Maybe CredPair)
|
2016-05-23 21:03:20 +00:00
|
|
|
getRemoteCredPair c gc storage = maybe fromcache (return . Just) =<< fromenv
|
2012-11-14 23:32:27 +00:00
|
|
|
where
|
|
|
|
fromenv = liftIO $ getEnvCredPair storage
|
|
|
|
fromcache = maybe fromconfig (return . Just) =<< readCacheCredPair storage
|
2018-12-04 17:37:43 +00:00
|
|
|
fromconfig = do
|
2019-10-10 19:31:10 +00:00
|
|
|
let key = credPairRemoteField storage
|
2018-12-04 17:37:43 +00:00
|
|
|
mcipher <- remoteCipher' c gc
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
case (getRemoteConfigValue key c, mcipher) of
|
2018-12-04 17:37:43 +00:00
|
|
|
(Nothing, _) -> return Nothing
|
|
|
|
(Just enccreds, Just (cipher, storablecipher)) ->
|
|
|
|
fromenccreds enccreds cipher storablecipher
|
|
|
|
(Just bcreds, Nothing) ->
|
|
|
|
fromcreds $ fromB64 bcreds
|
2014-09-18 21:58:03 +00:00
|
|
|
fromenccreds enccreds cipher storablecipher = do
|
2015-09-09 22:06:49 +00:00
|
|
|
cmd <- gpgCmd <$> Annex.getGitConfig
|
2016-05-23 21:03:20 +00:00
|
|
|
mcreds <- liftIO $ catchMaybeIO $ decrypt cmd (c, gc) cipher
|
2014-09-18 21:58:03 +00:00
|
|
|
(feedBytes $ L.pack $ fromB64 enccreds)
|
2020-06-16 21:03:19 +00:00
|
|
|
(readBytesStrictly $ return . S.unpack)
|
2014-09-18 21:58:03 +00:00
|
|
|
case mcreds of
|
|
|
|
Just creds -> fromcreds creds
|
|
|
|
Nothing -> do
|
|
|
|
-- Work around un-encrypted creds storage
|
|
|
|
-- bug in old S3 and glacier remotes.
|
|
|
|
-- Not a problem for shared cipher.
|
|
|
|
case storablecipher of
|
|
|
|
SharedCipher {} -> showLongNote "gpg error above was caused by an old git-annex bug in credentials storage. Working around it.."
|
2016-11-16 01:29:54 +00:00
|
|
|
_ -> giveup "*** Insecure credentials storage detected for this remote! See https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
|
2014-09-18 21:58:03 +00:00
|
|
|
fromcreds $ fromB64 enccreds
|
2012-11-19 21:32:58 +00:00
|
|
|
fromcreds creds = case decodeCredPair creds of
|
|
|
|
Just credpair -> do
|
|
|
|
writeCacheCredPair credpair storage
|
2014-09-18 21:58:03 +00:00
|
|
|
|
2012-11-19 21:32:58 +00:00
|
|
|
return $ Just credpair
|
2013-04-03 07:52:41 +00:00
|
|
|
_ -> error "bad creds"
|
2012-11-14 23:32:27 +00:00
|
|
|
|
2020-01-13 16:35:39 +00:00
|
|
|
getRemoteCredPairFor :: String -> ParsedRemoteConfig -> RemoteGitConfig -> CredPairStorage -> Annex (Maybe CredPair)
|
2016-05-23 21:03:20 +00:00
|
|
|
getRemoteCredPairFor this c gc storage = go =<< getRemoteCredPair c gc storage
|
2015-06-05 20:23:35 +00:00
|
|
|
where
|
|
|
|
go Nothing = do
|
S3: Improve diagnostics when a remote is configured with exporttree and versioning, but no S3 version id has been recorded for a key.
When public access is used for the remote, it complained that the user
needed to set creds to use it, which was just wrong.
When creds were being used, it fell back from trying to use the version ID
to just accessing the key in the bucket, which was ok for non-export
remotes, but wrong for buckets.
In both cases, display a hopefully useful warning.
This should only come up when an existing S3 remote has been exported
to, and then later versioning was enabled.
Note that it would perhaps be possible to fall back from trying to use
retrieveKeyFile when it fails and instead use retrieveKeyFileFromExport,
which may work when S3 version ID is missing. But there are problems
with that approach; how to tell when retrieveKeyFile has failed due to this
rather than a network problem etc? Anyway, that approach would only work
until the file in the export got overwritten, and then it would no
longer be accessible. And with versioning enabled, the user wants old
versions of objects to remain accessible, so it seems better to warn
about the problem as soon as possible, so they can go back and add S3
version IDs.
This work is supported by the NIH-funded NICEMAN (ReproNim TR&D3) project.
2018-12-06 17:43:18 +00:00
|
|
|
warning $ missingCredPairFor this storage
|
2015-06-05 20:23:35 +00:00
|
|
|
return Nothing
|
|
|
|
go (Just credpair) = return $ Just credpair
|
|
|
|
|
S3: Improve diagnostics when a remote is configured with exporttree and versioning, but no S3 version id has been recorded for a key.
When public access is used for the remote, it complained that the user
needed to set creds to use it, which was just wrong.
When creds were being used, it fell back from trying to use the version ID
to just accessing the key in the bucket, which was ok for non-export
remotes, but wrong for buckets.
In both cases, display a hopefully useful warning.
This should only come up when an existing S3 remote has been exported
to, and then later versioning was enabled.
Note that it would perhaps be possible to fall back from trying to use
retrieveKeyFile when it fails and instead use retrieveKeyFileFromExport,
which may work when S3 version ID is missing. But there are problems
with that approach; how to tell when retrieveKeyFile has failed due to this
rather than a network problem etc? Anyway, that approach would only work
until the file in the export got overwritten, and then it would no
longer be accessible. And with versioning enabled, the user wants old
versions of objects to remain accessible, so it seems better to warn
about the problem as soon as possible, so they can go back and add S3
version IDs.
This work is supported by the NIH-funded NICEMAN (ReproNim TR&D3) project.
2018-12-06 17:43:18 +00:00
|
|
|
missingCredPairFor :: String -> CredPairStorage -> String
|
|
|
|
missingCredPairFor this storage = unwords
|
2015-06-05 20:23:35 +00:00
|
|
|
[ "Set both", loginvar
|
|
|
|
, "and", passwordvar
|
|
|
|
, "to use", this
|
|
|
|
]
|
|
|
|
where
|
|
|
|
(loginvar, passwordvar) = credPairEnvironment storage
|
|
|
|
|
2012-11-14 23:32:27 +00:00
|
|
|
{- Gets a CredPair from the environment. -}
|
|
|
|
getEnvCredPair :: CredPairStorage -> IO (Maybe CredPair)
|
|
|
|
getEnvCredPair storage = liftM2 (,)
|
2013-09-22 18:13:31 +00:00
|
|
|
<$> getEnv uenv
|
|
|
|
<*> getEnv penv
|
2012-11-14 23:32:27 +00:00
|
|
|
where
|
|
|
|
(uenv, penv) = credPairEnvironment storage
|
|
|
|
|
2018-12-04 18:16:56 +00:00
|
|
|
{- Writes a cred pair to local cache, unless prevented by configuration. -}
|
2012-11-14 23:32:27 +00:00
|
|
|
writeCacheCredPair :: CredPair -> CredPairStorage -> Annex ()
|
2018-12-04 18:16:56 +00:00
|
|
|
writeCacheCredPair credpair storage =
|
|
|
|
whenM (annexCacheCreds <$> Annex.getGitConfig) $
|
|
|
|
writeCreds (encodeCredPair credpair) (credPairFile storage)
|
2018-12-04 18:02:37 +00:00
|
|
|
|
|
|
|
readCacheCredPair :: CredPairStorage -> Annex (Maybe CredPair)
|
|
|
|
readCacheCredPair storage = maybe Nothing decodeCredPair
|
|
|
|
<$> readCreds (credPairFile storage)
|
|
|
|
|
|
|
|
existsCacheCredPair :: CredPairStorage -> Annex Bool
|
|
|
|
existsCacheCredPair storage =
|
|
|
|
liftIO . doesFileExist =<< credsFile (credPairFile storage)
|
2012-11-14 23:32:27 +00:00
|
|
|
|
|
|
|
{- Stores the creds in a file inside gitAnnexCredsDir that only the user
|
|
|
|
- can read. -}
|
2018-12-04 18:02:37 +00:00
|
|
|
writeCreds :: Creds -> FilePath -> Annex ()
|
|
|
|
writeCreds creds file = do
|
2012-11-14 23:32:27 +00:00
|
|
|
d <- fromRepo gitAnnexCredsDir
|
|
|
|
createAnnexDirectory d
|
2013-05-09 17:57:31 +00:00
|
|
|
liftIO $ writeFileProtected (d </> file) creds
|
2012-11-14 23:32:27 +00:00
|
|
|
|
2018-12-04 18:02:37 +00:00
|
|
|
readCreds :: FilePath -> Annex (Maybe Creds)
|
|
|
|
readCreds f = liftIO . catchMaybeIO . readFileStrict =<< credsFile f
|
2014-10-21 19:09:40 +00:00
|
|
|
|
2018-12-04 18:02:37 +00:00
|
|
|
credsFile :: FilePath -> Annex FilePath
|
|
|
|
credsFile basefile = do
|
2012-11-14 23:32:27 +00:00
|
|
|
d <- fromRepo gitAnnexCredsDir
|
2014-10-21 19:09:40 +00:00
|
|
|
return $ d </> basefile
|
|
|
|
|
2012-11-14 23:32:27 +00:00
|
|
|
encodeCredPair :: CredPair -> Creds
|
|
|
|
encodeCredPair (l, p) = unlines [l, p]
|
|
|
|
|
|
|
|
decodeCredPair :: Creds -> Maybe CredPair
|
|
|
|
decodeCredPair creds = case lines creds of
|
|
|
|
l:p:[] -> Just (l, p)
|
|
|
|
_ -> Nothing
|
2014-04-20 16:46:33 +00:00
|
|
|
|
|
|
|
removeCreds :: FilePath -> Annex ()
|
|
|
|
removeCreds file = do
|
|
|
|
d <- fromRepo gitAnnexCredsDir
|
|
|
|
let f = d </> file
|
|
|
|
liftIO $ nukeFile f
|
2014-10-21 19:09:40 +00:00
|
|
|
|
2020-01-13 16:35:39 +00:00
|
|
|
includeCredsInfo :: ParsedRemoteConfig -> CredPairStorage -> [(String, String)] -> Annex [(String, String)]
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
includeCredsInfo pc@(ParsedRemoteConfig cm _) storage info = do
|
2014-10-21 19:09:40 +00:00
|
|
|
v <- liftIO $ getEnvCredPair storage
|
|
|
|
case v of
|
|
|
|
Just _ -> do
|
|
|
|
let (uenv, penv) = credPairEnvironment storage
|
|
|
|
ret $ "from environment variables (" ++ unwords [uenv, penv] ++ ")"
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
Nothing -> case (`M.lookup` cm) (credPairRemoteField storage) of
|
2014-10-21 19:09:40 +00:00
|
|
|
Nothing -> ifM (existsCacheCredPair storage)
|
|
|
|
( ret "stored locally"
|
|
|
|
, ret "not available"
|
|
|
|
)
|
fix encryption of content to gcrypt and git-lfs
Fix serious regression in gcrypt and encrypted git-lfs remotes.
Since version 7.20200202.7, git-annex incorrectly stored content
on those remotes without encrypting it.
Problem was, Remote.Git enumerates all git remotes, including git-lfs
and gcrypt. It then dispatches to those. So, Remote.List used the
RemoteConfigParser from Remote.Git, instead of from git-lfs or gcrypt,
and that parser does not know about encryption fields, so did not
include them in the ParsedRemoteConfig. (Also didn't include other
fields specific to those remotes, perhaps chunking etc also didn't
get through.)
To fix, had to move RemoteConfig parsing down into the generate methods
of each remote, rather than doing it in Remote.List.
And a consequence of that was that ParsedRemoteConfig had to change to
include the RemoteConfig that got parsed, so that testremote can
generate a new remote based on an existing remote.
(I would have rather fixed this just inside Remote.Git, but that was not
practical, at least not w/o re-doing work that Remote.List already did.
Big ugly mostly mechanical patch seemed preferable to making git-annex
slower.)
2020-02-26 21:20:56 +00:00
|
|
|
Just _ -> case extractCipher pc of
|
2015-04-11 04:10:34 +00:00
|
|
|
Just (EncryptedCipher {}) -> ret "embedded in git repository (gpg encrypted)"
|
2014-10-21 19:15:16 +00:00
|
|
|
_ -> ret "embedded in git repository (not encrypted)"
|
2014-10-21 19:09:40 +00:00
|
|
|
where
|
|
|
|
ret s = return $ ("creds", s) : info
|