RELEASE -> !RELEASE

[irc.git] / software / !RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2007.txt

From tigra.ru at gmail.com  Sat Jan 13 06:37:12 2007
From: tigra.ru at gmail.com (Tigra)
Date: Sat Jan 13 06:37:51 2007
Subject: [IRCServices Coding] configure error, 5.1a11 on FreeBSD 4.11
Message-ID: <9098af010701130637o3ac7c57bpda4686da6280b427@mail.gmail.com>

Hello Andrew

there is a configure error under FreeBSD 4.11

look at configure, lines 2614, 2615, 2626, 2627, 2637,2638, 2648, 2649,
missing $ sign when creating config.h file:

typedef   signed $TYPE_INT8   int8;
typedef unsigned $TYPE_INT8  uint8;

and so on.


---
wbr, Tigra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070113/322778af/attachment.html
From surreal.w00t at gmail.com  Sat Jan 13 10:40:30 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 13 10:40:35 2007
Subject: [IRCServices Coding] configure error, 5.1a11 on FreeBSD 4.11
In-Reply-To: <9098af010701130637o3ac7c57bpda4686da6280b427@mail.gmail.com>
References: <9098af010701130637o3ac7c57bpda4686da6280b427@mail.gmail.com>
Message-ID: <b19eae4e0701131040v54244964w323dfd8a557be511@mail.gmail.com>

I'm not sure as to whether there's a problem, but you may want to look
at upgrading anyway. FreeBSD 4.x is about to leave it's extended
support period.

On 1/13/07, Tigra <tigra.ru@gmail.com> wrote:
> Hello Andrew
>
> there is a configure error under FreeBSD 4.11
>
> look at configure, lines 2614, 2615, 2626, 2627, 2637,2638, 2648, 2649,
> missing $ sign when creating config.h file:
>
> typedef   signed $TYPE_INT8   int8;
> typedef unsigned $TYPE_INT8  uint8;
>
> and so on.
>
>
> ---
> wbr, Tigra
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>
From achurch at achurch.org  Sun Jan 14 05:00:54 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan 13 12:03:19 2007
Subject: [IRCServices Coding] configure error, 5.1a11 on FreeBSD 4.11
In-Reply-To: <9098af010701130637o3ac7c57bpda4686da6280b427@mail.gmail.com>
Message-ID: <45a93b05.70336@msgid.achurch.org>

>look at configure, lines 2614, 2615, 2626, 2627, 2637,2638, 2648, 2649,
>missing $ sign when creating config.h file:
>
>typedef   signed $TYPE_INT8   int8;
>typedef unsigned $TYPE_INT8  uint8;
>
>and so on.

     Fixed, thanks for the report.  Apply the patch below until I get a
new release out.

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

Index: configure
===================================================================
RCS file: /var/local/cvsroot/ircservices/configure,v
retrieving revision 2.135
diff -u -r2.135 configure
--- configure   6 Dec 2006 06:49:49 -0000       2.135
+++ configure   13 Jan 2007 20:02:55 -0000
@@ -2612,8 +2612,8 @@
 EOT
 else
     cat >>config.h.new <<EOT
-typedef   signed TYPE_INT8   int8;
-typedef unsigned TYPE_INT8  uint8;
+typedef   signed $TYPE_INT8   int8;
+typedef unsigned $TYPE_INT8  uint8;
 EOT
 fi
 if [ "$TYPE_INT16" = int16_t ] ; then
@@ -2623,8 +2623,8 @@
 EOT
 else
     cat >>config.h.new <<EOT
-typedef   signed TYPE_INT16  int16;
-typedef unsigned TYPE_INT16 uint16;
+typedef   signed $TYPE_INT16  int16;
+typedef unsigned $TYPE_INT16 uint16;
 EOT
 fi
 if [ "$TYPE_INT32" = int32_t ] ; then
@@ -2634,8 +2634,8 @@
 EOT
 else
     cat >>config.h.new <<EOT
-typedef   signed TYPE_INT32  int32;
-typedef unsigned TYPE_INT32 uint32;
+typedef   signed $TYPE_INT32  int32;
+typedef unsigned $TYPE_INT32 uint32;
 EOT
 fi
 if [ "$TYPE_INT64" = int64_t ] ; then
@@ -2645,8 +2645,8 @@
 EOT
 else
     cat >>config.h.new <<EOT
-typedef   signed TYPE_INT64  int64;
-typedef unsigned TYPE_INT64 uint64;
+typedef   signed $TYPE_INT64  int64;
+typedef unsigned $TYPE_INT64 uint64;
 EOT
 fi
 cat >>config.h.new <<EOT
From surreal.w00t at gmail.com  Sat Jan 13 13:19:04 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sat Jan 13 13:19:11 2007
Subject: [IRCServices Coding] Progress / testing?
Message-ID: <b19eae4e0701131319n2824911ew5b02dbc8cf879a1c@mail.gmail.com>

Just a little curious as to how progress is going on 5.1, now major
milestones (database API) and technical docs have been done, and as to
whether it's in use on any networks with more than 5 users. (i.e. how
it performs, stability, etc)

Anyone out there (including Andrew, on the first point) able to enlighten me?
From achurch at achurch.org  Sun Jan 14 06:19:38 2007
From: achurch at achurch.org (Andrew Church)
Date: Sat Jan 13 13:23:37 2007
Subject: [IRCServices Coding] Progress / testing?
In-Reply-To: <b19eae4e0701131319n2824911ew5b02dbc8cf879a1c@mail.gmail.com>
Message-ID: <45a94dd6.71647@msgid.achurch.org>

>Just a little curious as to how progress is going on 5.1, now major
>milestones (database API) and technical docs have been done, and as to
>whether it's in use on any networks with more than 5 users. (i.e. how
>it performs, stability, etc)
>
>Anyone out there (including Andrew, on the first point) able to enlighten me?

     I can't speak to the second point, but as to the first, I'm afraid
I've been a little burdened with work lately (various circumstances led to
my changing jobs late last year), so I haven't really had a chance to work
on Services since the last release.  Hopefully things will calm down over
the next couple of months; in the meantime, please be patient.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From tigra.ru at gmail.com  Sat Jan 13 21:45:16 2007
From: tigra.ru at gmail.com (Tigra)
Date: Sat Jan 13 21:45:21 2007
Subject: [IRCServices Coding] configure error, 5.1a11 on FreeBSD 4.11
In-Reply-To: <b19eae4e0701131040v54244964w323dfd8a557be511@mail.gmail.com>
References: <9098af010701130637o3ac7c57bpda4686da6280b427@mail.gmail.com>
        <b19eae4e0701131040v54244964w323dfd8a557be511@mail.gmail.com>
Message-ID: <9098af010701132145ub66715fuaebec158b2f0caf@mail.gmail.com>

On 1/13/07, Robin Burchell <surreal.w00t@gmail.com> wrote:
>
> I'm not sure as to whether there's a problem, but you may want to look
> at upgrading anyway. FreeBSD 4.x is about to leave it's extended
> support period.


yes, I know, but problem can exist not only on FreeBSD 4.x.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070114/e0bf073b/attachment.html
From richard at squarecows.com  Fri Feb 16 06:04:12 2007
From: richard at squarecows.com (Richard Harvey)
Date: Fri Feb 16 06:04:23 2007
Subject: [IRCServices Coding] 5.1 -import problem
Message-ID: <5b6dfd25fcf922a76e2e40f337cd5e7b@mail.squarecows.com>

Hi guys,

I'm trying to use the alpha version of ircservices because i have upgraded my ircd to solid-ircd because i'm looking to impliment SSL connections. I have come from a bahamut 1.8.4 server.

I've follow the upgrade path of 

shutdown the ircservices

installing the new .deb (dpkg -i ircservices_5.1a11-1.deb) -seems to work ok

then i run (ircservices -export=database.xml) -seems to work out

then i try and run (ircservices -import=database.xml) -errors with this

root@HOSTNAME /etc/ircservices# ircservices -import=database.xml
Initialization failed, exiting.

Can anyone help? Then i can get submitting performance stats and bugs for 5.1.

Cheers Ric

--
Richard Harvey
~~~~~~~~~~~~~
Email:          richard@squarecows.com
Web:            www.squarecows.com
Mobile:         07798 656 019
Skype In:       020 8816 8343

Fingerprint:    B9A6 97CD 5941 9EC2 45F4  BCF2 961E DD64 9D0F CA37

From achurch at achurch.org  Sat Feb 17 02:19:13 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Feb 16 09:24:01 2007
Subject: [IRCServices Coding] 5.1 -import problem
In-Reply-To: <5b6dfd25fcf922a76e2e40f337cd5e7b@mail.squarecows.com>
Message-ID: <45d5e8ae.40332@msgid.achurch.org>

>then i try and run (ircservices -import=database.xml) -errors with this
>
>root@HOSTNAME /etc/ircservices# ircservices -import=database.xml
>Initialization failed, exiting.

     Are there any error messages in the log file?  Did you remember to
enable the misc/xml-import module in ircservices.conf?  Try adding the
-debug and -nofork options to the command line (in import mode, Services
won't fork a child process anyway, but -nofork will cause log messages to
be printed to the console).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Sat Feb 17 12:00:00 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Feb 16 19:01:31 2007
Subject: [IRCServices Coding] Services 5.1a12 released
Message-ID: <45d67008.27327@msgid.achurch.org>

     Services 5.1a12 has been released, and can be downloaded from:

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

ed7bcd7cdcd10ab90c0b1e6b1f9d4e3e  ircservices-5.1a12.tar.gz
9e90be42d3f8b76d6c7df69708047a9e  ircservices-5.1a12.diff.gz
e8556080ff70b2d37a7259b19b67b7b7  ircservices-5.1a12-1.i386.rpm
814bbbd28b6b92443b095a9061de8a40  ircservices_5.1a12-1_i386.deb

The mirrors should have it shortly.

     This release takes care of a number of comparatively minor issues I
had encountered and noted while writing the Services technical manual.
This covers the last of my currently planned changes for 5.1; if nothing
comes up, I'll probably release a beta version before too long.  (This of
course assumes that I can find the time to do so.  There's a reason all
those change log entries are clustered in a single day--I didn't dare waste
my rare moments of freedom!)

Changes in version 5.1a12
-------------------------
2007/02/16      Fixed possibly incorrect handling by convert-db of nonstandard
                    channel fields FREASON and FTIME in HybServ databases.
2007/02/16      Fixed result message for SET TIMEZONE by a Services
                    administrator whose timezone is set to the default.
2007/02/16      Fixed a duplicate WALLOPS for NickServ SET PASSWORD by
                    Services administrators.
2007/02/16      Removed all support for "modeless" channels (+name).
2007/02/16      Fixed httpd/redirect handling of nicknames and channel
                    names containing slashes.  (As a side effect, URLs with
                    trailing slashes are no longer accepted.)
2007/02/16      The httpd/top-page module now only responds to requests for
                    the top page, rather than for any URL.
2007/02/16      The built-in HTTP server now reports an error on overlength
                    HTTP request lines rather than silently splitting them.
2007/02/16      Added password obscurity check to ChanServ REGISTER and SET
                    PASSWORD.  Suggested by Dionisios K. <vonitsa_net@yahoo.gr>
2007/02/16      Changed NSRejectEmail configuration directive to RejectEmail,
                    and added rejection checks to NickServ/ChanServ SET EMAIL.
2007/02/16      Changed MD_EXCLUSION constant name to MD_EXCLUDE to match
                    the OperServ command name.
2007/02/16      Add get/put-field wrapper routines to database code to
                    remove unnecessary complexity from database modules.
2007/02/16      Fixed bug causing PID file to not be removed on exit.
2007/01/14      Fixed bug in configure type definitions.  Reported by
                    <tigra.ru@gmail.com>

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Sat Mar 24 03:33:26 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Mar 23 11:34:17 2007
Subject: [IRCServices Coding] Services 5.1a13 released
Message-ID: <46041da5.40557@msgid.achurch.org>

     Services 5.1a13 has been released, and can be downloaded from:

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

4fb234f4992460dcb486b73aef1f6816  ircservices-5.1a13.tar.gz
678e17d3c06789e531125c80012f80c2  ircservices-5.1a13.diff.gz
1f22cc67e7efb00153396be687b6175f  ircservices-5.1a13-1.i386.rpm
f2d816b689f1e63e3986cb7e5e5836f9  ircservices_5.1a13-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.  (This is the same
change applied to version 5.0.60.)

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

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From v.ovsyannikov at kr.ru  Thu Mar 29 22:45:28 2007
From: v.ovsyannikov at kr.ru (Vitaliy Ovsyannikov)
Date: Thu Mar 29 22:45:54 2007
Subject: [IRCServices Coding] proxy checking
In-Reply-To: <46041da5.40557@msgid.achurch.org>
References: <46041da5.40557@msgid.achurch.org>
Message-ID: <277339607.20070330134528@kr.ru>

Hello,

Somebody has a module for checking client's IP address is an open
proxy?

--
wbr

From bender_54 at msn.com  Mon Apr 16 02:36:59 2007
From: bender_54 at msn.com (Nick Bent)
Date: Mon Apr 16 02:37:03 2007
Subject: [IRCServices Coding] Feature Suggestions
Message-ID: <BAY115-F128D33FFCBF18F53D54FE381520@phx.gbl>

An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070416/565eab6f/attachment.html
From ron2k.za at gmail.com  Mon Apr 16 03:27:12 2007
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Mon Apr 16 03:27:16 2007
Subject: [IRCServices Coding] Feature Suggestions
In-Reply-To: <BAY115-F128D33FFCBF18F53D54FE381520@phx.gbl>
References: <BAY115-F128D33FFCBF18F53D54FE381520@phx.gbl>
Message-ID: <debb3bc0704160327j6d7e7bb4ta442f7960f840eaf@mail.gmail.com>

> 1. /ns set autoop [on|off] - Just like Anope

If this is what I think it is, which is that the nick in question
won't be auto-opped on any channel (next time please elaborate on what
Anope does), I believe that Andrew may have been considering this at
one point (I think it was in one of the TODO lists). That being said,
I haven't seen this in 5.1, so it may have been dropped or thrown out.

> 2. I think channel passwords suck, so:
>
> - Leave /cs register the same, but ignore the password field, like on
> Surreal Services
>
> - Add an xOP level called QOP or CF or Co-Founder, access level 900 (not 999
> please).
>
> - Only the "true founder" can set successor.
>
> - Remove /cs identify
>
> - /cs drop won't require the user to do /cs identify first
>
> - Add commands owner and deowner, and levels autoowner and owner
>
> - /cs deprotect will no longer set mode -q, it will do -a only

I was actually thinking of something like this a while back. I'll
leave it up to Andrew to make the final call on this one, but I
suggest a few more things: firstly, regarding the "only the 'true
founder' can set successor" bit, go further - only the true founder
should be able to modify such a list in the first place. Secondly,
dropping a channel should always require a password, for security
reasons and to guard against accidental drops.

What I like about this method is that it reduces the possibility of
someone changing the "true founder" of a channel, as I assume that
users on a "co-founder" list wouldn't be given that permission.

As a sidenote, 5.1 has dropped support for the channel owner mode (+q
on UnrealIRCd for example); channel owners will be given the same
modes as those on the SOP list or access level >= 100.

