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

This commit is contained in:
Joey Hess 2013-07-25 14:03:07 -04:00
commit a34c36d7fe
5 changed files with 59 additions and 0 deletions

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="2001:4978:f:21a::2"
subject="comment 1"
date="2013-07-25T17:00:53Z"
content="""
Thank you for reminding me why I was using debian stable chroots for the autobuilds.
Unfortunately, I forgot about this problem and upgraded the chroots. Rebuilding them with all the stuff I need is going to take a while.
"""]]

View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="2001:4978:f:21a::2"
subject="comment 4"
date="2013-07-25T17:38:38Z"
content="""
Hmm, that strace exposes the full symmetric encryption key that git-annex has created. Thankfully, it is a single use key which will only be used for this glacier remote, so if you avoid using that remote (which is probably not usable anyway due to initremote not finishing!), the exposure won't matter.
But, it is possible that this part is where it reads your personal gpg private key file. Hopefully the 55 bytes exposed out of the full 616 byte file are before the actual secret key data, or not enough to weaken your key. :/
8268 read(4, \"q\224R\236\341\264\336\23\315FTD\341\253\372\6o\206\326\376\243\326\34L\1\245;\tb\361v\\\"..., 600) = 600
8268 read(4, \"\2548\332\257\334\237\343\354\23\224\377\377\302\264\352\21\", 16) = 16
It seems to be easier to social engineer people into stracing gpg and exposing data than I'd have hoped. Actually, I didn't plan to do that at all, I just wanted you to attach to gpg after this point.
----
So yeah, your gpg is hanging on stdin after git-annex has sent it the \"passphrase\" (really a symmetric gpg key) on fd 3.
The reason the directory special remote doesn't hang is because it does not use gpg to encrypt anything during the initremote process.
I think I have a theory of what's going on with your git-annex build. It does not include the assistant, so will be built without -threaded. Using the non-threaded runtime system may be leading to a deadlock when git-annex is supposed to be simulantaneously feeding stdin to gpg and processing its stdout. I have historically had some trouble around this, and it has probably not been well tested without the threaded runtime.
(The standalone tarball problem is due to this bug, which will hopefully be fixed soon: [[Linux_stand_alone_build_20130723_breaks_support_for_glibc_2.13_debian_stable]])
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="2001:4978:f:21a::2"
subject="comment 5"
date="2013-07-25T17:44:59Z"
content="""
I was able to reproduce the bug by building without -threaded
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="2001:4978:f:21a::2"
subject="comment 6"
date="2013-07-25T17:57:31Z"
content="""
I've made it always build with -threaded. Did not see anything obvious I could do to not make it hang with the non-threaded runtime, other than forking a separate feeder process. -threaded may make it not build on a few systems with sustandard ghc support (like sparc).
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="2001:4978:f:21a::2"
subject="comment 1"
date="2013-07-25T17:05:00Z"
content="""
Simply set up xmpp on your clients in addition to the central repository you have now. When one client pushes over ssh to the central repo, it will use XMPP to inform other clients of the change.
"""]]