dselect/dpkg & multiple versions

[Brian C. White]

I know that at one point the dselect/dpkg combination had fairly serious
problems if the same package name existed with multiple versions.  I learned
this the hard way when I installed from a mirror that had not run to
completion and thus had not deleted the older packages.

Dpkg installed _both_ versions of the packages at the same time and really
got screwed up.

The reason I bring this up is that there are now several package that are
_intentionally_ in the distribution multiple times with different versions:

  Debian-1.1-fixed/binary-i386/text/gs_2.62-2.deb
  non-free/binary/gs_4.01-2.deb

  Debian-1.1-fixed/binary-i386/text/gsfonts_2.62-2.deb
  non-free/binary/gsfonts_3.53-3.deb

  Debian-1.1-fixed/binary-i386/tex/lyx_0.9.23-1.deb
  contrib/binary/lyx_0.10.1-1.deb

These are already causing a bit of a problem with 'dftp' and I'm wondering
if they are/will cause problems with dselect/dpkg.


*** Bruce ***
What's the "official" word on duplicate packages this way?
 
  Brian
 ( [EMAIL PROTECTED] )
 
---
In theory, theory and practice are the same.  In practice, they're not.

Re: dselect/dpkg & multiple versions

[Bruce Perens]

> *** Bruce ***
> What's the "official" word on duplicate packages this way?

Ian Jackson wields the fiat power where software packaging is concerned.

Try dpkg_1.3.9 (or whatever version is now in incoming). Make up a good
test case and report the results as a bug.

Thanks

Bruce

Bug#4328:

[Larry 'Daffy' Daffner]

Package: util-linux
Version: 2.5-5

If clock is invoked with the -u flag and the kernel has the real time
clock enabled, it causes a segmentation fault.  omitting the -u flag
or running a kernel with the real time clock disabled will not cause
the problem.

I don't have the strace handy, but I can provide it if needed.

Debian version: rex-current

uname -a:
Linux pinky 2.0.13 #13 Sun Aug 25 09:59:02 CDT 1996 i486

libc: 5.2.18

-Larry

PGP depends.

[Dale Scheetz]

I bit the bullet today and decided to install and implement pgp. Searching
the packages files did not turn it up, but I was able to deduce that it
was therefore, in non-free. However the search turned up this information:

mailcrypt  -  depends: pgp
dchanges   -  recommends: pgp
elm and w3-el  -  suggests: pgp

Now, as it happens, I have also been reading the new Policy manual (BTW,
thank you Ian J. for this fine piece of work. It has been long needed and
I for one greatly appreciate your work) and it has some things to say
about this issue. In particular it says that packages that depend on
packages in non-free are to reside in contrib (or non-free if other
restictions apply). This makes it clear that mailcrypt should be in
contrib rather than the distribution proper. It isn't specific about those
packages that recommend or suggest a non-free package, but at least
recommend is strict enough to require special intervention with dselect in
order to install a package without it's recommends. The policy on these
conditions should be made more clear.

Thoughts?

Dwarf

  --

aka   Dale Scheetz   Phone:   1 (904) 877-0257
  Flexible Software  Fax: NONE 
  Black Creek Critters   e-mail:  [EMAIL PROTECTED]

 If you don't see what you want, just ask --

Bug#4329: Emacs has hardcoded path for jka-compr, breaks at upgrade

[Ian Jackson]

Package: emacs
Version: 19.31-2

