View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003223unrealircdpublic2007-02-02 13:402011-12-25 17:00
ReporterJasonTik Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
OS*OS Version* 
Product Version3.2.6 
Target Version3.3-alpha0Fixed in Version3.3-alpha0 
Summary0003223: Undocumented max link pass length
DescriptionOur network recently found out that there is a maximum link password length. It is undocumented, and less than 40. After this length, your links will always fail, even if your passwords match.

Please remove or document this limit.
TagsNo tags attached.
Attached Files
s_conf.patch (1,085 bytes)
3rd party modules

Activities

djGrrr

2007-02-02 14:23

reporter   ~0013161

I noticed this before too when trying a longer link password, was quite a while trying to figure out why my servers wouldn't link together, i didn't bother to report it at the time. Quite annoying to say the least.

aquanight

2007-02-02 15:10

reporter   ~0013162

The limit is 32 (see struct.h, #define PASSWDLEN).

I too am not entirely certain why this limit exists as the password field in struct Client is not staticly allocated like nick/user/hostname.

I should note that I don't recall any of our hardlimits being documented. Some are obvious. Particularly, NICKLEN=30 is in 005, and USERLEN=10 and HOSTLEN=63 are usually obvious (origins being UNIX usernames and DNS hostnames). REALLEN=50 isn't obvious, neither is CHANNELLEN=32, PASSWDLEN=32, KEYLEN (+k) =23, LINKLEN (+L)= =32 (could've just been #define LINKLEN CHANNELLEN).

Perhaps all of these should be documented.

JasonTik

2007-02-02 15:56

reporter   ~0013163

Last edited: 2007-02-07 21:39

 I would like to point out my servers gave no errors of any kind at passing this limit. Documented or not, at least hitting the others gives an error.

[edit:typo]

WolfSage

2007-04-15 17:03

reporter   ~0013413

How about issuing a warning when parsing the conf file? Would that suffice?

stskeeps

2007-04-21 03:26

reporter   ~0013624

Write patch for s_conf warning for this and i'll patch it. Honestly, I would rather have a error when PASS is called with a too long password instead, since there are so many auth types.

WolfSage

2007-04-21 11:52

reporter   ~0013625

The attached patch will fail if password-connect or password-receive is > PASSWDLEN (48 characters in 3.3alpha).

I do agree, however, that PASS needs to be modified accordingly. Currently it silently truncates, though still passes on the original password as part of the argument.

It shouldn't difficult to have PASS throw an error, but how should we do it? globops notice? locop notice? ...

Stealth

2007-04-21 11:56

reporter   ~0013626

Last edited: 2007-04-21 11:58

 Input

*edit* I think it should check and error when the conf is read, just like any other conf error

WolfSage

2007-04-21 11:59

reporter   ~0013627

Last edited: 2007-04-21 12:00

 Well if a pass that we missed for some reason is being truncated, we could at least throw warn to local operators

Stealth

2007-04-21 23:32

reporter   ~0013628

for backwards compatibility?

When it comes to linking, it should be sent as the link error

stskeeps

2007-04-24 05:40

reporter   ~0013656

Patched in .2373, however, i changed config_error to config_warn, as it should really be a hint instead.

syzop

2011-07-19 14:11

administrator   ~0016705

target: 3.3

use the patch, not the old 3.3 commit... I'd like an error in 3.3, not a warning.

syzop

2011-12-25 17:00

administrator   ~0016834

Last edited: 2011-12-25 17:06

 - Throw up an error if a password in the configuration file is too long
  (max 48 characters), reported by JasonTik, based on patch from
  WolfSage (0003223).

http://hg.unrealircd.com/hg/unreal/rev/46f02ee7e5f3

Used part of the patch for password-connect. But instead of using it for password-receive I modified Auth_CheckError() to throw a warning on plaintext passwords of size > PASSWDLEN instead.
This is because it should be limited to plaintext passwords, otherwise you would get an error if, for example, you provided a long filename/path of a certificate... which has nothing to do with the password length in the user struct so should be permitted ;)

Issue History

Date Modified Username Field Change
2007-02-02 13:40 JasonTik New Issue
2007-02-02 14:23 djGrrr Note Added: 0013161
2007-02-02 15:10 aquanight Note Added: 0013162
2007-02-02 15:56 JasonTik Note Added: 0013163
2007-02-02 15:57 JasonTik Note Edited: 0013163
2007-02-07 21:39 JasonTik Note Edited: 0013163
2007-04-15 17:03 WolfSage Note Added: 0013413
2007-04-18 05:11 stskeeps Status new => acknowledged
2007-04-21 03:26 stskeeps Note Added: 0013624
2007-04-21 11:49 WolfSage File Added: s_conf.patch
2007-04-21 11:52 WolfSage Note Added: 0013625
2007-04-21 11:56 Stealth Note Added: 0013626
2007-04-21 11:58 Stealth Note Edited: 0013626
2007-04-21 11:59 WolfSage Note Added: 0013627
2007-04-21 11:59 WolfSage Note Edited: 0013627
2007-04-21 12:00 WolfSage Note Edited: 0013627
2007-04-21 23:32 Stealth Note Added: 0013628
2007-04-24 05:40 stskeeps Status acknowledged => resolved
2007-04-24 05:40 stskeeps Fixed in Version => 3.3-alpha0
2007-04-24 05:40 stskeeps Resolution open => fixed
2007-04-24 05:40 stskeeps Assigned To => stskeeps
2007-04-24 05:40 stskeeps Note Added: 0013656
2011-07-19 14:11 syzop Note Added: 0016705
2011-07-19 14:11 syzop Assigned To stskeeps =>
2011-07-19 14:11 syzop Status resolved => has patch
2011-07-19 17:11 syzop Target Version => 3.3-alpha0
2011-12-25 17:00 syzop Note Added: 0016834
2011-12-25 17:00 syzop Status has patch => resolved
2011-12-25 17:00 syzop Assigned To => syzop
2011-12-25 17:06 syzop Note Edited: 0016834