View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003984 | unreal | ircd | public | 2010-12-24 00:49 | 2020-01-10 12:00 |
| Reporter | warg | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.2.9-RC1 | ||||
| Fixed in Version | 5.0.2 | ||||
| Summary | 0003984: TKL exemption for SSL certificates. (requested by Veil). | ||||
| Description | <%Veil> oo oo <%Veil> could we add compatability for except tkl's with ssl certificates? <&warg> great feature suggestion <%Veil> :) <&warg> where IP/hostnames tend to be dynamic, SSL certificates can be very very static. <&warg> That can't happen until 3.2.10 at least though, because 3.2.9 is on freeze I believe. I'll bug it as a feature request. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I do like this suggestion, and it should be expanded to the except ban block as well. This should not be too hard to implement as Unreal already has cert checking, however this probably would not work for exceptions on (g)Z:Lines since the connection is aborted before any information is processed. |
|
|
Sounds like a good idea (and Stealth's remark is correct) |
|
|
bump. post-beta1. |
|
|
This can now be done via https://www.unrealircd.org/docs/Extended_server_bans commit 596cf8e7defb6f2a606e5ca5aad51da9d7843a29 Author: Bram Matthys <[email protected]> Date: Fri Jan 10 11:18:05 2020 +0100 New: extended server bans: exempt by certificate fingerprint and SASL account. See https://www.unrealircd.org/docs/Extended_server_bans Examples with ELINE: /ELINE ~a:TrustedAccount kg 0 This user can bypass kline/gline when using SASL /ELINE ~S:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef kgf 0 Trusted user with this certificate fingerprint It also works with bans, although this would be less common: /GLINE ~a:EvilAccount A more useful purpose would be to use ~r (realname): /GLINE ~r:*some*stupid*real*name* (Although you could already ban realnames via spamfilter 'u') For third party module coders: If you have an extban in group 3 (a "matcher"-extban) then you can opt-in to support this. You do so at extban registration time: req.options = EXTBOPT_TKL; or, if you already had another flag set, like for +I, then: req.options = EXTBOPT_INVEX|EXTBOPT_TKL; In any case, you set the .options before you call ExtbanAdd(). Note that if you do indicate support then your is_ok function will be called like: extban->is_ok(client, NULL, mask, EXBCHK_PARAM, MODE_ADD, EXBTYPE_TKL); Important here is the NULL channel (since there is none) Similarly your is_banned function will be called with BANCHK_CONNECT: extban->is_banned(client, NULL, banstr, BANCHK_JOIN, &msg, &errmsg); Here too, it is important to note that channel is NULL. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-12-24 00:49 | warg | New Issue | |
| 2010-12-24 18:07 | Stealth | Note Added: 0016509 | |
| 2010-12-29 18:28 | syzop | Note Added: 0016533 | |
| 2010-12-29 18:28 | syzop | Assigned To | => syzop |
| 2010-12-29 18:28 | syzop | Status | new => confirmed |
| 2010-12-29 18:29 | syzop | Assigned To | syzop => |
| 2015-07-13 22:24 | syzop | Note Added: 0018491 | |
| 2020-01-10 12:00 | syzop | Assigned To | => syzop |
| 2020-01-10 12:00 | syzop | Status | confirmed => resolved |
| 2020-01-10 12:00 | syzop | Resolution | open => fixed |
| 2020-01-10 12:00 | syzop | Fixed in Version | => 5.0.2 |
| 2020-01-10 12:00 | syzop | Note Added: 0021220 |
