A hackint node at 28c3 is up and running! It is called reacher.hackint.eu and can be used with and without SSL.
This node is primarily intended for users attending the 28c3. You can use this node even if the connectivity to the rest of the worls goes down, as this hackint node is located directly at 28c3 noc.
reacher.hackint.eu has a certificate signed by the hackint ca.
Some hints on how to successfully join hackint using tor:
First, you need tor. Obviously. :) Then, you need to do your DNS requests via tor. This is essential, as the hackint hidden service domain, w4a6ssearu46yphm.onion, does not exist on "normal" DNS servers. Also, the IP behind it needs to be mapped by tor, so it needs to see the DNS request first.
Next, the ports you can use with tor are 6697 and 9999. This means your IRC client will have to support SSL! If it doesn't, choose one that does.
If your IRC client does not support socks, and you're using some unix, install socat and do:
socat tcp-listen:6697 socks4a:127.0.0.1:w4a6ssearu46yphm.onion:6697,socksport=9050
Next, do as root:
echo 127.0.0.1 irc.hackint.eu >> /etc/hosts
Now, while socks is running, point your irc client to irc.hackint.eu, port 6697, and tell it to use SSL. Enjoy anonymous irc.
Also, make sure in your torrc config file that tor listens for socks connections on port 9050.
Hackint's just gotten a new Certificate Authority, the hackint CA. To use it, visit our website, http://www.hackint.org/, and fetch the root certificate from there. It is going to be gpg-signed by more and more hackint admins.
More and more hackint servers' certificates are being signed with hackint's ca; at the moment, the following ones are:
To verify the certificate with irssi, place the root certificate somewhere, for example in /var/certs/hackint-ca.pem. Then issue in irssi:
/server -ssl -ssl_verify -ssl_cafile /var/certs/hackint-ca.pem $(SERVERNAME)
Please note that only once all of hackint's servers' certificates are signed can you reliably connect to the rotations irc.hackint.org or irc.hackint.eu with ssl verification enabled. Until then, you'll have to connect to an individual server whose certificate is already signed by the hackint ca, or verification will fail from time to time (every time the rotation hits a server whose certificate is not yet signed by hackint's ca)
In case of questions or problems, please join #hackint and ask!
This is harder than it might sound, at least if you are using hybrid ircd, which we do.
We have just applied a patch to our services, which means that in the future, you will not have to reidentify with nickserv after netsplits (provided your own connection to the server was not cut).
If you are interested in IRC internals, you can read more about that patch.
We check your IP against some blacklists to prevent abuse. Unfortunately, often times, abuse is done from a TOR exit node. Hence, many TOR exit nodes were blocked, preventing legitimate hackint users from using the network in an easy manner (cycling through different exit nodes usually helped).
We have now resolved the situation in a radical manner: all connections from TOR exit nodes are allowed, no matter how often they were blacklisted. Let's see how it works out :)
Note: should you get KLINED when connecting from an exit node - do not hesitate to complain to us using the email address given in the KLINE message! (You see the kline message when trying to reconnect).
We have upgraded our services package, atheme, to version 5.2.1. Atheme provides our NickServ and ChanServ facilities. 5.2.1 is the new stable version.
A little patching was necessary, as we use a combination of hybrid ircd and ratbox ircd. We believe these patches to be stable. :)
We have also - finally - added support for the +S chanmode to ChanServ's MLOCK command. If you do not know what mlock is, /msg chanserv help set mlock might enlighten you.
As always, ask in #hackint if anything is unclear to you.
Due to a blackout at TU Darmstadt earlier this weekend, one of hackint's servers, lechuck.hackint.eu, will be offline until late monday afternoon. Services are not affected by this. Please use the irc.hackint.eu rotation to make sure you always get a working server.
We've had the pleasure of some spammers lately, and you do have to admire their humour:
18:13 < spamremoval> to get your irc server and channel removed from our spam list, please visit this page: http://bit.ly/dqkvHa
We've decided to fight the spamming problem by checking all users against some blacklists. There's BOPM, but it requires a configuration for each irc server, which is hard to maintain.
Our stats code has been extended; a plugin infrastructure has been added, and the first usable plugin is the security greasel, a creature that checks all users connecting to a hackint irc server against blacklists and issues a kline if the IP is blacklisted.
If you find bugs in the code, or have written a patch, let us know. :}
We generate stats to see which hackint server is used by how many users and how many total users we have at any time.
The old version was buggy, and so we've decided to reimplement it. The current version is written in Erlang, and we already had to use the hot code swapping feature once. The code is available on the commercial platform github.
It's tradition to have a hackint server at the easterhegg. The idea behind this is that if the (usually unstable) easterhegg internet connection fails for any reason, IRC still works.
This year's easterhegg hackint server will be available during the event (probably not before Friday late evening) at easterhegg.hackint.eu.
You can register your nickname on hackint, and subsequently assign rights to it by registering a channel or being added to the access list of another channel. You can also use the GHOST command to terminate an old, yet-to-time-out connection of yours, allowing you to reuse your nick sooner after a network problem.
In addition to that, you can now prevent other people from using your nick: If someone is using your nick, you can have them renamed by issuing /msg NICKSERV RELEASE NICK PASSWORD. After that, your nick is taken by services for 30 seconds, so in order to use the nick yourself you have to issue the RELEASE command a second time.
If you want extra security, you can also enable automatic nickname enforcement. This will rename any user using your nick without identifying properly after 30 secods. You enable it by issuing /msg NICKSERV SET ENFORCE ON.
Today, I'd like to tell you about the little known user mode +g, which has been of use to me in the past.
A little background on IRC modes: Think of modes as attributes for irc channels and users altering their default behavior. There's two types of modes: parametrized modes, and flag modes. There are no parametrized user modes, only channel modes. Parametriezed channel modes consist of the mode character which designates the desired alteration, and a list of subjects it applies to (in the context of the channel).
Now back to the +g user mode. What it does is it prevents any user to private message you, meaning users can only contact you by writing to a channel you are also in. The good thing about +g: you are notified of attempts to contact you, so can whitelist people to exempt them from the ban.
While we have little to no spammers on hackint, +g also exists on some of the more noisy networks.
It was there from the very beginning of hackint: the channel mode +S. What does it mean?
It is simple: +S channels can only be joined by clients connected to hackint via an encrypted connection (SSL/TLS). Until recently, the ircd error message was everything but verbose:
Cannot join channel. (+S)
We've changed this to a more verbose and meaningful error message. I hope this prevents future confusion about this matter.
We've recently switched from anope to atheme IRC services. IRC services is a piece of software that provides facilities like NickServ and ChanServ.
NickServ allows you to register your nickname, which means you can prevent others from using that nickname. You can also register channels for your nickname, and other people who have registered a channel can add your registered nickname to their channel's access list, meaning for example you are automatically given chanop status upon joining a channel and identifying with nickserv.
We've imported the anope database into atheme, which means old nickname and channel registrations are kept. Some things are new, though:
In addition to the xOP channel permission system used by anope, atheme offers a more fine grained, flag based access system. Issue /msg ChanServ help flags to find out more.
In case you don't remember your NickServ password, you don't have to ask a staffer anymore to reset it for you. Instead, simply request NickServ to send you a reset email by doing: /msg NickServ sendpass $(NICKNAME). If you haven't got a valid email address set, then we've got a problem that's not easily solved. Thus, I recommend you set a valid email address for your nickname if you haven't done so already. You set an email address by issuing: /msg NickServ SET EMAIL your@email.address
To sum it up: the basic things stay the same (identification, channel permission management), so you don't have to learn anything new to work with the services. However, if you are founder or SOP of a channel, I recommend you take a look at what the new ChanServ offers you.
Some long time annoyances are gone. This includes ChanServ joining every registered channel upon services restart to reset the topic and/or channel modes, and the random deopping that happened after restarts / netsplits.
When evility.net first thought about joining hackint, we were very excited about it, but there were some details that needed to be sorted out first.
First of all, evility uses ratbox, we use hybrid. While the two ircds are pretty much compatible, there's some obstacles. For example, hackint uses halfops. A halfop is much like a chanop, only they can't kick chanops and de-op chanops. ratbox does not support halfops.
The way irc works is you have many versions of a channel, one for each irc server. The channels are identified by their names. As long as the ircservers are connected, all channels of the same name are synchronized. So for example, we have #hackint on stoertebeker.hackint.org, and we have #hackint on lechuck.hackint.org. Both servers talk to each other, about joining/leaving users, and about what is being said in either channel, ultimately making #hackint appear the very same on both of them. Now, what happens if one ircserver tells another ircserver to halfop a user, but that ircserver does not know what a halfop is?
We tested this: a user joined and was given halfop status by a chanop logged in from a hybrid server. The user appeared to have be given regular channel operator status on all ratboxen. So far, no problem. Now, the next thing that happened was that a regular chanop on a ratbox machine deopped the halfop, thinking he was a normal chanop. On all ratboxen, the halfop subsequently appeared to be a normal user - while on the hybrids he still had the halfop status.
As a result, the halfop was still able to kick normal users, and to all inhabitants of the channel that were connected from a ratbox it appeared as though a normal user was capable of kicking another normal user.
Conclusion: no big deal. We have only one channel that uses halfops at all and after talking to them, it turned out they don't absolutely them. :}
A little later, we found out that KLINEs work differently on ratbox and hybrid. The solution was found with the help of an efnet operator: just patch the services to emit two KLINE commands: one that is understood by the ratboxen, one that is understood by the hybrids.
A little background information about KLINEs: a KLINE is an automated, semi-permanent KILL that is stored in an ircd configuration file line (hence the name KLINE). Such an entry says, for example, if hc@salato.hcesperer.org connects, immediately disconnect them from the network (i.e. KILL them). KILLing someone in IRC means killing their ego at worst, merely killing their connection at best. KILLs are usually issued if a user turns out to be a spambot or of similar sinister nature. Sometimes, people are also KILLed on their birthdays if a better birthday present is not at hand. Rumor has it that people criticising IRC operators are KLINEd from time to time. That may be true on some networks, but such unprofessional bullshit will never happen on hackint.
Another, yet to be solved, however minor problem is the fact that ratboxens mod_forcejoin is incompatible to hybrid's.
We're pleased to announce that evility.net has joined hackint.
evility.net is a small IRC network using ratboxen (hackint was exclusively using hybrid so far) and mostly FreeBSD. They have two main channels: #evility, which is mostly about technology and FreeBSD related stuff; #doebeln is a regional channel.
There were a few technical issues that needed to be solved prior to the join; most notably the lack of halfops on the ratboxen, and some other protocol interoperability problems. Some of them are already fixed, some still need to be fixed. In case of problems, feel free to visit #hackint and complain. You may want to watch our stats, where the join should manifest itself in a few minutes.
Personally, I'm happy we could complete the join today, because way we can make use of evility's webchat for tonight's C-RadaR show now. :}
Hackint's services, which include ChanServ and NickServ, take note of every mode change that happens on hackint. A mode change happens, for example, if someone gives you op status in a channel.
Why do the services have to know? Because, for example, when you use ChanServ to register a channel, you must be opped in this channel. So ChanServ looks up your nickname in its user table to check if you actually are. If the services fail to properly take notice of mode changes, chances are, you cannot use them as intended. In this example, your request to register a channel would be denied.
The problem is actually simple: in hackint, we assign a UID to each username, which is comprised of a 3 character server ID (SID) and a 7 character random ID. On one occasion, services failed to convert between nickname and UID. This bug has long gone unnoticed, but is now fixed. Which means you can now register channels to your heart's content. ;-) Happy REGISTERing!
We've recently moved our irc services (anope) to stoertebeker, where they were recompiled with debugflags and no optimizations.
In the past, we have experienced three problems with anope:
We're on it...
