From e5ce108680fe50f385b5baddbfd1d106455a6a79 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U" Date: Sun, 3 Nov 2013 09:48:53 +0000 Subject: [PATCH 01/18] Added a comment --- .../comment_2_6321dec0b2f22f841f3cb986e063113f._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment diff --git a/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment b/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment new file mode 100644 index 0000000000..b1ce5a1a5b --- /dev/null +++ b/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_2_6321dec0b2f22f841f3cb986e063113f._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U" + nickname="Carlo" + subject="comment 2" + date="2013-11-03T09:48:53Z" + content=""" +Ah, the \"very complicated to get it to work\" part is what I didn't know, thanks for explaining and or the tips. +"""]] From b37f2fe296c985ec128a8254e594e7e226601654 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U" Date: Sun, 3 Nov 2013 09:49:17 +0000 Subject: [PATCH 02/18] Added a comment --- .../comment_3_01e6755a3c8c0e268e657e8992465d79._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment diff --git a/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment b/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment new file mode 100644 index 0000000000..b8b2316298 --- /dev/null +++ b/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U" + nickname="Carlo" + subject="comment 3" + date="2013-11-03T09:49:17Z" + content=""" +Ah, the \"very complicated to get it to work\" part is what I didn't know, thanks for explaining and or the tips. +"""]] From 36041523760f6f5e22d779229b9878f55a75053f Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U" Date: Sun, 3 Nov 2013 09:50:58 +0000 Subject: [PATCH 03/18] removed --- .../comment_3_01e6755a3c8c0e268e657e8992465d79._comment | 8 -------- 1 file changed, 8 deletions(-) delete mode 100644 doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment diff --git a/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment b/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment deleted file mode 100644 index b8b2316298..0000000000 --- a/doc/forum/Suggestion:_Put_ssh_server_back_into_android_version/comment_3_01e6755a3c8c0e268e657e8992465d79._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U" - nickname="Carlo" - subject="comment 3" - date="2013-11-03T09:49:17Z" - content=""" -Ah, the \"very complicated to get it to work\" part is what I didn't know, thanks for explaining and or the tips. -"""]] From ab65926f8eea55b98ae1d4034fa9d1435a2bf1f8 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" Date: Sun, 3 Nov 2013 11:24:28 +0000 Subject: [PATCH 04/18] Added a comment --- ...mment_5_4e193306801680bba433e75eb4dcba05._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/git-annex-shell:_gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment diff --git a/doc/bugs/git-annex-shell:_gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment b/doc/bugs/git-annex-shell:_gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment new file mode 100644 index 0000000000..137638aa5c --- /dev/null +++ b/doc/bugs/git-annex-shell:_gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" + nickname="Fabrice" + subject="comment 5" + date="2013-11-03T11:24:28Z" + content=""" +There is something very strange that I did not notice in my first report. When I try `git annex get --from encryptedrepo` nothing happens in the sense that git annex is not even trying to connect to the remote (no ssh connection attempt) while git.encryptedrepo.annex-gcrypt is set to true. When I set it to shell, nothing happens either. + +Another thing I did not report is that I tried the exact same manipulations with another server on which git annex is not installed. The `gcryptsetup permission denied` message was replaced by a `git-annex-shell not found` (or something similar), as expected. But the rest of the behavior was the same: no way to get the actual content with `git annex get --from`. Again, all of this is with 4.20131024, not with the ongoing version. + +I'll try got do more test with the new version. +"""]] From 5a24f1c044eae975d1712e1114916f68f6dd1ffe Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" Date: Sun, 3 Nov 2013 13:10:12 +0000 Subject: [PATCH 05/18] Added a comment --- .../comment_4_8724297f6d7ac140ab395a940bab0d7d._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment diff --git a/doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment b/doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment new file mode 100644 index 0000000000..983c35c3ab --- /dev/null +++ b/doc/forum/GPG_passphrase_handling/comment_4_8724297f6d7ac140ab395a940bab0d7d._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" + nickname="dxtrish" + subject="comment 4" + date="2013-11-03T13:10:11Z" + content=""" +I would have filed it in the bug section if I knew it was a bug. I just thought I had done something wrong :) +"""]] From b50debbd2652126547942a57e5e917e83212ec3e Mon Sep 17 00:00:00 2001 From: tanen Date: Sun, 3 Nov 2013 14:50:52 +0000 Subject: [PATCH 06/18] --- ..._change___34__deleted:_uuid.log__34__.mdwn | 42 +++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__.mdwn diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__.mdwn b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__.mdwn new file mode 100644 index 0000000000..ca8e765bc0 --- /dev/null +++ b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__.mdwn @@ -0,0 +1,42 @@ +### Please describe the problem. +Using the webapp to generate a new (local) repository instantly takes it to the following state: +[[!format sh """ +user@local:~/Annex$ git status +# On branch master +# Changes to be committed: +# (use "git reset HEAD ..." to unstage) +# +# deleted: uuid.log +# +user@local:~/Annex$ git branch + git-annex +* master +user@local:~/Annex$ git log +commit 90bfcaf17b0576d8ecdc48ae44dda22d41464acc +Author: local +Date: Sun Nov 3 15:30:17 2013 +0100 + + created repository +user@local:~/Annex$ git show HEAD +commit 90bfcaf17b0576d8ecdc48ae44dda22d41464acc +Author: local +Date: Sun Nov 3 15:30:17 2013 +0100 + + created repository + +diff --git a/uuid.log b/uuid.log +new file mode 100644 +index 0000000..9df3670 +--- /dev/null ++++ b/uuid.log +@@ -0,0 +1 @@ ++987e7b9a-aa9d-41db-ae92-23fcae7f6187 user@local:~/Annex timestamp=1383489017.181 +user@local:~/Annex$ +"""]] + +I'm new to git-annex, so I'm not quite sure, but looking at [[internals]] this file should only exist in the git-annex branch, not in master. Furthermore, from this state it seems impossible to get "sync with your other devices" to work, because of a merge conflict on this change. + +Perhaps some sort of a race-condition with the annex-assistant picking up the uuid.log file while the repository is being initialized? + +### What version of git-annex are you using? On what operating system? +Ubuntu 13.10 with git-annex 4.20130815 From c6b0272b1a13d75c42d87ffde494271d35d15fc4 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 3 Nov 2013 16:48:26 +0000 Subject: [PATCH 07/18] Added a comment --- ...comment_1_6441dd04adc158df22589c81746108a9._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment new file mode 100644 index 0000000000..6080e88e41 --- /dev/null +++ b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.47" + subject="comment 1" + date="2013-11-03T16:48:25Z" + content=""" +I can't reproduce this at all. What version of git do you have installed? Did you install git-annex from ubuntu's repository? Does the same thing happen if you install the standalone linux tarball and use it to make a new repository? + +git-annex never creates a file named uuid.log on disk, so it's quite strange that it shows up in the initial commit to the master branch. It sort of looks like somehow git-annex's normal use of a separate index file to stage the uuid.log to the git-annex branch is failing. Since I have never seen any problem with that, I have to suspect that the ubuntu build is somehow badly broken. Or that the git in Ubuntu is for some reason ignoring `GIT_INDEX_FILE`. +"""]] From df7ad73467d7895f8385948ecf8659e83f2b1396 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 3 Nov 2013 17:02:48 +0000 Subject: [PATCH 08/18] Added a comment --- ...mment_2_d1c5d7642284a375f9c455dbf76efa5c._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment new file mode 100644 index 0000000000..50bff5f41e --- /dev/null +++ b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.47" + subject="comment 2" + date="2013-11-03T17:02:47Z" + content=""" +I made an Ubuntu saucy chroot, apt-get installed git-annex from universe, and ran the webapp in there. I did not reproduce this problem. + +The cause of the problem, it seems, must be something local to your system. Perhaps you have an environment variable set that is messing up git. Or perhaps you have a different, broken version of git installed. + +Can you \"git show git-annex\" in the repository? It should show a commit made to the git-annex branch that adds the uuid.log there. +"""]] From e3b7682729ca15a54e15356c491b518387462a59 Mon Sep 17 00:00:00 2001 From: tanen Date: Sun, 3 Nov 2013 17:35:01 +0000 Subject: [PATCH 09/18] Added a comment --- ...ent_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment new file mode 100644 index 0000000000..7acab1c37f --- /dev/null +++ b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="tanen" + ip="83.128.159.25" + subject="comment 3" + date="2013-11-03T17:35:00Z" + content=""" +Very strange: this is on a machine that I wiped and reinstalled just a few hours ago, it's a completely fresh Ubuntu 13.10 install with barely anything installed but the defaults. Git version is 1.8.3.2-1 + +I initially just pulled git-annex from the Ubuntu repo. After that I grabbed a more recent version from https://launchpad.net/ubuntu/+source/git-annex/4.20131101/+build/5189754 which is showing the same behavior. + +\"git show git-annex\" indeed shows the commit creating the uuid.log file on the git-annex branch. master has just one commit, with description \"created repository\" and creates a \"uuid.log\" file. The contents of the master uuid.log are identical to the one in the git-annex branch. + +I'm currently in the middle of trying out a git-annex setup so I can't switch versions again right now, but given the above I imagine a fresh 13.10 VM should show the same behavior. +"""]] From b71738143d74ca5971af7c68d796e600db8db12b Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmTlfbCC37CAjhQrS107ZWRVA_sF4s3gLU" Date: Sun, 3 Nov 2013 19:18:06 +0000 Subject: [PATCH 10/18] --- ...lease_publish_new_releases_not_shorter_than_11_days.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn diff --git a/doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn new file mode 100644 index 0000000000..f67d2d797d --- /dev/null +++ b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days.mdwn @@ -0,0 +1,6 @@ +Hi, +i am following debian testing. The latest git-annex publication has manged to replace the former version on the last possible moment. Now another 10 days waiting. +Would be nice if you can coordinate with testing. + +Thank you for git-annex. +Jürgen From c49354b4bfeeeee3efcf707fa2206f460d712b55 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 3 Nov 2013 19:57:25 +0000 Subject: [PATCH 11/18] Added a comment --- .../comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment diff --git a/doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment new file mode 100644 index 0000000000..1fb259c98c --- /dev/null +++ b/doc/forum/Please_publish_new_releases_not_shorter_than_11_days/comment_1_da3d39de5be47ebe8b25a42ed1f36510._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.47" + subject="comment 1" + date="2013-11-03T19:57:24Z" + content=""" +I do coordinate with testing. That version had no possibility of ever reaching testing, since it failed to build on several architectures. +"""]] From d67480ad1981b2595e92c1339683d2a3679a78bd Mon Sep 17 00:00:00 2001 From: tanen Date: Sun, 3 Nov 2013 22:35:08 +0000 Subject: [PATCH 12/18] Added a comment --- ...4_f8a6e4415f4fe6da14f6a3b7334bc952._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment new file mode 100644 index 0000000000..9b1307df4c --- /dev/null +++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_4_f8a6e4415f4fe6da14f6a3b7334bc952._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="tanen" + ip="83.128.159.25" + subject="comment 4" + date="2013-11-03T22:35:07Z" + content=""" +The way I would want to setup git-annex (assistant) is \"Wuala/Spideroak style\": two computers with a full checkout of the repository, changes automatically being synced between them, even if the two computers are never online simultaneously, and encryption should be done locally: the (special) remote should not be able to view file listings or content. + +Do I understand it correctly that the gcrypt remote is the only way to make this happen? I tried to create such a setup via the webapp but failed. Adding the repository and remote (via \"Encrypt with GnuPG key\") on the first computer went OK*, but trying to enable that remote on the other computer fails: clicking enable asks me for the SSH password, but after that I just get redirected to a blank screen, with nothing to see in the logfile after the succesful call to ssh-keygen. No entry for the second computer is being added to authorized_keys on the remote. + +Perhaps this is because at this point the assistant is unable to actually parse the content of the encrypted repository? I tried importing the private key that was used while creating the repository on the other computer, but that made no difference. + +Thinking about this for a while, I believe gpg keys aren't actually particularly suited for this usecase. Even without the bug above, one would either have to awkwardly copy a private key to all hosts that are syncing to the repository; or, every time a new (or reinstalled) host wants to sync the repository, you would manually have to add the new keyid to the config and do the forced push + GCRYPT_FULL_REPACK, presumably having to reupload your entire history. Apart from this, having to backup a private key (outside of your git-annex based backups!) would be quite inconvenient. + +How would you feel about adding a new mode of operation where encryption is simply based on a passphrase? We could symetrically encrypt the repository with a keyfile that's stored in the repository itself, protecting the keyfile with a passphrase which - if stored at all - would be stored on the individual computers, outside of the repository. + +*although it erroneously used \"E0D2F776E7F674E3\" as key-id while the actual id is E7F674E3; where did that other half come from? +"""]] From 5e9021574f259420fec603423a31783566b81236 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU" Date: Mon, 4 Nov 2013 04:40:53 +0000 Subject: [PATCH 13/18] Added a comment --- ...comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment new file mode 100644 index 0000000000..8e767254c9 --- /dev/null +++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_5_11b8e82d2a234f65b58b823e71c6d6a2._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmNu4V5fvpLlBhaCUfXXOB0MI5NXwh8SkU" + nickname="Adam" + subject="comment 5" + date="2013-11-04T04:40:53Z" + content=""" +> How would you feel about adding a new mode of operation where encryption is simply based on a passphrase? We could symetrically encrypt the repository with a keyfile that's stored in the repository itself, protecting the keyfile with a passphrase which - if stored at all - would be stored on the individual computers, outside of the repository. + +Isn't that what the regular shared-encryption remote already does? Except it doesn't put a passphrase on the key, because anyone who has access to the local repo wouldn't need access to the remote one anyway. +"""]] From 88661c8e142a7f4017b006c95e55bd2c69235687 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" Date: Mon, 4 Nov 2013 07:39:22 +0000 Subject: [PATCH 14/18] Added a comment --- ...t_6_3e41948e1beffcf279bb05ef8e61cc07._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment new file mode 100644 index 0000000000..1a5d7f6e1c --- /dev/null +++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_6_3e41948e1beffcf279bb05ef8e61cc07._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" + nickname="Fabrice" + subject="comment 6" + date="2013-11-04T07:39:21Z" + content=""" +> _How would you feel about adding a new mode of operation where encryption is simply based on a passphrase? We could symetrically encrypt the repository with a keyfile that's stored in the repository itself, protecting the keyfile with a passphrase which - if stored at all - would be stored on the individual computers, outside of the repository._ + +As Adam wrote, without a passphrase, this is the shared encryption method. With an encrypted key, this is more or less the hybrid (default) scheme. The thing is that you have to share a secret to have a encrypted remote. I don't use the webapp, so I don't know what's happening in your case, but this is how it should work with the command line tools. First Alice create the encrypted remote with her pgp key. As far as I understand, git annex creates (via gpg) a key for a symmetric cypher which is stored in the repository, encrypted with Alice public key. If Alice wants to share the repository with Bob, she must either give a key pair (so the private key also, of course) to Bob or ask Bob for his public key. In the first case, Bob can clone the repository directly (upon reception of the key pair), while in the second case, Alice has to active Bob's public key (with `git annex enableremote myremote keyid+=bobsId`). In this case, again as far as I understand, the symmetric key is reencrypted for both Alice and Bob in the repo. + +I understand that you tried the first case with the webapp and that it did not work. I had a similar problem documented in this [http://git-annex.branchable.com/bugs/git-annex-shell:_gcryptsetup_permission_denied](bug). Maybe you could had some comments to this bug description? + +> _*although it erroneously used \"E0D2F776E7F674E3\" as key-id while the actual id is E7F674E3; where did that other half come from?_ + +This is the long id of your pgp key (16 characters as opposed to 8 for the short id). +"""]] From 90845210c7e58f19ef3931410f2fd203e06503b2 Mon Sep 17 00:00:00 2001 From: tanen Date: Mon, 4 Nov 2013 09:01:13 +0000 Subject: [PATCH 15/18] Added a comment --- ...t_7_4ce0b26b25b336f07b2e27246cdfba3e._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment new file mode 100644 index 0000000000..dfb2a3b92f --- /dev/null +++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_7_4ce0b26b25b336f07b2e27246cdfba3e._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="tanen" + ip="83.128.159.25" + subject="comment 7" + date="2013-11-04T09:01:13Z" + content=""" +Thanks for the responses. Please correct me if I'm wrong, but the way I understood it, using the shared encryption scheme creates a conflict between \"changes being synced between them, even if the two computers are never online simultaneously\" and \"encryption should be done locally: the (special) remote should not be able to view file listings or content.\" + +- If I use shared encryption \"the webapp way\", only the file contents will be rsynced to the remote, not the repository itself. This means that different hosts are unable to sync unless they are online simultaneously, so that commit data can be sent directly between them via XMPP. In practice, this would mean my hosts are never synced (because I don't keep my home computer running when I leave for work, and vice versa) + +- If I use shared encryption and additionally put the repository itself on a remote, that remote would have the keys to fully decrypt the repository, that's not acceptable. + +Reading through the docs again, the hybrid scheme actually seems to be closer to what I want than the shared scheme, but it still has a major downside: the encryption only applies to the files itself, so in order to get \"offline sync\" there still has to be a 'remote' for the repository itself, which will contain all your metadata unencrypted. And also it would depend on the user being able to manually setup and backup a set of gpg keys instead of just memorizing a secure passphrase. + +@Fabrice Looks like the bug you found could very well be the cause of the problem I had; I'll try it again when a new version is available. +"""]] From 5bc1136ee4970409bec7e73d03746900149930ae Mon Sep 17 00:00:00 2001 From: Rasmus Date: Mon, 4 Nov 2013 09:57:34 +0000 Subject: [PATCH 16/18] --- ...t_annex___39__corrupting__39___itself.mdwn | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/forum/Git_annex___39__corrupting__39___itself.mdwn diff --git a/doc/forum/Git_annex___39__corrupting__39___itself.mdwn b/doc/forum/Git_annex___39__corrupting__39___itself.mdwn new file mode 100644 index 0000000000..fe1edc17dc --- /dev/null +++ b/doc/forum/Git_annex___39__corrupting__39___itself.mdwn @@ -0,0 +1,34 @@ +Hi, + +Since the I updated to `2013-10-24` `git annex` has corrupted itself twice on my setup. I'm not claiming causality here and thus I haven't filled it as a bug (probably the mistake is mine). + +I use three laptops and one remote ssh server. The motherboard on laptop *T* seems to have broken and I haven't fixed it yet. I have disabled sync to *T* on the webapp dashboard. + +First, one computer, called *W*, broke on Friday. I got the dreaded [serious problem](http://git-annex.branchable.com/devblog/day_41__onward/) screen. `git fsck` reported lots of missing blobs and tree problem, though my data seemed OK. I git cloned the repo from computer *X*. Now, last night both X and W reported the same problem (log below). *W* recovered itself somehow, but *X* is now in a cycle of re-adding all files in the repo and the posting the below error that has to do with computer *T* (IP ending with 107). + +I would appreciate hints on why this suddenly started happen. Computer T has been out of sync for almost 14 days (since the 24th of October I think). + + error: refs/remotes/192.168.1.107_annex/git-annex does not point to a valid object! + error: refs/remotes/192.168.1.107_annex/master does not point to a valid object! + error: refs/remotes/192.168.1.107_annex/synced/git-annex does not point to a valid object! + error: refs/remotes/192.168.1.107_annex/synced/master does not point to a valid object! + error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object! + error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/git-annex does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/master does not point to a valid object! + error: refs/remotes/192.168.1.107_annex/git-annex does not point to a valid object! + error: refs/remotes/192.168.1.107_annex/master does not point to a valid object! + error: refs/remotes/192.168.1.107_annex/synced/git-annex does not point to a valid object! + error: refs/remotes/192.168.1.107_annex/synced/master does not point to a valid object! + error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object! + error: refs/synced/2ed58ecf-8e8c-44b8-ad34-d42ddfb35315/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/git-annex does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/cmFzbXVzQGNvZGVyb2xsZXJzLmNvbQ==/master does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/git-annex does not point to a valid object! + error: refs/synced/f54b8200-8ec1-43d2-8710-b73ec118addc/master does not point to a valid object! + error: invalid object 100644 1ca66de3cdd9c79cde26a7555cf3b8d26d0e371d for '000/147/SHA256E-s347--1ab8084bf9ae06407ce0a7260a83638ea6e9a028dc59b4815fd60aec61dbd747.txt.log.log' + fatal: git-write-tree: error building trees + TransferScanner crashed: failed to read sha from git write-tree + [2013-11-04 09:45:41 CET] TransferScanner: warning TransferScanner crashed: failed to read sha from git write-tree From f706c4ada814bf5a9fd84f27f3270a170dddb3cb Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" Date: Mon, 4 Nov 2013 10:31:56 +0000 Subject: [PATCH 17/18] Added a comment --- ...ent_8_49aa34d75d24a2066baa8a585bc9c2e9._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment new file mode 100644 index 0000000000..86f3f5cadc --- /dev/null +++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_8_49aa34d75d24a2066baa8a585bc9c2e9._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" + nickname="Fabrice" + subject="comment 8" + date="2013-11-04T10:31:56Z" + content=""" +I think you are (at least partially) right. Of course, the only way to sync completely computers that are not on together is to use either a usb drive or a third always on computer. (I've to confess I did not understand first when I read git annex docs, shame on me ;-) If you don't want to trust completely this computer (I don't, for instance), you must : + +* use an encrypted git repository on this computer; + +* and use either hybrid or pubkey encryption. + +But contrarily to what you seem to imply (I hope I understand you correctly), if you do that, the third computer can still figure out a few things (usage patterns, such as where connections come from), but that's all. You've got full sync and everything is encrypted, both the git part and the files handled by the annex. This applied only to encrypted git special remotes as other remotes do not store the git part. +"""]] From e8641876a23ba5e2de8c91627609464652d277d9 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8" Date: Mon, 4 Nov 2013 11:55:35 +0000 Subject: [PATCH 18/18] --- ...shlist:_encrypted_git_remote_on_hosting_site_from_webapp.mdwn | 1 + 1 file changed, 1 insertion(+) create mode 100644 doc/todo/wishlist:_encrypted_git_remote_on_hosting_site_from_webapp.mdwn diff --git a/doc/todo/wishlist:_encrypted_git_remote_on_hosting_site_from_webapp.mdwn b/doc/todo/wishlist:_encrypted_git_remote_on_hosting_site_from_webapp.mdwn new file mode 100644 index 0000000000..b7b1bad0c9 --- /dev/null +++ b/doc/todo/wishlist:_encrypted_git_remote_on_hosting_site_from_webapp.mdwn @@ -0,0 +1 @@ +It would be great to be able to do **private encrypted git remote on hosting site** and **multiuser encrypted git remote on hosting site** as explained in [[tips/fully encrypted git repositories with gcrypt]] through the webapp. I think it's a pretty common usecase that can be very useful for people not owning a proper server.