From 0673b27e6d8547daa5ed062507358b78df439ac7 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Wed, 2 Mar 2011 01:00:01 -0500 Subject: 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(-) create mode 100644 proposals/ideas/old/xxx-auto-update.txt delete mode 100644 proposals/ideas/xxx-auto-update.txt (limited to 'proposals/ideas') 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. - -- cgit v1.2.3-54-g00ecf