summaryrefslogtreecommitdiff
path: root/doc/devblog/day_387__release_day
diff options
context:
space:
mode:
Diffstat (limited to 'doc/devblog/day_387__release_day')
-rw-r--r--doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment15
1 files changed, 15 insertions, 0 deletions
diff --git a/doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment b/doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment
new file mode 100644
index 000000000..19492995a
--- /dev/null
+++ b/doc/devblog/day_387__release_day/comment_2_86262439c9056c0e06623cdf79eaf9a6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-03T17:56:44Z"
+ content="""
+The exposed information is not stored in the remote. If it's stored
+anywhere, it would be in a server log, which might log an attempt
+to access an un-encrypted key filename (which typically includes the
+checksum and maybe the file's extension).
+
+So on the one hand, you don't need to do anything other than upgrade
+git-annex to recover from the problem. On the other hand, if the potential
+that a un-encrypted filename of a git-annex key having leaked into a server
+log somewhere is a problem, I don't have a solution to the problem. :-/
+"""]]