2015-12-22 17:23:33 +00:00
|
|
|
{- git-annex content ingestion
|
|
|
|
-
|
2019-06-25 15:37:52 +00:00
|
|
|
- Copyright 2010-2019 Joey Hess <id@joeyh.name>
|
2015-12-22 17:23:33 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2015-12-22 17:23:33 +00:00
|
|
|
-}
|
|
|
|
|
|
|
|
module Annex.Ingest (
|
2015-12-22 19:23:27 +00:00
|
|
|
LockedDown(..),
|
2016-01-07 21:39:59 +00:00
|
|
|
LockDownConfig(..),
|
2015-12-22 17:23:33 +00:00
|
|
|
lockDown,
|
2016-02-16 18:43:43 +00:00
|
|
|
ingestAdd,
|
2017-02-09 19:32:22 +00:00
|
|
|
ingestAdd',
|
2015-12-22 17:23:33 +00:00
|
|
|
ingest,
|
2016-06-09 19:17:08 +00:00
|
|
|
ingest',
|
2015-12-22 20:22:28 +00:00
|
|
|
finishIngestUnlocked,
|
2015-12-22 20:55:49 +00:00
|
|
|
cleanOldKeys,
|
2015-12-22 17:23:33 +00:00
|
|
|
addLink,
|
|
|
|
makeLink,
|
2016-02-16 18:43:43 +00:00
|
|
|
addUnlocked,
|
2015-12-22 17:23:33 +00:00
|
|
|
restoreFile,
|
|
|
|
forceParams,
|
2016-02-16 18:43:43 +00:00
|
|
|
addAnnexedFile,
|
2015-12-22 17:23:33 +00:00
|
|
|
) where
|
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2015-12-22 17:23:33 +00:00
|
|
|
import Types.KeySource
|
|
|
|
import Backend
|
|
|
|
import Annex.Content
|
|
|
|
import Annex.Perms
|
|
|
|
import Annex.Link
|
|
|
|
import Annex.MetaData
|
2018-10-19 19:17:48 +00:00
|
|
|
import Annex.CurrentBranch
|
2016-02-16 18:43:43 +00:00
|
|
|
import Annex.Version
|
2015-12-22 20:55:49 +00:00
|
|
|
import Logs.Location
|
2015-12-22 17:23:33 +00:00
|
|
|
import qualified Annex
|
|
|
|
import qualified Annex.Queue
|
2015-12-22 20:22:28 +00:00
|
|
|
import qualified Database.Keys
|
2015-12-22 17:23:33 +00:00
|
|
|
import Config
|
|
|
|
import Utility.InodeCache
|
|
|
|
import Annex.ReplaceFile
|
|
|
|
import Utility.Tmp
|
|
|
|
import Utility.CopyFile
|
2016-02-15 15:47:33 +00:00
|
|
|
import Utility.Touch
|
2019-06-25 15:37:52 +00:00
|
|
|
import Utility.Metered
|
2016-01-05 21:22:19 +00:00
|
|
|
import Git.FilePath
|
2015-12-22 17:23:33 +00:00
|
|
|
import Annex.InodeSentinal
|
2016-03-29 17:26:06 +00:00
|
|
|
import Annex.AdjustedBranch
|
2015-12-22 17:23:33 +00:00
|
|
|
|
|
|
|
import Control.Exception (IOException)
|
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
data LockedDown = LockedDown
|
2016-01-07 21:39:59 +00:00
|
|
|
{ lockDownConfig :: LockDownConfig
|
2015-12-22 19:23:27 +00:00
|
|
|
, keySource :: KeySource
|
|
|
|
}
|
|
|
|
deriving (Show)
|
|
|
|
|
2016-01-07 21:39:59 +00:00
|
|
|
data LockDownConfig = LockDownConfig
|
2019-05-07 17:04:39 +00:00
|
|
|
{ lockingFile :: Bool
|
|
|
|
-- ^ write bit removed during lock down
|
|
|
|
, hardlinkFileTmpDir :: Maybe FilePath
|
|
|
|
-- ^ hard link to temp directory
|
2016-01-07 21:39:59 +00:00
|
|
|
}
|
|
|
|
deriving (Show)
|
|
|
|
|
2015-12-22 17:23:33 +00:00
|
|
|
{- The file that's being ingested is locked down before a key is generated,
|
|
|
|
- to prevent it from being modified in between. This lock down is not
|
|
|
|
- perfect at best (and pretty weak at worst). For example, it does not
|
|
|
|
- guard against files that are already opened for write by another process.
|
2015-12-22 19:23:27 +00:00
|
|
|
- So, the InodeCache can be used to detect any changes that might be made
|
|
|
|
- to the file after it was locked down.
|
2015-12-22 17:23:33 +00:00
|
|
|
-
|
|
|
|
- When possible, the file is hard linked to a temp directory. This guards
|
|
|
|
- against some changes, like deletion or overwrite of the file, and
|
|
|
|
- allows lsof checks to be done more efficiently when adding a lot of files.
|
|
|
|
-
|
|
|
|
- Lockdown can fail if a file gets deleted, and Nothing will be returned.
|
|
|
|
-}
|
2016-01-07 21:39:59 +00:00
|
|
|
lockDown :: LockDownConfig -> FilePath -> Annex (Maybe LockedDown)
|
|
|
|
lockDown cfg file = either
|
2015-12-22 17:23:33 +00:00
|
|
|
(\e -> warning (show e) >> return Nothing)
|
|
|
|
(return . Just)
|
2016-01-07 21:39:59 +00:00
|
|
|
=<< lockDown' cfg file
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2016-01-07 21:39:59 +00:00
|
|
|
lockDown' :: LockDownConfig -> FilePath -> Annex (Either IOException LockedDown)
|
2019-05-07 17:04:39 +00:00
|
|
|
lockDown' cfg file = tryIO $ ifM crippledFileSystem
|
|
|
|
( nohardlink
|
|
|
|
, case hardlinkFileTmpDir cfg of
|
|
|
|
Nothing -> nohardlink
|
|
|
|
Just tmpdir -> withhardlink tmpdir
|
2015-12-22 19:23:27 +00:00
|
|
|
)
|
|
|
|
where
|
2019-05-07 17:04:39 +00:00
|
|
|
nohardlink = withTSDelta $ liftIO . nohardlink'
|
|
|
|
|
|
|
|
nohardlink' delta = do
|
2015-12-22 17:23:33 +00:00
|
|
|
cache <- genInodeCache file delta
|
2016-01-07 21:39:59 +00:00
|
|
|
return $ LockedDown cfg $ KeySource
|
2015-12-22 17:23:33 +00:00
|
|
|
{ keyFilename = file
|
|
|
|
, contentLocation = file
|
|
|
|
, inodeCache = cache
|
|
|
|
}
|
2019-05-07 17:04:39 +00:00
|
|
|
|
|
|
|
withhardlink tmpdir = do
|
|
|
|
when (lockingFile cfg) $
|
|
|
|
freezeContent file
|
|
|
|
withTSDelta $ \delta -> liftIO $ do
|
|
|
|
(tmpfile, h) <- openTempFile tmpdir $
|
|
|
|
relatedTemplate $ "ingest-" ++ takeFileName file
|
|
|
|
hClose h
|
|
|
|
nukeFile tmpfile
|
|
|
|
withhardlink' delta tmpfile
|
|
|
|
`catchIO` const (nohardlink' delta)
|
|
|
|
|
|
|
|
withhardlink' delta tmpfile = do
|
2015-12-22 17:23:33 +00:00
|
|
|
createLink file tmpfile
|
|
|
|
cache <- genInodeCache tmpfile delta
|
2016-01-07 21:39:59 +00:00
|
|
|
return $ LockedDown cfg $ KeySource
|
2015-12-22 17:23:33 +00:00
|
|
|
{ keyFilename = file
|
|
|
|
, contentLocation = tmpfile
|
|
|
|
, inodeCache = cache
|
|
|
|
}
|
|
|
|
|
2016-02-16 18:43:43 +00:00
|
|
|
{- Ingests a locked down file into the annex. Updates the work tree and
|
|
|
|
- index. -}
|
2019-06-25 15:37:52 +00:00
|
|
|
ingestAdd :: MeterUpdate -> Maybe LockedDown -> Annex (Maybe Key)
|
|
|
|
ingestAdd meterupdate ld = ingestAdd' meterupdate ld Nothing
|
2017-02-09 19:32:22 +00:00
|
|
|
|
2019-06-25 15:37:52 +00:00
|
|
|
ingestAdd' :: MeterUpdate -> Maybe LockedDown -> Maybe Key -> Annex (Maybe Key)
|
|
|
|
ingestAdd' _ Nothing _ = return Nothing
|
|
|
|
ingestAdd' meterupdate ld@(Just (LockedDown cfg source)) mk = do
|
|
|
|
(mk', mic) <- ingest meterupdate ld mk
|
2017-02-09 19:32:22 +00:00
|
|
|
case mk' of
|
2016-02-16 18:43:43 +00:00
|
|
|
Nothing -> return Nothing
|
|
|
|
Just k -> do
|
|
|
|
let f = keyFilename source
|
|
|
|
if lockingFile cfg
|
2017-10-16 16:57:28 +00:00
|
|
|
then addLink f k mic
|
2019-08-26 19:52:19 +00:00
|
|
|
else do
|
|
|
|
mode <- liftIO $ catchMaybeIO $ fileMode <$> getFileStatus (contentLocation source)
|
|
|
|
stagePointerFile f mode =<< hashPointerFile k
|
2016-02-16 18:43:43 +00:00
|
|
|
return (Just k)
|
|
|
|
|
|
|
|
{- Ingests a locked down file into the annex. Does not update the working
|
2018-08-14 18:22:23 +00:00
|
|
|
- tree or the index. -}
|
2019-06-25 15:37:52 +00:00
|
|
|
ingest :: MeterUpdate -> Maybe LockedDown -> Maybe Key -> Annex (Maybe Key, Maybe InodeCache)
|
|
|
|
ingest meterupdate ld mk = ingest' Nothing meterupdate ld mk (Restage True)
|
2016-06-09 19:17:08 +00:00
|
|
|
|
2019-06-25 15:37:52 +00:00
|
|
|
ingest' :: Maybe Backend -> MeterUpdate -> Maybe LockedDown -> Maybe Key -> Restage -> Annex (Maybe Key, Maybe InodeCache)
|
|
|
|
ingest' _ _ Nothing _ _ = return (Nothing, Nothing)
|
|
|
|
ingest' preferredbackend meterupdate (Just (LockedDown cfg source)) mk restage = withTSDelta $ \delta -> do
|
2017-02-09 19:32:22 +00:00
|
|
|
k <- case mk of
|
|
|
|
Nothing -> do
|
|
|
|
backend <- maybe (chooseBackend $ keyFilename source) (return . Just) preferredbackend
|
2019-06-25 15:37:52 +00:00
|
|
|
fmap fst <$> genKey source meterupdate backend
|
2017-02-09 19:32:22 +00:00
|
|
|
Just k -> return (Just k)
|
2015-12-22 17:23:33 +00:00
|
|
|
let src = contentLocation source
|
|
|
|
ms <- liftIO $ catchMaybeIO $ getFileStatus src
|
|
|
|
mcache <- maybe (pure Nothing) (liftIO . toInodeCache delta src) ms
|
|
|
|
case (mcache, inodeCache source) of
|
|
|
|
(_, Nothing) -> go k mcache ms
|
|
|
|
(Just newc, Just c) | compareStrong c newc -> go k mcache ms
|
|
|
|
_ -> failure "changed while it was being added"
|
|
|
|
where
|
2017-02-09 19:32:22 +00:00
|
|
|
go (Just key) mcache (Just s)
|
2016-01-07 21:39:59 +00:00
|
|
|
| lockingFile cfg = golocked key mcache s
|
2019-08-26 19:52:19 +00:00
|
|
|
| otherwise = gounlocked key mcache s
|
2015-12-22 19:23:27 +00:00
|
|
|
go _ _ _ = failure "failed to generate a key"
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2017-11-15 20:55:38 +00:00
|
|
|
golocked key mcache s =
|
|
|
|
tryNonAsync (moveAnnex key $ contentLocation source) >>= \case
|
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
|
|
|
Right True -> do
|
2018-08-14 18:22:23 +00:00
|
|
|
populateAssociatedFiles key source restage
|
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
|
|
|
success key mcache s
|
|
|
|
Right False -> giveup "failed to add content to annex"
|
|
|
|
Left e -> restoreFile (keyFilename source) key e
|
2015-12-22 19:23:27 +00:00
|
|
|
|
|
|
|
gounlocked key (Just cache) s = do
|
2015-12-22 20:22:28 +00:00
|
|
|
-- Remove temp directory hard link first because
|
2015-12-27 19:59:59 +00:00
|
|
|
-- linkToAnnex falls back to copying if a file
|
2015-12-22 20:22:28 +00:00
|
|
|
-- already has a hard link.
|
|
|
|
cleanCruft source
|
2015-12-22 20:55:49 +00:00
|
|
|
cleanOldKeys (keyFilename source) key
|
2017-11-15 20:55:38 +00:00
|
|
|
linkToAnnex key (keyFilename source) (Just cache) >>= \case
|
2015-12-22 19:23:27 +00:00
|
|
|
LinkAnnexFailed -> failure "failed to link to annex"
|
2015-12-22 20:22:28 +00:00
|
|
|
_ -> do
|
2018-08-14 18:22:23 +00:00
|
|
|
finishIngestUnlocked' key source restage
|
2015-12-22 20:22:28 +00:00
|
|
|
success key (Just cache) s
|
2015-12-22 19:23:27 +00:00
|
|
|
gounlocked _ _ _ = failure "failed statting file"
|
2015-12-22 17:23:33 +00:00
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
success k mcache s = do
|
|
|
|
genMetaData k (keyFilename source) s
|
|
|
|
return (Just k, mcache)
|
2015-12-22 17:23:33 +00:00
|
|
|
|
|
|
|
failure msg = do
|
|
|
|
warning $ keyFilename source ++ " " ++ msg
|
2015-12-22 19:23:27 +00:00
|
|
|
cleanCruft source
|
2015-12-22 17:23:33 +00:00
|
|
|
return (Nothing, Nothing)
|
|
|
|
|
2015-12-22 20:22:28 +00:00
|
|
|
finishIngestUnlocked :: Key -> KeySource -> Annex ()
|
|
|
|
finishIngestUnlocked key source = do
|
2015-12-22 22:03:47 +00:00
|
|
|
cleanCruft source
|
2018-08-14 18:22:23 +00:00
|
|
|
finishIngestUnlocked' key source (Restage True)
|
2015-12-22 22:03:47 +00:00
|
|
|
|
2018-08-14 18:22:23 +00:00
|
|
|
finishIngestUnlocked' :: Key -> KeySource -> Restage -> Annex ()
|
|
|
|
finishIngestUnlocked' key source restage = do
|
2016-01-05 21:22:19 +00:00
|
|
|
Database.Keys.addAssociatedFile key =<< inRepo (toTopFilePath (keyFilename source))
|
2018-08-14 18:22:23 +00:00
|
|
|
populateAssociatedFiles key source restage
|
2015-12-22 20:22:28 +00:00
|
|
|
|
|
|
|
{- Copy to any other locations using the same key. -}
|
2018-08-14 18:22:23 +00:00
|
|
|
populateAssociatedFiles :: Key -> KeySource -> Restage -> Annex ()
|
|
|
|
populateAssociatedFiles key source restage = do
|
2015-12-22 20:22:28 +00:00
|
|
|
obj <- calcRepo (gitAnnexLocation key)
|
2016-01-05 21:22:19 +00:00
|
|
|
g <- Annex.gitRepo
|
|
|
|
ingestedf <- flip fromTopFilePath g
|
|
|
|
<$> inRepo (toTopFilePath (keyFilename source))
|
|
|
|
afs <- map (`fromTopFilePath` g) <$> Database.Keys.getAssociatedFiles key
|
|
|
|
forM_ (filter (/= ingestedf) afs) $
|
2018-08-14 18:22:23 +00:00
|
|
|
populatePointerFile restage key obj
|
2015-12-22 20:22:28 +00:00
|
|
|
|
2015-12-22 19:23:27 +00:00
|
|
|
cleanCruft :: KeySource -> Annex ()
|
|
|
|
cleanCruft source = when (contentLocation source /= keyFilename source) $
|
|
|
|
liftIO $ nukeFile $ contentLocation source
|
|
|
|
|
2015-12-22 20:55:49 +00:00
|
|
|
-- If a worktree file was was hard linked to an annex object before,
|
|
|
|
-- modifying the file would have caused the object to have the wrong
|
|
|
|
-- content. Clean up from that.
|
|
|
|
cleanOldKeys :: FilePath -> Key -> Annex ()
|
|
|
|
cleanOldKeys file newkey = do
|
2016-01-05 21:22:19 +00:00
|
|
|
g <- Annex.gitRepo
|
|
|
|
ingestedf <- flip fromTopFilePath g <$> inRepo (toTopFilePath file)
|
|
|
|
topf <- inRepo (toTopFilePath file)
|
2015-12-22 20:55:49 +00:00
|
|
|
oldkeys <- filter (/= newkey)
|
2016-01-05 21:22:19 +00:00
|
|
|
<$> Database.Keys.getAssociatedKey topf
|
lock: Fix edge cases where data loss could occur in v6 mode.
In the case where the pointer file is in place, and not the content
of the object, lock's performNew was called with filemodified=True,
which caused it to try to repopulate the object from an unmodified
associated file, of which there were none. So, the content of the object
got thrown away incorrectly. This was the cause (although not the root
cause) of data loss in https://github.com/datalad/datalad/issues/1020
The same problem could also occur when the work tree file is modified,
but the object is not, and lock is called with --force. Added a test case
for this, since it's excercising the same code path and is easier to set up
than the problem above.
Note that this only occurred when the keys database did not have an inode
cache recorded for the annex object. Normally, the annex object would be in
there, but there are of course circumstances where the inode cache is out
of sync with reality, since it's only a cache.
Fixed by checking if the object is unmodified; if so we don't need to
try to repopulate it. This does add an additional checksum to the unlock
path, but it's already checksumming the worktree file in another case,
so it doesn't slow it down overall.
Further investigation found a similar problem occurred when smudge --clean
is called on a file and the inode cache is not populated. cleanOldKeys
deleted the unmodified old object file in this case. This was also
fixed by checking if the object is unmodified.
In general, use of getInodeCaches and sameInodeCache is potentially
dangerous if the inode cache has not gotten populated for some reason.
Better to use isUnmodified. I breifly auited other places that check the
inode cache, and did not see any immediate problems, but it would be easy
to miss this kind of problem.
2016-10-17 16:56:26 +00:00
|
|
|
forM_ oldkeys $ \key ->
|
|
|
|
unlessM (isUnmodified key =<< calcRepo (gitAnnexLocation key)) $ do
|
|
|
|
caches <- Database.Keys.getInodeCaches key
|
2015-12-22 20:55:49 +00:00
|
|
|
unlinkAnnex key
|
2016-01-05 21:22:19 +00:00
|
|
|
fs <- filter (/= ingestedf)
|
|
|
|
. map (`fromTopFilePath` g)
|
2015-12-22 20:55:49 +00:00
|
|
|
<$> Database.Keys.getAssociatedFiles key
|
2017-11-15 20:55:38 +00:00
|
|
|
filterM (`sameInodeCache` caches) fs >>= \case
|
2015-12-27 19:59:59 +00:00
|
|
|
-- If linkToAnnex fails, the associated
|
2015-12-22 20:55:49 +00:00
|
|
|
-- file with the content is still present,
|
|
|
|
-- so no need for any recovery.
|
|
|
|
(f:_) -> do
|
|
|
|
ic <- withTSDelta (liftIO . genInodeCache f)
|
2015-12-27 19:59:59 +00:00
|
|
|
void $ linkToAnnex key f ic
|
2016-01-05 21:22:19 +00:00
|
|
|
_ -> logStatus key InfoMissing
|
2015-12-22 20:55:49 +00:00
|
|
|
|
2015-12-22 17:23:33 +00:00
|
|
|
{- On error, put the file back so it doesn't seem to have vanished.
|
|
|
|
- This can be called before or after the symlink is in place. -}
|
|
|
|
restoreFile :: FilePath -> Key -> SomeException -> Annex a
|
|
|
|
restoreFile file key e = do
|
|
|
|
whenM (inAnnex key) $ do
|
|
|
|
liftIO $ nukeFile file
|
|
|
|
-- The key could be used by other files too, so leave the
|
|
|
|
-- content in the annex, and make a copy back to the file.
|
|
|
|
obj <- calcRepo $ gitAnnexLocation key
|
|
|
|
unlessM (liftIO $ copyFileExternal CopyTimeStamps obj file) $
|
|
|
|
warning $ "Unable to restore content of " ++ file ++ "; it should be located in " ++ obj
|
|
|
|
thawContent file
|
|
|
|
throwM e
|
|
|
|
|
|
|
|
{- Creates the symlink to the annexed content, returns the link target. -}
|
|
|
|
makeLink :: FilePath -> Key -> Maybe InodeCache -> Annex String
|
|
|
|
makeLink file key mcache = flip catchNonAsync (restoreFile file key) $ do
|
|
|
|
l <- calcRepo $ gitAnnexLink file key
|
|
|
|
replaceFile file $ makeAnnexLink l
|
|
|
|
|
|
|
|
-- touch symlink to have same time as the original file,
|
|
|
|
-- as provided in the InodeCache
|
|
|
|
case mcache of
|
2018-10-30 02:22:36 +00:00
|
|
|
Just c -> liftIO $ touch file (inodeCacheToMtime c) False
|
2015-12-22 17:23:33 +00:00
|
|
|
Nothing -> noop
|
|
|
|
|
|
|
|
return l
|
|
|
|
|
|
|
|
{- Creates the symlink to the annexed content, and stages it in git.
|
|
|
|
-
|
|
|
|
- As long as the filesystem supports symlinks, we use
|
|
|
|
- git add, rather than directly staging the symlink to git.
|
|
|
|
- Using git add is best because it allows the queuing to work
|
|
|
|
- and is faster (staging the symlink runs hash-object commands each time).
|
|
|
|
- Also, using git add allows it to skip gitignored files, unless forced
|
|
|
|
- to include them.
|
|
|
|
-}
|
|
|
|
addLink :: FilePath -> Key -> Maybe InodeCache -> Annex ()
|
|
|
|
addLink file key mcache = ifM (coreSymlinks <$> Annex.getGitConfig)
|
|
|
|
( do
|
|
|
|
_ <- makeLink file key mcache
|
|
|
|
ps <- forceParams
|
|
|
|
Annex.Queue.addCommand "add" (ps++[Param "--"]) [file]
|
|
|
|
, do
|
|
|
|
l <- makeLink file key mcache
|
|
|
|
addAnnexLink l file
|
|
|
|
)
|
|
|
|
|
|
|
|
{- Parameters to pass to git add, forcing addition of ignored files. -}
|
|
|
|
forceParams :: Annex [CommandParam]
|
|
|
|
forceParams = ifM (Annex.getState Annex.force)
|
|
|
|
( return [Param "-f"]
|
|
|
|
, return []
|
|
|
|
)
|
2016-02-16 18:43:43 +00:00
|
|
|
|
|
|
|
{- Whether a file should be added unlocked or not. Default is to not,
|
2016-03-29 17:26:06 +00:00
|
|
|
- unless symlinks are not supported. annex.addunlocked can override that.
|
|
|
|
- Also, when in an adjusted unlocked branch, always add files unlocked.
|
|
|
|
-}
|
2016-02-16 18:43:43 +00:00
|
|
|
addUnlocked :: Annex Bool
|
2019-08-26 19:52:19 +00:00
|
|
|
addUnlocked =
|
2016-02-16 18:43:43 +00:00
|
|
|
(versionSupportsUnlockedPointers <&&>
|
|
|
|
((not . coreSymlinks <$> Annex.getGitConfig) <||>
|
2016-03-29 17:26:06 +00:00
|
|
|
(annexAddUnlocked <$> Annex.getGitConfig) <||>
|
2018-10-19 19:17:48 +00:00
|
|
|
(maybe False isadjustedunlocked . snd <$> getCurrentBranch)
|
2016-02-16 18:43:43 +00:00
|
|
|
)
|
|
|
|
)
|
2018-10-18 16:51:20 +00:00
|
|
|
where
|
2018-10-19 19:17:48 +00:00
|
|
|
isadjustedunlocked (LinkAdjustment UnlockAdjustment) = True
|
|
|
|
isadjustedunlocked (PresenceAdjustment _ (Just UnlockAdjustment)) = True
|
2018-10-18 16:51:20 +00:00
|
|
|
isadjustedunlocked _ = False
|
2016-02-16 18:43:43 +00:00
|
|
|
|
|
|
|
{- Adds a file to the work tree for the key, and stages it in the index.
|
|
|
|
- The content of the key may be provided in a temp file, which will be
|
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
|
|
|
- moved into place.
|
|
|
|
-
|
|
|
|
- When the content of the key is not accepted into the annex, returns False.
|
|
|
|
-}
|
|
|
|
addAnnexedFile :: FilePath -> Key -> Maybe FilePath -> Annex Bool
|
2019-08-26 19:52:19 +00:00
|
|
|
addAnnexedFile file key mtmp = ifM addUnlocked
|
2016-02-16 18:43:43 +00:00
|
|
|
( do
|
2016-04-14 18:30:15 +00:00
|
|
|
mode <- maybe
|
|
|
|
(pure Nothing)
|
|
|
|
(\tmp -> liftIO $ catchMaybeIO $ fileMode <$> getFileStatus tmp)
|
|
|
|
mtmp
|
|
|
|
stagePointerFile file mode =<< hashPointerFile key
|
2016-02-16 18:43:43 +00:00
|
|
|
Database.Keys.addAssociatedFile key =<< inRepo (toTopFilePath file)
|
|
|
|
case mtmp of
|
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
|
|
|
Just tmp -> ifM (moveAnnex key tmp)
|
|
|
|
( linkunlocked mode >> return True
|
|
|
|
, writepointer mode >> return False
|
|
|
|
)
|
2016-02-16 18:43:43 +00:00
|
|
|
Nothing -> ifM (inAnnex key)
|
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
|
|
|
( linkunlocked mode >> return True
|
|
|
|
, writepointer mode >> return True
|
2016-02-16 18:43:43 +00:00
|
|
|
)
|
|
|
|
, do
|
|
|
|
addLink file key Nothing
|
|
|
|
case mtmp of
|
2019-08-26 19:52:19 +00:00
|
|
|
Just tmp -> moveAnnex key tmp
|
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
|
|
|
Nothing -> return True
|
2016-02-16 18:43:43 +00:00
|
|
|
)
|
|
|
|
where
|
2017-11-15 20:55:38 +00:00
|
|
|
linkunlocked mode = linkFromAnnex key file mode >>= \case
|
|
|
|
LinkAnnexFailed -> liftIO $
|
|
|
|
writePointerFile file key mode
|
|
|
|
_ -> return ()
|
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
|
|
|
writepointer mode = liftIO $ writePointerFile file key mode
|