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: 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 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 <>config.h.new <>config.h.new <>config.h.new <>config.h.new < 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: 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: References: <9098af010701130637o3ac7c57bpda4686da6280b427@mail.gmail.com> Message-ID: <9098af010701132145ub66715fuaebec158b2f0caf@mail.gmail.com> On 1/13/07, Robin Burchell 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. 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 --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 --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: 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: References: Message-ID: > 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: 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 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 -------------- 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 @@

The available encryption modules are as follows:

    -
  • encryption/md5: Uses the MD5 hashing -algorithm1 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. +
  • encryption/md5: 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.

  • encryption/unix-crypt: DISCOURAGED. Uses the crypt() 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). -

    1Technically, the "RSA Data Security, Inc. MD5 -Message-Digest Algorithm". -

    Back to top 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 + 2007/05/14 pre1 Fixed a bug in XML import that caused channel mode locks to be lost. Reported by 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 + 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 + . 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 . + 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 + . 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 + 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 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 + +#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: 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: References: Message-ID: 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 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: References: Message-ID: 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 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 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 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: References: 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: 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 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 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 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 > >------------------------------------------------------------------ >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 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 does not define uint32_t on all >architectures, so this patch uses by default instead, and >fixes most of the build warnings. > >Thanks, > >--=20 >Tim Retout > >--=-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 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 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 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/