From surreal.w00t at gmail.com  Thu Jan  4 05:50:33 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu Jan  4 05:50:38 2007
Subject: [IRCServices] NS AJOIN and CS SET RESTRICTED
Message-ID: <b19eae4e0701040550w38e0d6d7ibabd641d2579ede@mail.gmail.com>

Bit of confusion here, I think it could be related to the user having
NS AJOIN enabled.. thoughts are welcome :p. Basic story is that
channel is SET RESTRICTed, Valentine is NOT on the access list, yet
does not seem to be getting correctly removed from the channel. My
guess is something to do with AJOIN, though I could be mistaken.

IRCd is InspIRCd 1.1, should you require a protocol module for testing
or other, one is available from our SVN:
http://svn.inspircd.org/repository/trunk/ircservices-module/inspircd.c

[11:47] 	*	Valentine_SC (VIP@ChatSpike-e494a2ac.bb.online.no) has
joined #La-Torrio.priv
[11:47] 	*	Valentine_SC has quit (Changing hosts)
[11:47] 	*	Valentine_SC (VIP@Brann.Stadion) has joined #La-Torrio.priv
[11:47] 	*	Twofish_aw sets ban on *!*VIP@*.Stadion
[11:47] 	*	Twofish_aw has kicked Valentine_SC from #La-Torrio.priv (Twofish_aw)
[11:56] 	*	slackey|jobb
(slacker007a@ChatSpike-58afe85e.80-203-62.nextgentel.com) has joined
#La-Torrio.priv
[11:58] 	*	Twofish_aw has changed the topic to: Hold inne GZ. Hold
dere her - og kikk innom regelmessig...
[11:58] 	*	Twofish_aw sets ban on *!*@Brann.Stadion

(...) (no unbans - all bans are still active)