I just upgraded from 19.29-3, and it left me with the following
/etc/site-start.el:
 (load "/usr/lib/emacs/19.29/lisp/jka-compr.elc")
 (if (file-exists-p "/usr/lib/emacs/site-lisp/w3-init.el") (load "w3-init"))
 (autoload 'lout-mode "lout-mode" "Mode for editing Lout source" t)
 (setq auto-mode-alist (append '(("\\.lout$" . lout-mode)) auto-mode-alist))
 (require 'vm-init)

This caused Emacs to fail to start because of the changed version
number in the pathname for jka-compr.

IMO this entry should not have used an absolute pathname, rather, it
should rely on the load-path.

If it did need an absolute pathname the Emacs postinst should have
fixed it up.

Ian.

Bug#4060: Update: 4060 - Kernel decompression failure.

[Bruce Perens]

[EMAIL PROTECTED] (Christopher R. Hertel)  wrote on 12.08.96 in <[EMAIL 
PROTECTED]>:

> Problem: On some systems, the compressed kernel image provided on the
> installation floppy (boot1440.bin) is not decompressed properly when
> read from floppy.  One solution that seems to work for most users is to
> *disable the internal cache*...

Kai:
> If disabling the cache makes a difference, this is almost certainly a  
> hardware problem.

We can, however, probably work around it, and if we can we should.

The suspicion is that we have to invalidate the CPU cache around the switching
of the A20 gate, and perhaps around the jump from 16-bit to 32-bit code
in /usr/src/linux/arch/i386/boot/setup.S . I am no 486 assembler expert, and
I am too busy with other stuff to do this. Any volunteers? Chris is able to
test it if you can hack up a kernel with the appropriate instructions inserted.

Thanks

Bruce

Re: BSD lpr vs. LPRng

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:
: 
: The only incompatibility is that you might have to add a :bk: entry to
: the printcap in order to print to a BSD-lpd-based network printer. 

I care a lot about compatibility with other BSD'ish lpd-based systems.  I 
could live with this easily.

Bdale

Re: PGP depends.

[Guy Maor]

On Wed, 28 Aug 1996, Dale Scheetz wrote:

> In particular it says that packages that depend on
> packages in non-free are to reside in contrib (or non-free if other
> restictions apply).

I've also been meaning to bring this up, but from another angle.
Previously, Ian, you've said that packages which depend on a non-free
package must be put in non-free, hence the current location.

The reasoning behind this is that a CD would typically have no non-free
packages.  Selecting mailcrypt would apparently confuse dselect as it
would not be able to find pgp.

I just wanted to confirm that dselect would not have problems with
moving mailcrypt and other such packages into contrib.


Guy

Re: dselect/dpkg & multiple versions

[Guy Maor]

On Wed, 28 Aug 1996, Brian C. White wrote:

> The reason I bring this up is that there are now several package that are
> _intentionally_ in the distribution multiple times with different versions:
> 
>   Debian-1.1-fixed/binary-i386/text/gs_2.62-2.deb
>   non-free/binary/gs_4.01-2.deb

This is the only intentional duplication.  Some discussion is pending
on whether to rename one of them.

>   Debian-1.1-fixed/binary-i386/text/gsfonts_2.62-2.deb
>   non-free/binary/gsfonts_3.53-3.deb
> 
>   Debian-1.1-fixed/binary-i386/tex/lyx_0.9.23-1.deb
>   contrib/binary/lyx_0.10.1-1.deb

These duplications are temporary.  The new Alladin gsfonts will soon be
in the main distribution as it can be.  And lyx has moved to contrib.
There's a bug pending on ftp.debian.org for me to correct the packages
that have moved out of the main distribution in buzz.

> These are already causing a bit of a problem with 'dftp' and I'm wondering
> if they are/will cause problems with dselect/dpkg.

I suggest you use dpkg-ftp instead of dftp.


Guy

Bug#4305: metmail uses non-existent flag in postinst

[Michael Meskes]

Susan G. Kleinmann writes:
> (Perhaps this should be a seperate bug report; if you want one, please
> let me know.)

No, it's not a bug I think.

> [...]
> New action 'view' for MIME type 'image/*'...
> --> package=metamailview=showpicture -viewer "xloadimage -view 
> -quiet" %s
> 
> 1)  package=metamailview=showpicture -viewer xv %s
> 
> Place at what priority? (1-2) -->1
>  ^^^<--- Notice that these indices do not match
>  the choices above ["-->" and "1)"] 

Where's th problem? You can install it as priority 1  (and thus moving
'showpicture -viewer xv %s' to 2) or you install it as 2 (and let
'showpicture -viewer xv %s' be 1). There are two lines given. Thus you need
two priorities.

> [...]
> This seems to be a problem with install-mime; or perhaps I did 

Yes, that's right. My metamail package just calls install-mime.

Michael


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

anybody debianizing qt?

[Heiko Schlittermann]

Hello out there ...

perhaps I've missed an announcement or similar.  Just I've downloaded
qt-0.98, a C++ Class Library for GUI development (X11, WinNT, other?).

The library (and source) seems to be free for X11 && devel of free
software.  As time of this writing the libs get compiled.  Some two
minor Makefile-Patches were necessary and now the tutorials and examples
run.

Now my question:  Is anybody out there already debianizing this library?

[ BTW: Source & Binary RPMs exist already ... ]
[ For further information I'll append the announcement from c.o.l.a. ]

Heiko
--
email : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
pgp   : A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 
finger: [EMAIL PROTECTED] [EMAIL PROTECTED]


From: [EMAIL PROTECTED]
Newsgroups: comp.os.linux.announce
Subject: Qt 0.98 - object-oriented C++ framework for GUI apps
Followup-To: comp.os.linux.development.apps
Date: Sat, 13 Jul 1996 11:21:39 GMT
Organization: Troll Tech AS, fax +47 22646949
Lines: 108
Approved: [EMAIL PROTECTED] (Lars Wirzenius)
Message-ID: <[EMAIL PROTECTED]>
NNTP-Posting-Host: localhost

-BEGIN PGP SIGNED MESSAGE-

Troll Tech is proud to relase a free version of Qt for the X Window
System. This release, Qt 0.98, is free for non-commercial use on all
operating systems that support the X Window System and includes the
complete Qt source code for X.

Qt 0.98 is intended as a bugfix release.

Qt 0.98 includes makefiles for Linux, Solaris, SunOS, FreeBSD and
OSF/1. New platforms will be added in the near future.  There are also
source and binary RPMs for linux.

Qt is a complete and well-developed object-oriented framework for
developing graphical user interface applications using C++. It has been
used professionally for over a year.

Qt has excellent documentation: 450 pages of postscript and fully
cross-referenced online html documentation. See it on the web:
http://www.troll.no/qt/

Qt is easy to learn, with consistent naming across all the classes and a
14-chapter on-line tutorial with links into the rest of the documentation.

Qt dramatically cuts down on development time and complexity in writing
user interface software for X-Windows.  It allows the programmer to focus
directly on the programming task, and not mess around with low-level X11
code.

Qt is fully object-oriented. All widgets and dialogs are C++ objects,
and, using inheritance, creation of new widgets is easy and natural.

Qt's revolutionary signal/slot mechanism provides true component
programming. Reusable components can work together without any knowledge
of each other, and in a type-safe way.

Qt has a very fast paint engine, in some cases ten times faster than
most other toolkits. You have full access to low-level painting
functionality. Painting is device independent, so the same code that draws
on the screen can generate printer output.  You can also do arbitrary
clipping, rotation, and scaling - simply and fast.

Qt is very fast and compact because it is based directly on Xlib and uses
neither Motif nor X Intrinsics.  Qt's widgets (user interface objects)
emulate the Motif look and feel, with slight improvements.

Qt is available under several licenses:

- for commercial use
- for use with free software (X only)
- for shareware developers (X only)

Note that the toolkit is the same, only the licenses differ.

The Qt GUI toolkit is copyright Troll Tech AS.  It is available (at the
time of writing) for Windows 95/NT and several variations of unix (X11
release 5 or later).  See http://www.troll.no/ for more availability
information, or fax Troll Tech at +47 22646949.

Qt can be downloaded from http://www.troll.no/dl/ or via anonymous FTP
from ftp.troll.no.

Join the qt-interest mailing list by sending a message containing the
single word "subscribe" to [EMAIL PROTECTED]

You can contact Troll Tech at

Troll Tech AS
Postboks 6133 Etterstad
N-0602 Oslo
Norway

fax: +47 22646949
email: [EMAIL PROTECTED]

And here is the LSM entry:

Begin3
Title:  Qt toolkit
Version:0.98
Entered-date:   11jul96
Description:C++ GUI class library with Motif look and feel
Keywords:   gui library motif c++
Author: [EMAIL PROTECTED]
Maintained-by:  [EMAIL PROTECTED]
Primary-site:   sunsite.unc.edu /pub/Linux/X11/devel
1248kB qt-0.98.tar.gz
Alternate-site: ftp.troll.no /qt/source
1248kB qt-0.98.tar.gz
Platform:   linux/X11R6
Copying-policy: freely distributable with certain restrictions
End

-BEGIN PGP SIGNATURE-
Version: 2.6.2i

iQCVAwUBMeeGAIQRll5MupLRAQEIzQP/c7oozBXhZfg2uspNjiDk1IsIgravAbP9
iWzL3eRy8kLntJ6XADn6svHGtQmgtVSpbHnVodQjFNeBpAgj0cCEfc/ZKAi+D5xT
xgiaykLVmFCcTF8sFAk5Q5Fs11Gi+P0TD2uuPUn4q9bBgv+YDeHblEnlZOVjly6z
cNIsQorcjZg=
=pxbj
-END PGP SIGNATURE-

-- 
This article has been digitally signed by the moderator, using PGP.
Finger [EMAIL PROTECTED] for PGP key needed for validati

ctags

[Heiko Schlittermann]

Hello,

to avoid duplicated effort ... is anybody out there already debianizing
the ctags package from Darren Hiebert <[EMAIL PROTECTED]>?

If not, I'd do it.

For further information about ctags I've appended posting to c.o.l.a.

[ And yes, I know of elvis-ctags, but it's up the user to evaluate which 
  is the true better ctags ... for me Darrens Ctags did it quite good. ]

Heiko
--
email : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
pgp   : A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 
finger: [EMAIL PROTECTED] [EMAIL PROTECTED]


Newsgroups: comp.os.linux.announce
Subject: Exuberant Ctags-1.4 - a better ctags
Followup-To: comp.os.linux.development.apps
Date: Tue, 27 Aug 1996 15:07:26 GMT
Organization: SIRSI Corporation
Lines: 146
Approved: [EMAIL PROTECTED] (Lars Wirzenius)
Message-ID: <[EMAIL PROTECTED]>
NNTP-Posting-Host: localhost

-BEGIN PGP SIGNED MESSAGE-

Announcing: Exuberant Ctags 1.4
Author: Darren Hiebert


Announcement

This is to announce an update of my new, better ctags utility. I am quite
pleased with it, and others who have used it have been enthusiastic about
the greater reliability and functionality it provides.

You can find it at:

sunsite.unc.edu:/pub/Linux/Incoming/ctags-1.4.tar.gz (for now)
or
sunsite.unc.edu:/pub/Linux/devel/lang/c/ctags-1.4.tar.gz (once moved)

and also at either of:

http://fly.hiwaay.net/~darren/ctags.html  (Official Web site)
ftp://ftp.halcyon.com/local/gvr/ctags-1.4.tar.gz


Changes since version 1.3:
==
 o  Added ability to recursively parse into class/struct/enum blocks to
look for nested class/struct/enum tags and enumeration values.

 o  Added feature to allow a specified list of tokens to be ignored while
parsing the file. This is particularly useful when prototyping macros
appear before the parameter list.

 o  Corrected problem where declaring a pointer const or volatile resulted
in no tag being generated.

 o  Correction to bug causing a function tag to be generated for comma
terminated function declarations.

 o  Various portability changes.


What is ctags?
==
Ctags generates an index (or "tag") file of C language objects found in a
set of file that allows these items to be quickly and easily located by a
text editor or other utility. A "tag" signifies a C language object for
which an index entry is available (or, alternatively, the index entry
created for that object).

Alternatively, ctags can generate a cross reference file which lists, in
human readable form, information about the various objects found in a set
of C language files.

Tag index files are supported by the vi(1) editor and its derivatives
(such as vim, elvis, stevie, xvi, and others) through the use of the ":ta"
command, which locates the object associated with a name appearing in a
source file and jumps to the file and line which defines the name.


What makes this ctags desirable?

1.  It can find *all* types of C language tags, including all of the
following:

macro definitions
enumerated values (values inside enum{...})
function and method definitions
enum/struct/union tags
external function prototypes (optional)
typedefs
variable declarations

2.  It is far less easily fooled by code containing #if preprocessor
conditional constructs, using a conditional path selection algorithm
to resolve complicated choices, and a fall-back algorithm when this one
fails.

3.  Can also be used to print out a list of selected objects found in source
files.

4.  Supports UNIX, MSDOS, WindowsNT, Windows95, OS/2 and the Amiga. In some
cases, you may need to play with the include files, depending upon you
compiler. Some pre-compiled binaries may become available on the web site.

I wrote this because of my disappointment with the other ctags utilities that
are available. However, it does have a couple of minor limitations (you be the
judge):

1)  Support for C++ is limited.
2)  Supports only C; not Lisp, shell scripts, or anything else you might
think of.


LSM Entry:
==
Begin3
Title:  Exuberant Ctags
Version:1.4
Entered-date:   20AUG96
Description:A better ctags which generates tags for all possible tag
types: macro definitions, enumerated values (values inside
enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes (optional), typedefs, and 
variable declarations. It is far less easily fooled by code
containing #if preprocessor conditional constructs, using a
conditional path selection algorithm to resolve complicated
choices, and a fall-back algorithm when this one fails. Can
also be used to print out a list of select

Bug#4316: cron -- crontab -l prints excess header

[Lars Wirzenius]

"Brian C. White":
> Could you write them to STDERR and the rest of the info to STDOUT?

An option to suppress them might be better.

> I thought about this, but it requries my script to know about the
> internals of crontab.  If crontab ever changed, then a problem could
> arise.  I prefer to keep related functionality as together as possible.

I can't remember that I've seen the extra header for other cron's. That
means that the scripts need to be modified when moving them from or to
a Debian system. Not a good idea, generally.

I don't think doing "crontab -l > foo; crontab foo" should modify the
crontab. That's counter-intuitive.

-- 
Please read  before mailing me.
Please don't Cc: me when replying to my message on a mailing list.




pgpmkzHP8d88c.pgp
Description: PGP signature

Bug#4330: amd hangs system

[Tim Wadsworth]

Package: amd
Version: upl102-3

Hi,

I am running the amd ("The 4.4BSD automounter") under Debian Linux
to mount users' home directories (and other shared filesystems).

The problem is that certain filesystems cause amd to lock up the
system, whereas mounting them using "mount" works fine. Other
filesystems work without any problems.

Amd appears to fork - presumably the child process attempts to perform 
the mount. Killing the "login" process, and the child "amd" process 
allows the system to run normally again, but attempting to access the 
same automount point again causes the behaviour to be repeated.
Any attempt to access any automount points from a shell just hangs the
shell (CTRL-C doesn't even get the prompt back).

The log messages do not shed any light on the problem. Eventually a
"fileserver xxx not responding still trying" appears, but the
fileserver itself is actually fine.

I'm using Debian 1.1, 2.0.0 kernel, libc.so.5.2.18

Amd is also used here on SunOS 4.1.3 and Solaris, and works without
this problem. I am using a direct copy of the map files.

The same problem occurs using Slackware and RedHat Linux and on 
different hardware. 

TIm.

Re: anybody debianizing qt?

[Sven Rudolph]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Heiko Schlittermann) writes:

> perhaps I've missed an announcement or similar.  Just I've downloaded
> qt-0.98, a C++ Class Library for GUI development (X11, WinNT, other?).
> 
> The library (and source) seems to be free for X11 && devel of free
> software.  As time of this writing the libs get compiled.  Some two
> minor Makefile-Patches were necessary and now the tutorials and examples
> run.
> 
> Now my question:  Is anybody out there already debianizing this library?

Lee Olds <[EMAIL PROTECTED]> works on it. Ask him about the current state.

Sven
-- 
Sven Rudolph <[EMAIL PROTECTED]> ; WWW : http://www.sax.de/~sr1/

Bug#4331: [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp (fwd)

[Marek Michalkiewicz]

Package: wu-ftpd
Version: 2.4-23

I don't know the exploit, but tar in the anon ftp area is the
same as the normal one, so I think Debian systems may have this
problem too.  Two messages from the linux-security list (the
second one includes a patch for tar - only for anon ftp, not
for the normal one!) are attached below.

Marek

From: Elliot Lee <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp
Date:   Mon, 19 Aug 1996 18:57:03 -0400 (EDT)

-BEGIN PGP SIGNED MESSAGE-

There is a security hole in the anonftp package included with all versions
of Red Hat Linux that allows an anonymous FTP user to execute arbitrary
commands in the chroot FTP environment. Due to some options in GNU tar
that are enabled by default, any program that exists (or can be uploaded
to) an FTP server can be run.

Severity is limited due to the chroot environment, but the problem still
needs to be addressed.

Updates are available on ftp.redhat.com now.

If you are using a version prior to 3.0.3, an upgrade is recommended to
solve other security holes.

If you are using 3.0.3 on the Intel, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/i386/updates/RPMS/anonftp-2.0-2.i386.rpm
and install it using 'rpm -Uvh [filename]'

If you are using 3.0.3 on the Alpha, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/axp/updates/RPMS/anonftp-2.0-2.axp.rpm
and install it using 'rpm -Uvh [filename]'

If you are using 3.0.4 (Rembrandt BETA) on the Intel, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/i386/updates/RPMS/anonftp-2.2-2.i386.rpm
and install it using 'rpm -Uvh [filename]'

If you are using 3.0.4 (Rembrandt BETA) on the Sparc, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/sparc/updates/RPMS/anonftp-2.2-2.sparc.rpm
and install it using 'rpm -Uvh [filename]'

All packages are PGP signed. Source packages are available in the usual
locations.

MD5 checksums:

ea1798199eb426695c6d4c2ad4106422  anonftp-2.0-2.axp.rpm
764ee004e25c3e278290820dbd58cc58  anonftp-2.0-2.i386.rpm
cb0b1905ab8d389d64677519913346a5  anonftp-2.0-2.src.rpm

c14af78ec7d5083b54e61f973ca7c6fb  anonftp-2.2-2.i386.rpm
760cb3d5bb37c618f1b84f1aa0f5ea53  anonftp-2.2-2.sparc.rpm
a2f3fb6e06fca1485e3f11e5e04f83d8  anonftp-2.2-2.src.rpm

Thanks to Alan Cox for finding this problem.

- -- Elliot Lee <[EMAIL PROTECTED]>
   Red Hat Software, http://www.redhat.com/

-BEGIN PGP SIGNATURE-
Version: 2.6.2

iQCVAwUBMhjxQiaSlK8942+NAQEngAQAgQDpcY4zYyvegaYQrAx1pW9w2IEeHqE5
yyeRre2rUsWBKVjizDttz+JO130+/2cZjjG0bpDzKeZidkENZGkHzlIP+lQLDAuG
jZ8rBqAdaEXmRUwZJzjwmEfBM218Z/W+fSrPj/w0CMqCn1THwJN4Vu6xaZ8TkxGf
2cI2lMO7XkQ=
=qu3w
-END PGP SIGNATURE-

Date:   Wed, 21 Aug 1996 10:05:52 -0400 (EDT)
From: Elliot Lee <[EMAIL PROTECTED]>
To: Roscinante <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: [linux-security] Re: Anon ftp pkg?

On Wed, 21 Aug 1996, Roscinante wrote:

> Does the updated anonftp pkg have a fixed version of tar?

Yes, that's all that changed :-)

> I've been trying all night to get rpm working on my slack system, am I
> wasting my time (someone told me all thats in the updated anonftp pkg is
> a config script)? 

No.

>  Are there options in tar that should be disabled at compile time?
> What options are exploitable? Please cc me directly.

I have attached a patch to tar that you can compile tar with to fix it.

Hope this helps,
 -- Elliot Lee = <[EMAIL PROTECTED]> == Red Hat Software --
"Usenet is like a herd of performing elephants with diarrhea; massive,
 difficult to redirect, awe-inspiring, entertaining, and a source of
 mind-boggling amounts of excrement when you least expect it."

--- tar-1.11.8/src/tar.c.sopwithSat Jun 17 16:48:32 1995
+++ tar-1.11.8/src/tar.cMon Aug 19 12:19:16 1996
@@ -22,6 +22,8 @@
 
 #include "system.h"
 
+#include 
+
 #ifndef FNM_LEADING_DIR
 # include 
 #endif
@@ -1202,14 +1204,19 @@
break;
 
   case OPTION_COMPRESS_PROG:
-   if (flag_compressprog)
- ERROR ((TAREXIT_FAILURE, 0,
- _("Only one compression option permitted")));
-   flag_compressprog = optarg;
+   openlog("ftp tar", 0, LOG_DAEMON);
+   syslog(LOG_WARNING,"Attempt to run tar via FTP with compress command 
%s",
+   optarg);
+   closelog();
+   flag_compressprog = NULL;
break;
 
   case OPTION_RSH_COMMAND:
-   flag_rsh_command = optarg;
+   openlog("ftp tar", 0, LOG_DAEMON);
+   syslog(LOG_WARNING,"Attempt to run tar via FTP with rsh command %s",
+   optarg);
+   closelog();
+   flag_rsh_command = NULL;
break;
 
   case 'g':

Bug#4332: Vulnerability in the Xt library (fwd)

[Marek Michalkiewicz]

Package: xlib
Version: 3.1.2-7

It seems there is a buffer overrun in libXt, which may be a security
hole (some programs using libXt, such as xterm, are setuid root).
I haven't tried to exploit it, but xterm -fg very_long_string
segfaults, so it might be exploitable (stack overwrite).  See the
attached message (which appeared on the bugtraq list) for a patch.

I haven't verified that the fix is indeed in XFree86-3.1.2F (just
released) - can't get to ftp.xfree86.org right now (too many users)
and can't find this version on mirror sites yet.

Marek

> Date: Sun, 25 Aug 1996 22:05:16 -0700
> From: Ollivier Robert <[EMAIL PROTECTED]>
> Subject:  Re: Vulnerability in the Xt library (fwd)
> To: Multiple recipients of list BUGTRAQ <[EMAIL PROTECTED]>

> According to John Capo:
> > Stefan `Sec` Zehl writes:
> > > I can confirm this for Freebsd 2.2-Current, it gives me a euid=0 /bin/sh
> 
> > I can also.  The xterm cores on -stable though.
> 
> I sent a patch and a portable version of snprintf to both the X consortium
> and Xfree86 yesterday. It will be in 3.1.2F.
> 
> If you have XFree sources on-line and are willing to recompile, apply the
> following patch in xc/lib/Xt:
> 
> --- Error.c.old Sun Aug 25 14:57:28 1996
> +++ Error.c Sun Aug 25 14:47:14 1996
> @@ -238,5 +238,5 @@
> (void) memmove((char*)par, (char*)params, i * sizeof(String) );
> bzero( &par[i], (10-i) * sizeof(String) );
> -(void) sprintf(message, buffer, par[0], par[1], par[2], par[3],
> +(void) snprintf(message, sizeof message, buffer, par[0], par[1], 
> par[2], par[3],
>par[4], par[5], par[6], par[7], par[8], par[9]);
> XtError(message);
> @@ -263,5 +263,5 @@
> (void) memmove((char*)par, (char*)params, i * sizeof(String) );
> bzero ( &par[i], (10-i) * sizeof(String) );
> -(void) sprintf(message, buffer, par[0], par[1], par[2], par[3],
> +(void) snprintf(message, sizeof message, buffer, par[0], par[1], 
> par[2], par[3],
>par[4], par[5], par[6], par[7], par[8], par[9]);
> XtWarning(message);
> 
> --
> Ollivier ROBERT-=- The daemon is FREE! -=-[EMAIL PROTECTED]
> FreeBSD keltia.freenix.fr 2.2-CURRENT #18: Sun Aug 18 19:16:52 MET DST 1996
> 

Bug#4190: Bug4190: serious security hole in libc (resolver)

[Marek Michalkiewicz]

Hi,

is there any way to change the subject line of an already existing
bug report?  This hole is a really *serious* (not moderate) one -
it lets any local and remote users read any file on the system.

I think there are two possible ways to fix it:
(1) ignore the dangerous environment variables completely (is anyone
actually using them?  I heard about them for the first time from
the security alert...).  If anyone needs these features - create
a separate full-featured resolver library people can use (for
non-setuid programs only) by setting LD_PRELOAD.

(2) ignore them if (geteuid() != getuid() || getegid() != getgid()).
Problem: you can pass them to login via telnetd, so telnetd
needs to be fixed too.  Anyway, I think telnetd should do what
the one in NetKit-0.08 does: allow only a few (known to be safe)
environment variables, and don't allow the rest.  Right now, we
check for a few variables known to be dangerous - and we can't
be sure that there are no more.  The bash man page mentions
BASH_ENV in one place, and it's not checked by telnetd.

Marek

Re: dpkg-buildpackage and -source questions

[Ian Jackson]

Karl Sackett writes ("dpkg-buildpackage and -source questions"):
> Regarding the -r option for dpkg-buildpackage, are there any
> examples of what's called for here?  Is the gain-root-command
> something each developer provides for himself, or is there a command
> or shell somewhere that performs this function?

How to get root is a piece of local policy, so you provide it
yourself.  It's possible that `su' or `sudo' or `really' or `super'
may be available to you and DTRT.

> Invoked as root, dpkg-buildpackage works fine.  But when I try to unpack the
> new package this is what happens:
> 
> mycroft$ dpkg-source -x exmh_1.6.9-1.dsc
> dpkg-source: error: tarfile `./exmh_1.6.9.orig.tar.gz' contains object with
> newline in its name 
> (exmh-1.6.9.orig/?exmh-1.6.9.orig/exmh.README?exmh-1.6.9.or
> ig/COPYRIGHT?exmh-1.6.9.orig/e...(rest of output deleted)
> 
> This happens with the packages I build and with the hello package I downloaded
> from  master.

Needless to say this doesn't happen to me.  I think your cpio or your
perl is broken.

Please send me by private email the output of the following commands
(feeding it to sh and sending me all the output concatenated is fine):
  md5sum exmh_1.6.9.orig.tar.gz
  zcat exmh_1.6.9.orig.tar.gz | md5sum
  cpio --version
  perl -v
  type cpio perl
  which cpio perl
  dpkg -s cpio perl
  echo -e 'ab\0cd\0' | perl -e '$/="\0";while(<>){print">$_<\n";}' | cat -vET
  zcat exmh_1.6.9.orig.tar.gz | cpio -0t | uuencode cpio-0t
  gzip -9v <`type -p cpio` | uuencode cpio.gz
(If you want to MIME-attach it make sure that the file is in
`Content-Transfer-Encoding: 7bit'.)

Thanks,
Ian.

Bug#4333: telnetd should be more paranoid about environment

[Marek Michalkiewicz]

Package: netstd
Version: 2.06-1

Right now, telnetd checks for a few dangerous environment variables.
I think it should do what telnetd in NetKit-0.08 does: only allow
a few variables which are known to be safe, and don't allow any
others.  The problem is that you never know that the list of the
dangerous variables is complete.

For example, we check for ENV, but not for BASH_ENV (mentioned in
the bash man page in one place - GNU creeping featurism strikes
again, argh), and also not for RESOLV_HOST_CONF and a few others.
NetKit-0.08 telnetd only allows DISPLAY, TERM, USER, LOGNAME and
POSIXLY_CORRECT.  I think we should do the same (ideally, the list
should be made configurable without recompiling, but that can be
done later).

Marek

Bug#4334: squid should not run as root by default

[Marek Michalkiewicz]

Package: squid
Version: 1.0.beta16-1

In the default configuration, squid runs as root.  While it can be
changed in the config file, someone might forget to configure it
after installation, so I think the default should be secure.  The
permissions/ownerships in /var/squid and /var/log/squid should be
changed accordingly.  I think squid should ideally run under its
own allocated UID/GID.

Marek

Bug#4335: cat -vET is lossy - there should be a non-lossy version

[Ian Jackson]

Package: textutils
Version: 1.17-2

-chiark:~> echo -e 'hi^IthereM-z\011hi' | cat -vET
hi^IthereM-z^Ihi$
-chiark:~>

As you can see, it's not possible to distinguish a single escaped
control character ^ or M- from the corresponding
sequence of printable characters.

There should be an option to do a reversible transformation.  I don't
particularly care what the transformation is, provided that it's not
insane.

Ian.

netcdf-perl_1.1-1 uploaded

[Brian Mays]

-BEGIN PGP SIGNED MESSAGE-

Format: 1.5
Date: Sat, 24 Aug 1996 08:07:03 -0400
Source: netcdf-perl
Binary: netcdf-perl
Architecture: source i386
Version: 1.1-1
Distribution: unstable
Urgency: low
Maintainer: Brian Mays <[EMAIL PROTECTED]>
Description: 
 netcdf-perl - A perl extension for accessing netCDF datasets.
Changes: 
 netcdf-perl (1.1-1) unstable; urgency=low
 .
   * Initial Debian release.
Files: 
 2a8f07d49f2c66ffd7acfe8158154556 608 misc extra netcdf-perl_1.1-1.dsc
 dd2acf5b912374b8cb1d73203c3f8221 53781 misc extra netcdf-perl_1.1.orig.tar.gz
 5117b3d6e1317540b0bd58afe782 3309 misc extra netcdf-perl_1.1-1.diff.gz
 334dc8facadff637e6a92812ab5e3fa5 47680 misc extra netcdf-perl_1.1-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2

iQCVAwUBMiSDLvrhbOLeJ39FAQElBAP9Gyn1WW4vZvopYOxAioSp9QvmDyJdbIqC
t3X0QnI7f0pqv/7kdw2+gXbDDlCgfr3OmlG1/I3BIs7ytmtvmycVzGS6NuKkDaGC
pQxW6U2qhQ3dHfoThdH5wfltcEd9QlSXXTchmA55A/NjvxQymOblr3mbE3Egot48
tZRbnohSEuY=
=UTZ6
-END PGP SIGNATURE-

maplay_1.2-1 uploaded

[Brian Mays]

-BEGIN PGP SIGNED MESSAGE-

Format: 1.5
Date: Fri, 23 Aug 1996 22:51:53 -0400
Source: maplay
Binary: maplay
Architecture: source i386
Version: 1.2-1
Distribution: unstable
Urgency: low
Maintainer: Brian Mays <[EMAIL PROTECTED]>
Description: 
 maplay - An MPEG Audio Player.
Changes: 
 maplay (1.2-1) unstable; urgency=low
 .
   * Initial release.
Files: 
 e533790dfb156db973223108c561dd30 588 sound optional maplay_1.2-1.dsc
 f22597f9750b348801bfa3e9547f84e3 48025 sound optional maplay_1.2.orig.tar.gz
 eaf5a090bc22e94710a578d94381ce7a 2801 sound optional maplay_1.2-1.diff.gz
 aa12d0fbaca6f0e51d800cfb0b37357c 42984 sound optional maplay_1.2-1_i386.deb

-BEGIN PGP SIGNATURE-
Version: 2.6.2

iQCVAwUBMiSCVPrhbOLeJ39FAQEmOgP/V6fThrjXYNgxwEfKs11YR1+UWv+navu+
fdOANiFT64OirBBi/2KDC9fa2SM1VQ+hotmuqiJd4vUVKeVUSgAuqIsaaeRgh5AQ
gDd3H6bio4IG1Yu/h+yZIdimn3TeNGi25tDERc2YJzNopfi6lD8QrNsPJ4y8jrTP
Fuezkgmkkzk=
=o6Sp
-END PGP SIGNATURE-

Bug#4336: /etc/ssh/ssh_random_seed should be moved to /var

[Marek Michalkiewicz]

Package: ssh
Version: 1.2.14-1

sshd writes to the file /etc/ssh/ssh_random_seed during normal
operation - the file should be moved to /var according to the
FSSTND recommendations.

Marek

Bug#4337: ssh should be compiled with -O2 (not -g -O)

[Marek Michalkiewicz]

Package: ssh
Version: 1.2.14-1

The package is compiled with the -g -O flags (autoconf default)
- this results in larger and slower binaries.  It might be a good
idea to use -O2 instead (no -g) and maybe strip the binaries too.

Marek

Bug#4330: amd hangs system

[Richard Kaszeta]

>The same problem occurs using Slackware and RedHat Linux and on 
>different hardware. 

Would you be willing to try another amd package?  To solve local
problems here I hand-patched a few things in the amd package, and
rolled in a few other patched from various newsgroups, and it has
worked without error for a month.

http://www.menet.umn.edu/~kaszeta/amd-upl102-custom1.i386.deb

*Please* let me know if you use it, and whether it works or not.

(Warning, it's config is a little different from the other amd packages).

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

Re:dselect/dpkg & multiple versions

[Michael Shields]

At 1996-08-28 21:59 +, Brian C. White wrote:
>I know that at one point the dselect/dpkg combination had fairly serious
>problems if the same package name existed with multiple versions.  I learned
>this the hard way when I installed from a mirror that had not run to
>completion and thus had not deleted the older packages.
>
>Dpkg installed _both_ versions of the packages at the same time and really
>got screwed up.
>
>The reason I bring this up is that there are now several package that are
>_intentionally_ in the distribution multiple times with different versions:

I think this is a useful feature and would like to see it on the wishlist
at least.  I'd definitely like to see dselect come up with a list of
multiple versions that are available -- from both stable and unstable, for
example -- and allow me to choose betwen them.  I'm guessing it would also
make support easier for the "realms" I mumbled about a few weeks ago.

(Of course, I ca'n't offer code at the moment so my opinion carries little
weight.)

--
Shields, CrossLink.

Bug#4338: sshd should support shadow passwords

[Marek Michalkiewicz]

Package: ssh
Version: 1.2.14-1

If compiled on a system which has no /etc/shadow file, sshd
doesn't support shadow passwords when using the password
authentication.  All the necessary code is already there (will
work with both shadow and non-shadow passwords) - all that is
needed is to hack the configure script a little so that it
defines HAVE_ETC_SHADOW in config.h.  (it should really check
for getspnam() instead of /etc/shadow, like GNU su does)

(Alternatively, just do "touch /etc/shadow" before building
the package.)

Marek

Bug#4331: linux-security] [linux-alert] SECURITY FIX/UPDATE: anonftp (fwd)

[Bernd Eckenfels]

Hi,
(debian bug, Elliot)

> Package: wu-ftpd
> Version: 2.4-23
> 
> I don't know the exploit, but tar in the anon ftp area is the
> same as the normal one, so I think Debian systems may have this
> problem too.  Two messages from the linux-security list (the
> second one includes a patch for tar - only for anon ftp, not
> for the normal one!) are attached below.

AFAIK it is along the line wit 

"site exec tar cvzf -rsh-command blafasel host:tar.tgz"

Of course there should be no tar binary in the site exec directory,
therefore I wonder where the problem ist... But I guess a strip down binary
version of tar together with a striped down binary version of ls (both
static) would be a nice idea to be included in wu-ftpd package.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )   [EMAIL PROTECTED],linux.de}  http://home.pages.de/~eckes/
  o--o *plush*  2048/A2C51749  [EMAIL PROTECTED]  +4972573817  *plush*
(OO)   If privacy is outlawed only Outlaws have privacy

Bug#4339: no free pine package available

[Marek Michalkiewicz]

Package: ftp.debian.org

The current version of pine is in non-free because the copyright
is not clear.  We really should talk to the maintainers - perhaps
we can get permission to distribute the package as part of the
distribution?  (FYI, it's in Red Hat, and those guys are quite
careful about copyrights, too...)

Even if we don't get permission (say, Red Hat paid them lots of
$$$ to get a license), I think we should still distribute an
older version (before the copyright change - I think it was 3.92)
in the regular distribution (just like we do with ghostscript).
Are there any problems with this?

Marek