I'm sending this from my phone so please excuse the top posting. Having given this some further thought, another way around the limitations from my previous email: Another possible workaround would be to implement a system similar to sqlines. Either: A) use nickserv nickname/password B) a nick setting for a separate password (think chanserv webpasswd) C) Separate list within services or stats This could allow immediate hostmask having the user sign on the same way opers do with oper hostmasking. This would allow it to be affective on all servers without requiring any extra work from the server admins. Or we could do user@host matching instead having either a network wide or server by server system similar to the system used on efnet (making it not exclusive to a specific group of people, but that would be an entirely different debate). On Monday, January 26, 2015, Jimmy Hess <mysidia@gmail.com> wrote:
On Mon, Jan 26, 2015 at 2:31 AM, Holbrook Bunting <holbrook@dal.net <javascript:;>> 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
-- holbrook / zort / srd SA: The halcyon team