On 11/14/2014 07:18 PM, Matthew Toseland wrote: > On 14/11/14 03:51, Steve Dougherty wrote: >> On Nov 5, 2014 7:04 AM, "Matthew Toseland" <mj...@cam.ac.uk> wrote: >>> On 05/11/14 04:37, Steve Dougherty wrote: ... >>>> Also update.sh|cmd contain what are effectively shell / batch script >>>> reimplementations of parts of the Node updater. Would anyone be >>>> interested in breaking out the deployment part so that both scripts can >>>> call the node jar with a main class that will fetch over HTTPS, then >>>> deployment proceeds as usual? Verification is currently sha1; is knowing >>>> the key alone (like from dependencies.properties) enough to know the >>>> file's checksum? If we switch to verify signatures how should we ship >>>> keys? >>> IMHO update.sh / update.cmd should work even if e.g. we have somehow >>> managed to corrupt the node jar, e.g. it's 0 bytes long, wrapper.conf is >>> broken, etc. They are supposed to be for last-resort recovery, so users >>> don't need to reinstall. >> Unless we suspect that there are either updater bugs or common system >> failures that lead to zero-byte jars, I'm not convinced it's worth the >> additional maintenance burden and additional opportunities to introduce >> bugs. If we move the updater into the jar it could repair the >> wrapper.conf when invoked from a script. (or directly) > This has happened lots of times before. IMHO it is common, and being > able to recover without doing a full reinstall is a useful feature, > especially if we want people to use darknet.
I have not been able to find bugs filed about this. Do you have anything that might be useful in reproducing the problem?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
