Recent changes to bugs

#208 mod-blacklist not working on FreeBSD

mIRCx — Thu, 28 Jan 2016 08:06:03 -0000

"dnsbl" {
// This DNSBL zone does not exist - you'll have to pick your own.
"sbl.spamhaus.org" {
// Send a notice instead of glining blacklisted ips
"debug" "1";
"description" "sbl.spamhaus.org";
"reason" "busted by a dns blacklist";
"duration" "5m";
// You can stick the client's IP in the G-line message.
"reason_2" "sbl.spamhaus.org %ip%'s address as 127.0.0.2";
// .. or the contents of a DNS TXT.
"reason_3" "%txt%";
};
this work like it or i need select more thing?

#208 mod-blacklist not working on FreeBSD

mIRCx — Thu, 28 Jan 2016 08:04:32 -0000

Entrope how this work in conf please?

Possible memory leak with CSEARCH

Jason — Tue, 05 Mar 2013 19:34:02 -0000

Not sure if you prefer SF or GitHub, so I'll just stick this here?

Possible memory leak when using CSEARCH and not providing arguments for criteria. In opserv_cdiscrim_create(), line ~3648:

if (i == (argc - 1)) {
send_message(user, opserv, "MSG_MISSING_PARAMS", argv[i]);
return NULL;
}

It simply returns NULL and doesn't free discrim, instead of jumping to fail and cleaning up first.

double exlamation mark gives error

Brainscrewer — Fri, 06 Jan 2012 00:30:50 -0000

Hi,

even without having access inside a channel, typing '!!" will result in getting the following message: -ChanServ- Public commands in #channel are restricted, even if !set pubcmd is 0.

Issue occurs on latest git.

HelpServ: wrong responses for persist settings

ZeRoFiGhter — Fri, 18 Nov 2011 17:31:48 -0000

Hi,

in commit 671a213e001f8317536101c7ea63cb0e6de04175 ("Fix the name and type of helpserv_bot.persist_types[].") you made a minor mistake:

in opt_persist (line 3205 in current git master) there is:
helpserv_notice(user, persistence_lengths[idx].print_name,
user_find_message(user, persistence_lengths[hs->persist_lengths[idx]].print_name));

but it should be:
helpserv_notice(user, persistence_types[idx].print_name,
user_find_message(user, persistence_lengths[hs->persist_lengths[idx]].print_name));

2nd parameter should be persistence_types instead of persistence_lengths

visible effect of this bug is that HelpServ replies just the text like "part" or "quit" for the persist types, instead of "ReqPersist part" and alike.

regards,
ZeRoFiGhter

Wrong min_argc for chanserv.8ball and no helpfile entry

ZeRoFiGhter — Sun, 30 Oct 2011 10:06:24 -0000

Hi,

the following line in chanserv.c (current git head)
7911 DEFINE_COMMAND(8ball, 1, 0, "flags", "+nolog,+toy,+acceptchan", NULL);
is wrong, it should be 2 as second parameter, because 8ball does at least need one parameter additional to the command itself.

Besides there is no helpfile entry for 8ball.

regards
ZeRoFiGhter

MemoServ: override and memoserv_can_send

ZeRoFiGhter — Sat, 28 May 2011 18:31:20 -0000

Hi,

i'm not sure if you still are interested in my reports ... anyway, i'll drop another one here:

Users with Helping flag don't pass the check in memoserv_can_send because they are never seen with their Helping fake struct userData:

if you have override access the method _GetChannelUser(...) returns the struct userData with seen = 0 from the helperList, which causes this

mod-memoserv.c: line 234
if (recip != NULL && recip->seen != 0)
return 1;

to never return 1 = allowed.

Version: Git head

kind regards
ZeRoFiGhter

override vs chanserv.trim

ZeRoFiGhter — Tue, 05 Oct 2010 19:47:25 -0000

hi,

we just noticed some strange behaviour:
helper with +g does a chanserv.trim while not having access at all.
general command handling allows to execute the command (due to +g) and logs as override
cmd_trim_users internally uses GetChannelAccess to check if the actor is allowed to trim which fails (as this does not check for +g, GetChannelUser should be used, imho, this checks for +g)
so cmd_trim_users msgs "you lack sufficient access" to the actor, while the command is still logged as override

1.4 latest git, as usual

small bug in !myaccess

Martin Martimeo — Tue, 21 Sep 2010 12:48:34 -0000

When showing !myaccess, there is a little comma too much at chanenls where you have more access than givevoice and giveops, but autoop is off:

[14:39] <ChanServ> Showing all channel entries for account MartinMartimeo:
[14:39] <ChanServ> [#LRSI (500,)]

[14:41] <MartinMartimeo> uset #lrsi noautoop on
[14:41] <ChanServ> NoAutoVoice On

[14:42] <MartinMartimeo> myaccess
[14:42] <ChanServ> Showing all channel entries for account MartinMartimeo:
[14:42] <ChanServ> [#LRSI (500)]

[14:47] <MartinMartimeo> set #lrsi
[14:47] <ChanServ> Channel Options:
[14:47] <ChanServ> GiveVoice 501
[14:47] <ChanServ> GiveOps 501

helpserv does not always a message on request drop

ZeRoFiGhter — Mon, 20 Sep 2010 19:06:36 -0000

hi,

i'm not sure if it's a bug or if it is really meant the way it is implemented ...

helpservs handle_part only sends a drop notification if there is a request text ... imho this does not make sense ... it should send it always (line 3841 in current git head)