At the moment ngircd fails the tests for reproducible builds in Debian
since it uses the __DATE__ and __TIME__ macros for the INFO command.
Instead of patching this out I decided to implement an optional
constant BIRTHTIME that allows you to set a time stamp for the "Birth
Date" information, in seconds since the epoch, like in
export CFLAGS += -DBIRTHTIME=$(shell date +%s --date="2015/08/15 23:42:22")
In the future, Debian will provide a SOURCE_DATE_EPOCH environment
variable, dealing with the situation until then will be my job.
The time format was taken from the NGIRCd_StartStr formatting in
ngircd.c so the "Birth Date" and "On-line since" lines in the INFO
output look similar:
:irc.example.net 371 nick :ngIRCd 22.1-IDENT+IPv6+IRCPLUS+PAM+SSL+SYSLOG+ZLIB-x86_64/pc/linux-gnu
:irc.example.net 371 nick :Birth Date: Tue Aug 25 2015 at 18:11:11 (CEST)
:irc.example.net 371 nick :On-line since Tue Aug 25 2015 at 18:11:33 (CEST)
:irc.example.net 374 nick :End of INFO list
The format of the time stamped is changed, but as far as I can tell, there's no
rule that is violated by that.
Bonus level: Reformat the messages so the time stamps are aligned.
AUTH is a valid nickname so sending notices to it is probably not
a good idea. Use * as the target instead as done with numerics
when the nick is not available.
This mimics the behaviour in Charybdis, IRCD-Hybrid, InspIRCd 2.2,
Plexus 4, etc.
Reconnecting to ngIRCd 22.1 built with OpenSSL with some OpenSSL
clients, including Pidgin and stunnel 5.06, attempts to reuse a session
and fails due to the absence of this line.
The error message in syslog from ngIRCd is:
> SSL protocol error: SSL_accept (error:140D9115:SSL
> routines:SSL_GET_PREV_SESSION:session id context uninitialized)
This patch appears to fix the problem for both Pidgin and stunnel; it
may work for other OpenSSL clients that attempt to re-use sessions.
* <https://github.com/ngircd/ngircd/issues/182>
* <https://developer.pidgin.im/ticket/11568>
* <https://www.openssl.org/docs/ssl/SSL_CTX_set_session_id_context.html>
* LucentW/master:
Fix with oneshot invites
Fixed building issues\
Implement timestamp tracking of invites
Keep track of who placed bans/invites/excepts
IRC operators w/OperCanMode can kick anyone [already cherry-picked]
Closes#203, Closes#205.
For example, Interix is missing this function, which prevented
ngIRCd to build on this platform. When setgroups(3) isn't available,
a warning message is issued when ngIRCd starts up.
lightIRC and other clients expecting RPL_LISTSTART should now behave correctly.
Closes#207.
(cherry picked from commit 0680ce5fd99bc643651d1433bcdaf271aeb73c46)
Up to now, only the the string ("haystack") became lowercased and was
the compared to the pattern ("needle") -- which failed, when the pattern
itself wasn't all lowercase ...
- Update documentation in ngircd.conf(5)
- LIST: Don't hide channels for IRC Ops when "MorePrivacy" is in effect
- WHOIS: Don't hide IP addresses/hostnames when "MorePrivacy" is in effect
Closes#198
Now lists nodes also have the "onlyonce" field, since the valid_until is
used to keep the timestamp of placing. Found no references to onlyonce
or about valid_until being == 1, though, so it might be unused, but
still available for other enhancements.
Implement user mode "I": Hide channels on WHOIS
User mode +I prevents ngIRCd from showing channels on WHOIS.
IRC Operators can always see those.
Closes#197.
Implement ERR_USERNOTONSERV(504) numeric and make sure that the
target user is on the same server when inviting other users to
local ("&") channels.
ircd-ratbox uses the ERR_USERNOTONSERV(504) numeric for this, and I
think this is a good idea -- other IRC daemons (like ircu) silently
drop such impossible invites, but thats not a big benefit ...
Idea by Cahata, thanks! Closes#183.
Up to now when receiving a MODE command, ngIRCd only reported the channel
creation time to clients that were members of the channel. This patch
reports the channel creation time to all clients, regardless if they are
joined to that channel or not.
At least ircd-seven behaves like this.
This closes#188. Thanks Cahata!
Alexander Barton