> 3. /cs clear #channel users - make this only kick users who don't have the
> access to use it.

No opinion on this.

> 4. When someone sets a new founder for the channel, they immediately lose
> their founder-level access.

Kind of stupid, as someone losing their founder-level access and
knowing the channel password could just identify using the channel
password and get founder-level access straight back. If the system
mentioned in your second point were to be implemented, then I could
see a use for this, but right now it makes no sense at all.

> 5. /ns listchans - make this list all of the user's channel accesses, like
> /ns alist in Anope

If I understand you correctly, you want this to display the access
list for a channel as well. Services already does this. (/msg ChanServ
ACCESS #channel LIST - or something like that)

> 6. When someone does /cs info #channel, and it shows the mode lock, make it
> show the locked mode paramaters too.

Bad idea. I'm sure that no-one wants to see their channel key
displayed in this manner. :)

--K
From achurch at achurch.org  Tue Apr 17 15:53:22 2007
From: achurch at achurch.org (Andrew Church)
Date: Tue Apr 17 00:12:03 2007
Subject: [IRCServices Coding] Feature Suggestions
In-Reply-To: <debb3bc0704160327j6d7e7bb4ta442f7960f840eaf@mail.gmail.com>
Message-ID: <4624733c.06344@msgid.achurch.org>

     To the original poster: Don't use HTML mail on this list.

>> 1. /ns set autoop [on|off] - Just like Anope
>
>If this is what I think it is, which is that the nick in question
>won't be auto-opped on any channel (next time please elaborate on what
>Anope does), I believe that Andrew may have been considering this at
>one point (I think it was in one of the TODO lists). That being said,
>I haven't seen this in 5.1, so it may have been dropped or thrown out.

     I've never seen the point to this option (if you don't want auto-ops,
don't have people give you auto-op access), so I won't be adding it.

>> 2. I think channel passwords suck, so:
[...]

     I agree, but removing them at this point is not feasible, so I've left
it documented as something for future developers to think about (technical
manual section 11).

>> 3. /cs clear #channel users - make this only kick users who don't have the
>> access to use it.

     I'd rather keep it the way it is--kick everybody out and let the users
sort things out afterwards.  (Changing it as you suggest would undoubtedly
leave users wondering "why didn't user X get kicked?")

>> 4. When someone sets a new founder for the channel, they immediately lose
>> their founder-level access.

     This is already the case (unless the founder used the IDENTIFY command
to gain privileges, in which case there would be no point in dropping
privileges because he could just identify again).

>> 5. /ns listchans - make this list all of the user's channel accesses, like
>> /ns alist in Anope
>
>If I understand you correctly, you want this to display the access
>list for a channel as well. Services already does this. (/msg ChanServ
>ACCESS #channel LIST - or something like that)

     I think the intention was a new command to list every channel the user
has a nonzero access level on, along with that access level.  I don't see
that as necessary, because (as you say) ChanServ ACCESS can already display
the access level of a particular list; also, the time required to search
through all access lists of all channels could be prohibitively long on
large networks.

>> 6. When someone does /cs info #channel, and it shows the mode lock, make it
>> show the locked mode paramaters too.
>
>Bad idea. I'm sure that no-one wants to see their channel key
>displayed in this manner. :)

     Exactly.  As for other modes, just look at the channel's current mode
set, which will naturally be the same as what's set in the mode lock.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From tim at retout.co.uk  Tue May 15 19:18:19 2007
From: tim at retout.co.uk (Tim Retout)
Date: Tue May 15 19:19:51 2007
Subject: [IRCServices Coding] Debian packages
Message-ID: <1179281899.26496.23.camel@regulus.retout.co.uk>

Hello!

I maintain an IRC server for a group of very happy ircservices users. We
are about to move to some amd64 machines, and run Debian.

I notice that binary Debian packages are available for i386 from your
website - but would it be helpful if I packaged ircservices and
submitted it to the main Debian archive? This would make it even easier
for Debian users like myself to use your software, especially if they
are using a different architecture.

Thanks for your time,

-- 
Tim Retout <tim@retout.co.uk>

From tim at retout.co.uk  Wed May 16 05:55:10 2007
From: tim at retout.co.uk (Tim Retout)
Date: Wed May 16 05:56:48 2007
Subject: [IRCServices Coding] md5 licensing
Message-ID: <1179320110.6934.18.camel@regulus.retout.co.uk>

The copyright notice on the md5 hashing code used in ircservices does
not grant a licence to redistribute modified versions. The clause about
mentioning "RSA Data Security, Inc." looks GPL-incompatible to me as
well. The same code was removed from Apache last year:
http://bugs.debian.org/340538

Please review this patch (against 5.1pre1) to port the md5 code to an
implementation licensed under a revised-BSD-style licence, found at:
http://sourceforge.net/project/showfiles.php?group_id=42360

I have tested it briefly, and it seems to work.

Thanks,

-- 
Tim Retout <tim@retout.co.uk>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ircservices-md5.diff
Type: text/x-patch
Size: 29252 bytes
Desc: not available
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070516/83119243/ircservices-md5-0001.bin
From achurch at achurch.org  Thu May 17 04:42:54 2007
From: achurch at achurch.org (Andrew Church)
Date: Wed May 16 12:43:59 2007
Subject: [IRCServices Coding] Debian packages
In-Reply-To: <1179281899.26496.23.camel@regulus.retout.co.uk>
Message-ID: <464b5efb.10707@msgid.achurch.org>

>I notice that binary Debian packages are available for i386 from your
>website - but would it be helpful if I packaged ircservices and
>submitted it to the main Debian archive? This would make it even easier
>for Debian users like myself to use your software, especially if they
>are using a different architecture.

     If you'd be willing to do that, I'd certainly appreciate it!  Please
let me know if there are any issues regarding packaging (such as file
layout), and I'll see if I can resolve them.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Thu May 17 04:48:47 2007
From: achurch at achurch.org (Andrew Church)
Date: Wed May 16 12:59:05 2007
Subject: [IRCServices Coding] md5 licensing
In-Reply-To: <1179320110.6934.18.camel@regulus.retout.co.uk>
Message-ID: <464b6285.20022@msgid.achurch.org>

>The copyright notice on the md5 hashing code used in ircservices does
>not grant a licence to redistribute modified versions. The clause about
>mentioning "RSA Data Security, Inc." looks GPL-incompatible to me as
>well. The same code was removed from Apache last year:
>http://bugs.debian.org/340538
>
>Please review this patch (against 5.1pre1) to port the md5 code to an
>implementation licensed under a revised-BSD-style licence, found at:
>http://sourceforge.net/project/showfiles.php?group_id=42360

     Thanks for pointing this out.  I've applied the patch below to
5.1pre1; let me know if you see any problems.

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

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

Index: docs/3.html
===================================================================
RCS file: /var/local/cvsroot/ircservices/docs/3.html,v
retrieving revision 2.74
diff -u -r2.74 3.html
--- docs/3.html 6 May 2007 06:49:48 -0000       2.74
+++ docs/3.html 16 May 2007 19:58:14 -0000
@@ -2279,10 +2279,10 @@
 <p>The available encryption modules are as follows:
 
 <p><ul>
-<li><b><tt>encryption/md5</tt></b>: Uses the MD5 hashing
-algorithm<sup>1</sup> to encrypt passwords.  This is a one-way encryption
-algorithm which generates a 128-bit "digest" of the password, and is used
-by several Unix systems to encrypt user passwords as well.
+<li><b><tt>encryption/md5</tt></b>: Uses the MD5 hashing algorithm to
+encrypt passwords.  This is a one-way encryption algorithm which generates
+a 128-bit "digest" of the password, and is used by several Unix systems to
+encrypt user passwords as well.
 <p><li><b><tt>encryption/unix-crypt</tt></b>: <b>DISCOURAGED.</b>  Uses the
 <tt>crypt()</tt> function available in most Unix systems, typically a
 variant of the DES encryption algorithm, to encrypt passwords.  This is a
@@ -2300,9 +2300,6 @@
 older passwords can still be used (provided the appropriate module is
 loaded).
 
-<p><sup>1</sup><font size=-1>Technically, the "RSA Data Security, Inc. MD5
-Message-Digest Algorithm".</font>
-
 <p align=right><font size="-1"><a href="#top">Back to top</a></font>
 
 <!------------------------------------------------------------------------>
Index: docs/Changes
===================================================================
RCS file: /var/local/cvsroot/ircservices/docs/Changes,v
retrieving revision 2.7
diff -u -r2.7 Changes
--- docs/Changes        13 May 2007 16:40:05 -0000      2.7
+++ docs/Changes        16 May 2007 19:58:14 -0000
@@ -1,5 +1,8 @@
 Version 5.1
 -----------
+2007/05/17     Replaced RSA's MD5 implementation with one licensed under
+                   more lenient terms.  Suggested by Tim Retout
+                   <tim@retout.co.uk>
 2007/05/14 pre1        Fixed a bug in XML import that caused channel mode locks to
                    be lost.  Reported by <loverboy@irc.doruk.net.tr>
 2007/05/14     Fixed Services being unable to start if both the compatibility
Index: modules/encryption/md5.c
===================================================================
RCS file: /var/local/cvsroot/ircservices/modules/encryption/md5.c,v
retrieving revision 2.24
diff -u -r2.24 md5.c
--- modules/encryption/md5.c    15 Feb 2007 14:53:30 -0000      2.24
+++ modules/encryption/md5.c    16 May 2007 19:58:14 -0000
@@ -22,322 +22,483 @@
 #define XTOI(c) ((c)>9 ? (c)-'A'+10 : (c)-'0')
 
 /*************************************************************************/
-/*======== Beginning of RSA's md5c.c ========*/
-
-/* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
-rights reserved.
-
-License to copy and use this software is granted provided that it
-is identified as the "RSA Data Security, Inc. MD5 Message-Digest
-Algorithm" in all material mentioning or referencing this software
-or this function.
-
-License is also granted to make and use derivative works provided
-that such works are identified as "derived from the RSA Data
-Security, Inc. MD5 Message-Digest Algorithm" in all material
-mentioning or referencing the derived work.
-
-RSA Data Security, Inc. makes no representations concerning either
-the merchantability of this software or the suitability of this
-software for any particular purpose. It is provided "as is"
-without express or implied warranty of any kind.
+/*======== Beginning of L. Peter Deutsch's md5.h ========*/
+/*
+  Copyright (C) 1999, 2002 Aladdin Enterprises.  All rights reserved.
 
-These notices must be retained in any copies of any part of this
-documentation and/or software.
- */
+  This software is provided 'as-is', without any express or implied
+  warranty.  In no event will the authors be held liable for any damages
+  arising from the use of this software.
 
-#include <string.h>
+  Permission is granted to anyone to use this software for any purpose,
+  including commercial applications, and to alter it and redistribute it
+  freely, subject to the following restrictions:
 
-typedef unsigned int UINT4;
+  1. The origin of this software must not be misrepresented; you must not
+     claim that you wrote the original software. If you use this software
+     in a product, an acknowledgment in the product documentation would be
+     appreciated but is not required.
+  2. Altered source versions must be plainly marked as such, and must not be
+     misrepresented as being the original software.
+  3. This notice may not be removed or altered from any source distribution.
 
-/* MD5 context. */
-typedef struct {
-  UINT4 state[4];                                   /* state (ABCD) */
-  UINT4 count[2];        /* number of bits, modulo 2^64 (lsb first) */
-  unsigned char buffer[64];                         /* input buffer */
-} MD5_CTX;
+  L. Peter Deutsch
+  ghost@aladdin.com
 
-/* MD5C.C - RSA Data Security, Inc., MD5 message-digest algorithm
  */
+/* $Id: md5.h,v 1.4 2002/04/13 19:20:28 lpd Exp $ */
+/*
+  Independent implementation of MD5 (RFC 1321).
 
-typedef void *POINTER;
-
-/* Constants for MD5Transform routine.
+  This code implements the MD5 Algorithm defined in RFC 1321, whose
+  text is available at
+       http://www.ietf.org/rfc/rfc1321.txt
+  The code is derived from the text of the RFC, including the test suite
+  (section A.5) but excluding the rest of Appendix A.  It does not include
+  any code or documentation that is identified in the RFC as being
+  copyrighted.
+
+  The original and principal author of md5.h is L. Peter Deutsch
+  <ghost@aladdin.com>.  Other authors are noted in the change history
+  that follows (in reverse chronological order):
+
+  2002-04-13 lpd Removed support for non-ANSI compilers; removed
+       references to Ghostscript; clarified derivation from RFC 1321;
+       now handles byte order either statically or dynamically.
+  1999-11-04 lpd Edited comments slightly for automatic TOC extraction.
+  1999-10-18 lpd Fixed typo in header comment (ansi2knr rather than md5);
+       added conditionalization for C++ compilation from Martin
+       Purschke <purschke@bnl.gov>.
+  1999-05-03 lpd Original version.
  */
-#define S11 7
-#define S12 12
-#define S13 17
-#define S14 22
-#define S21 5
-#define S22 9
-#define S23 14
-#define S24 20
-#define S31 4
-#define S32 11
-#define S33 16
-#define S34 23
-#define S41 6
-#define S42 10
-#define S43 15
-#define S44 21
-
-static void MD5Transform (UINT4 [4], unsigned char [64]);
-static void Encode (unsigned char *, UINT4 *, unsigned int);
-static void Decode (UINT4 *, unsigned char *, unsigned int);
-
-static unsigned char PADDING[64] = {
-  0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
-};
 
-/* F, G, H and I are basic MD5 functions.
- */
-#define F(x, y, z) (((x) & (y)) | ((~x) & (z)))
-#define G(x, y, z) (((x) & (z)) | ((y) & (~z)))
-#define H(x, y, z) ((x) ^ (y) ^ (z))
-#define I(x, y, z) ((y) ^ ((x) | (~z)))
+#ifndef md5_INCLUDED
+#  define md5_INCLUDED
 
-/* ROTATE_LEFT rotates x left n bits.
+/*
+ * This package supports both compile-time and run-time determination of CPU
+ * byte order.  If ARCH_IS_BIG_ENDIAN is defined as 0, the code will be
+ * compiled to run only on little-endian CPUs; if ARCH_IS_BIG_ENDIAN is
+ * defined as non-zero, the code will be compiled to run only on big-endian
+ * CPUs; if ARCH_IS_BIG_ENDIAN is not defined, the code will be compiled to
+ * run on either big- or little-endian CPUs, but will run slightly less
+ * efficiently on either one than if ARCH_IS_BIG_ENDIAN is defined.
  */
-#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32-(n))))
 
-/* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4.
-Rotation is separate from addition to prevent recomputation.
- */
-#define FF(a, b, c, d, x, s, ac) { \
- (a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \
- (a) = ROTATE_LEFT ((a), (s)); \
- (a) += (b); \
-  }
-#define GG(a, b, c, d, x, s, ac) { \
- (a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \
- (a) = ROTATE_LEFT ((a), (s)); \
- (a) += (b); \
-  }
-#define HH(a, b, c, d, x, s, ac) { \
- (a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \
- (a) = ROTATE_LEFT ((a), (s)); \
- (a) += (b); \
-  }
-#define II(a, b, c, d, x, s, ac) { \
- (a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \
- (a) = ROTATE_LEFT ((a), (s)); \
- (a) += (b); \
-  }
+typedef unsigned char md5_byte_t; /* 8-bit byte */
+typedef unsigned int md5_word_t; /* 32-bit word */
 
