Re: ssl security desaster

[Florian Weimer]

* Florian Weimer:

> Well, you can send me the key in private if you want.  Let's see if I
> can factor it. 8-)

I got the key from Patrik, but it's not contained in my blacklist.  We
couldn't find a dowkd version that flagged the key as weak, nor could we
definitely confirm that the very same key was actually tested at the
time the alleged false positive occurred.

*sigh*


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Daniel Jacobowitz]

On Mon, May 26, 2008 at 05:52:13PM +0100, Darren Salt wrote:
> I demand that Alexander E. Patrakov may or may not have written...
> 
> > Joerg Jaspert wrote:
> >> That already has a problem: How to define "large"? One way, which we
> >> chose for now, is simply "everything > 50MB".
> 
> > Random thought: some architecture-dependent -dbg packages are also > 50 MB
> > in size. Shouldn't they get some special treatment, too?
> 
> -Zlzma? :-)

FYI, the most recent CVS snapshots of GDB can read zlib-compressed
debug info.  If someone gets around to an objcopy patch to create it,
then we can change debhelper to use it...

-- 
Daniel Jacobowitz
CodeSourcery


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Mike Hommey]

On Tue, May 27, 2008 at 02:05:02PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 26, 2008 at 05:52:13PM +0100, Darren Salt wrote:
> > I demand that Alexander E. Patrakov may or may not have written...
> > 
> > > Joerg Jaspert wrote:
> > >> That already has a problem: How to define "large"? One way, which we
> > >> chose for now, is simply "everything > 50MB".
> > 
> > > Random thought: some architecture-dependent -dbg packages are also > 50 MB
> > > in size. Shouldn't they get some special treatment, too?
> > 
> > -Zlzma? :-)
> 
> FYI, the most recent CVS snapshots of GDB can read zlib-compressed
> debug info.  If someone gets around to an objcopy patch to create it,
> then we can change debhelper to use it...

That would change installed size, not archive size. That'd still be
interesting, though.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483211: ITP: eboard-extras-pack2 -- Additional piece sets and sounds for eboard (pack 2)

[Patrik Fimml]

Package: wnpp
Severity: wishlist
Owner: Patrik Fimml <[EMAIL PROTECTED]>

* Package name: eboard-extras-pack2
  Version : 1
  Upstream Author : Felipe Bergo <[EMAIL PROTECTED]>
* URL : http://www.bergo.eng.br/eboard/
* License : GPL
  Programming Lang: N/A (only images and sounds)
  Description : Additional piece sets and sounds for eboard (pack 2)

This is the second extras pack for eboard, a popular chess interface. It
provides additional piece sets and sounds.

While I adopt eboard (bug #483054) and -extras-pack1 (bug #483164), I plan to
package this second extras pack as well.

Patrik


signature.asc
Description: Digital signature

Mouse configuration during installation needs improvement

[Stephen Powell]

Per the suggestion of Jérémy Bobbio when he closed Bug
# 481514 against installation-reports, I am posting
this item to the debian-devel mailing list.

The Debian installer needs some improvement when it
comes to mouse configuration.  Currently, if the user
requests a "standard system" and a "desktop
environment" in the Debian installer, the X Window
System will be installed in such a way that it drives
the mouse directly, rather than going through gpm; and
gpm is not installed.  I recommend that gpm be
installed whenever a mouse is detected on the system;
and if the X server is also installed, it should
always be configured to get mouse events from the gpm
daemon rather than drive the mouse directly.

This will allow the use of the mouse both in a virtual
console and in X.  Not only that, but "hot swapping"
the mouse will be far less disruptive for X users. 
When the X server drives a standard PS/2 mouse
directly, if the user unplugs the mouse and plugs in
another one while the system is running, he must stop
and restart the X server, losing all of his X
applications in the process, in order to regain the
use of the mouse.  But when using gpm, all he must do
is stop and re-start the gpm daemon to make the mouse
work again.  The X server is unaffected and the X
applications are unaffected.

With this recommendation, you should also move gpm to
CD-ROM number 1.



  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Florian Weimer]

* Joerg Jaspert:

> Any comments?

In the long term, I'd like to see a better CDN, so that such
considerations would magically disappear.

> Timeframe for this? I expect it to be ready within 2 weeks.

Oooh.  For a production-quality CDN, 2 years seem more reasonable.

I don't know the reason for this change.  If something needs to be done
about archive size, this may or may not be a reasonable approach,
depending on the amount of work required for implementation and the
actual savings in terms of main archive size.  But I feel like preaching
to the choir. 8-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Large data packages in the archive

