Debian Bug report logs - #637856
/run/lock should be owned by uucp

version graph

Package: initscripts; Maintainer for initscripts is Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>; Source for initscripts is src:sysvinit.

Reported by: Joerg Dorchain <joerg@dorchain.net>

Date: Mon, 15 Aug 2011 07:45:02 UTC

Severity: normal

Found in version sysvinit/2.88dsf-13.11

Done: Roger Leigh <rleigh@codelibre.net>

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, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#637856; Package initscripts. (Mon, 15 Aug 2011 07:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Dorchain <joerg@dorchain.net>:
New Bug report received and forwarded. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 15 Aug 2011 07:45:05 GMT) Full text and rfc822 format available.

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

From: Joerg Dorchain <joerg@dorchain.net>
To: submit@bugs.debian.org
Subject: /run/lock should be owned by uucp
Date: Mon, 15 Aug 2011 09:43:12 +0200
[Message part 1 (text/plain, inline)]
Package: initscripts
Version: 2.88dsf-13.11

Hi,

there are programs that stat() /var/lock to test permissions
instead of actually trying to create lockfiles, the java rxtx
library for example. Before making this symlink to the /run/lock
tmpfs, ownership was preserved on harddisk.

A simple chgrp uucp /run/lock || true after creation/mounting of
/run/lock solves this and does not hurt programmes just trying to
write the lockfile.

A more general apporach is also welcome.

Bye,

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#637856; Package initscripts. (Mon, 15 Aug 2011 09:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 15 Aug 2011 09:18:14 GMT) Full text and rfc822 format available.

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

From: Roger Leigh <rleigh@codelibre.net>
To: Joerg Dorchain <joerg@dorchain.net>, 637856@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Mon, 15 Aug 2011 10:15:29 +0100
[Message part 1 (text/plain, inline)]
On Mon, Aug 15, 2011 at 09:43:12AM +0200, Joerg Dorchain wrote:
> there are programs that stat() /var/lock to test permissions
> instead of actually trying to create lockfiles, the java rxtx
> library for example. Before making this symlink to the /run/lock
> tmpfs, ownership was preserved on harddisk.

I think the check is broken.  They should just create the lockfile
and deal with failure as and when it occurs.  This use of stat(2)
is always broken on a multiuser system in any case, because there's
always a window between doing the check and creating the file
during which the ownership/permissions could change.

Regarding the ownership change (I assume here you changed it from
root:root to root:uucp?), this has never been supported.  And in
any case, /run/lock and /var/lock are writable by anyone at
present--the ownership should not matter:

% ls -ld /run/lock
drwxrwxrwt 3 root root 100 Aug 15 08:37 /run/lock

% ls -ld /var/lock
lrwxrwxrwx 1 root root 9 May 13 17:14 /var/lock -> /run/lock

> A simple chgrp uucp /run/lock || true after creation/mounting of
> /run/lock solves this and does not hurt programmes just trying to
> write the lockfile.

Why uucp?  As shown above, the user and group owning the directory
should not matter--it's globally writable and has the sticky-bit set.

> A more general apporach is also welcome.

We have been discussing moving to having a "lock" group as used by
other distributions, but this hasn't happened yet.  /run/lock
would then be run:lock 02775 I think.  Programs creating lockfiles
would then need to be running/started as root or setgid lock.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#637856; Package initscripts. (Mon, 15 Aug 2011 10:33:19 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 15 Aug 2011 10:33:23 GMT) Full text and rfc822 format available.

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

From: Roger Leigh <rleigh@codelibre.net>
To: Joerg Dorchain <joerg@dorchain.net>, 637856@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Mon, 15 Aug 2011 11:28:48 +0100
[Message part 1 (text/plain, inline)]
On Mon, Aug 15, 2011 at 10:15:29AM +0100, Roger Leigh wrote:
> On Mon, Aug 15, 2011 at 09:43:12AM +0200, Joerg Dorchain wrote:
> > A more general apporach is also welcome.
> 
> We have been discussing moving to having a "lock" group as used by
> other distributions, but this hasn't happened yet.  /run/lock
> would then be run:lock 02775 I think.