[13:01] 	*	Valentine (VIP@ChatSpike-e494a2ac.bb.online.no) has joined
#La-Torrio.priv
[13:01] 	*	Valentine has quit (Changing hosts)
[13:01] 	*	Valentine (VIP@Brann.Stadion) has joined #La-Torrio.priv
[13:01] 	LadauXimA	ikke lenge til1!!
[13:01] 	LadauXimA	ban
[13:02] 	Meg	hallo valentine
[13:02] 	Meg	du pr?ver og komme deg inn her hele tiden
[13:03] 	LadauXimA	im gone
[13:03] 	*	LadauXimA has quit ([CS] Quit: UR MOMMA IS SO FAT THAT SHE
SITS NEXT TO EVERYONE WHEN SHE IS AT THE CINEMA)
[13:04] 	*	aGal-007 (cs_man2@ChatSpike-5782f586.bb.online.no) has
joined #La-Torrio.priv
[13:05] 	aGal-007	sap ?
[13:06] 	Meg	ikke s? mye
[13:06] 	*	Valentine_SC (VIP@ChatSpike-e494a2ac.bb.online.no) has
joined #La-Torrio.priv
[13:06] 	*	Valentine_SC has quit (Changing hosts)
[13:06] 	*	Valentine_SC (VIP@Brann.Stadion) has joined #La-Torrio.priv
[13:07] 	*	Valentine has quit (Operation timed out)
[13:10] 	aGal-007	ok
[13:10] 	*	Slettemoen sets ban on Valentine_SC!VIP@Brann.Stadion
[13:10] 	*	Slettemoen has kicked Valentine_SC from #La-Torrio.priv
(Yes, I have ops &#139;182&#155;)

It's happening with others too:

[13:46:51] <Twofish> [14:40] 	Fatjoe	og du sier eg e gay HAHA
[13:46:52] <Twofish> [14:43] 	*	Twofish sets modes [#La-Torrio.priv +b
*!*da-lec@*.monet.no]
[13:46:52] <Twofish> [14:43] 	*	Twofish has kicked da-lec from
#La-Torrio.priv (mm - bare - bye)
[13:46:59] <Twofish> found him in there just before...
[13:47:53] <Twofish> so there is atleast 4 of them bypassing the "security"

Channel access list:

[13:45:21] <Twofish> [14:44] 	-ChanServ-	  Num   Lev  Nickname
[13:45:22] <Twofish> [14:44] 	-ChanServ-	    1   100  Taule
[13:45:22] <Twofish> [14:44] 	-ChanServ-	    2     1  LadauXimA
[13:45:22] <Twofish> [14:44] 	-ChanServ-	    3    10  Frode
[13:45:22] <Twofish> [14:44] 	-ChanServ-	    4   100  Twofish
[13:45:22] <Twofish> [14:44] 	-ChanServ-	    5     5  Confusion
[13:45:24] <Twofish> [14:44] 	-ChanServ-	    6    15  Fatjoe
[13:45:28] <Twofish> [14:44] 	-ChanServ-	    7     1  XplodingplastiX
[13:45:30] <Twofish> [14:44] 	-ChanServ-	    8     1  qweM
[13:45:32] <Twofish> [14:44] 	-ChanServ-	    9    15  Devilfish
[13:45:34] <Twofish> [14:44] 	-ChanServ-	   10     1  trym
[13:45:36] <Twofish> [14:44] 	-ChanServ-	   11     1  |Mr-OlseN|
[13:45:38] <Twofish> [14:44] 	-ChanServ-	   12     1  DelScorpio
[13:45:40] <Twofish> [14:44] 	-ChanServ-	   13     1  Stighelmer
[13:45:42] <Twofish> [14:44] 	-ChanServ-	   14     1  slackey
[13:45:44] <Twofish> [14:44] 	-ChanServ-	   15     1  Punkpal
[13:45:46] <Twofish> [14:44] 	-ChanServ-	   16     1  Martyy
[13:45:48] <Twofish> [14:44] 	-ChanServ-	   17    25  Sibi
[13:45:50] <Twofish> [14:44] 	-ChanServ-	   18     1  aGal-007
[13:45:52] <Twofish> [14:44] 	-ChanServ-	   19     1  Cheyenne2
[13:45:54] <Twofish> [14:44] 	-ChanServ-	   20     1  Morty--
[13:45:58] <Twofish> [14:44] 	-ChanServ-	   21     1  ralfie
[13:46:00] <Twofish> [14:44] 	-ChanServ-	   22     1  lwiplBlack
[13:46:02] <Twofish> [14:44] 	-ChanServ-	   23     5  Slabbedask
[13:46:04] <Twofish> [14:44] 	-ChanServ-	   24     1  extra|orbit
[13:46:06] <Twofish> [14:44] 	-ChanServ-	   25     1  Meg
[13:46:08] <Twofish> [14:44] 	-ChanServ-	   34    30  De_Morgan
[13:46:10] <Twofish> [14:44] 	-ChanServ-	   50     1  D-W

Thanks. I'm at a bit of a loss here. :p
w00t
From surreal.w00t at gmail.com  Thu Jan  4 05:55:02 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu Jan  4 05:55:06 2007
Subject: [IRCServices] Re: NS AJOIN and CS SET RESTRICTED
In-Reply-To: <b19eae4e0701040550w38e0d6d7ibabd641d2579ede@mail.gmail.com>
References: <b19eae4e0701040550w38e0d6d7ibabd641d2579ede@mail.gmail.com>
Message-ID: <b19eae4e0701040555v529a9426o1d11f1fbe360cfc1@mail.gmail.com>

An addendum, I forgot to mention I think it's NS AJOIN related because
the channel was set +i also.

On 1/4/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
From achurch at achurch.org  Sat Jan  6 10:56:59 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Jan  5 18:02:59 2007
Subject: [IRCServices] NS AJOIN and CS SET RESTRICTED
In-Reply-To: <b19eae4e0701040550w38e0d6d7ibabd641d2579ede@mail.gmail.com>
Message-ID: <459f0347.12125@msgid.achurch.org>

     The first thing that comes to mind is linked nicks.  I notice that
there are a lot of level-1 entries; could the user(s) in question have
nicks linked to these?  Use ChanServ STATUS (requires level 100 access by
default) to check the access level of the user on the channel before
kicking them.  Another possibility is that the ircd is rejecting the KICK
messages from Services; see if there are any relevant messages in the
Services log file.

     As far as joining around bans, that's an ircd issue, not a Services
issue.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

>Bit of confusion here, I think it could be related to the user having
>NS AJOIN enabled.. thoughts are welcome :p. Basic story is that
>channel is SET RESTRICTed, Valentine is NOT on the access list, yet
>does not seem to be getting correctly removed from the channel. My
>guess is something to do with AJOIN, though I could be mistaken.
>
>IRCd is InspIRCd 1.1, should you require a protocol module for testing
>or other, one is available from our SVN:
>http://svn.inspircd.org/repository/trunk/ircservices-module/inspircd.c
From achurch at achurch.org  Sat Jan  6 11:03:46 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Jan  5 18:10:15 2007
Subject: [IRCServices] Re: NS AJOIN and CS SET RESTRICTED
In-Reply-To: <b19eae4e0701040555v529a9426o1d11f1fbe360cfc1@mail.gmail.com>
Message-ID: <459f0504.12267@msgid.achurch.org>

>An addendum, I forgot to mention I think it's NS AJOIN related because
>the channel was set +i also.

     To clarify this, AJOIN only sends out SVSJOIN message for the relevant
user; actual join processing is handled by the ircd, which should only send
out a JOIN message if the user is allowed to join the channel.  It's
possible InspIRCd is not performing those checks correctly, which would
account for users being able to join through bans.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Sat Jan  6 10:53:50 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan  6 10:53:56 2007
Subject: [IRCServices] Re: NS AJOIN and CS SET RESTRICTED
In-Reply-To: <459f0504.12267@msgid.achurch.org>
References: <b19eae4e0701040555v529a9426o1d11f1fbe360cfc1@mail.gmail.com>
	<459f0504.12267@msgid.achurch.org>
Message-ID: <b19eae4e0701061053s6fe64a36k74a7f3d546271b50@mail.gmail.com>

Yes, there was a desync, as we only apply restrictions locally,
however SVSJOIN tried to JoinUser to the channel on every server --
not their local one, appearing to bypass the bans, etc (now fixed in
SVN/upcoming b9).

That's all fixed now, though.

Is there any point allowing AJOIN to a restricted channel if you're
not on the access list though? That seems like it could be used to
create joinfloods of a sort.

Thanks for the reply.

On 1/6/07, Andrew Church <achurch@achurch.org> wrote:
> >An addendum, I forgot to mention I think it's NS AJOIN related because
> >the channel was set +i also.
>
>      To clarify this, AJOIN only sends out SVSJOIN message for the relevant
> user; actual join processing is handled by the ircd, which should only send
> out a JOIN message if the user is allowed to join the channel.  It's
> possible InspIRCd is not performing those checks correctly, which would
> account for users being able to join through bans.
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
From achurch at achurch.org  Sun Jan  7 06:35:00 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan  6 13:39:30 2007
Subject: [IRCServices] Re: NS AJOIN and CS SET RESTRICTED
In-Reply-To: <b19eae4e0701061053s6fe64a36k74a7f3d546271b50@mail.gmail.com>
Message-ID: <45a0170e.71441@msgid.achurch.org>

>Is there any point allowing AJOIN to a restricted channel if you're
>not on the access list though? That seems like it could be used to
>create joinfloods of a sort.

     I suppose it could be useful to have AJOIN report potential problems,
but on the other hand that wouldn't do anything about the case where the
channel is set to RESTRICTED afterwards.  And if a user wants to flood the
network, there are plenty of easier ways--spam /ns HELP, for example. (:

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Fri Jan 12 05:34:41 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Fri Jan 12 05:34:46 2007
Subject: [IRCServices] Weird registration/ID issue
Message-ID: <b19eae4e0701120534k2b331fafvb397102b01b37f9d@mail.gmail.com>

Ok.. this is just plain bizarre.

Had a user come in today and report they are unable to identify as of
today/yesterday or so. Excuse my copypasting of logs.

[12:48:15] <xxx> it appears services refuse to mark me as having
identified for my nickname... if I intentionally type a wrong password
I get a "wrong password" notice, but if I use the right one, I get no
such notice, but no identified status either
[13:05:04] <@w00t> hmm what client are you using
[13:05:41] <+xxx> vanilla mirc
[13:05:46] <@w00t> reconnect
[13:05:50] <@w00t> /debug @d
[13:05:54] <@w00t> identify with services
[13:06:00] <@w00t> PM me the output from the @d window

then in PM..

[13:07:27] <xxx> interestingly, the debug window shows no information
coming back after sending the normal password.
[13:07:42] <w00t> how are you identifying
[13:07:56] <xxx> /nickserv as well as /ns
[13:08:03] <w00t> try /msg nickserv

..same result

His NS INFO showed him offline. Normally I'd leave this as a joke, but
he gave me his password (vaeiiliandor). I register a nickname
(Somenick), auth it, disconnect, reconnect, try login, same result ..
no output from services.

He says it worked fine until yesterday or so, we're running 5.0.55,
compiled on October.

Any ideas on what could cause this one? If relevant, I'll ask Brain /
Craig to check Services' logs as I currently do not have access to the
hub.

Forgive me if ths turns out to be something stupid. :P
From surreal.w00t at gmail.com  Wed Jan 17 19:08:30 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Wed Jan 17 19:08:36 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <b19eae4e0701120534k2b331fafvb397102b01b37f9d@mail.gmail.com>
References: <b19eae4e0701120534k2b331fafvb397102b01b37f9d@mail.gmail.com>
Message-ID: <b19eae4e0701171908u1ab236c6ib9983e380a3a4cfe@mail.gmail.com>

Have another 'no output' situation from the same copy of services,
reproducable with two people at least.

-> dexter.chatspike.net PRIVMSG nickserv :info [OPA]spaceRaptor
-> dexter.chatspike.net PRIVMSG nickserv :info [OPA]spaceRaptor all
<- :NickServ!services@chatspike.net NOTICE w00t :[OPA]spaceRaptor is
[OPA]spaceRaptor
<- :NickServ!services@chatspike.net NOTICE w00t :   Last seen time:
May 30 03:40:27 2006 BST
<- :NickServ!services@chatspike.net NOTICE w00t :  Time registered:
Sep 18 23:55:31 2003 BST
<- :NickServ!services@chatspike.net NOTICE w00t :Last quit message:
[CS] Quit: <[OPA]Anonymous> imagine if the fighter won, due to zedds
random battle code ****Our Enemys Should Fear Us. Our Current Allys
Should Depend On Us. And All Others Should Be Cannon Fodder Below Our
Feet. GO OPA!!!!****
<- :NickServ!services@chatspike.net NOTICE w00t :          Options:
Kill protection, Security

[02:57:28] <w00t> /ns info [OPA]spaceRaptor
[02:57:32] <w00t> do you get any output?
[02:57:56] <peavey> from?
[02:58:04] <w00t> ^ nickserv, with that command
[03:01:35] <peavey> ah no
[03:01:37] <peavey> nothing
[03:01:42] <w00t> no output?
[03:01:53] <peavey> /ns info [OPA]spaceRaptor ALL
[03:01:57] <peavey> but I do from that

Again, seems like a random case, but any ideas on what's going on here
or how to furthre diagnose the problem would be nice.

On 1/12/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
> Ok.. this is just plain bizarre.
>
> Had a user come in today and report they are unable to identify as of
> today/yesterday or so. Excuse my copypasting of logs.
>
> [12:48:15] <xxx> it appears services refuse to mark me as having
> identified for my nickname... if I intentionally type a wrong password
> I get a "wrong password" notice, but if I use the right one, I get no
> such notice, but no identified status either
> [13:05:04] <@w00t> hmm what client are you using
> [13:05:41] <+xxx> vanilla mirc
> [13:05:46] <@w00t> reconnect
> [13:05:50] <@w00t> /debug @d
> [13:05:54] <@w00t> identify with services
> [13:06:00] <@w00t> PM me the output from the @d window
>
> then in PM..
>
> [13:07:27] <xxx> interestingly, the debug window shows no information
> coming back after sending the normal password.
> [13:07:42] <w00t> how are you identifying
> [13:07:56] <xxx> /nickserv as well as /ns
> [13:08:03] <w00t> try /msg nickserv
>
> ..same result
>
> His NS INFO showed him offline. Normally I'd leave this as a joke, but
> he gave me his password (vaeiiliandor). I register a nickname
> (Somenick), auth it, disconnect, reconnect, try login, same result ..
> no output from services.
>
> He says it worked fine until yesterday or so, we're running 5.0.55,
> compiled on October.
>
> Any ideas on what could cause this one? If relevant, I'll ask Brain /
> Craig to check Services' logs as I currently do not have access to the
> hub.
>
> Forgive me if ths turns out to be something stupid. :P
>
From surreal.w00t at gmail.com  Sat Jan 20 15:52:07 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 20 15:52:14 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <b19eae4e0701171908u1ab236c6ib9983e380a3a4cfe@mail.gmail.com>
References: <b19eae4e0701120534k2b331fafvb397102b01b37f9d@mail.gmail.com>
	<b19eae4e0701171908u1ab236c6ib9983e380a3a4cfe@mail.gmail.com>
Message-ID: <b19eae4e0701201552h52f36353kb268f0216f373712@mail.gmail.com>

Disregard this. Turned out to be something incredibly simple, and stupid.

Still would have been nice to know there was someone on the other end
of the mailinglist actually recieving this :P

On 1/18/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
> Have another 'no output' situation from the same copy of services,
> reproducable with two people at least.
>
> -> dexter.chatspike.net PRIVMSG nickserv :info [OPA]spaceRaptor
> -> dexter.chatspike.net PRIVMSG nickserv :info [OPA]spaceRaptor all
> <- :NickServ!services@chatspike.net NOTICE w00t :[OPA]spaceRaptor is
> [OPA]spaceRaptor
> <- :NickServ!services@chatspike.net NOTICE w00t :   Last seen time:
> May 30 03:40:27 2006 BST
> <- :NickServ!services@chatspike.net NOTICE w00t :  Time registered:
> Sep 18 23:55:31 2003 BST
> <- :NickServ!services@chatspike.net NOTICE w00t :Last quit message:
> [CS] Quit: <[OPA]Anonymous> imagine if the fighter won, due to zedds
> random battle code ****Our Enemys Should Fear Us. Our Current Allys
> Should Depend On Us. And All Others Should Be Cannon Fodder Below Our
> Feet. GO OPA!!!!****
> <- :NickServ!services@chatspike.net NOTICE w00t :          Options:
> Kill protection, Security
>
> [02:57:28] <w00t> /ns info [OPA]spaceRaptor
> [02:57:32] <w00t> do you get any output?
> [02:57:56] <peavey> from?
> [02:58:04] <w00t> ^ nickserv, with that command
> [03:01:35] <peavey> ah no
> [03:01:37] <peavey> nothing
> [03:01:42] <w00t> no output?
> [03:01:53] <peavey> /ns info [OPA]spaceRaptor ALL
> [03:01:57] <peavey> but I do from that
>
> Again, seems like a random case, but any ideas on what's going on here
> or how to furthre diagnose the problem would be nice.
>
> On 1/12/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
> > Ok.. this is just plain bizarre.
> >
> > Had a user come in today and report they are unable to identify as of
> > today/yesterday or so. Excuse my copypasting of logs.
> >
> > [12:48:15] <xxx> it appears services refuse to mark me as having
> > identified for my nickname... if I intentionally type a wrong password
> > I get a "wrong password" notice, but if I use the right one, I get no
> > such notice, but no identified status either
> > [13:05:04] <@w00t> hmm what client are you using
> > [13:05:41] <+xxx> vanilla mirc
> > [13:05:46] <@w00t> reconnect
> > [13:05:50] <@w00t> /debug @d
> > [13:05:54] <@w00t> identify with services
> > [13:06:00] <@w00t> PM me the output from the @d window
> >
> > then in PM..
> >
> > [13:07:27] <xxx> interestingly, the debug window shows no information
> > coming back after sending the normal password.
> > [13:07:42] <w00t> how are you identifying
> > [13:07:56] <xxx> /nickserv as well as /ns
> > [13:08:03] <w00t> try /msg nickserv
> >
> > ..same result
> >
> > His NS INFO showed him offline. Normally I'd leave this as a joke, but
> > he gave me his password (vaeiiliandor). I register a nickname
> > (Somenick), auth it, disconnect, reconnect, try login, same result ..
> > no output from services.
> >
> > He says it worked fine until yesterday or so, we're running 5.0.55,
> > compiled on October.
> >
> > Any ideas on what could cause this one? If relevant, I'll ask Brain /
> > Craig to check Services' logs as I currently do not have access to the
> > hub.
> >
> > Forgive me if ths turns out to be something stupid. :P
> >
>
From achurch at achurch.org  Sun Jan 21 09:06:51 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan 20 16:07:42 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <b19eae4e0701201552h52f36353kb268f0216f373712@mail.gmail.com>
Message-ID: <45b2aec9.56021@msgid.achurch.org>

>Disregard this. Turned out to be something incredibly simple, and stupid.
>
>Still would have been nice to know there was someone on the other end
>of the mailinglist actually recieving this :P

     Sorry, I thought I had replied to at least the first message.  Out
of curiosity, what was the problem--a misconfigured client or something?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Sat Jan 20 16:10:08 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 20 16:10:12 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <45b2aec9.56021@msgid.achurch.org>
References: <b19eae4e0701201552h52f36353kb268f0216f373712@mail.gmail.com>
	<45b2aec9.56021@msgid.achurch.org>
Message-ID: <b19eae4e0701201610l9081250lc11d4dac3eeebf1c@mail.gmail.com>

A bug in the server software caused a text filter to be
mis-propegated, thus any line ending in 'or' was ignored. Note the
password ended in 'or', as did the nickname. Simple, but irritatingly
weird. :P

Off-topic momentarily, Andrew, did you recieve my off-list mail sent
in the last week or so?

On 1/21/07, Andrew Church <achurch@achurch.org> wrote:
> >Disregard this. Turned out to be something incredibly simple, and stupid.
> >
> >Still would have been nice to know there was someone on the other end
> >of the mailinglist actually recieving this :P
>
>      Sorry, I thought I had replied to at least the first message.  Out
> of curiosity, what was the problem--a misconfigured client or something?
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
From achurch at achurch.org  Sun Jan 21 09:32:11 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan 20 16:33:29 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <b19eae4e0701201610l9081250lc11d4dac3eeebf1c@mail.gmail.com>
Message-ID: <45b2b4d6.56041@msgid.achurch.org>

>A bug in the server software caused a text filter to be
>mis-propegated, thus any line ending in 'or' was ignored. Note the
>password ended in 'or', as did the nickname. Simple, but irritatingly
>weird. :P

     Ouch.  Yeah, those can be annoying to track down.

>Off-topic momentarily, Andrew, did you recieve my off-list mail sent
>in the last week or so?

     Yes, I did, and thanks--but you can see just how behind I'm getting
on things...

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Sat Jan 20 16:40:43 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 20 16:40:46 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <45b2b4d6.56041@msgid.achurch.org>
References: <b19eae4e0701201610l9081250lc11d4dac3eeebf1c@mail.gmail.com>
	<45b2b4d6.56041@msgid.achurch.org>
Message-ID: <b19eae4e0701201640r3546ec33y635526fa403b4d@mail.gmail.com>

No problems. When/if you get a chance to reply, I'm in no rush. Thanks :)

On 1/21/07, Andrew Church <achurch@achurch.org> wrote:
> >A bug in the server software caused a text filter to be
> >mis-propegated, thus any line ending in 'or' was ignored. Note the
> >password ended in 'or', as did the nickname. Simple, but irritatingly
> >weird. :P
>
>      Ouch.  Yeah, those can be annoying to track down.
>
> >Off-topic momentarily, Andrew, did you recieve my off-list mail sent
> >in the last week or so?
>
>      Yes, I did, and thanks--but you can see just how behind I'm getting
> on things...
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
From mamfelt at acm.org  Sun Jan 21 07:50:15 2007
From: mamfelt at acm.org (Michael Felt)
Date: Sun Jan 21 07:50:23 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <b19eae4e0701201552h52f36353kb268f0216f373712@mail.gmail.com>
References: <b19eae4e0701120534k2b331fafvb397102b01b37f9d@mail.gmail.com>	<b19eae4e0701171908u1ab236c6ib9983e380a3a4cfe@mail.gmail.com>
	<b19eae4e0701201552h52f36353kb268f0216f373712@mail.gmail.com>
Message-ID: <45B38BB7.9030307@acm.org>

Sounds like you solved it. What was it? And yes, there are lots of 
people who read - at least. I am not skilled enough to reply though.

Robin Burchell wrote:
> Disregard this. Turned out to be something incredibly simple, and stupid.
>
> Still would have been nice to know there was someone on the other end
> of the mailinglist actually recieving this :P
>
> On 1/18/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
>> Have another 'no output' situation from the same copy of services,
>> reproducable with two people at least.
>>
>> -> dexter.chatspike.net PRIVMSG nickserv :info [OPA]spaceRaptor
>> -> dexter.chatspike.net PRIVMSG nickserv :info [OPA]spaceRaptor all
>> <- :NickServ!services@chatspike.net NOTICE w00t :[OPA]spaceRaptor is
>> [OPA]spaceRaptor
>> <- :NickServ!services@chatspike.net NOTICE w00t :   Last seen time:
>> May 30 03:40:27 2006 BST
>> <- :NickServ!services@chatspike.net NOTICE w00t :  Time registered:
>> Sep 18 23:55:31 2003 BST
>> <- :NickServ!services@chatspike.net NOTICE w00t :Last quit message:
>> [CS] Quit: <[OPA]Anonymous> imagine if the fighter won, due to zedds
>> random battle code ****Our Enemys Should Fear Us. Our Current Allys
>> Should Depend On Us. And All Others Should Be Cannon Fodder Below Our
>> Feet. GO OPA!!!!****
>> <- :NickServ!services@chatspike.net NOTICE w00t :          Options:
>> Kill protection, Security
>>
>> [02:57:28] <w00t> /ns info [OPA]spaceRaptor
>> [02:57:32] <w00t> do you get any output?
>> [02:57:56] <peavey> from?
>> [02:58:04] <w00t> ^ nickserv, with that command
>> [03:01:35] <peavey> ah no
>> [03:01:37] <peavey> nothing
>> [03:01:42] <w00t> no output?
>> [03:01:53] <peavey> /ns info [OPA]spaceRaptor ALL
>> [03:01:57] <peavey> but I do from that
>>
>> Again, seems like a random case, but any ideas on what's going on here
>> or how to furthre diagnose the problem would be nice.
>>
>> On 1/12/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
>> > Ok.. this is just plain bizarre.
>> >
>> > Had a user come in today and report they are unable to identify as of
>> > today/yesterday or so. Excuse my copypasting of logs.
>> >
>> > [12:48:15] <xxx> it appears services refuse to mark me as having
>> > identified for my nickname... if I intentionally type a wrong password
>> > I get a "wrong password" notice, but if I use the right one, I get no
>> > such notice, but no identified status either
>> > [13:05:04] <@w00t> hmm what client are you using
>> > [13:05:41] <+xxx> vanilla mirc
>> > [13:05:46] <@w00t> reconnect
>> > [13:05:50] <@w00t> /debug @d
>> > [13:05:54] <@w00t> identify with services
>> > [13:06:00] <@w00t> PM me the output from the @d window
>> >
>> > then in PM..
>> >
>> > [13:07:27] <xxx> interestingly, the debug window shows no information
>> > coming back after sending the normal password.
>> > [13:07:42] <w00t> how are you identifying
>> > [13:07:56] <xxx> /nickserv as well as /ns
>> > [13:08:03] <w00t> try /msg nickserv
>> >
>> > ..same result
>> >
>> > His NS INFO showed him offline. Normally I'd leave this as a joke, but
>> > he gave me his password (vaeiiliandor). I register a nickname
>> > (Somenick), auth it, disconnect, reconnect, try login, same result ..
>> > no output from services.
>> >
>> > He says it worked fine until yesterday or so, we're running 5.0.55,
>> > compiled on October.
>> >
>> > Any ideas on what could cause this one? If relevant, I'll ask Brain /
>> > Craig to check Services' logs as I currently do not have access to the
>> > hub.
>> >
>> > Forgive me if ths turns out to be something stupid. :P
>> >
>>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
From surreal.w00t at gmail.com  Sun Jan 21 09:03:42 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sun Jan 21 09:03:48 2007
Subject: [IRCServices] Re: Weird registration/ID issue
In-Reply-To: <b19eae4e0701201610l9081250lc11d4dac3eeebf1c@mail.gmail.com>
References: <b19eae4e0701201552h52f36353kb268f0216f373712@mail.gmail.com>
	<45b2aec9.56021@msgid.achurch.org>
	<b19eae4e0701201610l9081250lc11d4dac3eeebf1c@mail.gmail.com>
Message-ID: <b19eae4e0701210903m56b42146gce9eae2d3b4c20d@mail.gmail.com>

To quote my previous post ;-)

On 1/21/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
> A bug in the server software caused a text filter to be
> mis-propegated, thus any line ending in 'or' was ignored. Note the
> password ended in 'or', as did the nickname. Simple, but irritatingly
> weird. :P
From paul.simpkin at hitec-systems.co.uk  Tue Feb  6 17:05:30 2007
From: paul.simpkin at hitec-systems.co.uk (Paul Simpkin)
Date: Tue Feb  6 17:05:13 2007
Subject: [IRCServices] Auto-op
Message-ID: <3169090C6ED7594884DB74E155D84A67016307@server-mail.hitec-systems.co.uk>

Hi,

 

I can't see the auto-op option any more after I install my bot on new
box.

 

 

Thanks for any help with this I am a total newbe when using this! 

 

 

 

 

Here is a list of my commands:

 

There use to be autoop......

 

-ChanServ- The following commands can be used with ChanServ:

-

-ChanServ-  

-

-ChanServ-     REGISTER   Register a channel

-

-ChanServ-     IDENTIFY   Identify yourself with your password

-

-ChanServ-     SENDPASS   Send a channel's password to you

-

-ChanServ-     DROP       Cancel the registration of a channel

-

-ChanServ-     SET        Set channel options and information

-

-ChanServ-     UNSET      Clear channel information

-

-ChanServ-     INFO       Show channel options and information

-

-ChanServ-     ACCESS     Maintain the overall channel access list

-

-ChanServ-     LEVELS     Fine-tune channel access levels

-

-ChanServ-     OP         Give a user chanop status (+o)

-

-ChanServ-     DEOP       Remove chanop status (+o)

-

-ChanServ-     VOICE      Give a user voice status (+v)

-

-ChanServ-     DEVOICE    Remove voice status (+v)

-

-ChanServ-     HALFOP     Give a user halfop status (+h)

-

-ChanServ-     DEHALFOP   Remove halfop status (+h)

-

-ChanServ-     PROTECT    Give a user protected status (+a)

-

-ChanServ-     DEPROTECT  Remove protected status (+a)

-

-ChanServ-     INVITE     Invite yourself to a channel

-

-ChanServ-     UNBAN      Unban yourself from a channel

-

-ChanServ-     KICK       Kick a user from a channel

-

-ChanServ-     TOPIC      Change a channel's topic

-

-ChanServ-     CLEAR      Clear channel modes or mass-kick users

-

-ChanServ-     STATUS     Return a user's access level on a channel

-

-ChanServ-     LIST       List registered channels

-

-ChanServ-     AKICK      Maintain the AutoKick list

-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070207/11efa8ef/attachment-0001.html
From semir at mslink.at  Tue Feb  6 17:08:21 2007
From: semir at mslink.at (Semir M.)
Date: Tue Feb  6 17:08:32 2007
Subject: [IRCServices] Auto-op
In-Reply-To: <3169090C6ED7594884DB74E155D84A67016307@server-mail.hitec-systems.co.uk>
References: <3169090C6ED7594884DB74E155D84A67016307@server-mail.hitec-systems.co.uk>
Message-ID: <86c55b630702061708t3f303383mde5a66cc09fb6eb@mail.gmail.com>

Hello,

mh, access (with level 50+) is a autoop level :-)