[Raphael Geissert]

Daniel Jacobowitz wrote:
> 
> FYI, the most recent CVS snapshots of GDB can read zlib-compressed
> debug info.  If someone gets around to an objcopy patch to create it,
> then we can change debhelper to use it...
> 

What's the runtime cost?
Usually things get slower with such kind of changes.

Cheers,
Raphael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mouse configuration during installation needs improvement

[Lennart Sorensen]

On Tue, May 27, 2008 at 12:57:11PM -0700, Stephen Powell wrote:
> Per the suggestion of J?r?my Bobbio when he closed Bug
> # 481514 against installation-reports, I am posting
> this item to the debian-devel mailing list.
> 
> The Debian installer needs some improvement when it
> comes to mouse configuration.  Currently, if the user
> requests a "standard system" and a "desktop
> environment" in the Debian installer, the X Window
> System will be installed in such a way that it drives
> the mouse directly, rather than going through gpm; and
> gpm is not installed.  I recommend that gpm be
> installed whenever a mouse is detected on the system;
> and if the X server is also installed, it should
> always be configured to get mouse events from the gpm
> daemon rather than drive the mouse directly.
> 
> This will allow the use of the mouse both in a virtual
> console and in X.  Not only that, but "hot swapping"
> the mouse will be far less disruptive for X users. 
> When the X server drives a standard PS/2 mouse
> directly, if the user unplugs the mouse and plugs in
> another one while the system is running, he must stop
> and restart the X server, losing all of his X
> applications in the process, in order to regain the
> use of the mouse.  But when using gpm, all he must do
> is stop and re-start the gpm daemon to make the mouse
> work again.  The X server is unaffected and the X
> applications are unaffected.
> 
> With this recommendation, you should also move gpm to
> CD-ROM number 1.

With current kernels, if you use /dev/input/mice, the port can be shared
by gpm and X at the same time, and all mice you connect (no matter what)
show up in that device.  Of course PS/2 mice can not be connected while
the system is on, since the hardware simply is not designed for that (I
believe it can actually be damaged by trying although I have no seen it
happen.).  On a few systems it seems to work if you plug in a ps/2 mouse
on the fly, but on the vast majority it does not work until you reset
the system.  USB mice of course are hot plug and hence much simpler.

I like gpm, and use it, but I no longer point X at it like I used to
now that the kernel allows mouse sharing at all times (as long as you
don't try to use the obsolete /dev/psaux device to access the mouse).

gpm would also be on the first CD already, if lots of people used it.
Apparently they do not.

-- 
Len Sorensen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mouse configuration during installation needs improvement

[Joey Hess]

Lennart Sorensen wrote:
> With current kernels, if you use /dev/input/mice, the port can be shared
> by gpm and X at the same time, and all mice you connect (no matter what)
> show up in that device.  Of course PS/2 mice can not be connected while
> the system is on, since the hardware simply is not designed for that (I
> believe it can actually be damaged by trying although I have no seen it
> happen.).  On a few systems it seems to work if you plug in a ps/2 mouse
> on the fly, but on the vast majority it does not work until you reset
> the system.  USB mice of course are hot plug and hence much simpler.
> 
> I like gpm, and use it, but I no longer point X at it like I used to
> now that the kernel allows mouse sharing at all times (as long as you
> don't try to use the obsolete /dev/psaux device to access the mouse).
> 
> gpm would also be on the first CD already, if lots of people used it.
> Apparently they do not.

gpm also leads to a number of complications for some users, as seen in the 
BTS.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Availability of debian changelogs

[Michael Banck]

On Tue, May 27, 2008 at 03:53:48PM +0100, Don Armstrong wrote:
> On Tue, 27 May 2008, Eugene V. Lyubimkin wrote:
> >  It's not convenient to download 20M only for viewing a changelog -
> > i want look at changelog to decide, should i upgrade this package or
> > no.
> 
> In general you will be able to view them using packages.debian.org.
> There is just a delay while packages.debian.org rebuilds the
> changelogs. If that delay is unacceptable, then getting the package
> itself is the way around it. Otherwise, you can wait for p.d.o to
> catch up.

In my experience, packages.qa.debian.org/package is usually quite quick
to have the latest changelog, in form of the changes file.  The rest of
the changelog should be available via packages.debian.org.


Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ssl security desaster

[Colin Watson]

On Tue, May 27, 2008 at 05:49:59PM +0200, Patrik Fimml wrote:
> On Tue, May 27, 2008 at 04:51:36PM +0200, Florian Weimer wrote:
> > > Well, I actually had false positives (on amd64) -- even freshly
> > > generated keys with the new libopenssl package were reported as bad,
> > > which irritated me a bit.
> > 
> > And you've already deleted those keys, right?  How convenient. 8-/
> 
> No, actually, /all/ keys I generated were allegedly weak -- this means, after
> executing ssh-keygen and dowkd.pl five times, I stuck to the key.

This rings all my alarm bells. In similar cases I've had reported to me,
it always turned out that e.g. somebody had upgraded openssl but not
libssl0.9.8, or something similar.

> (ssh-vulnkey thinks it is fine though.)

While I'm very confident in ssh-vulnkey's accuracy, note that
ssh-vulnkey has two different states you might interpret as "fine": "Not
blacklisted" (i.e. definitely fine) and "Unknown (no blacklist
information)" (i.e. no blacklist file installed for this key type and
size). In the most recent upload to unstable, I clarified the second
state to "Unknown (blacklist file not installed)" and added more
detailed documentation in the manual page.

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)