This should be root:lock 02775, of course.

>  Programs creating lockfiles
> would then need to be running/started as root or setgid lock.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#637856; Package initscripts. (Mon, 15 Aug 2011 10:51:29 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Dorchain <joerg@dorchain.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 15 Aug 2011 10:51:33 GMT) Full text and rfc822 format available.

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

From: Joerg Dorchain <joerg@dorchain.net>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 637856@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Mon, 15 Aug 2011 12:45:59 +0200
[Message part 1 (text/plain, inline)]
On Mon, Aug 15, 2011 at 10:15:29AM +0100, Roger Leigh wrote:
> On Mon, Aug 15, 2011 at 09:43:12AM +0200, Joerg Dorchain wrote:
> > there are programs that stat() /var/lock to test permissions
> > instead of actually trying to create lockfiles, the java rxtx
> > library for example. Before making this symlink to the /run/lock
> > tmpfs, ownership was preserved on harddisk.
> 
> I think the check is broken.  They should just create the lockfile

Well, there are issues with setuid()-binaries that need to do
their own access checks. A more common example would be the
sendmail binary.

> Regarding the ownership change (I assume here you changed it from
> root:root to root:uucp?), this has never been supported.  And in
> any case, /run/lock and /var/lock are writable by anyone at
> present--the ownership should not matter:

Yes, for a certain point of view you can argue that the
application is broken and that this is just a bad excuse for a
workaround of closed source sofware.
On the other hand, following the first paradigma of operations
("It has to work") this is the easiest place for a change that
makes it work with almost no side effects.
IMHO it would be a nice little feature of debian to be able to
cope with commercial software of certain quality.
> 
> Why uucp?  As shown above, the user and group owning the directory
> should not matter--it's globally writable and has the sticky-bit set.

As uucp is traditionally (yes, that means it is more than a
decade old and nobody but but long and greyhaired grandfathers
remember how it came to that) the user who uses lockfiles.
Specifically, that is what I need for my application to work.
I don't mind to have this configurable somewhere, e.g. yet
another rcS-variable would still be better than editing the
init.d script directly.
> 
> > A more general apporach is also welcome.
> 
> We have been discussing moving to having a "lock" group as used by
> other distributions, but this hasn't happened yet.  /run/lock
> would then be run:lock 02775 I think.  Programs creating lockfiles
> would then need to be running/started as root or setgid lock.

No problem with that. IIRC this is even supported by the rxtx
library my questionable binary uses. This would also separate the
locking functionally from the rest of the uucp stuff. setgid lock
would not even be necessary, just having lock amongst the
additional groups of the calling user would be sufficient.
I would still propose mode 3775, though.

On the other hand, uucp style lockfiles are typically used for
accessing devices owned by the dialout group.

Bye,

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#637856; Package initscripts. (Mon, 15 Aug 2011 14:12:35 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 15 Aug 2011 14:12:36 GMT) Full text and rfc822 format available.

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

From: Roger Leigh <rleigh@codelibre.net>
To: Joerg Dorchain <joerg@dorchain.net>
Cc: 637856@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Mon, 15 Aug 2011 14:59:04 +0100
[Message part 1 (text/plain, inline)]
On Mon, Aug 15, 2011 at 12:45:59PM +0200, Joerg Dorchain wrote:
> On Mon, Aug 15, 2011 at 10:15:29AM +0100, Roger Leigh wrote:
> > On Mon, Aug 15, 2011 at 09:43:12AM +0200, Joerg Dorchain wrote:
> > > there are programs that stat() /var/lock to test permissions
> > > instead of actually trying to create lockfiles, the java rxtx
> > > library for example. Before making this symlink to the /run/lock
> > > tmpfs, ownership was preserved on harddisk.
> > 
> > I think the check is broken.  They should just create the lockfile
> 
> Well, there are issues with setuid()-binaries that need to do
> their own access checks. A more common example would be the
> sendmail binary.