if you like sop/aop/vop, so you have to enable the module xop if i'm not
wrong ...


regards
Semir M.



2007/2/7, Paul Simpkin <paul.simpkin@hitec-systems.co.uk>:
>
>  Hi,
>
>
>
> I can't see the auto-op option any more after I install my bot on new box.
>
>
>
>
>
> Thanks for any help with this I am a total newbe when using this!
>
>
>
>
>
>
>
>
>
> Here is a list of my commands:
>
>
>
> There use to be autoop??
>
>
>
> -ChanServ- The following commands can be used with ChanServ:
>
> -
>
> -ChanServ-
>
> -
>
> -ChanServ-     REGISTER   Register a channel
>
> -
>
> -ChanServ-     IDENTIFY   Identify yourself with your password
>
> -
>
> -ChanServ-     SENDPASS   Send a channel's password to you
>
> -
>
> -ChanServ-     DROP       Cancel the registration of a channel
>
> -
>
> -ChanServ-     SET        Set channel options and information
>
> -
>
> -ChanServ-     UNSET      Clear channel information
>
> -
>
> -ChanServ-     INFO       Show channel options and information
>
> -
>
> -ChanServ-     ACCESS     Maintain the overall channel access list
>
> -
>
> -ChanServ-     LEVELS     Fine-tune channel access levels
>
> -
>
> -ChanServ-     OP         Give a user chanop status (+o)
>
> -
>
> -ChanServ-     DEOP       Remove chanop status (+o)
>
> -
>
> -ChanServ-     VOICE      Give a user voice status (+v)
>
> -
>
> -ChanServ-     DEVOICE    Remove voice status (+v)
>
> -
>
> -ChanServ-     HALFOP     Give a user halfop status (+h)
>
> -
>
> -ChanServ-     DEHALFOP   Remove halfop status (+h)
>
> -
>
> -ChanServ-     PROTECT    Give a user protected status (+a)
>
> -
>
> -ChanServ-     DEPROTECT  Remove protected status (+a)
>
> -
>
> -ChanServ-     INVITE     Invite yourself to a channel
>
> -
>
> -ChanServ-     UNBAN      Unban yourself from a channel
>
> -
>
> -ChanServ-     KICK       Kick a user from a channel
>
> -
>
> -ChanServ-     TOPIC      Change a channel's topic
>
> -
>
> -ChanServ-     CLEAR      Clear channel modes or mass-kick users
>
> -
>
> -ChanServ-     STATUS     Return a user's access level on a channel
>
> -
>
> -ChanServ-     LIST       List registered channels
>
> -
>
> -ChanServ-     AKICK      Maintain the AutoKick list
>
> -
>
> www.hitec-systems.co.uk
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070207/59270f74/attachment.html
From paul.simpkin at hitec-systems.co.uk  Tue Feb  6 17:10:37 2007
From: paul.simpkin at hitec-systems.co.uk (Paul Simpkin)
Date: Tue Feb  6 17:10:20 2007
Subject: [IRCServices] Auto-op
Message-ID: <3169090C6ED7594884DB74E155D84A67016308@server-mail.hitec-systems.co.uk>

Thanks! 

 

Paul

 

________________________________

From: ircservices-bounces@ircservices.za.net
[mailto:ircservices-bounces@ircservices.za.net] On Behalf Of Semir M.
Sent: 07 February 2007 01:08
To: IRC Services General Mailing List
Subject: Re: [IRCServices] Auto-op

 

Hello,

mh, access (with level 50+) is a autoop level :-)

if you like sop/aop/vop, so you have to enable the module xop if i'm not
wrong ...


regards
Semir M.




2007/2/7, Paul Simpkin <paul.simpkin@hitec-systems.co.uk>:

Hi,

 

I can't see the auto-op option any more after I install my bot on new
box.

 

 

Thanks for any help with this I am a total newbe when using this! 

 

 

 

 

Here is a list of my commands:

 

There use to be autoop......

 

-ChanServ- The following commands can be used with ChanServ:

-

-ChanServ-  

-

-ChanServ-     REGISTER   Register a channel

-

-ChanServ-     IDENTIFY   Identify yourself with your password

-

-ChanServ-     SENDPASS   Send a channel's password to you

-

-ChanServ-     DROP       Cancel the registration of a channel

-

-ChanServ-     SET        Set channel options and information

-

-ChanServ-     UNSET      Clear channel information

-

-ChanServ-     INFO       Show channel options and information

-

-ChanServ-     ACCESS     Maintain the overall channel access list

-

-ChanServ-     LEVELS     Fine-tune channel access levels

-

-ChanServ-     OP         Give a user chanop status (+o)

-

-ChanServ-     DEOP       Remove chanop status (+o)

-

-ChanServ-     VOICE      Give a user voice status (+v)

-

-ChanServ-     DEVOICE    Remove voice status (+v)

-

-ChanServ-     HALFOP     Give a user halfop status (+h)

-

-ChanServ-     DEHALFOP   Remove halfop status (+h)

-

-ChanServ-     PROTECT    Give a user protected status (+a)

-

-ChanServ-     DEPROTECT  Remove protected status (+a)

-

-ChanServ-     INVITE     Invite yourself to a channel

-

-ChanServ-     UNBAN      Unban yourself from a channel

-

-ChanServ-     KICK       Kick a user from a channel

-

-ChanServ-     TOPIC      Change a channel's topic

-

-ChanServ-     CLEAR      Clear channel modes or mass-kick users

-

-ChanServ-     STATUS     Return a user's access level on a channel

-

-ChanServ-     LIST       List registered channels

-

-ChanServ-     AKICK      Maintain the AutoKick list

-

 <http://www.hitec-systems.co.uk/logo.jpg> 

www.hitec-systems.co.uk


------------------------------------------------------------------
To unsubscribe or change your subscription options, visit:
http://lists.ircservices.za.net/mailman/listinfo/ircservices

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070207/0d11b51a/attachment-0001.htm
From opticphase at gmail.com  Fri Mar 16 20:34:25 2007
From: opticphase at gmail.com (J. King)
Date: Fri Mar 16 20:34:31 2007
Subject: [IRCServices] Regarding Founder Passwords
Message-ID: <2ae262ff0703162034t5b0f5298y95456d0513b8e7ce@mail.gmail.com>

Say I identify to a channel with the founder password, and I am either not
in the room or have left the room. Is there a time limit as to when the
'founder access' expires, or is that data only destroyed when I disconnect
or otherwise part from my registered nickname?

Thanks,
Phase
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070316/d18e0fab/attachment.html
From achurch at achurch.org  Sat Mar 17 12:55:02 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Mar 16 20:57:35 2007
Subject: [IRCServices] Regarding Founder Passwords
In-Reply-To: <2ae262ff0703162034t5b0f5298y95456d0513b8e7ce@mail.gmail.com>
Message-ID: <45fb672c.43123@msgid.achurch.org>

>Say I identify to a channel with the founder password, and I am either not
>in the room or have left the room. Is there a time limit as to when the
>'founder access' expires, or is that data only destroyed when I disconnect
>or otherwise part from my registered nickname?

     Services keeps track of channels you have identified for as long
