#d/TMI/boards/bugboard.c
ob_data (["short":"@@query_short","long":"@@query_long","short.text":"The Tmi-2 mudlib bug board","long.text":"This is a bulletin board. For information on how to use it, use `help board'.
","silent_look":1,"id":({"board","bulletin board",}),"last_location":0,])
messages ({(["title":"bugs","poster":"Leto","time":816819190,"body":"It looked silly to see 0 postings on this board, so I posted one ;)
If you think that you have a bug which we don't have here, it
might be wise to check /log/ChangeLog and see if we happened to
fix it already.

Leto
","id":1,]),(["id":2,"body":"The less command is foobar'ed here.

*grin*

Logic
","time":817154818,"poster":"Logic","title":"less",]),(["title":"mail","poster":"Dalto","time":817191236,"body":"There is a bug in mail

I believe changing line 15 from:
		if( strsrch( arg \"@\" ) ) {
to:
		if( arg && strsrch( arg, \"@\" ) != -1 ) {
will fix the problem.

-Dalto

P.S. The above code came from the mail command....not the mailer itself
","id":5,]),(["id":6,"body":"Thanks.  Fixed.
","time":817274388,"poster":"Robocoder","title":"Re: mail",]),(["title":"%^RESET%^","poster":"Hideyoshi","time":818192154,"body":"What is this?  It shows up in titles, in movement messages, etc...

-Hideyoshi@Sodden Earth
","id":7,]),(["title":"Re: %^RESET%^","poster":"Leto","time":818194380,"body":"On Tue Dec  5, Hideyoshi wrote:
> What is this?  It shows up in titles, in movement messages, etc...
> 
> -Hideyoshi@Sodden Earth

It's from the terminal type code. %^RESET%^ is part of the 'pinkfish'
colour code scheme. Obviously a few calls to the code where it interprets
the code depending on your terminal tpye are missing ;)
I've added it to my TODO list ;)

Leto

","id":8,]),(["id":9,"body":"For the time being, I just edited /cmds/std/_set.c to take out the
part that appends the RESET.  Actually, it's just commented out,
so it'll be easy enough to replace.
-h
","time":818223614,"poster":"Hideyoshi","title":"Re: Re: %^RESET%^",]),(["title":"Re: Re: %^RESET%^","poster":"Leto","time":818296914,"body":"On Wed Dec  6, Hideyoshi wrote:
> For the time being, I just edited /cmds/std/_set.c to take out the
> part that appends the RESET.  Actually, it's just commented out,
> so it'll be easy enough to replace.
> -h

that's not the constructive solution :)
We should make temrinal handling consistent by translating the
Pinkfish codes into terminal type dependant codes.
Right now, we have two systems doing just that,
One is the /adm/daemons/terminal.c and the other is the new mudos contrib
efun that sort of does the same.
We should prob use the efun, and then use it for each line in the who 
command that displays a title.

Leto
","id":10,]),(["id":11,"body":"Well the problem we have is that it appends it, but that RESET stuff
takes up space in the titles, and what happens is that the first %
or more doesn't get put in because of lack of space.  If the titles
are kept short enough it works.  In fact we changed our who around
quite a bit and because of that our titles have to be even shorter.
Just one of the many little things that happen.  Just my 2 cents.

Farrow
","time":818354777,"poster":"Farrow","title":"%^RESET%^",]),(["title":"Re:%^RESET%^","poster":"Leto","time":818382160,"body":"You should move the titles though the translator before 
displaying them. And you prob should calculate the length of the
string accordingly. Eg. If %^FOO%^ gets translated to some ansi 
colour code of 5 chars, those shouldn't be counted. Maybe a new
strlen simul or contrib efun which will help ?

Leto
","id":12,]),(["id":13,"body":"everybody should know this one by now, yet it's still unfixed.
/cmds/std/_do.c, the occurances of this_player() should be previous_object()
","time":823330361,"poster":"Hanzou","title":"really old security hole",]),(["id":14,"body":"On Sat Feb  3, Hanzou wrote:
> everybody should know this one by now, yet it's still unfixed.
> /cmds/std/_do.c, the occurances of this_player() should be previous_object()

While I've fixed this here, I'll take this opportunity to point out
the fact that without serious, serious, serious lib reworking, TMI
is going to remain a really insecure lib.
This was well known even 2 years ago, and we didn't do anything about
it then, either, because making a better security system is hard and
time consuming, and there were always more interesting things to be
doing.
Personally, if you admin a TMI mud, I think it is important that you know
that your mud isn't \"secure\", but I don't think you should worry too
hard about it.  Very few people know enough to break onto your mud,
and how much harm can someone who broke onto your mu do, if you're
making a regular backup (daily, weekly, whatever...)

If you don't make a daily backup, I think it is worth investing a bit
of energy to learn how to make it happen... all you _need_ to know
is the tar command, gzip, cp and how to use cron from unix (man cron).

We also provide a more sophisticated backup script w/ Lima, which will
work w/ any mudlib.  Feel free to go get that and use it for your own
mud...

","time":823337183,"poster":"Rust","title":"Re: really old security hole",]),(["id":15,"body":"On Sat Feb  3, Rust wrote:
> While I've fixed this here, I'll take this opportunity to point out
> the fact that without serious, serious, serious lib reworking, TMI
> is going to remain a really insecure lib.

the current security doesn't seem that bad to me.  it's fairly easy
to hack versions 1.1 and earlier, and 1.2 can be hacked with a little
difficulty, but currently i don't know any way to get admin access on
this version.
","time":823368313,"poster":"Hanzou","title":"Re: really old security hole",]),(["id":16,"body":"On Sat Feb  3, Hanzou wrote:
> On Sat Feb  3, Rust wrote:
> > While I've fixed this here, I'll take this opportunity to point out
> > the fact that without serious, serious, serious lib reworking, TMI
> > is going to remain a really insecure lib.
> 
> the current security doesn't seem that bad to me.  it's fairly easy
> to hack versions 1.1 and earlier, and 1.2 can be hacked with a little
> difficulty, but currently i don't know any way to get admin access on
> this version.

Probably the best way of getting admin access here (and prob. other
libs, is messing with functions, function pointers and bind.
At Earth we have similar problems with it. Bind is a great thing to use,
but hard to protect if you allow some form of binding with player objects.
But then again, how many people can work with function pointers, and
bind ? As Rust said, security isn't that big an issue on a real mud.
You should probably be more worried about wizards and the cheating they
do, then worry about them hacking root.

Leto
","time":823385356,"poster":"Leto","title":"Re: really old security hole",]),(["id":17,"body":"On Sat Feb  3, Hanzou wrote:
> On Sat Feb  3, Rust wrote:
> > While I've fixed this here, I'll take this opportunity to point out
> > the fact that without serious, serious, serious lib reworking, TMI
> > is going to remain a really insecure lib.
> 
> the current security doesn't seem that bad to me.  it's fairly easy
> to hack versions 1.1 and earlier, and 1.2 can be hacked with a little
> difficulty, but currently i don't know any way to get admin access on
> this version.
There are tons of ways to do this, but like I said, you really
need to know what you are doing.  
","time":823386285,"poster":"Rust","title":"Re: really old security hole",]),(["id":18,"body":"On Sat Feb  3, Leto wrote:
> On Sat Feb  3, Hanzou wrote:
> > On Sat Feb  3, Rust wrote:
> > > While I've fixed this here, I'll take this opportunity to point out
> > > the fact that without serious, serious, serious lib reworking, TMI
> > > is going to remain a really insecure lib.
> > 
> > the current security doesn't seem that bad to me.  it's fairly easy
> > to hack versions 1.1 and earlier, and 1.2 can be hacked with a little
> > difficulty, but currently i don't know any way to get admin access on
> > this version.
> 
> Probably the best way of getting admin access here (and prob. other
> libs, is messing with functions, function pointers and bind.
> At Earth we have similar problems with it. Bind is a great thing to use,
> but hard to protect if you allow some form of binding with player objects.
> But then again, how many people can work with function pointers, and
> bind ? As Rust said, security isn't that big an issue on a real mud.
> You should probably be more worried about wizards and the cheating they
> do, then worry about them hacking root.
> 
> Leto

> findfunc valid_bind /adm/obj/master
valid_bind() is not defined in /adm/obj/master
","time":823412245,"poster":"Hanzou","title":"Re: really old security hole",]),(["id":19,"body":"On Sun Feb  4, Hanzou wrote:
 
> > findfunc valid_bind /adm/obj/master
> valid_bind() is not defined in /adm/obj/master

It is now ;) Whoops :)

It probably needs some other new ones too.
valid_asm, valid_compile_to_c come to mind.

Leto
","time":823449627,"poster":"Leto","title":"Re: really old security hole",]),(["title":"auto-loaded objects and linkdeath","poster":"Hideyoshi","time":824369500,"body":"I've noticed that any objects set to autoload tend to multiply when a
player goes linkdead and then reconnects.  How can I fix this?  Am I
doing the autoload incorrectly?

int query_auto_load()

{

      return 1 ;

}

-Hideyoshi
","id":20,]),(["id":21,"body":"On Thu Feb 15, Hideyoshi wrote:
> I've noticed that any objects set to autoload tend to multiply when a
> player goes linkdead and then reconnects.  How can I fix this?  Am I
> doing the autoload incorrectly?

nod.

I checked here, but autoloading objects here don't multiply
when a player reconnects. Can you try your object here and see
if it also gets an additional copy upon becoming netdead?
Or else, let me know where your mud is, and if you haven't
wiped my char, i can have a look :)

Leto

Ps. I checked here with the autoloading /obj/shells/sbsh.c
","time":824408436,"poster":"Leto","title":"Re: auto-loaded objects and linkdeath",]),})
id_ref 31