cyberleo / protomuck Goto Github PK

What steps will reproduce the problem?
-> (objref on top of stack) "%~" fmtstring

What is the expected output? What do you see instead?
->If it feeds a object's reference into FMTSTRING's any-data-type flag, it 
should return a string containing an object reference, and NOT a object's name.

What version of the product are you using? On what operating system?
->Latest version, on whatever Hinoserm's server is running. (POSIX UNIX/LINUX? 
I have no clue.)

Please provide any additional information below.

Possible culprit/potential fix:
-=[Code Block]=----=[Copy Pasta, with comment sauce]=-=[F:p_strings.c]=--
/* FROM:Line 2762 */
                if (sstr[scnt] == '~') {
                    switch (oper2->type) {
                        case PROG_OBJECT:
                            sstr[scnt] = 'D'; /* 'D'; is using the %D Reference for FMTSTRING, using a dbref's name instead of the lowercase version */
                            break;
/* TO:Line 2766 */
-=[End of Code Block]=---------------------------------------------------

Updated BASEDBURL and GLOWUTILSURL to reflect updated domain.

This was reported to me by a user. Haven't gotten around to verifying it myself 
yet. I believe the DB format has changed multiple times since the last "stable" 
release; if so we will need to provide a sane upgrade path for users who have 
not been keeping up with CVS updates.

I have no idea how to create prims, so this is likely hopelessly wrong. I'm 
including the patches and work here, though, so I don't lose them.

hmac computation is relatively straightforward; but a separate constant-time 
verification prim is required, as a simple string comparison between two hmacs 
will introduce a trivially exploitable timing attack.

Alynna reported an issue where using JMP inside of a TRY-CATCH statement can 
produce odd results.  I was able to reproduce on ProtoMUCK 2.0b9.12.3.


Example:

: main
   0 try
      me @
      'test jmp
        "Go planet!"
      test:
        "Test" notify
   catch
   pop
   endcatch
;

Result:

Program Error.  Your program just got the following error.
..., line 5;  TRYPOP: Internal error; TRY stack underflow.

Breakpoint 20, save_command (d=0xb685c6d8, command=0xb664a4e8 "f", len=1, 
wclen=-1) at interface.c:3586
(gdb) fg
Continuing.
Breakpoint 18, handle_read_event (descr=7, player=-1, command=0xbf848498 "f", 
event=0x0, len=0, wclen=0) at timequeue.c:391
(gdb) bt
#0  handle_read_event (descr=7, player=-1, command=0xbf848498 "f", event=0x0, 
len=0, wclen=0) at timequeue.c:391
#1  0x081af361 in check_connect (d=0xb685c6d8, msg=0xbf898599 "") at 
interface.c:4413
#2  0x081af0dc in do_command (d=0xb685c6d8, t=0xb665d4f8) at interface.c:4345
#3  0x081ae574 in process_commands () at interface.c:4140
#4  0x081a9c84 in shovechars () at interface.c:1915
#5  0x081a76e2 in main (argc=5, argv=0xbf8f9244) at interface.c:767


The above debugger output confirms that CT_MUF connections that get processed 
by READ/TREAD are byte-processed twice; once inside process_input (save_command 
gets called, so this definitely happens), and again inside of check_connect.

Problems with this:
1) This is obviously a waste of processing.
2) The byte-processing loop inside of check_connect is hardwired to validate 
each byte with isprint(), which bypasses per-descriptor encoding preferences 
and will use the server's locale to decide printable status. (currently 
en_US.UTF-8 with UTF8_SUPPORT defined, and standard ANSI without)

What steps will reproduce the problem?
1. Trigger EVENT_WAIT in foreground mode. Do not process the READ event and pop 
it off the stack with the READ prim.
2. Send a single line of text to the game that will put something in your input 
queue. (i.e., must not bypass exit processing like BREAK_COMMAND and 
WHO_COMMAND)
3. Try to use any command that bypasses exit processing; BREAK_COMMAND (@Q) is 
of particular note.

The problem is that only the top item of the input queue gets processed for the 
special commands. This is a rare circumstance where the top item of the queue 
is not getting popped off, and as a result the user's input queue is locked 
until either the program releases them or they force it to abort by 
reconnecting.

dinfo 7

[Connecting] descr 7 (muf)
Descr Flags: DF_INTERACTIVE DF_COLOR
Termtype: SCREEN-256COLOR    Encoding: RAW
Host: [email protected]
IP: 69.15.43.130(58943) 450F2B82
Online: 00:00  Idle: 7s  Commands: 0

The presence of a negotiated TERMTYPE indicates that CT_MUF connections are 
processed for telnet options. We will need to add a toggle behavior for telnet 
handling on descriptors, and default it to off for CT_MUF connections. A new 
primitive will need to be added to manually toggle this behavior on. (i.e. for 
welcome screen replacement programs)


What is the expected output? What do you see instead?


Please use labels and text to provide additional information.