From rt-comment at krbdev.mit.edu Tue Sep 1 21:30:13 2009 From: rt-comment at krbdev.mit.edu (Luke Howard via RT) Date: Wed, 2 Sep 2009 01:30:13 +0000 (UTC) Subject: [krbdev.mit.edu #6555] k5_pac_validate_client() In-Reply-To: Message-ID: > Bug in 1.7 in k5_pac_validate_client(), in 1.7. It would be nice to > fix this for 1.7.1. > > The issue is that PACs from principals in different realms to the > service fail to validate. > > The fix to pac.c is to ignore the realm component (because the > principal name in the PAC is unqualified): > > if (pac_authtime != authtime || > !krb5_principal_compare_flags(context, > pac_principal, > principal, > > KRB5_PRINCIPAL_COMPARE_IGNORE_REALM)) > ret = KRB5KRB_AP_WRONG_PRINC; > > -- Luke > -- > www.padl.com | www.fghr.net From rt-comment at krbdev.mit.edu Thu Sep 3 13:39:52 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Thu, 3 Sep 2009 17:39:52 +0000 (UTC) Subject: [krbdev.mit.edu #6556] SVN Commit In-Reply-To: Message-ID: In the LDAP back end, return aliases when the CLIENT_REFERRALS_ONLY flag isn't set (abusing that flag to recognize a client name lookup). Based on a patch from Luke Howard. http://src.mit.edu/fisheye/changelog/krb5/?cs=22708 Commit By: ghudson Revision: 22708 Changed Files: U trunk/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c From rt-comment at krbdev.mit.edu Thu Sep 3 16:41:58 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Thu, 3 Sep 2009 20:41:58 +0000 (UTC) Subject: [krbdev.mit.edu #6557] SVN Commit In-Reply-To: Message-ID: In the presence of aliases, LDAP iteration was supplying the first principal it found within the expected realm, which is not necessarily the same as the canonical name. If the entry has a canonical name field, use that in preference to any of the principal names. http://src.mit.edu/fisheye/changelog/krb5/?cs=22710 Commit By: ghudson Revision: 22710 Changed Files: U trunk/src/plugins/kdb/ldap/libkdb_ldap/ldap_principal.c From rt-comment at krbdev.mit.edu Wed Sep 9 11:17:10 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Wed, 9 Sep 2009 15:17:10 +0000 (UTC) Subject: [krbdev.mit.edu #6558] SVN Commit In-Reply-To: Message-ID: gss_krb5int_copy_ccache was iterating over credentials in a ccache without freeing them. http://src.mit.edu/fisheye/changelog/krb5/?cs=22718 Commit By: ghudson Revision: 22718 Changed Files: U trunk/src/lib/gssapi/krb5/copy_ccache.c From rt-comment at krbdev.mit.edu Fri Sep 11 13:30:52 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Fri, 11 Sep 2009 17:30:52 +0000 (UTC) Subject: [krbdev.mit.edu #6559] SVN Commit In-Reply-To: Message-ID: Cherry-picked from Luke's authdata branch. http://src.mit.edu/fisheye/changelog/krb5/?cs=22732 Commit By: ghudson Revision: 22732 Changed Files: U trunk/src/lib/gssapi/krb5/import_name.c From rt-comment at krbdev.mit.edu Fri Sep 11 17:36:02 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 11 Sep 2009 21:36:02 +0000 (UTC) Subject: [krbdev.mit.edu #6560] SVN Commit In-Reply-To: Message-ID: test commit handler on drugstore-clone http://src.mit.edu/fisheye/changelog/krb5/?cs=22641 Commit By: tlyu Revision: 22641 Changed Files: D branches/commit-handler-test/aaaa/foo From rt-comment at krbdev.mit.edu Sat Sep 12 00:21:56 2009 From: rt-comment at krbdev.mit.edu (The RT System itself via RT) Date: Sat, 12 Sep 2009 04:21:56 +0000 (UTC) Subject: [krbdev.mit.edu #6561] No option to only build client and libs In-Reply-To: Message-ID: >From krb5-bugs-incoming-bounces at PCH.mit.edu Sat Sep 12 04:21:55 2009 Return-Path: Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (Postfix) with ESMTP id B9CD45C01D; Sat, 12 Sep 2009 04:21:55 +0000 (UTC) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8C4Ltkr018440; Sat, 12 Sep 2009 00:21:55 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n8C3cU70013564 for ; Fri, 11 Sep 2009 23:38:32 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n8C3cG2b010122 for ; Fri, 11 Sep 2009 23:38:17 -0400 (EDT) Received: from ohnopublishing.net (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 9F7DA1F6A595 for ; Fri, 11 Sep 2009 23:38:14 -0400 (EDT) Received: from ohnopublishing.net (d14-69-165-90.try.wideopenwest.com [69.14.90.165]) by mit.edu with ESMTP id wYD9ldIwc2WuHDoU for ; Fri, 11 Sep 2009 23:38:13 -0400 (EDT) Received-SPF: pass (mit.edu: domain of ohnobinki at ohnopublishing.net designates 69.14.90.165 as permitted sender) receiver=mit.edu; client_ip=69.14.90.165; envelope-from=ohnobinki at ohnopublishing.net; Received: by ohnopublishing.net (Postfix, from userid 1000) id 61C6633F91; Fri, 11 Sep 2009 23:38:17 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 ohnopublishing.net 61C6633F91 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ohnopublishing.net; s=ohnopublishing.net; t=1252726697; bh=fNRdRj2fYUvUTPKHnwbb5u6wCoWBFqGj7MwE3Rdetpg=; h=To:Subject:From:Reply-To:Cc:Message-Id:Date; b=e/ADVUxDxbDHywWIciVWcUyLABLEm5tCMEirh88F2sPfq0wURKwybILUBPPJNzwFi 1YLvuahdgSD7gUfeQgDlM3qvVQko6Wk19YrGyLbLI3nbGjnHlNTCGm/qKIpsELudrJ HBKS8WkEgc2jbJEmDDs1Hlx+vqwV0OEtVrL+oMOY= To: krb5-bugs at mit.edu Subject: no option to only build clients and libs From: Binki X-send-pr-version: 3.99 Message-Id: <20090912033817.61C6633F91 at ohnopublishing.net> Date: Fri, 11 Sep 2009 23:38:17 -0400 (EDT) X-Spam-Score: 0.10 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Sat, 12 Sep 2009 00:21:53 -0400 X-BeenThere: krb5-bugs-incoming at mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Binki Sender: krb5-bugs-incoming-bounces at PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces at PCH.mit.edu >Submitter-Id: net >Originator: Nathan Phillip Brink >Organization: >Confidential: no >Synopsis: No option to only build client and libs >Severity: non-critical >Priority: low >Category: krb5-misc >Class: change-request >Release: 1.6.3 >Environment: System: Linux ohnopublishing.net 2.6.30-gentoo-r4athlon64x2_2009.05.31 #1 SMP Fri Aug 21 12:50:25 EDT 2009 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux >Description: It appears from the online documentation that mit-krb5 and its build system does not support building only libs/clients. There should be options for building just the basic, necessary clients (kinit, kdestroy, kpasswd, klist, maybe kadmin) and libs. The primary number of systems which will have mit-krb5 installed do not need or have no reason to run the KDC. Building and installing that component is a waste of time and space for those machines. >How-To-Repeat: Read documentation and compile/install mit-krb5 >Fix: An option to only build the necessary client programs should be provided. Preferrably, the krb5-enabled system-util replacements would be optional as well, but those are at least still useful on client machines which aren't acting as KDCs ;-) From rt-comment at krbdev.mit.edu Sat Sep 12 12:29:45 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Sat, 12 Sep 2009 16:29:45 +0000 (UTC) Subject: [krbdev.mit.edu #6561] No option to only build client and libs In-Reply-To: Message-ID: By the standards of most modern software packages, the entirety of krb5 builds in very little time and takes very little space. Moreover, most people do not build krb5 themselves; they get it from an OS distribution. OS packages typically build all of krb5 and then split up the result into multiple binary packages, so they do not need build system support to separate clients, libraries, and so forth. Do you have a particular need in this regard? If this is just a matter of principle, I don't think we want to further complicate our build system. From rt-comment at krbdev.mit.edu Sat Sep 12 12:57:55 2009 From: rt-comment at krbdev.mit.edu (ohnobinki@ohnopublishing.net via RT) Date: Sat, 12 Sep 2009 16:57:55 +0000 (UTC) Subject: [krbdev.mit.edu #6561] No option to only build client and libs In-Reply-To: Message-ID: Greg Hudson via RT wrote: > By the standards of most modern software packages, the entirety of krb5 > builds in very little time and takes very little space. Moreover, most > people do not build krb5 themselves; they get it from an OS > distribution. As I do, using Gentoo. > OS packages typically build all of krb5 and then split up > the result into multiple binary packages, so they do not need build > system support to separate clients, libraries, and so forth. Many popular packages' build systems support conditional compilation/installation of portions of the software. Also, distributions somewhat rely on a program's build system to build the software. For example, Debian (I'm guessing), Gentoo, and LFS depend on your build system to produce the binaries andto install binaries where they belong. MIT's krb5 ironically recognizes this by providing an install target in its Makefiles. The distribution's task of making certain features of your package optional is somewhat dependent on your buildsystem's support for such. If every single distribution which packages mit-krb5 has to generate and maintain its own patches to the mit-krb5 buildsystem to have conditional building support, effort is wasted. Also, if your buildsystem builds programs which the distribution isn't installed, the user has to wait for those portions to be built. Thus, I think the proper place to implement conditional building and installation is within your buildsystem. A related task would be supporting installation of the system-utility replacement binaries, but that doesn't bother me as greatly as the inability to have even general control over what gets compiled when make is run. > > Do you have a particular need in this regard? If this is just a matter > of principle, I don't think we want to further complicate our build system. I'm sorry, it is a matter of two principles. 1. It should be possible to decide what gets installed and compiled when using compiling and installing mit-krb5. 2. Multiple distributions shouldn't duplicate effort in hacking your buildsystem or otherwise breaking it apart. If you are willing to consider this issue, I think I could put a patch together. I haven't looked too closely at your current buildsystem. I'm now just trying to establish that this bug is valid ;-). I initially wondering if this functionality just wasn't documented online, but you have hinted that the functionality doesn't exist. -- binki From rt-comment at krbdev.mit.edu Sat Sep 12 14:27:48 2009 From: rt-comment at krbdev.mit.edu (Russ Allbery via RT) Date: Sat, 12 Sep 2009 18:27:48 +0000 (UTC) Subject: [krbdev.mit.edu #6561] No option to only build client and libs In-Reply-To: Message-ID: "ohnobinki at ohnopublishing.net via RT" writes: > The distribution's task of making certain features of your package > optional is somewhat dependent on your buildsystem's support for such. > If every single distribution which packages mit-krb5 has to generate and > maintain its own patches to the mit-krb5 buildsystem to have conditional > building support, effort is wasted. Also, if your buildsystem builds > programs which the distribution isn't installed, the user has to wait > for those portions to be built. Thus, I think the proper place to > implement conditional building and installation is within your > buildsystem. I suspect this is a Gentoo-specific problem. For Red Hat and Debian at least, and I suspect for all distribution packaging that isn't based on the end-user compiling their own version of the software, there's no need to support building portions of the software. Building Debian packages or RPMs always builds all related packages, and then the user chooses which of those to install. -- Russ Allbery (rra at stanford.edu) From rt-comment at krbdev.mit.edu Sat Sep 12 14:48:45 2009 From: rt-comment at krbdev.mit.edu (ohnobinki@ohnopublishing.net via RT) Date: Sat, 12 Sep 2009 18:48:45 +0000 (UTC) Subject: [krbdev.mit.edu #6561] No option to only build client and libs In-Reply-To: Message-ID: Russ Allbery via RT wrote: > "ohnobinki at ohnopublishing.net via RT" writes: > >> The distribution's task of making certain features of your package >> optional is somewhat dependent on your buildsystem's support for such. >> If every single distribution which packages mit-krb5 has to generate and >> maintain its own patches to the mit-krb5 buildsystem to have conditional >> building support, effort is wasted. Also, if your buildsystem builds >> programs which the distribution isn't installed, the user has to wait >> for those portions to be built. Thus, I think the proper place to >> implement conditional building and installation is within your >> buildsystem. > > I suspect this is a Gentoo-specific problem. For Red Hat and Debian at > least, and I suspect for all distribution packaging that isn't based on > the end-user compiling their own version of the software, there's no need > to support building portions of the software. Building Debian packages or > RPMs always builds all related packages, and then the user chooses which > of those to install. You do not understand what I am trying to say. Gentoo could add support to their buildscripts to patch your buildsystem so that it could conditionally compile sources. Gentoo could also just delete installed binaries that the user doesn't want installed. However, both of these methods are incorrect ways of addressing a problem with mit-krb5's buildsystem: its lack of conditional building/installation. Gentoo does not support users just compiling their own software and manually installing it. This is not a good way to manage software. However, in Gentoo, users are encouraged and mostly required to compile software locally using ebuilds which are similar in principle to specfiles (any redhat users?) and use a package manager. Just as many distributions maintain patches against packages, Gentoo applies patches to mit-krb5 before it is compiled and installed. For some packages (including mit-krb5), there are patches that add missing functionality to buildsystems (sometimes in Gentoo-specific ways, but this bug is not an example of that). However, it is preferable to get things fixed upstream. I was submitting this request here because its fix would benefit many users of mit-krb5. And I was hoping that this change might trickle down so that Gentoo devs could easily add an option to the ebuild to only build and install the minimal set of libs and clients of mit-krb5. This would also ease the job of other distribution which mangle this package anyways. -- binki From rt-comment at krbdev.mit.edu Sat Sep 12 14:58:23 2009 From: rt-comment at krbdev.mit.edu (Russ Allbery via RT) Date: Sat, 12 Sep 2009 18:58:23 +0000 (UTC) Subject: [krbdev.mit.edu #6561] No option to only build client and libs In-Reply-To: Message-ID: "ohnobinki at ohnopublishing.net via RT" writes: > Russ Allbery via RT wrote: >> "ohnobinki at ohnopublishing.net via RT" writes: >>> The distribution's task of making certain features of your package >>> optional is somewhat dependent on your buildsystem's support for such. >>> If every single distribution which packages mit-krb5 has to generate >>> and maintain its own patches to the mit-krb5 buildsystem to have >>> conditional building support, effort is wasted. Also, if your >>> buildsystem builds programs which the distribution isn't installed, >>> the user has to wait for those portions to be built. Thus, I think the >>> proper place to implement conditional building and installation is >>> within your buildsystem. >> I suspect this is a Gentoo-specific problem. For Red Hat and Debian at >> least, and I suspect for all distribution packaging that isn't based on >> the end-user compiling their own version of the software, there's no >> need to support building portions of the software. Building Debian >> packages or RPMs always builds all related packages, and then the user >> chooses which of those to install. > You do not understand what I am trying to say. I think that I do, but am addressing a more limited part of your point than I think you're realizing. You made the argument that "if every single distribution which packages mit-krb5 has to generate and maintain its own patches to the mit-krb5 buildsystem to have conditional building support, effort is wasted." I'm pointing out that the only distribution that is likely to care is Gentoo; this is not a useful feature for other distributions that don't use the approach that Gentoo takes to building software. That doesn't mean that your feature proposal is without merit, only that the scope of expected usage is somewhat smaller than I think your bug report reflected. > However, it is preferable to get things fixed upstream. I was submitting > this request here because its fix would benefit many users of mit-krb5. > And I was hoping that this change might trickle down so that Gentoo devs > could easily add an option to the ebuild to only build and install the > minimal set of libs and clients of mit-krb5. Of course. I think the question is whether it adds complexity to the build system that the Kerberos maintainers don't want to cope with. -- Russ Allbery (rra at stanford.edu) From rt-comment at krbdev.mit.edu Sat Sep 12 16:55:01 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Sat, 12 Sep 2009 20:55:01 +0000 (UTC) Subject: [krbdev.mit.edu #6561] No option to only build client and libs In-Reply-To: Message-ID: If this build system support would make life easier for Gentoo's package system, that's a valid use case. I don't think other OS packaging systems would make use of the functionality (they would still use "make install" and then use file lists to split up the binary packages), but even one distribution's needs are relevant. So, no promises, but if I have time I will see how complicated this really is. From rt-comment at krbdev.mit.edu Sat Sep 12 22:52:26 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Sun, 13 Sep 2009 02:52:26 +0000 (UTC) Subject: [krbdev.mit.edu #6563] SVN Commit In-Reply-To: Message-ID: Merge Luke's users/lhoward/s4u branch to trunk. Implements S4U2Self and S4U2Proxy extensions. http://src.mit.edu/fisheye/changelog/krb5/?cs=22736 Commit By: ghudson Revision: 22736 Changed Files: U trunk/src/clients/kvno/kvno.M U trunk/src/clients/kvno/kvno.c U trunk/src/include/k5-int.h U trunk/src/include/kdb.h U trunk/src/include/kdb_ext.h U trunk/src/include/krb5/krb5.hin U trunk/src/kadmin/cli/kadmin.c U trunk/src/kdc/do_tgs_req.c U trunk/src/kdc/kdc_authdata.c U trunk/src/kdc/kdc_preauth.c U trunk/src/kdc/kdc_util.c U trunk/src/kdc/kdc_util.h A trunk/src/lib/crypto/krb/enc_provider/ U trunk/src/lib/gssapi/generic/gssapi_ext.h U trunk/src/lib/gssapi/krb5/Makefile.in U trunk/src/lib/gssapi/krb5/accept_sec_context.c U trunk/src/lib/gssapi/krb5/acquire_cred.c U trunk/src/lib/gssapi/krb5/gssapiP_krb5.h U trunk/src/lib/gssapi/krb5/gssapi_krb5.c U trunk/src/lib/gssapi/krb5/import_name.c U trunk/src/lib/gssapi/krb5/init_sec_context.c U trunk/src/lib/gssapi/krb5/krb5_gss_glue.c A trunk/src/lib/gssapi/krb5/s4u_gss_glue.c U trunk/src/lib/gssapi/krb5/val_cred.c U trunk/src/lib/gssapi/libgssapi_krb5.exports U trunk/src/lib/gssapi/mechglue/Makefile.in U trunk/src/lib/gssapi/mechglue/g_accept_sec_context.c U trunk/src/lib/gssapi/mechglue/g_acquire_cred.c A trunk/src/lib/gssapi/mechglue/g_acquire_cred_imp_name.c U trunk/src/lib/gssapi/mechglue/g_glue.c U trunk/src/lib/gssapi/mechglue/g_initialize.c U trunk/src/lib/gssapi/mechglue/g_set_context_option.c U trunk/src/lib/gssapi/mechglue/mglueP.h U trunk/src/lib/gssapi/spnego/gssapiP_spnego.h U trunk/src/lib/gssapi/spnego/spnego_mech.c U trunk/src/lib/kadm5/str_conv.c U trunk/src/lib/krb5/asn.1/asn1_k_decode.c U trunk/src/lib/krb5/asn.1/asn1_k_decode.h U trunk/src/lib/krb5/asn.1/asn1_k_encode.c U trunk/src/lib/krb5/asn.1/krb5_decode.c U trunk/src/lib/krb5/krb/Makefile.in U trunk/src/lib/krb5/krb/gc_frm_kdc.c U trunk/src/lib/krb5/krb/gc_via_tkt.c U trunk/src/lib/krb5/krb/get_creds.c U trunk/src/lib/krb5/krb/get_in_tkt.c U trunk/src/lib/krb5/krb/int-proto.h U trunk/src/lib/krb5/krb/kfree.c U trunk/src/lib/krb5/krb/preauth2.c A trunk/src/lib/krb5/krb/s4u_creds.c U trunk/src/lib/krb5/krb/send_tgs.c U trunk/src/lib/krb5/krb/srv_dec_tkt.c U trunk/src/lib/krb5/libkrb5.exports U trunk/src/lib/krb5/os/sendto_kdc.c U trunk/src/slave/kproplog.c U trunk/src/tests/asn.1/krb5_decode_leak.c U trunk/src/tests/asn.1/krb5_decode_test.c U trunk/src/tests/asn.1/krb5_encode_test.c U trunk/src/tests/asn.1/ktest.c U trunk/src/tests/asn.1/ktest.h U trunk/src/tests/asn.1/ktest_equal.c U trunk/src/tests/asn.1/ktest_equal.h U trunk/src/tests/asn.1/reference_encode.out U trunk/src/tests/asn.1/trval_reference.out U trunk/src/tests/gssapi/Makefile.in A trunk/src/tests/gssapi/t_s4u.c From rt-comment at krbdev.mit.edu Sun Sep 13 10:23:38 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Sun, 13 Sep 2009 14:23:38 +0000 (UTC) Subject: [krbdev.mit.edu #6563] SVN Commit In-Reply-To: Message-ID: Remove src/lib/crypto/krb/enc_provider, which was accidentally resurrected in the S4U merge after being moved into the back-end directories in r22707. http://src.mit.edu/fisheye/changelog/krb5/?cs=22744 Commit By: ghudson Revision: 22744 Changed Files: D trunk/src/lib/crypto/krb/enc_provider/ From rt-comment at krbdev.mit.edu Sun Sep 13 13:17:10 2009 From: rt-comment at krbdev.mit.edu (Ezra Peisach via RT) Date: Sun, 13 Sep 2009 17:17:10 +0000 (UTC) Subject: [krbdev.mit.edu #6564] s4u extensions integration broke test suite... In-Reply-To: Message-ID: During the des3-aes tests (gssclient tests) Core dump in the kdc.... Looks like reply.padata is pointing to garbage... (gdb) where #0 krb5_free_pa_data (context=0x889cae8, val=0xfd13) at ../../../../src/lib/krb5/krb/kfree.c:394 #1 0x0804d791 in process_tgs_req (pkt=0xbfe84480, from=0xbfe84494, response=0xbfe8449c) at ../../src/kdc/do_tgs_req.c:1006 #2 0x0804bbe0 in dispatch (pkt=0xbfe84480, from=0xbfe84494, response=0xbfe8449c) at ../../src/kdc/dispatch.c:89 #3 0x0805afe6 in process_packet (conn=0x889f828, selflags=1) at ../../src/kdc/network.c:1238 #4 0x0805a3e3 in service_conn (selflags=, conn=) at ../../src/kdc/network.c:1564 #5 listen_and_process (selflags=, conn=) at ../../src/kdc/network.c:1655 #6 0x08058d0e in main (argc=5, argv=0xbfe84604) at ../../src/kdc/main.c From valgrind: ==23113== Conditional jump or move depends on uninitialised value(s) ==23113== at 0x804D77B: process_tgs_req (do_tgs_req.c:1005) ==23113== by 0x804BBDF: dispatch (dispatch.c:89) ==23113== by 0x805AFE5: process_packet (network.c:1238) ==23113== by 0x805A3E2: listen_and_process (network.c:1564) ==23113== by 0x8058D0D: main (main.c:897) ==23113== ==23113== Conditional jump or move depends on uninitialised value(s) ==23113== at 0x40CF879: krb5_free_pa_data (kfree.c:392) ==23113== by 0x804D790: process_tgs_req (do_tgs_req.c:1006) ==23113== by 0x804BBDF: dispatch (dispatch.c:89) ==23113== by 0x805AFE5: process_packet (network.c:1238) ==23113== by 0x805A3E2: listen_and_process (network.c:1564) ==23113== by 0x8058D0D: main (main.c:897) ==23113== ==23113== Use of uninitialised value of size 4 ==23113== at 0x40CF87B: krb5_free_pa_data (kfree.c:394) ==23113== by 0x804D790: process_tgs_req (do_tgs_req.c:1006) ==23113== by 0x804BBDF: dispatch (dispatch.c:89) ==23113== by 0x805AFE5: process_packet (network.c:1238) ==23113== by 0x805A3E2: listen_and_process (network.c:1564) ==23113== by 0x8058D0D: main (main.c:897) From rt-comment at krbdev.mit.edu Sun Sep 13 22:03:29 2009 From: rt-comment at krbdev.mit.edu (Ezra Peisach via RT) Date: Mon, 14 Sep 2009 02:03:29 +0000 (UTC) Subject: [krbdev.mit.edu #6564] SVN Commit In-Reply-To: Message-ID: Initialize several variables - so that on error cleanup - we do not try to free bogus memory. The ticket is still open as the kproplog test is failing - but no coredump. http://src.mit.edu/fisheye/changelog/krb5/?cs=22750 Commit By: epeisach Revision: 22750 Changed Files: U trunk/src/kdc/do_tgs_req.c From rt-comment at krbdev.mit.edu Sun Sep 13 22:44:02 2009 From: rt-comment at krbdev.mit.edu (Ezra Peisach via RT) Date: Mon, 14 Sep 2009 02:44:02 +0000 (UTC) Subject: [krbdev.mit.edu #6564] s4u extensions integration broke test suite... In-Reply-To: Message-ID: The failure in the iprop test suite is only when the des3-aes tests are enabled alone... When the full testsuite is enabled - everything works. I do not think this is a s4u integration problem - but possibly a testsuite problem. So - we can close and review this. From rt-comment at krbdev.mit.edu Mon Sep 14 00:15:18 2009 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 14 Sep 2009 04:15:18 +0000 (UTC) Subject: [krbdev.mit.edu #6564] s4u extensions integration broke test suite... In-Reply-To: Message-ID: On Sep 13, 2009, at 22:44, Ezra Peisach via RT wrote: > The failure in the iprop test suite is only when the des3-aes tests > are > enabled alone... When the full testsuite is enabled - everything > works. > I do not think this is a s4u integration problem - but possibly a > testsuite problem. > > So - we can close and review this. There are several tests that only get run on the first pass through, because theoretically they shouldn't be affected by the enctype-list changes between passes. Perhaps this indicates a test is wrongly being skipped. Ken From Xu at krbdev.mit.edu Sat Sep 12 16:45:34 2009 From: Xu at krbdev.mit.edu (Xu@krbdev.mit.edu) Date: Sat, 12 Sep 2009 20:45:34 +0000 (UTC) Subject: [krbdev.mit.edu #6562] kinit not working if kdc is configured with numerical IPv6 address In-Reply-To: Message-ID: Hi, all: I am writing to report a bug in 1.7 release. In /etc/krb5.conf, if kdc is configured with numerical IPv6 address, Kerberos client will not be able to locate this kdc, and kinit will fail. Here is an example: ============================================= /* The content of /etc/krb5.conf with IPv6 address */ [realms] XCIPV6.COM = { kdc = [3ffe:2000:0:1::100]:88 default_domain = xcipv6.com } /* Kerberos authentication result */ qxu at durian(pts/3):/etc[112]$ kinit XCTEST100 at XCIPV6.COM kinit(v5): Cannot resolve network address for KDC in realm XCIPV6.COM while getting initial credentials ============================================= In my eyes, if numerical IPv4 address is supported for kdc entry in /etc/krb5.conf, so should be for numerical IPv6 address. Investigation shows the defect is in the function "krb5_locate_srv_conf_1()" in the file "krb5-1.7/src/lib/krb5/os/locate_kdc.c", and a fix has been made out. Anyone would like to review? P.S. How to send the fix to you guys? Email Attachment? Thanks, Xu Qiang From rt-comment at krbdev.mit.edu Mon Sep 14 13:25:18 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Mon, 14 Sep 2009 17:25:18 +0000 (UTC) Subject: [krbdev.mit.edu #6562] kinit not working if kdc is configured with numerical IPv6 address In-Reply-To: Message-ID: An email attachment should work fine, yes. From rt-comment at krbdev.mit.edu Mon Sep 14 21:45:49 2009 From: rt-comment at krbdev.mit.edu ( Arlene Berry via RT) Date: Tue, 15 Sep 2009 01:45:49 +0000 (UTC) Subject: [krbdev.mit.edu #6565] HP-UX IA64 wrong endian In-Reply-To: Message-ID: For krb5-1.7 all IA64 platforms are identified as little endian but HP-UX is big endian. It's causing the 1.7 arcfour string to key function to use the wrong endian and it's resulting in KRB5KDC_ERR_PREAUTH_FAILED errors. The endian is also incorrect for 1.6.3 but its arcfour string to key function works anyway. Here's what I did to fix it for us: Index: krb5/src/include/k5-platform.h =================================================================== --- krb5/src/include/k5-platform.h (revision 37170) +++ krb5/src/include/k5-platform.h (revision 37171) @@ -476,10 +476,10 @@ As far as I know, only PDP11 and ARM (which we don't handle here) have strange byte orders where an 8-byte value isn't laid out as either 12345678 or 87654321. */ -# if defined(__i386__) || defined(_MIPSEL) || defined(__alpha__) || defined(__ia64__) +# if defined(__i386__) || defined(_MIPSEL) || defined(__alpha__) || (defined(__ia64__) && !defined(__hpux)) # define K5_LE # endif -# if defined(__hppa__) || defined(__rs6000__) || defined(__sparc__) || defined(_MIPSEB) || defined(__m68k__) || defined(__sparc64__) || defined(__ppc__) || defined(__ppc64__) +# if defined(__hppa__) || defined(__rs6000__) || defined(__sparc__) || defined(_MIPSEB) || defined(__m68k__) || defined(__sparc64__) || defined(__ppc__) || defined(__ppc64__) || (defined(__hpux) && defined(__ia64)) # define K5_BE # endif #endif From rt-comment at krbdev.mit.edu Mon Sep 14 22:36:15 2009 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 15 Sep 2009 02:36:15 +0000 (UTC) Subject: [krbdev.mit.edu #6565] HP-UX IA64 wrong endian In-Reply-To: Message-ID: On Sep 14, 2009, at 21:45, Arlene Berry via RT wrote: > For krb5-1.7 all IA64 platforms are identified as little endian but > HP-UX is big endian. I wondered if there should be some startup-time sanity check of that, just to be safe. The current GCC sources indicate that it'll define __BIG_ENDIAN__ on big-endian IA64 targets. It may be good to add __BIG_ENDIAN__ and __LITTLE_ENDIAN__ to the list of macros we test for; certainly several GCC configurations seem to define one or the other for several processors that can go either way. I'll take a look.... Ken From rt-comment at krbdev.mit.edu Tue Sep 15 02:17:18 2009 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 15 Sep 2009 06:17:18 +0000 (UTC) Subject: [krbdev.mit.edu #6565] SVN Commit In-Reply-To: Message-ID: Check __BIG_ENDIAN__ and __LITTLE_ENDIAN__ to determine endianness. In fallback code, check ia64 platforms for hpux vs everything else; HP-UX uses big-endian mode. http://src.mit.edu/fisheye/changelog/krb5/?cs=22761 Commit By: raeburn Revision: 22761 Changed Files: U trunk/src/include/k5-platform.h From Xu at krbdev.mit.edu Tue Sep 15 01:56:16 2009 From: Xu at krbdev.mit.edu (Xu@krbdev.mit.edu) Date: Tue, 15 Sep 2009 05:56:16 +0000 (UTC) Subject: [krbdev.mit.edu #6562] kinit not working if kdc is configured with numerical IPv6 address In-Reply-To: Message-ID: > -----Original Message----- > From: krb5-bugs-bounces at mit.edu > [mailto:krb5-bugs-bounces at mit.edu] On Behalf Of Greg Hudson via RT > Sent: Tuesday, September 15, 2009 1:25 AM > Subject: [krbdev.mit.edu #6562] kinit not working if kdc is > configured with numerical IPv6 address > > An email attachment should work fine, yes. Here is the fix. Please review. Thanks, Xu Qiang From rt-comment at krbdev.mit.edu Tue Sep 15 15:28:33 2009 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 15 Sep 2009 19:28:33 +0000 (UTC) Subject: [krbdev.mit.edu #6565] SVN Commit In-Reply-To: Message-ID: Fix stupid logic bug in last version. http://src.mit.edu/fisheye/changelog/krb5/?cs=22766 Commit By: raeburn Revision: 22766 Changed Files: U trunk/src/include/k5-platform.h From rt-comment at krbdev.mit.edu Tue Sep 15 22:02:35 2009 From: rt-comment at krbdev.mit.edu (elric@mournblade.imrryr.org via RT) Date: Wed, 16 Sep 2009 02:02:35 +0000 (UTC) Subject: [krbdev.mit.edu #6566] UDP datagrams > 4K do not work. In-Reply-To: Message-ID: In src/kdc/network.c, in the function: process_packet(): We find: response = NULL; saddr_len = sizeof(saddr); cc = recvfrom(port_fd, pktbuf, sizeof(pktbuf), 0, (struct sockaddr *)&saddr, &saddr_len); if (cc == -1) { if (errno != EINTR /* This is how Linux indicates that a previous transmission was refused, e.g., if the client timed out before getting the response packet. */ && errno != ECONNREFUSED ) com_err(prog, errno, "while receiving from network"); return; } if (!cc) return; /* zero-length packet? */ Unfortunately, if you receive a datagram of over sizeof(pktbuf) you will succeed with cc == sizeof(pktbuf) not detecting the fact that there was additional data. This results in an ASN.1 parse error. What should happen is that the KDC should return an appropriate error to the client indicating that TCP should be used. Or maybe the buffer size should be increased to the maximum allowable for UDP. I prefer the second option as there is nothing inherently wrong with 64K UDP packets. I noticed this while debugging a JGSS problem. Apparently, the Java Kerberos libraries do not fail over from UDP to TCP unless the KDC specifically tells them to. And they have no default setting for udp_preference_limit. And so, if you are constructing tickets of over 4K because, let's say, a user is in a lot of groups in Windows, JGSS will just fail against an MIT KDC. Fix: change MAX_DGRAM_SIZE in /include/krb5/stock/osconf.h to be the actual maximum datagram size, 65536. -- Roland Dowdeswell http://Imrryr.ORG/~elric/ From rt-comment at krbdev.mit.edu Wed Sep 16 00:35:37 2009 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Wed, 16 Sep 2009 04:35:37 +0000 (UTC) Subject: [krbdev.mit.edu #6566] UDP datagrams > 4K do not work. In-Reply-To: Message-ID: On Sep 15, 2009, at 22:02, elric at mournblade.imrryr.org via RT wrote: > Unfortunately, if you receive a datagram of over sizeof(pktbuf) > you will succeed with cc == sizeof(pktbuf) not detecting the fact > that there was additional data. This results in an ASN.1 parse > error. What should happen is that the KDC should return an > appropriate error to the client indicating that TCP should be used. Regardless of other options, it sounds like cc==sizeof(pktbuf) should trigger the use-TCP error, since we can't distinguish between a packet equal in size to the buffer and a packet that was larger but got truncated. Either that, or we could peek at the size of the next datagram and grow the buffer as needed, but I'm not sure that peeking can be done portably. > Or maybe the buffer size should be increased to the maximum allowable > for UDP. I prefer the second option as there is nothing inherently > wrong with 64K UDP packets. With jumbograms, UDP messages larger than 64K are possible. (RFC 2675) Still, 64K does seem like a reasonable limit (i.e., way larger than we would normally expect). > I noticed this while debugging a JGSS problem. Apparently, the > Java Kerberos libraries do not fail over from UDP to TCP unless > the KDC specifically tells them to. And they have no default > setting for udp_preference_limit. And so, if you are constructing > tickets of over 4K because, let's say, a user is in a lot of groups > in Windows, JGSS will just fail against an MIT KDC. From what I've read, the common wisdom still seems to be that some gateways/routers/NAT boxes/firewalls/whatever will not properly process UDP fragments, so UDP traffic over ~1500 bytes (or less) may never get to the KDC. So this sounds like a bug in the Java Kerberos libraries. Ken -- Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium From rt-comment at krbdev.mit.edu Wed Sep 16 04:08:44 2009 From: rt-comment at krbdev.mit.edu (elric@mournblade.imrryr.org via RT) Date: Wed, 16 Sep 2009 08:08:44 +0000 (UTC) Subject: [krbdev.mit.edu #6566] UDP datagrams > 4K do not work. In-Reply-To: Message-ID: On 1253075737 seconds since the Beginning of the UNIX epoch "Ken Raeburn via RT" wrote: > >On Sep 15, 2009, at 22:02, elric at mournblade.imrryr.org via RT wrote: >> Unfortunately, if you receive a datagram of over sizeof(pktbuf) >> you will succeed with cc == sizeof(pktbuf) not detecting the fact >> that there was additional data. This results in an ASN.1 parse >> error. What should happen is that the KDC should return an >> appropriate error to the client indicating that TCP should be used. > >Regardless of other options, it sounds like cc==sizeof(pktbuf) should >trigger the use-TCP error, since we can't distinguish between a packet >equal in size to the buffer and a packet that was larger but got >truncated. Either that, or we could peek at the size of the next >datagram and grow the buffer as needed, but I'm not sure that peeking >can be done portably. Yes, this sounds like exactly the approach I would think about implementing. >> I noticed this while debugging a JGSS problem. Apparently, the >> Java Kerberos libraries do not fail over from UDP to TCP unless >> the KDC specifically tells them to. And they have no default >> setting for udp_preference_limit. And so, if you are constructing >> tickets of over 4K because, let's say, a user is in a lot of groups >> in Windows, JGSS will just fail against an MIT KDC. > > From what I've read, the common wisdom still seems to be that some >gateways/routers/NAT boxes/firewalls/whatever will not properly >process UDP fragments, so UDP traffic over ~1500 bytes (or less) may >never get to the KDC. So this sounds like a bug in the Java Kerberos >libraries. It's most certainly a bug in the Java Kerberos libraries. I've also run into them breaking when frags are dropped, etc. Thanks, -- Roland Dowdeswell http://Imrryr.ORG/~elric/ From rt-comment at krbdev.mit.edu Wed Sep 16 23:31:41 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Thu, 17 Sep 2009 03:31:41 +0000 (UTC) Subject: [krbdev.mit.edu #115] can't addprinc -policy -randkey In-Reply-To: Message-ID: This bug resurfaced in krb5 1.7 as a result of r20650. From rt-comment at krbdev.mit.edu Mon Sep 21 11:53:49 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Mon, 21 Sep 2009 15:53:49 +0000 (UTC) Subject: [krbdev.mit.edu #6563] SVN Commit In-Reply-To: Message-ID: Fix a few bugs in r22736. Cherry-picked from Luke's authdata branch. http://src.mit.edu/fisheye/changelog/krb5/?cs=22780 Commit By: ghudson Revision: 22780 Changed Files: U trunk/src/lib/gssapi/mechglue/g_set_context_option.c U trunk/src/lib/krb5/krb/s4u_creds.c From rt-comment at krbdev.mit.edu Mon Sep 21 12:13:01 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Mon, 21 Sep 2009 16:13:01 +0000 (UTC) Subject: [krbdev.mit.edu #115] can't addprinc -policy -randkey In-Reply-To: Message-ID: Fixed in r22781, which is tracked in ticket #6568 so it can have separated target_version metadata. From rt-comment at krbdev.mit.edu Mon Sep 21 12:11:27 2009 From: rt-comment at krbdev.mit.edu (Greg Hudson via RT) Date: Mon, 21 Sep 2009 16:11:27 +0000 (UTC) Subject: [krbdev.mit.edu #6568] SVN Commit In-Reply-To: Message-ID: The fix for ticket #6074 (r20650) caused a partial regression of ticket #115 (r9210) because the dummy password contained only one character class. As a minimal 1.7 fix, use all five character classes in the dummy password. http://src.mit.edu/fisheye/changelog/krb5/?cs=22781 Commit By: ghudson Revision: 22781 Changed Files: U trunk/src/kadmin/cli/kadmin.c From rt-comment at krbdev.mit.edu Tue Sep 22 15:57:04 2009 From: rt-comment at krbdev.mit.edu ( Arlene Berry via RT) Date: Tue, 22 Sep 2009 19:57:04 +0000 (UTC) Subject: [krbdev.mit.edu #6569] krb5-1.7 hangs on Solaris In-Reply-To: Message-ID: We're seeing hangs on Solaris because krb5-1.7 uses res_init and res_search from multiple threads. On Solaris, those functions are not thread safe. To fix it we changed krb5int_dns_init to call res_init only once and added a mutex around res_search: Index: src/lib/krb5/os/dnsglue.c =================================================================== --- src/lib/krb5/os/dnsglue.c (revision 37274) +++ src/lib/krb5/os/dnsglue.c (working copy) @@ -63,6 +63,10 @@ static int initparse(struct krb5int_dns_state *); #endif +#if !USE_RES_NINIT +static k5_mutex_t dns_res_lock = K5_MUTEX_PARTIAL_INITIALIZER; +#endif + /* * krb5int_dns_init() * @@ -102,12 +106,24 @@ #if USE_RES_NINIT memset(&statbuf, 0, sizeof(statbuf)); ret = res_ninit(&statbuf); -#else - ret = res_init(); -#endif if (ret < 0) return -1; +#else + if (!(_res.options & RES_INIT)) + { + ret = res_init(); + if (ret < 0) + return -1; + ret = k5_mutex_finish_init(&dns_res_lock); + if (ret < 0) + return ret; + } + ret = k5_mutex_lock(&dns_res_lock); + if (ret < 0) + return ret; +#endif + do { p = (ds->ansp == NULL) ? malloc(nextincr) : realloc(ds->ansp, nextincr); @@ -152,6 +168,8 @@ errout: #if USE_RES_NINIT res_ndestroy(&statbuf); +#else + k5_mutex_unlock(&dns_res_lock); #endif if (ret < 0) { if (ds->ansp != NULL) { From rt-comment at krbdev.mit.edu Tue Sep 22 17:43:01 2009 From: rt-comment at krbdev.mit.edu ( Arlene Berry via RT) Date: Tue, 22 Sep 2009 21:43:01 +0000 (UTC) Subject: [krbdev.mit.edu #6569] krb5-1.7 hangs on Solaris In-Reply-To: Message-ID: We build on Solaris 8 because we support Solaris 8 and up. I checked and HAVE_RES_NINIT and HAVE_RES_NSEARCH are defined but not HAVE_RES_NDESTROY. All three are required for dnsglue.c to set USE_RES_NINIT. From rt-comment at krbdev.mit.edu Tue Sep 22 19:28:08 2009 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 22 Sep 2009 23:28:08 +0000 (UTC) Subject: [krbdev.mit.edu #6569] krb5-1.7 hangs on Solaris In-Reply-To: Message-ID: Finding a thread-safe way of using the resolver would be better that locking around it within the Kerberos library, since the application may use it in other threads at the same time. It looks to me like there should be a workaround, thanks to Sun, but other OSes still using such old versions of BIND (are there any such that we still care about?) may still have problems. I'd consider using Sun's helper functions, if the early Solaris 8 releases are to be supported... Some possibly useful references: http://opensolaris.org/sc/src/iser/iser-on/usr/src/lib/nsswitch/dns/common/dns_mt.c Several comments discussing thread safety in various versions of BIND and the Solaris modifications to it, starting with BIND 8.1.2. Apparently Sun's modifications included functions that "enabled and disabled MT mode per-thread" for BIND 8.1.2, but weren't needed later in 8.2.2. I'm not sure if that means the new BIND code was entirely thread-safe, or just some parts that Sun cared about. http://docs.sun.com/app/docs/doc/806-7502/6jgce020l?a=view "Berkeley Internet Name Domain (BIND) has migrated from version 8.1.2 to 8.2.2 in the Solaris 8 4/01 release." So before that they were using 8.1.2; with the 4/1 release and later, BIND should apparently be thread-safe. http://developers.sun.com/solaris/articles/using_etc_release.html There were a few releases of "Solaris 8" before the 4/1 release, as well as a few after. http://www.cert.org/advisories/CA-2001-02.html The info from Sun in the vendor section suggests that BIND 8.1.2 was used back in Solaris 7, so I'm guessing it may have been in the initial Solaris 8 release. I could be wrong, if it was put in as a later update to both 7 and 8. http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg03798.html BIND 8.2 added the "nearly-thread-safe resolver API", so if there are thread safety issues it seems likely Arlene is using 8.1.2. (And 8.2 is also when getaddrinfo was added, so our fake one is probably being used still.) Ken P.S. There's also the route of just saying, "We assume X, Y, and Z facilities on your OS are thread-safe; if not, then the Kerberos libraries will not be thread-safe either." And encourage the use of OS updates that implement thread safety for routines POSIX says should be thread-safe. In early NetBSD releases, we knew this was an issue around getaddrinfo(), for example. In this case, there are OS updates available that fix the thread safety problem, and updating to Solaris 9 or 10 isn't even required. But it may still be too much of an imposition.... From rt-comment at krbdev.mit.edu Tue Sep 22 16:06:56 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 22 Sep 2009 20:06:56 +0000 (UTC) Subject: [krbdev.mit.edu #6569] krb5-1.7 hangs on Solaris In-Reply-To: Message-ID: " Arlene Berry via RT" writes: > We're seeing hangs on Solaris because krb5-1.7 uses res_init and > res_search from multiple threads. On Solaris, those functions are not > thread safe. To fix it we changed krb5int_dns_init to call res_init > only once and added a mutex around res_search: Interesting... what release of Solaris? I thought that the thread-safe res_ninit() were available on modern Solaris releases. From rt-comment at krbdev.mit.edu Mon Sep 28 16:06:59 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:06:59 +0000 (UTC) Subject: [krbdev.mit.edu #6505] SVN Commit In-Reply-To: Message-ID: pull up r22392 from trunk ------------------------------------------------------------------------ r22392 | raeburn | 2009-05-27 16:03:46 -0400 (Wed, 27 May 2009) | 10 lines ticket: 6505 target_version: 1.7 tags: pullup subject: fix t_prf test code properly Correction to patch in r22364: "i" was used in two places, one of which required an int-sized value and the other of which required a size_t. Instead of changing the type, split the two uses into separate variables. http://src.mit.edu/fisheye/changelog/krb5/?cs=22794 Commit By: tlyu Revision: 22794 Changed Files: U branches/krb5-1-7/src/lib/crypto/t_prf.c From rt-comment at krbdev.mit.edu Mon Sep 28 16:27:11 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:27:11 +0000 (UTC) Subject: [krbdev.mit.edu #6506] SVN Commit In-Reply-To: Message-ID: pull up r22397 from trunk ------------------------------------------------------------------------ r22397 | ghudson | 2009-06-01 18:39:31 -0400 (Mon, 01 Jun 2009) | 17 lines ticket: 6506 subject: Make results of krb5_db_def_fetch_mkey more predictable tags: pullup target_version: 1.7 krb5_db_def_fetch_mkey tries the stash file as a keytab, then falls back to the old stash file format. If the stash file was in keytab format, but didn't contain the desired master key, we would try to read a keytab file as a stash file. This could succeed or fail depending on byte order and other unpredictable factors. The upshot was that one of the libkadm5 unit tests (init 108) was getting a different error code on different platforms. To fix this, only try the stash file format if we get KRB5_KEYTAB_BADVNO trying the keytab format. This requires reworking the error handling logic. http://src.mit.edu/fisheye/changelog/krb5/?cs=22795 Commit By: tlyu Revision: 22795 Changed Files: U branches/krb5-1-7/src/lib/kdb/kdb_default.c From rt-comment at krbdev.mit.edu Mon Sep 28 16:27:14 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:27:14 +0000 (UTC) Subject: [krbdev.mit.edu #6508] SVN Commit In-Reply-To: Message-ID: pull up r22402 from trunk ------------------------------------------------------------------------ r22402 | epeisach | 2009-06-05 23:55:44 -0400 (Fri, 05 Jun 2009) | 7 lines ticket: 6508 subject: kadm5int_acl_parse_restrictions could ref uninitialized variable The variable sp is never initialized. If the first argument to the function is null, the code falls through to freeing sp if valid. However, sp is never set. http://src.mit.edu/fisheye/changelog/krb5/?cs=22796 Commit By: tlyu Revision: 22796 Changed Files: U branches/krb5-1-7/src/lib/kadm5/srv/server_acl.c From rt-comment at krbdev.mit.edu Mon Sep 28 16:34:54 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:34:54 +0000 (UTC) Subject: [krbdev.mit.edu #6509] SVN Commit In-Reply-To: Message-ID: pull up r22403 from trunk ------------------------------------------------------------------------ r22403 | epeisach | 2009-06-06 09:46:06 -0400 (Sat, 06 Jun 2009) | 9 lines ticket: 6509 subject: kadmind is parsing acls good deref NULL pointer on error In kadm5int_acl_parse_line, if you setup an acl w/ restrictions (i.e. the four argument acl format) - but have an error parsing the first few fields, acle is NULLed out, and is then derefed. This adds a conditional and indents according to the krb5 c-style... http://src.mit.edu/fisheye/changelog/krb5/?cs=22797 Commit By: tlyu Revision: 22797 Changed Files: U branches/krb5-1-7/src/lib/kadm5/srv/server_acl.c From rt-comment at krbdev.mit.edu Mon Sep 28 16:44:21 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:44:21 +0000 (UTC) Subject: [krbdev.mit.edu #6511] SVN Commit In-Reply-To: Message-ID: ------------------------------------------------------------------------ r22409 | epeisach | 2009-06-09 22:55:22 -0400 (Tue, 09 Jun 2009) | 7 lines ticket: 6511 subject: krb5int_rd_chpw_rep could call krb5_free_error with random value clang picked up on a path in which krberror is not set and passed as an argument to krb5_free_error(). Essentially if the clearresult length < 2 but everything decodes - you can hit this path... http://src.mit.edu/fisheye/changelog/krb5/?cs=22798 Commit By: tlyu Revision: 22798 Changed Files: U branches/krb5-1-7/src/lib/krb5/krb/chpw.c From rt-comment at krbdev.mit.edu Mon Sep 28 16:44:24 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:44:24 +0000 (UTC) Subject: [krbdev.mit.edu #6512] SVN Commit In-Reply-To: Message-ID: pull up r22413, r22410 from trunk ------------------------------------------------------------------------ r22413 | epeisach | 2009-06-17 13:51:31 -0400 (Wed, 17 Jun 2009) | 5 lines ticket: 6512 In the previous patch - I neglected a potential NULL deref in the call to krb5int_yarrow_cipher_final. Trivial fix. ------------------------------------------------------------------------ r22410 | epeisach | 2009-06-11 13:01:13 -0400 (Thu, 11 Jun 2009) | 7 lines subject: krb5int_yarrow_final could deref NULL if out of memory ticket: 6512 krb5int_yarrow_final tests if the Yarrow_CTX* is valid (not NULL) - and if not - signals and error for return - but still invokes mem_zero (memset) with it as an argument. This will only happen in an out-of-memory situation. http://src.mit.edu/fisheye/changelog/krb5/?cs=22799 Commit By: tlyu Revision: 22799 Changed Files: U branches/krb5-1-7/src/lib/crypto/yarrow/yarrow.c From rt-comment at krbdev.mit.edu Mon Sep 28 16:58:55 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:58:55 +0000 (UTC) Subject: [krbdev.mit.edu #6514] SVN Commit In-Reply-To: Message-ID: pull up r22417 from trunk ------------------------------------------------------------------------ r22417 | raeburn | 2009-06-18 17:56:48 -0400 (Thu, 18 Jun 2009) | 13 lines ticket: 6514 subject: minor memory leak in 'none' replay cache type tags: pullup target_version: 1.7.1 version_reported: 1.7 The replay cache type implementations are responsible for freeing the main rcache structure when the cache handle is closed. The 'none' rcache type wasn't doing this, resulting in a small memory leak each time such a cache was opened and closed. Not a big deal for a server process servicing a single client, but it could accumulate (very very slowly) for a long-running server. http://src.mit.edu/fisheye/changelog/krb5/?cs=22800 Commit By: tlyu Revision: 22800 Changed Files: U branches/krb5-1-7/src/lib/krb5/rcache/rc_none.c From rt-comment at krbdev.mit.edu Mon Sep 28 16:58:58 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 20:58:58 +0000 (UTC) Subject: [krbdev.mit.edu #6515] SVN Commit In-Reply-To: Message-ID: pull up r22418 from trunk ------------------------------------------------------------------------ r22418 | raeburn | 2009-06-18 19:25:25 -0400 (Thu, 18 Jun 2009) | 36 lines ticket: 6515 subject: reduce some mutex performance problems in profile library tags: pullup target_version: 1.7.1 version_reported: 1.7 In profile_node_iterator we unlock a mutex in order to call profile_update_file_data, which wants to lock that mutex itself, and then when it returns we re-lock the mutex. (We don't use recursive mutexes, and I would continue to argue that we shouldn't.) On the Mac, when running multiple threads, it appears that this results in very poor peformance, and much system and user CPU time is spent working with the locks. (Linux doesn't seem to suffer as much.) So: Split profile_update_file_data into a locking wrapper, and an inner routine that does the real work but requires that the lock be held on entry. Call the latter from profile_node_iterator *without* unlocking first, and only unlock if there's an error. This doesn't move any significant amount of work into the locking region; it pretty much just joins locking regions that were disjoint for no good reason. On my tests on an 8-core Mac, in a test program running gss_init_sec_context in a loop in 6 threads, this brought CPU usage per call down by 40%, and improved wall-clock time even more. Single-threaded performance improved very slightly, probably in the noise. Linux showed modest improvement (5% or less) in CPU usage in a 3-thread test on a 4-core system. Similar tests with gss_accept_sec_context showed similar contention around the profile-library mutexes, but I haven't analyzed the performance changes there from this patch. More work is needed, but this will help. http://src.mit.edu/fisheye/changelog/krb5/?cs=22801 Commit By: tlyu Revision: 22801 Changed Files: U branches/krb5-1-7/src/util/profile/prof_file.c U branches/krb5-1-7/src/util/profile/prof_int.h U branches/krb5-1-7/src/util/profile/prof_tree.c From rt-comment at krbdev.mit.edu Mon Sep 28 17:22:49 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 21:22:49 +0000 (UTC) Subject: [krbdev.mit.edu #1233] SVN Commit In-Reply-To: Message-ID: pull up r22434 from trunk ------------------------------------------------------------------------ r22434 | tlyu | 2009-07-10 15:20:26 -0400 (Fri, 10 Jul 2009) | 8 lines ticket: 1233 Add a new '-W' option to kadmind and kdb5_util create to allow reading weak random numbers on startup, to avoid long delays in testing situations. Use only for testing. Update testing scripts accordingly. http://src.mit.edu/fisheye/changelog/krb5/?cs=22803 Commit By: tlyu Revision: 22803 Changed Files: U branches/krb5-1-7/src/kadmin/dbutil/kdb5_create.c U branches/krb5-1-7/src/kadmin/server/ovsec_kadmd.c U branches/krb5-1-7/src/kadmin/testing/scripts/start_servers_local U branches/krb5-1-7/src/tests/dejagnu/config/default.exp From rt-comment at krbdev.mit.edu Mon Sep 28 17:22:45 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 21:22:45 +0000 (UTC) Subject: [krbdev.mit.edu #6428] SVN Commit In-Reply-To: Message-ID: pull up r22423, r22422 from trunk ------------------------------------------------------------------------ r22423 | tlyu | 2009-06-25 22:44:41 -0400 (Thu, 25 Jun 2009) | 4 lines ticket: 6428 Add test case omitted in last commit. ------------------------------------------------------------------------ r22422 | tlyu | 2009-06-25 22:43:21 -0400 (Thu, 25 Jun 2009) | 8 lines ticket: 6428 version_reported: 1.7 target_version: 1.7.1 tags: pullup Check for principal expiration prior to checking for password expiration. Reported by Phil Pishioneri. http://src.mit.edu/fisheye/changelog/krb5/?cs=22802 Commit By: tlyu Revision: 22802 Changed Files: U branches/krb5-1-7/src/kdc/kdc_util.c A branches/krb5-1-7/src/tests/dejagnu/krb-standalone/princexpire.exp From rt-comment at krbdev.mit.edu Mon Sep 28 17:27:40 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 21:27:40 +0000 (UTC) Subject: [krbdev.mit.edu #6519] SVN Commit In-Reply-To: Message-ID: pull up r22424 from trunk ------------------------------------------------------------------------ r22424 | ghudson | 2009-06-26 21:00:05 -0400 (Fri, 26 Jun 2009) | 7 lines ticket: 6519 tags: pullup target_version: 1.7 In krb5_copy_error_message, pass correct pointer to krb5int_clear_error. http://src.mit.edu/fisheye/changelog/krb5/?cs=22804 Commit By: tlyu Revision: 22804 Changed Files: U branches/krb5-1-7/src/lib/krb5/krb/kerrs.c From rt-comment at krbdev.mit.edu Mon Sep 28 17:27:43 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 28 Sep 2009 21:27:43 +0000 (UTC) Subject: [krbdev.mit.edu #6530] SVN Commit In-Reply-To: Message-ID: pull up r22435 from trunk ------------------------------------------------------------------------ r22435 | tlyu | 2009-07-10 15:46:20 -0400 (Fri, 10 Jul 2009) | 9 lines ticket: 6530 target_version: 1.7.1 tags: pullup subject: check for slogin failure in setup_root_shell Add a check for a slogin message that indicates an unknown public key fingerprint, as rlogin looks like it points to slogin by default on Debian Lenny. http://src.mit.edu/fisheye/changelog/krb5/?cs=22805 Commit By: tlyu Revision: 22805 Changed Files: U branches/krb5-1-7/src/tests/dejagnu/config/default.exp From rt-comment at krbdev.mit.edu Mon Sep 28 21:12:32 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 29 Sep 2009 01:12:32 +0000 (UTC) Subject: [krbdev.mit.edu #6540] SVN Commit In-Reply-To: Message-ID: pull up r22473 from trunk ------------------------------------------------------------------------ r22473 | epeisach | 2009-07-30 13:12:20 -0400 (Thu, 30 Jul 2009) | 5 lines ticket: 6540 subject: memory leak in test code t_authdata Free the krb5_context at the end to release memory. http://src.mit.edu/fisheye/changelog/krb5/?cs=22808 Commit By: tlyu Revision: 22808 Changed Files: U branches/krb5-1-7/src/lib/krb5/krb/t_authdata.c From rt-comment at krbdev.mit.edu Mon Sep 28 21:12:26 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 29 Sep 2009 01:12:26 +0000 (UTC) Subject: [krbdev.mit.edu #6532] SVN Commit In-Reply-To: Message-ID: pull up r22443 from trunk ------------------------------------------------------------------------ r22443 | tlyu | 2009-07-16 21:35:58 -0400 (Thu, 16 Jul 2009) | 8 lines ticket: 6531 target_version: 1.6.4 tags: pullup subject: include win-mac.h in gssftp/ftp/cmds.c for HAVE_STDLIB_H gssftp/ftp/cmds.c had a preprocessor conditional on HAVE_STDLIB_H that will not evaluate correctly on WIN32 unless win-mac.h is included first. http://src.mit.edu/fisheye/changelog/krb5/?cs=22807 Commit By: tlyu Revision: 22807 Changed Files: U branches/krb5-1-7/src/appl/gssftp/ftp/cmds.c From rt-comment at krbdev.mit.edu Mon Sep 28 21:12:37 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 29 Sep 2009 01:12:37 +0000 (UTC) Subject: [krbdev.mit.edu #6541] SVN Commit In-Reply-To: Message-ID: pull up r22474 from trunk ------------------------------------------------------------------------ r22474 | epeisach | 2009-07-30 13:22:28 -0400 (Thu, 30 Jul 2009) | 7 lines ticket: 6541 subject: Fix memory leak in k5_pac_verify_server_checksum k5_pac_verify_server_checksum was leaking memory when the checksum was valid. t_pac.c: Fix memory leak by forgetting to release memory. http://src.mit.edu/fisheye/changelog/krb5/?cs=22809 Commit By: tlyu Revision: 22809 Changed Files: U branches/krb5-1-7/src/lib/krb5/krb/pac.c U branches/krb5-1-7/src/lib/krb5/krb/t_pac.c From rt-comment at krbdev.mit.edu Mon Sep 28 21:12:43 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 29 Sep 2009 01:12:43 +0000 (UTC) Subject: [krbdev.mit.edu #6533] SVN Commit In-Reply-To: Message-ID: pull up r22475 from trunk ------------------------------------------------------------------------ r22475 | ghudson | 2009-07-30 15:06:37 -0400 (Thu, 30 Jul 2009) | 8 lines ticket: 6533 tags: pullup target_version: 1.7 Include in k5-platform.h, since we use assertions in some of the macros defined there, as well as in many source files which do not themselves include . Report and fix by Rainer Weikusat. http://src.mit.edu/fisheye/changelog/krb5/?cs=22810 Commit By: tlyu Revision: 22810 Changed Files: U branches/krb5-1-7/src/include/k5-platform.h From rt-comment at krbdev.mit.edu Mon Sep 28 21:38:50 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 29 Sep 2009 01:38:50 +0000 (UTC) Subject: [krbdev.mit.edu #6542] SVN Commit In-Reply-To: Message-ID: pull up r22516 from trunk ------------------------------------------------------------------------ r22516 | ghudson | 2009-08-10 15:12:47 -0400 (Mon, 10 Aug 2009) | 8 lines ticket: 6542 subject: Check for null characters in pkinit cert fields tags: pullup target_version: 1.7 When processing DNS names or MS UPNs in pkinit certs, disallow embedded null characters. http://src.mit.edu/fisheye/changelog/krb5/?cs=22811 Commit By: tlyu Revision: 22811 Changed Files: U branches/krb5-1-7/src/plugins/preauth/pkinit/pkinit_crypto_openssl.c From rt-comment at krbdev.mit.edu Mon Sep 28 21:39:03 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 29 Sep 2009 01:39:03 +0000 (UTC) Subject: [krbdev.mit.edu #6543] SVN Commit In-Reply-To: Message-ID: pull up r22519 from trunk ------------------------------------------------------------------------ r22519 | ghudson | 2009-08-12 14:53:47 -0400 (Wed, 12 Aug 2009) | 12 lines ticket: 6543 subject: Reply message ordering bug in ftpd tags: pullup target_version: 1.7 user() was replying to the user command and then calling login(), which could send a continuation reply if it fails to chdir to the user's homedir. Continuation replies must come before the actual reply; the mis-ordering was causing ftp and ftpd to deadlock. To fix the bug, invoke login() before reply() so that the continuation reply comes first. http://src.mit.edu/fisheye/changelog/krb5/?cs=22812 Commit By: tlyu Revision: 22812 Changed Files: U branches/krb5-1-7/src/appl/gssftp/ftpd/ftpd.c From rt-comment at krbdev.mit.edu Mon Sep 28 21:39:09 2009 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 29 Sep 2009 01:39:09 +0000 (UTC) Subject: [krbdev.mit.edu #6551] SVN Commit In-Reply-To: Message-ID: pull up r22636 from trunk ------------------------------------------------------------------------ r22636 | ghudson | 2009-08-27 09:40:50 -0400 (Thu, 27 Aug 2009) | 17 lines ticket: 6551 subject: Memory leak in spnego accept_sec_context error path tags: pullup target_version: 1.7 If the underlying mechanism's accept_sec_context returns an error, the spnego accept_sec_context was leaving allocated data in *context_handle, which is incorrect for the first call according to RFC 2744. Fix this by mirroring some code from the spnego init_sec_context, which always cleans up the half-constructed context in case of error. This is allowed (though not encouraged) by RFC 2744 for second and subsequent calls; since we were already doing it in init_sec_context, it seems simpler to do that than keep track of whether this is a first call or not. http://src.mit.edu/fisheye/changelog/krb5/?cs=22813 Commit By: tlyu Revision: 22813 Changed Files: U branches/krb5-1-7/src/lib/gssapi/spnego/spnego_mech.c