Hi!
I wrote a small patch that allows you to specify a file in the config containing forbidden nicks. This may be useful to disallow users changing their nicks to NickServ or ChanServ or any other nick.
regards, Fabian
Fabian Schlager fabian.schlager@gmail.com wrote:
I wrote a small patch that allows you to specify a file in the config containing forbidden nicks. This may be useful to disallow users changing their nicks to NickServ or ChanServ or any other nick.
Please send patches inline in the future; this makes it easier for me to comment, also please also use diff -p option, it makes it easier to see where the change actually is.
+GLOBAL bool +Conf_ReadBadNicksFile( char *FileName )
const char *
// Allocate enough memory to store the nickname
Conf_BadNicks[Conf_BadNicks_Count] = malloc(strlen(tmpNick));
strcpy(Conf_BadNicks[Conf_BadNicks_Count], tmpNick);
buffer overflow. ( should be malloc(strlen( ) + 1 ). Just use strdup(3).
if (Conf_BadNicks_Count > MAX_BADNICKS)
buffer overflow, must be >=
- if( strcasecmp( Var, "BadNicksFile" ) == 0 ) {
/* File containing restricted nicknames, e.g. NickServ */
len = strlcpy( Conf_BadNicksFile, Arg, sizeof( Conf_BadNicksFile ));
if (len >= sizeof( Conf_BadNicksFile ))
Config_Error_TooLong( Line, Var );
That looks strange. Why do you try to open it after detecting that the filename was truncated? (Hmm, why do we need to save the filename in the first place?)
+#define MAX_BADNICKS 100 /* Max. count of restricted nicks */
}
This adds whitespace damage. Please don't do this; it only clutters diffsets. (Removing existing trailing whitespace is perfectly ok)
+GLOBAL bool Conf_ReadBadNicksFile PARAMS(( char *FileName ));
I see no reason to export this function; should be static.
My take on the intention of this patch: _IF_ there really is demand for such a feature then we should probably implement it without imposing any restrictions, i.e. the nick name list should be as large as needed.
On CodingStyle: this is largely open to debate. Basically ngircd has an "old" style (very long functions, long lines, you-know-it-when-you-see-it) and a "new" style (similar to Linux Kernel CodingStyle). Always use the "new" style, even when editing "old-style" code.
Comments? Are people interested in the "Nick Blacklist" Option?
Florian
On Mon, Jan 21, 2008 at 08:05:09PM +0100, Florian Westphal wrote:
Fabian Schlager fabian.schlager@gmail.com wrote:
I wrote a small patch that allows you to specify a file in the config containing forbidden nicks. This may be useful to disallow users changing their nicks to NickServ or ChanServ or any other nick.
Please send patches inline in the future; this makes it easier for me to
I didn't actually *see* there was an attachment, on a quick flick, so another preference for in-line, here...
[...]
My take on the intention of this patch: _IF_ there really is demand for such a feature then we should probably implement it without imposing any restrictions, i.e. the nick name list should be as large as needed.
Agreed, in principle.
On CodingStyle: this is largely open to debate. Basically ngircd has an "old" style (very long functions, long lines, you-know-it-when-you-see-it) and a "new" style (similar to Linux Kernel CodingStyle). Always use the "new" style, even when editing "old-style" code.
Comments? Are people interested in the "Nick Blacklist" Option?
Checking, it's something that a couple of other ircds provide... but just because they do, should ngircd?
Part of me thinks it makes sense to set it in the daemon config, another things that a sensible service/bot should kick/re-nick/cycle the idiots using 'their' nicks, and claim for themselves.
Am 21.01.2008 um 20:05 schrieb Florian Westphal:
Fabian Schlager fabian.schlager@gmail.com wrote:
I wrote a small patch that allows you to specify a file in the config containing forbidden nicks. This may be useful to disallow users changing their nicks to NickServ or ChanServ or any other nick.
Please send patches inline in the future; this makes it easier for me to comment, also please also use diff -p option, it makes it easier to see where the change actually is.
Right, sending patches inline using "diff -up" ist the preferred way. It makes dealing with the patches much more easier.
And I second all the other points Florian already mentioned.
My take on the intention of this patch: _IF_ there really is demand for such a feature then we should probably implement it without imposing any restrictions, i.e. the nick name list should be as large as needed.
I agree. We could use the already existing array functions for that.
On CodingStyle: this is largely open to debate. Basically ngircd has an "old" style (very long functions, long lines, you-know-it-when-you-see-it) and a "new" style (similar to Linux Kernel CodingStyle). Always use the "new" style, even when editing "old-style" code.
And I have to agree once more: it has been a "not so good" decision to start coding ngIRCd using the old coding style and german comments in the first place. There is no need to change old code just to make it "style compliant", but please (please!) use the "new style" when touching old and writing new code!
You can use the tool contrib/ngindent, which is a wrapper for (GNU) indent, to get an idea how actual code should look like.
Comments? Are people interested in the "Nick Blacklist" Option?
I don't know. Personally I don't need it, but I could imagine that this functionality could be useful ...
Regards Alex