View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006579 | unreal | public | 2025-09-23 13:39 | 2026-06-05 18:14 | |
| Reporter | zw32h | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | feedback | Resolution | reopened | ||
| Fixed in Version | 6.2.3-rc1 | ||||
| Summary | 0006579: usermodes/privdeaf | ||||
| Description | It seems logical that usermodes/privdeaf should ignore TAGMSG otherwise users receive the "User does not accept private messages" notice multiple times before they've even sent the message that should trigger it. | ||||
| 3rd party modules | |||||
|
|
Yeah I think I agree there :) |
|
|
Patch attached. privdeaf-ignore-tagmsg.patch (885 bytes) |
|
|
Hmm, your patch makes it so TAGMSGs are delivered even if user is +D. I thought you meant to silently reject TAGMSG if +D. Ah yeah, you probably did that because you could deny in HOOK_DENY without setting an errmsg. |
|
|
Done now, thanks for the suggestion! Also applied to +R. And this fixes semi-silently iterating through users to see who is +R/+D as well. https://github.com/unrealircd/unrealircd/commit/2dd23d13b7a88dc66e0865f076ee8c22449a7aa7 commit 2dd23d13b7a88dc66e0865f076ee8c22449a7aa7 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD) Author: Bram Matthys <[email protected]> Date: Fri Jan 23 08:19:31 2026 +0100 Silently drop TAGMSG to users who refuse PRIVMSG/NOTICE also (umode +D, +R), since the message/notice would not make it through either. This also means someone can no longer iterate through users to see who is +D/+R by sending a "silent" TAGMSG. (Silent in the sense that the end-user usually would not have noticed) Suggested in https://bugs.unrealircd.org/view.php?id=6579 by zw32h (I think) This also means HOOKTYPE_CAN_SEND_TO_USER now allows you to NOT to set errmsg, to silently drop a message. Previously we would crash deliberately on such a situation to enforce that all modules would set a proper errmsg. |
|
|
This also happens in at least a couple of other scenarios, for example when a user becomes affected by a +b after joining the channel, or when a user without +v tries to send to a channel with +m, etc. |
|
|
Yeah the reason i did it for user to user without much hesitation is because it fixes this "leak" of showing that you are on ignore (i mean silenced). but for channels, yeah, as mentioned on IRC. It may be better to discuss this with IRCv3, so we don't do something other than inspircd, ergo and such. For NOTICE it is speced that it should not send errors, for TAGMSG i see nothing in the specification indicating such a thing. This is just a quick response, since we were talking on IRC and this bug now reflects that :D Oh and as mentioned on IRC, you can work around it for your client with: Just once: CAP REQ :labeled-response Then: @label=typing;typing=active TAGMSG #unreal-devel And then, in the error numeric response from the server, you can see the 'typing' tag and ignore it for those cases. Or ignore all TAGMSG errors i guess. Up to you. That's something that "can work today" so to say :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-09-23 13:39 | zw32h | New Issue | |
| 2025-09-23 17:34 | syzop | Assigned To | => syzop |
| 2025-09-23 17:34 | syzop | Status | new => acknowledged |
| 2025-09-23 17:34 | syzop | Note Added: 0023514 | |
| 2025-12-17 17:21 | zw32h | Note Added: 0023583 | |
| 2025-12-17 17:21 | zw32h | File Added: privdeaf-ignore-tagmsg.patch | |
| 2026-01-23 08:16 | syzop | Note Added: 0023598 | |
| 2026-01-23 08:27 | syzop | Note Edited: 0023598 | |
| 2026-01-23 08:28 | syzop | Status | acknowledged => resolved |
| 2026-01-23 08:28 | syzop | Resolution | open => fixed |
| 2026-01-23 08:28 | syzop | Fixed in Version | => 6.2.3-rc1 |
| 2026-01-23 08:28 | syzop | Note Added: 0023599 | |
| 2026-06-02 21:26 | zw32h | Status | resolved => feedback |
| 2026-06-02 21:26 | zw32h | Resolution | fixed => reopened |
| 2026-06-02 21:26 | zw32h | Note Added: 0023664 | |
| 2026-06-05 18:13 | syzop | Note Added: 0023670 | |
| 2026-06-05 18:14 | syzop | Note Edited: 0023670 |
