笑話

From rt-comment at krbdev.mit.edu Mon Dec 2 00:53:05 2002 From: rt-comment at krbdev.mit.edu (mizukami shine via RT) Date: Mon, 2 Dec 2002 00:53:05 -0500 (EST) Subject: [krbdev.mit.edu #1267] MIT Kerberos V5 release 1.2.6 des-cbc-md5 In-Reply-To: Message-ID: There is a question. MIT Kerberos V5 release 1.2.6 des-cbc-md5 Is encryption mode supported? If it sets up how again when supporting, it will be des-cbc-md5. Can encryption mode be confirmed? Since it is in a hurry just for a moment, if possible, please let me know early. Thank you for your consideration. __________________________________________________ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/ From rt-comment at krbdev.mit.edu Mon Dec 2 17:09:51 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 2 Dec 2002 17:09:51 -0500 (EST) Subject: [krbdev.mit.edu #1268] config option for kinit to skip krb524 In-Reply-To: Message-ID: As Paul suggests, some way of indicating that krb524 is not supported would be helpful, though I think we should consider some means that causes the krb524 code to return an appropriate error indication right away, rather than doing it entirely in kinit. From rt-comment at krbdev.mit.edu Tue Dec 3 08:16:17 2002 From: rt-comment at krbdev.mit.edu ( Sabrina Baretta via RT) Date: Tue, 3 Dec 2002 08:16:17 -0500 (EST) Subject: [krbdev.mit.edu #1269] Low cost quality conference calls In-Reply-To: Message-ID:

Compare What You Pay For Conference Calls
We Only Charge 15 Cents Per Minute!

(INCLUDES LONG DISTANCE)

No setup fees
No contracts or monthly fees
Call anytime, from anywhere, to anywhere
Connects up to 100 Participants
Simplicity in set up and administration
Operator Help available 24/7

Account Approval Required

Use Our Crystal Clear Conferencing Service
to Manage Your Long Distance Meetings.

Fill out the form below and a representative
will contact you with more information.

Required Input Field*

Name*

Web Address

Company Name

State*

Business Phone*

Home Phone

Email Address*

Type of Business

We are strongly against sending unsolicited emails to those who do not wish to receive our mailings. We have attained the services of an independent 3rd party to overlook list management and removal services. To be removed from our list, send an e-mail to remove at virtual-biz.net with the word "remove" in the subject line.
From rt-comment at krbdev.mit.edu Tue Dec 3 10:10:45 2002 From: rt-comment at krbdev.mit.edu (fariba@usc.edu via RT) Date: Tue, 3 Dec 2002 10:10:45 -0500 (EST) Subject: [krbdev.mit.edu #1270] Fw: Possible kadmind problem In-Reply-To: Message-ID: we run kerberos 1.2.2 and recently keep getting the following error.we do not see any problem with kadmin. any idea why it is happening? > ----- Original Message ----- > From: "System Manager" > To: > Sent: Monday, December 02, 2002 3:22 PM > Subject: Possible kadmind problem > > > > There may a problem with kadmind on kaus.usc.edu, please check. > > (if kadmind has been checked/restarted in the last hour, this message may > be redundant) > > > > > From raeburn at MIT.EDU Tue Dec 3 16:59:32 2002 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 03 Dec 2002 16:59:32 -0500 Subject: [krbdev.mit.edu #1270] Fw: Possible kadmind problem In-Reply-To: ("fariba@usc.edu via RT"'s message of "Tue, 3 Dec 2002 10:10:45 -0500 (EST)") References: Message-ID: "There may be a problem" doesn't tell us anything. This message doesn't come from our code. "fariba at usc.edu via RT" writes: > we run kerberos 1.2.2 and recently keep getting the following error.we do > not see any problem with kadmin. any idea why it is happening? >> > There may a problem with kadmind on kaus.usc.edu, please check. >> > (if kadmind has been checked/restarted in the last hour, this message > may >> be redundant) From rt-comment at krbdev.mit.edu Tue Dec 3 17:05:18 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 3 Dec 2002 17:05:18 -0500 (EST) Subject: [krbdev.mit.edu #1270] Fw: Possible kadmind problem In-Reply-To: Message-ID: "There may be a problem" doesn't tell us anything. This message doesn't come from our code. "fariba at usc.edu via RT" writes: > we run kerberos 1.2.2 and recently keep getting the following error.we do > not see any problem with kadmin. any idea why it is happening? >> > There may a problem with kadmind on kaus.usc.edu, please check. >> > (if kadmind has been checked/restarted in the last hour, this message > may >> be redundant) From rt-comment at krbdev.mit.edu Wed Dec 4 23:26:46 2002 From: rt-comment at krbdev.mit.edu (tbd234@mail.ht.net.tw via RT) Date: Wed, 4 Dec 2002 23:26:46 -0500 (EST) Subject: [krbdev.mit.edu #1271] 給家人更好的生活...你非看不可! In-Reply-To: Message-ID: 笑話

如果你這輩子想要有所成就，給家人好的生活，完成自己的理想，你!非了解這個機會不可...點我!也可以點這兒喔！
From rt-comment at krbdev.mit.edu Fri Dec 6 22:37:28 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Fri, 6 Dec 2002 22:37:28 -0500 (EST) Subject: [krbdev.mit.edu #1237] CVS Commit In-Reply-To: Message-ID: Checkpoint first step of merge. Moved per-file data into a separate object from the profile handle. Dropped some old MacOS 9 code. * prof_int.h: Include Mac OS X versions of header files if appropriate. Only include prof_err.h if profile.h doesn't define ERROR_TABLE_BASE_prof. (struct _prf_data_t): Move most of contents of _prf_file_t here. Add reference count. (prf_data_t): New typedef. (struct _prf_file_t): Include an array of one _prf_data_t structure. * prof_file.c (profile_open_file): Fill in "data" field. Drop some old Mac specific code. (profile_flush_file_data): Renamed from profile_flush_file, now takes prf_data_t argument. (profile_flush_file_data): Likewise. (profile_free_file): Now calls profile_free_file_data. (profile_free_file_data): New function, with most of old profile_free_file code. * prof_init.c (profile_init_path): Removed old Mac version. (profile_ser_size, profile_ser_externalize): Get file data from new "data" field. * prof_set.c (rw_setup, profile_update_relation, profile_clear_relation, profile_rename_section, profile_add_relation): Likewise. * prof_tree.c (profile_node_iterator): Likewise. * test_profile.c (do_batchmode): Likewise. * prof_int.h (profile_flush_file): Now a macro. * prof_err.et (PROF_MAGIC_FILE_DATA): New error code value. To generate a diff of this commit: cvs diff -r1.118 -r1.119 krb5/src/util/profile/ChangeLog cvs diff -r1.7 -r1.8 krb5/src/util/profile/prof_err.et cvs diff -r1.22 -r1.23 krb5/src/util/profile/prof_file.c cvs diff -r1.29 -r1.30 krb5/src/util/profile/prof_init.c cvs diff -r1.23 -r1.24 krb5/src/util/profile/prof_int.h cvs diff -r1.2 -r1.3 krb5/src/util/profile/prof_set.c cvs diff -r1.20 -r1.21 krb5/src/util/profile/prof_tree.c cvs diff -r1.12 -r1.13 krb5/src/util/profile/test_profile.c From rt-comment at krbdev.mit.edu Fri Dec 6 23:14:11 2002 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 6 Dec 2002 23:14:11 -0500 (EST) Subject: [krbdev.mit.edu #1189] CVS Commit In-Reply-To: Message-ID: Fix some KRB5_CALLCONV botches that were causing trouble for Windows build. Update send_to_kdc() to use various krb5 internals to talk to the krb4 KDC. Add a new internal function to optionally return the local address used to talk to the KDC. Many changes to lib/krb5/os to support this. Fix bug in krb5int_sendto() that prevented correct UDP length from being returned. Update callers of internal locate_* and sendto_* functions. To generate a diff of this commit: cvs diff -r1.329 -r1.330 krb5/src/include/ChangeLog cvs diff -r1.130 -r1.131 krb5/src/include/k5-int.h cvs diff -r1.146 -r1.147 krb5/src/lib/krb4/ChangeLog cvs diff -r1.6 -r1.7 krb5/src/lib/krb4/g_ad_tkt.c cvs diff -r1.10 -r1.11 krb5/src/lib/krb4/g_in_tkt.c cvs diff -r1.12 -r1.13 krb5/src/lib/krb4/send_to_kdc.c cvs diff -r5.334 -r5.335 krb5/src/lib/krb5/os/ChangeLog cvs diff -r5.12 -r5.13 krb5/src/lib/krb5/os/accessor.c cvs diff -r5.31 -r5.32 krb5/src/lib/krb5/os/changepw.c cvs diff -r5.72 -r5.73 krb5/src/lib/krb5/os/locate_kdc.c cvs diff -r5.27 -r5.28 krb5/src/lib/krb5/os/os-proto.h cvs diff -r5.59 -r5.60 krb5/src/lib/krb5/os/sendto_kdc.c cvs diff -r5.6 -r5.7 krb5/src/lib/krb5/os/t_locate_kdc.c cvs diff -r5.17 -r5.18 krb5/src/lib/krb5/os/t_std_conf.c From rt-comment at krbdev.mit.edu Fri Dec 6 23:17:26 2002 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 6 Dec 2002 23:17:26 -0500 (EST) Subject: [krbdev.mit.edu #1189] CVS Commit In-Reply-To: Message-ID: * sendmsg.c (krb524_sendto_kdc): Update calls to locate_server() and locate_kdc() to restrict protocol family to IPv4. To generate a diff of this commit: cvs diff -r1.116 -r1.117 krb5/src/krb524/ChangeLog cvs diff -r1.21 -r1.22 krb5/src/krb524/sendmsg.c From rt-comment at krbdev.mit.edu Mon Dec 9 16:26:08 2002 From: rt-comment at krbdev.mit.edu (rmdyer@uncc.edu via RT) Date: Mon, 9 Dec 2002 16:26:08 -0500 (EST) Subject: [krbdev.mit.edu #1201] kdc returns replay when replayed request not apparent In-Reply-To: Message-ID: MIT Kerberos Bug Support, Sam Hartman, Tom Yu We have projects in our group that we need to get moved forward. Since it looks like the replay packet problem is going to drag out for some time I've decided to accept a quick fix from Microsoft. My Microsoft support Kerberos developer in Redmond has hacked up a change to the WinXP "kerberos.dll" that includes a "Sleep()" function call at a critial location in the code. He said that this may produce performance problems (an improper and poor fix), but that it should solve my issue. I have tested his hacked dll and it does solve the problem. I no longer get replay packets back from the MIT KDC. I believe the hack will be made into a hotfix, at least my Microsoft tech rep said he was pushing it through QFE. I don't know if it will be a public or private fix yet. I do however anticipate that the issue with MIT's replay cache will be resolved, and that Microsoft will work well with a finalized Kerberos RFC that both organizations agree on. I am somewhat unhappy with the response so far from both organizations, but I suppose due to the levels at which this problem plays out, I shouldn't be too impatient. It does look like this this is a two part problem. On the one hand, MIT's code does not cache the entire authenticator. On the other, Microsoft really shouldn't be sending two auth requests with the same time in the microsecond field (my opinion). It would be nice to be notified by Microsoft/MIT when this issue is taken care of, but I'm not holding my breath. Thanks for the help, Rodney Rodney M. Dyer x86 Systems Programmer College of Engineering Computing Services University of North Carolina at Charlotte Email rmdyer at uncc.edu Phone (704)687-3518 Help Desk Line (704)687-3150 FAX (704)687-2352 Office 267 Smith Building At 10:32 PM 10/8/2002 -0400, you wrote: >Hi, it seems very likely that you have encountered a bug in replay >detection. There are many places to which we might assign blame for >this one. These include the MIT krb5 implementation of the replay >cache, the protocol specification itself, and the Windows krb5 client >implementation. > >Basically, the replay cache in MIT krb5 only stores the tuple of {client >principal, server principal, time, microseconds}. If two authenticators >have identical such tuples, the second is considered to be a replay, >even if it is different from the first. This behavior, while not >explicitly required by RFC 1510 (the specification of the Kerberos v5 >protocol), is strongly suggested by some wording in the RFC. > >A complicating factor is the historical behavior of the gettimeofday() >system call on Unix. This system call returns monotonically increasing >microsecond values for multiple calls within the same second, regardless >of whether the callers are different processes. Additionally, I believe >that the PC hardware clock only has a resolution of 55ms. If Windows is >using this hardware clock to retrieve microsecond values for >constructing authenticators, it is quite possible for two authenticators >for distinct requests to have identical {client principal, servver >principal, time, microseconds} tuples. > >In your packet trace, I see four distinct TGS-REQ messages. Of >particular interest are the third and fourth TGS-REQ messages. The >third, issued at 14:51:20.868353, asking for a >cifs/adcsm2.test.uncc.edu at UNCC.EDU ticket, receives a KRB-ERROR due to a >request for a non-existent service. The fourth, issued at >14:51:20.877389, asking for a ticket for krbtgt/TEST.UNCC.EDU at UNCC.EDU, >receives a replay error. Note that fewer than 55ms have elapsed between >these requests. > >I cannot verify my hypothesis directly, since I do not have access to >the session key used to encrypt the authenticators in question. I can >observe from the packet trace that they are not identical. At the very >least, the checksums inside the authenticators would have to be >different, as they intend to authenticate requests asking for different >tickets. > >I will attempt to correspond with some contacts at Microsoft to discover >whether my hypothesis regarding the Windows generation of microseconds >values for authenticators is likely to be correct. Meanwhile, I will >investigate correcting this bug in the MIT implementation, though it >does seem potentially difficult because of assumptions made in the API >design. Also, I have begun discussion in the IETF Kerberos working >group to discover if there are any security vulnerabilities that might >be introduced by making the replay detection procedure only compare the >encrypted authenticators. > >---Tom From rt-comment at krbdev.mit.edu Mon Dec 9 17:18:13 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 9 Dec 2002 17:18:13 -0500 (EST) Subject: [krbdev.mit.edu #1272] ktutil addent is not documented In-Reply-To: Message-ID: The addent command to ktutil is not documented. From rt-comment at krbdev.mit.edu Tue Dec 10 14:51:24 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 10 Dec 2002 14:51:24 -0500 (EST) Subject: [krbdev.mit.edu #1273] kadmin should gain option to remove old keys from keytab In-Reply-To: Message-ID: The ktrem old option seems to remove all but the most recent key. It would be nice if it had an option to remove all keys that have are neither current nor added within some period of time, so you could rekey and remove keys that will not be used for current tickets. From rt-comment at krbdev.mit.edu Tue Dec 10 14:56:21 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 10 Dec 2002 14:56:21 -0500 (EST) Subject: [krbdev.mit.edu #1274] kadmin should not authenticate simply to run the ktrem command In-Reply-To: Message-ID: Kadmin requires that I authenticate to the admin server in order to remove a key from my local keytab. This is annoying. It is hard to fix because of the structure of the kadmin program. IT may be easier to move this functionality into ktutil From rt-comment at krbdev.mit.edu Thu Dec 12 16:25:55 2002 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Thu, 12 Dec 2002 16:25:55 -0500 (EST) Subject: [krbdev.mit.edu #1189] CVS Commit In-Reply-To: Message-ID: More KfM merge work. Create new file FSp-glue.c including KfM functions that had previously been scattered through various other files. Port RealmsConfig-glue.c from KfM, including old Unix-ish krb4 configuration code as fallback. Remove other files containing old realm/config file support. Add KRB5_CALLCONV to krb_get_in_tkt_creds. Fix various functions to take const char* as arguments now that tkt_string() returns const. Assorted minor cleanup. Implement krb_get_err_text in terms of com_err. Implement gross kludge to force krb_err_txt to remain in sync with com_err. To generate a diff of this commit: cvs diff -r5.92 -r5.93 krb5/src/appl/telnet/libtelnet/ChangeLog cvs diff -r5.25 -r5.26 krb5/src/appl/telnet/libtelnet/kerberos.c cvs diff -r5.3 -r5.4 krb5/src/appl/telnet/libtelnet/strcasecmp.c cvs diff -r5.86 -r5.87 krb5/src/include/kerberosIV/ChangeLog cvs diff -r1.20 -r1.21 krb5/src/include/kerberosIV/des.h cvs diff -r1.46 -r1.47 krb5/src/include/kerberosIV/krb.h cvs diff -r5.240 -r5.241 krb5/src/kdc/ChangeLog cvs diff -r5.84 -r5.85 krb5/src/kdc/kerberos_v4.c cvs diff -r1.147 -r1.148 krb5/src/lib/krb4/ChangeLog cvs diff -r1.47 -r1.48 krb5/src/lib/krb4/Makefile.in cvs diff -r1.8 -r1.9 krb5/src/lib/krb4/dest_tkt.c cvs diff -r1.4 -r1.5 krb5/src/lib/krb4/err_txt.c cvs diff -r1.11 -r1.12 krb5/src/lib/krb4/g_in_tkt.c cvs diff -r1.9 -r1.10 krb5/src/lib/krb4/g_svc_in_tkt.c cvs diff -r1.3 -r1.4 krb5/src/lib/krb4/g_tf_fname.c krb5/src/lib/krb4/g_tf_realm.c cvs diff -r1.13 -r1.14 krb5/src/lib/krb4/in_tkt.c cvs diff -r1.7 -r1.8 krb5/src/lib/krb4/krb4int.h cvs diff -r1.1 -r1.2 krb5/src/lib/krb4/krb_err.et cvs diff -r1.13 -r1.14 krb5/src/lib/krb4/send_to_kdc.c cvs diff -r1.20 -r1.21 krb5/src/lib/krb4/tf_util.c cvs diff -r0 -r1.1 krb5/src/lib/krb4/FSp-glue.c krb5/src/lib/krb4/RealmsConfig-glue.c cvs diff -r1.5 -r0 krb5/src/lib/krb4/g_admhst.c cvs diff -r1.8 -r0 krb5/src/lib/krb4/g_krbhst.c cvs diff -r1.7 -r0 krb5/src/lib/krb4/g_krbrlm.c cvs diff -r1.14 -r0 krb5/src/lib/krb4/realmofhost.c From rt-comment at krbdev.mit.edu Thu Dec 12 16:25:55 2002 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Thu, 12 Dec 2002 16:25:55 -0500 (EST) Subject: [krbdev.mit.edu #1189] CVS Commit In-Reply-To: Message-ID: More KfM merge work. Create new file FSp-glue.c including KfM functions that had previously been scattered through various other files. Port RealmsConfig-glue.c from KfM, including old Unix-ish krb4 configuration code as fallback. Remove other files containing old realm/config file support. Add KRB5_CALLCONV to krb_get_in_tkt_creds. Fix various functions to take const char* as arguments now that tkt_string() returns const. Assorted minor cleanup. Implement krb_get_err_text in terms of com_err. Implement gross kludge to force krb_err_txt to remain in sync with com_err. To generate a diff of this commit: cvs diff -r5.92 -r5.93 krb5/src/appl/telnet/libtelnet/ChangeLog cvs diff -r5.25 -r5.26 krb5/src/appl/telnet/libtelnet/kerberos.c cvs diff -r5.3 -r5.4 krb5/src/appl/telnet/libtelnet/strcasecmp.c cvs diff -r5.86 -r5.87 krb5/src/include/kerberosIV/ChangeLog cvs diff -r1.20 -r1.21 krb5/src/include/kerberosIV/des.h cvs diff -r1.46 -r1.47 krb5/src/include/kerberosIV/krb.h cvs diff -r5.240 -r5.241 krb5/src/kdc/ChangeLog cvs diff -r5.84 -r5.85 krb5/src/kdc/kerberos_v4.c cvs diff -r1.147 -r1.148 krb5/src/lib/krb4/ChangeLog cvs diff -r1.47 -r1.48 krb5/src/lib/krb4/Makefile.in cvs diff -r1.8 -r1.9 krb5/src/lib/krb4/dest_tkt.c cvs diff -r1.4 -r1.5 krb5/src/lib/krb4/err_txt.c cvs diff -r1.11 -r1.12 krb5/src/lib/krb4/g_in_tkt.c cvs diff -r1.9 -r1.10 krb5/src/lib/krb4/g_svc_in_tkt.c cvs diff -r1.3 -r1.4 krb5/src/lib/krb4/g_tf_fname.c krb5/src/lib/krb4/g_tf_realm.c cvs diff -r1.13 -r1.14 krb5/src/lib/krb4/in_tkt.c cvs diff -r1.7 -r1.8 krb5/src/lib/krb4/krb4int.h cvs diff -r1.1 -r1.2 krb5/src/lib/krb4/krb_err.et cvs diff -r1.13 -r1.14 krb5/src/lib/krb4/send_to_kdc.c cvs diff -r1.20 -r1.21 krb5/src/lib/krb4/tf_util.c cvs diff -r0 -r1.1 krb5/src/lib/krb4/FSp-glue.c krb5/src/lib/krb4/RealmsConfig-glue.c cvs diff -r1.5 -r0 krb5/src/lib/krb4/g_admhst.c cvs diff -r1.8 -r0 krb5/src/lib/krb4/g_krbhst.c cvs diff -r1.7 -r0 krb5/src/lib/krb4/g_krbrlm.c cvs diff -r1.14 -r0 krb5/src/lib/krb4/realmofhost.c From rt-comment at krbdev.mit.edu Thu Dec 12 17:15:27 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 12 Dec 2002 17:15:27 -0500 (EST) Subject: [krbdev.mit.edu #669] There should be a configure option for USE_RCACHE In-Reply-To: Message-ID: I disagree that a configure option should exist to disable replay caches. The Kerberos specification requires that they be used so making them easy to disable is not desirable. From rt-comment at krbdev.mit.edu Thu Dec 12 17:22:46 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 12 Dec 2002 17:22:46 -0500 (EST) Subject: [krbdev.mit.edu #1202] KDC also rejects some valid flags In-Reply-To: Message-ID: Love points out that our KDC also rejects the disabled transited check option which it does understand. Fixing this bug should fix that issue as well. I have marked for inclusion in 1.3. From rt-comment at krbdev.mit.edu Thu Dec 12 20:31:25 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Thu, 12 Dec 2002 20:31:25 -0500 (EST) Subject: [krbdev.mit.edu #669] There should be a configure option for USE_RCACHE In-Reply-To: Message-ID: [hartmans - Thu Dec 12 17:15:26 2002]: > I disagree that a configure option should exist to disable replay > caches. Then perhaps you should put removal of the --enable/disable-kdc-replay-cache option from kdc/configure.in, and documenting the change from 1.2, onto the 1.3 task list. > The Kerberos specification requires that they be used so making > them easy to disable is not desirable. They're of limited use in the KDC, I think. From rt-comment at krbdev.mit.edu Thu Dec 12 20:35:02 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Thu, 12 Dec 2002 20:35:02 -0500 (EST) Subject: [krbdev.mit.edu #1202] KDC rejects unknown flags In-Reply-To: Message-ID: [hartmans - Thu Dec 12 17:22:45 2002]: > Love points out that our KDC also rejects the disabled transited check > option which it does understand. Yes, that's part of the protection against exploitation of the old chk_trans.c bug. We shouldn't make the KDC obey this flag unconditionally without warning admins that they'll need to upgrade servers that are too old. (Not obeying but not rejecting would probably be okay.) From rt-comment at krbdev.mit.edu Sun Dec 15 22:03:25 2002 From: rt-comment at krbdev.mit.edu ( Holiday Greetings via RT) Date: Sun, 15 Dec 2002 22:03:25 -0500 (EST) Subject: [krbdev.mit.edu #1275] Your Receipt In-Reply-To: Message-ID: Get Free Gas... and earn CASH! What if every gas station in your town was selling gas for $1.50 per gallon and a new station opened up selling gas at $1.19? Wouldn't you buy your gas there and tell everyone you know about it? Right now there is a company willing to pay you lots of money and give you free gasto tell the world how to save money on gasoline. Someone earned$2100 their first day doing exactly that. Do yourself a favor by calling 1-888-321-7078 and Get Free Gas... and earn CASH! Thank you. =============================================================== This message was not sent unsolicited. Your email has been submitted and verified for opt in promotions. Note: This is not a spam email. This email was sent to you because you have been verified and agreed to opt in to receive promotional material. If you wish to unsubscribe or if you received this email by error, please reply to: merry_christmas at vrfund.com From rt-comment at krbdev.mit.edu Mon Dec 16 14:42:42 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 16 Dec 2002 14:42:42 -0500 (EST) Subject: [krbdev.mit.edu #1202] KDC rejects unknown flags In-Reply-To: Message-ID: >>>>> "Ken" == Ken Raeburn via RT writes: Ken> [hartmans - Thu Dec 12 17:22:45 2002]: >> Love points out that our KDC also rejects the disabled >> transited check option which it does understand. Ken> Yes, that's part of the protection against exploitation of Ken> the old chk_trans.c bug. We shouldn't make the KDC obey this Ken> flag unconditionally without warning admins that they'll need Ken> to upgrade servers that are too old. (Not obeying but not Ken> rejecting would probably be okay.) I think that doing so for 1.3 would be fine, particularly if we get our act together and document it and publish the CERT advisory. From rt-comment at krbdev.mit.edu Mon Dec 16 16:49:07 2002 From: rt-comment at krbdev.mit.edu (Ezra Peisach via RT) Date: Mon, 16 Dec 2002 16:49:07 -0500 (EST) Subject: [krbdev.mit.edu #1276] Compiling --without-krb4 fails due to dependencies in Makefile.in In-Reply-To: Message-ID: appl/bsd and appl/gssftp/ftpd fail to compile if --without-krb4 is specified due to dependency on include/krb524.h listed in Makefile.in. Two solutions as I see them: a) In generating dependencies, strip out the krb524.h dependency b) Always generate a krb524.h header file - even if not building with krb4. Ezra From rt-comment at krbdev.mit.edu Mon Dec 16 17:50:31 2002 From: rt-comment at krbdev.mit.edu (登錄桃太郎@MIT.EDU via RT) Date: Mon, 16 Dec 2002 17:50:31 -0500 (EST) Subject: [krbdev.mit.edu #1277] Re:有人找不到你們的網站 ! K5jgE6EaBxj4WqxBPz06YWP In-Reply-To: Message-ID: 提供100名

From rt-comment at krbdev.mit.edu Tue Dec 17 11:55:43 2002 From: rt-comment at krbdev.mit.edu (Ken Hornstein via RT) Date: Tue, 17 Dec 2002 11:55:43 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: I discovered recently that the API krb5_get_init_creds_keytab doesn't take a prompter argument. This makes it difficult to do things like hardware preauthentication using a key stored in a keytab. I propose the following API to solve the problem: krb5_get_init_creds_keytab_prompter KRB5_PROTOTYPE((krb5_context context, krb5_creds *creds, krb5_principal client, krb5_keytab arg_keytab, krb5_prompter_fct prompter, void *data, krb5_deltat start_time, char *in_tkt_service, krb5_get_init_creds_opt *options)); (Obviously, it looks a whole lot like the krb5_get_init_creds_keytab API). I'm not so convinced the name is particularly great, though. Any comments? From marc at MIT.EDU Tue Dec 17 13:05:53 2002 From: marc at MIT.EDU (Marc Horowitz) Date: 17 Dec 2002 13:05:53 -0500 Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: "Ken Hornstein via RT"'s message of "Tue, 17 Dec 2002 11:55:43 -0500 (EST)" References: Message-ID: "Ken Hornstein via RT" writes: >> I discovered recently that the API krb5_get_init_creds_keytab doesn't >> take a prompter argument. This makes it difficult to do things like >> hardware preauthentication using a key stored in a keytab. >> >> Any comments? Why do you think you need this? The idea of getting initial creds from a keytab is that a daemon or other automated task can act as a kerberos client without user interaction. If you require user interaction, why aren't you just using a password? Marc From rt-comment at krbdev.mit.edu Tue Dec 17 13:06:12 2002 From: rt-comment at krbdev.mit.edu ( via RT) Date: Tue, 17 Dec 2002 13:06:12 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: "Ken Hornstein via RT" writes: >> I discovered recently that the API krb5_get_init_creds_keytab doesn't >> take a prompter argument. This makes it difficult to do things like >> hardware preauthentication using a key stored in a keytab. >> >> Any comments? Why do you think you need this? The idea of getting initial creds from a keytab is that a daemon or other automated task can act as a kerberos client without user interaction. If you require user interaction, why aren't you just using a password? Marc From rt-comment at krbdev.mit.edu Tue Dec 17 13:17:44 2002 From: rt-comment at krbdev.mit.edu (Ken Hornstein via RT) Date: Tue, 17 Dec 2002 13:17:44 -0500 (EST) Subject: [krbdev.mit.edu #1279] Internal API change to support hardware preauth better In-Reply-To: Message-ID: If krb5_get_init_creds() gets an error, it will retry the request against the master KDC. This doesn't involve any more user interaction, since the password is cached in a callback structure. But in the hardware preauthentication case, a user is asked for their hardware token multiple times. The library needs to cache the hardware token information so it doesn't prompt the user for the token again. From rt-comment at krbdev.mit.edu Tue Dec 17 13:21:42 2002 From: rt-comment at krbdev.mit.edu (Ken Hornstein via RT) Date: Tue, 17 Dec 2002 13:21:42 -0500 (EST) Subject: [krbdev.mit.edu #1280] There is no memory keytab In-Reply-To: Message-ID: There isn't a memory keytab, but a keytab is the only way to provide a key to some functions (like krb5_rd_req()). There should be one. From rt-comment at krbdev.mit.edu Tue Dec 17 13:23:28 2002 From: rt-comment at krbdev.mit.edu (Ken Hornstein via RT) Date: Tue, 17 Dec 2002 13:23:28 -0500 (EST) Subject: [krbdev.mit.edu #1281] fakeka needs to be integrated into the distribution tree. In-Reply-To: Message-ID: Fakeka needs to be imported into the build tree. From rt-comment at krbdev.mit.edu Tue Dec 17 13:39:44 2002 From: rt-comment at krbdev.mit.edu (kenh@cmf.nrl.navy.mil via RT) Date: Tue, 17 Dec 2002 13:39:44 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: >Why do you think you need this? The idea of getting initial creds >from a keytab is that a daemon or other automated task can act as a >kerberos client without user interaction. If you require user >interaction, why aren't you just using a password? I need to use a host key in a keytab (hence keytab) as a user's long-term key with a hardware token (user interaction). This is to implement Matt Crawford's hw-auth draft. Okay, so technically I don't need a keytab interface, but there's no way to give the API a raw key and provide a prompter interface, and that's the real deficiency. --Ken From marc at MIT.EDU Tue Dec 17 14:38:33 2002 From: marc at MIT.EDU (Marc Horowitz) Date: 17 Dec 2002 14:38:33 -0500 Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: "kenh@cmf.nrl.navy.mil via RT"'s message of "Tue, 17 Dec 2002 13:39:44 -0500 (EST)" References: Message-ID: "kenh at cmf.nrl.navy.mil via RT" writes: >> I need to use a host key in a keytab (hence keytab) as a user's >> long-term key with a hardware token (user interaction). Why do you need to do this? When, in the real world, would this ever happen? >> This is to implement Matt Crawford's hw-auth draft. Okay, so >> technically I don't need a keytab interface, but there's no way to >> give the API a raw key and provide a prompter interface, and that's >> the real deficiency. You haven't convinced me there's a deficiency here. Marc From rt-comment at krbdev.mit.edu Tue Dec 17 14:38:36 2002 From: rt-comment at krbdev.mit.edu ( via RT) Date: Tue, 17 Dec 2002 14:38:36 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: "kenh at cmf.nrl.navy.mil via RT" writes: >> I need to use a host key in a keytab (hence keytab) as a user's >> long-term key with a hardware token (user interaction). Why do you need to do this? When, in the real world, would this ever happen? >> This is to implement Matt Crawford's hw-auth draft. Okay, so >> technically I don't need a keytab interface, but there's no way to >> give the API a raw key and provide a prompter interface, and that's >> the real deficiency. You haven't convinced me there's a deficiency here. Marc From rt-comment at krbdev.mit.edu Tue Dec 17 14:54:43 2002 From: rt-comment at krbdev.mit.edu (kenh@cmf.nrl.navy.mil via RT) Date: Tue, 17 Dec 2002 14:54:43 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: >>> I need to use a host key in a keytab (hence keytab) as a user's >>> long-term key with a hardware token (user interaction). > >Why do you need to do this? When, in the real world, would this ever >happen? Actually, this is something we do every day here; we want the ability to validate someone's hardware token for root access via sudo. We used the old API before, and I was updating everything to the new API. It's not like I was making this up, you know :-) This is all tied up in the requirement for hardware preauthentication at DOD supercomputer sites. >>> This is to implement Matt Crawford's hw-auth draft. Okay, so >>> technically I don't need a keytab interface, but there's no way to >>> give the API a raw key and provide a prompter interface, and that's >>> the real deficiency. > >You haven't convinced me there's a deficiency here. Well, let's turn this around a bit; is there a reason NOT to implement this? Okay, I understand the generic argument of additional API calls increasing Kerberos programming complexity (it's complex enough as is), and I can accept that in a generic sense ... but it seems like, in hindsight, that if we were designing this API today, I would argue that leaving the possibility of having a prompter callback in this function (when doing so would be trivially simple) could only be a possible win. And I don't really see how to implement this without an API change somewhere; it's either this, or implement something like krb5_get_init_creds_skey. --Ken From marc at MIT.EDU Tue Dec 17 16:07:37 2002 From: marc at MIT.EDU (Marc Horowitz) Date: 17 Dec 2002 16:07:37 -0500 Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: "kenh@cmf.nrl.navy.mil via RT"'s message of "Tue, 17 Dec 2002 14:54:43 -0500 (EST)" References: Message-ID: "kenh at cmf.nrl.navy.mil via RT" writes: >> >>> I need to use a host key in a keytab (hence keytab) as a user's >> >>> long-term key with a hardware token (user interaction). >> > >> >Why do you need to do this? When, in the real world, would this ever >> >happen? >> >> Actually, this is something we do every day here; we want the ability to >> validate someone's hardware token for root access via sudo. We used the >> old API before, and I was updating everything to the new API. It's not >> like I was making this up, you know :-) This is all tied up in the >> requirement for hardware preauthentication at DOD supercomputer sites. Now I think I understand. You're just using the keytab because it's convenient, not because you have some requirement to authenticate as the specific key in the keytab. You're also trying to avoid making the user type his password again, even though the user will have to do the hardware preauth interaction. For that matter, isn't the hardware token specific to the user? Can you use an arbitrary user's hardware token with the key in the keytab? How do you know which token is being used, since the client name in the as-req is goint to be the name from the keytab? If this is currently working as you imply, can you explain it so I can understand it better? Then maybe I can come up with some more clever suggestion. Marc From rt-comment at krbdev.mit.edu Tue Dec 17 16:07:40 2002 From: rt-comment at krbdev.mit.edu ( via RT) Date: Tue, 17 Dec 2002 16:07:40 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: "kenh at cmf.nrl.navy.mil via RT" writes: >> >>> I need to use a host key in a keytab (hence keytab) as a user's >> >>> long-term key with a hardware token (user interaction). >> > >> >Why do you need to do this? When, in the real world, would this ever >> >happen? >> >> Actually, this is something we do every day here; we want the ability to >> validate someone's hardware token for root access via sudo. We used the >> old API before, and I was updating everything to the new API. It's not >> like I was making this up, you know :-) This is all tied up in the >> requirement for hardware preauthentication at DOD supercomputer sites. Now I think I understand. You're just using the keytab because it's convenient, not because you have some requirement to authenticate as the specific key in the keytab. You're also trying to avoid making the user type his password again, even though the user will have to do the hardware preauth interaction. For that matter, isn't the hardware token specific to the user? Can you use an arbitrary user's hardware token with the key in the keytab? How do you know which token is being used, since the client name in the as-req is goint to be the name from the keytab? If this is currently working as you imply, can you explain it so I can understand it better? Then maybe I can come up with some more clever suggestion. Marc From rt-comment at krbdev.mit.edu Tue Dec 17 16:22:19 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 17 Dec 2002 16:22:19 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: Marc, read the draft (draft-ietf-krb-wg-hw-auth) if you want to understand what is going on. I actually think that passing in this particular key as the keytab is wrong, but since Ken is not planning on contributing the code that uses this preauth type, just the new get_init_creds API, I don't have to make that evaluation. While I agree that keytabs are commonly used to by applications that do not want user interaction, it does not seem unreasonable to use them in other circumstances where using a prompter is appropriate. Certainly it is possible to store a long-term key in a keytab even if the KDC requires preauth for that key. In the current code base there is not client side support for this case. From rt-comment at krbdev.mit.edu Tue Dec 17 17:51:14 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 17 Dec 2002 17:51:14 -0500 (EST) Subject: [krbdev.mit.edu #1282] need standard way of finding keytab In-Reply-To: Message-ID: Hacks like this shouldn't be needed. There should be some standard way of indicating where a keytab is located for a given user or service. For example, perhaps non-root users would look in ~/etc/krb5.keytab, or maybe krb5.conf could have a table mapping principal names or service (first-component) names to pathnames ("zephyr = /usr/local/etc/zephyr/zephyr.keytab"). Maybe both. No special configuration should be needed to look for the current standard services (host and ftp at least) in the standard keytab, though that could be accomplished by having a list of names instead of just one. Say, if the default is "~/etc/krb5.keytab:/etc/krb5.keytab" or equivalent. Ken From rt-comment at krbdev.mit.edu Tue Dec 17 23:50:15 2002 From: rt-comment at krbdev.mit.edu (kenh@cmf.nrl.navy.mil via RT) Date: Tue, 17 Dec 2002 23:50:15 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: >Now I think I understand. You're just using the keytab because it's >convenient, not because you have some requirement to authenticate as >the specific key in the keytab. You're also trying to avoid making >the user type his password again, even though the user will have to do >the hardware preauth interaction. Right, exactly. Well, it's a _bit_ more complex than that. Sam explained it fairly well in his message, but the problem is that the host key is taking the place of the user's long-term key. So that needs to make it into the library ... but you can't feed a raw key into krb5_get_init_creds_password(), and krb5_get_init_creds_keytab() doesn't take a prompter, and so on ... I thought about something along the lines of krb5_get_init_creds_skey(), but the problem with THAT is that you want to be able to pass in multiple keys to match whatever the KDC sends back, and designing an API for that seemed more work than I wanted to tackle (and I wasn't sure it was the right answer). >For that matter, isn't the hardware token specific to the user? Can >you use an arbitrary user's hardware token with the key in the keytab? >How do you know which token is being used, since the client name in >the as-req is goint to be the name from the keytab? Well ... since you asked ... What I did was write a half-assed implementation of a memory keytab, just enough to make krb5_get_init_creds_keytab() work. I then read out all of the host keys out of the on-disk keytab and placed them into the memory keytab, but with the user's principal as the principal name in the keytab entry. Seems to work alright. And before anyone mentions ... yes, I know that I had to use a private API to register a new keytab type, but it seems like the right solution there is to write a "real" memory keytab type (since it's the only way to feed in a key to calls like krb5_rd_req()). --Ken From basch at MIT.EDU Wed Dec 18 07:30:56 2002 From: basch at MIT.EDU (Richard Basch) Date: Wed, 18 Dec 2002 07:30:56 -0500 Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: I wonder if there should be some way of registering a "preauth" handler (ie. callback function) into one of the opaque structures, such that when prompting or other actions are required, the handler is called and can take care of the issues. I don't think we want users to pass a function pointer directly to the API, but some type of "function" registration may be useful, such that it is populated with a default/null handler, and advanced programmers such as Ken, can benefit. Thoughts? > -----Original Message----- > From: krb5-bugs-admin at MIT.EDU [mailto:krb5-bugs-admin at MIT.EDU]On Behalf > Of kenh at cmf.nrl.navy.mil via RT > Sent: Tuesday, December 17, 2002 11:50 PM > To: krb5-prs at mit.edu > Subject: Re: [krbdev.mit.edu #1278] No prompter interface for > krb5_get_init_creds_keytab > > > > >Now I think I understand. You're just using the keytab because it's > >convenient, not because you have some requirement to authenticate as > >the specific key in the keytab. You're also trying to avoid making > >the user type his password again, even though the user will have to do > >the hardware preauth interaction. > > Right, exactly. Well, it's a _bit_ more complex than that. Sam explained > it fairly well in his message, but the problem is that the host key is > taking the place of the user's long-term key. So that needs to make it > into the library ... but you can't feed a raw key into > krb5_get_init_creds_password(), and krb5_get_init_creds_keytab() doesn't > take a prompter, and so on ... I thought about something along the lines > of krb5_get_init_creds_skey(), but the problem with THAT is that you want > to be able to pass in multiple keys to match whatever the KDC sends back, > and designing an API for that seemed more work than I wanted to tackle > (and I wasn't sure it was the right answer). > > >For that matter, isn't the hardware token specific to the user? Can > >you use an arbitrary user's hardware token with the key in the keytab? > >How do you know which token is being used, since the client name in > >the as-req is goint to be the name from the keytab? > > Well ... since you asked ... > > What I did was write a half-assed implementation of a memory keytab, > just enough to make krb5_get_init_creds_keytab() work. I then read out > all of the host keys out of the on-disk keytab and placed them into the > memory keytab, but with the user's principal as the principal name in > the keytab entry. Seems to work alright. And before anyone mentions ... > yes, I know that I had to use a private API to register a new keytab > type, but it seems like the right solution there is to write a "real" > memory keytab type (since it's the only way to feed in a key to calls > like krb5_rd_req()). > > --Ken > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > http://mailman.mit.edu/mailman/listinfo/krb5-bugs > From rt-comment at krbdev.mit.edu Wed Dec 18 07:33:32 2002 From: rt-comment at krbdev.mit.edu (basch@MIT.EDU via RT) Date: Wed, 18 Dec 2002 07:33:32 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: I wonder if there should be some way of registering a "preauth" handler (ie. callback function) into one of the opaque structures, such that when prompting or other actions are required, the handler is called and can take care of the issues. I don't think we want users to pass a function pointer directly to the API, but some type of "function" registration may be useful, such that it is populated with a default/null handler, and advanced programmers such as Ken, can benefit. Thoughts? > -----Original Message----- > From: krb5-bugs-admin at MIT.EDU [mailto:krb5-bugs-admin at MIT.EDU]On Behalf > Of kenh at cmf.nrl.navy.mil via RT > Sent: Tuesday, December 17, 2002 11:50 PM > To: krb5-prs at mit.edu > Subject: Re: [krbdev.mit.edu #1278] No prompter interface for > krb5_get_init_creds_keytab > > > > >Now I think I understand. You're just using the keytab because it's > >convenient, not because you have some requirement to authenticate as > >the specific key in the keytab. You're also trying to avoid making > >the user type his password again, even though the user will have to do > >the hardware preauth interaction. > > Right, exactly. Well, it's a _bit_ more complex than that. Sam explained > it fairly well in his message, but the problem is that the host key is > taking the place of the user's long-term key. So that needs to make it > into the library ... but you can't feed a raw key into > krb5_get_init_creds_password(), and krb5_get_init_creds_keytab() doesn't > take a prompter, and so on ... I thought about something along the lines > of krb5_get_init_creds_skey(), but the problem with THAT is that you want > to be able to pass in multiple keys to match whatever the KDC sends back, > and designing an API for that seemed more work than I wanted to tackle > (and I wasn't sure it was the right answer). > > >For that matter, isn't the hardware token specific to the user? Can > >you use an arbitrary user's hardware token with the key in the keytab? > >How do you know which token is being used, since the client name in > >the as-req is goint to be the name from the keytab? > > Well ... since you asked ... > > What I did was write a half-assed implementation of a memory keytab, > just enough to make krb5_get_init_creds_keytab() work. I then read out > all of the host keys out of the on-disk keytab and placed them into the > memory keytab, but with the user's principal as the principal name in > the keytab entry. Seems to work alright. And before anyone mentions ... > yes, I know that I had to use a private API to register a new keytab > type, but it seems like the right solution there is to write a "real" > memory keytab type (since it's the only way to feed in a key to calls > like krb5_rd_req()). > > --Ken > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > http://mailman.mit.edu/mailman/listinfo/krb5-bugs > From rt-comment at krbdev.mit.edu Thu Dec 19 00:54:11 2002 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 19 Dec 2002 00:54:11 -0500 (EST) Subject: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab In-Reply-To: Message-ID: So, note that there are two sides to the interaction. I think the current interface correctly handles the case where you want the preaauth mechanism to interact with a user using an application-supplied prompter function. This is mechanism-independent and similar to PAM conversation functions. Ken pointed out that we have no way of setting this up while using a keytab to get a long-term key. I agree that this functionality should be offered and agreed to accept the functionality if code is committed. I disagree that Ken's use of the keytab interface for the hw-auth draft is appropriate but don't believe he plans to give us that code, so I'm not sure it matters. None of this speaks to a related problem which is how we get preauth mechanism specific data from an application or hardware device to that mechanism. The current prompter interface is clearly appropriate (as are things like PAM conversation functions within the PAM framework). It sounds like Richard is addressing that problem rather than the user interaction problem. From rt-comment at krbdev.mit.edu Thu Dec 19 00:55:59 2002 From: rt-comment at krbdev.mit.edu ( diesel fuel injection via RT) Date: Thu, 19 Dec 2002 00:55:59 -0500 (EST) Subject: [krbdev.mit.edu #1283] Head & Rotor VE 12/18 In-Reply-To: Message-ID: Dear Sir, *※笢繚籵饜璃釦§蚳珛汜莉VE掙芛(VE煦饜掙掙芛軞傖),翋猁倰瘍衄拻坋鍊4JB1,艙隴佴6BT,甡峎螞腴齬溫,拻坋鍵④縐..... * 笢繚籵饜璃釦衄嗣爛汜莉VE掙芛腔冪桄, 釬峈誕婌輛⻌蚐掙蚐郲俴珛腔蚳珛釦,扂蠅奀覦躲趿弊暱跪華［坳莘蚐�蚐驗扞炵苀腔秶婖妀腔汜莉馱眙,甜ブ祥剿柲彶弊暱奻郔珂輛腔樓馱,聆彸馱.莉ⅲ腔窐講睿俋夤肮弊俋肮濬莉ⅲ眈絞. * ⺼勤扂蠅腔莉ⅲ覜倓𧘇,ワ籵眭扂蠅. we have been in the field of diesel fuel injection systems for quite a few years.(CHINA) Recently we have developed a new kind of h&r, AM Bosch number HD90100A.Its unit price is USD150/pc.And we also adjust the unit price of Nozzle , Plunger to USD4~5/pc respectively. We tell you that we will update our VE h&r (hydraulic heads for the VE distributor pump) list in our homepages.Thirty more models will be added.And the minimum order will be 10pcs a model. we give the unity quotation of VE distributor head: 3-cyl:USD:55/1pcs 4-cyl:USD:40~50/1pcs 5-cyl:USD:55/1pcs 6-cyl:USD:45~50/1pcs We can ship the following three models to you within 8~10 weeks. after we receive your payment. If you feel interested in our products,please advise the details about what you need,such model name,part number,quantity and so on.We are always within your touch. we'd like to interchange our website's linkage with you.As a result,we can add the icon of your website to our website's main-page. Vice versa.What do you think of that? Thanks and best regards Looking forward to our favorable cooperation. Hope to hear from you soon. (NIPPON DENSO) 096400-0143 096400-0242 096400-0262 096400-0371 096400-0432 096400-1030 096400-1060 096400-1090 096400-1210 096400-1220 096400-1230 096400-1240 096400-1250 096400-1330 096400-1331 096400-1600 096540-0080 146400-2220 145400-3320 146400-4520 146400-5521 146400-8821 146400-9720 146401-0520 146401-2120 146402-0820 146402-0920 146402-1420 146402-4020 146402-4320 146402-3820 146403-2820 146403-3120 146403-3520 146404-1520 146404-2200 146405-1920 146430-1420 1 468 333 320 1 468 333 323 1 468 334 313 1 468 334 327 1 468 334 565 1 468 334 337 1 468 334 378 1 468 334 424 1 468 334 475 1 468 334 485 1 468 334 494 1 468 334 496 1 468 334 580 1 468 334 590 1 468 334 564 1 468 334 565 1 468 334 575 1 468 334 592 1 468 334 595 1 468 334 596 1 468 334 603 1 468 334 604 1 468 334 606 1 468 334 617 1 468 334 675 1 468 334 678 1 468 334 720 1 468 334 780 1 468 334 798 1 468 334 859 1 468 334 874 1 468 334 899 1 468 334 946 1 468 335 345 2 468 335 022 1 468 336 335 1 468 336 352 1 468 336 364 1 468 336 403 1 468 336 423 1 468 336 464 1 468 336 480 1 468 336 528 1 468 336 608 1 468 336 614 1 468 336 626 1 468 336 632 2 468 334 050 2 468 334 021 2 468 336 013 C.Hua Sales & purchasing director http://WWW.China-LuTon.com china-lutong at ynmail.com From rt-comment at krbdev.mit.edu Thu Dec 19 18:21:06 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Thu, 19 Dec 2002 18:21:06 -0500 (EST) Subject: [krbdev.mit.edu #1284] rcp tests and ipv6 In-Reply-To: Message-ID: The test suite support for rcp doesn't handle ipv6, nor does it handle output from rcp saying that connections were refused at the first address tried but there are other addresses to try. If the local hostname maps to an ipv6 address as well as an ipv4 address, this combination can cause false negative results from the test suite. I suggest fixing both: - make the standalone daemon code handle ipv6 if available - make the test suite deal with multiple listed addresses when some are refusing connections, timing out, whatever (this one might also affect, say, disconnected laptops with their "normal" addresses listed in /etc/hosts but not on any interface while disconnected) From rt-comment at krbdev.mit.edu Sun Dec 22 01:00:31 2002 From: rt-comment at krbdev.mit.edu (jack@yahoo.com.tw via RT) Date: Sun, 22 Dec 2002 01:00:31 -0500 (EST) Subject: [krbdev.mit.edu #1285] 很值得看一看喔!尤其是有喜歡的人!! In-Reply-To: Message-ID: 被深愛的六大條件
被深愛的六大條件

當一個令人愛到心坎、一生一世都想要在一起的人，究竟有什麼祕訣呢？其實很簡單，但是很少人能從頭到尾、貫徹始終地做到。

1.開朗 笑容隨時都可以令人精神為之一振

2.元氣 這年頭，並不是長得美才叫做帥哥、美人

3.溫柔人的溫柔可以軟化一切

        4.口才不是每個人都有像推銷員或是政客一般擁有流利的口才但是身為一個理   想情人可就得具備察言觀色、適時說出動聽、窩心的話來讓對方覺得舒服的本事。

5.信賴不管別人說什麼要打從心底相信一個人的確不是一件容易的情。

6.尊重聽對方說話的時候總是認真地看著對方的眼睛

你想要找到這些人嗎?或者你想成為這樣的人呢?

請按此進入

From rt-comment at krbdev.mit.edu Mon Dec 23 14:01:54 2002 From: rt-comment at krbdev.mit.edu (456@MIT.EDU via RT) Date: Mon, 23 Dec 2002 14:01:54 -0500 (EST) Subject: [krbdev.mit.edu #1286] 一個創新的觀念,您一定要知道!!! In-Reply-To: Message-ID: 新網頁1
☆在現階段全球景氣低迷，台灣失業率高達５％☆
有人沒工作，一直在找工作．．．
有人有工作，卻怕那天工作不要他了．．．

有人有機會，一直不懂把握．．．
有人沒機會，卻一直尋找成功的法則．．．

如果你找不到工作，快看看到底現在賺錢的行業是什麼．．．
如果你有工作，快看看是不是可以有一個可以兼職再為自己加薪或備胎的機會．．．
錢不是萬能，沒有錢卻萬萬不能‧我們要活到老、學到老、卻不要做到老..
想要擺脫捉襟見肘、省吃儉用的窘境，就只有趕快掌握趨勢‧創造財富
存款零利率，股票不爭氣，想要成為富爸爸唯有將消費成為資產而非負債....

獻給為了可愛的孩子、快樂的妻子、健康的父母，以及我們一切未完成的夢想打拼的你...

一個創新的行業，等您來了解******請點選

　

祝您今年心想事成，財源滾滾
如本廣告信對您產生困擾，請您刪除此信並在此深感報歉！請多見諒，謝謝！

From rt-comment at krbdev.mit.edu Mon Dec 23 17:43:08 2002 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 23 Dec 2002 17:43:08 -0500 (EST) Subject: [krbdev.mit.edu #1276] CVS Commit In-Reply-To: Message-ID: Replace dependencies on generated krb524 and krb4 headers with variables, to allow correct behavior when krb4 is disabled. To generate a diff of this commit: cvs diff -r5.390 -r5.391 krb5/src/ChangeLog cvs diff -r1.248 -r1.249 krb5/src/aclocal.m4 cvs diff -r5.71 -r5.72 krb5/src/appl/bsd/Makefile.in cvs diff -r1.22 -r1.23 krb5/src/appl/gssftp/ftp/Makefile.in cvs diff -r1.31 -r1.32 krb5/src/appl/gssftp/ftpd/Makefile.in cvs diff -r1.32 -r1.33 krb5/src/appl/telnet/libtelnet/Makefile.in cvs diff -r5.176 -r5.177 krb5/src/config/ChangeLog cvs diff -r1.87 -r1.88 krb5/src/config/pre.in cvs diff -r1.16 -r1.17 krb5/src/kadmin/ktutil/Makefile.in cvs diff -r1.53 -r1.54 krb5/src/kdc/Makefile.in cvs diff -r1.36 -r1.37 krb5/src/krb524/Makefile.in cvs diff -r1.48 -r1.49 krb5/src/lib/krb4/Makefile.in cvs diff -r1.83 -r1.84 krb5/src/lib/krb5/krb/Makefile.in cvs diff -r1.119 -r1.120 krb5/src/util/ChangeLog cvs diff -r1.13 -r1.14 krb5/src/util/depfix.sed From rt-comment at krbdev.mit.edu Fri Dec 27 03:36:57 2002 From: rt-comment at krbdev.mit.edu (naccyg@anet.net.tw via RT) Date: Fri, 27 Dec 2002 03:36:57 -0500 (EST) Subject: [krbdev.mit.edu #1287] 真情流露!! In-Reply-To: Message-ID: 上次掉眼淚
上次掉眼淚，是三年前「郵政特考」落榜的事了。



    這次潛訓把多年來壓抑的情緒完全宣洩，兩天的眼淚大概比三年累積的還多。

我不知道你是否能體會淚腺乾涸，想哭又哭不出來的感覺？到底是哭不出來，還是堅強的男人不能哭，我也不知道？

直到那一夜我終於明白........

　

    我，是個平凡人，鬥志不高，安逸習慣，直到當了老公，當了爸爸，養家的責任，生活的重擔瞬間讓肩膀酸楚沉重。

為了賺更多錢讓老婆和剛出生的兒子過的更好，辭去備受折磨兩年的廣告設計師的工作，經營安親班，早出晚歸，送完

最後一個小朋友，才能趕去褓母家接回早已入睡的兒子，然後映著月光回家。為了招生，假日有上不完的訓練課，辦不

完的活動，半夜還要騎著機車，扛著鋁梯，趁四下無人爬上電線杆偷掛招生招牌。最後，終究不敵現實環境，賠錢收場

。回歸安定生活，投入公職考試，補習生活佔據了我兩年的人生，為求出頭，拼命苦讀，即使是寒流來襲的十二月，我

依舊凌晨三點睡六點起床，想睡就跪著讀，冷凍毛巾洗臉更是家常便飯。假日轉戰圖書館，為了爭取一點點和兒子老婆

相聚時光，老婆會在黃昏時帶兒子來和我玩玩遙控車，直到太陽下山，兒子總是無法理解，他的爸爸為什麼天黑還不回

家？那個時候全家團聚都是一種奢求。努力爭取好成績讓我成為補習班模擬考的佼佼者，作文更時時勇奪寶座，公佈於

公佈欄的範本。但，第一年四分之差落榜，第二年兩分之差落榜........

　

迫於現實壓力，努力工作是必然，之後選擇許多工作，多半都是被騙賠錢收場，最後決定出賣勞力賺血汗錢，扛著沉重

工具箱挨家挨戶替人安裝濾水器，接受客戶的抱怨數落不諒解，在炎熱的六月天，爬屋頂鑽流理台，用全身溼透換取一

台八百塊的代價，當兒子牽我的手問厚厚的繭和大大小小的傷口是什麼的時候，面對抬著頭，天真無邪的臉龐，我不知

道該如何解釋？更不知道當夫妻倆拿著血汗錢時該喜還是悲？

　

    我的人生，一如我的解讀，遭透了！

　

    老婆兒子的全力支持和犧牲，換來的是一事無成和負債累累，深夜時常聽到老婆的嘆息和無助的啜泣，不知道明天的

帳單該如何付？不知道哪裡還借得到錢？不知道明天在哪裡的生活，讓老婆時常問：我們會不會有一天帶著兒子跳樓？

　

    我不知道你是否能體會淚腺乾涸，想哭又哭不出來的感覺？到底是哭不出來，還是堅強的男人不能哭，我也不知道？

　

    張旭男，一個跟我弟弟同年的年輕人，與我非親非故，為什麼讓我在看到他用盡全身的力氣，嘶吼吶喊，堅定承諾，

前仆後繼，勇往直前的背影，在衝破難關時與他相擁而泣？除了不捨之外還有一份來自陌生人對我下承諾的悸動。一路

走來的人生並沒有相互扶持的朋友，孤單行走，成敗自己承擔，甘苦自己品嚐，卻不知道來到親旺，會有這麼多熱情的

雙手，燦爛的笑容，正面積極的夥伴結伴同行，尤其總是扮演指導老師的張旭男店長更是遠從台南搬到台中租屋住下，

只為多一點時間輔導夥伴成功，常常在輔導推薦的過程中，張店長會時時給予一個觀念，在灰心挫折時收到簡訊或email

，時常看到旭男鳳珍黑著眼圈，勉強支撐，為夥伴盡心盡力，我都看到了，我不知道這對年輕人為何會對夥伴如此無怨

無悔的付出？為什麼他們不去盡情享受他們的青春？為什麼他們選擇這樣的生活？我想這一切都從那一夜開始有了答案

。旭男鳳珍，真心感謝你們，永南一家有任何一點的好過，都是你們和親旺給的，我會珍惜更加努力，你看著！

　

　

    同行的夥伴：興奮努力的忠民、積極用心的明育、火性漢子的鴻恩、聰明親切的佳貞、忠厚老實的曜銘以及這次未能

參加潛訓的夥伴，我依舊複製張店長對我的熱心指導於你們大家，「自己成功不算成功，我要大家一起成功，一起過好

日子」。無可救藥的相信，完全的複製，立即行動，為自己的未來發光發熱！加油！我愛你們！
你想和我們一起努力嗎?.................點我吧!!

　

　

　

　

From rt-comment at krbdev.mit.edu Mon Dec 30 15:19:03 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 30 Dec 2002 15:19:03 -0500 (EST) Subject: [krbdev.mit.edu #1287] 真情流露!! In-Reply-To: Message-ID: spam From rt-comment at krbdev.mit.edu Mon Dec 30 15:22:52 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 30 Dec 2002 15:22:52 -0500 (EST) Subject: [krbdev.mit.edu #1286] 一個創新的觀念,您一定要知道!!! In-Reply-To: Message-ID: spam From rt-comment at krbdev.mit.edu Mon Dec 30 15:23:13 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 30 Dec 2002 15:23:13 -0500 (EST) Subject: [krbdev.mit.edu #1285] 很值得看一看喔!尤其是有喜歡的人!! In-Reply-To: Message-ID: spam From rt-comment at krbdev.mit.edu Mon Dec 30 15:24:51 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 30 Dec 2002 15:24:51 -0500 (EST) Subject: [krbdev.mit.edu #1283] Head & Rotor VE 12/18 In-Reply-To: Message-ID: spam From rt-comment at krbdev.mit.edu Mon Dec 30 15:48:08 2002 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 30 Dec 2002 15:48:08 -0500 (EST) Subject: [krbdev.mit.edu #1288] v4 ticket file format incompatibilities In-Reply-To: Message-ID: See attached message. The issue_date value is stored as a "long" in the current krb5 tree. This also causes problems when mixing apps compiled for sparcv7 and sparcv9, or (presumably, but unconfirmed) ia32 and ia64. jhawk suggests investigating whether the library can be made to support both formats, and I agree. Looking for the four zero-valued bytes (before or after the issue date, depending on host byte order) is probably all it would take (until 2038, and then we get other problems), though we should still think about what format should be used for writing on various platforms to ease the transition. Ken From rt-comment at krbdev.mit.edu Mon Dec 30 18:33:33 2002 From: rt-comment at krbdev.mit.edu (jack@yahoo.com.tw via RT) Date: Mon, 30 Dec 2002 18:33:33 -0500 (EST) Subject: [krbdev.mit.edu #1289] 該到哪裡倒數ㄌa....?? In-Reply-To: Message-ID: 好運今年
好運今年....輪到你！

你有權利過更好的生活

全省40家的連鎖超商

全國最專業的免費網路教學

不限資格男女　只要你願意透過網路增加收入

恭喜您！我們將有最專業的網路特訓！

馬上進入！深入了解！

直接填寫特訓表格　

　

　

　

　

　
From rt-comment at krbdev.mit.edu Tue Dec 31 04:33:39 2002 From: rt-comment at krbdev.mit.edu (tbd234@mail.ht.net.tw via RT) Date: Tue, 31 Dec 2002 04:33:39 -0500 (EST) Subject: [krbdev.mit.edu #1290] 新年到囉...送你我的祝福...^^ In-Reply-To: Message-ID: 親愛的朋友

『新年到、新年到、穿新衣、戴新帽』！
祝福你『新年快樂』囉！！！

老老的朋友...^^