-/* MD5 initialization. Begins an MD5 operation, writing a new context.
- */
-static void MD5Init (context)
-MD5_CTX *context;                                        /* context */
-{
-  context->count[0] = context->count[1] = 0;
-  /* Load magic initialization constants.
-*/
-  context->state[0] = 0x67452301;
-  context->state[1] = 0xefcdab89;
-  context->state[2] = 0x98badcfe;
-  context->state[3] = 0x10325476;
-}
+/* Define the state of the MD5 Algorithm. */
+typedef struct md5_state_s {
+    md5_word_t count[2];       /* message length in bits, lsw first */
+    md5_word_t abcd[4];                /* digest buffer */
+    md5_byte_t buf[64];                /* accumulate block */
+} md5_state_t;
 
-/* MD5 block update operation. Continues an MD5 message-digest
-  operation, processing another message block, and updating the
-  context.
- */
-static void MD5Update (context, input, inputLen)
-MD5_CTX *context;                                        /* context */
-unsigned char *input;                                /* input block */
-unsigned int inputLen;                     /* length of input block */
+#ifdef __cplusplus
+extern "C" 
 {
-  unsigned int i, index, partLen;
+#endif
 
-  /* Compute number of bytes mod 64 */
-  index = (unsigned int)((context->count[0] >> 3) & 0x3F);
+/* Initialize the algorithm. */
+void md5_init(md5_state_t *pms);
 
-  /* Update number of bits */
-  if ((context->count[0] += ((UINT4)inputLen << 3))
-   < ((UINT4)inputLen << 3))
- context->count[1]++;
-  context->count[1] += ((UINT4)inputLen >> 29);
-
-  partLen = 64 - index;
-
-  /* Transform as many times as possible.
-*/
-  if (inputLen >= partLen) {
- memcpy
-   ((POINTER)&context->buffer[index], (POINTER)input, partLen);
- MD5Transform (context->state, context->buffer);
-
- for (i = partLen; i + 63 < inputLen; i += 64)
-   MD5Transform (context->state, &input[i]);
-
- index = 0;
-  }
-  else
- i = 0;
-
-  /* Buffer remaining input */
-  memcpy
- ((POINTER)&context->buffer[index], (POINTER)&input[i],
-  inputLen-i);
-}
+/* Append a string to the message. */
+void md5_append(md5_state_t *pms, const md5_byte_t *data, int nbytes);
 
-/* MD5 finalization. Ends an MD5 message-digest operation, writing the
-  the message digest and zeroizing the context.
- */
-static void MD5Final (digest, context)
-unsigned char digest[16];                         /* message digest */
-MD5_CTX *context;                                       /* context */
-{
-  unsigned char bits[8];
-  unsigned int index, padLen;
+/* Finish the message and return the digest. */
+void md5_finish(md5_state_t *pms, md5_byte_t digest[16]);
 
-  /* Save number of bits */
-  Encode (bits, context->count, 8);
+#ifdef __cplusplus
+}  /* end extern "C" */
+#endif
 
-  /* Pad out to 56 mod 64.
-*/
-  index = (unsigned int)((context->count[0] >> 3) & 0x3f);
-  padLen = (index < 56) ? (56 - index) : (120 - index);
-  MD5Update (context, PADDING, padLen);
-
-  /* Append length (before padding) */
-  MD5Update (context, bits, 8);
-  /* Store state in digest */
-  Encode (digest, context->state, 16);
-
-  /* Zeroize sensitive information.
-*/
-  memset ((POINTER)context, 0, sizeof (*context));
-}
+#endif /* md5_INCLUDED */
+/*======== End of L. Peter Deutsch's md5.h ========*/
 
-/* MD5 basic transformation. Transforms state based on block.
- */
-static void MD5Transform (state, block)
-UINT4 state[4];
-unsigned char block[64];
-{
-  UINT4 a = state[0], b = state[1], c = state[2], d = state[3], x[16];
+/*======== Beginning of L. Peter Deutsch's md5.c (with the line ========
+  ======== [#include "md5.h"] removed)                          ========*/
+/*
+  Copyright (C) 1999, 2000, 2002 Aladdin Enterprises.  All rights reserved.
 
-  Decode (x, block, 64);
+  This software is provided 'as-is', without any express or implied
+  warranty.  In no event will the authors be held liable for any damages
+  arising from the use of this software.
 
-  /* Round 1 */
-  FF (a, b, c, d, x[ 0], S11, 0xd76aa478); /* 1 */
-  FF (d, a, b, c, x[ 1], S12, 0xe8c7b756); /* 2 */
-  FF (c, d, a, b, x[ 2], S13, 0x242070db); /* 3 */
-  FF (b, c, d, a, x[ 3], S14, 0xc1bdceee); /* 4 */
-  FF (a, b, c, d, x[ 4], S11, 0xf57c0faf); /* 5 */
-  FF (d, a, b, c, x[ 5], S12, 0x4787c62a); /* 6 */
-  FF (c, d, a, b, x[ 6], S13, 0xa8304613); /* 7 */
-  FF (b, c, d, a, x[ 7], S14, 0xfd469501); /* 8 */
-  FF (a, b, c, d, x[ 8], S11, 0x698098d8); /* 9 */
-  FF (d, a, b, c, x[ 9], S12, 0x8b44f7af); /* 10 */
-  FF (c, d, a, b, x[10], S13, 0xffff5bb1); /* 11 */
-  FF (b, c, d, a, x[11], S14, 0x895cd7be); /* 12 */
-  FF (a, b, c, d, x[12], S11, 0x6b901122); /* 13 */
-  FF (d, a, b, c, x[13], S12, 0xfd987193); /* 14 */
-  FF (c, d, a, b, x[14], S13, 0xa679438e); /* 15 */
-  FF (b, c, d, a, x[15], S14, 0x49b40821); /* 16 */
-
- /* Round 2 */
-  GG (a, b, c, d, x[ 1], S21, 0xf61e2562); /* 17 */
-  GG (d, a, b, c, x[ 6], S22, 0xc040b340); /* 18 */
-  GG (c, d, a, b, x[11], S23, 0x265e5a51); /* 19 */
-  GG (b, c, d, a, x[ 0], S24, 0xe9b6c7aa); /* 20 */
-  GG (a, b, c, d, x[ 5], S21, 0xd62f105d); /* 21 */
-  GG (d, a, b, c, x[10], S22,  0x2441453); /* 22 */
-  GG (c, d, a, b, x[15], S23, 0xd8a1e681); /* 23 */
-  GG (b, c, d, a, x[ 4], S24, 0xe7d3fbc8); /* 24 */
-  GG (a, b, c, d, x[ 9], S21, 0x21e1cde6); /* 25 */
-  GG (d, a, b, c, x[14], S22, 0xc33707d6); /* 26 */
-  GG (c, d, a, b, x[ 3], S23, 0xf4d50d87); /* 27 */
-  GG (b, c, d, a, x[ 8], S24, 0x455a14ed); /* 28 */
-  GG (a, b, c, d, x[13], S21, 0xa9e3e905); /* 29 */
-  GG (d, a, b, c, x[ 2], S22, 0xfcefa3f8); /* 30 */
-  GG (c, d, a, b, x[ 7], S23, 0x676f02d9); /* 31 */
-  GG (b, c, d, a, x[12], S24, 0x8d2a4c8a); /* 32 */
-
-  /* Round 3 */
-  HH (a, b, c, d, x[ 5], S31, 0xfffa3942); /* 33 */
-  HH (d, a, b, c, x[ 8], S32, 0x8771f681); /* 34 */
-  HH (c, d, a, b, x[11], S33, 0x6d9d6122); /* 35 */
-  HH (b, c, d, a, x[14], S34, 0xfde5380c); /* 36 */
-  HH (a, b, c, d, x[ 1], S31, 0xa4beea44); /* 37 */
-  HH (d, a, b, c, x[ 4], S32, 0x4bdecfa9); /* 38 */
-  HH (c, d, a, b, x[ 7], S33, 0xf6bb4b60); /* 39 */
-  HH (b, c, d, a, x[10], S34, 0xbebfbc70); /* 40 */
-  HH (a, b, c, d, x[13], S31, 0x289b7ec6); /* 41 */
-  HH (d, a, b, c, x[ 0], S32, 0xeaa127fa); /* 42 */
-  HH (c, d, a, b, x[ 3], S33, 0xd4ef3085); /* 43 */
-  HH (b, c, d, a, x[ 6], S34,  0x4881d05); /* 44 */
-  HH (a, b, c, d, x[ 9], S31, 0xd9d4d039); /* 45 */
-  HH (d, a, b, c, x[12], S32, 0xe6db99e5); /* 46 */
-  HH (c, d, a, b, x[15], S33, 0x1fa27cf8); /* 47 */
-  HH (b, c, d, a, x[ 2], S34, 0xc4ac5665); /* 48 */
-
-  /* Round 4 */
-  II (a, b, c, d, x[ 0], S41, 0xf4292244); /* 49 */
-  II (d, a, b, c, x[ 7], S42, 0x432aff97); /* 50 */
-  II (c, d, a, b, x[14], S43, 0xab9423a7); /* 51 */
-  II (b, c, d, a, x[ 5], S44, 0xfc93a039); /* 52 */
-  II (a, b, c, d, x[12], S41, 0x655b59c3); /* 53 */
-  II (d, a, b, c, x[ 3], S42, 0x8f0ccc92); /* 54 */
-  II (c, d, a, b, x[10], S43, 0xffeff47d); /* 55 */
-  II (b, c, d, a, x[ 1], S44, 0x85845dd1); /* 56 */
-  II (a, b, c, d, x[ 8], S41, 0x6fa87e4f); /* 57 */
-  II (d, a, b, c, x[15], S42, 0xfe2ce6e0); /* 58 */
-  II (c, d, a, b, x[ 6], S43, 0xa3014314); /* 59 */
-  II (b, c, d, a, x[13], S44, 0x4e0811a1); /* 60 */
-  II (a, b, c, d, x[ 4], S41, 0xf7537e82); /* 61 */
-  II (d, a, b, c, x[11], S42, 0xbd3af235); /* 62 */
-  II (c, d, a, b, x[ 2], S43, 0x2ad7d2bb); /* 63 */
-  II (b, c, d, a, x[ 9], S44, 0xeb86d391); /* 64 */
-
-  state[0] += a;
-  state[1] += b;
-  state[2] += c;
-  state[3] += d;
-
-  /* Zeroize sensitive information.
-*/
-  memset ((POINTER)x, 0, sizeof (x));
-}
+  Permission is granted to anyone to use this software for any purpose,
+  including commercial applications, and to alter it and redistribute it
+  freely, subject to the following restrictions:
 
-/* Encodes input (UINT4) into output (unsigned char). Assumes len is
-  a multiple of 4.
- */
-static void Encode (output, input, len)
-unsigned char *output;
-UINT4 *input;
-unsigned int len;
-{
-  unsigned int i, j;
+  1. The origin of this software must not be misrepresented; you must not
+     claim that you wrote the original software. If you use this software
+     in a product, an acknowledgment in the product documentation would be
+     appreciated but is not required.
+  2. Altered source versions must be plainly marked as such, and must not be
+     misrepresented as being the original software.
+  3. This notice may not be removed or altered from any source distribution.
 
-  for (i = 0, j = 0; j < len; i++, j += 4) {
- output[j] = (unsigned char)(input[i] & 0xff);
- output[j+1] = (unsigned char)((input[i] >> 8) & 0xff);
- output[j+2] = (unsigned char)((input[i] >> 16) & 0xff);
- output[j+3] = (unsigned char)((input[i] >> 24) & 0xff);
-  }
-}
+  L. Peter Deutsch
+  ghost@aladdin.com
 
-/* Decodes input (unsigned char) into output (UINT4). Assumes len is
-  a multiple of 4.
  */
