| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
with annexed files.
Closes https://github.com/datalad/datalad/issues/18
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
This commit was sponsored by Andrew Cant.
|
| |/
|
|
| |
outside the menus.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This allows bypassing the direct mode guard in a safe way to do all sorts
of things including git revert, git mv, git checkout ...
This commit was sponsored by the WikiMedia Foundation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
typechange staged in index
I had hoped that the git devs could change git's handling of partial
commits to not use a false index file, but seems not.
So, this relies on some git internals to detect that case. The test suite
has a test case added to catch it if changes to git break it.
This commit was sponsored by Paul Tagliamonte.
|
| | |
|
| |
|
|
| |
through 5.20131127. That fixup code would accidentially fire when --git-dir was incorrectly pointed at the working tree of a git-annex repository, resulting in data loss. Closes: #768093
|
| | |
|
| | |
|
| |
|
|
| |
Before, the old version of the creds could be left there, and would continue to be used.
|
| |
|
|
|
|
|
|
| |
This is intended to let the user easily tell if a remote's creds are
coming from info embedded in the repository, or instead from the
environment, or perhaps are locally stored in a creds file.
This commit was sponsored by Frédéric Schütz.
|
| |
|
|
|
|
| |
No per-remote-type info yet.
This commit was sponsored by Stanley Yamane.
|
| |
|
|
| |
including its key and size.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
inability to manipulate the environment on windows.
Didn't know that this library existed!
This includes making git-annex not re-exec itself on start on windows, and
making the test suite on Windows run tests without forking.
|
| |
|
|
|
|
|
|
|
| |
an existing git remote.
This is not a complete fix. For one, git remote will happily go add a
remote that has the same name as an existing special remote. For another,
enableremote will enable a special remote over top of an existing git
remote. And, also, the webapp might.
|
| |
|
|
| |
https://github.com/haskell/hackage-server/issues/269
|
| |
|
|
|
|
|
|
|
| |
has no effect.
Added a Default instance for TrustLevel, and was able to use that to clear
up several other parts of the code too.
This commit was sponsored by Stephan Schulz
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Before, embedcreds=yes did not cause the creds to be stored in remote.log,
but also prevented them being locally cached.
|
| |
|
|
|
|
|
|
| |
The new yesod needs the ViewPatterns extension.
Also, a TH splice in Assistant/Threads/WebApp.hs failed to work without
OverLoadedStrings.
This commit was sponsored by Brock Spratlen.
|
| | |
|
| | |
|
| |
|
|
|
| |
I used to have this and hackage rejected the os(gnu), so I am going to see
if the new hackage still rejects it.
|
| | |
|
| |
|
|
| |
armhf.
|
| |
|
|
| |
work. Closes: #763057
|
| | |
|
| |
|
|
| |
debian/rules.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See 2fb7ad68637cc4e1092f835055a974f141808ca0 for backstory about how a repo
could be in this state.
When decryption fails, the repo must be using non-encrypted creds. Note
that creds are encrypted/decrypted using the encryption cipher which is
stored in the repo, so the decryption cannot fail due to missing gpg keys
etc. (For !shared encryptiom, the cipher is iteself encrypted using some
gpg key(s), and the decryption of the cipher happens earlier, so not
affected by this change.
Print a warning message for !shared repos, and continue on using the
cipher. Wrote a page explaining what users hit by this bug should do.
This commit was sponsored by Samuel Tardieu.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
cc54ff9e49260cd94f938e69e926a273e231ef4e, which tried to
fix the problem by not decrypting the embedded creds.
This commit was sponsored by Josh Taylor.
|
| |
|
|
|
|
|
|
|
|
| |
the repository was configured with encryption=shared embedcreds=yes."
This reverts commit cc54ff9e49260cd94f938e69e926a273e231ef4e.
I can find no basis for that commit and think that I made it in error.
setRemoteCredPair always encrypts using the cipher from remoteCipher,
even when the cipher is shared.
|
| |
|
|
| |
already done in indirect mode.
|
| |
|
|
| |
introduced in version 5.20140817.)
|
| |
|
|
| |
not yet supported on Windows.
|
| |
|
|
| |
automatically shut down the assistant. Closes: #761261
|
| | |
|
| |
|
|
| |
This also works with 0.9, and probably 0.8.
|
| |
|
|
| |
capacity/accuracy, fall back to a reasonable default bloom filter size.
|
Joey Hess