Bug#849918: RFS: tinymux/2.10.1.13-1

On Thu, Jan 5, 2017 at 12:32 AM, Tobias Frost <tobi@debian.org> wrote:

Control: tags -1 moreinfo

BTW, you're using the tar.gz .. Can you use the tar.bz2 for the
packaging as it compresses better? This is also the one that is picked
up by uscan... (Just use uscan --force-download to get a copy and then
delete the other one)

Done.

- d/clean: You can use wildcards, eg. it is less fragile if your clean
games/bin/* instead of the individual files.

Done.

- you do not need to d/clean condig.(log|status)

Done.

About the install:
- there are a few files with *.conf that are going to /usr/share/...
Are they conf-files that should actually go to /etc/ as a kind of
system-wide configuration?

They would be game-specific -- the name of the game, ports used, The tinymux-install script doesn't support it directly, but someone could run that script multiple time, and rename the resulting tinymux directory to the um-teen different games they want to run. Each one would need to have it's own configuration.

> - There's no obvious override for the duplicate changelog warning.

The problem is that dh_installchangelogs will pick it up, but you've
got it also specified in d/docs.

Just removed CHANGES from d/docs.

You shouldn't install the doc INSTALL, as this is not relevant for
Debian binary packages -- it talks mostly about how to compile etc.
(README.Debian takes it job appearantly already)

Did not see that one in the d/docs file. There are references to it in other readme files, but that file itself is not being installed.

While this explains the why very well (and is too extensive on the what
(this is will be in the diff) Convention is just to write:
* New maintainer. (Closes: #YourITABugNumber)

Let's be fashionable. Changed to reference the bug.

One thing I noted: NOTES mentions there is a default password. (I guess
it it a kind of admin password) This is a bad idea, securitywise and
should be changed.

It is a kind of admin password, the password to the ''god' account within the game. A bit of tradition buried there (https://en.wikipedia.org/wiki/Potrzebie). These mud games were once hosted in hidden fashion on University boxes, hidden in plain sight. You had to be smart enough to find the party or deserve an invitation. It's not like that now.

OK, back to business. I agree that it is a bad idea. A fix would require that the following lines in netmux.db be changed at install time:

"$SHA1$X0PG0reTn66s$FxO7KKs/CJ+an2rDWgGO4zpo1co="

Or, a command-line option to netmux added that went through the steps of loading the game's database but immediately changing the password to something else before accepting connections. Both options would need upstream work. I prefer the second option, but any option would require upstream work.

None of the game accounts are given any control over the shell account. The worst #1 should be able to do is delete the database from the inside or change a configuration option which takes the game down by causing a divide-by-zero. What worries me more than the initial, default #1 password. is the UTF-8 state machine that parses input for all users and the fact all users have access to PCRE globs. I still remember the old telnet bugs, and PCRE globs are mini-programs, and it isn't hard to tie the game up for an hour with a carefully chosen ones. We've added CPU limits within the inner loops in the PCRE code to forestall this, and that's the only reasons why I use the PCRE statically instead of using it as a library.