as you are connected to IRC, even if you change your nickname.  (The
assumption is that if you know the password for the channel, you're
authorized to perform founder actions on that channel, and that fact
won't change regardless of what other actions you might take on IRC.)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From opticphase at gmail.com  Fri Mar 16 23:32:17 2007
From: opticphase at gmail.com (J. King)
Date: Fri Mar 16 23:32:20 2007
Subject: [IRCServices] Regarding Founder Passwords
In-Reply-To: <45fb672c.43123@msgid.achurch.org>
References: <2ae262ff0703162034t5b0f5298y95456d0513b8e7ce@mail.gmail.com>
	<45fb672c.43123@msgid.achurch.org>
Message-ID: <2ae262ff0703162332v71db7b13k3191a26821838950@mail.gmail.com>

Thanks!

On 3/16/07, Andrew Church <achurch@achurch.org> wrote:
>
> >Say I identify to a channel with the founder password, and I am either
> not
> >in the room or have left the room. Is there a time limit as to when the
> >'founder access' expires, or is that data only destroyed when I
> disconnect
> >or otherwise part from my registered nickname?
>
>      Services keeps track of channels you have identified for as long
> as you are connected to IRC, even if you change your nickname.  (The
> assumption is that if you know the password for the channel, you're
> authorized to perform founder actions on that channel, and that fact
> won't change regardless of what other actions you might take on IRC.)
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070317/80cd3dbc/attachment.html
From bu7cher at yandex.ru  Fri Mar 23 00:55:39 2007
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Fri Mar 23 00:56:38 2007
Subject: [IRCServices] services panic
Message-ID: <460387FB.104@yandex.ru>

Hi, i've got services panic on the FreeBSD 6.2-STABLE amd64.
I have in the log:

[Mar 23 10:31:20 2007] PANIC! signal 10, buffer = :IIIEFF PRIVMSG 
ChanServ :access #greenlan list 1-999
[Mar 23 10:31:20 2007] Services terminating: Bus error: 10

When i try this command:
/chanserv access #greenlan list 1-999

I've got:
[Mar 23 10:38:50 2007] PANIC! signal 10, buffer = :butcher PRIVMSG 
ChanServ@services.heaven.hvn :access #greenlan list 1-999
[Mar 23 10:38:50 2007] Services terminating: Bus error: 10


-- 
WBR, Andrey V. Elsukov
From achurch at achurch.org  Fri Mar 23 17:25:39 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Mar 23 01:28:36 2007
Subject: [IRCServices] services panic
In-Reply-To: <460387FB.104@yandex.ru>
Message-ID: <46038fb0.41737@msgid.achurch.org>

>[Mar 23 10:31:20 2007] PANIC! signal 10, buffer = :IIIEFF PRIVMSG 
>ChanServ :access #greenlan list 1-999
>[Mar 23 10:31:20 2007] Services terminating: Bus error: 10

     A "bus error" usually indicates a hardware failure or other system
error unrelated to Services.  I'm unable to reproduce this error; try
moving Services to a different computer and see if the problem persists.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From bu7cher at yandex.ru  Fri Mar 23 01:29:12 2007
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Fri Mar 23 01:29:30 2007
Subject: [IRCServices] services panic
In-Reply-To: <460387FB.104@yandex.ru>
References: <460387FB.104@yandex.ru>
Message-ID: <46038FD8.5020900@yandex.ru>

Andrey V. Elsukov ?????:
> Hi, i've got services panic on the FreeBSD 6.2-STABLE amd64.
> I have in the log:
> 
> [Mar 23 10:31:20 2007] PANIC! signal 10, buffer = :IIIEFF PRIVMSG 
> ChanServ :access #greenlan list 1-999
> [Mar 23 10:31:20 2007] Services terminating: Bus error: 10

Sorry, forgot, I use ircservices-5.0.59.

-- 
WBR, Andrey V. Elsukov
From bu7cher at yandex.ru  Fri Mar 23 01:49:22 2007
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Fri Mar 23 01:49:33 2007
Subject: [IRCServices] services panic
In-Reply-To: <46038fb0.41737@msgid.achurch.org>
References: <46038fb0.41737@msgid.achurch.org>
Message-ID: <46039492.3010700@yandex.ru>

Andrew Church ?????:
>> [Mar 23 10:31:20 2007] PANIC! signal 10, buffer = :IIIEFF PRIVMSG 
>> ChanServ :access #greenlan list 1-999
>> [Mar 23 10:31:20 2007] Services terminating: Bus error: 10
> 
>      A "bus error" usually indicates a hardware failure or other system
> error unrelated to Services.  I'm unable to reproduce this error; try
> moving Services to a different computer and see if the problem persists.

I've tried this several times and sometimes i've got a SIGSEGV:
[Mar 23 10:26:45 2007] PANIC! signal 11, buffer = :IIIEFF PRIVMSG 
ChanServ :access #barakholka list 1-999
[Mar 23 10:26:45 2007] Services terminating: Segmentation fault: 11
[Mar 23 10:49:46 2007] PANIC! signal 11, buffer = :IIIEFF? PRIVMSG 
ChanServ :access #xxx list 1-999
[Mar 23 10:49:46 2007] Services terminating: Segmentation fault: 11

Maybe this problem is related to amd64?

-- 
WBR, Andrey V. Elsukov
From xxx.coder at gmail.com  Fri Mar 23 10:23:03 2007
From: xxx.coder at gmail.com (ongeboren)
Date: Fri Mar 23 10:23:06 2007
Subject: [IRCServices] Regarding Founder Passwords
In-Reply-To: <45fb672c.43123@msgid.achurch.org>
References: <2ae262ff0703162034t5b0f5298y95456d0513b8e7ce@mail.gmail.com>
	<45fb672c.43123@msgid.achurch.org>
Message-ID: <ce6d53600703231023y1677d0fbue43e3d1378805fb9@mail.gmail.com>

So, if your founder password ever gets compromised, no matter how many
times you change it, if there are other persons who identified for
that channel, they will stay identified and will be able to request
the new password be sent to their emails?

On 3/17/07, Andrew Church <achurch@achurch.org> wrote:
> >Say I identify to a channel with the founder password, and I am either not
> >in the room or have left the room. Is there a time limit as to when the
> >'founder access' expires, or is that data only destroyed when I disconnect
> >or otherwise part from my registered nickname?
>
>      Services keeps track of channels you have identified for as long
> as you are connected to IRC, even if you change your nickname.  (The
> assumption is that if you know the password for the channel, you're
> authorized to perform founder actions on that channel, and that fact
> won't change regardless of what other actions you might take on IRC.)
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>


-- 
Evlogi Petrov - ongeboren@UniBG
From achurch at achurch.org  Sat Mar 24 02:29:45 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Mar 23 10:52:21 2007
Subject: [IRCServices] Regarding Founder Passwords
In-Reply-To: <ce6d53600703231023y1677d0fbue43e3d1378805fb9@mail.gmail.com>
Message-ID: <460413d1.55423@msgid.achurch.org>

>So, if your founder password ever gets compromised, no matter how many
>times you change it, if there are other persons who identified for
>that channel, they will stay identified and will be able to request
>the new password be sent to their emails?

     That's correct with respect to Services 5.0.  The SENDPASS feature
has been dropped from Services 5.1 so that particular problem is no longer
an issue.  You do, however, raise a valid point with respect to users who
remain connected to the network, and I have changed ChanServ SET PASSWORD
in 5.1 to clear founder privileges from all users except the one setting
the password (see patch below, which may also work with 5.0 but hasn't
been tested--I'll look into including this in 5.0 as well).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

Index: modules/chanserv/set.c
===================================================================
RCS file: /var/local/cvsroot/ircservices/modules/chanserv/set.c,v
retrieving revision 2.66
diff -u -r2.66 set.c
--- modules/chanserv/set.c	16 Feb 2007 12:49:31 -0000	2.66
+++ modules/chanserv/set.c	23 Mar 2007 17:44:52 -0000
@@ -334,6 +334,7 @@
 static void do_set_password(User *u, ChannelInfo *ci, char *param)
 {
     Password passbuf;
+    User *u2;
 
     if (stricmp(param, ci->name) == 0
      || stricmp(param, ci->name+1) == 0
@@ -363,6 +364,19 @@
         module_log("%s!%s@%s set password as Services admin for %s",
                    u->nick, u->username, u->host, ci->name);
     }
+    /* Clear founder privileges from all other users who might have
+     * identified earlier. */
+    for (u2 = first_user(); u2; u2 = next_user()) {
+        if (u2 != u) {
+            struct u_chaninfolist *c, *c2;
+            LIST_FOREACH_SAFE (c, u2->id_chans, c2) {
+                if (irc_stricmp(c->chan, ci->name) == 0) {
+                    LIST_REMOVE(c, u2->id_chans);
+                    free(c);
+                }
+            }
+        }
+    }
 }
 
 /*************************************************************************/
From achurch at achurch.org  Sat Mar 24 03:22:11 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Mar 23 11:28:03 2007
Subject: [IRCServices] Services 5.0.60 released
Message-ID: <46041c2d.17615@msgid.achurch.org>

     Services 5.0.60 has been released, and can be downloaded from:

http://www.ircservices.za.net/download/   (Japan)
ftp://ftp.esper.net/ircservices/          (Western USA)

c00180091fce3277121d897e0f6f2529  ircservices-5.0.60.tar.gz
3a89cc811aa26bcb7f922388236253a5  ircservices-5.0.60.diff.gz
34f34c690facf1bab88c60c189e2f284  ircservices-5.0.60-1.i386.rpm
715c70cfbf2b1f391606c56f2228a4de  ircservices_5.0.60-1_i386.deb

The mirrors should have it shortly.

     This release changes the semantics of the ChanServ SET PASSWORD
command to remove founder privileges from all users who had previously
identified for the channel, to prevent users who do not know the new
password from performing founder-level operations.  While only a concern
in limited circumstances, this problem can (for example) allow a malicious
user who has stolen a channel password to use the SENDPASS command to
learn the new channel password without having to identify again.  Networks
for which this is a concern should upgrade as soon as possible.

Changes in version 5.0.60
-------------------------
2007/03/24	Changed ChanServ SET PASSWORD to remove founder privileges
		    from any users who had previously identified for the
		    channel (backported from 5.1a13).  Reported by
		    ongeboren <xxx.coder@gmail.com>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From nick at nickgawronski.com  Fri Mar 23 20:07:07 2007
From: nick at nickgawronski.com (Nick Gawronski)
Date: Fri Mar 23 20:07:19 2007
Subject: [IRCServices] Services 5.0.60 released
References: <46041c2d.17615@msgid.achurch.org>
Message-ID: <005701c76dc1$8552a490$250110ac@CHIHUAHUAD1>

Hi, In order to apply this upgrade will I need to upgrade anything in either 
ircservices.conf or modules.conf?  In memory I still have services 5.0.56 
running but on disk I have version 5.0.59, I see no reason to restart the 
version in ram if it is running correctly, the new version will just be 
loaded if the old one crashes.
Nick Gawronski irc.nickgawronski.com
----- Original Message ----- 
From: "Andrew Church" <achurch@achurch.org>
To: "services" <ircservices@ircservices.za.net>
Sent: Friday, March 23, 2007 1:22 PM
Subject: [IRCServices] Services 5.0.60 released


>     Services 5.0.60 has been released, and can be downloaded from:
>
> http://www.ircservices.za.net/download/   (Japan)
> ftp://ftp.esper.net/ircservices/          (Western USA)
>
> c00180091fce3277121d897e0f6f2529  ircservices-5.0.60.tar.gz
> 3a89cc811aa26bcb7f922388236253a5  ircservices-5.0.60.diff.gz
> 34f34c690facf1bab88c60c189e2f284  ircservices-5.0.60-1.i386.rpm
> 715c70cfbf2b1f391606c56f2228a4de  ircservices_5.0.60-1_i386.deb
>
> The mirrors should have it shortly.
>
>     This release changes the semantics of the ChanServ SET PASSWORD
> command to remove founder privileges from all users who had previously
> identified for the channel, to prevent users who do not know the new
> password from performing founder-level operations.  While only a concern
> in limited circumstances, this problem can (for example) allow a malicious
> user who has stolen a channel password to use the SENDPASS command to
> learn the new channel password without having to identify again.  Networks
> for which this is a concern should upgrade as soon as possible.
>
> Changes in version 5.0.60
> -------------------------
> 2007/03/24 Changed ChanServ SET PASSWORD to remove founder privileges
>     from any users who had previously identified for the
>     channel (backported from 5.1a13).  Reported by
>     ongeboren <xxx.coder@gmail.com>
>
>  --Andrew Church
>    achurch@achurch.org
>    http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
> 

From Craig at frostycoolslug.com  Sat Mar 24 10:53:50 2007
From: Craig at frostycoolslug.com (Craig McLure)
Date: Sat Mar 24 10:54:01 2007
Subject: [IRCServices] Services 5.0.60 released
In-Reply-To: <005701c76dc1$8552a490$250110ac@CHIHUAHUAD1>
References: <46041c2d.17615@msgid.achurch.org>
	<005701c76dc1$8552a490$250110ac@CHIHUAHUAD1>
Message-ID: <8a79f15a0703241053oa5480abv6d492f30732fa185@mail.gmail.com>

To my knowledge, nothing has change which requires a config change for
a VERY long time, and the changelog
(http://www.ircservices.za.net/Changes.txt) seems to support that, so
you should be fine as you are

On 24/03/07, Nick Gawronski <nick@nickgawronski.com> wrote:
> Hi, In order to apply this upgrade will I need to upgrade anything in either
> ircservices.conf or modules.conf?  In memory I still have services 5.0.56
> running but on disk I have version 5.0.59, I see no reason to restart the
> version in ram if it is running correctly, the new version will just be
> loaded if the old one crashes.
> Nick Gawronski irc.nickgawronski.com
> ----- Original Message -----
> From: "Andrew Church" <achurch@achurch.org>
> To: "services" <ircservices@ircservices.za.net>
> Sent: Friday, March 23, 2007 1:22 PM
> Subject: [IRCServices] Services 5.0.60 released
>
>
> >     Services 5.0.60 has been released, and can be downloaded from:
> >
> > http://www.ircservices.za.net/download/   (Japan)
> > ftp://ftp.esper.net/ircservices/          (Western USA)
> >
> > c00180091fce3277121d897e0f6f2529  ircservices-5.0.60.tar.gz
> > 3a89cc811aa26bcb7f922388236253a5  ircservices-5.0.60.diff.gz
> > 34f34c690facf1bab88c60c189e2f284  ircservices-5.0.60-1.i386.rpm
> > 715c70cfbf2b1f391606c56f2228a4de  ircservices_5.0.60-1_i386.deb
> >
> > The mirrors should have it shortly.
> >
> >     This release changes the semantics of the ChanServ SET PASSWORD
> > command to remove founder privileges from all users who had previously
> > identified for the channel, to prevent users who do not know the new
> > password from performing founder-level operations.  While only a concern
> > in limited circumstances, this problem can (for example) allow a malicious
> > user who has stolen a channel password to use the SENDPASS command to
> > learn the new channel password without having to identify again.  Networks
> > for which this is a concern should upgrade as soon as possible.
> >
> > Changes in version 5.0.60
> > -------------------------
> > 2007/03/24 Changed ChanServ SET PASSWORD to remove founder privileges
> >     from any users who had previously identified for the
> >     channel (backported from 5.1a13).  Reported by
> >     ongeboren <xxx.coder@gmail.com>
> >
> >  --Andrew Church
> >    achurch@achurch.org
> >    http://achurch.org/
> > ------------------------------------------------------------------
> > To unsubscribe or change your subscription options, visit:
> > http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>


-- 
/**********************************************
 *        Craig "FrostyCoolSlug" McLure
 * ChatSpike    - http://www.chatspike.net
 * InspIRCd     - http://www.inspircd.org
 **********************************************/
From nim at shadowfire.org  Tue Mar 27 17:34:08 2007
From: nim at shadowfire.org (nim@shadowfire.org)
Date: Tue Mar 27 17:34:12 2007
Subject: [IRCServices] IrcServices enforcing +R
Message-ID: <20070328003408.GA15055@localhost.localdomain>


<snip>
2005/03/31	ChanServ now stops non-identified users from joining
		    channels with mode +R locked on.  Suggested by
		    Dionisios K. <vonitsa_net@xxxxx.xx>
</snip>

As per the changelog, on 2005/03/31, ircservices started enforcing +R.  It has been suggested by some users on shadowfire that there are cases when 
this is not a desireable action.  Is there a way that you can make this a configurable option by the channel founder via /msg chanserv set?

Nim
Network Administrator
Shadowfire IRC network

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070327/bb672509/attachment.pgp
From achurch at achurch.org  Wed Mar 28 12:27:33 2007
From: achurch at achurch.org (Andrew Church)
Date: Tue Mar 27 20:30:04 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <20070328003408.GA15055@localhost.localdomain>
Message-ID: <4609e138.15266@msgid.achurch.org>

>As per the changelog, on 2005/03/31, ircservices started enforcing +R.  It =
>has been suggested by some users on shadowfire that there are cases when=20
>this is not a desireable action.  Is there a way that you can make this a c=
>onfigurable option by the channel founder via /msg chanserv set?

     Since the whole intent of +R is to prevent users with unregistered
nicknames from joining the channel, I don't see what point there would be
to this.  If you want to allow such users to join the channel, then don't
lock +R on.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From nim at shadowfire.org  Tue Mar 27 20:57:37 2007
From: nim at shadowfire.org (nim@shadowfire.org)
Date: Tue Mar 27 20:57:42 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <4609e138.15266@msgid.achurch.org>
References: <20070328003408.GA15055@localhost.localdomain>
	<4609e138.15266@msgid.achurch.org>
Message-ID: <20070328035737.GB19013@localhost.localdomain>

The problem was, when services split, some users get unidentified, and chanserv joins and does a kick banning spree, and yes, I am using the lastest 
version of services.

On Wed, Mar 28, 2007 at 12:27:33PM +0900, Andrew Church wrote:
> >As per the changelog, on 2005/03/31, ircservices started enforcing +R.  It =
> >has been suggested by some users on shadowfire that there are cases when=20
> >this is not a desireable action.  Is there a way that you can make this a c=
> >onfigurable option by the channel founder via /msg chanserv set?
> 
>      Since the whole intent of +R is to prevent users with unregistered
> nicknames from joining the channel, I don't see what point there would be
> to this.  If you want to allow such users to join the channel, then don't
> lock +R on.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070327/7d2b7c92/attachment.pgp
From achurch at achurch.org  Wed Mar 28 14:58:38 2007
From: achurch at achurch.org (Andrew Church)
Date: Tue Mar 27 23:03:21 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <20070328035737.GB19013@localhost.localdomain>
Message-ID: <460a0526.15370@msgid.achurch.org>

>The problem was, when services split, some users get unidentified, and chan=
>serv joins and does a kick banning spree, and yes, I am using the lastest=
>=20
>version of services.

     If ChanServ "joins", you're not using IRC Services.  In any case,
Services keeps track of users' identification status across netsplits and
restarts (unless you have NoSplitRecovery set in your ircservices.conf),
so the only users that would be affected by this are those that first
connected to the network while Services was split.  If this bothers you,
then again, the answer is not to use MLOCK +R (you can, of course, still
use +R normally).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From nim at shadowfire.org  Wed Mar 28 06:08:45 2007
From: nim at shadowfire.org (nim@shadowfire.org)
Date: Wed Mar 28 06:08:56 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <460a0526.15370@msgid.achurch.org>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
Message-ID: <20070328130845.GA21510@localhost.localdomain>



>      If ChanServ "joins", you're not using IRC Services.


19:02 <nim> and
19:02 <nim> mlock +R
19:02 <mithrandi> done
19:02 <nim> just for curiosities sake
19:02 -!- ChanServ [services@shadowfire.org] has joined #testquux
19:02 -!- mode/#testquux [+b *!mithrandi@*.telkomadsl.co.za] by ChanServ
19:02 -!- mithtest was kicked from #testquux by ChanServ [You are not permitted to be on this channel.]
19:02 -!- mode/#testquux [+q mithrandi] by ChanServ


<08:06:17> -!- Irssi: Changed to shadowfire server 65.110.62.93
<08:08:30> [shadowfire] -!- [Services.ShadowFire.ORG] ircservices-5.0.60 Services.ShadowFire.ORG build #1, compiled Sat Mar 24 15:02:53 EDT 2007


Nim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070328/b4dfa3a6/attachment-0001.pgp
From nim at shadowfire.org  Wed Mar 28 06:10:53 2007
From: nim at shadowfire.org (nim@shadowfire.org)
Date: Wed Mar 28 06:10:56 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <460a0526.15370@msgid.achurch.org>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
Message-ID: <20070328131053.GB21510@localhost.localdomain>

Forgot to add, thanks anyway.

On Wed, Mar 28, 2007 at 02:58:38PM +0900, Andrew Church wrote:
> >The problem was, when services split, some users get unidentified, and chan=
> >serv joins and does a kick banning spree, and yes, I am using the lastest=
> >=20
> >version of services.
> 
>      If ChanServ "joins", you're not using IRC Services.  In any case,
> Services keeps track of users' identification status across netsplits and
> restarts (unless you have NoSplitRecovery set in your ircservices.conf),
> so the only users that would be affected by this are those that first
> connected to the network while Services was split.  If this bothers you,
> then again, the answer is not to use MLOCK +R (you can, of course, still
> use +R normally).
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070328/421c04a1/attachment.pgp
From ron2k.za at gmail.com  Wed Mar 28 06:12:25 2007
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Wed Mar 28 06:12:31 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <20070328130845.GA21510@localhost.localdomain>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
	<20070328130845.GA21510@localhost.localdomain>
Message-ID: <debb3bc0703280612r7548a454lc37f67b5417624ff@mail.gmail.com>

I have to say that I'm in agreement with Andrew here. If you mlock +R,
you're implying that you want Services to enforce it.

Just my 2 cents worth.

--K

On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
>
>
> >      If ChanServ "joins", you're not using IRC Services.
>
>
> 19:02 <nim> and
> 19:02 <nim> mlock +R
> 19:02 <mithrandi> done
> 19:02 <nim> just for curiosities sake
> 19:02 -!- ChanServ [services@shadowfire.org] has joined #testquux
> 19:02 -!- mode/#testquux [+b *!mithrandi@*.telkomadsl.co.za] by ChanServ
> 19:02 -!- mithtest was kicked from #testquux by ChanServ [You are not permitted to be on this channel.]
> 19:02 -!- mode/#testquux [+q mithrandi] by ChanServ
>
>
> <08:06:17> -!- Irssi: Changed to shadowfire server 65.110.62.93
> <08:08:30> [shadowfire] -!- [Services.ShadowFire.ORG] ircservices-5.0.60 Services.ShadowFire.ORG build #1, compiled Sat Mar 24 15:02:53 EDT 2007
>
>
> Nim
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGCmjdhwuzJdpbgpkRApWWAKCigegERZrLgZXI9EteO1FiTm4QRACgjMqZ
> AWlXwY+9Bn64FdmqqgsFeqw=
> =6cxY
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
From nim at shadowfire.org  Wed Mar 28 06:21:29 2007
From: nim at shadowfire.org (nim@shadowfire.org)
Date: Wed Mar 28 06:21:32 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <debb3bc0703280612r7548a454lc37f67b5417624ff@mail.gmail.com>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
	<20070328130845.GA21510@localhost.localdomain>
	<debb3bc0703280612r7548a454lc37f67b5417624ff@mail.gmail.com>
Message-ID: <20070328132128.GC21510@localhost.localdomain>

The problem is, the ircd explicitly allows methods to bypass +R, yet ircservices doesnt, such as /inviting for instance.

Also, just my 2 cents worth.


Nim

On Wed, Mar 28, 2007 at 03:12:25PM +0200, Kieron Thwaites wrote:
> I have to say that I'm in agreement with Andrew here. If you mlock +R,
> you're implying that you want Services to enforce it.
> 
> Just my 2 cents worth.
> 
> --K
> 
> On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
> >
> >
> >>      If ChanServ "joins", you're not using IRC Services.
> >
> >
> >19:02 <nim> and
> >19:02 <nim> mlock +R
> >19:02 <mithrandi> done
> >19:02 <nim> just for curiosities sake
> >19:02 -!- ChanServ [services@shadowfire.org] has joined #testquux
> >19:02 -!- mode/#testquux [+b *!mithrandi@*.telkomadsl.co.za] by ChanServ
> >19:02 -!- mithtest was kicked from #testquux by ChanServ [You are not 
> >permitted to be on this channel.]
> >19:02 -!- mode/#testquux [+q mithrandi] by ChanServ
> >
> >
> ><08:06:17> -!- Irssi: Changed to shadowfire server 65.110.62.93
> ><08:08:30> [shadowfire] -!- [Services.ShadowFire.ORG] ircservices-5.0.60 
> >Services.ShadowFire.ORG build #1, compiled Sat Mar 24 15:02:53 EDT 2007
> >
> >
> >Nim
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.6 (GNU/Linux)
> >
> >iD8DBQFGCmjdhwuzJdpbgpkRApWWAKCigegERZrLgZXI9EteO1FiTm4QRACgjMqZ
> >AWlXwY+9Bn64FdmqqgsFeqw=
> >=6cxY
> >-----END PGP SIGNATURE-----
> >
> >------------------------------------------------------------------
> >To unsubscribe or change your subscription options, visit:
> >http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070328/cf4e9649/attachment.pgp
From ron2k.za at gmail.com  Wed Mar 28 06:28:50 2007
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Wed Mar 28 06:29:14 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <20070328132128.GC21510@localhost.localdomain>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
	<20070328130845.GA21510@localhost.localdomain>
	<debb3bc0703280612r7548a454lc37f67b5417624ff@mail.gmail.com>
	<20070328132128.GC21510@localhost.localdomain>
Message-ID: <debb3bc0703280628p2f9c5eaek57786329c2253b4e@mail.gmail.com>

You do have a valid point there, however my opinion is that it won't
be worth adding the extra complexity to deal with special cases (such
as invited users). There's a FAQ entry dealing with a similar issue,
although I'm uncertain whether or not Andrew would extend it to
something like this.

Incidentally, Services exhibits this behaviour in other cases as well.
If you /invite a user who's on the channel AKICK list, for example,
Services will still kick the user out, even if the user was able to
walk though bans set by Services because of said /invite.

--K

On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
> The problem is, the ircd explicitly allows methods to bypass +R, yet ircservices doesnt, such as /inviting for instance.
>
> Also, just my 2 cents worth.
>
>
> Nim
>
> On Wed, Mar 28, 2007 at 03:12:25PM +0200, Kieron Thwaites wrote:
> > I have to say that I'm in agreement with Andrew here. If you mlock +R,
> > you're implying that you want Services to enforce it.
> >
> > Just my 2 cents worth.
> >
> > --K
> >
> > On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
> > >
> > >
> > >>      If ChanServ "joins", you're not using IRC Services.
> > >
> > >
> > >19:02 <nim> and
> > >19:02 <nim> mlock +R
> > >19:02 <mithrandi> done
> > >19:02 <nim> just for curiosities sake
> > >19:02 -!- ChanServ [services@shadowfire.org] has joined #testquux
> > >19:02 -!- mode/#testquux [+b *!mithrandi@*.telkomadsl.co.za] by ChanServ
> > >19:02 -!- mithtest was kicked from #testquux by ChanServ [You are not
> > >permitted to be on this channel.]
> > >19:02 -!- mode/#testquux [+q mithrandi] by ChanServ
> > >
> > >
> > ><08:06:17> -!- Irssi: Changed to shadowfire server 65.110.62.93
> > ><08:08:30> [shadowfire] -!- [Services.ShadowFire.ORG] ircservices-5.0.60
> > >Services.ShadowFire.ORG build #1, compiled Sat Mar 24 15:02:53 EDT 2007
> > >
> > >
> > >Nim
> > >
> > >-----BEGIN PGP SIGNATURE-----
> > >Version: GnuPG v1.4.6 (GNU/Linux)
> > >
> > >iD8DBQFGCmjdhwuzJdpbgpkRApWWAKCigegERZrLgZXI9EteO1FiTm4QRACgjMqZ
> > >AWlXwY+9Bn64FdmqqgsFeqw=
> > >=6cxY
> > >-----END PGP SIGNATURE-----
> > >
> > >------------------------------------------------------------------
> > >To unsubscribe or change your subscription options, visit:
> > >http://lists.ircservices.za.net/mailman/listinfo/ircservices
> > >
> > ------------------------------------------------------------------
> > To unsubscribe or change your subscription options, visit:
> > http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGCmvYhwuzJdpbgpkRAg/gAJ9O/lhKFnvhIUjtduxXBtrz2cUlewCaA6Pd
> ZX79ddqtyYzh1lUh+YDpPXQ=
> =MXPH
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
From Craig at frostycoolslug.com  Wed Mar 28 17:08:17 2007
From: Craig at frostycoolslug.com (Craig McLure)
Date: Wed Mar 28 17:08:25 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <debb3bc0703280628p2f9c5eaek57786329c2253b4e@mail.gmail.com>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
	<20070328130845.GA21510@localhost.localdomain>
	<debb3bc0703280612r7548a454lc37f67b5417624ff@mail.gmail.com>
	<20070328132128.GC21510@localhost.localdomain>
	<debb3bc0703280628p2f9c5eaek57786329c2253b4e@mail.gmail.com>
Message-ID: <8a79f15a0703281708y24aa7508u43ca27b57562af92@mail.gmail.com>

I agree with you and Andy, there's also the issue of checking whether
the user has permission on services side to perform the specific
invite, for your +R case, it would need to be ensure that the user has
permission to change the MLOCK on the channel before the invite could
be allowed, with normal procedure for this being:

/cs set #channel mlock -R
/invite user #channel
*** USER JOINS ***
/cs set #channel mlock +R

which adds another level of complexity to what is being asked (Also
note this would be added for one, maybe two, IRCd(s)).

What it all comes down to, is I don't believe that the behaviour of an
IRCd should dictate the behaviour of Services.

It's just my 2c, and at the end of the day, it comes down to Andy to
make the final call ;)



On 28/03/07, Kieron Thwaites <ron2k.za@gmail.com> wrote:
> You do have a valid point there, however my opinion is that it won't
> be worth adding the extra complexity to deal with special cases (such
> as invited users). There's a FAQ entry dealing with a similar issue,
> although I'm uncertain whether or not Andrew would extend it to
> something like this.
>
> Incidentally, Services exhibits this behaviour in other cases as well.
> If you /invite a user who's on the channel AKICK list, for example,
> Services will still kick the user out, even if the user was able to
> walk though bans set by Services because of said /invite.
>
> --K
>
> On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
> > The problem is, the ircd explicitly allows methods to bypass +R, yet ircservices doesnt, such as /inviting for instance.
> >
> > Also, just my 2 cents worth.
> >
> >
> > Nim
> >
> > On Wed, Mar 28, 2007 at 03:12:25PM +0200, Kieron Thwaites wrote:
> > > I have to say that I'm in agreement with Andrew here. If you mlock +R,
> > > you're implying that you want Services to enforce it.
> > >
> > > Just my 2 cents worth.
> > >
> > > --K
> > >
> > > On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
> > > >
> > > >
> > > >>      If ChanServ "joins", you're not using IRC Services.
> > > >
> > > >
> > > >19:02 <nim> and
> > > >19:02 <nim> mlock +R
> > > >19:02 <mithrandi> done
> > > >19:02 <nim> just for curiosities sake
> > > >19:02 -!- ChanServ [services@shadowfire.org] has joined #testquux
> > > >19:02 -!- mode/#testquux [+b *!mithrandi@*.telkomadsl.co.za] by ChanServ
> > > >19:02 -!- mithtest was kicked from #testquux by ChanServ [You are not
> > > >permitted to be on this channel.]
> > > >19:02 -!- mode/#testquux [+q mithrandi] by ChanServ
> > > >
> > > >
> > > ><08:06:17> -!- Irssi: Changed to shadowfire server 65.110.62.93
> > > ><08:08:30> [shadowfire] -!- [Services.ShadowFire.ORG] ircservices-5.0.60
> > > >Services.ShadowFire.ORG build #1, compiled Sat Mar 24 15:02:53 EDT 2007
> > > >
> > > >
> > > >Nim
> > > >
> > > >-----BEGIN PGP SIGNATURE-----
> > > >Version: GnuPG v1.4.6 (GNU/Linux)
> > > >
> > > >iD8DBQFGCmjdhwuzJdpbgpkRApWWAKCigegERZrLgZXI9EteO1FiTm4QRACgjMqZ
> > > >AWlXwY+9Bn64FdmqqgsFeqw=
> > > >=6cxY
> > > >-----END PGP SIGNATURE-----
> > > >
> > > >------------------------------------------------------------------
> > > >To unsubscribe or change your subscription options, visit:
> > > >http://lists.ircservices.za.net/mailman/listinfo/ircservices
> > > >
> > > ------------------------------------------------------------------
> > > To unsubscribe or change your subscription options, visit:
> > > http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFGCmvYhwuzJdpbgpkRAg/gAJ9O/lhKFnvhIUjtduxXBtrz2cUlewCaA6Pd
> > ZX79ddqtyYzh1lUh+YDpPXQ=
> > =MXPH
> > -----END PGP SIGNATURE-----
> >
> > ------------------------------------------------------------------
> > To unsubscribe or change your subscription options, visit:
> > http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>


-- 
/**********************************************
 *        Craig "FrostyCoolSlug" McLure
 * ChatSpike    - http://www.chatspike.net
 * InspIRCd     - http://www.inspircd.org
 **********************************************/
From nim at shadowfire.org  Wed Mar 28 18:54:01 2007
From: nim at shadowfire.org (nim@shadowfire.org)
Date: Wed Mar 28 18:54:11 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <8a79f15a0703281708y24aa7508u43ca27b57562af92@mail.gmail.com>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
	<20070328130845.GA21510@localhost.localdomain>
	<debb3bc0703280612r7548a454lc37f67b5417624ff@mail.gmail.com>
	<20070328132128.GC21510@localhost.localdomain>
	<debb3bc0703280628p2f9c5eaek57786329c2253b4e@mail.gmail.com>
	<8a79f15a0703281708y24aa7508u43ca27b57562af92@mail.gmail.com>
Message-ID: <20070329015401.GA24057@localhost.localdomain>

Honestly, i was thing more along the lines of a setting on if the founder wanted services to enforce this behavior on mlock +R or not, which 
should be more simple to accomplish.  Andrew already said he doesnt agree with me on the neccessity of this functionality, so i will just leave
it at that.

Nim

On Thu, Mar 29, 2007 at 01:08:17AM +0100, Craig McLure wrote:
> I agree with you and Andy, there's also the issue of checking whether
> the user has permission on services side to perform the specific
> invite, for your +R case, it would need to be ensure that the user has
> permission to change the MLOCK on the channel before the invite could
> be allowed, with normal procedure for this being:
> 
> /cs set #channel mlock -R
> /invite user #channel
> *** USER JOINS ***
> /cs set #channel mlock +R
> 
> which adds another level of complexity to what is being asked (Also
> note this would be added for one, maybe two, IRCd(s)).
> 
> What it all comes down to, is I don't believe that the behaviour of an
> IRCd should dictate the behaviour of Services.
> 
> It's just my 2c, and at the end of the day, it comes down to Andy to
> make the final call ;)
> 
> 
> 
> On 28/03/07, Kieron Thwaites <ron2k.za@gmail.com> wrote:
> >You do have a valid point there, however my opinion is that it won't
> >be worth adding the extra complexity to deal with special cases (such
> >as invited users). There's a FAQ entry dealing with a similar issue,
> >although I'm uncertain whether or not Andrew would extend it to
> >something like this.
> >
> >Incidentally, Services exhibits this behaviour in other cases as well.
> >If you /invite a user who's on the channel AKICK list, for example,
> >Services will still kick the user out, even if the user was able to
> >walk though bans set by Services because of said /invite.
> >
> >--K
> >
> >On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
> >> The problem is, the ircd explicitly allows methods to bypass +R, yet 
> >ircservices doesnt, such as /inviting for instance.
> >>
> >> Also, just my 2 cents worth.
> >>
> >>
> >> Nim
> >>
> >> On Wed, Mar 28, 2007 at 03:12:25PM +0200, Kieron Thwaites wrote:
> >> > I have to say that I'm in agreement with Andrew here. If you mlock +R,
> >> > you're implying that you want Services to enforce it.
> >> >
> >> > Just my 2 cents worth.
> >> >
> >> > --K
> >> >
> >> > On 28/03/07, nim@shadowfire.org <nim@shadowfire.org> wrote:
> >> > >
> >> > >
> >> > >>      If ChanServ "joins", you're not using IRC Services.
> >> > >
> >> > >
> >> > >19:02 <nim> and
> >> > >19:02 <nim> mlock +R
> >> > >19:02 <mithrandi> done
> >> > >19:02 <nim> just for curiosities sake
> >> > >19:02 -!- ChanServ [services@shadowfire.org] has joined #testquux
> >> > >19:02 -!- mode/#testquux [+b *!mithrandi@*.telkomadsl.co.za] by 
> >ChanServ
> >> > >19:02 -!- mithtest was kicked from #testquux by ChanServ [You are not
> >> > >permitted to be on this channel.]
> >> > >19:02 -!- mode/#testquux [+q mithrandi] by ChanServ
> >> > >
> >> > >
> >> > ><08:06:17> -!- Irssi: Changed to shadowfire server 65.110.62.93
> >> > ><08:08:30> [shadowfire] -!- [Services.ShadowFire.ORG] 
> >ircservices-5.0.60
> >> > >Services.ShadowFire.ORG build #1, compiled Sat Mar 24 15:02:53 EDT 
> >2007
> >> > >
> >> > >
> >> > >Nim
> >> > >
> >> > >-----BEGIN PGP SIGNATURE-----
> >> > >Version: GnuPG v1.4.6 (GNU/Linux)
> >> > >
> >> > >iD8DBQFGCmjdhwuzJdpbgpkRApWWAKCigegERZrLgZXI9EteO1FiTm4QRACgjMqZ
> >> > >AWlXwY+9Bn64FdmqqgsFeqw=
> >> > >=6cxY
> >> > >-----END PGP SIGNATURE-----
> >> > >
> >> > >------------------------------------------------------------------
> >> > >To unsubscribe or change your subscription options, visit:
> >> > >http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >> > >
> >> > ------------------------------------------------------------------
> >> > To unsubscribe or change your subscription options, visit:
> >> > http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.6 (GNU/Linux)
> >>
> >> iD8DBQFGCmvYhwuzJdpbgpkRAg/gAJ9O/lhKFnvhIUjtduxXBtrz2cUlewCaA6Pd
> >> ZX79ddqtyYzh1lUh+YDpPXQ=
> >> =MXPH
> >> -----END PGP SIGNATURE-----
> >>
> >> ------------------------------------------------------------------
> >> To unsubscribe or change your subscription options, visit:
> >> http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >>
> >------------------------------------------------------------------
> >To unsubscribe or change your subscription options, visit:
> >http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >
> 
> 
> -- 
> /**********************************************
> *        Craig "FrostyCoolSlug" McLure
> * ChatSpike    - http://www.chatspike.net
> * InspIRCd     - http://www.inspircd.org
> **********************************************/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.ircservices.za.net/pipermail/ircservices/attachments/20070328/3f77f95d/attachment-0001.pgp
From xxx.coder at gmail.com  Thu Mar 29 06:59:48 2007
From: xxx.coder at gmail.com (ongeboren)
Date: Thu Mar 29 06:59:52 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <460a0526.15370@msgid.achurch.org>
References: <20070328035737.GB19013@localhost.localdomain>
	<460a0526.15370@msgid.achurch.org>