I'm not sure I follow.  A stat(2) on a symlink is equivalent to a
stat(2) on the pointed-to object, unless you use lstat(2).  Since
the directory is world-writable, any access checks will always succeed.
The introduction of the /var/lock->/var/run symlink will not change
the behaviour of stat(2).

> > Regarding the ownership change (I assume here you changed it from
> > root:root to root:uucp?), this has never been supported.  And in
> > any case, /run/lock and /var/lock are writable by anyone at
> > present--the ownership should not matter:
> 
> Yes, for a certain point of view you can argue that the
> application is broken and that this is just a bad excuse for a
> workaround of closed source sofware.
> On the other hand, following the first paradigma of operations
> ("It has to work") this is the easiest place for a change that
> makes it work with almost no side effects.
> IMHO it would be a nice little feature of debian to be able to
> cope with commercial software of certain quality.

I don't think this is an issue restricted to Debian--it is presumably
already broken on most other distributions as well?  This isn't a
recent change, or a change made in isolation.  AFAICT it was made
for FHS compliance reasons--nowadays /var/lock is used for a lot
more than just uucp, so expecting it to be owned by the uucp group
is, I think, unrealistic.  root:root or root:lock are the way things
have gone.

> > Why uucp?  As shown above, the user and group owning the directory
> > should not matter--it's globally writable and has the sticky-bit set.
> 
> As uucp is traditionally (yes, that means it is more than a
> decade old and nobody but but long and greyhaired grandfathers
> remember how it came to that) the user who uses lockfiles.
> Specifically, that is what I need for my application to work.
> I don't mind to have this configurable somewhere, e.g. yet
> another rcS-variable would still be better than editing the
> init.d script directly.

We don't currently permit changing of the ownership; the permissions
are entirely configurable in /etc/fstab.  You could use the tmpfs
uid= and gid=options to set the uucp group there.  We don't explicitly
cater for customisation here because the admin should never need
to change the ownership of these FHS-specified locations.

> > We have been discussing moving to having a "lock" group as used by
> > other distributions, but this hasn't happened yet.  /run/lock
> > would then be run:lock 02775 I think.  Programs creating lockfiles
> > would then need to be running/started as root or setgid lock.
> 
> No problem with that. IIRC this is even supported by the rxtx
> library my questionable binary uses. This would also separate the
> locking functionally from the rest of the uucp stuff. setgid lock
> would not even be necessary, just having lock amongst the
> additional groups of the calling user would be sufficient.
> I would still propose mode 3775, though.
> 
> On the other hand, uucp style lockfiles are typically used for
> accessing devices owned by the dialout group.

The liblockdev library exists to lock ttyS devices portably; any
program creating uucp-stype LCK..* files under /var/lock should be
using it.

Looking to the future, Linux permits the use of flock(2) on devices,
so the reality is that "lockfiles" are entirely redundant when you
can lock the device directly using an proper kernel-provided
advisory lock.  This is much more robust.  When I have time, I'll be
looking at making liblockdev use flock directly.