-static void Decode (output, input, len)
-UINT4 *output;
-unsigned char *input;
-unsigned int len;
-{
-  unsigned int i, j;
+/* $Id: md5.c,v 1.6 2002/04/13 19:20:28 lpd Exp $ */
+/*
+  Independent implementation of MD5 (RFC 1321).
 
-  for (i = 0, j = 0; j < len; i++, j += 4)
- output[i] = ((UINT4)input[j]) | (((UINT4)input[j+1]) << 8) |
-   (((UINT4)input[j+2]) << 16) | (((UINT4)input[j+3]) << 24);
-}
+  This code implements the MD5 Algorithm defined in RFC 1321, whose
+  text is available at
+       http://www.ietf.org/rfc/rfc1321.txt
+  The code is derived from the text of the RFC, including the test suite
+  (section A.5) but excluding the rest of Appendix A.  It does not include
+  any code or documentation that is identified in the RFC as being
+  copyrighted.
+
+  The original and principal author of md5.c is L. Peter Deutsch
+  <ghost@aladdin.com>.  Other authors are noted in the change history
+  that follows (in reverse chronological order):
+
+  2002-04-13 lpd Clarified derivation from RFC 1321; now handles byte order
+       either statically or dynamically; added missing #include <string.h>
+       in library.
+  2002-03-11 lpd Corrected argument list for main(), and added int return
+       type, in test program and T value program.
+  2002-02-21 lpd Added missing #include <stdio.h> in test program.
+  2000-07-03 lpd Patched to eliminate warnings about "constant is
+       unsigned in ANSI C, signed in traditional"; made test program
+       self-checking.
+  1999-11-04 lpd Edited comments slightly for automatic TOC extraction.
+  1999-10-18 lpd Fixed typo in header comment (ansi2knr rather than md5).
+  1999-05-03 lpd Original version.
+ */
 
-/*======== End of md5c.c ========*/
+#include <string.h>
+
+#undef BYTE_ORDER      /* 1 = big-endian, -1 = little-endian, 0 = unknown */
+#ifdef ARCH_IS_BIG_ENDIAN
+#  define BYTE_ORDER (ARCH_IS_BIG_ENDIAN ? 1 : -1)
+#else
+#  define BYTE_ORDER 0
+#endif
+
+#define T_MASK ((md5_word_t)~0)
+#define T1 /* 0xd76aa478 */ (T_MASK ^ 0x28955b87)
+#define T2 /* 0xe8c7b756 */ (T_MASK ^ 0x173848a9)
+#define T3    0x242070db
+#define T4 /* 0xc1bdceee */ (T_MASK ^ 0x3e423111)
+#define T5 /* 0xf57c0faf */ (T_MASK ^ 0x0a83f050)
+#define T6    0x4787c62a
+#define T7 /* 0xa8304613 */ (T_MASK ^ 0x57cfb9ec)
+#define T8 /* 0xfd469501 */ (T_MASK ^ 0x02b96afe)
+#define T9    0x698098d8
+#define T10 /* 0x8b44f7af */ (T_MASK ^ 0x74bb0850)
+#define T11 /* 0xffff5bb1 */ (T_MASK ^ 0x0000a44e)
+#define T12 /* 0x895cd7be */ (T_MASK ^ 0x76a32841)
+#define T13    0x6b901122
+#define T14 /* 0xfd987193 */ (T_MASK ^ 0x02678e6c)
+#define T15 /* 0xa679438e */ (T_MASK ^ 0x5986bc71)
+#define T16    0x49b40821
+#define T17 /* 0xf61e2562 */ (T_MASK ^ 0x09e1da9d)
+#define T18 /* 0xc040b340 */ (T_MASK ^ 0x3fbf4cbf)
+#define T19    0x265e5a51
+#define T20 /* 0xe9b6c7aa */ (T_MASK ^ 0x16493855)
+#define T21 /* 0xd62f105d */ (T_MASK ^ 0x29d0efa2)
+#define T22    0x02441453
+#define T23 /* 0xd8a1e681 */ (T_MASK ^ 0x275e197e)
+#define T24 /* 0xe7d3fbc8 */ (T_MASK ^ 0x182c0437)
+#define T25    0x21e1cde6
+#define T26 /* 0xc33707d6 */ (T_MASK ^ 0x3cc8f829)
+#define T27 /* 0xf4d50d87 */ (T_MASK ^ 0x0b2af278)
+#define T28    0x455a14ed
+#define T29 /* 0xa9e3e905 */ (T_MASK ^ 0x561c16fa)
+#define T30 /* 0xfcefa3f8 */ (T_MASK ^ 0x03105c07)
+#define T31    0x676f02d9
+#define T32 /* 0x8d2a4c8a */ (T_MASK ^ 0x72d5b375)
+#define T33 /* 0xfffa3942 */ (T_MASK ^ 0x0005c6bd)
+#define T34 /* 0x8771f681 */ (T_MASK ^ 0x788e097e)
+#define T35    0x6d9d6122
+#define T36 /* 0xfde5380c */ (T_MASK ^ 0x021ac7f3)
+#define T37 /* 0xa4beea44 */ (T_MASK ^ 0x5b4115bb)
+#define T38    0x4bdecfa9
+#define T39 /* 0xf6bb4b60 */ (T_MASK ^ 0x0944b49f)
+#define T40 /* 0xbebfbc70 */ (T_MASK ^ 0x4140438f)
+#define T41    0x289b7ec6
+#define T42 /* 0xeaa127fa */ (T_MASK ^ 0x155ed805)
+#define T43 /* 0xd4ef3085 */ (T_MASK ^ 0x2b10cf7a)
+#define T44    0x04881d05
+#define T45 /* 0xd9d4d039 */ (T_MASK ^ 0x262b2fc6)
+#define T46 /* 0xe6db99e5 */ (T_MASK ^ 0x1924661a)
+#define T47    0x1fa27cf8
+#define T48 /* 0xc4ac5665 */ (T_MASK ^ 0x3b53a99a)
+#define T49 /* 0xf4292244 */ (T_MASK ^ 0x0bd6ddbb)
+#define T50    0x432aff97
+#define T51 /* 0xab9423a7 */ (T_MASK ^ 0x546bdc58)
+#define T52 /* 0xfc93a039 */ (T_MASK ^ 0x036c5fc6)
+#define T53    0x655b59c3
+#define T54 /* 0x8f0ccc92 */ (T_MASK ^ 0x70f3336d)
+#define T55 /* 0xffeff47d */ (T_MASK ^ 0x00100b82)
+#define T56 /* 0x85845dd1 */ (T_MASK ^ 0x7a7ba22e)
+#define T57    0x6fa87e4f
+#define T58 /* 0xfe2ce6e0 */ (T_MASK ^ 0x01d3191f)
+#define T59 /* 0xa3014314 */ (T_MASK ^ 0x5cfebceb)
+#define T60    0x4e0811a1
+#define T61 /* 0xf7537e82 */ (T_MASK ^ 0x08ac817d)
+#define T62 /* 0xbd3af235 */ (T_MASK ^ 0x42c50dca)
+#define T63    0x2ad7d2bb
+#define T64 /* 0xeb86d391 */ (T_MASK ^ 0x14792c6e)
+
+
+static void
+md5_process(md5_state_t *pms, const md5_byte_t *data /*[64]*/)
+{
+    md5_word_t
+       a = pms->abcd[0], b = pms->abcd[1],
+       c = pms->abcd[2], d = pms->abcd[3];
+    md5_word_t t;
+#if BYTE_ORDER > 0
+    /* Define storage only for big-endian CPUs. */
+    md5_word_t X[16];
+#else
+    /* Define storage for little-endian or both types of CPUs. */
+    md5_word_t xbuf[16];
+    const md5_word_t *X;
+#endif
+
+    {
+#if BYTE_ORDER == 0
+       /*
+        * Determine dynamically whether this is a big-endian or
+        * little-endian machine, since we can use a more efficient
+        * algorithm on the latter.
+        */
+       static const int w = 1;
+
+       if (*((const md5_byte_t *)&w)) /* dynamic little-endian */
+#endif
+#if BYTE_ORDER <= 0            /* little-endian */
+       {
+           /*
+            * On little-endian machines, we can process properly aligned
+            * data without copying it.
+            */
+           if (!((data - (const md5_byte_t *)0) & 3)) {
+               /* data are properly aligned */
+               X = (const md5_word_t *)data;
+           } else {
+               /* not aligned */
+               memcpy(xbuf, data, 64);
+               X = xbuf;
+           }
+       }
+#endif
+#if BYTE_ORDER == 0
+       else                    /* dynamic big-endian */
+#endif
+#if BYTE_ORDER >= 0            /* big-endian */
+       {
+           /*
+            * On big-endian machines, we must arrange the bytes in the
+            * right order.
+            */
+           const md5_byte_t *xp = data;
+           int i;
+
+#  if BYTE_ORDER == 0
+           X = xbuf;           /* (dynamic only) */
+#  else
+#    define xbuf X             /* (static only) */
+#  endif
+           for (i = 0; i < 16; ++i, xp += 4)
+               xbuf[i] = xp[0] + (xp[1] << 8) + (xp[2] << 16) + (xp[3] << 24);
+       }
+#endif
+    }
+
+#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32 - (n))))
+
+    /* Round 1. */
+    /* Let [abcd k s i] denote the operation
+       a = b + ((a + F(b,c,d) + X[k] + T[i]) <<< s). */
+#define F(x, y, z) (((x) & (y)) | (~(x) & (z)))
+#define SET(a, b, c, d, k, s, Ti)\
+  t = a + F(b,c,d) + X[k] + Ti;\
+  a = ROTATE_LEFT(t, s) + b
+    /* Do the following 16 operations. */
+    SET(a, b, c, d,  0,  7,  T1);
+    SET(d, a, b, c,  1, 12,  T2);
+    SET(c, d, a, b,  2, 17,  T3);
+    SET(b, c, d, a,  3, 22,  T4);
+    SET(a, b, c, d,  4,  7,  T5);
+    SET(d, a, b, c,  5, 12,  T6);
+    SET(c, d, a, b,  6, 17,  T7);
+    SET(b, c, d, a,  7, 22,  T8);
+    SET(a, b, c, d,  8,  7,  T9);
+    SET(d, a, b, c,  9, 12, T10);
+    SET(c, d, a, b, 10, 17, T11);
+    SET(b, c, d, a, 11, 22, T12);
+    SET(a, b, c, d, 12,  7, T13);
+    SET(d, a, b, c, 13, 12, T14);
+    SET(c, d, a, b, 14, 17, T15);
+    SET(b, c, d, a, 15, 22, T16);
+#undef SET
+
+     /* Round 2. */
+     /* Let [abcd k s i] denote the operation
+          a = b + ((a + G(b,c,d) + X[k] + T[i]) <<< s). */
+#define G(x, y, z) (((x) & (z)) | ((y) & ~(z)))
+#define SET(a, b, c, d, k, s, Ti)\
+  t = a + G(b,c,d) + X[k] + Ti;\
+  a = ROTATE_LEFT(t, s) + b
+     /* Do the following 16 operations. */
+    SET(a, b, c, d,  1,  5, T17);
+    SET(d, a, b, c,  6,  9, T18);
+    SET(c, d, a, b, 11, 14, T19);
+    SET(b, c, d, a,  0, 20, T20);
+    SET(a, b, c, d,  5,  5, T21);
+    SET(d, a, b, c, 10,  9, T22);
+    SET(c, d, a, b, 15, 14, T23);
+    SET(b, c, d, a,  4, 20, T24);
+    SET(a, b, c, d,  9,  5, T25);
+    SET(d, a, b, c, 14,  9, T26);
+    SET(c, d, a, b,  3, 14, T27);
+    SET(b, c, d, a,  8, 20, T28);
+    SET(a, b, c, d, 13,  5, T29);
+    SET(d, a, b, c,  2,  9, T30);
+    SET(c, d, a, b,  7, 14, T31);
+    SET(b, c, d, a, 12, 20, T32);
+#undef SET
+
+     /* Round 3. */
+     /* Let [abcd k s t] denote the operation
+          a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
+#define H(x, y, z) ((x) ^ (y) ^ (z))
+#define SET(a, b, c, d, k, s, Ti)\
+  t = a + H(b,c,d) + X[k] + Ti;\
+  a = ROTATE_LEFT(t, s) + b
+     /* Do the following 16 operations. */
+    SET(a, b, c, d,  5,  4, T33);
+    SET(d, a, b, c,  8, 11, T34);
+    SET(c, d, a, b, 11, 16, T35);
+    SET(b, c, d, a, 14, 23, T36);
+    SET(a, b, c, d,  1,  4, T37);
+    SET(d, a, b, c,  4, 11, T38);
+    SET(c, d, a, b,  7, 16, T39);
+    SET(b, c, d, a, 10, 23, T40);
+    SET(a, b, c, d, 13,  4, T41);
+    SET(d, a, b, c,  0, 11, T42);
+    SET(c, d, a, b,  3, 16, T43);
+    SET(b, c, d, a,  6, 23, T44);
+    SET(a, b, c, d,  9,  4, T45);
+    SET(d, a, b, c, 12, 11, T46);
+    SET(c, d, a, b, 15, 16, T47);
+    SET(b, c, d, a,  2, 23, T48);
+#undef SET
+
+     /* Round 4. */
+     /* Let [abcd k s t] denote the operation
+          a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */
+#define I(x, y, z) ((y) ^ ((x) | ~(z)))
+#define SET(a, b, c, d, k, s, Ti)\
+  t = a + I(b,c,d) + X[k] + Ti;\
+  a = ROTATE_LEFT(t, s) + b
+     /* Do the following 16 operations. */
+    SET(a, b, c, d,  0,  6, T49);
+    SET(d, a, b, c,  7, 10, T50);
+    SET(c, d, a, b, 14, 15, T51);
+    SET(b, c, d, a,  5, 21, T52);
+    SET(a, b, c, d, 12,  6, T53);
+    SET(d, a, b, c,  3, 10, T54);
+    SET(c, d, a, b, 10, 15, T55);
+    SET(b, c, d, a,  1, 21, T56);
+    SET(a, b, c, d,  8,  6, T57);
+    SET(d, a, b, c, 15, 10, T58);
+    SET(c, d, a, b,  6, 15, T59);
+    SET(b, c, d, a, 13, 21, T60);
+    SET(a, b, c, d,  4,  6, T61);
+    SET(d, a, b, c, 11, 10, T62);
+    SET(c, d, a, b,  2, 15, T63);
+    SET(b, c, d, a,  9, 21, T64);
+#undef SET
+
+     /* Then perform the following additions. (That is increment each
+        of the four registers by the value it had before this block
+        was started.) */
+    pms->abcd[0] += a;
+    pms->abcd[1] += b;
+    pms->abcd[2] += c;
+    pms->abcd[3] += d;
+}
+
+void
+md5_init(md5_state_t *pms)
+{
+    pms->count[0] = pms->count[1] = 0;
+    pms->abcd[0] = 0x67452301;
+    pms->abcd[1] = /*0xefcdab89*/ T_MASK ^ 0x10325476;
+    pms->abcd[2] = /*0x98badcfe*/ T_MASK ^ 0x67452301;
+    pms->abcd[3] = 0x10325476;
+}
+
+void
+md5_append(md5_state_t *pms, const md5_byte_t *data, int nbytes)
+{
+    const md5_byte_t *p = data;
+    int left = nbytes;
+    int offset = (pms->count[0] >> 3) & 63;
+    md5_word_t nbits = (md5_word_t)(nbytes << 3);
+
+    if (nbytes <= 0)
+       return;
+
+    /* Update the message length. */
+    pms->count[1] += nbytes >> 29;
+    pms->count[0] += nbits;
+    if (pms->count[0] < nbits)
+       pms->count[1]++;
+
+    /* Process an initial partial block. */
+    if (offset) {
+       int copy = (offset + nbytes > 64 ? 64 - offset : nbytes);
+
+       memcpy(pms->buf + offset, p, copy);
+       if (offset + copy < 64)
+           return;
+       p += copy;
+       left -= copy;
+       md5_process(pms, pms->buf);
+    }
+
+    /* Process full blocks. */
+    for (; left >= 64; p += 64, left -= 64)
+       md5_process(pms, p);
+
+    /* Process a final partial block. */
+    if (left)
+       memcpy(pms->buf, p, left);
+}
+
+void
+md5_finish(md5_state_t *pms, md5_byte_t digest[16])
+{
+    static const md5_byte_t pad[64] = {
+       0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+    };
+    md5_byte_t data[8];
+    int i;
+
+    /* Save the length before padding. */
+    for (i = 0; i < 8; ++i)
+       data[i] = (md5_byte_t)(pms->count[i >> 2] >> ((i & 3) << 3));
+    /* Pad to 56 bytes mod 64. */
+    md5_append(pms, pad, ((55 - (pms->count[0] >> 3)) & 63) + 1);
+    /* Append the length. */
+    md5_append(pms, data, 8);
+    for (i = 0; i < 16; ++i)
+       digest[i] = (md5_byte_t)(pms->abcd[i >> 2] >> ((i & 3) << 3));
+}
+/*======== End of L. Peter Deutsch's md5.c ========*/
 /*************************************************************************/
 /*************************************************************************/
 
@@ -347,13 +508,13 @@
 
 static int md5_encrypt(const char *src, int len, char *dest, int size)
 {
-    MD5_CTX context;
+    md5_state_t context;
 
     if (size < 16)
         return 16;
-    MD5Init(&context);
-    MD5Update(&context, (unsigned char *)src, len);
-    MD5Final((unsigned char *)dest, &context);
+    md5_init(&context);
+    md5_append(&context, (unsigned char *)src, len);
+    md5_finish(&context, (unsigned char *)dest);
     return 0;
 }
 
From bender_54 at msn.com  Thu May 17 01:07:12 2007
From: bender_54 at msn.com (Nick Bent)
Date: Thu May 17 01:07:16 2007
Subject: [IRCServices Coding] RE: IRCServices-Coding Digest, Vol 33, Issue 1
Message-ID: <BAY115-W187D4F1BEA5BC303C569D181330@phx.gbl>

Skipped content of type multipart/alternative-------------- next part --------------
> Message: 6
> Date: Tue, 17 Apr 2007 15:53:22 JST
> From: achurch@achurch.org (Andrew Church)
> Subject: Re: [IRCServices Coding] Feature Suggestions
> To: ircservices-coding@ircservices.za.net
> Message-ID: <4624733c.06344@msgid.achurch.org>
> Content-Type: text/plain; charset=ISO-2022-JP
> 
> To the original poster: Don't use HTML mail on this list.
> 
> >> 1. /ns set autoop [on|off] - Just like Anope
> >
> >If this is what I think it is, which is that the nick in question
> >won't be auto-opped on any channel (next time please elaborate on what
> >Anope does), I believe that Andrew may have been considering this at
> >one point (I think it was in one of the TODO lists). That being said,
> >I haven't seen this in 5.1, so it may have been dropped or thrown out.
> 
> I've never seen the point to this option (if you don't want auto-ops,
> don't have people give you auto-op access), so I won't be adding it.

