summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar http://joeyh.name/ <http://joeyh.name/@web>2014-09-18 19:28:56 +0000
committerGravatar admin <admin@branchable.com>2014-09-18 19:28:56 +0000
commitdd67dc6bb568f471a3c61017b0f0151f3f473178 (patch)
treeda1c0a1a06e3e6ce28aad2c0b8255fc3436c7eaa
parent70adc6588d4a6375b45783165b098b191cf8654e (diff)
Added a comment
-rw-r--r--doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment10
1 files changed, 10 insertions, 0 deletions
diff --git a/doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment b/doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment
new file mode 100644
index 000000000..d230e52aa
--- /dev/null
+++ b/doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T19:28:56Z"
+ content="""
+Ok, I managed to reproduce this. In my case, there was no \"Bad creds\" message because the broken creds data it used happened to contain a newline, but same problem; the creds stored by the webapp are not used properly when re-enabling the box.com remote elsewhere. Same problem would affect other special remotes using embedded creds and shared encryption.
+
+Seems to be a bug introduced in [[!commit fbdeeeed5fa276d94be587c8916d725eddcaf546]]. Despite what the commit says, the embedded creds did get encrypted with the shared gpg key. I have reverted that commit to fix this problem.
+"""]]