Message-ID: <ce6d53600703290659x484fb79of7a1992b1c02302b@mail.gmail.com>

Imho, "modes lock" and "modes enforcement" are 2 different things. If
they are separated, channel owners could decide not to enforce the
modes, allowing for instance cmode +b be used to silence a user (as
some irc servers don't allow messages from banned users) but still
keep the banned user in the channel. Analogously, the same goes for
cmode +r (identified to services only). Further, if configured by the
services admin, services could act even more aggressively by kicking
all users matching a ban not placed via the ban list in services but
via /mode #chan +b mask, provided the channel has "modes enforcement
on". The last extra isn't probably desirable for big production
networks.

Feel free to disagree with me, but propose something better instead,
as my idea should be trivial to implement and is an acceptable
compromise.

On 3/28/07, Andrew Church <achurch@achurch.org> wrote:
> >The problem was, when services split, some users get unidentified, and chan=
> >serv joins and does a kick banning spree, and yes, I am using the lastest=
> >=20
> >version of services.
>
>      If ChanServ "joins", you're not using IRC Services.  In any case,
> Services keeps track of users' identification status across netsplits and
> restarts (unless you have NoSplitRecovery set in your ircservices.conf),
> so the only users that would be affected by this are those that first
> connected to the network while Services was split.  If this bothers you,
> then again, the answer is not to use MLOCK +R (you can, of course, still
> use +R normally).
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>


-- 
Evlogi Petrov - ongeboren@UniBG
From achurch at achurch.org  Thu Mar 29 23:53:06 2007
From: achurch at achurch.org (Andrew Church)
Date: Thu Mar 29 08:09:11 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <ce6d53600703290659x484fb79of7a1992b1c02302b@mail.gmail.com>
Message-ID: <460bd695.30350@msgid.achurch.org>

>Imho, "modes lock" and "modes enforcement" are 2 different things. If
>they are separated, channel owners could decide not to enforce the
>modes, allowing for instance cmode +b be used to silence a user (as
>some irc servers don't allow messages from banned users) but still
>keep the banned user in the channel. Analogously, the same goes for
>cmode +r (identified to services only). Further, if configured by the
>services admin, services could act even more aggressively by kicking
>all users matching a ban not placed via the ban list in services but
>via /mode #chan +b mask, provided the channel has "modes enforcement
>on". The last extra isn't probably desirable for big production
>networks.
>
>Feel free to disagree with me, but propose something better instead,
>as my idea should be trivial to implement and is an acceptable
>compromise.

     Okay, here's my proposal.  The ChanServ "mode lock" functionality
will enforce locked modes at all times, performing the following actions:

   - When a client attempts to change the state of a locked mode (off to
     on, on to off, or changing parameters of an active mode), ChanServ
     will reverse the change.

   - When a client joins an empty channel with one or modes locked on,
     those modes will be automatically set on the channel.

   - If a client attempts to join a channel to which the mode lock denies
     them access, ChanServ will kickban the client from the channel.

If this enforcement is not desired, the mode lock functionality should not
be used.

     Conveniently, this is how Services already works. (:

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

P.S. If you disagree with my decision, you are of course free to write
(and distribute, if you so choose) a patch.  That's what open source is
about, after all.  You would, however, be well advised to consider the
varied effects of netsplits and netjoins, particularly with respect to
colliding channels and clients in them at netjoin time.
From aragon at phat.za.net  Thu Mar 29 08:26:13 2007
From: aragon at phat.za.net (Aragon Gouveia)
Date: Thu Mar 29 08:26:25 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <460bd695.30350@msgid.achurch.org>
References: <ce6d53600703290659x484fb79of7a1992b1c02302b@mail.gmail.com>
	<460bd695.30350@msgid.achurch.org>
Message-ID: <20070329152613.GA56024@phat.za.net>

| By Andrew Church <achurch@achurch.org>
|                                          [ 2007-03-29 17:09 +0200 ]
> P.S. If you disagree with my decision, you are of course free to write
> (and distribute, if you so choose) a patch.  That's what open source is
> about, after all.  You would, however, be well advised to consider the
> varied effects of netsplits and netjoins, particularly with respect to
> colliding channels and clients in them at netjoin time.

Indeed, and this is a very simple patch from my brief look at it.  See lines
330-337 of modules/chanserv/check.c.  Commenting that block should stop the
behaviour in the case of +R enforcement.

However, FWIW, I do think it'd be useful to permit channel owners to decide
what level of enforcement they want chanserv to perform in their channel. 
Maybe something for 5.1 or future versions?


Regards,
Aragon
From achurch at achurch.org  Fri Mar 30 00:34:20 2007
From: achurch at achurch.org (Andrew Church)
Date: Thu Mar 29 08:38:23 2007
Subject: [IRCServices] IrcServices enforcing +R
In-Reply-To: <20070329152613.GA56024@phat.za.net>
Message-ID: <460bdd6c.30756@msgid.achurch.org>

>However, FWIW, I do think it'd be useful to permit channel owners to decide
>what level of enforcement they want chanserv to perform in their channel. 
>Maybe something for 5.1 or future versions?

     I may consider a configuration file option to allow +R checks to be
disabled for non-empty channels, since networks with frequent splits may
prefer to take that security risk.  For individual channels, though, the
choice is either to lock +R on or not to lock it; I won't add an extra
option for "enforcement level".

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From bu7cher at yandex.ru  Thu Mar 29 20:58:20 2007
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Thu Mar 29 20:58:33 2007
Subject: [IRCServices] services panic
In-Reply-To: <46038fb0.41737@msgid.achurch.org>
References: <46038fb0.41737@msgid.achurch.org>
Message-ID: <460C8ADC.5010001@yandex.ru>

Andrew Church ?????:
>      A "bus error" usually indicates a hardware failure or other system
> error unrelated to Services.  I'm unable to reproduce this error; try
> moving Services to a different computer and see if the problem persists.

I've recompile my services with CFLAGS=-g and -dumpcore. Now i have 
several cores. You can look to backtraces on the url:
http://butcher.heavennet.ru/services/

-- 
WBR, Andrey V. Elsukov
From achurch at achurch.org  Fri Mar 30 13:07:19 2007
From: achurch at achurch.org (Andrew Church)
Date: Thu Mar 29 21:09:39 2007
Subject: [IRCServices] services panic
In-Reply-To: <460C8ADC.5010001@yandex.ru>
Message-ID: <460c8d7d.34274@msgid.achurch.org>

>I've recompile my services with CFLAGS=-g and -dumpcore. Now i have 
>several cores. You can look to backtraces on the url:
>http://butcher.heavennet.ru/services/

     Thanks for the help--it looks like this is caused by erroneous code
that just happens to work properly on 32-bit x86 systems (my own
environment).  Try applying the following patch and let me know if it
solves the problem.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

-----------------------------------------------------------------------

Index: misc.c
===================================================================
RCS file: /var/local/cvsroot/ircservices/misc.c,v
retrieving revision 2.37.2.4
diff -u -r2.37.2.4 misc.c
--- misc.c	23 Mar 2007 18:10:42 -0000	2.37.2.4
+++ misc.c	30 Mar 2007 04:07:10 -0000
@@ -616,11 +616,15 @@
     /* Now call the callback routine for each index. */
     numcount = 0;
     for (i = min; i <= max; i++) {
+	va_list args_copy;
 	int res;
+
 	if (!(numflag[i>>3] & (1 << (i&7))))
 	    continue;
 	numcount++;
-	res = callback(u, i, args);
+	va_copy(args_copy, args);
+	res = callback(u, i, args_copy);
+	va_end(args_copy);
 	if (debug)
 	    log("debug: process_numlist: tried to do %d; result = %d", i, res);
 	if (res < 0)
From bu7cher at yandex.ru  Thu Mar 29 22:42:30 2007
From: bu7cher at yandex.ru (Andrey V. Elsukov)
Date: Thu Mar 29 22:42:37 2007
Subject: [IRCServices] services panic
In-Reply-To: <460c8d7d.34274@msgid.achurch.org>
References: <460c8d7d.34274@msgid.achurch.org>
Message-ID: <460CA346.90000@yandex.ru>

Andrew Church wrote:
>      Thanks for the help--it looks like this is caused by erroneous code
> that just happens to work properly on 32-bit x86 systems (my own
> environment).  Try applying the following patch and let me know if it
> solves the problem.

Thanks! Seems that this patch resolves problems.

-- 
WBR, Andrey V. Elsukov
From achurch at achurch.org  Fri Mar 30 15:21:18 2007
From: achurch at achurch.org (Andrew Church)
Date: Thu Mar 29 23:23:46 2007
Subject: [IRCServices] Services 5.0.61 released
Message-ID: <460caced.52141@msgid.achurch.org>

     Services 5.0.61 has been released, and can be downloaded from:

http://www.ircservices.za.net/download/   (Japan)
ftp://ftp.esper.net/ircservices/          (Western USA)

51559570701f884f459036e88104ea15  ircservices-5.0.61.tar.gz
c192883fe561dd8248e939434ca32ef4  ircservices-5.0.61.diff.gz
b508c38b2dfad8cbb1210844e8acbe2a  ircservices-5.0.61-1.i386.rpm
59bb6d4cff08dbf6469dfbac661e62ca  ircservices_5.0.61-1_i386.deb

The mirrors should have it shortly.

     This release fixes the bug just mentioned on the mailing list which
can allow users to crash Services on certain platforms.  The bug does not
affect the x86-32 platform (Intel or AMD CPUs running in 32-bit mode) when
compiled with GCC, but those using other platforms (including x86-64) or
compilers should upgrade immediately.

     Apologies for the inconvenience.

Changes in version 5.0.61
-------------------------
2007/03/30	Fixed crash on x86-64 systems under certain circumstances.
		    Reported by Andrey V. Elsukov <bu7cher@yandex.ru>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From toxic at freemail.gr  Sat Mar 31 01:55:58 2007
From: toxic at freemail.gr (Dionisios K.)
Date: Sat Mar 31 01:56:25 2007
Subject: [IRCServices] NSRegEmailMax Is not reloaded on rehash?
Message-ID: <460E221E.8080606@freemail.gr>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
I think that NSRegEmailMax option on modules.conf is not reloaded on
rehash and it needs a restart.
Is this normal or a bug?

- --
Dionisios K.
Network Administrator On NeMeSiS.mIRC.gr
ToXiC@FreeMail.gr

PGP Key:        http://toxic.my-place.us/pubkey.asc
PGP FP:       0950 5363 DD1C D5A7 45C6 2991 F760 982E DD47 9149
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFGDiIe92CYLt1HkUkRAjaHAJ0duHDPQk/nxDtpbAypt0cZw442AACgldR6
FkK3eNIM0h9DSUqcdi1gnRs=
=9TbA
-----END PGP SIGNATURE-----

From achurch at achurch.org  Sat Mar 31 20:06:00 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat Mar 31 04:06:42 2007
Subject: [IRCServices] NSRegEmailMax Is not reloaded on rehash?
In-Reply-To: <460E221E.8080606@freemail.gr>
Message-ID: <460e40be.55760@msgid.achurch.org>

>I think that NSRegEmailMax option on modules.conf is not reloaded on
>rehash and it needs a restart.
>Is this normal or a bug?

     I can't reproduce this using either 5.0.61 or 5.1a13.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Sun Apr  1 09:01:33 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sun Apr  1 09:01:37 2007
Subject: [IRCServices] Dynamic modules support in 5.0.x
Message-ID: <b19eae4e0704010901w11580df0sc2f251e5d08374ad@mail.gmail.com>

Hi,

It appears configure doesn't correctly detect dlopen support on some
systems (x86_64/amd64 3200+ Gentoo w/gcc 4.1.1 at least) - because it
does not compile test-dlopen.c with -fPIC.

Passing -cflags -fPIC to ./configure  fixes the problem.

Is it possible to get configure patched to avoid this workaround?

Thanks.
w00t
From ron2k.za at gmail.com  Sun Apr  1 11:01:14 2007
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Sun Apr  1 11:01:18 2007
Subject: [IRCServices] Compiler warning with Gentoo and gcc 4.1.1
Message-ID: <debb3bc0704011101sa86c365n36fb59bbf304ab20@mail.gmail.com>

Hi,

I'm getting the following compiler warning when compiling Services
(5.0.60 and 5.0.61) on an x86-32 machine (Celeron 1.7GHz) using Gentoo
2006.1 and gcc 4.1.1:

/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld:
warning: creating a DT_TEXTREL in object.

Services does compile successfully, however, and it seems to run just fine.

Any advice on how to proceed with this, or is this something that I
shouldn't worry too much about?

--K
From omster at gmail.com  Sun Apr  1 15:43:35 2007
From: omster at gmail.com (Om)
Date: Sun Apr  1 15:43:53 2007
Subject: [IRCServices] Dynamic modules support in 5.0.x
In-Reply-To: <b19eae4e0704010901w11580df0sc2f251e5d08374ad@mail.gmail.com>
References: <b19eae4e0704010901w11580df0sc2f251e5d08374ad@mail.gmail.com>
Message-ID: <46103597.8090604@gmail.com>

Robin Burchell wrote:
> Hi,
> 
> It appears configure doesn't correctly detect dlopen support on some
> systems (x86_64/amd64 3200+ Gentoo w/gcc 4.1.1 at least) - because it
> does not compile test-dlopen.c with -fPIC.
> 
> Passing -cflags -fPIC to ./configure  fixes the problem.
> 
> Is it possible to get configure patched to avoid this workaround?
> 
> Thanks.
> w00t

The x86_64 system in question was mine -- so if Andy or anyone else has 
patches and such to try then direct them my way.

Cheers,
-ol
From achurch at achurch.org  Mon Apr  2 09:10:14 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun Apr  1 17:10:44 2007
Subject: [IRCServices] Dynamic modules support in 5.0.x
In-Reply-To: <b19eae4e0704010901w11580df0sc2f251e5d08374ad@mail.gmail.com>
Message-ID: <46104a02.47547@msgid.achurch.org>

>It appears configure doesn't correctly detect dlopen support on some
>systems (x86_64/amd64 3200+ Gentoo w/gcc 4.1.1 at least) - because it
>does not compile test-dlopen.c with -fPIC.
>
>Passing -cflags -fPIC to ./configure  fixes the problem.
>
>Is it possible to get configure patched to avoid this workaround?

     I'll look into this for 5.1.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Mon Apr  2 09:10:51 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun Apr  1 17:12:41 2007
Subject: [IRCServices] Compiler warning with Gentoo and gcc 4.1.1
In-Reply-To: <debb3bc0704011101sa86c365n36fb59bbf304ab20@mail.gmail.com>
Message-ID: <46104a76.47555@msgid.achurch.org>

>I'm getting the following compiler warning when compiling Services
>(5.0.60 and 5.0.61) on an x86-32 machine (Celeron 1.7GHz) using Gentoo
>2006.1 and gcc 4.1.1:
>
>/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld:
>warning: creating a DT_TEXTREL in object.
>
>Services does compile successfully, however, and it seems to run just fine.
>
>Any advice on how to proceed with this, or is this something that I
>shouldn't worry too much about?

     If it works, don't worry about it. (:  Some systems don't deal well
with text relocations (this is related to the -fPIC issue just mentioned),
so that's probably why ld is complaining, but if Services works fine on
your system, it's not relevant to you.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From toxic at freemail.gr  Tue Apr  3 14:57:26 2007
From: toxic at freemail.gr (Dionisios K.)
Date: Tue Apr  3 14:57:33 2007
Subject: [IRCServices] Feature For 5.1
Message-ID: <4612CDC6.6020702@freemail.gr>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
I want to suggest a feature for 5.1 Something for ircds with +h
(halfops).
To modify the secureops command so it may allow halfops but not ops OR
dont allow anyone.
Something like:
/cs set #channel secureops ops / all / off
If "ops" option is enabled chanserv will allow halfops.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFGEs3G92CYLt1HkUkRAkcTAJ9s4/h5tZWHxTe/7tYLDLoKw1YgPQCfWrDL
OZMLT2B3YxaKPAd9KCg1EnM=
=Petr
-----END PGP SIGNATURE-----

From toxic at freemail.gr  Tue May  1 22:06:59 2007
From: toxic at freemail.gr (Dionisios K.)
Date: Tue May  1 22:06:20 2007
Subject: [IRCServices] Feature request
Message-ID: <46381C73.7010104@freemail.gr>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is possible to add an option on the config file for a delay (optional)
before nickserv autojoin after identify?

Thank you.

- --
Dionisios K.
Network Administrator On NeMeSiS.mIRC.gr
ToXiC@FreeMail.gr

PGP Key:        http://toxic.my-place.us/pubkey.asc
PGP FP:       0950 5363 DD1C D5A7 45C6 2991 F760 982E DD47 9149
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOBxz92CYLt1HkUkRAgmdAKCdb9tnGSUyppIzWvCAPZ/szhidNACfUYbv
TD8zwjXwF8WdugX5UMMg6Fk=
=ljs8
-----END PGP SIGNATURE-----
From achurch at achurch.org  Sun May  6 14:43:25 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat May  5 22:44:28 2007
Subject: [IRCServices] Feature For 5.1
In-Reply-To: <4612CDC6.6020702@freemail.gr>
Message-ID: <463d6b37.42304@msgid.achurch.org>

>I want to suggest a feature for 5.1 Something for ircds with +h
>(halfops).
>To modify the secureops command so it may allow halfops but not ops OR
>dont allow anyone.
>Something like:
>/cs set #channel secureops ops / all / off
>If "ops" option is enabled chanserv will allow halfops.

I don't really see the utility of this, but if there's enough interest in
it I'll consider it.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Sun May  6 14:44:27 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat May  5 22:46:37 2007
Subject: [IRCServices] Feature request
In-Reply-To: <46381C73.7010104@freemail.gr>
Message-ID: <463d6bba.42313@msgid.achurch.org>

>Is possible to add an option on the config file for a delay (optional)
>before nickserv autojoin after identify?

I'd rather not, since it could confuse users when they're suddenly joined
to a channel without having done anything immediately prior.  (Even a
10-second delay, for example, can be disorienting if the user's mind has
gone onto other things.)  Why would you want such an option?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Sun May  6 17:18:19 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun May  6 01:18:24 2007
Subject: [IRCServices] Services 5.1pre0 released
Message-ID: <463d8f4b.23151@msgid.achurch.org>

     After close to three years of work, Services 5.1 has finally reached
beta status, and Services 5.1pre0 has now been released.  It can be
downloaded from the usual sites:

http://www.ircservices.za.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/          (Western USA)

75e0b3c432239bd392fc3834cadc28b0  ircservices-5.1pre0.tar.gz
8e32697bee2282ce98dd14df6bbe2150  ircservices-5.1pre0-1.i386.rpm
2ba786a9bf6e175887a926d219286844  ircservices_5.1pre0-1_i386.deb

The mirrors should have it shortly.

     While not a stable release, I am announcing this version here (and
will announce future beta versions on this list as well) for two reasons.
One is that, while I am hesitant to label it "stable" before it has seen
widespread testing, the code itself is pretty solid, and should be usable
in production environments.  I will, of course, respond to bugs as quickly
as I can, but I'd like to recommend that those of you currently using 5.0
upgrade to 5.1 at your convenience, even before the stable release.  I will
also continue to support version 5.0 until 5.1 reaches stable status.

     The second, and more important, reason for posting the announcement
to this list is that I intend version 5.1 to be the last version of IRC
Services, at least under my care.  While I don't consider Services
"complete"--software development is a neverending task, and in any case
users' needs change over time--I do believe that it's time for me to move
on to other things.  In fact, I already devote a fair amount of my time
outside of work to other software development projects (such as the
audio/video tool "transcode", for those who are familiar with it), and I
have other hobbies which I haven't been able to pursue as much as I'd
like.  I've also found that I personally use IRC very infrequently these
days, and that has inevitably lessened my interest in continuing Services
development as well.

     I certainly don't believe that IRC itself is a dead or obsolete
protocol, and I've spent the better part of the past year writing a
detailed technical manual for Services, found in the "docs/tech" directory
of the distribution, so that other developers can pick up as easily as
possible where I'm leaving off.  Even after the release of 5.1.0, I will
continue to monitor the mailing lists and maintain Services 5.1 to the
extent of fixing bugs and making other reasonably small changes.  In terms
of major improvements and additions, however, 5.1.0 will be the "final
form" of Services for IRC Networks.

     For this reason, I'd like to encourage discussion of beta versions of
5.1 on this list, rather than on the coding list as has been done in the
past.  I'll continue to accept new feature suggestions until the release of
5.1.0, so if there is something you'd like to see added, feel free to bring
it up on this list.  (However, I will as always exercise my discretion in
choosing whether a suggested feature should be added, as described in FAQ
Z.5; I'm not going to bloat the program just because it's the last version.
The module system is available as always for third parties to add anything
I decide to leave out, and it has been improved for 5.1--in particular,
modules can now save data to persistent storage without any modification of
the core Services code.)

     In addition to feature suggestions, I'd also like to hear about
anything in the Services user interface that seems awkward or unintuitive,
whether new for 5.1 or present since previous versions.  After over ten
years of development, I know Services inside and out, so things that seem
obvious to me may not be so to newcomers.  If there are any questions you
frequently get from new users, that probably means something needs to be
changed, so let me know.

     Technical issues should be directed to the coding list, as always.  In
particular, if there are any issues with packaging Services for use with an
operating system distribution, I'd like to hear about them so that they can
be corrected.  (I personally use a home-built Linux system, and as such I
haven't kept close track of changes in how various OSes and distributions
arrange their filesystems.)

     I realize that this "end-of-life" announcement for Services may come
as a surprise to some, and for that I apologize.  As I mentioned earlier, I
will continue to support Services for some time to come (my current thought
is for two to three years after the release of 5.1.0); however, I did want
to provide advance warning of my future intentions.  Thank you all for your
support over the years.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/

-------------------------
What's New in version 5.1
-------------------------
Database handling, the one aspect of Services which has remained
essentially unchanged since version 1.0, has finally undergone a fairly
significant redesign.  Rather than using specialized data load and save
routines tailored for the core Services pseudoclients, Services now
implements a generic database table system, which has the dual benefits of
separating the data storage system from the rest of Services (allowing
alternative storage methods to be implemented easily) and allowing third-
party modules and extensions to create their own non-volatile databases
without resorting to custom load/save routines.  The default database file
format has also been changed to be more flexible and error-resilient than
the old format (which admittedly isn't saying much); see the "upgrading"
section of the manual for instructions on switching your databases to the
new format.

The often-criticized channel memo system has also been redesigned for this
version.  Instead of storing channel memos with the channel, memos are now
sent to the founder and all users on the channel with a particular access
level (by default level 100, or SOP level).  These memos are distinguished
from ordinary memos by text that says "(for #channel)" when reading the
memo.  As a result of this change, users will be notified about new channel
memos in the same way as ordinary user-to-user memos.

NOTICE: When loading databases from version 5.0 or earlier, all channel
        memos will be deleted.

Encryption support has also been improved.  Encryption is no longer an
all-or-nothing affair; the encryption method is stored with each password,
so that enabling or disabling encryption will have no effect on passwords
that were previously set.  The "encryption/unix-crypt" module has been
added, allowing the use of the Unix crypt() function to encrypt passwords.

The NickServ and ChanServ SENDPASS commands added in version 5.0 have been
removed in favor of the new NickServ REAUTH command.  This command
generates an authentication code which the user can use once to identify to
their nickname in place of the password, and then change the password as
needed.  Channel passwords can always be changed by the founder after
nickname identification, rendering ChanServ SENDPASS unnecessary.

Long LIST/VIEW responses are now handled more cleanly.  Except for NickServ
ACCESS LIST (since nickname access lists are generally short) and MemoServ
LIST (since memos are numbered), every list now includes an "end of list"
message indicating both the number of entries displayed and the total
number of entries in the list; the configuration directive ListMax,
replacing NSListMax and CSListMax, sets the maximum number of entries
displayed for any of these commands.  It is also possible to skip a certain
number of entries by adding a "+NNN" after the command, allowing all of the
entries in a long list to be viewed bit by bit.

At the development level, handling of module compilation has been improved,
allowing third-party modules to be simply "dropped in" without requiring
changes to Makefiles or other Services distribution files.  An extension
interface has been added to Services' multilingual support as well,
allowing modules to add their own language strings and load their own
language files.

Other changes:
  + Command aliases can now be added for NickServ, ChanServ, and MemoServ
        commands via the NSAlias, CSAlias, and MSAlias directives.
  + Notices are now sent to the user when sending of a mail authentication
        code message fails.  (However, errors after the message has been
        handed off to the mail server cannot be detected.)
  + A new configuration directive, RejectEmail, now allows selected E-mail
        addresses to be rejected by NickServ and ChanServ commands.
  + NickServ INFO will now indicate when a nickname's user is using a
        different linked nickname if the nickname group's PRIVATE option
        is not set.
  + NickServ now has a RESTOREMAIL command (in the nickserv/mail-auth
        module), which allows a user to restore their nickname's last
        authenticated E-mail address if, for example, SET EMAIL is used
        with an incorrect address.
  + NickServ SET/UNSET by Services administrators for others' nicknames is
        now done by putting a "!" before the nick to avoid ambiguity; for
        example, "SET !nick NOEXPIRE ON" instead of "SET nick NOEXPIRE ON".
  + ChanServ REGISTER and SET PASSWORD now check for and disallow easily
        guessable passwords.
  + ChanServ ACCESS now includes a LISTLEVEL subcommand to list access
        entries with a given level or within a given level range.
  + ChanServ AKICK and MemoServ IGNORE now support matching by IP address
        (on servers which support client IP address information).
  + ChanServ OP, VOICE, and similar commands can now be used with multiple
        nicknames.
  + MemoServ now has a RENUMBER command to remove "holes" in the memo
        number sequence.
  + MemoServ FORWARD now sends all selected memos in a single E-mail
        message, rather than sending each memo in a separate message.
  + OperServ AKILL and related commands now have a CHECK subcommand which
        can be used to find all masks that match a given user/hostname.
  + SQlines are no longer applied to IRC operators during Services startup
        or netjoins if the IRC protocol in use supports sending user modes
        with the NICK message.  This includes the bahamut, hybrid,
        inspircd, monkey, ptlink, ratbox, solid-ircd, trircd, and unreal
        protocol modules.
  + The ignore system has been redesigned, and now keeps better track of
        how much load each user is putting on Services.  The ignorance
        threshold can be fine-tuned via the configuration file.
  + A new "unsorted list" mode has been added to improve Services'
        performance on large networks.  By giving the -no-sorted-list
        option to the configure script, Services will not try to keep
        nicknames and channels in alphabetical order; this means that
        commands such as NickServ LIST will no longer return nicknames in
        order, but Services will run significantly faster.
  + Support has been added for the InspIRCd, ircd-ratbox, and solid-ircd
        IRC servers.
  + Unreal's NICKCHARS protocol option, allowing non-ASCII characters in
        nicknames, is now supported.
  * ChanServ DROP now behaves like NickServ DROP: dropping a channel now
        requires the channel password to be entered with the DROP command,
        and DROPCHAN has been added as a separate command for Services
        administrators to drop arbitrary channels.
  * The ChanServ ACCESS, XOP, and AKICK commands no longer use entry
        numbers; the DEL and LIST subcommands now work with nicknames
        (hostmasks for the AKICK command) only.
  * The binary distributions (RPM and Debian packages) now install into
        /opt/ircservices and /var/opt/ircservices, rather than /usr/sbin
        and /usr/lib/ircservices.
  * Tab characters are no longer used (or allowed) in the source code.
  - The deprecated nickserv/oldlink module, which provided support for the
        format of the LINK command used in version 4 of Services, has been
        removed.
  - Support for "modeless channels", with names of the form "+name", has
        been removed.  (Support for registering such channels was removed
        in version 5.0.0; this version removes the special handling for
        such channels in other parts of the program.)
  - Support for the "channel owner" mode present in the PTlink (+a),
        trircd (+u), and Unreal (+q) IRC servers has been removed, as there
        are too many differing opinions on its proper use.
  - Language support for Italian and Portuguese has been removed, due to
        the lack of volunteers to maintain them.
  - Support for old versions of GCC (anything before GCC 3.2) has been
        removed.
Configuration file changes:
  + IncludeFile has been added to allow configuration directives to be
        split up into multiple files, and may be used in both
        ircservices.conf and modules.conf.
  + LoadLanguageText (ircservices.conf) has been added to allow replacement
        of Services text strings at runtime.
  + RejectEmail (ircservices.conf) has been added to allow rejection of
        selected E-mail addresses.
  + NSAlias (module nickserv/main), CSAlias (module chanserv/main), and
        MSAlias (module memoserv/main) have been added to allow creation of
        command aliases.
  + NSSetEmailDelay (module nickserv/main) has been added to enforce a
        delay between consecutive uses of the SET EMAIL command, thereby
        reducing the potential for sending mailbombs.
  + CSDefModeLock (module chanserv/main) has been added to allow the
        default mode lock for newly registered channels to be changed.
  + CSSkipModeRCheck (module chanserv/main) has been added to allow the
        check of a nickname's registration status at channel join time
        (used to kick unregistered nicknames from channels locked +R) to
        be skipped.
  + MSExpireDelay (module memoserv/main) has been added to allow memo
        expiration to be delayed until a certain time after the memo is
        first read.
  + MaxMessages (module mail/main) has been added to allow a limit to be
        placed on the total number of messages in transit.
  * ListMax (ircservices.conf) has been added in place of NSListMax and
        CSListMask to set a limit on the number of entries displayed for
        all LIST-like commands.
  * WallAdminPrivs (ircservices.conf) has been added in place of
        WallGetpass and WallSetpass to cause a WALLOPS/GLOBOPS to be sent
        on all NickServ and ChanServ commands that use Services
        administrator privileges.
  * The database name configuration directives (NickServDB, ChanServDB,
        etc.) have been moved from the various pseudoclient module sections
        to the database/version4 module section, and now explicitly specify
        filenames.
  - The nickserv/sendpass and chanserv/sendpass modules (and therefore
        their respective configuration sections) have been removed.
  - CSAutokickReason (module chanserv/main) has been removed, as the
        built-in reason prefix "AKICK by <nick>" makes it unnecessary.
  - MSExpireUnread (module memoserv/main) has been removed, since it
        results in silent data loss.
  - MSNotifyAll (module memoserv/main) has been removed, since it is
        required for channel memos.  MemoServ will now always behave as if
        MSNotifyAll was set.
  - MaxSockets (module mail/smtp) has been removed, since MaxMessages now
        performs the same function.
From toxic at freemail.gr  Sun May  6 15:03:55 2007
From: toxic at freemail.gr (Dionisios K.)
Date: Sun May  6 15:03:45 2007
Subject: [IRCServices] Feature request
In-Reply-To: <463d6bba.42313@msgid.achurch.org>
References: <463d6bba.42313@msgid.achurch.org>
Message-ID: <463E50CB.5080908@freemail.gr>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lets say i have a vhost or i'm an ircop..
I want to first activate my host and oper-up to get operhost after
identify my nickname and after this nickserv can ajoin me to the
channels so my vhost will be shown and not my real hostname.
I talking about 1-2 seconds delay not 10 or more seconds.
Thats why i'm asking for this.

Andrew Church wrote:
>> Is possible to add an option on the config file for a delay (optional)
>> before nickserv autojoin after identify?
>
> I'd rather not, since it could confuse users when they're suddenly joined
> to a channel without having done anything immediately prior. (Even a
> 10-second delay, for example, can be disorienting if the user's mind has
> gone onto other things.) Why would you want such an option?
>
> --Andrew Church
> achurch@achurch.org
> http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
>


- --
Dionisios K.
Network Administrator On NeMeSiS.mIRC.gr
ToXiC@FreeMail.gr

PGP Key: http://toxic.my-place.us/pubkey.asc
PGP FP: 0950 5363 DD1C D5A7 45C6 2991 F760 982E DD47 9149
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPlDK92CYLt1HkUkRAsN3AJ9UPX8FyfDJa9AGLR+YF9PiqlbOSQCcC2Bq
8VMLmUoDC8/bDr+66w+y74E=
=48E3
-----END PGP SIGNATURE-----

From toxic at freemail.gr  Sun May  6 15:17:04 2007
From: toxic at freemail.gr (Dionisios K.)
Date: Sun May  6 15:16:47 2007
Subject: [IRCServices] Feature For 5.1
In-Reply-To: <463d6b37.42304@msgid.achurch.org>
References: <463d6b37.42304@msgid.achurch.org>
Message-ID: <463E53E0.1070605@freemail.gr>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lets say i'm a founder on a channel..
I dont want channel ops to give op status but i want some times (lets
say when all ops are inactive) to give +h to some people.
Halfops can not do much damage to the channel so ops (and i) dont have
to trust them 100%.
I think it will be useful for many users (founders) out there..
Thanks:-)

Andrew Church wrote:
>> I want to suggest a feature for 5.1 Something for ircds with +h
>> (halfops).
>> To modify the secureops command so it may allow halfops but not ops OR
>> dont allow anyone.
>> Something like:
>> /cs set #channel secureops ops / all / off
>> If "ops" option is enabled chanserv will allow halfops.
>
> I don't really see the utility of this, but if there's enough interest in
> it I'll consider it.
>
> --Andrew Church
> achurch@achurch.org
> http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
>


- --
Dionisios K.
Network Administrator On NeMeSiS.mIRC.gr
ToXiC@FreeMail.gr

PGP Key: http://toxic.my-place.us/pubkey.asc
PGP FP: 0950 5363 DD1C D5A7 45C6 2991 F760 982E DD47 9149
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPlPg92CYLt1HkUkRApljAJ9rzFRw/zWpXO8ojDsl0aNZ3d1TwQCcD7wN
wC9m5wiZe3TY3P+2Rf5pzFM=
=oJ3J
-----END PGP SIGNATURE-----

From achurch at achurch.org  Mon May  7 13:17:29 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun May  6 21:19:09 2007
Subject: [IRCServices] Feature request
In-Reply-To: <463E50CB.5080908@freemail.gr>
Message-ID: <463ea8b9.62004@msgid.achurch.org>

>Lets say i have a vhost or i'm an ircop..
>I want to first activate my host and oper-up to get operhost after
>identify my nickname and after this nickserv can ajoin me to the
>channels so my vhost will be shown and not my real hostname.
>I talking about 1-2 seconds delay not 10 or more seconds.
>Thats why i'm asking for this.

     My suggestion in this case would be to not use autojoin at all, or to
take care of your operhost settings before identifying to NickServ.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Thu May 10 04:16:47 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu May 10 04:16:52 2007
Subject: [IRCServices] AKICK sometimes not functioning
Message-ID: <b19eae4e0705100416p489aaa7fr90eb6f3d6bd1efef@mail.gmail.com>

This was sent offlist to Andrew by a friend of mine some time ago.
I've seen the same problem happen on Unreal from time to time. Has
there been any progress?

---

For some reason i can't sent mails to the list so i sent it directly to you.
I suspect that there is a bug/desync with unrealircd protocol and akick
command. From the debug i got these things:

(1) First of all an akicked nick was join on the channel and NO ban
added (the akick form is *gami?*!*@*):

debug: Received: :athens.mirc.gr ~ 1075076130 #hellas :gamias_ixiwn_pc
protocol/unreal: debug: gamias_ixiwn_pc SJOINs #hellas
chanserv/main: debug: AutoKicking
gamias_ixiwn_pc!oeo@dsl-88-218-20-176.customers.vivodi.gr
debug: Sent: :ChanServ KICK #hellas gamias_ixiwn_pc :AKICK by ToXiC (REASON)

(2) Then i sent the CLEAR BANS command. On the channel ONLY ONE ban was
active on the channel but on debug log was shown:

debug: Received: :^^Dark_Angel^^ ! chanserv@services.mirc.gr :clear
#hellas bans
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-C3145A85.static.ot *!*@hellenic-32E97525.otenet.gr
malakas!*@* kavliares!*@* *gami?*!*@* *!*@7613FF74.63BB16D5.CFD57BAB.IP
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-A46D449A.otenet.gr *!*@hellenic-89BB5FC5.adsl.forthnet.gr
*!*@hellenic-D3CC9140.tri.sch.gr putsaras!*@*
*!*@hellenic-CE36B1C9.adsl.forthnet.gr *!*@clnt-1sek-g-ath.att.sch.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@E1939A95.20603DA2.215D451.IP *kayla*!*@* *gamo*!*@* gaula!*@*
*!*@9207C5E3.6FEDB5B7.50F427D1.IP *!*@69.249.180.193
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@86D9FC89.10EC8293.9A2BCC0A.IP *!*@68.85.35.202
*!*@4F8C3B01.E5B9DDEC.B *!*@hellenic-D80AC49D.telecable.es
*!*@200.153.72.218 *!*@3302F7A5.4A306984.A8695807.IP
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@BCE67E57.82264834.675173FD.IP *!*@124.28.25.108 *!*@87.68.39.186
*!*@5C2967CE.83DA9394.D9A6C199.IP *!*@200.254.132.132 *!*@203.113.15.234
debug: Sent: :ChanServ MODE #hellas -bbbbbb *!*@217.218.242.196
*!*@hellenic-EBC9B4C6.sec.ppp.nifty.com *!*@12693008.2C0C2038.620F215.IP
*!*@hellenic-5CDBBD4A.tricom.net *!*@29B2856B.15C972F6.9B81B978.IP
*!*@C0E99826.F2B2EE09.4F8A4945.IP
debug: Sent: :ChanServ MODE #hellas -bbbbbb *!*@69.4 *!*@64.238.186.38
*!*@F16DFCFA.D40B9A28.7C3DD77E.IP *!*atlanta@*.kastoria.acn.gr
*kavliar*!*@* *kaUl*!*@*
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-E38CC884.otenet.gr *!*psaxno@*.otenet.gr
*!*@AD527F08.B2BAE8E7.F86BB95D.IP *!*@B2CD6562.365635F2.E209DD7.IP
kavla7!*@* *!*@hellenic-8FBDAF80.dsl.hol.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb *!*@5EF6B664.CACEC989.976065
*!*@hellenic-457BB65E.otenet.gr *!*@hellenic-818B283.tellas.gr
*!*@hellenic-457BB65E.otenet.gr *!*921@*.otenet.gr
*!*@hellenic-815568A1.otenet.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb mbixtis!*@* horny!*@*
*!*@6C753ADD.365635F2.E209DD7.IP kavla7!*@*
*!*@hellenic-8FBDAF80.dsl.hol.gr *!*@5EF6B664.CACEC989.976065B3.IP
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-89AC502D.xan1.nas.panafonet.gr *porn*!*@* kaulomeno!*@*
*!*@hellenic-89AC502D.xan1.nas.panafonet.gr *porn*!*@* kaulomeno!*@*
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-97D67394.her01.cas.hol.gr *!*@ED27260.365635F2.E209DD7.IP
*!*@hellenic-C085AE56.otenet.gr *kaulia*!*@* kaula*!*@* poutsaras!*@*
debug: Sent: :ChanServ MODE #hellas -bbbbbb *GAVLA*!*@* pso__la_ras!*@
*!*buser@* *!*@hellenic-65C000A.dsl.hol.gr GAMIAS!*@*
*!*@D4BE7241.365635F2.E209DD7.IP
debug: Sent: :ChanServ MODE #hellas -bbbbbb
vbvbvv!*536@hellenic-23DA8179.otenet.gr *!*@hellenic-970F30D5.cc
*!*@D4BE7241.365635F2.E209DD7.IP *!*@hellenic-37821E0B.axiom.gr
*!*@hellenic-3F1003D9.kif1.nas.panafonet.gr
*!*@hellenic-9F7AB9F8.adsl.forthnet.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-4CC13A63.salonica.acn.gr *!*@5CFE2D85.EB38140.F5CB24F2.IP
FUKboy!*@* pour *!*@hellenic-8AE409A2.dsl.hol.gr
*!*@hellenic-82AFF71B.thess.sch.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb *poytan?*!*@*
*!*@hellenic-3DFF340E.att.sch.gr KAVLIRA!*@*
*!*@hellenic-59571E46.att.sch.gr Psolaras!*@* POUTSOPNIXTR!*@*
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-4CC13A63.salonica.acn.gr *!*@5CFE2D85.EB38140.F5CB24F2.IP
FUKboy!*@* pourstaki*!*@* *!*@hellenic-8AE409A2.dsl.hol.gr
*!*@hellenic-D8F3EF1E.otenet.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@53DD28DB.1E0DF0D9.50F427D1.IP *!*@hellenic-B632CB38.flo.sch.gr
*!*@604FB915.365635F2.E209DD7.IP *!*@hellenic-DBD1B126.adsl.forthnet.gr
*!*@hellenic-1C64F517.otenet.gr *fuck*!*@*
debug: Sent: :ChanServ MODE #hellas -bbbbbb fucker!*@*
*!*@C03B072C.9EF6AB6B.2012A77E.IP *!*@hellenic-8C47805C.otenet.gr
*!*@9EB429A5.EB38140.F5CB24F2.IP *!*@hellenic-8C47805C.otenet.gr
*!*@hellenic-2219D447.gre.sch.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-34FB22FB.otenet.gr *Kolarak*!*@* *gavli*!*@*
*!*@hellenic-59571E46.att.sch.gr
*!*@hellenic-760996C0.dip0.t-ipconnect.de
*!*@hellenic-6E8C11DE.adsl.forthnet.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb *malak?s*!*@* GAMIAS!*@*
GAMIAS!*@* *!*@hellenic-760996C0.dip0.t-ipconnect.de
*!*@hellenic-6E8C11DE.adsl.forthnet.gr *malak?s*!*@*
debug: Sent: :ChanServ MODE #hellas -bbbbbb GAMIAS!*@*
*!*@hellenic-760996C0.dip0.t-ipconnect.de
*!*@hellenic-6E8C11DE.adsl.forthnet.gr *malak?s*!*@* kauliara!*@* GAMIAS!*@*
debug: Sent: :ChanServ MODE #hellas -bbbbbb
*!*@hellenic-5DC10C9B.lns.hol.gr gamias*!*@*
*!*@8E942C27.C4FDAC18.50F427D1.IP gamikoylas!*@* gamias*!*@*
*!*@hellenic-BF84614C
debug: Sent: :ChanServ MODE #hellas -bbbbbb moynogavla!*@*
*!*3045-7190@*.B167C549.9D81F7A.IP *!*@8E942C27.C4FDAC18.50F427D1.IP
gamikoylas!*@* gamias*!*@* *!*@hellenic-BF84614C.otenet.gr
debug: Sent: :ChanServ MODE #hellas -bbbbbb moynogavla!*@*
*!*3045-7190@*.B167C549.9D81F7A.IP *!*@hellenic-A93D458.otenet.gr
malakas!*@* moynogavla!*@* *!*3045-7190@*.B167C549.9D81F7A.IP
channel: MODE #hellas -b moynogavla!*@*: ban not found
channel: MODE #hellas -b *!*3045-7190@*.B167C549.9D81F7A.IP: ban not found
debug: Sent: :ChanServ MODE #hellas -bb *!*@hellenic-A93D458.otenet.gr
malakas!*@*
channel: MODE #hellas -b *!*@hellenic-A93D458.otenet.gr: ban not found
channel: MODE #hellas -b malakas!*@*: ban not found
debug: Sent: :ChanServ NOTICE ^^Dark_Angel^^ :All bans on channel
#hellas have been removed.

On the channel only this was shown: * ChanServ sets mode: -b malakas!*@*

(3) Then when the bad nickname came back it was kicked/banned just fine:

protocol/unreal: debug: gamias_ixiwn_pc SJOINs #hellas
chanserv/main: debug: AutoKicking
gamias_ixiwn_pc!oeo@dsl-88-218-20-176.customers.vivodi.gr
debug: Sent: :ChanServ MODE #hellas +b *gami?*!*@*
debug: Sent: :ChanServ KICK #hellas gamias_ixiwn_pc :AKICK by ToXiC (REASON)


-----

REPLY:

Andrew Church wrote:
> > Thanks for the message. I'm busy with work at the moment, but I'll take a
> > look into the problem as soon as possible. If you can find a way to
> > consistently reproduce the problem, that would help as well.

----

ME:

It's random i can't reproduce it.
I have seen it on restricted channels also.
As i can see for some reason ircservices is not informed for removed
bans so it thinks that the ban already exists and it not add it again.
From achurch at achurch.org  Sun May 13 06:19:48 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat May 12 14:21:29 2007
Subject: [IRCServices] AKICK sometimes not functioning
In-Reply-To: <b19eae4e0705100416p489aaa7fr90eb6f3d6bd1efef@mail.gmail.com>
Message-ID: <46462fd5.44532@msgid.achurch.org>

>This was sent offlist to Andrew by a friend of mine some time ago.
>I've seen the same problem happen on Unreal from time to time. Has
>there been any progress?

     I'm afraid not; I've been unable to find any apparent cause for the
problem, so at this point there's not much I can do without further
information, such as a way to consistently reproduce it.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From loverboy at irc.doruk.net.tr  Sun May 13 06:13:13 2007
From: loverboy at irc.doruk.net.tr (LoVeRbOy (A.S.))
Date: Sun May 13 06:13:56 2007
Subject: [IRCServices] ircservices-5.1pre0 Problems
Message-ID: <001901c79560$90fdf530$0100000a@citir>

Today we tried new beta release,
And we come across some problems...Here is the list... (Converted DB from 
5.0.* and Unreal IRCD)

1- Translations arent ready.
2- Founders of the channels dont get +q when they join the channel but they 
get +a.
3- Mlocks are gone after the convert.
4- In some channels when you voice someone, chanserv makes -ao even they 
dont have access. But if they left the channel and come back. No problem 
occurs.

We will try again later...Turned back to stable Release.. 

From surreal.w00t at gmail.com  Sun May 13 06:37:27 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sun May 13 06:37:41 2007
Subject: [IRCServices] ircservices-5.1pre0 Problems
In-Reply-To: <001901c79560$90fdf530$0100000a@citir>
References: <001901c79560$90fdf530$0100000a@citir>
Message-ID: <b19eae4e0705130637j4faf064cl47b12ae68df00a2f@mail.gmail.com>

For some strange reasoning ("not being agreed upon"), +q support was
removed. I don't really understand or agree with the logic behind it,
nor does anyone else I know of. But that's why that didn't work at
least. :)

On 5/13/07, LoVeRbOy (A.S.) <loverboy@irc.doruk.net.tr> wrote:
> Today we tried new beta release,
> And we come across some problems...Here is the list... (Converted DB from
> 5.0.* and Unreal IRCD)
>
> 1- Translations arent ready.
> 2- Founders of the channels dont get +q when they join the channel but they
> get +a.
> 3- Mlocks are gone after the convert.
> 4- In some channels when you voice someone, chanserv makes -ao even they
> dont have access. But if they left the channel and come back. No problem
> occurs.
>
> We will try again later...Turned back to stable Release..
>
> ------------------------------------------------------------------
> To unsubscribe