From what I've just been reading on RXTX file locks, it's rather
broken.
  (including http://rxtx.qbang.org/wiki/index.php/Trouble_shooting)
I think that, first and foremost, RXTX needs fixing.  It can use
liblockdev, which I see has already been suggested looking at list
archives with google.  It's basically using broken assumptions and
broken checks.  I don't think that breakage in a Java library can
really warrant changes to the default ownership of an FHS-standardised
directory.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#637856; Package initscripts. (Tue, 16 Aug 2011 06:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joerg Dorchain <joerg@dorchain.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Tue, 16 Aug 2011 06:57:03 GMT) Full text and rfc822 format available.

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

From: Joerg Dorchain <joerg@dorchain.net>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 637856@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Tue, 16 Aug 2011 08:53:24 +0200
[Message part 1 (text/plain, inline)]
On Mon, Aug 15, 2011 at 02:59:04PM +0100, Roger Leigh wrote:
> > > I think the check is broken.  They should just create the lockfile
> > 
> > Well, there are issues with setuid()-binaries that need to do
> > their own access checks. A more common example would be the
> > sendmail binary.
> 
> I'm not sure I follow.  A stat(2) on a symlink is equivalent to a
> stat(2) on the pointed-to object, unless you use lstat(2).  Since
> the directory is world-writable, any access checks will always succeed.
> The introduction of the /var/lock->/var/run symlink will not change
> the behaviour of stat(2).

I am under the impression that these applications check for group
permissions, and consider a world-writeable directory unsafe. I have
only looked at strace output, not disassembled code.
> 
> I don't think this is an issue restricted to Debian--it is presumably
> already broken on most other distributions as well?  This isn't a
> recent change, or a change made in isolation.  AFAICT it was made
> for FHS compliance reasons--nowadays /var/lock is used for a lot
> more than just uucp, so expecting it to be owned by the uucp group
> is, I think, unrealistic.  root:root or root:lock are the way things
> have gone.

I use this application roughly every  other week, on a machine
following testing, so I am quite sure the change happend in the
last few weeks.

As said, root:lock ownership with group-write permissions is
probably ok.
> 
> 
> We don't currently permit changing of the ownership; the permissions
> are entirely configurable in /etc/fstab.  You could use the tmpfs
> uid= and gid=options to set the uucp group there.

Thanks for that hint.

> We don't explicitly
> cater for customisation here because the admin should never need
> to change the ownership of these FHS-specified locations.

Well, if all developers would follow the FHS, it would be great.
> 
> > No problem with that. IIRC this is even supported by the rxtx
> > library my questionable binary uses. This would also separate the
> > locking functionally from the rest of the uucp stuff. setgid lock
> > would not even be necessary, just having lock amongst the
> > additional groups of the calling user would be sufficient.
> > I would still propose mode 3775, though.
> > 
> > On the other hand, uucp style lockfiles are typically used for
> > accessing devices owned by the dialout group.
> 
> The liblockdev library exists to lock ttyS devices portably; any
> program creating uucp-stype LCK..* files under /var/lock should be
> using it.

I do not see a realistic chance to have this application changed.
> 
> Looking to the future, Linux permits the use of flock(2) on devices,
> so the reality is that "lockfiles" are entirely redundant when you
> can lock the device directly using an proper kernel-provided
> advisory lock.  This is much more robust.  When I have time, I'll be
> looking at making liblockdev use flock directly.

I completely agree. However, this is an application from the
past, and not open source. Nevertheless I have not much choice but
using it.

> 
> From what I've just been reading on RXTX file locks, it's rather
> broken.
>   (including http://rxtx.qbang.org/wiki/index.php/Trouble_shooting)
> I think that, first and foremost, RXTX needs fixing.  It can use
> liblockdev, which I see has already been suggested looking at list
> archives with google.  It's basically using broken assumptions and
> broken checks.

Even if librxtx is ever fixed, that fixed version needs to make
it into the closed source apps of a commercial vendor. It will
take years.

> I don't think that breakage in a Java library can
> really warrant changes to the default ownership of an FHS-standardised
> directory.

As said, root:lock would also be ok. Even if you are not moving
away from FHS for policy reasons, just do not make it
unnecessarly hard to run with slight derivations from it.
Besides, I am sure it is not the only pre-FHS application out
there.

Bye,

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

Reply sent to Roger Leigh <rleigh@codelibre.net>:
You have taken responsibility. (Sun, 29 Apr 2012 17:03:05 GMT) Full text and rfc822 format available.

Notification sent to Joerg Dorchain <joerg@dorchain.net>:
Bug acknowledged by developer. (Sun, 29 Apr 2012 17:03:05 GMT) Full text and rfc822 format available.

Message #35 received at 637856-done@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Joerg Dorchain <joerg@dorchain.net>, 637856-done@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Sun, 29 Apr 2012 18:00:09 +0100
On Tue, Aug 16, 2011 at 08:53:24AM +0200, Joerg Dorchain wrote:
> On Mon, Aug 15, 2011 at 02:59:04PM +0100, Roger Leigh wrote:
> > I don't think this is an issue restricted to Debian--it is presumably
> > already broken on most other distributions as well?  This isn't a
> > recent change, or a change made in isolation.  AFAICT it was made
> > for FHS compliance reasons--nowadays /var/lock is used for a lot
> > more than just uucp, so expecting it to be owned by the uucp group
> > is, I think, unrealistic.  root:root or root:lock are the way things
> > have gone.
> 
> I use this application roughly every  other week, on a machine
> following testing, so I am quite sure the change happend in the
> last few weeks.
> 
> As said, root:lock ownership with group-write permissions is
> probably ok.

> > We don't currently permit changing of the ownership; the permissions
> > are entirely configurable in /etc/fstab.  You could use the tmpfs
> > uid= and gid=options to set the uucp group there.
> 
> Thanks for that hint.

Given that the above is a sufficient workaround for the problem,
I'm closing this bug.  (We can't change the defaults of the entire
distribution just for the sake a single broken bit of software.
Changing it would break even more programs in any case.)


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.




Message #36 received at 637856-done@bugs.debian.org (full text, mbox):

From: Joerg Dorchain <joerg@dorchain.net>
To: Roger Leigh <rleigh@codelibre.net>
Cc: Joerg Dorchain <joerg@dorchain.net>, 637856-done@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Sun, 29 Apr 2012 22:28:20 +0200
[Message part 1 (text/plain, inline)]
On Sun, Apr 29, 2012 at 06:00:09PM +0100, Roger Leigh wrote:
> 
> Given that the above is a sufficient workaround for the problem,
> I'm closing this bug.  (We can't change the defaults of the entire
> distribution just for the sake a single broken bit of software.
> Changing it would break even more programs in any case.)

