On Sunday 14 December 2008 12:48, Ian Clarke wrote: > On Thu, Dec 11, 2008 at 8:16 PM, Zero3 <zero3 at zerosplayground.dk> wrote: > > That covers mine, toads and nextgens opinions. What do everyone else think? > > Here are my thoughts: > > Bundling > ---------- > I don't have a problem with bundling per-se provided we are judicious > about what gets bundled. In issues like this I think its instructive > to look at what other installers do and I think its pretty clear that > bundling dependencies is the norm, not the exception. > > That being said, I don't have a big problem with downloading > dependencies on-demand either. I don't think there is a big > difference in the user experience in either case. > > So I could live with either solution.
As I understand it, so could nextgens, as long as *the installers and the jars they contain are NOT BUILT ON EMU*. IMHO this isn't unreasonable, since they would only have to be rebuilt when we release a new stable build, I have to run a load of scripts at that point anyway. Am I misrepresenting/misunderstanding you nextgens? > > Building the installer automatically on emu > -------------------------------------------------- > The idea that a compromised Emu could lead to the compromising of tens > of thousands of Freenet users is very scary indeed. That being said, > this is a risk with any software that is downloaded from a web server > anywhere. Its more a bug in the lax security models of today's > operating systems, than in anything we are doing in particular. Sure, and this is part of the reason we create a separate user for Freenet on Windows, a policy that has caused much controversy. > > Again, I think we should look to the norm for other software, and the > norm is that automatic building of in-development software is pretty > common (Firefox, etc). IMHO it is important that we have on-commit compilation and deployment of new builds for testers. This does not necessarily have to run on emu; it is simplest to do it that way but it's not essential. Also, getting a notification when you commit something that doesn't compile is useful, but since we don't block the commit, this can also be done off emu if it improves our security. Whether it would in fact is an open question since any process running elsewhere would need to have enough rights to push the new jars to emu. However, stable builds can and should be held to a higher standard of security, hence for example auto-updates are inserted manually and the updater private key isn't kept on emu. > > Ian. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081215/b7e27f8f/attachment.pgp>
