Package: wnpp
Severity: wishlist
Owner: Karl Ferdinand Ebert <kfebert@gmail.com>

* Package name : tmux
Version : 0.7
Upstream Author : Nicholas Marriott <nicm@users.sf.net>
* URL : http://sf.net/projects/tmux
* License : BSD
Programming Lang: C
Description : an alternative to screen, licensed under 3-BSD

tmux enables a number of terminals (or windows) to be accessed and
controlled from a single terminal. tmux runs as a server-client system.
A server is created automatically when necessary and holds a number of
sessions, each of which may have a number of windows linked to it.
Any number of clients may connect to a session, or the server may be
controlled by issuing commands with tmux. Communication takes place
through a socket, by default placed in /tmp.

-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Am Thursday 12 March 2009 11:13:00 schrieb Guus Sliepen:
> On Wed, Mar 11, 2009 at 11:56:01PM +0100, Karl Ferdinand Ebert wrote:
> > * Package name : tmux
> > Description : an alternative to screen, licensed under 3-BSD
>
> The short description should stand on its own, not reference other
> software. You can mention this package's relation with screen in the long
> description. You also should not mention its license in the long or short
> description, that's what the copyright file is for. The short description
> should probably just be "terminal multiplexer".

The short description had been "terminal multiplexer" from the first packaging
attempts but I did not know it had to be the line in the bug report. The long
description is extended with details from the FAQ:

* How is tmux different from GNU screen? What else does it offer?

tmux offers several advantages over screen:

- a clearly-defined client-server model: windows are independent entities
which
may be attached simultaneously to multiple sessions and viewed from multiple
clients (terminals), as well as moved freely between sessions within the
same
tmux server;
- a consistent, well-documented command interface, with the same syntax
whether used interactively, as a key binding, or from the shell;
- easily scriptable from the shell;
- multiple paste buffers;
- choice of vim or emacs key layouts;
- an option to limit the window size;
- a more usable status line syntax, with the ability to display the first line
of output of a specific command;
- a cleaner, modern, easily extended, BSD-licensed codebase.

From Williams' email:
> What does this have over screen, other than being BSD licensed?

answered above.
> The design of tmux seems less secure, too.

In which way is it less secure?
My first contact with this package was on a OpenBSD mallinglist, as I followed
those discussions some developers where involved.
(I do not mean it is more secure by that but I appreciate their code in
general)


Regards,


Ferdinand

On Sat, 14 Mar 2009, Mike Hommey <mh@glandium.org> wrote:
> > [Mike Hommey]
> >
> > > Screen does that too, so that would hardly be less secure than screen.
> >
> > Well, if by "in /tmp" you mean "in /var/run/screen".
>
> Well, that's a Debian thing. Upstream default is /tmp/screens, and last
> time I checked on RH, it was there too.

RHEL 5.2 has /var/run/screen. Debian/Lenny and RHEL 5.2 work in a similar
way, you have a setgid screen program and the /var/run/screen directory is
writable by the group. In Debian there is an init.d script to create that
directory (presumably to support tmpfs /var/run) while in RHEL it is
installed as part of the package.

RHEL 4.7 has the directory /tmp/screens for root and /tmp/uscreens for user
sessions. /tmp/uscreens is owned by the first non-root user who ran screen
and group writable. If that user is hostile (or even clueless) then "chmod
700 /tmp/uscreens" will make it unusable for others. I don't know whether
they can do anything really bad, screen appears to check the ownership of the
socket so it should be OK apart from DOS attacks.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org