inheritable annex.securehashesonly

* init: When annex.securehashesonly has been set with git-annex config,
  copy that value to the annex.securehashesonly git config.
* config --set: As well as setting value in git-annex branch,
  set local gitconfig. This is needed especially for
  annex.securehashesonly, which is read only from local gitconfig and not
  the git-annex branch.

doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn has the
rationalle for doing it this way. There's no perfect solution; this
seems to be the least-bad one.

This commit was supported by the NSF-funded DataLad project.

update

early cancelation of transfer that annex.securehashesonly prohibits

This avoids sending all the data to a remote, only to have it reject it
because it has annex.securehashesonly set. It assumes that local and
remote will have the same annex.securehashesonly setting in most cases.
If a remote does not have that set, and local does, the remote won't get
some content it would otherwise accept.

Also avoids downloading data that will not be added to the local object
store due to annex.securehashesonly.

Note that, while encrypted special remotes use a GPGHMAC key variety,
which is not collisiton resistent, Transfers are not used for such
keys, so this check is avoided. Which is what we want, so encrypted
special remotes still work.

This commit was sponsored by Ewen McNeill.

reorg

securehash matching

Added --securehash option to match files using a secure hash function, and
corresponding securehash preferred content expression.

This commit was sponsored by Ethan Aubin.

mapM_ = sequence_ . map

make fsck check annex.securehashesonly, and new tip for working around SHA1 collisions with git-annex

This commit was sponsored by andrea rota.

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.

add cryptographicallySecure

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.

Merge branch 'master' of ssh://git-annex.branchable.com

fix osxapp target

Broken by recent changes to other targets

Added a comment

Added a comment

move thoughts

more thoughts

Added a comment

further thoughts

remove cryptohash from debian build-dep option

Removed support for building with the old cryptohash library.

Building with that library made git-annex not support SHA3; it's time for
that to always be supported in case SHA2 dominoes.

devblog

SHA1 collisions in key names was more exploitable than I thought

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.

fix up Read instance incompatability caused by recent commit

9c4650358ca85a298b747bb897dbf4f8f891fa22 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, 9c4650358ca85a298b747bb897dbf4f8f891fa22 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.

update

Revert "pointer to a todo"

This reverts commit ae3f6705eb8c4d33ef5983e8ccc6ade6cf0baff6.

todo is not ready yet

add KeyVariety type

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.

factor non-type stuff out of Key

pointer to a todo

update

clarify that annex.backends is used when adding new files

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.)

Merge branch 'master' of ssh://git-annex.branchable.com

add back a configure target

Otherwise, make reconfigures every time and then rebuilds all files.

I went too far in 3af9f5ed1a54f1df12f85f613826040e5e855817. 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

make file2key reject E* backend keys with a long extension

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.

Added a comment

update

update

typo

updates

update

Tighten key parser to not accept keys containing a non-numeric fields, which 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.

Merge branch 'master' of ssh://git-annex.branchable.com

add para

Added a comment

noCommit for PostReceive

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

slight correction

Merge branch 'master' of ssh://git-annex.branchable.com

devblog

Added a comment

remove Build/SysConfig.hs target

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

Added a comment

status: Pass --ignore-submodules=when option on to git status.

Didn't make --ignore-submodules without a value be handled because I can't
see a way to make optparse-applicative parse that. I've opened a bug
requesting a way to do that:
https://github.com/pcapriotti/optparse-applicative/issues/243

question

make curl show http errors to stderr

* Run curl with -S, so HTTP errors are displayed, even when
  it's otherwise silent.
* When downloading in --json or --quiet mode, use curl in preference
  to wget, since curl is able to display only errors to stderr, unlike
  wget.

This does mean that downloadQuiet is only silent on stdout, not necessarily
on stderr, which affects a couple other calls of it. For example,
downloading the .git/config of a http remote may show an error message now,
perhaps with slightly suboptimal formatting due to other output.

update

improve layout

Merge branch 'master' of ssh://git-annex.branchable.com

Run wget with -nv instead of -q, so it will display HTTP errors.

This adds one extra line of output when a download is successful,
after the progress bar. I don't much like that, but wget does not provide a
way to show HTTP errors without it.

removed

Added a comment

Added a comment

comment

comment

Added a comment: the problem files

adjust: Fix behavior when used in a repository that contains submodules.

Also fixed the LsFiles parser to not assume its output has a fixed width
type field.

Merge branch 'master' of ssh://git-annex.branchable.com

comment

mention GIT_SSH_COMMAND

comment

comment

remove

I've seen this thing, whatever it is, mentioned in spam links before,
so even if it's valid for some OS (probably not the one being asked
about), it's verboten here.

comment

git-annex.cabal: Make crypto-api a dependency even when built w/o webapp and test suite.

The p2p code made it always be needed.

This commit was sponsored by Anthony DeRobertis on Patreon.

comment

comment

Added a comment

Added a comment

linkify

devblog

documentation updates for new receive.denyCurrentBranch=updateInstead support

This commit was sponsored by andrea rota.

sync hack to make updateInstead work on eg FAT

sync: When syncing with a local repository located on a crippled
filesystem, run the post-receive hook there, since it wouldn't get run
otherwise. This makes pushing to repos on FAT-formatted removable drives
update them when receive.denyCurrentBranch=updateInstead.

Made Remote.Git export onLocal, which was cleaned up to not have so many
caveats about its use.

This commit was sponsored by Jeff Goeke-Smith on Patreon.

have onLocal stop any coprocesses, not only cat-file

I have not seen any other coprocesses being started, but let's avoid
problems if any do for whatever reason.

post-recive hook to make updateInstead work in direct mode and adjusted branches

* Added post-recieve hook, which makes updateInstead work with direct
  mode and adjusted branches.
* init: Set up the post-receive hook.

This commit was sponsored by Fernando Jimenez on Patreon.

make git-annex:git-annex push quiet again

Recent changes had a side effect of displaying errors in the fairly
common case when this push fails. Since the synced/git-annex push
is always forced, those errors are noise, so hide again.

This means 3 separate pushes are done now, where before it only made 2.
A bit more expensive, but ssh connection caching eliminates most of
the costs.

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.

thoughts

comment

Merge branch 'master' of ssh://git-annex.branchable.com

initial whining

Added a comment