You can't stop people from giving you access. This is an attitude thing,
where a user has chosen to only give themselves staus when they need it.

> 
> >> 6. When someone does /cs info #channel, and it shows the mode lock, make it
> >> show the locked mode paramaters too.
> >
> >Bad idea. I'm sure that no-one wants to see their channel key
> >displayed in this manner. :)
> 
> Exactly. As for other modes, just look at the channel's current mode
> set, which will naturally be the same as what's set in the mode lock.
> 
> --Andrew Church

Perhaps show parameters for all modes but k? Using one command instead of two to 
see the full mode lock would be nice.

Nick
From ron2k.za at gmail.com  Thu May 17 01:14:48 2007
From: ron2k.za at gmail.com (Kieron Thwaites)
Date: Thu May 17 01:14:52 2007
Subject: [IRCServices Coding] RE: IRCServices-Coding Digest, Vol 33,
        Issue 1
In-Reply-To: <BAY115-W187D4F1BEA5BC303C569D181330@phx.gbl>
References: <BAY115-W187D4F1BEA5BC303C569D181330@phx.gbl>
Message-ID: <debb3bc0705170114p799455f2gac77808b854103cc@mail.gmail.com>

OK, why the text file? It makes your message rather inconvenient to
read. Either that, or I'm just lazy. :)

Now to respond to your points.

1. I'm in agreement with Andrew. If you don't want access, tell
whoever is controlling the channel not to give you access, or write a
script in your client (if your client supports it) to remove said
access.

If you want this functionality to be in Services, feel free to write a
module that does this. :)

2. In my opinion, totally unnecessary.

--K

On 17/05/07, Nick Bent <bender_54@msn.com> wrote:
> .txt file attached
> ________________________________
> Invite your mail contacts to join your friends list with Windows Live
> Spaces. It's easy! Try it!
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>
From surreal.w00t at gmail.com  Thu May 17 03:53:56 2007
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu May 17 03:54:02 2007
Subject: [IRCServices Coding] RE: IRCServices-Coding Digest, Vol 33,
        Issue 1
In-Reply-To: <debb3bc0705170114p799455f2gac77808b854103cc@mail.gmail.com>
References: <BAY115-W187D4F1BEA5BC303C569D181330@phx.gbl>
        <debb3bc0705170114p799455f2gac77808b854103cc@mail.gmail.com>
Message-ID: <b19eae4e0705170353w7e21e997sc22961481f80e170@mail.gmail.com>

Is it actually possible to remove your own access (vop, whatever) from
a channel? If not, that might be something to think about instead.

On 5/17/07, Kieron Thwaites <ron2k.za@gmail.com> wrote:
> OK, why the text file? It makes your message rather inconvenient to
> read. Either that, or I'm just lazy. :)
>
> Now to respond to your points.
>
> 1. I'm in agreement with Andrew. If you don't want access, tell
> whoever is controlling the channel not to give you access, or write a
> script in your client (if your client supports it) to remove said
> access.
>
> If you want this functionality to be in Services, feel free to write a
> module that does this. :)
>
> 2. In my opinion, totally unnecessary.
>
> --K
>
> On 17/05/07, Nick Bent <bender_54@msn.com> wrote:
> > .txt file attached
> > ________________________________
> > Invite your mail contacts to join your friends list with Windows Live
> > Spaces. It's easy! Try it!
> > ------------------------------------------------------------------
> > To unsubscribe or change your subscription options, visit:
> > http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> >
> >
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
From tim at retout.co.uk  Thu May 17 05:50:40 2007
From: tim at retout.co.uk (Tim Retout)
Date: Thu May 17 05:52:12 2007
Subject: [IRCServices Coding] Debian packages
In-Reply-To: <464b5efb.10707@msgid.achurch.org>
References: <464b5efb.10707@msgid.achurch.org>
Message-ID: <1179406240.3796.20.camel@regulus.retout.co.uk>

On Thu, 2007-05-17 at 04:42 +0000, Andrew Church wrote:
> >I notice that binary Debian packages are available for i386 from your
> >website - but would it be helpful if I packaged ircservices and
> >submitted it to the main Debian archive? This would make it even easier
> >for Debian users like myself to use your software, especially if they
> >are using a different architecture.
> 
>      If you'd be willing to do that, I'd certainly appreciate it!  Please
> let me know if there are any issues regarding packaging (such as file
> layout), and I'll see if I can resolve them.

I have filed an ITP: http://bugs.debian.org/424844

It would be nice to update support for ircd-irc2 and ircd-ircu, both of
which appear to use newer server protocols these days.

-- 
Tim Retout <tim@retout.co.uk>

From omster at gmail.com  Thu May 17 06:58:12 2007
From: omster at gmail.com (Om)
Date: Thu May 17 06:58:33 2007
Subject: [IRCServices Coding] RE: IRCServices-Coding Digest, Vol 33, Issue
        1
In-Reply-To: <b19eae4e0705170353w7e21e997sc22961481f80e170@mail.gmail.com>
References: <BAY115-W187D4F1BEA5BC303C569D181330@phx.gbl>       <debb3bc0705170114p799455f2gac77808b854103cc@mail.gmail.com>
        <b19eae4e0705170353w7e21e997sc22961481f80e170@mail.gmail.com>
Message-ID: <464C5F74.7060108@gmail.com>

Robin Burchell wrote:
> Is it actually possible to remove your own access (vop, whatever) from
> a channel? If not, that might be something to think about instead.

As long as it doesn't let you remove a negative access level ;p
From achurch at achurch.org  Fri May 18 01:23:34 2007
From: achurch at achurch.org (Andrew Church)
Date: Thu May 17 09:25:07 2007
Subject: [IRCServices Coding] Debian packages
In-Reply-To: <1179406240.3796.20.camel@regulus.retout.co.uk>
Message-ID: <464c81de.46627@msgid.achurch.org>

>I have filed an ITP: http://bugs.debian.org/424844
>
>It would be nice to update support for ircd-irc2 and ircd-ircu, both of
>which appear to use newer server protocols these days.

     I'll take a look and see if it's feasible (my recollection at least
as far as ircu is concerned is that P10 was missing some critical features
that made it incompatible with Services) Do you know where documentation
on the protocols used by these servers can be found?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Fri May 18 01:29:39 2007
From: achurch at achurch.org (Andrew Church)
Date: Thu May 17 09:31:36 2007
Subject: [IRCServices Coding] RE: IRCServices-Coding Digest, Vol 33,
        Issue 1
In-Reply-To: <b19eae4e0705170353w7e21e997sc22961481f80e170@mail.gmail.com>
Message-ID: <464c8366.46635@msgid.achurch.org>

>Is it actually possible to remove your own access (vop, whatever) from
>a channel? If not, that might be something to think about instead.

     I couldn't read the original message, but this looks like something
worth thinking about.  I'll consider it.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From tim at retout.co.uk  Fri May 18 00:46:09 2007
From: tim at retout.co.uk (Tim Retout)
Date: Fri May 18 00:47:35 2007
Subject: [IRCServices Coding] md5 licensing
In-Reply-To: <464b6285.20022@msgid.achurch.org>
References: <464b6285.20022@msgid.achurch.org>
Message-ID: <1179474369.4232.7.camel@regulus.retout.co.uk>

On Thu, 2007-05-17 at 04:48 +0000, Andrew Church wrote:
> >Please review this patch (against 5.1pre1) to port the md5 code to an
> >implementation licensed under a revised-BSD-style licence, found at:
> >http://sourceforge.net/project/showfiles.php?group_id=42360
> 
>      Thanks for pointing this out.  I've applied the patch below to
> 5.1pre1; let me know if you see any problems.

The docs/Changes hunk didn't apply for me, but that's trivial. The code
passes my brief, brief testing. :)

Thanks,

-- 
Tim Retout <tim@retout.co.uk>

From tim at retout.co.uk  Fri May 18 01:58:01 2007
From: tim at retout.co.uk (Tim Retout)
Date: Fri May 18 01:59:24 2007
Subject: [IRCServices Coding] Debian packages
In-Reply-To: <464c81de.46627@msgid.achurch.org>
References: <464c81de.46627@msgid.achurch.org>
Message-ID: <1179478681.4232.15.camel@regulus.retout.co.uk>

On Fri, 2007-05-18 at 01:23 +0000, Andrew Church wrote:
> >I have filed an ITP: http://bugs.debian.org/424844
> >
> >It would be nice to update support for ircd-irc2 and ircd-ircu, both of
> >which appear to use newer server protocols these days.
> 
>      I'll take a look and see if it's feasible (my recollection at least
> as far as ircu is concerned is that P10 was missing some critical features
> that made it incompatible with Services) Do you know where documentation
> on the protocols used by these servers can be found?

For ircu, there's:
http://web.mit.edu/klmitch/Sipb/devel/src/ircu2.10.11/doc/p10.html

ircnet's appears to have docs in the tarball:
ftp://ftp.irc.org/irc/server/irc2.11.1p1.tgz

I'll see what I can do to help with these. Meanwhile, I'll just make a
package, since I need one.

There's also been a request that I use a different name for the package,
as 'ircservices' is 'very generic'. I'm not sure what you think about
that.

-- 
Tim Retout <tim@retout.co.uk>

From achurch at achurch.org  Fri May 18 18:10:27 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri May 18 02:21:31 2007
Subject: [IRCServices Coding] Debian packages
In-Reply-To: <1179478681.4232.15.camel@regulus.retout.co.uk>
Message-ID: <464d7017.47545@msgid.achurch.org>

>>      I'll take a look and see if it's feasible (my recollection at least
>> as far as ircu is concerned is that P10 was missing some critical features
>> that made it incompatible with Services) Do you know where documentation
>> on the protocols used by these servers can be found?
>
>For ircu, there's:
>http://web.mit.edu/klmitch/Sipb/devel/src/ircu2.10.11/doc/p10.html

     Unfortunately, this is very incomplete, so I'll have to put it off
until I have the time to study the source code myself.

>ircnet's appears to have docs in the tarball:
>ftp://ftp.irc.org/irc/server/irc2.11.1p1.tgz

     I can't find any technical documentation in there aside from the
base RFCs, so this will also have to wait for a closer look at the
source code.

>There's also been a request that I use a different name for the package,
>as 'ircservices' is 'very generic'. I'm not sure what you think about
>that.

     I think I'm going to have to say no to that, since ircservices is
the official name of the package--and to be honest, as the author of the
first widely used Services package, I think I have a right to the name. :)
See e.g.: http://freshmeat.net/projects/ircservices/

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From tim at retout.co.uk  Fri Jul 13 03:18:39 2007
From: tim at retout.co.uk (Tim Retout)
Date: Fri Jul 13 03:20:58 2007
Subject: [IRCServices Coding] Build prefix/FHS compliance
Message-ID: <1184321919.6368.14.camel@regulus.retout.co.uk>

Hi! After a bit of a hiatus for DebConf, I'm catching up with my
packaging work.

I've worked out three changes that I'd like to make for Debian:

      * You may have noticed that the consensus on the Debian bug
        tracker is that I need to change the package name to something
        other than 'ircservices' to fit into the package namespace - so
        I'd like to change the binary name as well. Currently the value
        of $(PROGRAM) in the Makefile doesn't affect the pidfile or the
        ircservices-chk script.
      * I need to be able to change the build prefix independently for
        'make install' - i.e. as if installing into a chroot. I could
        either add an $(INSTALL_PREFIX) variable, or possibly modify
        $(PREFIX) in a backwards-compatible way.
      * The default locations of the installed files will need modifying
        to fit into the Filesystem Hierarchy Standard. This will be the
        most complicated patch, I expect.

I realise this is at a really bad time in your release process, so if I
don't get all of these done in time, I can maintain patches against the
released version.

Thanks,

-- 
Tim Retout <tim@retout.co.uk>

From achurch at achurch.org  Fri Jul 13 19:54:25 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Jul 13 03:59:54 2007
Subject: [IRCServices Coding] Build prefix/FHS compliance
In-Reply-To: <1184321919.6368.14.camel@regulus.retout.co.uk>
Message-ID: <46975b27.53464@msgid.achurch.org>

     Thanks for the notes.  I'm swamped with work at the moment, but I'll
definitely look into addressing the first two points for the next beta
release.

     As far as FHS compliance goes, can you make any specific suggestions?
I'm not sure how much I can do, since Services' design requires all data
under a common hierarchy, and at this point it's a bit late to go back and
change that so it works reliably with scattered files.  It may suffice in
at least some cases to use absolute rather than relative paths, though, so
let me know what changes you'd recommend and I'll see how feasable they
are.

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

>Hi! After a bit of a hiatus for DebConf, I'm catching up with my
>packaging work.
>
>I've worked out three changes that I'd like to make for Debian:
>
>      * You may have noticed that the consensus on the Debian bug
>        tracker is that I need to change the package name to something
>        other than 'ircservices' to fit into the package namespace - so
>        I'd like to change the binary name as well. Currently the value
>        of $(PROGRAM) in the Makefile doesn't affect the pidfile or the
>        ircservices-chk script.
>      * I need to be able to change the build prefix independently for
>        'make install' - i.e. as if installing into a chroot. I could
>        either add an $(INSTALL_PREFIX) variable, or possibly modify
>        $(PREFIX) in a backwards-compatible way.
>      * The default locations of the installed files will need modifying
>        to fit into the Filesystem Hierarchy Standard. This will be the
>        most complicated patch, I expect.
>
>I realise this is at a really bad time in your release process, so if I
>don't get all of these done in time, I can maintain patches against the
>released version.
>
>Thanks,
>
>-- 
>Tim Retout <tim@retout.co.uk>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From tim at retout.co.uk  Fri Jul 20 06:43:16 2007
From: tim at retout.co.uk (Tim Retout)
Date: Fri Jul 20 06:44:50 2007
Subject: [IRCServices Coding] Build prefix/FHS compliance
In-Reply-To: <46975b27.53464@msgid.achurch.org>
References: <46975b27.53464@msgid.achurch.org>
Message-ID: <1184938996.8469.15.camel@regulus.retout.co.uk>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070720/7e722ea8/attachment.pgp
From achurch at achurch.org  Sun Jul 22 23:48:53 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun Jul 22 07:50:22 2007
Subject: [IRCServices Coding] Build prefix/FHS compliance
In-Reply-To: <1184938996.8469.15.camel@regulus.retout.co.uk>
Message-ID: <46a36ea2.54537@msgid.achurch.org>

Just a note to let you know I've got the patch--thanks.  I'll take a look
at it when I have a chance.

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

