[tor-commits] [torspec/master] Move xxx-auto-update.txt to ideas/old: Thandy superseded it.

[nickm at torproject.org]

commit 0673b27e6d8547daa5ed062507358b78df439ac7
Author: Nick Mathewson <nickm at torproject.org>
Date:   Wed Mar 2 01:00:01 2011 -0500

    Move xxx-auto-update.txt to ideas/old: Thandy superseded it.
---
 proposals/ideas/old/xxx-auto-update.txt |   39 +++++++++++++++++++++++++++++++
 proposals/ideas/xxx-auto-update.txt     |   39 -------------------------------
 2 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/proposals/ideas/old/xxx-auto-update.txt b/proposals/ideas/old/xxx-auto-update.txt
new file mode 100644
index 0000000..dc9a857
--- /dev/null
+++ b/proposals/ideas/old/xxx-auto-update.txt
@@ -0,0 +1,39 @@
+
+Notes on an auto updater:
+
+steve wants a "latest" symlink so he can always just fetch that.
+
+roger worries that this will exacerbate the "what version are you
+using?" "latest." problem.
+
+weasel suggests putting the latest recommended version in dns. then
+we don't have to hit the website. it's got caching, it's lightweight,
+it scales. just put it in a TXT record or something.
+
+but, no dnssec.
+
+roger suggests a file on the https website that lists the latest
+recommended version (or filename or url or something like that).
+
+(steve seems to already be doing this with xerobank. he additionally
+suggests a little blurb that can be displayed to the user to describe
+what's new.)
+
+how to verify you're getting the right file?
+a) it's https.
+b) ship with a signing key, and use some openssl functions to verify.
+c) both
+
+andrew reminds us that we have a "recommended versions" line in the
+consensus directory already.
+
+if only we had some way to point out the "latest stable recommendation"
+from this list. we could list it first, or something.
+
+the recommended versions line also doesn't take into account which
+packages are available -- e.g. on Windows one version might be the best
+available, and on OS X it might be a different one.
+
+aren't there existing solutions to this? surely there is a beautiful,
+efficient, crypto-correct auto updater lib out there. even for windows.
+
diff --git a/proposals/ideas/xxx-auto-update.txt b/proposals/ideas/xxx-auto-update.txt
deleted file mode 100644
index dc9a857..0000000
--- a/proposals/ideas/xxx-auto-update.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-
-Notes on an auto updater:
-
-steve wants a "latest" symlink so he can always just fetch that.
-
-roger worries that this will exacerbate the "what version are you
-using?" "latest." problem.
-
-weasel suggests putting the latest recommended version in dns. then
-we don't have to hit the website. it's got caching, it's lightweight,
-it scales. just put it in a TXT record or something.
-
-but, no dnssec.
-
-roger suggests a file on the https website that lists the latest
-recommended version (or filename or url or something like that).
-
-(steve seems to already be doing this with xerobank. he additionally
-suggests a little blurb that can be displayed to the user to describe
-what's new.)
-
-how to verify you're getting the right file?
-a) it's https.
-b) ship with a signing key, and use some openssl functions to verify.
-c) both
-
-andrew reminds us that we have a "recommended versions" line in the
-consensus directory already.
-
-if only we had some way to point out the "latest stable recommendation"
-from this list. we could list it first, or something.
-
-the recommended versions line also doesn't take into account which
-packages are available -- e.g. on Windows one version might be the best
-available, and on OS X it might be a different one.
-
-aren't there existing solutions to this? surely there is a beautiful,
-efficient, crypto-correct auto updater lib out there. even for windows.
-