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. Memory issues aside, 1.5 definetely *is* faster at least in Swing applets. 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 ;) > 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.) > 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 :( > 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 :) > > 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 :) > 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. --snip-- > NextGen$. > PS: btw, you have commit access on svn, feel free to change it ;) > (directory /trunk/website) I thought it might be more diplomatic to debate it first ... I'm at work anyway :) Bob
