Thanks for your reply, Alex. :) On 21/01/2007, at 7:27 PM, Alex Thurgood wrote:
Yes, I agree, the absence of visible, and regularly updated security information does look bad, and the fact that there was almost nothing about the latest security fixes is worrying as far as I'm concerned.On the other hand, this bug is in the JRE and not OOo, even if we supply the JRE bundled, so I would also agree that this is not really our problem. OOo can run without the JRE (albeit with limited functionality), but it does not depend on the JRE for importing/exporting GIF format images (at least not to my knowledge, I believe these filters are still C++ coded). I feel it would be difficult and probably even impossible to post security warnings about every potential flaw in connected software that could interact with OOo. How would one approach, say, the discovery of a flaw in python, that could be abused to attack OOo ? (not talking about a flaw in the pyuno bridge, here). Or Delphi ? I'm still of the opinion that we must be more visible and responsive to our own flaws first, before we can even dream about issuing notices of security problems in connected software programs.Just my 2cents, but an interesting discussion all the same.
It is. I think we can usually ask ourselves: what is likely to alarm our users? They are certainly aware of the presence of Java in OpenOffice.org, so it would be a good idea to address any Java issues, at least to post a link about them on the security page that takes users to the Java (or other) site with information about the issue.
I recommend in general that the security site should address any issues directly related to OpenOffice.org, and should post links to others, in a section labelled, for example, "Security issues in external software".
A page with nothing on it about current issues is not going to reassure our users.
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do)
http://groups-beta.google.com/group/vi-VN
PGP.sig
Description: This is a digitally signed message part
