FWIW, this is Cygwin 1.7
From all I can tell, it's trashing the ',' and anything
after it.
Note that it happens with SERVER_REALM_OPTION as well,
which has a ',' too.
$ /usr/local/bin/shishi.exe --verbose --client-name=jblaine | more
option: verbose-asn1
option: verbose-noise
option: verbose-crypto
option: verbose-crypto-noise
option: realm-kdc=PROJ1.OUR.ORG,proj1-kdc.our.org
Found REALM_KDC_OPTION
'value' = PROJ1.OUR.ORG
add_realm is true, executing block around line 208
nrealminfos = 1
BREAKING OUT
case -1, then no value, breaking out
option: server-realm=PROJ1.OUR.ORG,.our.org
Found SERVER_REALM_OPTION
'value' = PROJ1.OUR.ORG
case -1, then no value, breaking out
option: stringprocess=UTF-8
option: quick-random
option: stringprocess=UTF-8
Shishi initial library configuration:
Default realm: PROJ1.OUR.ORG
Default principal: (NULL)
Client KDC etypes: aes256-cts-hmac-sha1-96
Verbose: -1
Ticket life: 28800 seconds. Wed Oct 27 04:41:05 2010
Renew life: 604800 seconds. Tue Nov 2 20:41:05 2010
KDCs for realm PROJ1.OUR.ORG:
option: (null)
option: verbose
Building KDC-REQ...
...etc...
On 10/26/2010 7:20 PM, Simon Josefsson wrote:
Jeff Blaine<[email protected]> writes:
FWIW, building under Cygwin works, but the resulting shishi
does not properly parse etc/shishi/shishi.conf
Hmm, I answered my own question. No, it doesn't work with
libidn installed either.
Libidn only matters for non-ascii username/passwords, so it wouldn't
explain issues like this.
Note that it completely ignores the realm-kdc line of the
config file, but DOES pick up the default-realm ... weird.
Yes, I think you identified the problem.
realm-kdc=PROJ1.OUR.ORG,proj1-kdc.our.org
...
KDCs for realm PROJ1.OUR.ORG:
KDCs for realm PROJ1.OUR.ORG:
Your config looks fine. The two lines here indicate something strange
is going on. When I test your config file on a debian box I get this:
KDCs for realm PROJ1.OUR.ORG:
Transport UDP host proj1-kdc.our.org port (null)
If you can debug what is happening in lib/cfg.c (search for 'case
REALM_KDC_OPTION') that would really help.
It could be a problem with 'getsubopt' under Windows. Maybe the gnulib
module isn't kicking in properly, or there is a bug in it. Glibc
systems have getsubopt built in.
Maybe there is some CRLF issue? As far as I can tell, it should ignore
both \r and \n but at least worth debugging further if you can easily
rewrite the file with different EOL encodings.
/Simon
_______________________________________________
Help-shishi mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-shishi
