On Mon, Jan 26, 2015 at 2:31 AM, Holbrook Bunting <holbrook@dal.net> wrote: [snip]
So to get something like this would mean adding into services a flag for say, helpers, into nickserv for a registered nickname.
Yes... Essentially services would need to trigger it immediately after completing any desired authentication procedure, and a NickServ per-nickname boolean flag would seem like the most likely candidate for such a function. Of course an alternative would be to not re-use NickServ-based authentication at all, and just have a single shared password, Or a separate database with usernames and passwords for the 'Helper mask' function, Or simply have a database of registered Google Authenticator TOTP tokens for qualified helpers. These may be more flexible, since it could actually be implemented independent of other services and not require NickServ identification, so the helper could login with a randomized nickname.
The only problem here is that until the user has identified to nickserv, or is using the applicable nickname when connecting and matching a user@host [snip]
Correct. The helper might be subject to the possibility of a premeditated attack from a persistent stalker. I would note, however... that there is a mechanism in bahamut where the user can configure a password in their IRC client, and if they connected to the server using a non-passworded I:Line, the IDENTIFY command is sent upon login, so they might often be identified before /NOTIFY triggers. There is the trouble that, the hostname is exposed if: (1) Services is down, And (2) There is a race condition, between the time the user logs in and the time services However, I think most such abuses are acts of opportunism, a requirement to perform reconnaissance first is increasing time and effort -- even if the shield provided is not perfect, it is setting a higher bar, so it is still an improvement. The above trouble situations or limitations show imperfections that could be improved upon, they don't really negate the benefit, and they should not deter or obstruct implementation. -- -Jimmy