>On Fri, 2007-07-13 at 19:54 +0000, Andrew Church wrote:
>> As far as FHS compliance goes, can you make any specific suggestions?
>> I'm not sure how much I can do, since Services' design requires all data
>> under a common hierarchy, and at this point it's a bit late to go back and
>> change that so it works reliably with scattered files.  It may suffice in
>> at least some cases to use absolute rather than relative paths, though, so
>> let me know what changes you'd recommend and I'll see how feasable they
>> are.
>
>Attached is a patch I'm currently using in the package - I've not
>finished testing it, but the idea is that things like modules, config
>files, language files and the helpfiles are opened only in one place, so
>are easy to relocate. Anything else can be fixed with absolute paths in
>the config files.
>
>The build system gets patched to add some configuration options to
>support this - it also implements the $(DESTDIR) prefix for the install
>target.
>
>(I'm happy to hand over whatever little copyright is in this patch.)
>
>--
>Tim Retout <tim@retout.co.uk>
From tim at retout.co.uk  Sat Jul 28 07:51:04 2007
From: tim at retout.co.uk (Tim Retout)
Date: Sat Jul 28 07:51:59 2007
Subject: [IRCServices Coding] FTBFS on amd64
Message-ID: <1185634264.12950.7.camel@regulus.retout.co.uk>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070728/dc2f45d2/attachment-0001.pgp
From tim at retout.co.uk  Sat Jul 28 07:51:03 2007
From: tim at retout.co.uk (Tim Retout)
Date: Sat Jul 28 07:52:00 2007
Subject: [IRCServices Coding] FTBFS on amd64
Message-ID: <1185634263.12950.6.camel@regulus.retout.co.uk>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070728/3b5f4e9f/attachment.pgp
From achurch at achurch.org  Sun Jul 29 23:32:00 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun Jul 29 08:08:59 2007
Subject: [IRCServices Coding] FTBFS on amd64
In-Reply-To: <1185634264.12950.7.camel@regulus.retout.co.uk>
Message-ID: <46acad80.20264@msgid.achurch.org>

Thanks for the note, but I'm going to reject most of this as unnecessary;
Services doesn't use the int*_t types for historical reasons (see section
11-1 of the technical manual), and the pointer->int conversions, while bad
practice, are known to always fit in 32 bits.  I've corrected the two
format string bits, since pointer differences and size_t could legitimately
be wider than an int.

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

>
>--===============1334927669==
>Content-Type: multipart/signed; micalg=pgp-sha1;
>       protocol="application/pgp-signature";
>       boundary="=-9UM9eTCG9p0bZ0vGzUkL"
>
>
>--=-9UM9eTCG9p0bZ0vGzUkL
>Content-Type: multipart/mixed; boundary="=-P2RArCa9ERxXvALoWALg"
>
>
>--=-P2RArCa9ERxXvALoWALg
>Content-Type: text/plain
>Content-Transfer-Encoding: quoted-printable
>
>Hi,
>
>It seems that the header <sys/types.h> does not define uint32_t on all
>architectures, so this patch uses <inttypes.h> by default instead, and
>fixes most of the build warnings.
>
>Thanks,
>
>--=20
>Tim Retout <tim@retout.co.uk>
>
>--=-P2RArCa9ERxXvALoWALg
>Content-Disposition: attachment; filename=inttypes.diff
>Content-Type: text/x-patch; name=inttypes.diff; charset=UTF-8
>Content-Transfer-Encoding: base64
>
>SW5kZXg6IGlyY3NlcnZpY2VzLWNodXJjaC01LjF+cHJlMy9kZWZzLmgNCj09PT09PT09PT09PT09
>PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0t
>LSBpcmNzZXJ2aWNlcy1jaHVyY2gtNS4xfnByZTMub3JpZy9kZWZzLmgJMjAwNy0wNy0yOCAxNTox
>NToyNy4wMDAwMDAwMDAgKzAxMDANCisrKyBpcmNzZXJ2aWNlcy1jaHVyY2gtNS4xfnByZTMvZGVm
>cy5oCTIwMDctMDctMjggMTU6MTU6MjcuMDAwMDAwMDAwICswMTAwDQpAQCAtMTM3LDcgKzEzNyw3
>IEBADQogI2luY2x1ZGUgPGVycm5vLmg+DQogI2luY2x1ZGUgPGxpbWl0cy5oPg0KICNpbmNsdWRl
>IDxtYXRoLmg+DQotI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KKyNpbmNsdWRlIDxpbnR0eXBlcy5o
>Pg0KICNpbmNsdWRlIDxzeXMvdGltZS5oPg0KIA0KICN1bmRlZiBlbmNyeXB0DQpJbmRleDogaXJj
>c2VydmljZXMtY2h1cmNoLTUuMX5wcmUzL2xhbmd1YWdlLmMNCj09PT09PT09PT09PT09PT09PT09
>PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBpcmNz
>ZXJ2aWNlcy1jaHVyY2gtNS4xfnByZTMub3JpZy9sYW5ndWFnZS5jCTIwMDctMDctMjggMTU6MTU6
>MjcuMDAwMDAwMDAwICswMTAwDQorKysgaXJjc2VydmljZXMtY2h1cmNoLTUuMX5wcmUzL2xhbmd1
>YWdlLmMJMjAwNy0wNy0yOCAxNToxNToyNy4wMDAwMDAwMDAgKzAxMDANCkBAIC0yOTAsNyArMjkw
>LDcgQEANCiAgICAgRklMRSAqZjsNCiAgICAgY2hhciBidWZbQlVGU0laRV0sICpzOw0KICAgICBj
>aGFyICoqbmV3dGV4dHNbTlVNX0xBTkdTXTsNCi0gICAgdWludDMyIG5ld3NpemVzW05VTV9MQU5H
>U107DQorICAgIHVpbnRwdHJfdCBuZXdzaXplc1tOVU1fTEFOR1NdOw0KICAgICBpbnQgaSwgY3Vy
>c3RyLCBjdXJsYW5nLCBsaW5lOw0KICAgICBpbnQgcmV0dmFsID0gMSwgZmlyc3RsaW5lID0gMTsN
>CiANCkBAIC00MTUsMTAgKzQxNSwxMCBAQA0KICAgICAgICAgICAgIG5ld3RleHRzW2N1cmxhbmdd
>WzBdID0gbmV3YnVmOw0KICAgICAgICAgICAgIGZvciAoaSA9IDA7IGkgPCBudW1fc3RyaW5nczsg
>aSsrKSB7DQogICAgICAgICAgICAgICAgIGlmIChuZXd0ZXh0c1tjdXJsYW5nXVtpKzFdKSB7DQot
>ICAgICAgICAgICAgICAgICAgICBpbnQgb2ZzID0gKGludCluZXd0ZXh0c1tjdXJsYW5nXVtpKzFd
>IC0gMTsNCisgICAgICAgICAgICAgICAgICAgIGludHB0cl90IG9mcyA9IChpbnRwdHJfdCluZXd0
>ZXh0c1tjdXJsYW5nXVtpKzFdIC0gMTsNCiAgICAgICAgICAgICAgICAgICAgIG5ld3RleHRzW2N1
>cmxhbmddW2krMV0gPSBuZXdidWYrNCArIG9sZGxlbiArIG9mczsNCiAgICAgICAgICAgICAgICAg
>fSBlbHNlIGlmIChsYW5ndGV4dHNbY3VybGFuZ11baSsxXSkgew0KLSAgICAgICAgICAgICAgICAg
>ICAgaW50IG9mcyA9IGxhbmd0ZXh0c1tjdXJsYW5nXVtpKzFdDQorICAgICAgICAgICAgICAgICAg
>ICBpbnRwdHJfdCBvZnMgPSBsYW5ndGV4dHNbY3VybGFuZ11baSsxXQ0KICAgICAgICAgICAgICAg
>ICAgICAgICAgICAgICAgIC0gbGFuZ3RleHRzW2N1cmxhbmddWzBdOw0KICAgICAgICAgICAgICAg
>ICAgICAgbmV3dGV4dHNbY3VybGFuZ11baSsxXSA9IG5ld2J1ZiArIG9mczsNCiAgICAgICAgICAg
>ICAgICAgfSBlbHNlIHsNCkluZGV4OiBpcmNzZXJ2aWNlcy1jaHVyY2gtNS4xfnByZTMvc29ja2V0
>cy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
>PT09PT09PT09PT09PT09DQotLS0gaXJjc2VydmljZXMtY2h1cmNoLTUuMX5wcmUzLm9yaWcvc29j
>a2V0cy5jCTIwMDctMDYtMTAgMTQ6MTM6MDQuMDAwMDAwMDAwICswMTAwDQorKysgaXJjc2Vydmlj
>ZXMtY2h1cmNoLTUuMX5wcmUzL3NvY2tldHMuYwkyMDA3LTA3LTI4IDE1OjM2OjQ0LjAwMDAwMDAw
>MCArMDEwMA0KQEAgLTE4MTAsOCArMTgxMCw4IEBADQogICAgIEVOVEVSKCIlcCwldSIsIHMsIHNp
>emUpOw0KICAgICBpZiAoc2l6ZSA8PSByZWFkX2J1ZmZlcl9sZW4ocykpIHsNCiAgICAgICAgIGxv
>Zygic29ja2V0czogQlVHOiByZXNpemVfcmJ1ZiglZCk6IHNpemUgKCVkKSA8PSBybGVuICglZCki
>DQotICAgICAgICAgICAgIiAoY3Vyc2l6ZSAlZCkiLCBzLT5mZCwgc2l6ZSwgcmVhZF9idWZmZXJf
>bGVuKHMpLA0KLSAgICAgICAgICAgIHMtPnJ0b3AgLSBzLT5yYnVmKTsNCisgICAgICAgICAgICAi
>IChjdXJzaXplICVsZCkiLCBzLT5mZCwgc2l6ZSwgcmVhZF9idWZmZXJfbGVuKHMpLA0KKyAgICAg
>ICAgICAgIChsb25nKShzLT5ydG9wIC0gcy0+cmJ1ZikpOw0KICAgICAgICAgUkVUVVJOX1dJVEgo
>MCk7DQogICAgIH0NCiAgICAgUkVUVVJOX1dJVEgocmVzaXplX2J1Zigmcy0+cmJ1ZiwgJnMtPnJw
>dHIsICZzLT5yZW5kLCAmcy0+cnRvcCwgc2l6ZSkpOw0KQEAgLTE4MjMsOCArMTgyMyw4IEBADQog
>ICAgIEVOVEVSKCIlcCwldSIsIHMsIHNpemUpOw0KICAgICBpZiAoc2l6ZSA8PSB3cml0ZV9idWZm
>ZXJfbGVuKHMpKSB7DQogICAgICAgICBsb2coInNvY2tldHM6IEJVRzogcmVzaXplX3didWYoJWQp
>OiBzaXplICglZCkgPD0gd2xlbiAoJWQpIg0KLSAgICAgICAgICAgICIgKGN1cnNpemUgJWQpIiwg
>cy0+ZmQsIHNpemUsIHdyaXRlX2J1ZmZlcl9sZW4ocyksDQotICAgICAgICAgICAgcy0+d3RvcCAt
>IHMtPndidWYpOw0KKyAgICAgICAgICAgICIgKGN1cnNpemUgJWxkKSIsIHMtPmZkLCBzaXplLCB3
>cml0ZV9idWZmZXJfbGVuKHMpLA0KKyAgICAgICAgICAgIChsb25nKShzLT53dG9wIC0gcy0+d2J1
>ZikpOw0KICAgICAgICAgUkVUVVJOX1dJVEgoMCk7DQogICAgIH0NCiAgICAgUkVUVVJOX1dJVEgo
>cmVzaXplX2J1Zigmcy0+d2J1ZiwgJnMtPndwdHIsICZzLT53ZW5kLCAmcy0+d3RvcCwgc2l6ZSkp
>Ow0KQEAgLTIwODcsNyArMjA4Nyw3IEBADQogICAgICAgICBlcnJubyA9IEVJTlZBTDsNCiAgICAg
>ICAgIFJFVFVSTl9XSVRIKC0xKTsNCiAgICAgfQ0KLSAgICBpZiAoKHMtPmZsYWdzICYgU0ZfRElT
>Q09OTkVDVElORykgJiYgISgoaW50KWNvZGUgJiBESVNDT05OX1JFU1VNRV9GTEFHKSkNCisgICAg
>aWYgKChzLT5mbGFncyAmIFNGX0RJU0NPTk5FQ1RJTkcpICYmICEoKGludHB0cl90KWNvZGUgJiBE
>SVNDT05OX1JFU1VNRV9GTEFHKSkNCiAgICAgICAgIFJFVFVSTl9XSVRIKDApOw0KICAgICBpZiAo
>KHMtPmZsYWdzICYgU0ZfRElTQ09OTl9SRVEpICYmIGNvZGUgPT0gRElTQ09OTl9MT0NBTCkNCiAg
>ICAgICAgIFJFVFVSTl9XSVRIKDApOw0KQEAgLTIxMjIsNyArMjEyMiw3IEBADQogICAgICAgICAv
>KiBUaGUgZGlzY29ubmVjdCBjYWxsYmFjayBkb2Vzbid0IG5lZWQgdG8gY2hlY2sgZm9yIGRpc2Nv
>bm5lY3Rpb24sDQogICAgICAgICAgKiBzbyB3ZSBqdXN0IGNhbGwgaXQgZGlyZWN0bHkgKi8NCiAg
>ICAgICAgIGVycm5vID0gZXJybm9fc2F2ZTsNCi0gICAgICAgIHMtPmNiX2Rpc2Nvbm4ocywgKHZv
>aWQgKikoKGludCljb2RlICYgfkRJU0NPTk5fUkVTVU1FX0ZMQUcpKTsNCisgICAgICAgIHMtPmNi
>X2Rpc2Nvbm4ocywgKHZvaWQgKikoKGludHB0cl90KWNvZGUgJiB+RElTQ09OTl9SRVNVTUVfRkxB
>RykpOw0KICAgICB9DQogICAgIHMtPmZsYWdzICY9IH5TRl9ESVNDT05ORUNUSU5HOw0KICAgICBp
>ZiAocy0+ZmQgPj0gMCkgew0KSW5kZXg6IGlyY3NlcnZpY2VzLWNodXJjaC01LjF+cHJlMy9tb2R1
>bGVzL2VuY3J5cHRpb24vdW5peC1jcnlwdC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09
>PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gaXJjc2VydmljZXMt
>Y2h1cmNoLTUuMX5wcmUzLm9yaWcvbW9kdWxlcy9lbmNyeXB0aW9uL3VuaXgtY3J5cHQuYwkyMDA3
>LTA2LTEwIDE0OjEzOjA1LjAwMDAwMDAwMCArMDEwMA0KKysrIGlyY3NlcnZpY2VzLWNodXJjaC01
>LjF+cHJlMy9tb2R1bGVzL2VuY3J5cHRpb24vdW5peC1jcnlwdC5jCTIwMDctMDctMjggMTU6MTU6
>MjcuMDAwMDAwMDAwICswMTAwDQpAQCAtNDQsNyArNDQsNyBAQA0KICAgICB9DQogICAgIGlmIChz
>dHJsZW4ocmVzKSA+IHNpemUtMSkgew0KICAgICAgICAgbW9kdWxlX2xvZygiZW5jcnlwdDogY3J5
>cHQoKSByZXR1cm5lZCB0b28gbG9uZyBhIHN0cmluZyEgKCVkIg0KLSAgICAgICAgICAgICAgICAg
>ICAiIGNoYXJhY3RlcnMpIiwgc3RybGVuKHJlcykpOw0KKyAgICAgICAgICAgICAgICAgICAiIGNo
>YXJhY3RlcnMpIiwgKGludClzdHJsZW4ocmVzKSk7DQogICAgICAgICByZXR1cm4gc3RybGVuKHJl
>cykgKyAxOw0KICAgICB9DQogICAgIHN0cnNjcHkoZGVzdCwgcmVzLCBzaXplKTsNCn==
>
>
>--=-P2RArCa9ERxXvALoWALg--
>
>--=-9UM9eTCG9p0bZ0vGzUkL
>Content-Type: application/pgp-signature; name=signature.asc
>Content-Description: This is a digitally signed message part
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (GNU/Linux)
>
>iD8DBQBGq1fYOHNNd4eQFFIRAvuZAKDq4k4Jn0eL0fyu3P/D7qwsn4T24wCfSMAI
>90bFNYpl49Pnnn8mygn3/ls=
>=ixXP
>-----END PGP SIGNATURE-----
>
>--=-9UM9eTCG9p0bZ0vGzUkL--
>
>
>--===============1334927669==
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>--===============1334927669==--
>
From dmartin at tekconxus.com  Sun Aug  5 01:14:11 2007
From: dmartin at tekconxus.com (Dereck Martin)
Date: Sun Aug  5 01:14:07 2007
Subject: [IRCServices Coding] XML Export to mySQL with PHP
Message-ID: <46B586D3.8030205@tekconxus.com>

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

