: ) */
From: Coder-com [mailto:coder-com-boun...@undernet.org] On Behalf Of Aaron
Kaufman
Sent: Tuesday, March 17, 2015 1:33 PM
To: coder-com@undernet.org
Subject: [Coder-com] bug in m_info.c
The code in mo_info() and ms_info() is fubar'ed and results in global opers
*NOT* seeing either the
The code in mo_info() and ms_info() is fubar'ed and results in global opers
*NOT* seeing either the oh-so-grateful-to-our-ancestors infotext, or the
perhaps more critical md5 hashes of all of the .c and .h files coded.
Moreover, it violates HIS in a very tiny way by allowing lusers to see the
md5 h
Please be advised that, due to increasing levels of spam, we have turned
off anonymous posting of bugs via the SourceForge bug tracking tool.
This means that you will need to acquire a SourceForge account in order
to post bug reports. This process should be relatively painless, and
posting via the
I agree. Original message follows.
On Thu, Jun 12, 2003 at 09:52:18PM +0100, Chris Crowther wrote:
> On Thursday 12 Jun 2003 9:30 pm, you wrote:
>
> > channels should be listed with the channel name clearly shown... and either
> > display the topic, or show "" (or something similiar) in
> > it's
> > How about we drop +p as a separate mode and make it do +s for
> compatibility?
> > --
> > Kevin L. Mitchell <[EMAIL PROTECTED]>
The most important difference is (or used to be, dunno
if that still works as-is) that when you are on a channel
that is +s then you cannot be found with a wildcard /
On Fri, Jun 13, 2003 at 01:43:06PM +0200, Carlo Wood wrote:
> The most important difference is (or used to be, dunno
> if that still works as-is) that when you are on a channel
> that is +s then you cannot be found with a wildcard /WHO
> if you'd otherwise have matched. This isn't the case
> when
Agreed. That's exactly what you use it for. As is implies fixing it to
work properly though I'd assume :)
At 10:08 PM 6/12/2003 -0600, Captain Kirk wrote:
I always found +p useful for those who wanted to find the channel, and
weren't just people looking to pester someone. +s hides completely,
> > I can't see a constructive difference between showing the channel names
as
> > Prv and hiding them completly. The only way it would make sense is the
way I
> > stated, otherwise +p and +s become analegous and +p is just there for
> > historical reasons.
>
> How about we drop +p as a separate m
On Thursday 12 Jun 2003 9:55 pm, you wrote:
> How about we drop +p as a separate mode and make it do +s for
> compatibility?
Yeah, or just remove it entirely, people would soon stop using it *g*
--
hikari
[EMAIL PROTECTED]
oper @ London.UK.EU.Undernet.Org
> I can't see a constructive difference between showing the channel names as
> Prv and hiding them completly. The only way it would make sense is the way I
> stated, otherwise +p and +s become analegous and +p is just there for
> historical reasons.
How about we drop +p as a separate mode
On Thursday 12 Jun 2003 9:30 pm, you wrote:
> channels should be listed with the channel name clearly shown... and either
> display the topic, or show "" (or something similiar) in
> it's place.
Which is pretty much what I said. +p *should* be visible on /list, but
should be hidden on a
I'd agree 100% The point I was making was that the historical versions of
ircu (2.9) showed them as "*"... at least 2.9.32 did. I would say that +p
channels should be listed with the channel name clearly shown... and either
display the topic, or show "" (or something similiar) in
it's place.
On Thursday 12 Jun 2003 8:25 pm, you wrote:
> Unfortunately for whatever reason this is _not_ the way the current version
> of ircu works. Both +p and +s are totally hidden from /list (it doesn't
> even show a "*" or "Prv" like some older ircd versions did).
I can't see a constructive di
At 18:23 12-06-2003, Tom Rons wrote:
> My view of it was this:
>
> +p does not show in /list at all
> +s shows in /list with channel name as "*" but topic visible
Why do I have the odd feeling that it's acually the other way around? :)
AFAIK +p channels are shown, but without their name (+s not sho
This is what I've always thought as well (though I thought the topics were
supposed to show up as well? I suppose that's a minor detail) and is borne
out in the way that I use +p on my own channels. I use it if I am going
somewhere and I don't want people in that channel to /whois me and follo
According to my look at ircu 2.9.32 (the last version of 2.9) it was the
other way around... except that the topics were also hidden for +ps.
if (cptr->user && !(SecretChannel(chptr) && !IsMember(cptr, chptr)))
{
nr--;
sendto_one(cptr, rpl_str(RPL_LIST), me.name, cptr->name,
Ummm... +p channels were _always_ showed in /list as I recall.
"Secret" implies totally secret -- i.e: you can't find out about it unless
you already know the name.
"Private" implies that your existence on the channel is "private" unless
they already know the name... or if they start /join'ing
> +p does not show in /list at all
> +s shows in /list with channel name as "*" but topic visible
>
are you sure its not the other way around?
> My view of it was this:
>
> +p does not show in /list at all
> +s shows in /list with channel name as "*" but topic visible
Why do I have the odd feeling that it's acually the other way around? :)
AFAIK +p channels are shown, but without their name (+s not shown in
list at all, if you're not on
>
> Although afaic we know longer send "Prv" as the channel name for a Private
> (+p) channel...I don't know if anyone ever did tbh. I believe the
intended
> operation is that Private channels will show up on LIST, without their
topic,
> but membership of the channel is not visible through use of
At 09:28 12-06-2003, you wrote:
On Thursday 12 Jun 2003 5:43 am, Captain Kirk wrote:
[snip /list +s/+p discussion]
My view of it was this:
Both show up on /list if you are in the channel.
Both show up on /whois'ing someone else if you are in the channel.
+p does not show in /list at all
+s shows
On Thursday 12 Jun 2003 5:43 am, Captain Kirk wrote:
> I always thought it was the other way around. If you set +p, the channel
> won't appear in /list but if you whois someone who "is" in the channel it
4.2.6 List Message
"[...] Private channels are listed (without their topics) as chann
>
> I have found what I think is a bug in the /list command. Mainly that +p
> channels do not seem to show up.
>
> It was always my understanding that the major (only?) difference between a
> PRIVATE and a SECRET channel is that PRIVATE channels show up in
> /list. This is the way I have always u
I have found what I think is a bug in the /list command. Mainly that +p
channels do not seem to show up.
It was always my understanding that the major (only?) difference between a
PRIVATE and a SECRET channel is that PRIVATE channels show up in
/list. This is the way I have always used +p...
It seems that ircu doesn't send RPL_ENDOFNAMES when requesting NAMES of a
channel you are not in remotely.
--
volta
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> > This will block all eembots that were active on the channel because of =
> > 'Internal database doesn't match with server' and it is not compliant to =
> > the RFC1459. Can you please take a look at this?
I believe this is fixed in one of the rec
> > When someone parts a channel, the server will send a message to all =
> > clients that the one has parted
> >
> > in older versions it looked like
> >
> > PART #holland
> > now it is:
> > PART :#holland
> > with a semicolor before the #
> >
> > This will block all eembots that were active on t
Trying without HTML then :)
> When someone parts a channel, the server will send a message to all =
> clients that the one has parted
>
> in older versions it looked like
>
> PART #holland
> now it is:
> PART :#holland
> with a semicolor before the #
>
> This will block all eembots that were act
Okay, just tried it! 8)Bug submitted on the site for 2.10.11
Note that I'll be forced to revert to the old version if we can't find why
the server isn't able to deal with netburst anymore in this version. 8(
regards,
radium
On the 6 Octobre 2002 22:45, you wrote :
> Greetings. As so
On Wed, Oct 09, 2002 at 12:14:03AM +0100, [EMAIL PROTECTED] wrote:
> I'm assuming this trivial fix will nail it (but haven't tested of course).
Update: tested, applied, deployed.
splidge
QuakeNet person
Hi all,
I've found a bug in m_stats.c.. it puts the stats character the user asked
for into a signed char value, which is bad news if it's a char with
value > 127...
(yes, some luser just cored our test server again)
I'm assuming this trivial fix will nail it (but haven't tested of course).
--
Greetings. As some of you have no doubt figured out by now, our CVS
repository is now hosted by SourceForge. This isn't the only resource
SourceForge provides us with--we also have access to their "artifact"
tracking system. Currently, the undernet-ircu project on SourceForge
has three trackers
lt;[EMAIL PROTECTED]>
To: "C-C people" <[EMAIL PROTECTED]>
Sent: Friday, August 09, 2002 6:18 PM
Subject: Re: [Coder-Com] bug with BAN cmd (level 74-)
NicoS,
it could maybe explain why, but it's still not normal that X lets USP get
ops to then deop it cause it isnt
/msg X op #chan [nick].
Feel free to correct me if I'm wrong.
Hidden
- Original Message -
From: "éL NìçoS" <[EMAIL PROTECTED]>
To: "Hidden" <[EMAIL PROTECTED]>
Cc: "Undernet Coder Committee" <[EMAIL PROTECTED]>
Sent: Friday, August
stray @ Krey.Net
- Original Message -
From: "Hidden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 09, 2002 5:50 AM
Subject: [Coder-Com] bug with BAN cmd (level 74-)
People on this list,
Here's the problem:
[23:43] -> *[EMAIL PROTECTED]* b
People on this list,
Here's the problem:
[23:43] -> *[EMAIL PROTECTED]* ban #chan *usp*!*@* 24 74 uh
[23:43] *** X sets mode: -oo USP USPDB
[23:43] -X- Added ban *usp*!*@* to #chan at level 74
[23:44] [23:43] -X- Added ban *usp*!*@* to #chan at level 74
[23:44] *** X sets mode: +o USP
[23:44] *
Hello Imad,
Sunday, June 16, 2002, 6:22:41 AM, you wrote:
Ie> hi , some one reported that on #coder-com
->> *x* access #close tracker2 -modif
Ie> -X- USER: Tracker2 ACCESS: 420 LU
Ie> -X- CHANNEL: #close -- AUTOMODE: None
Ie> -X- ** SUSPENDED ** - Expires in 0 days, 05:08:30 (Level 400)
Ie> -X-
hi , some one reported that on #coder-com
-> *x* access #close tracker2 -modif
-X- USER: Tracker2 ACCESS: 420 LU
-X- CHANNEL: #close -- AUTOMODE: None
-X- ** SUSPENDED ** - Expires in 0 days, 05:08:30 (Level 400)
-X- LAST SEEN: 0 days, 02:42:25 ago.
-X- LAST MODIFIED: (MeSteRR) DoM`[EMAIL PROTECT
I suppose we could have a separate list, but that just seems sort of
bureaucratic.
On Thu, 2 May 2002, Kev wrote:
>
> > All this talk about X ... Does that belong on this list?
>
> X is a module of GNUWorld, which is a coder-com-sponsored project.
> Therefore discussion of it is appropriate for
On Thu, 2 May 2002, Kev wrote:
> X is a module of GNUWorld, which is a coder-com-sponsored project.
> Therefore discussion of it is appropriate for this list.
"so nuh!"
--
Chris "_Shad0w_" Crowther
[EMAIL PROTECTED]
http://www.shad0w.org.uk/
> All this talk about X ... Does that belong on this list?
X is a module of GNUWorld, which is a coder-com-sponsored project.
Therefore discussion of it is appropriate for this list.
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
ECTED]
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
De la part de Hidden
Envoyé : 1 mai, 2002 18:09
À : [EMAIL PROTECTED]
Objet : [Coder-Com] bug with the unban cmd
OUTsider,
/msg X unban #chan Hidden was suppose to remove only the bans matching
the
nick Hidden (*!*
All this talk about X ... Does that belong on this list?
In order to preserve synchronization it is necessary for
the servers to remove all bans that are overlapped
by a new ban that is set. That means that when someone
(including when that someone is X) sets a ban *!*@*
then ALL bans are remove
You'll have to excuse my feeble mind on this one:
> Thats indeed a bug, and when it'll be fixed, I think the unban issue with
> *!*@* can be forgotten. That cmd SHOULD remove only bans matching
> [EMAIL PROTECTED] (*!*@*) and not the 2 others (*!*[EMAIL PROTECTED] and
> the other)
When setting t
. :-)
That's my theory, which would explain your test.
- Original Message -
From: Hidden <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 01, 2002 5:09 PM
Subject: [Coder-Com] bug with the unban cmd
| OUTsider,
|
| /msg X unban #chan Hidden was suppose to rem
OUTsider,
/msg X unban #chan Hidden was suppose to remove only the bans matching the
nick Hidden (*!*@*) but it didnt.
Coders, There is a bug here.
[18:01] -> *[EMAIL PROTECTED]* ban #test-chan *!*[EMAIL PROTECTED]
[18:01] -X- Added ban *!*[EMAIL PROTECTED] to #test-chan at level 75
[18:01] -> *
On Wed, Apr 24, 2002 at 06:20:57PM -0400, Hidden wrote:
> Dear ircu coders,
>
> I think I found a very little bug and thought should let you know about it.
>
> /msg will say: no such nick.
> /notice will return nothing.
It's normal behaviour. You should *never* send an (automatic)
reply in
At 23:20 24/04/2002, you wrote:
>Dear ircu coders,
>
>I think I found a very little bug and thought should let you know about it.
>
>/msg will say: no such nick.
>/notice will return nothing.
>[18:16] -> *akvn* uh
>(Script/18:16:08) No such nick: akvn
>[18:16] -> -akvn- uh
From rfc1459:
T
> I think I found a very little bug and thought should let you know about it.
>
> /msg will say: no such nick.
> /notice will return nothing.
> [18:16] -> *akvn* uh
> (Script/18:16:08) No such nick: akvn
> [18:16] -> -akvn- uh
This is by design, actually. NOTICE is usually used when no resp
Dear ircu coders,
I think I found a very little bug and thought should let you know about it.
/msg will say: no such nick.
/notice will return nothing.
[18:16] -> *akvn* uh
(Script/18:16:08) No such nick: akvn
[18:16] -> -akvn- uh
Telnet:
:Haarlem.NL.EU.UnderNet.Org NOTICE hidd :on 1 ca 1(4
On Wed, Feb 27, 2002 at 07:37:03AM +1300, Isomer wrote:
> In this case it will not squit. It checks to see if the timestamp is
> more than 5 minutes in the *future* not the past, so lag will only make
> the test *less* likely to succeed.
Ah ok. What about that it seems to KILL the client
who cr
> While implementing apass1-2, my eye fell on m_create.
> It seems that what happens there should be changed.
>
> Firstly, the last exit_client KILLs sptr, a client. It doesn't SQUIT
> the server of sptr. But changing this into squitting the server of
> sptr would be at least as wrong - conside
While implementing apass1-2, my eye fell on m_create.
It seems that what happens there should be changed.
The code currently is:
int ms_create(struct Client* cptr, struct Client* sptr, int parc, char* parv[])
{
...
if (IsServer(sptr))
return protocol_violation(sptr,"%s tried to CREATE a ch
Its missing a new language entry (You may have seen it used on Undernet
warning you not to give out passwords). To fix, run this from the doc/
directory in your gnuworld repository:
psql dbname I don't know if this is just buggy for me or not, I compiled a new
version of
> gnuworld for a "pl
Please do not send HTML email to this list.
> -X- AUTHENTICATION SUCCESSFUL as tang--X- Unable to retrieve
> response. Please contact a cservice administrator.
I'm not very familiar with X's current architecture, but two possibilities
come to mind. The first is that the language tables haven't
I don't know if this is just buggy for me or not, I compiled a new version of gnuworld for a "play" network for some friends and myself. Whenever I compiled gnuworld I didn't receive any errors, it all compiled without a problem, however when I login to X I get this:
-> *[EMAIL PROTECTED]* login
> > When doing /who ~* x and /who * it don't show all the users, even it don't
> > show a end of who list.
> > And it shows actions that the people send to the server.
>
> Just to eliminate the obvious--have you verified that this isn't a client bug,
> perhaps by telnetting to the server and attem
> My Oper password is 12 char long, I did a mistake when typing it and it
> worked. Example: /Oper Math MYPASSWORDWORD instead of MYPASSWORD
>
> Server version : u2.10.10.pl18.(release). *.PartyNet.Org
> B27eEFfHIKMpRStUvW
1) Please do NOT send HTML emails to this list. The HTML portion of your
- Original Message -
From:
Mathieu
René
To: [EMAIL PROTECTED]
Sent: Sunday, January 20, 2002 11:20
AM
Subject: [Coder-Com] Bug report for
ircu2.10.10.pl18
My Oper password is 12 char long, I did a mistake when typing
it and it worked. Example:
/Oper Math
On Sun, 20 Jan 2002, Mathieu René wrote:
> My Oper password is 12 char long, I did a mistake when typing it and it
> worked. Example: /Oper Math MYPASSWORDWORD instead of MYPASSWORD
>
> Server version : u2.10.10.pl18.(release). *.PartyNet.Org
> B27eEFfHIKMpRStUvW
>
> Math
> [EMAIL PROTECTED]
>
i
My Oper
password is 12 char long, I did a mistake when typing it and it worked. Example: /Oper
Math MYPASSWORDWORD instead of MYPASSWORD
Server version : u2.10.10.pl18.(release).
*.PartyNet.Org B27eEFfHIKMpRStUvW
Math
[EMAIL PROTECTED]
> When doing /who ~* x and /who * it don't show all the users, even it don't
> show a end of who list.
> And it shows actions that the people send to the server.
Just to eliminate the obvious--have you verified that this isn't a client bug,
perhaps by telnetting to the server and attempting to r
When doing /who ~* x and /who * it don't show all the users, even it don't
show a end of who list.
And it shows actions that the people send to the server.
#amsterdam LiNkS^ Hiw ~[EMAIL PROTECTED] :2 Victor Hugo
#krushnet spin Hi ~[EMAIL PROTECTED] :3 chris
#krushnet Maniac G*@wg ~[EMAIL PROTECTE
Ltd.
> From: "Diego Pappa" <[EMAIL PROTECTED]>
> Date: Fri, 28 Dec 2001 11:02:59 -0300
> To: <[EMAIL PROTECTED]>
> Subject: [Coder-Com] Bug
>
> I have install in my IRC service IRCU clients 2.10.7 and HUB 2.10.4.
>
> I have problems with the stats c
I have install in my IRC service IRCU clients
2.10.7 and HUB 2.10.4.
I have problems with the stats command I like
protect this command to see only for the opers this step was configuration in
the compiling step or in the ircd.conf???
Thanks a lot!!
Diego
i think regardless of how many bans have been set and how screwy they
are, if in any of the modes set that one is superior ie *!*~*@*, ircu
wont waste time and effort whilst its being set, but wait till modes
have been stopped being sent by the client, then it will work out if
they are valid, repe
66 matches
Mail list logo
