binary-alpha and binary-sparc directories
I've created binary-alpha and binary-sparc directories under the development tree. They're both empty at the moment, of course, but they're ready for use whenever the development teams have something to put there. (BTW, I plan to rename binary to binary-i386 as soon as we finish the planned FTP reorganization.)
Re: Buglist
On Thu, 21 Dec 1995, Bruce Perens wrote: > I have a bunch of bugs I haven't closed out, and there are bugs > on packages I've transferred to other maintainers that the other > maintainers have not closed out. I will not be able to deal with > this until after New Years. I, too, have some work to do wrt to closing bug reports, etc., and I won't be able to get to them until the new year.
David J Meltzer: mailx-5.5 (slackware /bin/mail) security hole
FYI -- This appears to affect Debian's mailx as well. Robert Leslie [EMAIL PROTECTED] --- Forwarded Message Message-ID: <[EMAIL PROTECTED]> Date: Fri, 22 Dec 1995 17:35:01 -0500 From: David J Meltzer <[EMAIL PROTECTED]> Subject: mailx-5.5 (slackware /bin/mail) security hole To: Multiple recipients of list BUGTRAQ <[EMAIL PROTECTED]> There is a problem prevalent in the way many programs implement their usage of mktemp() in order to create temporary files in /tmp, allowing users on a machine to read and write to the contents of temporary files created. The basic problem is that there is a race condition that exists between the point that a program calls mktemp(), and the pathname returned by mktemp is actually created. For some programs, the file creation is immediately or almost immediately following the mktemp(), resulting in an extremely small window of opportunity, and as a result making it very difficult to exploit. However, there are other programs that do not immediately open the file, and in these cases it is only a matter of getting the timing right in order to exploit the hole. To exploit this hole, simply create the file that mktemp() returns as a valid temporary filename after mktemp() has been called, but before the file has been opened, allowing the user running the program permissions to read and write from that temporary file. The program will then succeed in an fopen, and will write to the file, oblivious to the fact that it didn't actually create the file, and that others can also read and write from the file. Note that most programs will immediately unlink() a temporary file, but that does not delete it until after it is closed. Closing a file results in the contents of it being flushed, and so by using a 'tail -f' or a similar procedure, you can capture the contents of the file before it is removed from the filesystem. The filename returned by mktemp() is easily determined for most unix platforms, allowing this bug to be exploited. For the linux libc, this is to replace the X's in the template with the leftmost digit starting at 'a', and then being incremented 'a'-'z', 'A'-'Z', and '0'-'9' (if that file already exists), and then replacing the rest of the X's with the process id (0 padded). Other operating systems use a variation of this technique, experimentation easily reveals the algorithm. The generic procedure used to formulate an exploit for a particular program with this bug is as follows: 1. detect the execution of the program. 2. determine the temporary filename that mktemp() will return when called by the program. 3. determine the point at which mktemp() is called by the program, and immediately following that point, create the file, with rw permissions for the user who is running the program. 4. read the contents of the temporary file, using a 'tail -f' or your own routines. Linux's /bin/mail, as included in Slackware 3.0 (mailx 5.5), suffers from this mktemp() problem in all temporary files it creates. It uses 5 temporary files with filenames generated during the program's initialization in a tinit() function, and then uses them as it becomes necessary during the program's execution. The race condition begins in this tinit() function. The temporary files that can be exploited are as follows: /tmp/ReXX Used when a user selects 'e' from the mailx command prompt, to edit mail. The message the user has selected to edit is copied to the temporary file at this point, and then the editor is invoked on that temp file. The race condition ends when the user has selected 'e', and allows the mesage being edited to be read. /tmp/RsXX Used when a user sends mail, usually from the command line, such as: 'mail dave'. The race condition ends when EOF is recieved from stdin, and the message is about to be sent, and allows the outgoing mail to be read. /tmp/RqXX Used when mail arrives into the mail spool while mail is currently running. The race condition ends when the program is preparing to shutdown, and allows the new contents of the mail spool to be read. /tmp/RmXX Used to prepend a message to the user's mbox file. Prepending requires the entire mbox contents to be read to the temporary file and then appened to the new message(s) being added to the file. This is disabled by default in Slackware 3.0 in the /etc/mail.rc by the use of the set append option. For this to be useful, that option needs to be removed from /etc/mail.rc, or an unset append needs to be added to the user executing mail's .mailrc file. The race condition ends when the program is preparing to shutdown /tmp/RxXX Used to read messages from the user's mail spool. The race condition ends duri
Re: ELF flex
Ian Murdock wrote: >> Ian M., if you are maintaining flex, any chance of getting an ELF >> version uploaded soon? If you'd rather not be bothered, perhaps I >> could even take the package off your hands. > > Yes, please do. Very well: Date: 23 Dec 95 07:40 UT Source: flex Binary: flex Version: 2.5.2-2 Description: flex: A fast lexical analyzer generator. Priority: Low Changes: * New maintainer. * Rebuilt for ELF. Files: -rw-rw-r-- 1 rob rob381961 Dec 23 02:34 flex-2.5.2-2.tar.gz -rw-rw-r-- 1 rob rob 407 Dec 23 02:40 flex-2.5.2-2.diff.gz -rw-r--r-- 1 root rob129524 Dec 23 02:36 flex-2.5.2-2.deb b1f9161bb387a5f7261ad7a5d441493b flex-2.5.2-2.tar.gz d6ac69a49dd1808a05a163c39a10b4dd flex-2.5.2-2.diff.gz 54c0a83418af27526f3b617f3b07248b flex-2.5.2-2.deb Happy Holidays. -- Robert Leslie [EMAIL PROTECTED]
Re: Bug#2042: less-290-5
On Fri, 22 Dec 1995, Ian Murdock wrote: > On Mon, 18 Dec 1995, Bill Mitchell wrote: > > > Fixed in less-290-7, just uploaded to pixar. > > Don't you mean ftp.debian.org? I think I uploaded it to pixar. There were several notices a week or two back that uploads to ftp.debian.org should be suspended. Bruce opened up an Incoming directory on pixar as an alternative. I uploaded a number of packages to pixar. I guess that Incoming for uploads must now be ftp.debian.org again, even though I've seen no announcement to that effect.
dchanges (was: m4 rebuilt as ELF)
On Fri, 22 Dec 1995, Ian Murdock wrote: > Actually, it should be in the distribution. Where should I put it? The control file says Section: misc. That seemed to me to be the most appropriate place.
findutils rebuilt as ELF
I have rebuilt the findutils package as ELF and placed the binary package into ftp.debian.org//debian/private/project/Incoming. Date: 23 Dec 95 16:36 UT Source: findutils Binary: findutils Version: 4.1-5 Description: findutils: GNU find, xargs and locate. Priority: Low Changes: * New maintainer. * Rebuilt for ELF. Files: -rw-r--r-- 1 kevinusers 271006 Dec 23 08:35 findutils-4.1-5.tar.gz -rw-r--r-- 1 kevinusers 31405 Dec 23 08:33 findutils-4.1-5.diff.gz -rw-r--r-- 1 kevinusers 81572 Dec 23 08:33 findutils-4.1-5.deb a31550215e7737622dd311c2ce8cb8a9 findutils-4.1-5.tar.gz 81014a81f01c32b3f81385b90a916b8c findutils-4.1-5.diff.gz 349f803cc6504f64577a9534b8e9fe81 findutils-4.1-5.deb
Re: binary-alpha and binary-sparc directories
On Sat, 23 Dec 1995, Ian Murdock wrote: > I've created binary-alpha and binary-sparc directories under the > development tree. They're both empty at the moment, of course, but > they're ready for use whenever the development teams have something > to put there. > > (BTW, I plan to rename binary to binary-i386 as soon as we finish the > planned FTP reorganization.) It seems that the Guidelines document needs updating to address issues falling out of this. One issue is whether binary packages are to be distinguished by distribution-specific naming convention (and, if so, what that convention is to be). Binary packages will need need distinguishing names if they're to be uploaded to a common Incoming directory. Will debian systems offer cross-compilation facilities? Will the developer of a sparc-targeted package be expected to provide an i386 build as well? If not, and some other developer provides the i386-targeted package, which of the two source packages (which may differ from one another) will be in the distribution? It seems to me that packages will need a primary maintainer, who would be responsible for the source package, and an architecture specific maintainer for each supported binary package. One person could act in all capacities, of course, but I'd expect that at least some packages would have different maintainers for the different architectures. The way I see this working, architecture-specific maintainers with the ability to address architecture-specific bug reports and do architecture-specific testing would feed architecture-specific fixes and patches to the primary package maintainer. Primary package maintainers having, say, a sparc would install alpha or i386 patches blindly, relying on the testing done by the alpha and i386 maintainers, and issue a package revision update.
Re: binary-alpha and binary-sparc directories
Also, don't forget about architecture-independent binaries... -- Raul
bind-4.9.3BETA26-3 uploaded
This revision is ELF. Also note a change in the version string to remove an embedded "-". As a result of this dpkg thinks this version is a downgrade, although it's not. I haven't yet made any changes to let BIND do cacheing nameservice by default. I'd also like to think about making libresolv into a shared library, and possibly splitting up the package into several smaller packages: bind (nameservice daemon, sample zone files, /etc/named.boot, /etc/init.d/bind, misc docs), resolv (runtime resolver shared library, /etc/resolv.conf), resolv-dev (resolver include files and .so link, docs), & dns-utils (nslookup, dig, etc.) It would then be nice to have all the programs linked with libresolv.a be recompiled to use the shared library. Comments? Date: 24 Dec 95 02:33 UT Source: bind Binary: bind Version: 4.9.3BETA26-3 Description: bind: Internet domain name server Priority: Low Changes: * New maintainer. * Rebuilt for ELF. Files: -rw-rw-r-- 1 rob rob 1529582 Dec 23 21:25 bind-4.9.3BETA26-3.tar.gz -rw-rw-r-- 1 rob rob 3172 Dec 23 21:30 bind-4.9.3BETA26-3.diff.gz -rw-r--r-- 1 root root 365436 Dec 23 21:20 bind-4.9.3BETA26-3.deb 8aff8d674f3fd05ff8d830e09e442e9f bind-4.9.3BETA26-3.tar.gz 68de1d709aa1fe4e3eae526aee2153d2 bind-4.9.3BETA26-3.diff.gz a25d1e7a0bd8e7fa5d3ecac1d4bafe7d bind-4.9.3BETA26-3.deb -- Robert Leslie [EMAIL PROTECTED]
man wont install?
Hi... Just folowwing up that story about the libgdbm1 (that perl and all the other stuff will fail if they arent updated with it)... Man seems to be released for the new libgdbm1 package, however libgdm1 wont let me install it because of it's conflict being man <2.3.10-6 which includes 6 it seems. Is that actually meant to be right, and we're still waiting on a new man package? Or is it a mistake in the conflicts for libgdbm1? Regs -- Karl Ferguson <[EMAIL PROTECTED]> Network Supervisor - Tower Internet Services. | Internet Providers and | Tel: +61-9-316-3036 Fax: +61-9-381-3909| Networking Solutions |
figlet-2.1.1-1 uploaded
Figlet is a cool program for doing things _ _ _ _ _ _ | (_) | _ | |_| |__ (_)___ | | | |/ / _ \ | __| '_ \| / __| | | | < __/ | |_| | | | \__ \_ |_|_|_|\_\___| \__|_| |_|_|___(_) The authors have given permission to distribute figlet as part of Debian GNU/Linux. I don't know the copyright status on any of the contributed fonts yet, so this package contains only the fonts that come with the standard figlet distribution. I'll make a separate package for the other fonts later. Date: 24 Dec 95 04:40 UT Source: figlet Binary: figlet Version: 2.1.1-1 Description: figlet: Frank, Ian & Glenn's Letters. Priority: Low Changes: * New package (ELF). Files: -rw-rw-r-- 1 rob rob 56575 Dec 23 23:22 figlet-2.1.1-1.tar.gz -rw-rw-r-- 1 rob rob 1943 Dec 23 23:25 figlet-2.1.1-1.diff.gz -rw-r--r-- 1 root root51163 Dec 23 23:22 figlet-2.1.1-1.deb a0cae762bfad7cae84e14373f11dccb3 figlet-2.1.1-1.tar.gz 51c6fd9d6018ed91af1777304174469d figlet-2.1.1-1.diff.gz 10d715c6fb1e9b940d31c276b5c3db65 figlet-2.1.1-1.deb -- Robert Leslie [EMAIL PROTECTED]