I still think a /run/lock writeable by a lock group is a good
idea. Nevertheless I am fine with closing this bug report.
However, it might be an idea to mention the permissions settable
in /etc/fstab in a README.debian for the package might be useful,
too.

Bye,

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

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

From: Roger Leigh <rleigh@codelibre.net>
To: Joerg Dorchain <joerg@dorchain.net>
Cc: 637856-done@bugs.debian.org
Subject: Re: Bug#637856: /run/lock should be owned by uucp
Date: Sun, 29 Apr 2012 23:21:28 +0100
On Sun, Apr 29, 2012 at 10:28:20PM +0200, Joerg Dorchain wrote:
> On Sun, Apr 29, 2012 at 06:00:09PM +0100, Roger Leigh wrote:
> > 
> > Given that the above is a sufficient workaround for the problem,
> > I'm closing this bug.  (We can't change the defaults of the entire
> > distribution just for the sake a single broken bit of software.
> > Changing it would break even more programs in any case.)
> 
> I still think a /run/lock writeable by a lock group is a good
> idea. Nevertheless I am fine with closing this bug report.
> However, it might be an idea to mention the permissions settable
> in /etc/fstab in a README.debian for the package might be useful,
> too.

Yes, I'll open a separate bug report about that.

This is documented in fstab(5), and was updated in the version
of sysvinit currently in experimental, which should be in
testing/unstable soon.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 28 May 2012 07:36:24 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: Fri Apr 25 07:12:57 2014; Machine Name: buxtehude.debian.org

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