On 11/26/06, coderman <[EMAIL PROTECTED]> wrote:
... why the focus on automatic updates? [we thought we'd need these at one point, but really, it opened up more problems than it solved. additional care before releases has proved sufficient]
i am referring to the developers of janusvm, NOT Tor, since this paragraph is confusing. the first few versions included an update check that used a hard coded hostname in /etc/hosts (to prevent DNS latency/DoS) to retrieve via http a file that contained an sha256 digest associated with the current release or update. each build included an sha256 id associated with the current version. if the version stored on the vm file system at boot and the version obtained online were different this was assumed to indicate a new release was available. a gpg public key used for signing updates was also bundled with the vm image, and the update process would obtain two more files $id.tgz and $id.tgz.asc which contained the patch and its signature, respectively. the $id.tgz was digested and if the sha256 sum of the downloaded update did not match the sum obtained in the current.id http request, the update aborted with prejudice. if the digests matched, gpg was then used to verify the $id.tgz.asc signature associated with the downloaded update. if this failed, also abort. if all validations passed, the update was applied to the vm file system and the init process continued to start as expected, but now with the updates applied. --- in short, we thought this might be needed to push critical updates or config changes for Tor or other applications / utils on the vm. it turned out this kind of urgent / critical update was never needed, and various organizations who started blocking our update server IP address ended up causing longer startup times due to the http timeout required before continuing past the update check. not to mention the scalability concerns of doing this for anything more than a small number of clients. best regards,
