| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
Added --securehash option to match files using a secure hash function, and
corresponding securehash preferred content expression.
This commit was sponsored by Ethan Aubin.
|
| | |
|
| |
|
|
|
|
| |
collisions with git-annex
This commit was sponsored by andrea rota.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Note that GPGHMAC keys are not cryptographically secure, because their
content has no relation to the name of the key. So, things that use this
function to avoid sending keys to a remote will need to special case in
support for those keys. If GPGHMAC keys were accepted as
cryptographically secure, symlinks using them could be committed to a
git repo, and their content would be accepted into the repo, with no
guarantee that two repos got the same content, which is what we're aiming
to prevent.
|
| |\ |
|
| | |
| |
| |
| | |
Broken by recent changes to other targets
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
| |
Building with that library made git-annex not support SHA3; it's time for
that to always be supported in case SHA2 dominoes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Yesterday's SHA1 collision attack could be used to generate eg:
SHA256-sfoo--whatever.good
SHA256-sfoo--whatever.bad
Such that they collide. A repository with the good one could have the
bad one swapped in and signed commits would still verify.
I've already mitigated this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2f868db90c7ba16eee901b9b1472b1e1a889dd93 changed the Read instance for
Key.
I've checked all uses of that instance (by removing it and seeing what
breaks), and they're all limited to the webapp, except one.
That is GitAnnexDistribution's Read instance.
So, 2f868db90c7ba16eee901b9b1472b1e1a889dd93 would have broken upgrades
of git-annex from downloads.kitenet.net. Once the .info files there got
updated for a new release, old releases would have failed to parse them
and never upgraded.
To fix this, I found a way to make the .info files that contain
GitAnnexDistribution values be readable by the old version of git-annex.
This commit was sponsored by Ewen McNeill.
|
| | |
|
| |
|
|
|
|
| |
This reverts commit d884cdfbed61fa451c54562711ab5a12f41a7f7a.
todo is not ready yet
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Where before the "name" of a key and a backend was a string, this makes
it a concrete data type.
This is groundwork for allowing some varieties of keys to be disabled
in file2key, so git-annex won't use them at all.
Benchmarks ran in my big repo:
old git-annex info:
real 0m3.338s
user 0m3.124s
sys 0m0.244s
new git-annex info:
real 0m3.216s
user 0m3.024s
sys 0m0.220s
new git-annex find:
real 0m7.138s
user 0m6.924s
sys 0m0.252s
old git-annex find:
real 0m7.433s
user 0m7.240s
sys 0m0.232s
Surprising result; I'd have expected it to be slower since it now parses
all the key varieties. But, the parser is very simple and perhaps
sharing KeyVarieties uses less memory or something like that.
This commit was supported by the NSF-funded DataLad project.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Even if annex.backends does not include a backend, that does not prevent
git-annex commands from acting on a file using the missing backend.
(There's really no reason at all for annex.backends to be a list.)
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise, make reconfigures every time and then rebuilds all files.
I went too far in 3dc6aa3f53dc17573996a3ceae32f80dfd9e7094. All that's
needed is to make the configure target not use Build/SysConfig.hs as the
target name, so make won't delete that file after a failed build.
This commit was supported by the NSF-funded DataLad project
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I am not happy that I had to put backend-specific code in file2key. But
it would be very difficult to avoid this layering violation.
Most of the time, when parsing a Key from a symlink target, git-annex
never looks up its Backend at all, so adding this check to a method of
the Backend object would not work.
The Key could be made to contain the appropriate
Backend, but since Backend is parameterized on an "a" that is fixed to
the Annex monad later, that would need Key to change to "Key a".
The only way to clean this up that I can see would be to have the Key
contain a LowlevelBackend, and put the validation in LowlevelBackend.
Perhaps later, but that would be an extensive change, so let's not do
it in this commit which may want to cherry-pick to backports.
This commit was sponsored by Ethan Aubin.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
could be used to embed data useful for a SHA1 attack against git.
Also todo about why this is important, and with some further hardening to
add.
This commit was sponsored by Ignacio on Patreon.
|
| |\ |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was noticed because it broke the datalad test suite, which pushed
to the remote and then fetched to check if it had received the expected
branches. Auto-init caused the git-annex branch on the remote to
diverge, breaking that test.
https://github.com/datalad/datalad/issues/1319#issuecomment-281649518
The auto-init still happens, it's staged in the journal, and will be
commited by some later git-annex command when it runs. Which is fine,
it's the same as that later command doing the auto-init.
This commit was supported by the NSF-funded DataLad project
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem with that target was, if a target like git-annex that
depended on it failed for some reason, make would delete
Build/SysConfig.hs, since it knows it's an intermediate file. But, since
stack only builds that file once, that caused all subsequent make git-annex
builds to fail.
Also, this avoids a double stack build when building with stack. Since
stack has no configure stage, and the Build/SysConfig.hs target was
about running the configure stage, the only way to only build once is to
combine the targets like this.
This should work better on the autobuilders that build with stack.
This commit was sponsored by NSF-funded DataLad project
|
| | |
|
Joey Hess
michalrus
openmedi
benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3
unicell@9c0b0afd4176d5933d4b5c41350ebe61488c1df0
lhunath@3b4ff15f4600f3276d1776a490b734fca0f5c245
jean.jordaan@4bb3bd508a9eb0a4bab5d1b587dadd2b6c4a7edc
db48x