[Colin Watson]

On Tue, May 27, 2008 at 01:45:25AM +0200, Klaus Ethgen wrote:
> Am Di den 27. Mai 2008 um  1:09 schrieb Colin Watson:
> > On Thu, May 15, 2008 at 09:15:57AM -0700, Mike Bird wrote:
> > > The rollout of information and updates was appalling - even adding in
> > > the material from Ubuntu the information was piecemeal and inadequate
> > > to properly secure systems within the limited time before crackers
> > > might be expected to have exploits.
> > 
> > I think part of the problem here was that the coordinated release date
> > for the advisory was simply too soon after the relevant parties were
> > notified.
> 
> Ehem, is it your idea of security to make it secret (like Microsoft do
> often)?

Well done; a straw man combined with an implication of an ad hominem.
That always really impresses me.

> It is never ever a good idea to make security issues secret or
> protracting it.
> 
> And in this special case it was easy to fix the problem very fast when
> the advisory cames out.

Let's say you'd been asleep at the time, and the advisory had laid out
everything necessary to make it trivial to produce an exploit (it could
easily have been much more explicit than it was, and even with limited
information it only took a day and a half to produce an exploit; a
couple of hours would not at all have been out of the question). Would
you still feel the same way if your accounts had been compromised?

If we had released any sooner, the OpenSSH blacklisting support would
not have been available, and every system administrator would have had
to figure out what was going on by hand rather than have the upgrade
automatically deny attempts to exploit this vulnerability. If we had
released later, a number of flaws in the blacklisting support could have
been fixed, alleviating a great deal of confusion among system
administrators (I spent considerable time that week supporting people
confused by the new tools), and I doubt it would have made much if any
difference to exploit production.

> > but I think an extra day or two on the embargo period would very
> > likely have produced a better result.
> 
> It is never a good idea to set a embargo period for a security issue.
> This is more valid for the scope of this big security problem!

If it had been released without an embargo, many more systems would have
been compromised, and (given the severity) it's entirely possible that
somebody would have managed to write a worm that took advantage of this
to seriously damage Internet infrastructure. It's as simple as that. We
used the embargo period to develop tools to help system administrators
defend themselves, not to sit in a smoke-filled room gloating that we
knew a secret and you didn't.

I believe wholeheartedly in full disclosure of all security problems.
Nothing else ultimately makes sense, particularly in the free software
world. That doesn't mean I think we have to actively help the black
hats; a few days of advance notice is just about all the advantage we
have, and we desperately need to make good use of it.

> All together I must say it was very professional and fast how the debian
> security team and other had done the treatment of the problem. Don't
> lower them by arguing with snakeoil about that the reaction was to fast!
> It can never be fast enough.

Note that I was myself heavily involved in producing some of the fixes
that went out in Debian security advisories. If the people directly
involved are not entitled to make comments on the process, who exactly
do you think is?

I think everyone involved did a wonderful job, especially given the
appalling constraints they were under. There is a difference, though,
between acknowledging the excellent work that was done and burying one's
head in the sand claiming that nothing could possibly have been
improved.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ssl security desaster (was: Re: SSH keys: DSA vs RSA)

[Martin Langhoff]

On Wed, May 28, 2008 at 11:13 AM, Colin Watson <[EMAIL PROTECTED]> wrote:
> I think everyone involved did a wonderful job, especially given the
> appalling constraints they were under. There is a difference, though,
> between acknowledging the excellent work that was done and burying one's
> head in the sand claiming that nothing could possibly have been
> improved.

