View Issue Details

IDProjectCategoryView StatusLast Update
0002154unrealircdpublic2007-12-30 11:39
Reporteraquanight Assigned To 
PrioritynormalSeveritytrivialReproducibilityalways
Status closedResolutionno change required 
PlatformX86OSWindowsOS VersionXP Pro SP2
Product Version3.2.2 
Summary0002154: PART vs SAPART?
DescriptionStskeeps brought up an interesting issue concerning the SAPART reason stuff in #unreal-support...

<@JK> aquanight, scary part msg
<+haltdef> ?
<@JK> aquanight, "(SAPart: boo)" :P
<+aquanight> heh
<+aquanight> what's so scary about it? :P
<+aquanight> especially since 3.2.2 will do that for a real SAPART :p
<@JK> :P
-- Here it is :P --
<@Stskeeps> ..
<@Stskeeps> aquanight: kick Syzop / codemastr in the balls from me for that
<@Stskeeps> as it can be faked into hell.
<+aquanight> Stskeeps: ?
<@JK> lol
<+aquanight> the SAPart: but is constant
<+aquanight> bit*
<+aquanight> but hm
<@Stskeeps> ..
<+aquanight> oh yea, well regular /part...
<@Stskeeps> /part #foo :SAPart: foo
<+aquanight> yah
<+aquanight> I know
<+aquanight> hm
<@JK> THere should be way by which to distinguish server-added messages from user-added ones :-)
<+aquanight> well there is an easy way to do that
<+aquanight> change /sapart from a :victim PART #channel :SAPart: message to :server.name KICK #channel victim :message
<@JK> Having no distinction makes for paranoia and intability :/
<+aquanight> there aren't any server generated kicks except for +f [t]
<@JK> Hey I'm all in favour of that, but I imagine some would oppose that
<@JK> not to mention all the people coming here to whine :(
<+aquanight> only problem is the difference in how clients interpret KICK as opposed to PART
<+aquanight> for example, a client might not autorejoin if it receives an unexpected PART - it just closes the channel window no questions asked
<@JK> They should treat it nearly identical really
<+aquanight> KICK on the other hand...

So yeah. I think it's probably pretty trivial to fix. Just make /part reject the reason if it starts with SAPart: and isn't coming from m_sapart :P .
TagsNo tags attached.
3rd party modules

Relationships

child of 0003111 closed 3.2.7 Release 

Activities

codemastr

2004-11-02 17:13

reporter   ~0008223

First, what's the big deal, I don't really see much of an issue?
Second, I think the old alternative was worse - opers being able to fake parts from users
Third, no this isn't something I overlooked when adding the "SAPart:" prefix, it was simply something I didn't think was a big deal.

aquanight

2004-11-02 17:23

reporter   ~0008225

Indeed, really it's the same thing as having set { prefix-quit "no"; }; ...

SomeOp: /kill SomeOne Bye.
* SomeOne (user@host.domain) Quit ([server.name] Local kill by SomeOp (Bye)

SomeOne: /quit [server.name] Local kill by SomeOp (Bye)
* SomeOne (user@host.domain) Quit ([server.name] Local kill by SomeOp (Bye)

I'd suggest a prefix-part, but that's overkill when there's only one server-generated part (and not even 100% server-generated at that) really... if people abuse that too much then it's not hard for the admin to disable part reasons :P .

Dukat

2004-11-03 05:41

reporter   ~0008229

If you're really that paranoid, you can still use the Spamfilter to block reasons starting with SAPart...

vonitsanet

2007-04-19 07:23

reporter   ~0013602

*bump*

Quis

2007-12-24 13:53

reporter   ~0014930

Clients do handle kick different from part!

Most clients will leave the window open when kicked,
so you can read the last lines before you got kicked.

But parting is (mostly) done by yourself,
so the window gets closed, first parting, and closing the window after that wouldn't make sense.

syzop

2007-12-30 11:36

administrator   ~0014948

dropped. too much cpu for something stupid (a simple string comparison will not suffice).

Issue History

Date Modified Username Field Change
2004-11-02 15:15 aquanight New Issue
2004-11-02 17:13 codemastr Note Added: 0008223
2004-11-02 17:23 aquanight Note Added: 0008225
2004-11-03 05:41 Dukat Note Added: 0008229
2006-11-12 15:06 syzop Relationship added child of 0003111
2007-04-19 07:23 vonitsanet Note Added: 0013602
2007-04-19 07:32 stskeeps Status new => acknowledged
2007-09-06 10:10 syzop Relationship added child of 0003454
2007-12-24 13:53 Quis Note Added: 0014930
2007-12-30 11:35 syzop Relationship deleted child of 0003454
2007-12-30 11:36 syzop Note Added: 0014948
2007-12-30 11:39 syzop QA => Not touched yet by developer
2007-12-30 11:39 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2007-12-30 11:39 syzop Status acknowledged => closed
2007-12-30 11:39 syzop Resolution open => no change required