IRC-Junkie.org – IRC News

All about Internet Relay Chat

Tag Archives: IRC

Mac OS X IRC Client Textual Version 2.1 Hits AppStore

The OS X IRC client Textual just got released as version 2.1 in the Mac OS AppStore.

 

What has begun as a fork of LimeChat has quickly evolved into something very distinct and usable, which was a main point of critique with the original.

Textual Mac OS X IRC Client

Textual Mac OS X IRC Client

Textuals’ feature-set is really complete: themes, plugins and an extensive range of configuration options.

One neat feature is the inline display of graphics and YouTube video thumbnails so you know what you’re going to click on even before you click.

What really sets Textual apart from other clients on OS X is its stability – crashes and lockups are really far and few between, if any. Attaching to a bouncer with log-replay doesn’t take longer than a few seconds even for a channel # in the high double-digits.

 

Textual is a fully Lion-compatible and also supports fullscreen IRCing so you’re no longer distracted by work when you’re chatting with your buddies ;)

 

Since 2.1 it now supports SASL plaintext auth, IPv6, regular expression support for highlights and it already complies with Apples’ new sandboxing requirement for Apps distributed via the AppStore.

 

The client is a paid-for app and costs $4.99, is available as a Trial version and even can be built by yourself from source.

 

AppStore link: Textual

Changelog

IRC Defender arbitrary code execution exploit

Yesterday, news broke that there is an arbitrary code execution exploit within the still popular IRC security service IRC Defender which is, according to the reporter, being actively exploited.

The flaw is said to be within the InspIRCd link module for which a patched version exists, but according to the original post to the IRC-Security mailinglist there are more flaws within the InspIRCd link module and also within the UnrealIRCd link module.

The original poster on the mailinglist suggests to get rid of IRC Defender immediately and to replace it with something else (have a look at Omega Security Services) and also to check for signs of recent intrusions which have taken place on or after 15th November. He also urges to look out for rogue entries in ~/.ssh/authorized_keys and look for suspicious processes.

So far, at least three networks seem to have been exploited due to this flaw – the highest profile victim so far seems to be the hack of the AnonOps network which also seems to have been possible due to that flaw – contrary to the rumored Anope 0-day.

Original post on the IRC-Security mailinglist is here (needs registration).

Thanks to alyx for the tip etc!

The patched inspircd12.pm link module can be obtained from here.

UnrealIRCd 3.2.9 – New stable version after 2 years

UnrealIRCd, the IRCd that still dominates the usage statistics of all IRCds, has seen another stable release and is now at version 3.2.9.

After 2 release candidates and with 212 changes and bugfixes – almost the same amount as the last three stable releases combined – among which is a “substantial amount of new features” as Syzop writes in their announcement.

He thanks everyone that made this release possible but especially mentions binki who did a “considerable amount of work to make this release possible”.

And indeed, there is a large amount of changes – for example:

  • Extended Bans (new modes introduced, ban stacking behaviour)
  • Extended Invite Exceptions / Invex
  • New Channelmode +Z which works in conjunction with +z (SSL only) and is set once every joined user is on SSL which might not be the case during netsplits/-joins
  • Remote MOTD support
  • Remote includes caching so that an old version of a remote include is loaded in case the webserver containing the include is down
  • /rehash -global – rehashes all servers at once
  • STARTTLS – connect to a “regular” port SSL encrypted
  • IPv6 clones detection support, defaults to /64

A small excerpt of the bugs that have been fixed:

  • Low connection frequencies (connfreq) no longer pose a problem due to reworking the corresponding code
  • IPv6 related fixes
  • an obscure crash bug that only occured rarely on outgoing connects

Work on UnrealIRCd 3.3 already has begun and is, according to development plans, the replacement for the often retried and ultimately failed rewrite which was to be released as UnrealIRCd 4.

The release announcement can be found here and the full changelog for changes since UnrealIRCd 3.2.8.1 is here (you need to scroll all the way down).

Hybrid releases 7.3.0

Earlier this week, Jon Lusky released a new version of ircd-hybrid. The version number has now reached 7.3.0. Among the changes you find a new Bulgarian translation, a fixed IPv6 implementation and channel modes O and S for opers-only respective SSL/TLS-only clients. Server administrators now get to choose whether they want to use SSLv3 or TLSv1 to secure connections. All spy-notice modules that previously covered reports for usage of STATS, TRACE, MOTD and ADMIN have been replaced by server-sided notices. The old LazyLinks concept has now been removed, as it was half broken. The WATCH command known from UnrealIRCd and Bahamut has been added. In addition to that, a few minor cleanups and bugs leading to crashes have been fixed.

Hybrid is used together with Ratbox (which is a fork) and CSIRCd on both EFnet and IRCsource. It has been forked many times and it’s known for its stability and quality of code.

By looking at the SVN repository it seems like the developer team behind Hybrid is working towards a 8.0 release, featuring better services support while still keeping simplicity.

A Day on QuakeNet

A nice visualization of a normal day on the “largest internet relay chat Network in the world” brings us meeb of QuakeNet:

He goes on to write that the video shows “one day of activity, 24 hours, midnight to midnight in UTC, on the QuakeNet IRC network summarised into a 12 minute data visualisation” and that “each dot represents a new user connecting to the network, there are some 400 new connections per minute on average in this visualisation”.

The data which the video was rendered of has been “collected strictly anonymously at a high level” by a network service that “already stores connection data in memory” meeb emphasizes.

Talking about the technical aspects of the video, meeb explains that the “final visualisation was produced using processing” – the total amount of data processed was 14GB that took about 8 hours on a fast PC according to meeb.

The resulting 1080p video was about 8GB in size for the 12 minute visualization and re-rendering that into a h264 video took “another 5-6 hours”.

For more information, read the original post here.

And yes, now i’m curious on how such a visualization would look like for other networks :)