View Issue Details

IDProjectCategoryView StatusLast Update
0004032unrealircdpublic2015-05-25 10:58
Reportersyzop Assigned Tosyzop  
Status resolvedResolutionfixed 
Target Version3.4-alpha1Fixed in Version3.4-alpha3 
Summary0004032: Restructuring link block
DescriptionProposal to restructure the link { } block in 3.4*:

link <server-name> {
    username <usermask>;
    hostname <ipmask>;
    bind-ip <ip-to-bind-to>;
    port <port-to-connect-on>;
    password-connect <password-to-connect-with>;
    password-receive <password-to-receive> { <auth-type>; };
    hub <hub-mask>;
    leaf <leaf-mask>;
    leafdepth <depth>;
    class <class-name>;
    ciphers <ssl-ciphers>;
    options {

link <server-name> {
    incoming {
        mask *@;
        // may contain multiple masks: or should this be in a separate { mask ...; mask .. } ?
        password <password-to-receive> { <auth-type>; };
    outgoing {
        bind-ip <ip-to-bind-to>;
        hostname; /* may also be an IP */
        port 6697; /* or move the hostname & ip into one item ? */
        password <password-to-connect-with>;
        options { ssl; zip; autoconnect; };
    hub <hub-mask>;
    leaf <leaf-mask>;
    leafdepth <depth>;
    class <class-name>;
    ciphers <ssl-ciphers>;
    options {
        quarantine; /* is a generic option */

* split into incoming & outgoing to make everything less obscure
* split helps with dynamic ip setups, previously one could only use that with nohostcheck, now you can still have some IP security as you don't need to allow all ips.
* usermask & hostmask is now just 'mask' in incoming side
* allow multiple masks in incoming
* nodnscache: make this the default
* nohostcheck: no longer needed
* ssl: moved to outgoing: obviously decided by outgoing connect to an ssl port or not
* zip: previously required on both in&out: but why? get rid of incoming side requirement. IIRC this is possible.
TagsNo tags attached.
3rd party modules



2011-07-21 13:48

reporter   ~0016732

My problem with the current link block is that too many things are required.

link::outgoing::password should be made optional (and default to `*' I guess) since a server using sslclientcert ignores the password. link::outgoing::port should default to 6667 even though use of the default would be discouraged.

Only one of link::outgoing or link::incoming should need to be specified. Not specifying link::incoming should have the same effect as setting link::incoming::mask to "NOBODY" ( This is sorta suggested by ). If link::outgoing is missing, then link::outgoing::hostname would be defaulted to `*'. Unless if marking a link block as supporting ingoing or outgoing connections is done at a deeper level ;-).


2013-01-03 05:21

reporter   ~0017294

"link::outgoing::port should default to 6667 even though use of the default would be discouraged."

I disagree. There should not be any default ports. Many set-ups are private and may not want to use common ports. The only way I can see forcing a default port would be with something like set::options::default-port so admins can choose their own default upfront.


2013-01-05 10:19

administrator   ~0017298

* agreed with either having link::outgoing or link::incoming is enough. we could use the suggested logic and put '*'/'NOBODY' for outgoing/incoming hostname when not specified
* outgoing password optional is ok (incoming obviously not ;p)
* might be a good idea to, as suggested, detect a '*' hostname for outgoing and print out a more descriptive error than trying to resolve '*' to something etc. etc.
* I tend to agree with keeping port mandatory, if you make this optional it will stay at 6667 too much while we in fact want to encourage specific server-port setups.
* all the original comments stay intact ;)

I'd like to see this in 3.4


2015-05-25 10:58

administrator   ~0018341

Done in 3.4-alpha3:

(some more pending)

There's one change in the link block structure I posted earlier. "password" has been moved out incoming & outgoing and is now a single item:
move to a single password entry in link block: "password in link block should be plaintext OR should be the SSL fingerprint of the remote link (=better)"

.. as there's little benefit of using hashed passwords if the other password needs to be specified in plaintext anyway.. if you care about security then you should use SSL certificate (fingerprints).

TODO: improve error, add some wiki explaining all this and add the link in the error....

TODO 2: better error for people upgrading from 3.2.x.

Issue History

Date Modified Username Field Change
2011-07-19 16:57 syzop New Issue
2011-07-19 16:58 syzop Status new => feedback
2011-07-21 13:48 ohnobinki Note Added: 0016732
2013-01-03 05:21 katsklaw Note Added: 0017294
2013-01-05 10:19 syzop Note Added: 0017298
2013-01-05 10:20 syzop Status feedback => confirmed
2013-01-05 10:20 syzop Description Updated View Revisions
2013-01-05 10:20 syzop Target Version 3.3-alpha0 => 3.4-alpha1
2015-05-25 10:58 syzop Note Added: 0018341
2015-05-25 10:58 syzop Status confirmed => resolved
2015-05-25 10:58 syzop Fixed in Version => 3.4-alpha3
2015-05-25 10:58 syzop Resolution open => fixed
2015-05-25 10:58 syzop Assigned To => syzop