Debian Bug report logs - #267040
remote code execution hole due to lack of Java security manager

version graph

Package: gcjwebplugin; Maintainer for gcjwebplugin is (unknown);

Reported by: Phil Endecott <spam-from-debian-bugs@chezphil.org>

Date: Fri, 20 Aug 2004 11:18:03 UTC

Severity: critical

Tags: security

Merged with 301134

Found in versions 0.3.0-1, 0.3.1-2, classpath/2:0.91+cvs20060611-1

Fixed in versions classpath/2:0.97.2-1.1, classpath/2:0.97.1-5+lenny1

Done: Ben Hutchings <ben@decadent.org.uk>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Michael Koch <konqueror@gmx.de>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Phil Endecott <spam-from-debian-bugs@chezphil.org>:
New Bug report received and forwarded. Copy sent to Michael Koch <konqueror@gmx.de>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Phil Endecott <spam-from-debian-bugs@chezphil.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: gcjwebplugin: Should include "UNRESTRICTED access to your computer" warning somewhere
Date: Fri, 20 Aug 2004 12:09:53 +0100
Package: gcjwebplugin
Version: 0.3.0-1
Severity: normal
Tags: security

The gcjwebplugin web page (http://www.nongnu.org/gcjwebplugin/) has the
following very prominent warning:

WARNING:
The current version does not provide a security manager capable of 
handling Java (tm) applets. Applets have UNRESTRICTED access to your 
computer. This means they can do anything you can do, like deleting all 
your important data. 

Does this apply to the Debian package?  Assuming that it does, I feel 
that a similar warning should be shown.  It could be included in the 
Description, but I think that something even more prominent is justified 
considering the seriousness of the problem.  For example, there could be 
a high-priority debconf question saying "A malicious web page could 
trash your system, are you sure you want to install this?".

Regards,  --Phil.



-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.3-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8

Versions of packages gcjwebplugin depends on:
ii  libc6                    2.3.2.ds1-11    GNU C Library: Shared libraries an
ii  libgcc1                  1:3.4.1-4sarge1 GCC support library
ii  libglib2.0-0             2.4.2-1         The GLib library of C routines
ii  libstdc++5               1:3.3.4-2       The GNU Standard C++ Library v3
ii  sablevm                  1.1.6-2         Free implementation of Java Virtua

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Michael Koch <konqueror@gmx.de>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to Michael Koch <konqueror@gmx.de>. Full text and rfc822 format available.

Message #10 received at 267040@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Phil Endecott <spam-from-debian-bugs@chezphil.org>, 267040@bugs.debian.org
Subject: Re: Bug#267040: gcjwebplugin: Should include "UNRESTRICTED access to your computer" warning somewhere
Date: Fri, 20 Aug 2004 06:25:04 -0700
severity 267040 grave
thanks

On Fri, Aug 20, 2004 at 12:09:53PM +0100, Phil Endecott wrote:
> Package: gcjwebplugin
> Version: 0.3.0-1
> Severity: normal
> Tags: security
> 
> The gcjwebplugin web page (http://www.nongnu.org/gcjwebplugin/) has the
> following very prominent warning:
> 
> WARNING:
> The current version does not provide a security manager capable of 
> handling Java (tm) applets. Applets have UNRESTRICTED access to your 
> computer. This means they can do anything you can do, like deleting all 
> your important data. 

I'm increasing the severity of this bug accordingly.  Furthermore, if this
package is still under development and not ready for widespread use (this
seems to be the case from this warning), then it should not be included in a
Debian stable release.  Indeed, I would suggest that it be moved from
unstable to experimental until this issue is corrected.

-- 
 - mdz



Severity set to `grave'. Request was from Matt Zimmerman <mdz@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Michael Koch <konqueror@gmx.de>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #17 received at 267040@bugs.debian.org (full text, mbox):

From: Michael Koch <konqueror@gmx.de>
To: 267040@bugs.debian.org
Subject: gcjwebplugin: Should include "UNRESTRICTED access to your computer" warning somewhere
Date: Sun, 29 Aug 2004 22:02:02 +0200
Hi,


sorry for not answering sooner. The plan is not to let gcjwebplugin into 
testing corrently as libgcj is not fully security audited yet. Thats 
the main missing thing. The idea to add this warning is already 
implemented on my local disk. Just neither added to gcjwebplugin cvs or 
a release, nor added to the debian package yet.

The main reason to upload to unstable and not to experimental was to 
make sure it builds on all Debian archs and more people can actually 
test it. Most build issues are solved now, others are not.



Michael



Information forwarded to debian-bugs-dist@lists.debian.org, Michael Koch <konqueror@gmx.de>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Phil Endecott <phil_ehkji_endecott@chezphil.org>:
Extra info received and forwarded to list. Copy sent to Michael Koch <konqueror@gmx.de>. Full text and rfc822 format available.

Message #22 received at 267040@bugs.debian.org (full text, mbox):

From: Phil Endecott <phil_ehkji_endecott@chezphil.org>
To: 267040@bugs.debian.org
Cc: mdz@alcor.net
Subject: Huge security void still present in gcjwebplugin
Date: Sun, 19 Dec 2004 00:23:20 +0000
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267040

It's now 120 days since I reported the security problem with 
gcjwebplugin: according to its own web page 
(http://www.nongnu.org/gcjwebplugin/) it has nothing to prevent applets 
from trashing your computer, yet the Debian package doesn't even have a 
warning in its description or installation script.

I can't think of any other package that could leave a user's system so 
vulnerable.  This is a serious security problem.  I think that this 
package ought to be removed to experimental (to me, "unstable" does not 
imply "huge known security holes"), and warnings added to the 
description and installation scripts immediately, and a warning should 
be posted to debian-security-announce advising people to remove the package.

Regards,

Phil Endecott.








Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Michael Koch <konqueror@gmx.de>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #27 received at 267040@bugs.debian.org (full text, mbox):

From: Michael Koch <konqueror@gmx.de>
To: Phil Endecott <phil_ehkji_endecott@chezphil.org>, 267040@bugs.debian.org
Cc: mdz@alcor.net
Subject: Re: Bug#267040: Huge security void still present in gcjwebplugin
Date: Sun, 19 Dec 2004 09:39:55 +0100
Am Sonntag, 19. Dezember 2004 01:23 schrieb Phil Endecott:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267040
>
> It's now 120 days since I reported the security problem with
> gcjwebplugin: according to its own web page
> (http://www.nongnu.org/gcjwebplugin/) it has nothing to prevent
> applets from trashing your computer, yet the Debian package doesn't
> even have a warning in its description or installation script.

I will rework this.

> I can't think of any other package that could leave a user's system
> so vulnerable.  This is a serious security problem.  I think that
> this package ought to be removed to experimental (to me, "unstable"
> does not imply "huge known security holes"), and warnings added to
> the description and installation scripts immediately, and a warning
> should be posted to debian-security-announce advising people to
> remove the package.

The main problem is that the underlying packages, libgcj in this case, 
are not guaranteed to be secure. There is stuff to support security 
but no one has ever done a security audit. Its not gcjwebplugin's 
fault to be insecure, it just exposes this insecurity. Most apps 
using libgcj done need the security features either.

libgcj is part of GCC. Would you suggest moving GCC to experimental 
only ? 


Michael
-- 
Homepage: http://www.worldforge.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Michael Koch <konqueror@gmx.de>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Phil Endecott <phil_ehkji_endecott@chezphil.org>:
Extra info received and forwarded to list. Copy sent to Michael Koch <konqueror@gmx.de>. Full text and rfc822 format available.

Message #32 received at 267040@bugs.debian.org (full text, mbox):

From: Phil Endecott <phil_ehkji_endecott@chezphil.org>
To: Michael Koch <konqueror@gmx.de>, 267040@bugs.debian.org
Cc: mdz@alcor.net
Subject: Re: Bug#267040: Huge security void still present in gcjwebplugin
Date: Sun, 19 Dec 2004 16:30:25 +0000
>>I can't think of any other package that could leave a user's system
>>so vulnerable.  This is a serious security problem.  I think that
>>this package ought to be removed to experimental (to me, "unstable"
>>does not imply "huge known security holes"), and warnings added to
>>the description and installation scripts immediately, and a warning
>>should be posted to debian-security-announce advising people to
>>remove the package.
> 
> The main problem is that the underlying packages, libgcj in this case, 
> are not guaranteed to be secure. There is stuff to support security 
> but no one has ever done a security audit. Its not gcjwebplugin's 
> fault to be insecure, it just exposes this insecurity. Most apps 
> using libgcj done need the security features either.
> 
> libgcj is part of GCC. Would you suggest moving GCC to experimental 
> only ? 

No.  There is a crucial difference between gcc (including its java 
compiler) and this plugin, and that's that this plugin runs inside web 
browsers.  Web browsers, along with other applications that interface 
with the potentially dangerous "outside world", need to be more secure 
that other categories of applications.  When using g++ or gcj from the 
command line I will only compile and run code that I have some trust in. 
 On the other hand, when visiting web pages I expect to be protected 
from malicious code that they might contain.

--Phil









Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Michael Koch <konqueror@gmx.de>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #37 received at 267040@bugs.debian.org (full text, mbox):

From: Michael Koch <konqueror@gmx.de>
To: Phil Endecott <phil_ehkji_endecott@chezphil.org>
Cc: 267040@bugs.debian.org, mdz@alcor.net
Subject: Re: Bug#267040: Huge security void still present in gcjwebplugin
Date: Sun, 19 Dec 2004 17:43:46 +0100
Am Sonntag, 19. Dezember 2004 17:30 schrieb Phil Endecott:
> >>I can't think of any other package that could leave a user's
> >> system so vulnerable.  This is a serious security problem.  I
> >> think that this package ought to be removed to experimental (to
> >> me, "unstable" does not imply "huge known security holes"), and
> >> warnings added to the description and installation scripts
> >> immediately, and a warning should be posted to
> >> debian-security-announce advising people to remove the package.
> >
> > The main problem is that the underlying packages, libgcj in this
> > case, are not guaranteed to be secure. There is stuff to support
> > security but no one has ever done a security audit. Its not
> > gcjwebplugin's fault to be insecure, it just exposes this
> > insecurity. Most apps using libgcj done need the security
> > features either.
> >
> > libgcj is part of GCC. Would you suggest moving GCC to
> > experimental only ?
>
> No.  There is a crucial difference between gcc (including its java
> compiler) and this plugin, and that's that this plugin runs inside
> web browsers.  Web browsers, along with other applications that
> interface with the potentially dangerous "outside world", need to
> be more secure that other categories of applications.  When using
> g++ or gcj from the command line I will only compile and run code
> that I have some trust in. On the other hand, when visiting web
> pages I expect to be protected from malicious code that they might
> contain.

gcjwebplugin is not limited to be used inside web browsers. It can be 
used standalone.

I have a patch to show a warning before each applet gets started. 
Would you be okay with this ?


Michael
-- 
Homepage: http://www.worldforge.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Michael Koch <konqueror@gmx.de>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Justin Pryzby <justinpryzby@users.sourceforge.net>:
Extra info received and forwarded to list. Copy sent to Michael Koch <konqueror@gmx.de>. Full text and rfc822 format available.

Message #42 received at 267040@bugs.debian.org (full text, mbox):

From: Justin Pryzby <justinpryzby@users.sourceforge.net>
To: 267040@bugs.debian.org
Subject: security
Date: Fri, 21 Jan 2005 15:49:49 -0500
Showing a warning before running each applet is a good idea.  Using
debconf to display a warning is a bad idea, because only the
administrator will see it ("debconf is/was never mean for such
things").

Justin



Merged 267040 301134. Request was from Petter Reinholdtsen <pere@hungry.com> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Piotr Engelking <inkerman42@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `critical'. Request was from Piotr Engelking <inkerman42@gmail.com> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: pending Request was from Michael Koch <konqueror@gmx.de> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: pending Request was from Michael Koch <konqueror@gmx.de> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: fixed-in-experimental Request was from Michael Koch <konqueror@gmx.de> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: fixed-in-experimental Request was from Michael Koch <konqueror@gmx.de> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Michael Koch <konqueror@gmx.de>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Michael Koch <konqueror@gmx.de>. Full text and rfc822 format available.

Message #61 received at 267040@bugs.debian.org (full text, mbox):

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: 267040@bugs.debian.org
Cc: Michael Koch <konqueror@gmx.de>
Subject: Bug#267040: Is a warning really adequate?
Date: Sat, 19 Aug 2006 16:36:42 +0200
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 <jeroen@wolffelaar.nl> -----

Date: Sat, 19 Aug 2006 13:16:54 +0200
From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: Robert Millan <rmh@aybabtu.com>, debian-gcc@lists.debian.org,
	debian-release@lists.debian.org
Subject: Re: gcj and etch freeze
Message-ID: <20060819111654.GB22092@A-Eskwadraat.nl>
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
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to debian-release-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



----- End forwarded message -----

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Reply sent to Michael Koch <konqueror@gmx.de>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Phil Endecott <spam-from-debian-bugs@chezphil.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #66 received at 267040-close@bugs.debian.org (full text, mbox):

From: Michael Koch <konqueror@gmx.de>
To: 267040-close@bugs.debian.org
Subject: Bug#267040: fixed in classpath 2:0.92-1
Date: Sun, 10 Sep 2006 04:52:05 -0700
Source: classpath
Source-Version: 2:0.92-1

We believe that the bug you reported is fixed in the latest version of
classpath, which is due to be installed in the Debian FTP archive:

classpath-common-unzipped_0.92-1_all.deb
  to pool/main/c/classpath/classpath-common-unzipped_0.92-1_all.deb
classpath-common_0.92-1_all.deb
  to pool/main/c/classpath/classpath-common_0.92-1_all.deb
classpath-doc_0.92-1_all.deb
  to pool/main/c/classpath/classpath-doc_0.92-1_all.deb
classpath-gtkpeer_0.92-1_i386.deb
  to pool/main/c/classpath/classpath-gtkpeer_0.92-1_i386.deb
classpath-qtpeer_0.92-1_i386.deb
  to pool/main/c/classpath/classpath-qtpeer_0.92-1_i386.deb
classpath_0.92-1.diff.gz
  to pool/main/c/classpath/classpath_0.92-1.diff.gz
classpath_0.92-1.dsc
  to pool/main/c/classpath/classpath_0.92-1.dsc
classpath_0.92-1_i386.deb
  to pool/main/c/classpath/classpath_0.92-1_i386.deb
classpath_0.92.orig.tar.gz
  to pool/main/c/classpath/classpath_0.92.orig.tar.gz
gcjwebplugin_0.92-1_i386.deb
  to pool/main/c/classpath/gcjwebplugin_0.92-1_i386.deb
jikes-classpath_0.92-1_all.deb
  to pool/main/c/classpath/jikes-classpath_0.92-1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 267040@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Koch <konqueror@gmx.de> (supplier of updated classpath package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat,  9 Sep 2006 07:39:01 +0000
Source: classpath
Binary: classpath-qtpeer classpath-gtkpeer gcjwebplugin classpath-doc classpath-common-unzipped classpath-common classpath jikes-classpath
Architecture: source all i386
Version: 2:0.92-1
Distribution: unstable
Urgency: low
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Michael Koch <konqueror@gmx.de>
Description: 
 classpath  - clean room standard Java libraries
 classpath-common - clean room standard Java libraries - architecture independent fil
 classpath-common-unzipped - clean room standard Java libraries - architecture independent fil
 classpath-doc - clean room standard Java libraries - free Java API documentation
 classpath-gtkpeer - clean room standard Java libraries - GTK AWT peer
 classpath-qtpeer - clean room standard Java libraries - QT AWT peer
 gcjwebplugin - web browser plugin to execute Java (tm) applets
 jikes-classpath - clean room standard Java libraries - wrapper for jikes
Closes: 266906 267040 275245 290498 301134 336773 351518 357830 359654 369979 372851 373791 384354 385369
Changes: 
 classpath (2:0.92-1) unstable; urgency=low
 .
   * New upstream release (Closes: #385369, #384354).
     - Adjusted debian/patches/10_appletviewer.dpatch to patch gappletviewer.
   * debian/control: Don't Build-Depends on cdbs.
 .
 classpath (2:0.91+cvs20060611-2) experimental; urgency=low
 .
   * Honors disabled Java setting in Firefox (Closes: #266906).
   * debian/control: Moved gcjwebplugin to Section: net.
   * debian/control: Don't Build-Depends on sound dependencies on kfreebsd-i386,
     kfreebsd-amd64 and hurd-i386.
   * debian/rules: Enable sound support only on linux (Closes: #372851).
   * debian/README.Debian: Removed description for enabling Graphics2D support.
     It's used by default now.
   * debian/control: Build-Depends on libxul-dev (Closes: #373791).
 .
 classpath (2:0.91+cvs20060611-1) experimental; urgency=low
 .
   * New upstream release
     - Shows warning before loading an applet (Closes: #267040, #301134).
     - New package Depends on jamvm or cacao (Closes: #369979).
     - Crashes with Firefox are not reproducable anymore
       (Closes: #290498, #336773).
     - Starts up with Firefox (Closes: #275245).
     - Fixes NullPointerException during applet loading (Closes: #351518).
     - Fixes deadlock in image drawing code (Closes: #357830).
   * debian/control: New package gcjwebplugin
   * debian/gcjwebplugin.links, debian/gcjwebplugin.install: New files.
   * debian/classpath-common-unzipped.install: Install classes in sun.*
     namespace.
   * debian/classpath.install: Don't install new appletviewer binary.
   * debian/patches/appletviewer.patch: Added runtime selection to
     appletviewer (Closes: #359654).
Files: 
 3214d5a31b24ff0bc9a275b5d5f5ef69 1340 libs optional classpath_0.92-1.dsc
 4603ef3e593713d94788b919bc0b6c75 9161101 libs optional classpath_0.92.orig.tar.gz
 d87b041976c9eedbe3f90d4ca63ddb43 12895 libs optional classpath_0.92-1.diff.gz
 d8f6baa70301c60c339a09f053077d64 8154784 libs optional classpath-common_0.92-1_all.deb
 b770a71a1790fcf585ae91e9809ce90c 5744344 libs optional classpath-common-unzipped_0.92-1_all.deb
 9938f60cd3e289996c5cc31bc1c31b9f 28912296 doc optional classpath-doc_0.92-1_all.deb
 eef6d450ae09cae745ab0b5ac62f9ff8 232438 libs optional jikes-classpath_0.92-1_all.deb
 a2cf937f3813efdb7d149c21aebb57c9 353948 libs optional classpath_0.92-1_i386.deb
 8e5598d8aa71024f58da23d8aed90bf9 310486 libs optional classpath-gtkpeer_0.92-1_i386.deb
 c8990676e1716b76aac076881c636b7d 310944 libs optional classpath-qtpeer_0.92-1_i386.deb
 6982960c5ff98ea72badd5b3ed62cf3f 244102 net optional gcjwebplugin_0.92-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFAu/lWSOgCCdjSDsRAqnTAJ4pTrSMbyEH6KL4WMvb03lrlDgPuQCeI6t+
lhUbTi0yB8lKlFK+i8JQwpQ=
=/7hg
-----END PGP SIGNATURE-----




Reply sent to Michael Koch <konqueror@gmx.de>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Samuel Hym <Samuel.Hym@gmail.com>:
Bug acknowledged by developer. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Jeroen van Wolffelaar <jeroen@wolffelaar.nl>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #76 received at 267040@bugs.debian.org (full text, mbox):

From: Jeroen van Wolffelaar <jeroen@wolffelaar.nl>
To: 267040@bugs.debian.org
Cc: Michael Koch <konqueror@gmx.de>, Debian Bugs Control Bot <control@bugs.debian.org>
Subject: Re: Bug#267040: Is a warning really adequate?
Date: Fri, 6 Oct 2006 14:33:52 +0200
reopen 267040
thanks

On Sat, Aug 19, 2006 at 04:36:42PM +0200, Jeroen van Wolffelaar wrote:
> What do you think about this?

I do not feel that my concerns have been adressed.

--Jeroen

-- 
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl



Bug reopened, originator not changed. Request was from Jeroen van Wolffelaar <jeroen@wolffelaar.nl> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to "Herman Robak" <herman@skolelinux.no>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #83 received at 267040@bugs.debian.org (full text, mbox):

From: "Herman Robak" <herman@skolelinux.no>
To: 267040@bugs.debian.org
Subject: Don't present "be safe, or get things done" choices to browser users!
Date: Sun, 06 Jul 2008 13:10:58 +0200
I know this is old news, but I just got this warning dialog in my face.
And I know what most "regular" users are inclined to do: Just make it
work, which means whitelist high and low.

Out of the box, Debian does not include non-free.  According to the 
package listings of the DFSG walled garden (i.e. "main"), Sun Java 
does not exist.  Not in Debian Etch, the current stable, that is.

Do you assume that nobody trusts _your_ judgement, but uses Google, 
looks for Sun Java, and installs that instead?  Or do you actually 
think that warning dialogs are an adequate security measure here?

IMO, java-gcj-compat-plugin in its current state has no business 
in Debian Stable. (unless that fat warning was a false alarm?)

-- 
Herman Robak




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #88 received at 267040@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: debian-release@bugs.debian.org
Cc: security@debian.org, 267040@bugs.debian.org
Subject: gcjwebplugin runs untrusted code without sandbox
Date: Sun, 7 Sep 2008 17:39:28 +0100
[Message part 1 (text/plain, inline)]
gcjwebplugin is a Java plugin for web browsers.  It does not include the
security manager which is a crucial part of the "sandboxing" of Java
applets.  The maintainers have "fixed" this bug (#267040) merely by
adding a warning prompt before running applets, which is well known to
be an insufficient means of protecting users from malware.  Please do
not include it in lenny.  (Unfortunately it is built from the classpath
source package, so that will have to be modified to remove it.)

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #93 received at 267040@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: debian-release@bugs.debian.org
Cc: security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Sun, 07 Sep 2008 19:18:32 +0200
[Ben Hutchings]
> Please do not include it in lenny.  (Unfortunately it is built from
> the classpath source package, so that will have to be modified to
> remove it.)

Are there any free applet plugins available in main now?  Perhaps the
gcjwebplugin should be replaced by something from openjdk?  Then the
users with it currenctly installed will keep applets working. :)

Happy hacking,
-- 
Petter Rinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Message #96 received at 267040@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-release@bugs.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Mon, 8 Sep 2008 17:02:11 +0200
On Sun, Sep 07, 2008 at 05:39:28PM +0100, Ben Hutchings wrote:
> gcjwebplugin is a Java plugin for web browsers.  It does not include the
> security manager which is a crucial part of the "sandboxing" of Java
> applets.  The maintainers have "fixed" this bug (#267040) merely by
> adding a warning prompt before running applets, which is well known to
> be an insufficient means of protecting users from malware.  Please do
> not include it in lenny.  (Unfortunately it is built from the classpath
> source package, so that will have to be modified to remove it.)

How is this different from the multitude of interfaces in the system in
which data is assumed to be trusted?

If you want a similar example, Iceweasel will process certain websites after
warning the user that special privileges were requested, and asking for
confirmation.

There's a huge amount of users who don't care about security, but do care
a lot about certain websites working.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Message #99 received at 267040@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-release@lists.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Mon, 8 Sep 2008 20:15:33 +0200
[ sorry for the duplicate, my first reply didn't get to -release ]

On Sun, Sep 07, 2008 at 05:39:28PM +0100, Ben Hutchings wrote:
> gcjwebplugin is a Java plugin for web browsers.  It does not include the
> security manager which is a crucial part of the "sandboxing" of Java
> applets.  The maintainers have "fixed" this bug (#267040) merely by
> adding a warning prompt before running applets, which is well known to
> be an insufficient means of protecting users from malware.  Please do
> not include it in lenny.  (Unfortunately it is built from the classpath
> source package, so that will have to be modified to remove it.)

How is this different from the multitude of interfaces in the system in
which data is assumed to be trusted?

If you want a similar example, Iceweasel will process certain websites after
warning the user that special privileges were requested, and asking for
confirmation.

There's a huge amount of users who don't care about security, but do care
a lot about certain websites working.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #104 received at 267040@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Robert Millan <rmh@aybabtu.com>
Cc: debian-release@bugs.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Mon, 8 Sep 2008 23:51:55 +0100
[Message part 1 (text/plain, inline)]
On Mon, Sep 08, 2008 at 05:02:11PM +0200, Robert Millan wrote:
> On Sun, Sep 07, 2008 at 05:39:28PM +0100, Ben Hutchings wrote:
> > gcjwebplugin is a Java plugin for web browsers.  It does not include the
> > security manager which is a crucial part of the "sandboxing" of Java
> > applets.  The maintainers have "fixed" this bug (#267040) merely by
> > adding a warning prompt before running applets, which is well known to
> > be an insufficient means of protecting users from malware.  Please do
> > not include it in lenny.  (Unfortunately it is built from the classpath
> > source package, so that will have to be modified to remove it.)
> 
> How is this different from the multitude of interfaces in the system in
> which data is assumed to be trusted?

Data from the network is generally treated as untrusted; where programs
are found to be insufficiently paranoid, we treat this as a bug and
issue a security update.

In general, we require the user to make an explicit choice to download
and run code outside of a sandbox.  Visiting a web site and clicking
"OK" is not such an explicit choice.

> If you want a similar example, Iceweasel will process certain websites after
> warning the user that special privileges were requested, and asking for
> confirmation.

I believe you're mistaken.  But if you're right, that's also a bug.

> There's a huge amount of users who don't care about security, but do care
> a lot about certain websites working.
 
They can use the Sun Java plugin.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.	They only think they are.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Message #107 received at 267040@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-release@bugs.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Tue, 9 Sep 2008 14:30:17 +0200
On Mon, Sep 08, 2008 at 11:51:55PM +0100, Ben Hutchings wrote:
> > 
> > How is this different from the multitude of interfaces in the system in
> > which data is assumed to be trusted?
> 
> Data from the network is generally treated as untrusted;

The user is in charge.  Data from the network becomes trusted when the user
decides so.  This applies to a lot of different situations, I assume it's not
necessary for me to give examples?

> They can use the Sun Java plugin.

I can't believe you're actually arguing that the solution against blindly
trusting a website is blindly trusting a binary blob.

Here's my advice: If you don't like gcjwebplugin, don't use it.  If you like
binary blobs, go use them.  If you don't care about Java, don't use either.
Just don't impose your view on everyone else by requesting arbitrary removal
of a package.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Message #110 received at 267040@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-release@lists.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Tue, 9 Sep 2008 15:12:54 +0200
[ whoops, resending again...]

On Mon, Sep 08, 2008 at 11:51:55PM +0100, Ben Hutchings wrote:
> > 
> > How is this different from the multitude of interfaces in the system in
> > which data is assumed to be trusted?
> 
> Data from the network is generally treated as untrusted;

The user is in charge.  Data from the network becomes trusted when the user
decides so.  This applies to a lot of different situations, I assume it's not
necessary for me to give examples?

> They can use the Sun Java plugin.

I can't believe you're actually arguing that the solution against blindly
trusting a website is blindly trusting a binary blob.

Here's my advice: If you don't like gcjwebplugin, don't use it.  If you like
binary blobs, go use them.  If you don't care about Java, don't use either.
Just don't impose your view on everyone else by requesting arbitrary removal
of a package.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #115 received at 267040@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Robert Millan <rmh@aybabtu.com>
Cc: debian-release@lists.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Tue, 9 Sep 2008 23:11:45 +0100
[Message part 1 (text/plain, inline)]
On Tue, Sep 09, 2008 at 03:12:54PM +0200, Robert Millan wrote:
> 
> [ whoops, resending again...]
> 
> On Mon, Sep 08, 2008 at 11:51:55PM +0100, Ben Hutchings wrote:
> > > 
> > > How is this different from the multitude of interfaces in the system in
> > > which data is assumed to be trusted?
> > 
> > Data from the network is generally treated as untrusted;
> 
> The user is in charge.  Data from the network becomes trusted when the user
> decides so.  This applies to a lot of different situations, I assume it's not
> necessary for me to give examples?

When a user navigates to a web page, they want to see that page.  Any
prompts on the way tend to be interpreted as "do you want to see this
web page or not?", to which the answer is "yes of course".  If the
question is really "do you want to trust this web site with full control
over your account?" then it's leading the user into a trap.  This is why
the major browsers now use an information bar to notify the user that
some potentially insecure feature is not active and can be manually
activated, rather than forcing the user to make a decision before the
page will appear.

If the plugin was changed to use the information bar and provide a
whitelisting mechanism for trusted sites, I think that would satisfy
the requirement for an explicit choice by the user.  But it still
wouldn't be nearly as good as a proper sandbox.

> > They can use the Sun Java plugin.
> 
> I can't believe you're actually arguing that the solution against blindly
> trusting a website is blindly trusting a binary blob.

I would rather use a secure free plugin than a secure non-free plugin,
but apparently that doesn't exist.  Since the choice is between a secure
non-free plugin and an insecure free plugin, them I'm afraid I'd go for
the former because I trust Sun much more than I trust many of the web
sites I visit.  I'd be very surprised if you can honestly say the
opposite.

> Here's my advice: If you don't like gcjwebplugin, don't use it.  If you like
> binary blobs, go use them.  If you don't care about Java, don't use either.

As it happens, I have no need for Java applets; Flash seems to have
taken their place.  (And yes I know there's a similar problem there,
though AFAIK the free implementations are sufficiently sandboxed.)

> Just don't impose your view on everyone else by requesting arbitrary removal
> of a package.
 
It's not arbitrary.  As it stands, this package is a security hole
just waiting to be exploited if it gets released.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to peter green <plugwash@p10link.net>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #120 received at 267040@bugs.debian.org (full text, mbox):

From: peter green <plugwash@p10link.net>
To: ben@decadent.org.uk
Cc: rmh@aybabtu.com, debian-release@lists.debian.org, security@debian.org, 267040@bugs.debian.org, debian-java@lists.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Wed, 10 Sep 2008 01:21:55 +0100
>> I can't believe you're actually arguing that the solution against blindly
>> trusting a website is blindly trusting a binary blob.
>
>I would rather use a secure free plugin than a secure non-free plugin,
>but apparently that doesn't exist.  Since the choice is between a secure
>non-free plugin and an insecure free plugin, them I'm afraid I'd go for
>the former because I trust Sun much more than I trust many of the web
>sites I visit.  I'd be very surprised if you can honestly say the
>opposite.

What about icedtea-gcjwebplugin? does that have a functioning security manager? 
(I belive it does but i'm not certain, adding debian-java to cc for comments on 
that). If so then it may be the free "secure" soloution you are looking for.







Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Message #123 received at 267040@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-release@lists.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Wed, 10 Sep 2008 17:31:40 +0200
On Tue, Sep 09, 2008 at 11:11:45PM +0100, Ben Hutchings wrote:
> It's not arbitrary.  As it stands, this package is a security hole
> just waiting to be exploited if it gets released.

I take it "gdebi" (or whatever it's called) is also a security hole then?  It
installs untrusted data when the user has approved it!

You can even visit a website, click on a .deb file, and upon your confirmation
untrusted code is executed with root perms.  Clearly we should do something
to prevent that.

Also, lots of websites strongly encourage you to install Adobe Flash.  They
point you to a website, giving you an unsigned binary, and upon your approval
your system ends up executing it.  Clearly we should do something to prevent
that.

Fix your double standards.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Message #126 received at 267040@bugs.debian.org (full text, mbox):

From: Robert Millan <rmh@aybabtu.com>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-release@lists.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Wed, 10 Sep 2008 17:34:43 +0200
On Tue, Sep 09, 2008 at 11:11:45PM +0100, Ben Hutchings wrote:
> > I can't believe you're actually arguing that the solution against blindly
> > trusting a website is blindly trusting a binary blob.
> 
> I would rather use a secure free plugin than a secure non-free plugin,
> but apparently that doesn't exist.  Since the choice is between a secure
> non-free plugin and an insecure free plugin, them I'm afraid I'd go for
> the former because I trust Sun much more than I trust many of the web
> sites I visit.  I'd be very surprised if you can honestly say the
> opposite.

I suppose it's different for everyone.  But if you want my opinion, the
reason I refuse to use Sun's plugin is not because of security, but simply
because I believe I am my own master.  And since I don't owe allegiance to
Sun, I don't kneel to them.

Then again, the "security" issue is not real.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to Osamu Aoki <osamu@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #131 received at 267040@bugs.debian.org (full text, mbox):

From: Osamu Aoki <osamu@debian.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Robert Millan <rmh@aybabtu.com>, debian-release@lists.debian.org, security@debian.org, 267040@bugs.debian.org
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Thu, 11 Sep 2008 00:57:58 +0900
Hi,

On Tue, Sep 09, 2008 at 11:11:45PM +0100, Ben Hutchings wrote:
> On Tue, Sep 09, 2008 at 03:12:54PM +0200, Robert Millan wrote:
...
> When a user navigates to a web page, they want to see that page.  Any
> prompts on the way tend to be interpreted as "do you want to see this
> web page or not?", to which the answer is "yes of course".  If the
> question is really "do you want to trust this web site with full control
> over your account?" then it's leading the user into a trap.  This is why
> the major browsers now use an information bar to notify the user that
> some potentially insecure feature is not active and can be manually
> activated, rather than forcing the user to make a decision before the
> page will appear.
> 
> If the plugin was changed to use the information bar and provide a
> whitelisting mechanism for trusted sites, I think that would satisfy
> the requirement for an explicit choice by the user.  But it still
> wouldn't be nearly as good as a proper sandbox.
> 
> > > They can use the Sun Java plugin.
> > 
> > I can't believe you're actually arguing that the solution against blindly
> > trusting a website is blindly trusting a binary blob.
> 
> I would rather use a secure free plugin than a secure non-free plugin,
> but apparently that doesn't exist.  Since the choice is between a secure
> non-free plugin and an insecure free plugin, them I'm afraid I'd go for
> the former because I trust Sun much more than I trust many of the web
> sites I visit.  I'd be very surprised if you can honestly say the
> opposite.

That is your choice.
 
> > Here's my advice: If you don't like gcjwebplugin, don't use it.  If you like
> > binary blobs, go use them.  If you don't care about Java, don't use either.
> 
> As it happens, I have no need for Java applets; Flash seems to have
> taken their place.  (And yes I know there's a similar problem there,
> though AFAIK the free implementations are sufficiently sandboxed.)
> 
> > Just don't impose your view on everyone else by requesting arbitrary removal
> > of a package.
>  
> It's not arbitrary.  As it stands, this package is a security hole
> just waiting to be exploited if it gets released.
> 
> Ben.

I only hear criticism to others' action but no concrete alternative
proposal (like goos patch) from Ben.

You can easily criticise shortcomings and prdonopose to kick those
package out but unless your proposal improves situation, I see no gain
for Debian and no one will agree.

I have successfully removed one of old FREE-flash package from our
archive for lenny but that was because there were these better FREE
softwares (not Adobe one as reason for removal).

Please use balanced view on these.

Osamu





Bug marked as fixed in version 2:0.91+cvs20060611-1, send any further explanations to Samuel Hym <Samuel.Hym@gmail.com> Request was from kurt@roeckx.be (Kurt Roeckx) to control@bugs.debian.org. (Sun, 14 Sep 2008 14:48:06 GMT) Full text and rfc822 format available.

Bug no longer marked as fixed in version 2:0.91+cvs20060611-1. Request was from kurt@roeckx.be (Kurt Roeckx) to control@bugs.debian.org. (Sun, 14 Sep 2008 14:54:07 GMT) Full text and rfc822 format available.

Bug reopened, originator not changed. Request was from kurt@roeckx.be (Kurt Roeckx) to control@bugs.debian.org. (Sun, 14 Sep 2008 14:54:08 GMT) Full text and rfc822 format available.

Tags removed: fixed-in-experimental Request was from kurt@roeckx.be (Kurt Roeckx) to control@bugs.debian.org. (Sun, 14 Sep 2008 14:54:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. Full text and rfc822 format available.

Acknowledgement sent to kurt@roeckx.be (Kurt Roeckx):
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #144 received at 267040@bugs.debian.org (full text, mbox):

From: kurt@roeckx.be (Kurt Roeckx)
To: control@bugs.debian.org
Cc: 267040@bugs.debian.org
Subject: found 267040 in 2:0.91+cvs20060611-1
Date: Sun, 14 Sep 2008 17:17:47 +0200 (CEST)
# Automatically generated email from bts, devscripts version 2.10.35
# Marking also as found in the first version of classpath source package that had this binary package, used to be in it's own source package.
found 267040 2:0.91+cvs20060611-1




Bug marked as found in version 2:0.91+cvs20060611-1. Request was from kurt@roeckx.be (Kurt Roeckx) to control@bugs.debian.org. (Sun, 14 Sep 2008 15:21:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. (Mon, 29 Sep 2008 15:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Moritz Muehlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. (Mon, 29 Sep 2008 15:12:02 GMT) Full text and rfc822 format available.

Message #151 received at 267040@bugs.debian.org (full text, mbox):

From: Moritz Muehlenhoff <jmm@inutil.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: debian-release@bugs.debian.org, security@debian.org, 267040@bugs.debian.org, konqueror@gmx.de
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Mon, 29 Sep 2008 17:09:43 +0200
On Sun, Sep 07, 2008 at 05:39:28PM +0100, Ben Hutchings wrote:
> gcjwebplugin is a Java plugin for web browsers.  It does not include the
> security manager which is a crucial part of the "sandboxing" of Java
> applets.  The maintainers have "fixed" this bug (#267040) merely by
> adding a warning prompt before running applets, which is well known to
> be an insufficient means of protecting users from malware.  Please do
> not include it in lenny.  (Unfortunately it is built from the classpath
> source package, so that will have to be modified to remove it.)

I had discussed this with Michael Koch some time ago; the version
in Lenny implements a security manager, but it's not yet clear whether
it's fully appropriate. We didn't reach a final conclusion, but I guess
the warning is sufficient for Lenny.

Cheers,
        Moritz




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. (Mon, 20 Oct 2008 18:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Moritz Muehlenhoff <jmm@inutil.org>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. (Mon, 20 Oct 2008 18:00:03 GMT) Full text and rfc822 format available.

Message #156 received at 267040@bugs.debian.org (full text, mbox):

From: Moritz Muehlenhoff <jmm@inutil.org>
To: Moritz Muehlenhoff <jmm@inutil.org>
Cc: Ben Hutchings <ben@decadent.org.uk>, debian-release@bugs.debian.org, security@debian.org, 267040@bugs.debian.org, konqueror@gmx.de
Subject: Re: gcjwebplugin runs untrusted code without sandbox
Date: Mon, 20 Oct 2008 19:58:28 +0200
Moritz Muehlenhoff wrote:
> On Sun, Sep 07, 2008 at 05:39:28PM +0100, Ben Hutchings wrote:
> > gcjwebplugin is a Java plugin for web browsers.  It does not include the
> > security manager which is a crucial part of the "sandboxing" of Java
> > applets.  The maintainers have "fixed" this bug (#267040) merely by
> > adding a warning prompt before running applets, which is well known to
> > be an insufficient means of protecting users from malware.  Please do
> > not include it in lenny.  (Unfortunately it is built from the classpath
> > source package, so that will have to be modified to remove it.)
> 
> I had discussed this with Michael Koch some time ago; the version
> in Lenny implements a security manager, but it's not yet clear whether
> it's fully appropriate. We didn't reach a final conclusion, but I guess
> the warning is sufficient for Lenny.

I haven't heard back from Michael and I believe we should err on the
safe side and not lure users into a false sense of security.

Since we now have icedtea-gcjwebplugin in Lenny, we have a web plugin
based on OpenJDK and should drop the gcjwebplugin binary package from
Lenny.

Cheers,
        Moritz




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>:
Bug#267040; Package gcjwebplugin. (Sun, 26 Oct 2008 22:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to sean finney <seanius@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>. (Sun, 26 Oct 2008 22:03:02 GMT) Full text and rfc822 format available.

Message #161 received at 267040@bugs.debian.org (full text, mbox):

From: sean finney <seanius@debian.org>
To: 267040@bugs.debian.org
Subject: NMU pending
Date: Sun, 26 Oct 2008 22:53:18 +0100
[Message part 1 (text/plain, inline)]
hi,

as moritz has pointed out, icedtea-gcjwebplugin gives a viable solution
for the secure/Free dilemma, so i've uploaded an NMU that disables
generation of the binary package.  i've only commented out the relevant
lines from debian/control so it should be easy enough to re-enable it
again later.

i've also sent it to delayed/5-day, so there's time for review/rejection
of the NMU.  though if you agree please feel free to let me know so i
can speed it up instead.


	sean
[signature.asc (application/pgp-signature, inline)]

Tags added: pending Request was from Sean Finney <seanius@debian.org> to control@bugs.debian.org. (Sun, 26 Oct 2008 22:57:03 GMT) Full text and rfc822 format available.

Reply sent to Sean Finney <seanius@debian.org>:
You have taken responsibility. (Fri, 31 Oct 2008 22:21:03 GMT) Full text and rfc822 format available.

Notification sent to Phil Endecott <spam-from-debian-bugs@chezphil.org>:
Bug acknowledged by developer. (Fri, 31 Oct 2008 22:21:03 GMT) Full text and rfc822 format available.

Message #168 received at 267040-close@bugs.debian.org (full text, mbox):

From: Sean Finney <seanius@debian.org>
To: 267040-close@bugs.debian.org
Subject: Bug#267040: fixed in classpath 2:0.97.2-1.1
Date: Fri, 31 Oct 2008 22:17:14 +0000
Source: classpath
Source-Version: 2:0.97.2-1.1

We believe that the bug you reported is fixed in the latest version of
classpath, which is due to be installed in the Debian FTP archive:

classpath-common-unzipped_0.97.2-1.1_all.deb
  to pool/main/c/classpath/classpath-common-unzipped_0.97.2-1.1_all.deb
classpath-common_0.97.2-1.1_all.deb
  to pool/main/c/classpath/classpath-common_0.97.2-1.1_all.deb
classpath-doc_0.97.2-1.1_all.deb
  to pool/main/c/classpath/classpath-doc_0.97.2-1.1_all.deb
classpath-gtkpeer_0.97.2-1.1_amd64.deb
  to pool/main/c/classpath/classpath-gtkpeer_0.97.2-1.1_amd64.deb
classpath-qtpeer_0.97.2-1.1_amd64.deb
  to pool/main/c/classpath/classpath-qtpeer_0.97.2-1.1_amd64.deb
classpath_0.97.2-1.1.diff.gz
  to pool/main/c/classpath/classpath_0.97.2-1.1.diff.gz
classpath_0.97.2-1.1.dsc
  to pool/main/c/classpath/classpath_0.97.2-1.1.dsc
classpath_0.97.2-1.1_amd64.deb
  to pool/main/c/classpath/classpath_0.97.2-1.1_amd64.deb
jikes-classpath_0.97.2-1.1_all.deb
  to pool/main/c/classpath/jikes-classpath_0.97.2-1.1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 267040@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sean Finney <seanius@debian.org> (supplier of updated classpath package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sun, 26 Oct 2008 21:45:32 +0100
Source: classpath
Binary: classpath classpath-gtkpeer classpath-qtpeer classpath-common classpath-common-unzipped classpath-doc jikes-classpath
Architecture: source all amd64
Version: 2:0.97.2-1.1
Distribution: unstable
Urgency: high
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Sean Finney <seanius@debian.org>
Description: 
 classpath  - clean room standard Java libraries
 classpath-common - clean room standard Java libraries - architecture independent fil
 classpath-common-unzipped - clean room standard Java libraries - architecture independent fil
 classpath-doc - clean room standard Java libraries - free Java API documentation
 classpath-gtkpeer - clean room standard Java libraries - GTK+ AWT peer
 classpath-qtpeer - clean room standard Java libraries - QT AWT peer
 jikes-classpath - clean room standard Java libraries - wrapper for jikes
Closes: 267040
Changes: 
 classpath (2:0.97.2-1.1) unstable; urgency=high
 .
   * Non-maintainer upload.
   * Redisable gcjwebplugin for all architectures, since the security
     issues are not considered to be adequately resolved for lenny and the
     icedtea-gcjwebplugin is now available (closes: #267040).
Checksums-Sha1: 
 fe0b65edc5db7fc3fb80e15eb684f6a8c8a6c016 1808 classpath_0.97.2-1.1.dsc
 c3c0e80c726d15095123757175fe8ced0fc044b8 15448 classpath_0.97.2-1.1.diff.gz
 8fe68467cb42586e2efde29e5345db25ff6b4719 9251964 classpath-common_0.97.2-1.1_all.deb
 63e4b8c5cc43b3436b642c225c9868eb48efc7bb 6375694 classpath-common-unzipped_0.97.2-1.1_all.deb
 cee7b472af626fd30c8cb19faf205dea61553cee 30243524 classpath-doc_0.97.2-1.1_all.deb
 c1dd07e2311c6900a0265aae5a47f81ff2e35c04 23350 jikes-classpath_0.97.2-1.1_all.deb
 bbeffd3aed59cee55d9ea9e8469a23a54839e4f4 174372 classpath_0.97.2-1.1_amd64.deb
 2f5c86cf61c34a2fde1745eb3f5107cc7fdeebd8 103156 classpath-gtkpeer_0.97.2-1.1_amd64.deb
 2e3362d958fc9d3e8697fa28bc99742080d7f4f5 105676 classpath-qtpeer_0.97.2-1.1_amd64.deb
Checksums-Sha256: 
 0b65301eb895a7f3c31cd143f785f5ce572d03b9063a12e52e2e485237c715a5 1808 classpath_0.97.2-1.1.dsc
 17cad0e6b4004db73d0deee6656aabfe1bc2a670c5f5290fede05dd55bf0ec3c 15448 classpath_0.97.2-1.1.diff.gz
 c92652a83fb6dfed806b706882228465cf39b75ae527cb4e4a82ef2e2f8be2b0 9251964 classpath-common_0.97.2-1.1_all.deb
 bf2a30ff0725dc9f98c2c635bc9263c7225da3ef8775d33276cdde436b57c3d3 6375694 classpath-common-unzipped_0.97.2-1.1_all.deb
 edd9196d1464c004ea7d162e45180d347428615b55682e0f3e7e3209ea7b69f1 30243524 classpath-doc_0.97.2-1.1_all.deb
 4ec6acce573a367763867e0daaf127e04e1ebc0745907527cb5ea56d9a40722d 23350 jikes-classpath_0.97.2-1.1_all.deb
 adb4751b952d00d06abb8b9b96e69ac546cc3b34bfecb74d98467f542673f96a 174372 classpath_0.97.2-1.1_amd64.deb
 09140534e8a771fb5d5f49e60fc65db0856234c6248528dabcfb49b05a6dfc9c 103156 classpath-gtkpeer_0.97.2-1.1_amd64.deb
 570d26413c3c742e7a55570145fa473bba834e92a32807610cf23fde849b5d73 105676 classpath-qtpeer_0.97.2-1.1_amd64.deb
Files: 
 8c7bcfaf551f680b93c0b4f0dc44fd0e 1808 libs optional classpath_0.97.2-1.1.dsc
 ab7e1e809cac44c83713fc5b95ff6586 15448 libs optional classpath_0.97.2-1.1.diff.gz
 1ea1bcace585b6bd8ac41e0cfadb2422 9251964 libs optional classpath-common_0.97.2-1.1_all.deb
 c34b5ea7883eff7c8ee8c3d363ece595 6375694 libs optional classpath-common-unzipped_0.97.2-1.1_all.deb
 9440e625d00328d4a5556c492fecef9d 30243524 doc optional classpath-doc_0.97.2-1.1_all.deb
 ec150d5267c836a4f3cc53becaf118bf 23350 devel optional jikes-classpath_0.97.2-1.1_all.deb
 108c30665479c8cbaafe49e03bd4cc3d 174372 libs optional classpath_0.97.2-1.1_amd64.deb
 522d1d7ca97fed9ad0230dbefdc6f055 103156 libs optional classpath-gtkpeer_0.97.2-1.1_amd64.deb
 6cdf50b10a183c3d5afc63219cc94b39 105676 libs optional classpath-qtpeer_0.97.2-1.1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJBOJIynjLPm522B0RAqpUAJ9PqicCpb+IOdBHPq0JurZ+hgXVfgCff5xC
uxwdDwPURsibhww62DyxZAU=
=sf8W
-----END PGP SIGNATURE-----





Reply sent to Sean Finney <seanius@debian.org>:
You have taken responsibility. (Fri, 31 Oct 2008 22:21:03 GMT) Full text and rfc822 format available.

Notification sent to Samuel Hym <Samuel.Hym@gmail.com>:
Bug acknowledged by developer. (Fri, 31 Oct 2008 22:21:03 GMT) Full text and rfc822 format available.

Tags removed: Request was from Ben Hutchings <ben@decadent.org.uk> to control@bugs.debian.org. (Sat, 22 Nov 2008 20:57:07 GMT) Full text and rfc822 format available.

Reply sent to Ben Hutchings <ben@decadent.org.uk>:
You have taken responsibility. (Sun, 30 Nov 2008 17:33:03 GMT) Full text and rfc822 format available.

Notification sent to Phil Endecott <spam-from-debian-bugs@chezphil.org>:
Bug acknowledged by developer. (Sun, 30 Nov 2008 17:33:04 GMT) Full text and rfc822 format available.

Message #180 received at 267040-close@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: 267040-close@bugs.debian.org
Subject: Bug#267040: fixed in classpath 2:0.97.1-5+lenny1
Date: Sun, 30 Nov 2008 17:02:09 +0000
Source: classpath
Source-Version: 2:0.97.1-5+lenny1

We believe that the bug you reported is fixed in the latest version of
classpath, which is due to be installed in the Debian FTP archive:

classpath-common-unzipped_0.97.1-5+lenny1_all.deb
  to pool/main/c/classpath/classpath-common-unzipped_0.97.1-5+lenny1_all.deb
classpath-common_0.97.1-5+lenny1_all.deb
  to pool/main/c/classpath/classpath-common_0.97.1-5+lenny1_all.deb
classpath-doc_0.97.1-5+lenny1_all.deb
  to pool/main/c/classpath/classpath-doc_0.97.1-5+lenny1_all.deb
classpath-gtkpeer_0.97.1-5+lenny1_i386.deb
  to pool/main/c/classpath/classpath-gtkpeer_0.97.1-5+lenny1_i386.deb
classpath-qtpeer_0.97.1-5+lenny1_i386.deb
  to pool/main/c/classpath/classpath-qtpeer_0.97.1-5+lenny1_i386.deb
classpath_0.97.1-5+lenny1.diff.gz
  to pool/main/c/classpath/classpath_0.97.1-5+lenny1.diff.gz
classpath_0.97.1-5+lenny1.dsc
  to pool/main/c/classpath/classpath_0.97.1-5+lenny1.dsc
classpath_0.97.1-5+lenny1_i386.deb
  to pool/main/c/classpath/classpath_0.97.1-5+lenny1_i386.deb
jikes-classpath_0.97.1-5+lenny1_all.deb
  to pool/main/c/classpath/jikes-classpath_0.97.1-5+lenny1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 267040@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ben Hutchings <ben@decadent.org.uk> (supplier of updated classpath package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 29 Nov 2008 19:35:40 +0000
Source: classpath
Binary: classpath classpath-gtkpeer classpath-qtpeer classpath-common classpath-common-unzipped classpath-doc jikes-classpath
Architecture: source all i386
Version: 2:0.97.1-5+lenny1
Distribution: testing
Urgency: low
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Changed-By: Ben Hutchings <ben@decadent.org.uk>
Description: 
 classpath  - clean room standard Java libraries
 classpath-common - clean room standard Java libraries - architecture independent fil
 classpath-common-unzipped - clean room standard Java libraries - architecture independent fil
 classpath-doc - clean room standard Java libraries - free Java API documentation
 classpath-gtkpeer - clean room standard Java libraries - GTK+ AWT peer
 classpath-qtpeer - clean room standard Java libraries - QT AWT peer
 jikes-classpath - clean room standard Java libraries - wrapper for jikes
Closes: 267040
Changes: 
 classpath (2:0.97.1-5+lenny1) testing; urgency=low
 .
   * Non-maintainer upload.
   * Redisable gcjwebplugin for all architectures, since the security
     issues are not considered to be adequately resolved for lenny and the
     icedtea-gcjwebplugin is now available. Closes: #267040
Checksums-Sha1: 
 419ddff9bcafe6c440086387ed6c0ba3fa2c0681 1860 classpath_0.97.1-5+lenny1.dsc
 9c76cedbd46813445f58600c08912475d4fb589f 15439 classpath_0.97.1-5+lenny1.diff.gz
 6813b32f66e6f13024149c28a593f59ce46419e1 9203518 classpath-common_0.97.1-5+lenny1_all.deb
 6b530a5d9b1b6e792791b594fc56dafc63cdebc3 6365678 classpath-common-unzipped_0.97.1-5+lenny1_all.deb
 0c2fe47ca2deac5cc6ed0ec595bf379759f1aea1 30318882 classpath-doc_0.97.1-5+lenny1_all.deb
 4fcf510da14e81dda00f3d52f57676e975fde07b 21090 jikes-classpath_0.97.1-5+lenny1_all.deb
 58977f09dcfe84bf92966be99745969e1c4e6d58 207790 classpath_0.97.1-5+lenny1_i386.deb
 83bdc247963cb9e1492fa2440a7ac23a7abff739 93300 classpath-gtkpeer_0.97.1-5+lenny1_i386.deb
 f12b34b03637c753cab13f0fed67bdbeb9341863 103194 classpath-qtpeer_0.97.1-5+lenny1_i386.deb
Checksums-Sha256: 
 03b46b1e14dba56ba1b3033818a414deaa946d47daf25fb998f466e1ee449d3d 1860 classpath_0.97.1-5+lenny1.dsc
 042e91fe4c29edaed5672314c3a16a79de0c51e12c46f095c52f3fb65cea7a65 15439 classpath_0.97.1-5+lenny1.diff.gz
 8cbd507a754dedd40ef98869f70c5fff71e9b722ba99823e36d784d4384ee893 9203518 classpath-common_0.97.1-5+lenny1_all.deb
 c9978b159e0a6ecf598451b06723c2336f1309e18831c5030b65204dc6e5cc8c 6365678 classpath-common-unzipped_0.97.1-5+lenny1_all.deb
 c6efb2a99548d2d58b01a040a4877d57148203fc61e6fcd708dbb95372b27bce 30318882 classpath-doc_0.97.1-5+lenny1_all.deb
 3936115e38cb0b9ace0d54343899fa74398ac48a76b0909b67ed5d57579e0669 21090 jikes-classpath_0.97.1-5+lenny1_all.deb
 193a3ce3115764b60d4b02713b3011495b8691ffc39b43107c11691c1eb78562 207790 classpath_0.97.1-5+lenny1_i386.deb
 791ddc680fa1ca57f0ac29e47d35773aaa6e0eaf3c8f16dd1398c1779427b69a 93300 classpath-gtkpeer_0.97.1-5+lenny1_i386.deb
 99198cd00b5c472267149a071c7e6983796860daccfa884a2e62dba495c26fae 103194 classpath-qtpeer_0.97.1-5+lenny1_i386.deb
Files: 
 2e1a2f7d077ae44c33668249e2abdde6 1860 libs optional classpath_0.97.1-5+lenny1.dsc
 05e17d2aa8a86e35acea77bac56b54a9 15439 libs optional classpath_0.97.1-5+lenny1.diff.gz
 02d87ddc76d48e008f2fdb87848bf48a 9203518 libs optional classpath-common_0.97.1-5+lenny1_all.deb
 be5c47b4e5bea6f76a876372f8d1c627 6365678 libs optional classpath-common-unzipped_0.97.1-5+lenny1_all.deb
 187118bb2966ef884496b93a08ecfb17 30318882 doc optional classpath-doc_0.97.1-5+lenny1_all.deb
 d0f16bd21245923141f45acbd55360e2 21090 devel optional jikes-classpath_0.97.1-5+lenny1_all.deb
 488f536b683fcc3db0595ed09b2a184d 207790 libs optional classpath_0.97.1-5+lenny1_i386.deb
 f0e9304ae9ccdaa0c642a20fbb5027e9 93300 libs optional classpath-gtkpeer_0.97.1-5+lenny1_i386.deb
 9128df349a942419f36555f8f02e5239 103194 libs optional classpath-qtpeer_0.97.1-5+lenny1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJMrq179ZNCRIGYgcRAu6zAJ9CbRUtSVUZOQQpOS00RcP98/WivACglF3u
jY+UQxnCJaf0meRJD6Oyh1A=
=YBH3
-----END PGP SIGNATURE-----





Reply sent to Ben Hutchings <ben@decadent.org.uk>:
You have taken responsibility. (Sun, 30 Nov 2008 17:33:04 GMT) Full text and rfc822 format available.

Notification sent to Samuel Hym <Samuel.Hym@gmail.com>:
Bug acknowledged by developer. (Sun, 30 Nov 2008 17:33:05 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 29 Dec 2008 07:27:09 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 15:36:56 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.