A wonderful job indeed. *Thanks* from this corner of the world to the
Debian + Ubuntu team involved. The efforts in getting it all done
while balancing the maturity of the SSH blacklist patches & scripts vs
risk have been excellent.

It was a hard day for everyone else too, but it is clear that it would
have been much worse without such careful handling of the situation.

cheers,


m
-- 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian's eboard package

[Chris Bannister]

On Mon, May 26, 2008 at 04:07:55PM +0200, Patrik Fimml wrote:
> Hi,
> 
> the latest eboard package in unstable is version 1.0.3-1. It is rather
> unusable, because it keeps crashing frequently (#452686). Meanwhile, upstream
> has moved on to version 1.1.1, released three months ago.
> 
> I have tried to contact the maintainer on this issue four days ago, without
> reply to date.
> 
> However, seeing that the latest package is more than a year old, and there is
> a one-year-old bug constating the wish for a 1.0.4 package (#427434), it seems
> to me that the maintainer is not interested in the package.
> 
> As I frequently use eboard and have done some "hobby" packages before, I'd
> like to take care of the package. What exactly is the procedure to follow in
> this case?

Is xboard a suitable replacement?

-- 
Chris.
==
"One, with God, is always a majority, but many a martyr has been burned
   at the stake while the votes were being counted."  -- Thomas B. Reed


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Generated changes and patch systems

[Neil Williams]

On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-05-25 at 13:19 +0100, Mark Brown wrote:
> 
> >> If you run autotools at build time you should also ensure that the
> >> changes which autotools makes are reverted in the clean target.  This
> >> means that your diff doesn't get cluttered with automatically generated
> >> things and ensures that repeated builds of the package produce the same
> >> diff.gz.
> 
> > I haven't seen any other packages doing that - is there an example
> > involving aclocal.m4 somewhere?
> 
> Lots of other packages do this -- one of mine off the top of my head is
> xml-security-c.

Nope. No mention of aclocal.m4 in debian/rules for that package,
just /usr/share/misc/config.guess and config.sub.

I need to patch configure and configure.ac in this package, that means
that aclocal.m4 is constantly being changed and reverted. It shouldn't
matter - it really should not.

I see no purpose in lintian (or dpkg come to that) testing for changes
in aclocal.m4 - IMHO it should simply be exempt from this check. No
distro can risk patching aclocal.m4 - by it's nature it is transient and
volatile and subject to large changes entirely at the mercy of external
factors. Any build system that tries is simply going to break
constantly, AFAICT.

No matter how I wrap the cp foo foo.safe mv foo.safe foo in
debian/rules, the first build can be OK but all subsequent builds end up
with aclocal.m4 in the .diff.gz. Besides, replacing aclocal.m4 after it
has just been updated by ./configure is not a good idea to me.

> > I really don't want to do all that for the tmpl/* files as well - I
> > don't see the need, copying dozens of files into foo.safe or
> > foo.upstream and then moving them back?
> 
> Just delete them then.

??? That simply does not work. The problem is that running gtk-doc not
only requires tmpl/*.sgml files to exist but it *then modifies them*!
Even though I don't install these files into the package, I cannot
delete them and I cannot move them out of the way or the documentation
is not updated. Again, first build can be OK, second build generates a
dozen spurious warnings (because the files are modified after
the .diff.gz is created but cannot be reliably reverted before the next
build).

I don't see that I should provide out-dated documentation (by dropping
--enable-gtk-doc) just because it suits lintian - neither can I patch
the updates because the updates themselves are generated by a third
party tool so I can neither control the changes made nor maintain
"clean" patches. I suspect the issue arises because upstream happen to
prepare the release tarballs on Ubuntu or Fedora where the tool version
differs. The precise reason is inconsequential - the problem is that
Debian should not need to care about these modifications. It's taking
'divergence' one stage too far.

With these gtk-doc files, it's not so much that the tmpl/*.sgml files
are generated but that a tool essential to the build modifies them in a
way that cannot be patched because the results of the patches are
variable according to that third party tool. The changes then affect the
files that are packaged. Some of these are formatting changes -
whitespace changes, extra lines, comment changes. Other changes cause
sections or entire pages to migrate within the final files. The "sense"
of the docs doesn't appear to change, just the internal structure - as
determined by the differing versions of the tools used.

The CDBS build doesn't do anything different - it's just that lintian
doesn't produces any warnings for this check in CDBS packages, ever.

> The point is to not put mechanically generated changes in the diff, since
> it makes it much harder to review what the maintainer has actually done.

I don't see how it can be prevented. Take a look at the current .diff.gz
for libgpewidget 0.115-5 in the archive.

> I think most people take the approach of just deleting such files in the
> clean target, which will exclude their changes from the diff.

Sorry, it is not as simple as that - the package simply won't build if
tmpl/*.sgml are removed, no rule to make tmpl/*.sgml.

The tmpl/*.sgml files cannot be cleaned and removing aclocal.m4 is
simply pointless (and creates an even larger .diff.gz).

I still don't see what problem this test is trying to solve - AFAICT the
problem didn't exist in the first place and all this extra work appears
pointless.

I still think patch-system-but-direct-changes-in-diff should be
downgraded to info only, if kept at all.

I fail to see what I'm doing wrong - or even why it matters to lintian.

We risk swapping a minor problem that only occurs when the maintainer
upgrades from one version to another (and which could be fixed by
dpkg-source ignoring changes to generated files in the .diff.gz or not
applying generated changes that do exist in the .diff.gz) for a major
FTBFS error every time some random third party package is updated by
erron

Re: Generated changes and patch systems

[Russ Allbery]

Neil Williams <[EMAIL PROTECTED]> writes:
> On Sun, 2008-05-25 at 08:40 -0700, Russ Allbery wrote:

>> Lots of other packages do this -- one of mine off the top of my head is
>> xml-security-c.

> Nope. No mention of aclocal.m4 in debian/rules for that package,
> just /usr/share/misc/config.guess and config.sub.

Uh, it's the same problem.  Surely the generalization is obvious?

I guess look at shibboleth-sp if it's not

> I need to patch configure and configure.ac in this package, that means
> that aclocal.m4 is constantly being changed and reverted. It shouldn't
> matter - it really should not.

Right, so delete it in the clean rule.

> I see no purpose in lintian (or dpkg come to that) testing for changes
> in aclocal.m4 - IMHO it should simply be exempt from this check.

Absolutely not -- you're introducing unexpected changes to the packaging
diff file, and that's exactly the point of this check.  Delete the
modified and regenerated files in the clean rule and then you won't have
this problem.

> No distro can risk patching aclocal.m4 - by it's nature it is transient
> and volatile and subject to large changes entirely at the mercy of
> external factors. Any build system that tries is simply going to break
> constantly, AFAICT.

Exactly, which is why lintian is making sure that you don't introduce
patches to it in your *.diff.gz inadvertantly, since it's not a sane thing
to do when you're using a patch system.  The preferred method to handle it
as far as I'm concerned is doing what you're doing -- running autotools at
build time.  In that case, you need to remove the regenerated files in
your clean rule.  The other way to do it, particularly if you need a very
specific version of autotools, is to run them yourself and save them as a
patch, but I think that's a bad idea except in very specific situations.

>>> I really don't want to do all that for the tmpl/* files as well - I
>>> don't see the need, copying dozens of files into foo.safe or
>>> foo.upstream and then moving them back?

>> Just delete them then.

> ??? That simply does not work. The problem is that running gtk-doc not
> only requires tmpl/*.sgml files to exist but it *then modifies them*!

This is extremely unusual.  Are you *sure* that it does an inplace edit of
the files during the build process?  This is almost never what build
systems do; instead, they generate files from other files using templating
systems.  They may ship the results of that operation and then redo it
during the build, in which case you need to delete the regenerated files
in your clean rule.

If they really expect the files to exist and to edit them in-place during
the build, upstream is doing something insane, and it's really something
that should be fixed upstream; a lintian warning is drawing your attention
to a very broken behavior.

> Even though I don't install these files into the package, I cannot
> delete them and I cannot move them out of the way or the documentation
> is not updated. Again, first build can be OK, second build generates a
> dozen spurious warnings (because the files are modified after the
> .diff.gz is created but cannot be reliably reverted before the next
> build).

Right, lintian is diagnosing build system brokenness.  I'm fairly happy
with lintian's behavior here; what it's drawing attention to is exactly
the kind of thing that breaks repeated package builds or causes NMUs to
introduce spurious package diffs, and is something that should really
ideally be fixed.

> With these gtk-doc files, it's not so much that the tmpl/*.sgml files
> are generated but that a tool essential to the build modifies them in a
> way that cannot be patched because the results of the patches are
> variable according to that third party tool.

If the tool behaves and only behaves in that way (I haven't checked), that
tool is broken and we should fix that tool.

> The CDBS build doesn't do anything different - it's just that lintian
> doesn't produces any warnings for this check in CDBS packages, ever.

Well, yes, it does, if CDBS uses a recognized patch system, but the list
of patch systems that lintian recognizes is fairly limited at this point.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]