Hello All,

I have wrote a php script that will essentially sync up the services xml
export found in the /dbaccess/xml-export/ of http server to mysql.  It
doesn't do all the values, but most of the them (at least the ones most
care about).  I will run this as a night cron job.

This script basically takes the most current xml export, parses it, and
then compares it to the mysql database.  If there are new or modified
entries it will add or update them.  If there are any entries that are
old and need to be removed (expired nicks/channels/unlinked nicks), it
deletes them.

I am sharing this script in hopes someone else may find it useful.  The
are two scripts.  One script creates the tables in mysql.  The second
script does all the other work.

The script is designed to only be ran once a day.  I am using DATE
stamps to distinguish between out of date entries and new ones.
Multiple runs in the same day will only update or add new entries.
Expired entries will only be removed the following day.

You can find my script here:
  http://www.tekconxus.com/files/ircservices-xml2mysql-0.5.tag.gz

Setup Instructions:

1. You will need to perform this command in mysql:

        CREATE DATABASE ircservices;

2. Modify the create_tables.php database variables.
3  Run "php -f create_tables.php" (only needs to be done once)
4. Modify the ircservices-xml2mysql.php database & xml variables.
5. Run "php -f ircservices-xml2mysql.php"

It will do its magic and even display some little progress graphics.
        (+) Add, (-) Delete, (^) Update

If there is enough curiosity in this script, I will add all entries from
the XML file.  For those interested in the output...during this run one
nick was added and one deleted.  The rest of the entries were synced.

###########################################################
fatbastard scripts # php -f ircservices-xml2mysql.php
- --04:10:49--  http://10.10.0.4:8080/dbaccess/xml-export/
           => `ircservices.xml'
Connecting to 10.10.0.4:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]

    [ <=>
                                        ] 11,225        --.--K/s

04:10:49 (13.59 MB/s) - `ircservices.xml' saved [11225]

Processing NickInfo Section:
^^+^-
Processing ChannelInfo Section:
^^^^
Processing NickGroupInfo Section:
^^^^
Updated: 11
Added: 1
Deleted: 1

###########################################################
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGtYbTZgcWLP4PXgERAouDAJ4/g8VQMCO1vgEX5Yd4SZtAJLgsPQCgnwdm
BXbK3a2j5efoIMru76pxkKA=
=pxA1
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ircservices-xml2mysql-0.5.tar.gz
Type: application/gzip
Size: 2814 bytes
Desc: not available
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20070805/bc355b84/ircservices-xml2mysql-0.5.tar.bin
From achurch at achurch.org  Sun Aug  5 20:09:25 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun Aug  5 04:24:35 2007
Subject: [IRCServices Coding] Build prefix/FHS compliance
In-Reply-To: <1184938996.8469.15.camel@regulus.retout.co.uk>
Message-ID: <46b5b36c.65741@msgid.achurch.org>

>Attached is a patch I'm currently using in the package - I've not
>finished testing it, but the idea is that things like modules, config
>files, language files and the helpfiles are opened only in one place, so
>are easy to relocate. Anything else can be fixed with absolute paths in
>the config files.

Thanks for the patch, but after some thought I've decided I'm not going
to make Services FHS-compliant, so I'll have to ask you to make those
changes as a distribution-local patch.  It looks like the changes you
propose are sufficient, but the binary-plus-single-data-directory scheme
has been part of Services since the earliest versions, and I'm reluctant
to make such a change to the design without a thorough review of all
potential effects of the change, which I'm afraid I no longer have time
for at this point.

I have, however, added support for alternate installation paths and
changing the executable name to the next beta, which should be out soon.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From aragon at phat.za.net  Fri Sep  7 16:43:42 2007
From: aragon at phat.za.net (Aragon Gouveia)
Date: Fri Sep  7 16:43:55 2007
Subject: [IRCServices Coding] block nick registrations whose email address
        is suspended
Message-ID: <20070907234342.GA37186@phat.za.net>

Hi,

We've been having fun and games with a particular user recently.  This
person accesses our network from a 3G internet connection whose IP address
is allocated from a pool of IP addresses NAT'd and shared by thousands of
other users of this particular ISP.  Sadly many people subscribe to this
poor excuse for an internet connection, and consequently a largish chunk of
our users all appear to be connecting from the same IP address, even though
they're completely seperate and unrelated entities in real life.

Needless to say, dealing with abusive users from this ISP isn't easy.  One
saving grace we have is that many of our channels set +R, so I needed a way
to make endless reregistering of nicks more complicated.

I've written a patch that adds a checkpoint to the do_register function of
nickserv that checks to see if the email address of a nick being registered
is already set on another registered nickname that is suspended.  If it
finds a suspended nick with the same email address, it disallows the
registration.

This allows me to suspend an offending nick and force the person to go
through the agony of creating a new email address if he wants to come back
and cause more trouble in +R channels.  Hopefully this will frustrate
idiots enough to loose interest. :)

Patch is attached.  It would be nice to have module_log show what nick the
new registration is colliding with, but I'll settle with having to guess for
now.  Suggestions welcome!

I think this might come in handy to others, so maybe worth pulling into
official releases?


Regards,
Aragon
-------------- next part --------------
--- ircservices-5.0.62/modules/nickserv/main.c  Sun Jun 10 15:26:58 2007
+++ ircservices-5.0.62.blabbernet/modules/nickserv/main.c       Sat Sep  8 00:49:44 2007
@@ -523,6 +523,10 @@
                        NSRegEmailMax);
        }
 
+    } else if (email && !is_services_admin(u) && is_email_suspended(email)) {
+        module_log("%s@%s tried to register nick %s whose email address %s is suspended elsewhere",
+                      u->username, u->host, u->nick, email);
+        notice_lang(s_NickServ, u, NICK_CANNOT_BE_REGISTERED, u->nick);
     } else {
        int replied = 0;
        int len = strlen(pass), max;
--- ircservices-5.0.62/modules/nickserv/util.c  Sun Jun 10 15:26:58 2007
+++ ircservices-5.0.62.blabbernet/modules/nickserv/util.c       Sat Sep  8 00:45:59 2007
@@ -855,6 +855,24 @@
     return has_authcode ? -count : count;
 }
 
+/***********************************************************************/
+
+/* Check if any nicknames with the given E-mail address are suspended.
+ */
+
+int is_email_suspended (const char *email)
+{
+    NickGroupInfo *ngi;
+
+    for (ngi = first_nickgroupinfo(); ngi; ngi = next_nickgroupinfo()) {
+       if (ngi->email && stricmp(ngi->email, email) == 0) {
+           if (ngi->suspendinfo)
+               return 1;
+       }
+    }
+    return 0;
+}
+
 /*************************************************************************/
 /*************************************************************************/
 
--- ircservices-5.0.62/modules/nickserv/ns-local.h      Sun Jun 10 15:26:58 2007
+++ ircservices-5.0.62.blabbernet/modules/nickserv/ns-local.h   Sat Sep  8 00:54:28 2007
@@ -96,6 +96,7 @@
 E int nick_check_password(User *u, NickInfo *ni, const char *password,
                          const char *command, int failure_msg);
 E int count_nicks_with_email(const char *email);
+E int is_email_suspended(const char *email);
 
 E int init_util(Module *module);
 E void exit_util(void);
From achurch at achurch.org  Mon Sep 10 11:08:16 2007
From: achurch at achurch.org (Andrew Church)
Date: Sun Sep  9 19:09:21 2007
Subject: [IRCServices Coding] block nick registrations whose email address
        is suspended
In-Reply-To: <20070907234342.GA37186@phat.za.net>
Message-ID: <46e4a748.43764@msgid.achurch.org>

I've added similar functionality to 5.1.  Thanks for the suggestion!

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

>Hi,
>
>We've been having fun and games with a particular user recently.  This
>person accesses our network from a 3G internet connection whose IP address
>is allocated from a pool of IP addresses NAT'd and shared by thousands of
>other users of this particular ISP.  Sadly many people subscribe to this
>poor excuse for an internet connection, and consequently a largish chunk of
>our users all appear to be connecting from the same IP address, even though
>they're completely seperate and unrelated entities in real life.
>
>Needless to say, dealing with abusive users from this ISP isn't easy.  One
>saving grace we have is that many of our channels set +R, so I needed a way
>to make endless reregistering of nicks more complicated.
>
>I've written a patch that adds a checkpoint to the do_register function of
>nickserv that checks to see if the email address of a nick being registered
>is already set on another registered nickname that is suspended.  If it
>finds a suspended nick with the same email address, it disallows the
>registration.
>
>This allows me to suspend an offending nick and force the person to go
>through the agony of creating a new email address if he wants to come back
>and cause more trouble in +R channels.  Hopefully this will frustrate
>idiots enough to loose interest. :)
>
>Patch is attached.  It would be nice to have module_log show what nick the
>new registration is colliding with, but I'll settle with having to guess for
>now.  Suggestions welcome!
>
>I think this might come in handy to others, so maybe worth pulling into
>official releases?
>
>
>Regards,
>Aragon
From tim at retout.co.uk  Sun Oct 21 12:32:51 2007
From: tim at retout.co.uk (Tim Retout)
Date: Sun Oct 21 12:58:56 2007
Subject: [IRCServices Coding] ircservices-church ITP
Message-ID: <1192995171.7726.14.camel@regulus.retout.co.uk>

Having given it some thought, and considering that

      * IRC Services as shipped will not build on 64-bit architectures,
      * Andrew Church does not want the patch to fix this, for
        historical reasons,
      * my original intent for this software was for use on amd64
        servers,
      * I am unwilling to maintain large patches against upstream,

regrettably I have lost interest in packaging IRC Services for Debian. I
am therefore closing the ITP.

Sorry for taking so long to come to this conclusion.

-- 
Tim Retout <tim@retout.co.uk>

From achurch at achurch.org  Tue Oct 30 00:45:50 2007
From: achurch at achurch.org (Andrew Church)
Date: Mon Oct 29 08:50:22 2007
Subject: [IRCServices Coding] Analysis of the 5.1.2 bug
Message-ID: <4726015c.15341@msgid.achurch.org>

    Now that a bit of time has passed since the release of Services
5.1.2, and (hopefully) everyone has upgraded, I thought I'd post a more
detailed explanation of exactly how the critical bug that prompted this
release came about.  (As you are probably aware, various and sundry bugs
have pushed Services all the way to 5.1.6 since then, but in this text
I'll focus on the bug that was fixed by 5.1.2.  Just as a reminder, all
5.1.x releases through 5.1.5 have bugs allowing users to crash Services,
so you should immediately upgrade to 5.1.6 if you haven't already.)

The Bug
=======

     The bug itself is fairly straightforward (as those who read the
diff file will have already realized): using the ChanServ AKICK VIEW
command on a channel with at least one autokick caused Services to
crash, without exception.  By default, the AKICK command requires
channel access level 100 to use; this is the basis for the "sufficiently
privileged users" text in the announcement.  In reality, unless channel
registration was disabled, any user could register a new channel (thus
gaining founder status) and use the AKICK command on that channel,
effectively allowing any user to crash Services.  (Ironically, when
channel registration was disabled, a separate bug--fixed in 5.1.3--had
the potential to let any user cause a crash.)

     A most embarrassing bug, indeed...

How It Came About
=================

     One of the changes implemented in Services 5.1 was to unify (from
an interface standpoint, at least; internally, there's still far too
much code duplication) the listing functionality of all pseudoclient
commands.  Among other things, this included removing the entry numbers
from the ChanServ ACCESS, XOP (SOP/AOP/HOP/VOP/NOP), and AKICK commands,
mostly to avoid the confusion that can result from multiple users
deleting entries in the middle of the list.

     Conceptually, this is a simple change, only requiring the removal
of the corresponding parameter from the code that outputs entries to the
user.  But theory and practice are different beasts, as they say; in the
case of AKICK VIEW, the data for each entry is formatted using a
language-specific string, requiring a change not only in the code itself
but also in each of the language files.  I actually made this latter
change, presumably with the intent of going back and updating the code
once I had all the language files updates out of the way.  However, it
seems that I forgot to make that final update, leaving the entry number
present in the the code that formatted autokick entries for the VIEW
subcommand.  This resulted, eventually, in something like printf("%s",1)
--which of course crashed when the program tried to dereference the
entry number as a pointer.

     Ordinarily, GCC can catch inconsistencies between format strings
and parameters like this; I always compile Services using GCC's -Werror
option, to ensure I catch as many potential problems as possible.  With
language strings, however, the format string itself is located in a data
file separate from the source code.  Since the data isn't accessible to
the compiler, these checks can't be made, and the error slipped by
unnoticed until this bug was reported.

Are Any Other Commands At Risk?
===============================

     With respect to this particular change, no.  The removal of list
entry numbers affected only the ChanServ ACCESS LIST, XOP LIST, and
AKICK LIST/VIEW commands.  Of these, XOP LIST and AKICK LIST use literal
format strings for their output, which were corrected as part of the
code change; ACCESS LIST uses the language system, but its code and
format strings were both updated properly, and it is likewise not
susceptible to this problem.

     With respect to all commands in general, all I can say is "I hope
not."  I've done my best, within the constraints of time and an eleven-
year-old codebase, to program defensively; since 5.1.2, I've also gone
over all uses of language strings, and added some checks to my release
process (see below) to help avoid any more slipping in.  But given that
I let these bugs by, who knows what else might be hiding?

Lessons To Be Learned
=====================

Lesson 1: Test suites

     Ah, our good old friend, testing.  I actually had started work on a
test suite for Services at one point, which was the main motivation for
the OperServ debug commands.  Regrettably, between a lack of time in my
earlier days of Services development (being not nearly as fluent in
progamming then as I am now, writing a test suite to interact with a
server was a formidable task, and I chose to use my time working on
Services itself instead) and a lack of interest later, I never took the
test suite beyond simple nickname operations.

     Of course, even a basic test that just ran through all the commands
would have caught this bug, and to that I can only say:  Mea culpa.
Lack of interest or otherwise, I failed to follow best practices, and
that failure came back to bite me.

Lesson 2: Format strings are dangerous

     Services makes use of the standard printf()-style format strings in
its language files, partly out of convenience and partly because I
didn't know any better when I designed the language system.  While the
flexibility of format strings is undeniably useful, their implementation
leaves much to be desired--especially in a language like C that does not
pass type information around.  In fact, inconsistencies between format
strings in different language files has resulted in similar crashes in
the past (including the less-dangerous one fixed in version 5.1.3).  Of
course, most of the danger in using format strings comes from the fact
that strings are second-class citizens in the C data type world: to
process a string, you access successive bytes through a pointer--and if
that particular value happens to be something that's not a pointer,
BOOM.  So this lesson could just as easily be "C strings are dangerous".

     So what can be done about it?  Well, one of the obvious solutions--
and probably the best idea in the long run--is to rewrite the
pseudoclients in a higher-level language, such as Perl; Perl's dynamic
typing ensures that this sort of problem can't occur.  (Then again,
dynamically typed languages have their own problems, so this isn't a
perfect solution.)  I'd actually had thoughts about implementing a Perl
base for pseudoclients in a future version of Services, but I don't have
nearly enough time or interest to do so at this point.

     Another option would be to change the language file system to use a
