--- Begin Message ---
Am Donnerstag, den 05.01.2017, 05:14 -0700 schrieb Stephen Dennis:
> 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:
>
> > 5
>
> "$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.
OK, thanks for the explanation.
uploaded finally :) Thanks for your contributions!
--
tobi
--- End Message ---