View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004043unrealircdpublic2011-09-19 00:052012-02-26 21:42
Reportermaxb Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status confirmedResolutionopen 
Product Version3.2.8 
Summary0004043: Caution about mismatched cloak-keys should also apply to hiddenhost-prefix ?
Descriptionhttp://www.unrealircd.com/files/docs/unreal32docs.html#setblock cautions that cloak-keys must be the same on all linked servers. It seems to me that the same caution also ought to apply to hiddenhost-prefix?

Ideally the ircd would also check for mismatches at link time in much the same way cloak keys are checked.
TagsNo tags attached.
3rd party modules

Relationships

related to 0004090 resolvedsyzop Clarify that hiddenhost-prefix must be the same on linked servers for bans to function properly. (see 0004063) 

Activities

katsklaw

2011-09-19 04:07

reporter   ~0016750

Last edited: 2011-09-19 04:08

 The difference is that cloak keys are used for hashing, hidden host prefix is a text field and isn't checked or really even cared about when linking. ircd1 will send real and hidden hosts.

hidden-something.my-isp.net will not clash or desync with somethingelse-something.my-isp.net because it's a simple plain text replacement for that quad and isn't hashing it.

maxb

2011-09-19 23:09

reporter   ~0016751

Both the cloak-keys (via hashing) and the hiddenhost-prefix (via simply being prepended) contribute to the overall string form of the hidden host.

Surely then, it's equally important that both be the same, to ensure that the a given real host turns into the same hidden host, whereever on the network it is hidden?

maxb

2011-10-30 02:29

reporter   ~0016764

I've just found the following in doc/technical/serverprotocol.html (in the NETINFO section):

"The cloak-prefix is currently not sent here (and thus unreal won't generate warning for mismatching cloak prefixes, but they should be the same anyway)."

So this is a known issue, it seems.

Issue History

Date Modified Username Field Change
2011-09-19 00:05 maxb New Issue
2011-09-19 04:07 katsklaw Note Added: 0016750
2011-09-19 04:08 katsklaw Note Edited: 0016750
2011-09-19 23:09 maxb Note Added: 0016751
2011-09-20 19:04 syzop Status new => confirmed
2011-10-30 02:29 maxb Note Added: 0016764
2012-02-26 21:42 syzop Relationship added related to 0004090