custom formatting system.  Parameters could be named, for example, and
an array of structures including parameter names and data types along
with the parameters themselves could be passed to routines like
notice_lang().  Of course, this has the downside of turning what's
currently a simple list of parameters into a more complex variable
declaration; and since the data types would have to be specified
manually, there's still the danger of mismatched types, leading to
potential crashes.  Nonetheless, this might be a more feasible approach
for those who are interested in improving Services' robustness but don't
want to go as far as rewriting half of it in Perl.

     I've implemented two crude solutions in Services 5.1.3.  One is the
use of a script, modified from one provided by German translator Jacek
Margos, to check all language files for format string inconsistencies at
release time.  The other is a simple compilation check: at release time,
I run a test compilation where notice_lang() and notice_help() calls
using fixed message IDs are replaced with notice() calls that use the
corresponding strings from the English language file (lang/en_us.l).
The resulting executable is of course useless from a multilingual point
of view, but the compiler will complain about any cases where format
strings and parameters don't match.  While this won't catch cases where
the format string is selected by a variable, it would have found the
particular bug fixed in version 5.1.2.

Final Thoughts
==============

     Needless to say, this bug in particular, as well as the fact that I
had to make five releases of a supposedly "stable" version of Services
in the space of ten days to correct other bugs of varying seriousness,
is quite embarrassing.  I'm of course acutely aware of the trouble it's
caused everyone using Services, of the repeated interruptions in normal
network operations that will have resulted from upgrades (if not
crashes)--and let none say that it's "just IRC"!  But at the same time,
I take pride in my work as a software developer, and seeing myself make
such trivial mistakes as these is, well, depressing to say the least.
I could make excuses that the code base is aging (which is true), or
that I've lost too much interest in the program to do a proper job
(which is also true, to be honest--that's the main reason I declared 5.1
to be the final version of Services).  I could even claim that I've got
another project twice the sice of Services that's considerably more
stable (which is true as well, thanks in no small part to the experience
I've gained from Services itself).  But since none of that changes the
facts, all I can say in the end is that I screwed up, and I'm sorry.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From Craig at frostycoolslug.com  Mon Oct 29 10:39:34 2007
From: Craig at frostycoolslug.com (Craig McLure)
Date: Mon Oct 29 10:39:06 2007
Subject: [IRCServices Coding] Analysis of the 5.1.2 bug
In-Reply-To: <4726015c.15341@msgid.achurch.org>
References: <4726015c.15341@msgid.achurch.org>
Message-ID: <8a79f15a0710291039x2f818a73j3b37007f853d8f05@mail.gmail.com>

No apology necessary my good friend, everyone screws up, even myself,
On one or two occasions i've written code which in theory was solid,
just to have it come back and bite me in the ass several times a few
weeks on, each time i fixed a part of it, another part came along and
took another bite (I'm missing half a buttock at this point) it's an
unfortunate part of the development cycle. Sure it's an embarrassment
and can induce a really bad day, but no one will think any less of
you, especially if they know the effort and general requirements which
go into making such a large package as services.

I've been on these lists now since 2001 (admittedly, I was a LOT
younger back then (15ish?)), and i've found your general dedication to
the software to be inspirational, and it was tweaking IRCServices that
kickstarted my coding career. IRCServices has always been well
written, and always will be well written. I'm sure someone will pick
up the baton and continue the IRCServices package far into the future,
but i doubt they will have the same dedication and motivation to
improve this as you have had. I know from experience that coding
something for many, many years has some diminishing returns on the
mind of the developer (not that i'm saying you've lost your mind), but
dispite this, you've continued to fully support a package which you
have lost interest in.

You say you're a proud person when it comes to code, well, you damn
well should be. You've created a rock solid piece of software, you've
taken no crap over the years, and you've continued to evolve it to a
point where it's probably the best services package in existence.

Don't be depressed, don't be ashamed, don't be embarrassed, hold your
head up high, for the unfortunate events of the last week can't even
place a scratch on the quality you've provided over the years.

-- 
/**********************************************
 *        Craig "FrostyCoolSlug" McLure
 * ChatSpike    - http://www.chatspike.net
 * InspIRCd     - http://www.inspircd.org
 **********************************************/

On 29/10/2007, Andrew Church <achurch@achurch.org> wrote:
>     Now that a bit of time has passed since the release of Services
> 5.1.2, and (hopefully) everyone has upgraded, I thought I'd post a more
> detailed explanation of exactly how the critical bug that prompted this
> release came about.  (As you are probably aware, various and sundry bugs
> have pushed Services all the way to 5.1.6 since then, but in this text
> I'll focus on the bug that was fixed by 5.1.2.  Just as a reminder, all
> 5.1.x releases through 5.1.5 have bugs allowing users to crash Services,
> so you should immediately upgrade to 5.1.6 if you haven't already.)
>
> The Bug
> =======
>
>      The bug itself is fairly straightforward (as those who read the
> diff file will have already realized): using the ChanServ AKICK VIEW
> command on a channel with at least one autokick caused Services to
> crash, without exception.  By default, the AKICK command requires
> channel access level 100 to use; this is the basis for the "sufficiently
> privileged users" text in the announcement.  In reality, unless channel
> registration was disabled, any user could register a new channel (thus
> gaining founder status) and use the AKICK command on that channel,
> effectively allowing any user to crash Services.  (Ironically, when
> channel registration was disabled, a separate bug--fixed in 5.1.3--had
> the potential to let any user cause a crash.)
>
>      A most embarrassing bug, indeed...
>
> How It Came About
> =================
>
>      One of the changes implemented in Services 5.1 was to unify (from
> an interface standpoint, at least; internally, there's still far too
> much code duplication) the listing functionality of all pseudoclient
> commands.  Among other things, this included removing the entry numbers
> from the ChanServ ACCESS, XOP (SOP/AOP/HOP/VOP/NOP), and AKICK commands,
> mostly to avoid the confusion that can result from multiple users
> deleting entries in the middle of the list.
>
>      Conceptually, this is a simple change, only requiring the removal
> of the corresponding parameter from the code that outputs entries to the
> user.  But theory and practice are different beasts, as they say; in the
> case of AKICK VIEW, the data for each entry is formatted using a
> language-specific string, requiring a change not only in the code itself
> but also in each of the language files.  I actually made this latter
> change, presumably with the intent of going back and updating the code
> once I had all the language files updates out of the way.  However, it
> seems that I forgot to make that final update, leaving the entry number
> present in the the code that formatted autokick entries for the VIEW
> subcommand.  This resulted, eventually, in something like printf("%s",1)
> --which of course crashed when the program tried to dereference the
> entry number as a pointer.
>
>      Ordinarily, GCC can catch inconsistencies between format strings
> and parameters like this; I always compile Services using GCC's -Werror
> option, to ensure I catch as many potential problems as possible.  With
> language strings, however, the format string itself is located in a data
> file separate from the source code.  Since the data isn't accessible to
> the compiler, these checks can't be made, and the error slipped by
> unnoticed until this bug was reported.
>
> Are Any Other Commands At Risk?
> ===============================
>
>      With respect to this particular change, no.  The removal of list
> entry numbers affected only the ChanServ ACCESS LIST, XOP LIST, and
> AKICK LIST/VIEW commands.  Of these, XOP LIST and AKICK LIST use literal
> format strings for their output, which were corrected as part of the
> code change; ACCESS LIST uses the language system, but its code and
> format strings were both updated properly, and it is likewise not
> susceptible to this problem.
>
>      With respect to all commands in general, all I can say is "I hope
> not."  I've done my best, within the constraints of time and an eleven-
> year-old codebase, to program defensively; since 5.1.2, I've also gone
> over all uses of language strings, and added some checks to my release
> process (see below) to help avoid any more slipping in.  But given that
> I let these bugs by, who knows what else might be hiding?
>
> Lessons To Be Learned
> =====================
>
> Lesson 1: Test suites
>
>      Ah, our good old friend, testing.  I actually had started work on a
> test suite for Services at one point, which was the main motivation for
> the OperServ debug commands.  Regrettably, between a lack of time in my
> earlier days of Services development (being not nearly as fluent in
> progamming then as I am now, writing a test suite to interact with a
> server was a formidable task, and I chose to use my time working on
> Services itself instead) and a lack of interest later, I never took the
> test suite beyond simple nickname operations.
>
>      Of course, even a basic test that just ran through all the commands
> would have caught this bug, and to that I can only say:  Mea culpa.
> Lack of interest or otherwise, I failed to follow best practices, and
> that failure came back to bite me.
>
> Lesson 2: Format strings are dangerous
>
>      Services makes use of the standard printf()-style format strings in
> its language files, partly out of convenience and partly because I
> didn't know any better when I designed the language system.  While the
> flexibility of format strings is undeniably useful, their implementation
> leaves much to be desired--especially in a language like C that does not
> pass type information around.  In fact, inconsistencies between format
> strings in different language files has resulted in similar crashes in
> the past (including the less-dangerous one fixed in version 5.1.3).  Of
> course, most of the danger in using format strings comes from the fact
> that strings are second-class citizens in the C data type world: to
> process a string, you access successive bytes through a pointer--and if
> that particular value happens to be something that's not a pointer,
> BOOM.  So this lesson could just as easily be "C strings are dangerous".
>
>      So what can be done about it?  Well, one of the obvious solutions--
> and probably the best idea in the long run--is to rewrite the
> pseudoclients in a higher-level language, such as Perl; Perl's dynamic
> typing ensures that this sort of problem can't occur.  (Then again,
> dynamically typed languages have their own problems, so this isn't a
> perfect solution.)  I'd actually had thoughts about implementing a Perl
> base for pseudoclients in a future version of Services, but I don't have
> nearly enough time or interest to do so at this point.
>
>      Another option would be to change the language file system to use a
> custom formatting system.  Parameters could be named, for example, and
> an array of structures including parameter names and data types along
> with the parameters themselves could be passed to routines like
> notice_lang().  Of course, this has the downside of turning what's
> currently a simple list of parameters into a more complex variable
> declaration; and since the data types would have to be specified
> manually, there's still the danger of mismatched types, leading to
> potential crashes.  Nonetheless, this might be a more feasible approach
> for those who are interested in improving Services' robustness but don't
> want to go as far as rewriting half of it in Perl.
>
>      I've implemented two crude solutions in Services 5.1.3.  One is the
> use of a script, modified from one provided by German translator Jacek
> Margos, to check all language files for format string inconsistencies at
> release time.  The other is a simple compilation check: at release time,
> I run a test compilation where notice_lang() and notice_help() calls
> using fixed message IDs are replaced with notice() calls that use the
> corresponding strings from the English language file (lang/en_us.l).
> The resulting executable is of course useless from a multilingual point
> of view, but the compiler will complain about any cases where format
> strings and parameters don't match.  While this won't catch cases where
> the format string is selected by a variable, it would have found the
> particular bug fixed in version 5.1.2.
>
> Final Thoughts
> ==============
>
>      Needless to say, this bug in particular, as well as the fact that I
> had to make five releases of a supposedly "stable" version of Services
> in the space of ten days to correct other bugs of varying seriousness,
> is quite embarrassing.  I'm of course acutely aware of the trouble it's
> caused everyone using Services, of the repeated interruptions in normal
> network operations that will have resulted from upgrades (if not
> crashes)--and let none say that it's "just IRC"!  But at the same time,
> I take pride in my work as a software developer, and seeing myself make
> such trivial mistakes as these is, well, depressing to say the least.
> I could make excuses that the code base is aging (which is true), or
> that I've lost too much interest in the program to do a proper job
> (which is also true, to be honest--that's the main reason I declared 5.1
> to be the final version of Services).  I could even claim that I've got
> another project twice the sice of Services that's considerably more
> stable (which is true as well, thanks in no small part to the experience
> I've gained from Services itself).  But since none of that changes the
> facts, all I can say in the end is that I screwed up, and I'm sorry.
>
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
From manual4000 at yahoo.com  Fri Dec 14 05:12:47 2007
From: manual4000 at yahoo.com (MaNUaL)
Date: Fri Dec 14 11:53:19 2007
Subject: [IRCServices Coding] samode
Message-ID: <35304.61536.qm@web53012.mail.re2.yahoo.com>

Hi. I am using ircservices-5.1.10 with Unreal3.2.7 ircd.

When i use /samode #channel +o mynick the chanserv deops me because i
am not in the access list of the channel. If i am, no problem occurs..

Help from unreal shows the following:



***** Samode *****

 Allows a Services Administrator to change the mode on a channel,

 without having Operator status.

 Services Admin Command

 Syntax:  SAMODE <channel> <mode>

 Example: SAMODE #Support +m



I am a services admin but i all i get is this:


/samode #opers +o MaNUaL

[14:56] * irc.example.net sets mode: +o MaNUaL

[14:56] * ChanServ sets mode: -o MaNUaL



Is this a normal behavior or is it a bug? I think when i use samode the chanserv should comply with it...

Thanks in advance


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
From achurch at achurch.org  Sat Dec 15 13:16:57 2007
From: achurch at achurch.org (Andrew Church)
Date: Fri Dec 14 20:19:16 2007
Subject: [IRCServices Coding] samode
In-Reply-To: <35304.61536.qm@web53012.mail.re2.yahoo.com>
Message-ID: <476355c0.55637@msgid.achurch.org>

>Hi. I am using ircservices-5.1.10 with Unreal3.2.7 ircd.
>
>When i use /samode #channel +o mynick the chanserv deops me because i
>am not in the access list of the channel. If i am, no problem occurs..

This is designed behavior.  If you need to override the channel access
list, use the OperServ MODE command.

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