#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