As I explained in my mail below, I have my doubt whether just a warning
is an adequate resolution to this bug. I haven't entirely made up my
mind though, because well, there is a warning and users sort of choose
for themselves, but still, currently I tend to think it's not a good
idea to allow *this* easily that users allow remote code execution.
What do you think about this?
--Jeroen
----- Forwarded message from Jeroen van Wolffelaar <[EMAIL PROTECTED]> -----
Date: Sat, 19 Aug 2006 13:16:54 +0200
From: Jeroen van Wolffelaar <[EMAIL PROTECTED]>
To: Robert Millan <[EMAIL PROTECTED]>, debian-gcc@lists.debian.org,
debian-release@lists.debian.org
Subject: Re: gcj and etch freeze
Message-ID: <[EMAIL PROTECTED]>
Resent-From: debian-release@lists.debian.org
List-Id: <debian-release.lists.debian.org>
On Sat, Aug 19, 2006 at 02:59:28AM -0700, Steve Langasek wrote:
> On Sat, Aug 19, 2006 at 11:42:03AM +0200, Robert Millan wrote:
> > > Last I knew, it still had
> > > serious security problems.
>
> > Which ones? I can't see anything in the BTS.
>
> I wouldn't know them by bug number; previously though, the problem was that
> gcjwebplugin didn't have appropriate sandboxing.
#267040: remote code execution hole due to lack of Java security manager
This is 'fixed' by:
- Shows warning before loading an applet (Closes: #267040, #301134)
Which, IMHO, doesn't make this usable except in fully trusted
environments where the browser is exclusively used to browse a fully
trusted intranet where nobody can change web content that doens't
already have root on your machine.
Which is, basicly nowhere (IMHO, and barring myself misunderstanding
something).
The warning is talked about here:
http://langel.wordpress.com/2006/06/05/gcjwebplugin-is-actually-worth-using/
(thanks Michael Koch for the link)
I personally do not think we should offer this option to users, because
users tend to trust sites easily (and they are too often asked about
'trusting' too, w.r.t. https websites, for example), even though the
wording used is strong, and the consequence is arbitrary remote code
execution.
Anyway, I will followup to the bug in question for discussion about this
issue.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----- End forwarded message -----
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
