correction of scope of security problem

AFAICS, it's not only affecting resumes, but any upload to a special remote
with chunking enabled.
This commit is contained in:
Joey Hess 2016-04-28 16:07:10 -04:00
parent b22409db38
commit 9c7e46c9c5
Failed to extract signature
2 changed files with 4 additions and 7 deletions

4
debian/changelog vendored
View file

@ -8,8 +8,8 @@ git-annex (6.20160419) unstable; urgency=medium
* Fix bug that prevented resuming of uploads to encrypted special remotes * Fix bug that prevented resuming of uploads to encrypted special remotes
that used chunking. that used chunking.
* That bug could also expose the names of keys to such remotes when * That bug could also expose the names of keys to such remotes, so it is a
attempting to resume an upload, so it is a minor security issue. minor security issue.
* Fix duplicate progress meter display when downloading from a git remote * Fix duplicate progress meter display when downloading from a git remote
over http with -J. over http with -J.
* reinject: When src file's content cannot be verified, leave it alone, * reinject: When src file's content cannot be verified, leave it alone,

View file

@ -10,9 +10,6 @@ non-chunked form, since a remote can be reconfigured to add chunking.
So it's nothing to worry about. So it's nothing to worry about.
The lack of encryption of the key when checking to resume is definitely a The lack of encryption of the key when checking to resume is definitely a
bug. A bit of a security bug too, although it only happens when resuming bug. A bit of a security bug too.
uploads. (I double checked the other operations and they all encrypt keys) (I double checked the other operations and they all encrypt keys)
I suppose that if the server was hostile, it could randomly make
uploads fail, in order to get git-annex to expose content keys via
this bug when resuming.
"""]] """]]