summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment9
1 files changed, 9 insertions, 0 deletions
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment
new file mode 100644
index 000000000..7629d45df
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/comment_8_39139e25175ae265a4dc15f0b6b7b618._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pot"
+ subject="Hmmm, seems odd such a serious bug is allowed to linger without serious investigation"
+ date="2016-08-09T19:22:48Z"
+ content="""
+Should a developer not be all over this, would seem like a very major issue with the gcrypt backend (and annex's interaction with it) that this outcome could even be possible. You can't be using an encrypted store, which becomes irrepairably corrupted and with some of your data sat outside, unencrypted!
+
+Any thoughts from more knowledgeable developers on how to fix, investigate further, or do something useful on this front?
+"""]]