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/passwordB) 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>
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