Uli Schlachter [Thu, 6 Dec 2012 16:28:05 +0000 (17:28 +0100)]
CModule::OnMode(): Fix a stupid NULL pointer dereference
When joining a channel, OnMode() (via SetModes()) was called with pOpNick ==
NULL. This bad pointer was turned into a reference and given to modules.
This bug exists since 2008 when the OnMode() module call was added. It wasn't
noticed before because apparently no module used this CNick argument before.
Uli Schlachter [Sat, 5 Nov 2011 11:17:31 +0000 (12:17 +0100)]
route_replies: Handle raw 482
lahwran reported the following message from *route_replies and also figured out
which message we failed to handle, thanks!
<*route_replies> This module hit a timeout which is possibly a bug.
<*route_replies> To disable this message, do "/msg *route_replies silent yes"
<*route_replies> Last request: MODE #somesecretchannel I
Alexey Sokolov [Sat, 5 Nov 2011 04:51:53 +0000 (11:51 +0700)]
Change the order of -I directives in Makefile.
If ZNC was already installed, it had its headers somewhere.
The chances are that something else can be installed at the same place,
including some ZNC's dependency whose include dir would be included to
CXXFLAGS. Another possibility of including that dir is triggered when
using FreeBSD - ./configure explicitly adds -I/usr/local/include in that
case.
And so we get a directory with old ZNC headers included to CXXFLAGS
before our new shiny ./include.
With their order changed, the proper headers are included now.
Thanks to those who repored the issue, thanks to PsWii60 for helping to
track it down, thanks to my parents for creating me and therefore
enabling me to fix it, and to many other people.
Uli Schlachter [Thu, 3 Nov 2011 07:54:23 +0000 (08:54 +0100)]
Don't use "mkdir" during install
lahwran just showed up on irc and told us that he installed znc, but znc failed
to find any modules. The reason for this was his umask 077 which means that
"make install" installed stuff so that only root can access it.
The solution is do use "install -d" since that makes sure to ignore the
currently set umask.
However, google finds results which say that "install -d" might mess with stuff
of pre-existing directories when it shouldn't, so we must first test if the
directory already exists before calling install. Obviously, this makes our
Makefile a lot more readable. :-(
I didn't have time to test this properly, so stuff might break.
This avoids your irc windows being filled with away stuff
Downside of antiidle is that because it messages yourself internally
the irc server will send messages to you when you're marked as away.
This can end up being really annoying, so those messages are blocked
with these changes.
Robby found a bug with evil ChanServ which goes like this:
- You join an empty, but registered channel and the IRCd applies its default
modes (+nt), but ZNC didn't ask for MODE, so doesn't know this.
- ChanServ applies whatever channel modes it wants to apply. This causes ZNC to
see a mode change (e.g. +s).
The result of this is that ZNC thinks that the channel has mode +s and it will
tell every client that connects to it about this.
The fix is to send a MODE request when JOINing. To make sure that we don't
confuse clients, we block the reply.
Modern/decent networks have services anyway, and for registered channels
this module is useless. Also it tends to fight ChanServ in case if
ChanServ joins/parts the channel to remove ops.
Users of deprecated ne^W^Wnetworks without services can use it from extra.
Uli Schlachter [Mon, 29 Aug 2011 12:02:39 +0000 (14:02 +0200)]
Drop @DEFS@ from the build system
This will only ever be set to -DHAVE_CONFIG_H. However, we shouldn't give this
flag to other people's code (e.g. through znc-config). Since we don't need it,
it's best to just drop it completely.
Jim Hull [Tue, 13 Sep 2011 22:03:09 +0000 (15:03 -0700)]
rework SendBuffer fixing an issue where ClearBuffer() nuked the buffer after playing to the first client
(cherry picked from commit 793c34699a0de8a384cea359821beea66c1a00a4)
Jim Hull [Tue, 13 Sep 2011 06:03:03 +0000 (23:03 -0700)]
fixed a null reference to pClient in hooks 'OnChanBufferStarting,OnChanBufferStarting,OnChanBufferEnding,OnChanBufferEnding', such that when pClient is NULL the hooks are called on all clients associated to that user
Jonas Gorski [Sun, 4 Sep 2011 10:54:09 +0000 (12:54 +0200)]
fix build error when compiling against uclibc(++)
Fixes the following error:
In file included from ZNCString.cpp:10:0:
FileUtils.h: In static member function 'static CString CDir::GetCWD()':
FileUtils.h:246:36: error: 'getcwd' was not declared in this scope
Signed-off-by: Jonas Gorski <redacted> Signed-off-by: Uli Schlachter <redacted>
This should stop all fights against ChanServ. Please note that nothing will
happen if we are the only one in the channel after 15 secs since this module
only checks if it needs to do something when someone leaves a channel.
Uli Schlachter [Fri, 5 Aug 2011 13:02:04 +0000 (15:02 +0200)]
Include zncconfig.h in all headers
The rule is that zncconfig.h must be the very same thing that is included. We
cheat and only include it in headers (so that modules dont have to have be
changed). However, it looks like some modules where missed.
This commit fixes test/ConfigTest which crashed if _GLIBCXX_DEBUG was enabled
(--enable-debug) because it didn't see this define before including a c++
header.
Uli Schlachter [Wed, 3 Aug 2011 20:05:21 +0000 (22:05 +0200)]
Stop asking for the host name in --makepem
Come on, it's a self-signed certificate, how much value does it have anyway?
Also, it gets rid of a question during --makeconf which confuses some people.
This should now use $HOSTNAME and fall back to "host.unknown" if that isn't set.
Since commit 1a1cc4c756e, we'd always send a "MODE #chan" to IRC when we
received a "JOIN #chan". It used to work before that commit, because the mode
reply which is automatically sent on join is sent before the "end of /names"
numeric.
This just removes that MODE request. Proper IRC server should always send a MODE
reply on channel join.
When we hit the "maximum open files" limit, we close the listener that hit this
error. Previously we did so silently which means no one could figure out what
happened.
This commits adds a broadcast message giving a hint, but this should never
happen in a real-world situation anyway (unless you have 1000 users).
This fixes the "busy loop waiting for an SSL handshake to finish" which the last
"Update to latest Csocket" was already supposed to fix. However, that fix had a
bug if poll() is used instead of select().
poll()'s timeout argument is in milliseconds while select also allows
microseconds. Since Csocket originally used select(), it expects the
microseconds-approach. This means it has to divide by 1000 to get the timeout
argument for poll().
However, the iQuickReset which was used to "fix" (rather: hide) the busy loop
was less than 1ms so this still resulted in a timeout of 0 (= busy loop) because
integer division truncates the result.
This means that they will get a new cookie on the next request. This will make
sure that you will be able to use webadmin again if your IP changed (which seems
to happen to quite a number of people).
This helps people figuring out that they are still building their modules for
the wrong znc version since they have more than one installation on their box.
Uli Schlachter [Sun, 26 Jun 2011 10:11:40 +0000 (12:11 +0200)]
Update to latest Csocket
Fixes:
- A possible crash bug for empty DNS replies with c-ares. E.g. a AAAA lookup for
google.com doesn't give any reply but is still successful. This might be a
c-ares bug (there is ARES_ENODATA) or c-ares just changed its behavior?
(No bug report, just noticed accidentally)
- Connecting to ipv4-only hosts with a v6 bindhost caused weird errors:
https://github.com/znc/znc/issues/47
- There was a pull request for some DSA server certificate thingy:
https://github.com/znc/znc/pull/46
- Busy loop waiting for an SSL handshake to finish:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631590
- Some other stuff? No idea what some of the changes in here are actually doing.
Uli Schlachter [Mon, 13 Jun 2011 13:19:17 +0000 (15:19 +0200)]
Fix a bug in MCString::Encode()
For character values above 127, the signed char that could be used here did the
wrong thing. That is, *it >> 4 returned a negative value and the array hexdigits
was read indexed with that wrong value.
Fix this by explicitly using unsigned char.
Thanks to crocket for reporting this bug which he found with perform (broken
entries after a restart/reload).