* Bob <bob_j_hayes at yahoo.co.uk> [2005-12-15 13:06:31]: > NextGen$ <nextgens at ...> writes: > > > * Bob <bob_j_hayes at ...> [2005-12-15 11:14:37]: > --snip-- > > > there were recently 3 new applet privellege escalation vulnerabilities > > > publicised affecting everything less than 1.5.0 update 3. > > > Link multilined for stupid gmane filter : > > > http://searchsecurity.techtarget.com/originalContent/ > > > 0,289142,sid14_gci1148505,00.html > > > > > > I can confirm that the current 0.5 still runs OK on 1.4.1 since I have to > > > use > > > that version of blackdown on Sparc Linux :) but I suggest we should > > > recommend > > > the latest 1.5 / 5.0 to windows users in light of the above. > > > > I don't agree :p > > Memory management has changed between 1.4 and 1.5 ... many users will > > see their scripts/performances tweaks broken after updating ... > > I agree that it would be simpler to support only the latest sun's jvm, > > but I don't think that's the way to go ;) > > Oh I know all about 1.5's memory hoarding, believe me :) I've been developing > an applet which has to do numerous silly things to conserve every precious > byte > it can otherwise the lazy JVM uses over 96% of the heap before it bothers to > do any gc ... working heap is then so low it stalls for ages. They should at > least have increased the default max heap size from the miserly 96MB if > they're going to do that kind of "optimisation". Use of the forbidden, > deprecated, never-do-this-no-really explicit System.gc() at strategic points > produces measurable improvements too, make of that what you will. >
Such a hack aren't a long-term solution :) > Memory issues aside, 1.5 definetely *is* faster at least in Swing applets. I can't see where we are using swing in the code ;) > Anyway, I'm not arguing for a 1.5 recommendation for performance reasons but > for security. I think I can say without fear of contradiction that anyone > using 0.5 must care more about the latter than the former ;) > ok :) I had misunderstood your point. > > And the main point is : Do you have anything prooving that freenet is > > performing better on 1.5 than on 1.4 ? No ? well so let Sun deal with > > their jvm's security matters ... > > Umm, we have a duty to the users to not lead to them getting hacked. I would > be > very suprised if spyware installers etc weren't already in the wild for these > vulnerabilities. Security is important, especially given that freenet is > supposed to be a secure anonymity service. Sun *have* dealt with these > vulnerabilities, but if users have old 1.4 JVM's they may never know it, that > would be partly OUR fault, and the user could rightly blame us. (AFAIK > 1.4.2_09 > is the first one that does systray update nagging.) > :/ Anyway, using a closed source JVM... yes, I get it, beeing up to date prevents worms :) > > As far as I know, freenet runs on 1.4 > > and it's advertised as such :p > > Yes it does, on 1.4.1 blackdown at least (mentioned above). That's as low as > you can go I believe, due to NIO bugs in earlier versions. It would be nice if > Sun backported these fixes to 1.4.2 but it appears they're not going to :( > .7 Will run on "free" jvms : I'll start a new thread soon about it... > > Is there any need to switch to 1.5 ? As > > far as the current buildscript goes, the precompiled version of freenet > > isn't using 1.5 improvements (target=1.4 in build.xml)... > > > > But if their is *really* a gain, we can change that for sure :) > > Our users not getting hacked is a pretty major "gain" in my book ... > > If you really want a performance improvement, 1.4.x still appears to suffer > from the SelectorLoop problem sometimes, even with the workarounds in fred, > which causes severe performance loss / crashes. There are many bugs in > various 1.4 versions too e.g. apparently impossible to get query part of > URL's, > getDocumentBase() and getCodeBase() do the opposite of what javadoc says and > don't even do it properly, AWT/Swing z-fighting repaint issues ... I could go > on :) agreed for the SelectorLoop problem ... but I've never seen the workaround crashing... Other stuffs aren't used in the curent code ;) > > > > All recent windows JVMs have a systray app which autoupdates aggressively, > > > even to beta versions(!) provided the user OK's it, therefore recommending > > > a recent version should save us from future issues like this. > > > > And ? will the next step be decaprate 1.4 support as 70% of freenet's > > users are using the default installer wich is settuping a 1.5 JVM ? > > I'm not proposing anything like that, such things are a matter for the fred > contributors. Which I'm not good enough to become one of anytime soon :) > As I've just said, I misunderstood your point :) > > We could as well report with Fred that the jvm might be vulnerable > > to security matters if version is < latest. > > I suppose there could be something like that, it amounts to the same thing > though : recommending secure versions. It's easier to get it out of the way > before they even install than expecting them to upgrade immediately > afterwards. > agreed I haven't run any JVM on windows since to long to have the right to express my PoV, If you would like to change the "recommanded" JVM on the windows part of the download page, feel free to do it, but please, add that Freenet can still run on 1.4 somewhere else (on the *NIX part for example ^-^). --snip-- NextGen$.
