View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003441 | unreal | module api | public | 2007-07-13 15:46 | 2019-12-28 09:44 |
Reporter | aquanight | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | closed | Resolution | open | ||
Platform | x86 | OS | Linux Gentoo | OS Version | 2.6.17 |
Product Version | 4.0-devel | ||||
Summary | 0003441: Things that need change or features to be implemented in Unreal4 to match things in Unreal3 | ||||
Description | ==== If you contribute patches of some of these issues, please make a new bug report for them. It will make QA much easier. ===== Just a small collection of things I've found that could be changed to make u4 more like u3: - m_cloaking.cpp: Change to unreal 3.x algo, using arbitrary strings, etc. - m_hidechans.cpp: Change to usermode +p, same as unreal 3.x - m_messageflodd.cpp: Extend to full support of u3-style +f (eg +f [5c#C3]:2 etc). Probably will require a fair bit of work. - Make m_filter.pcre.so enabled by default (unless we don't find pcre in configure). - Extended bans (~q, and so forth). - m_alias.cpp: Change the placeholders to be a bit more u3-like: %# instead of $#, %#- instead of $#-, allow %-# and %#-#, %n instead of $nick, also possibly do: %u instead of $ident, %h instead of $host, %v instead of $vhost - Seperate cloaked host from virtual host, like u3. Add usermode +t, unsetting drops from virthost to cloaked host. I'm sure this isn't an exhaustive list. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
3rd party modules | |||||
related to | 0003467 | resolved | Implement U3 cloaking algorithm for U4 | |
related to | 0003509 | resolved | Implement "ban version" blocks from U3 | |
related to | 0003514 | closed | Include-Directive needs to support wildcards | |
related to | 0003443 | closed | Linking with previous stable version (U3) | |
child of | 0003417 | closed | TODO list for Unreal4.0 |
|
I submitted a few of my own...but I will add on here from now on. Sorry. -0003442 -0003443 -I think in each oper block (previously known as o:Line). You should have a block called the host-override. Let's assume this is in an oper block for a netadmin. host-override { Founder.IEatTooMuch.Net; }; So when they Operup, their host changes to that regardless of the preset VHost of someone of that oper type. In other words: If later in the conf you have hosts { netadmin "Network-Administrator.IEatTooMuch.Net"; }; So when that person, with the host-override, opers up. They will not get the preset netadmin host, they'll get their own. Thus overriding the host. -Keep the Oper system they have setup. (Keep it and I'll stay in the #Unreal-Support channel to help out) -Make sure Services packages like Anope have no issues working with U4. Instant compatibility? -When rehashing local/remote servers make the server GlobOps the result. That way if there is an error in the conf, it can be seen without going on that server. -Have IRCd run in Unicode right out of the box. Including NickNames, Idents, vHosts, and Real Names. -Make /LUSERS command not include U:Lined Servers. There may be more to come.... |
|
Also make snomasks use umode +s. Insp has server notices as +s, and then snomasks under +n... |
|
There's also no global z:line... and if z:lines are global, there is no local only |
|
Adding on: -(I forget of InspIRCd has this) Make/Keep an oper command called /chgnick <old nick> <new nick> So we can change a nickname without the need for services. But also, keep /svsnick |
|
Insp has chgnick, called SANICK (m_sanick.so) |
|
Okay I modify my request... -Change /SANICK to /CHGNICK -Keep USERMODE +Q as part of the U4 Distro |
|
ALso... -Get rid of the error that occurs when a U:Lined server sets modes via "MODE" instead of FMODE. Gives you some bull about possible desync and what not. |
|
[quote]-Change /SANICK to /CHGNICK[/quote] Keep in mind this goes along with a few other commands generally thought to be service-admin things (sajoin, sapart, samode). To be honest, I'm not even sure if sanick/chgnick needs to be in our distribution, since we shouldn't really encourage people to just be abusive. Changing someone else's nick is rarely useful on a network. [quote]-Keep USERMODE +Q as part of the U4 Distro[/quote] This would be more a "make u4 like insp" not "make u4 like u3". And in this case we're going with the "make it like u3": +Q will not be part of the distribution. At all. Invisibility like this was taken out from 3.2 for several good reasons (unethical, illegal, it gave u3 a kind of bad name iirc). It will not be in u4 for the same reasons. [quote]-Get rid of the error that occurs when a U:Lined server sets modes via "MODE" instead of FMODE. Gives you some bull about possible desync and what not.[/quote] I can't say I know much about insp server protocol, but I find this somewhat sensible: having services/operoverride modechanges as FMODE means less special cases for MODE that have to be worked in. |
|
About /sanick vs /chgnick...a general pattern I've seen, feel free to correct me, is /chg* = localops can do it, /sa* = services-asmins can do it. I would think nickchanging other users would be restirtced to services-admins since nicknames are pretty much their department. |
|
I don't really understand how +Q/+I can be considered unethical. It's the same principle as changing your nick, ident, host, realname, and setting +H and spying on a channel. It just makes the job easier for IRCOperators. Maybe you could keep the mode, but make a login for it, or an OperFlag for it. To keep it secure. This would have been helpful on my IRC Network when I had an issue with bots. I couldn't get into their channel due to +iK. And I couldn't just change nick and such and just randomly show up. I know you have your mind made up...and I'm wasting my breath. But I just have to question what I don't comprehend. How can that be considered unethical? |
|
[quote]I know you have your mind made up...and I'm wasting my breath. But I just have to question what I don't comprehend. How can that be considered unethical?[/quote] For starters, it can be considered illegal in some places. Plus there's, ultimately, better ways to do this, that don't require massive code hacks like the old +I apparently was. Since the removal of +I in 3.2-beta*, unreal has had the policy of: "Never again." For the same reason, we don't provide support for people who use modules such as m_spy. This is why the main page of this very bugtracker had, for a long time (I think sts has done something to it), a post saying exactly this, that +I is gone permanently. Likewise, insp's +Q will not be part of u4's distribution, and don't count on us providing support for anyone who uses it. |
|
Okay. Just out of my curiosity. What are the better ways to accomplish spying, without spoofing your own information and hoping the channel isn't +is? |
|
ngrep. google it. now can we get off the subject of +Q and stuff?! |
|
And my retort to ngrep, then finished. I had simplicity in mind. Yet still spying. Oh well. *tries to think of anything else* AH NICKCHARS! -I'm not sure how you want to handle the NickChar / Ident / Host / RealName situation. Insp uses some module where you can specify your own custom ident/host characters. Basically, you can add multibyte stuff and the whole sort. |
|
The third-party module m_whoismodes.cpp (originally coded by ViaraiX) outputs the usermodes in /WHOIS for IRC operators. I've taken the liberty of cosmetically modifying the code and submitting it here (i'm not too sure if this is the right place to do this) so that it looks like the original usermode output on the Unreal3.2.* branch. I hope this helps. I'm not much of a coder, but i'll help where I can. ;-) |
|
[quote]I don't really understand how +Q/+I can be considered unethical. It's the same principle as changing your nick, ident, host, realname, and setting +H and spying on a channel.[/quote] Changing your nick/username/host(mask)/realname are all changes to your online identity that any user can do, so we expect that. Setting +H does not hide your identity, it just hides the fact that you are an oper, like how +p hides channels you are in. None of the above change the fact that when someone is in a channel, everyone knows that someone is in there. They may not know who, but they do know someone is there, so then they may choose to keep private/sensitive convos out of the channel due to an unknown user. Usermode +Q/I completely hides you from everyone else(One of them lets other opers see you). So what happens next, for example, is that 3 users who know each other have a conversation containing comments they don't want other people to see, because they don't see an unknown user in there. being in that channel but +Q/I is an invasion of privacy. A very loose analogy would be turning yourself invisible to watch someone have a shower. If you don't want people to think that the nicklist is a lie, explicity tell them or don't respond to /names and /who #channel at all. [quote]This would have been helpful on my IRC Network when I had an issue with bots. I couldn't get into their channel due to +iK. And I couldn't just change nick and such and just randomly show up.[/quote] Bots say something useful in channel? If not: /who #channel If so: Clone on the server with a different nick and use sajoin, override or m_uline to get into the channel. Sorry about the off-topic aquanight, I really wanted to respond. |
|
m_invisible does not have to be included in the default distribution. This module can be offered on a 3rd party module site or from the inpsircd website itself. Because of the uncertainty of legality and morality of the module, its best to leave it out, and let people who really want it get it from other places, like what I said above. |
|
Secure connection message in whois uses SWHOIS numeric (I think) on Insp |
|
Uploaded patches for m_ssl_gnutls and m_ssl_openssl. Someone delete the .cpp files of these modules please :) |
|
==== If you contribute patches of some of these issues, please make a new bug report for them. It will make QA much easier. ===== |
|
Check bans against cloaked host and virtual host. Currently insp/u4 only checks realhost. In the process of looking at ban code to find that out, I've also found that implementing extbans might not be as easy as originally thought. May require an extension on the IsBanned function. Thank goodness for C++ overloading ;) . |
|
Not sure if it is in Insp already, but u4 definitely needs a /saumode to forcechange a user's modes. Additionally, I run into some problems when services go down yet u3 still has modes that require +r to be set (+M,+R,etc.) Services-admins at the least should be able to set +r on a user (using /saumode of course). |
|
I thoroughly disagree. nobody except servers/services should be able to set umode +r on a user. +r is kinda like +z, it's a promise of a particular property that the user possesses. |
|
One major issue I can see, many who run Unreal 3.2.x are using FreeBSD 4.x legacy stable branch. Will the new code be able to run properly on legacy stable branches (as from reports I received Inspire doesn't run properly on the legacy branches even with newer gcc installed). |
|
On that issue.. I'll have to highlight two things regarding that: http://www.freebsd.org/portmgr/policies_releng_4.html - FreeBSD 4.* is EOL, EOS - FreeBSD 6.1 is more than stable for a upgrade. Basically - last release was in 2005. Also, from our project paradigms: http://dev.unrealircd.com/unrealircd_project_paradigms "Backwards compatibility wrt. OS'es are kept at a level representing current common server operating systems in use, but not if it hinders innovation that could improve the quality of user experience for the majority of users, but if there is a way to easily keep backwards compatibility, this will be done." Based on this, we dropped Amiga support to make it possible to make Unreal3.2 modular - Amiga doesn't have dlopen() support We dropped Win95/98/ME support of same reason. We dropped NT4 support of same reason - the APIs limitations were simply keeping us back and damaged user experience. I admit loosing old OS support is sad, and that we cannot run on old OS'es - but the fact is, this move has many benefits for Unreal itself. There's practically no danger for simply upgrading a server that should have been upgraded already - there's even compat4x in the versions so binaries will keep on running. I admit it'll incur downtime for a provider - but when I see a 800day update on a shell provider where there's several known kernel exploits, it scares me that people would even run their IRCds on that. Like any server provider, let it be web server, etc, they should follow the new versions to not experience security problems and there's honestly no excuse not to upgrade. |
|
Hide +j and +f secondary variables from /LIST for regular users. I reckon this could pose as a security threat of sorts, as then people that abuse channels can adjust their method of attack to be within these thresholds. |
|
ban version { } is in Unreal3 , and for me very useful. This has been discussed on Inspircd homepage. But I hope you will consider it. :-) http://www.inspircd.org/forum/showthread.php?t=74 |
|
I don't think U4 has restrict umodes/cmodes... This has been an excellent feature for many networks |
|
See 0003514. Include should support wildcards. |
Date Modified | Username | Field | Change |
---|---|---|---|
2007-07-13 15:46 | aquanight | New Issue | |
2007-07-13 15:46 | aquanight | Relationship added | child of 0003417 |
2007-07-13 21:13 | aquanight | Relationship added | related to 0003442 |
2007-07-13 21:15 | aquanight | Relationship added | related to 0003443 |
2007-07-13 22:28 | eLement | Note Added: 0014481 | |
2007-07-13 22:28 | eLement | Note Edited: 0014481 | |
2007-07-14 12:00 | Stealth | Note Added: 0014487 | |
2007-07-14 16:37 | Stealth | Note Added: 0014489 | |
2007-07-14 22:56 | eLement | Note Added: 0014490 | |
2007-07-14 23:08 | Stealth | Note Added: 0014491 | |
2007-07-15 10:25 |
|
Status | new => acknowledged |
2007-07-15 18:00 | eLement | Note Edited: 0014481 | |
2007-07-15 18:05 | eLement | Note Edited: 0014481 | |
2007-07-15 18:07 | eLement | Note Added: 0014497 | |
2007-07-15 18:09 | eLement | Note Added: 0014498 | |
2007-07-15 21:58 | aquanight | Note Added: 0014500 | |
2007-07-16 03:37 |
|
Sticky Issue | No => Yes |
2007-07-17 01:42 | Shining Phoenix | Note Added: 0014504 | |
2007-07-17 01:51 | eLement | Note Added: 0014505 | |
2007-07-17 20:21 | aquanight | Note Added: 0014517 | |
2007-07-17 20:41 | eLement | Note Added: 0014518 | |
2007-07-17 21:10 | aquanight | Note Added: 0014519 | |
2007-07-18 00:10 | eLement | Note Added: 0014520 | |
2007-07-18 14:07 | CuttingEdge | File Added: m_whoismodes.cpp | |
2007-07-18 14:12 | CuttingEdge | Note Added: 0014521 | |
2007-07-18 14:52 |
|
Summary | [Unreal4] Some things to make it more Unreal3-like => Things that need change or features to be implemented in Unreal4 to match things in Unreal3 |
2007-07-18 17:52 | Shining Phoenix | Note Added: 0014522 | |
2007-07-18 17:53 | Shining Phoenix | Note Edited: 0014522 | |
2007-07-18 17:53 | Shining Phoenix | Note Edited: 0014522 | |
2007-07-19 11:10 | dmb | Note Added: 0014527 | |
2007-07-19 19:16 | Stealth | Note Added: 0014528 | |
2007-07-19 19:25 | Stealth | File Added: m_ssl_gnutls.cpp | |
2007-07-19 19:25 | Stealth | File Added: m_ssl_openssl.cpp | |
2007-07-19 19:26 | Stealth | Note Added: 0014529 | |
2007-07-19 19:28 | Stealth | Note Edited: 0014529 | |
2007-07-19 19:44 | Stealth | Note Edited: 0014529 | |
2007-07-19 19:44 | Stealth | File Added: m_ssl_gnutls-whoisnumeric.patch | |
2007-07-19 19:44 | Stealth | File Added: m_ssl_openssl-whoisnumeric.patch | |
2007-07-19 22:06 | aquanight | File Deleted: m_ssl_gnutls.cpp | |
2007-07-19 22:06 | aquanight | File Deleted: m_ssl_openssl.cpp | |
2007-07-20 06:37 |
|
QA | => Not touched yet by developer |
2007-07-20 06:37 |
|
U4: Need for upstream patch | => No need for upstream InspIRCd patch |
2007-07-20 06:37 |
|
U4: Upstream notification of bug | => Not decided |
2007-07-20 06:37 |
|
Description Updated | |
2007-07-20 06:37 |
|
Note Added: 0014531 | |
2007-07-20 10:44 | aquanight | U4: Upstream notification of bug | Not decided => U4-only issue |
2007-07-20 10:44 | aquanight | U4: Contributor working on this | => None |
2007-07-20 10:44 | aquanight | Description Updated | |
2007-07-20 11:38 | aquanight | Note Added: 0014538 | |
2007-07-23 09:14 |
|
Status | acknowledged => confirmed |
2007-07-23 09:21 |
|
Relationship deleted | related to 0003442 |
2007-07-26 14:12 | kevind23 | Note Added: 0014598 | |
2007-07-26 15:20 | tabrisnet | Note Added: 0014599 | |
2007-07-26 15:48 | jschurawlow | Note Added: 0014600 | |
2007-07-26 15:57 |
|
Note Added: 0014601 | |
2007-07-28 06:16 | CuttingEdge | Note Added: 0014616 | |
2007-07-31 11:00 | klaus | Note Added: 0014640 | |
2007-07-31 11:20 | Stealth | Note Added: 0014641 | |
2007-08-11 21:36 | aquanight | Relationship added | related to 0003467 |
2007-08-11 21:51 | aquanight | Relationship added | related to 0003509 |
2007-08-12 14:40 | apti | Note Added: 0014722 | |
2007-09-21 19:47 | aquanight | Relationship added | related to 0003514 |
2009-07-24 01:09 | Stealth | Status | confirmed => closed |
2017-01-06 15:48 | syzop | Category | module => module api |
2019-12-28 09:44 | syzop | Sticky Issue | Yes => No |