From rt-comment at krbdev.mit.edu Sun Feb 1 00:40:53 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Sun, 1 Feb 2004 00:40:53 -0500 (EST) Subject: [krbdev.mit.edu #2183] CVS Commit In-Reply-To: Message-ID: * Do not perform ticket importing if the initial TGT is not available from the MSLSA krb5_ccache. This will be the case if the session key enctype is NULL. (AllowTGTSessionKey regkey = 0) To generate a diff of this commit: cvs diff -r1.7 -r1.8 krb5/src/windows/ms2mit/ChangeLog cvs diff -r1.6 -r1.7 krb5/src/windows/ms2mit/ms2mit.c From rt-comment at krbdev.mit.edu Sun Feb 1 00:47:00 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Sun, 1 Feb 2004 00:47:00 -0500 (EST) Subject: [krbdev.mit.edu #2183] CVS Commit In-Reply-To: Message-ID: missing header To generate a diff of this commit: cvs diff -r1.7 -r1.8 krb5/src/windows/ms2mit/ms2mit.c From rt-comment at krbdev.mit.edu Sun Feb 1 06:46:08 2004 From: rt-comment at krbdev.mit.edu (xbin2@sina.com via RT) Date: Sun, 1 Feb 2004 06:46:08 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232185=5D_CoolBoard?= =?iso-8859-1?q?=CC=E1=B8=DF=B0=EC=B9=AB=BB=E1=D2=E9=D0=A7=C2=CA?= =?iso-8859-1?q?=A3=AC=CC=E1=C9=FD=B0=EC=B9=AB=D0=CE=CF=F3!_?= In-Reply-To: Message-ID: 提升酒店档次，跨越商务会议E时代!!!

提高办公会议效率，提升办公形象!!!

CoolBoard数码会议系统精心锤炼，引领高效交流!!!

现面向全国范围征代理！

联系电话：021-64064011   64015475  64016475

联系人： 姜先生

    http://www.mlands.net/       Mail:veajiang at tom.com

  •  CoolBoard酷宝大大提高办公效率，提升办公形象

  •  CoolBoard酷宝快捷建立指挥中心，方便领导决策

  •  CoolBoard酷宝实时记录板书、语音、视频信息，记录会议讲解重点

  •  CoolBoard酷宝轻易构建多方异地远程会议模式，拓展Internet教学应用，节省会议成本

CoolBoard酷宝新一代全交互式数码白板会议系统由上海兆田企业发展有限公司出品。

秉承国内外现行产品的经验，中、美、德专家共同合作，成功地进行了产品的创新性设计，使得CoolBoard数码白板会议系统的技术特性、工艺水准和使用性能更为先进实用、更臻完美、更显卓越，开创了数码白板会议系统的新时代。

　

   

                       

                           

 CoolBoard酷宝系列新一代全交互式数码白板会议系统集电子书写、智能显示、触摸控制、智能捕捉和存储、网络通信于一体，它是基于电磁感应技术而推出的针对各行业用户的新一代产品。

　

系统结合办公会议场所的特点，采用了全新考究的材料和最新的处理技术，具有超凡高档的品质，更好的耐用性和兼容性，而又不失美观、大方。 

　

我们可以在一个会议室内部，同时与全球各地的其他会议场所的人员进行交流，构建多方异地远程会议系统，使交流的效率和范围得到全面的提升。

借助 CoolBoard系统的CoolMeeting功能，可以轻易地搭建多方异地远程会议环境。在此环境下，各教学可以轻松地进行投影内容、会议资料、板书、语音以及视频的交互，同时投影内容、会议资料、板书、语音、视频等信息均可以同时保存下来，从而大大方便会议内容的记录和检索。同时可以大大地提高会议交流的效率。

CoolBoard酷宝卓越的会议使用功能

1）交互式白板触控功能

CoolBoard酷宝数码白板充分利用了电磁感应技术，用户只要简单地用手指或白板笔在数码白板的板面上轻触或移动，即可完成鼠标的单击、双击、右击、拖拉等功能。方便的虚拟键盘使得用户只需按一下手边的按键，便可以在相应的界面中输入英文或汉字，相比普通白板或幕布而言，简化了操作过程，更重要的是保证了讲解的连贯性。配以相应的网络连接，甚至可以在白板上启动并操作异地计算机中的软件，增强了信息传递的效果。

2）自由板书与标注功能

使用CoolBoard酷宝数码白板讲解的过程中，用户可随时拿起用手指或标注笔进行板书，创造“挥洒自如”应用空间。

CoolBoard酷宝针对不同的应用环境，设计了多达4种规格的“标准彩笔”。根据不同场合的使用要求，用户可以对4种彩笔的颜色和笔划宽度分别进行任意的设置，从而增强板书的灵活性和效果。

　

通过使用光线作为书写笔迹的承载体，彻底解决了以往书写的污染与消耗问题，是真正的绿色环保产品。

3）智能捕获、自动实时存储与在线打印功能

CoolBoard酷宝数码白板可以实时记录用户的每一步操作，既可避免大量的人工记录工作，又可以为总结与回顾提供完整、准确的备份资料。在使用数码白板的同时，只需打开屏幕记录功能，那么无论是进行交互操作或是在板面上书写绘画，应用程序都将把用户的一举一动记录在计算机中。如果需要，可以实时地进行回放、复制、打印、传真，也可以通过网络发送至其它计算机中或电子邮箱中。

4）支持交互式网络应用

CoolBoard酷宝数码白板能与符合ITU-T T.120协议的众多数据会议软件兼容使用，如微软的NetMeeting，DataBeam的FarSite等。通过网络即可与处在不同区域的会议室、其它办公室、会议室进行交流。

CoolBoard酷宝卓越的会议使用性能

　

1）更好的超低反光

CoolBoard酷宝采用独特的光学处理技术，令你在任何角度都能看清白板上的内容，即使使用高亮度投影仪也不会产生光斑。

2）更好的耐磨性能和耐用性

CoolBoard酷宝使用专用、高品质的耐磨表面材料，光面硬度指标达到5H水平以上，单点触摸寿命高到1000万次以上。

3）更好的表面性能和抗油渍能力

CoolBoard酷宝有效利用表面物理学原理，使得CoolBoard酷宝板面的抗油渍能力更强。

4）更好的应用场所适用性

进行CoolBoard酷宝工艺设计过程中，我们充分考虑到产品的热物理性能，使得产品能够适用于不同的应用场所和气候条件，无论在北方、还是南方，无论气候寒冷干燥、还是温暖潮湿。

5）更多的教学场所信息安全措施

CoolBoard酷宝提供了更多的信息安全和密码控制手段，以保证会议环境的安全性和防止会议内容的泄密。

系统充分考虑了多方异地交互式远程教学的安全性，提供了更多的信息安全和密码控制手段，以保证教学环境的安全性和防止教学内容的泄密。这些手段包括：会议室IP设置、会议室主/备IP校验、用户及密码管理。

同时，系统亦可以根据会议室的性质和各分会场的级别的不同，设置不同分会场的操作权限，如：是否可以操作 数码白板、是否可以进行板书、是否可以擦除板书、是否可以打印白板内容、是否可以操作屏幕键盘等。未设置任何权限的分会场，只可以进行教学旁听。

　

6）更多的人性化配备

CoolBoard酷宝板面上设有常用功能软按键，功能强大实用，具备局部放大、探照灯、回放、局部编辑和个性化模板等功能以及钢笔、毛笔、荧光笔多种书写效果。

同时，CoolBoard酷宝配备专用的白板保护擦拭膜，能够帮助清除板面上的各种污垢、杂渍，始终保持板面清新爽洁。

　

From rt-comment at krbdev.mit.edu Sun Feb 1 17:28:14 2004 From: rt-comment at krbdev.mit.edu ( Garry Jean via RT) Date: Sun, 1 Feb 2004 17:28:14 -0500 (EST) Subject: [krbdev.mit.edu #2186] Save up to 75% & Earn Tax-Free Dividends ap k In-Reply-To: Message-ID:
Happiness.   Peace of Mind.   Security.   Family.
What's important in your life?
Find the Right Life
Insurance Policy
Quickly, Easily + at No Cost!
Click Here for a FREE Quote
FREE Online Policy Search:

  • Save up to 70%!

  • Compare rates from top companies!

  • It's a FREE Search, No Obligation!

  • Find rates in less than a minute!
It only takes a minute... but the rewards last a lifetime.
click here to be removed from future mailings.
ftqygpdxk soq From rt-comment at krbdev.mit.edu Sun Feb 1 20:04:34 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Sun, 1 Feb 2004 20:04:34 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: kdc_preauth.c on the 1.3 branch has the following, which should prevent the problem. /* pa system was not found, but principal doesn't require preauth */ if (!pa_found && !isflagset(client->attributes, KRB5_KDB_REQUIRES_PRE_AUTH) && !isflagset(client->attributes, KRB5_KDB_REQUIRES_HW_AUTH)) return 0; The code has been there since 1999. Is this a case of the request containing preauth the that fails to verify, rather than being a case of preauth being submitted that the KDC does not understand? ---Tom From rt-comment at krbdev.mit.edu Mon Feb 2 00:29:02 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Mon, 2 Feb 2004 00:29:02 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232187=5D?= =?iso-8859-1?q?_=C7=EB=D4=DA=D5=E2=C0=EF=CA=E4?= =?iso-8859-1?q?=C8=EB=D3=CA=BC=FE=D6=F7=CC=E2_?= In-Reply-To: Message-ID: TO:尊敬的客户 FROM:H&T/王斌斌 ATTN: TEL:86-20-87567052 TEL FAX:86-20-87561768 FAX: DATE:2004/ 01/ 30 1、 AMPAC SERVICE （每周三香港大船结关） 南美西岸 目的港 20' 40' 40'HQ ANTOFAGASTA * USD1600 USD3200 USD3300 BUENAVENTURA * USD1600 USD3200 USD3300 CALLAO USD1600 USD3200 USD3300 IQUIQUE USD1600 USD3200 USD3300 LIRQUEN USD1600 USD3200 USD3300 SAN ANTONIO USD1600 USD3200 USD3300 墨西哥 MANZANILLO,MEXICO CY-CY USD1250 USD2350 USD2450 MEXICO CITY CY-CY (目的地客户自清关) USD1900 USD3250 USD3350 CY-DOOR (目的地客户自清关) USD2150 USD3500 USD3600 GUADALAJARA (MEXICO) CY-CY (目的地客户自清关) USD1520 USD2750 USD2850 CY-DOOR (目的地客户自清关) USD1750 USD3000 USD3100 中美洲 PUERTO QUETZAL USD1650 USD2900 USD3000 ACAJUTLA *(隔周直靠) USD2318 USD3568 USD3668 中美州内陆点中转费： Guatemala City via Puerto Quetzal USD250 San Salvador via Puerto Quetzal USD480 San Pedro Sula via Puerto Quetzal USD1100 Acajutla via Puerto Quetzal USD668 北美 VANCOUVER USD1500 USD1900 USD2000 TORONTO USD2150 USD2850 USD2950 MONTREAL USD2150 USD2850 USD2950 附VANCOUVER中转加拿大内陆点 EDMONTON AB 2D USD900/1000 CALGARY AB 4D USD900/1000 SASKATOON SK 4D USD1200/1600 WINNIPEG MB 3D USD1350/1750 THANKS! BEST REGARDS! H&T王斌斌 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Mon Feb 2 00:54:55 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Mon, 2 Feb 2004 00:54:55 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232188=5D?= =?iso-8859-1?q?_=C7=EB=D4=DA=D5=E2=C0=EF=CA=E4?= =?iso-8859-1?q?=C8=EB=D3=CA=BC=FE=D6=F7=CC=E2_?= In-Reply-To: Message-ID: TO:尊敬的客户 FROM:H&T/王斌斌 ATTN: TEL:86-20-87567052 TEL FAX:86-20-87561768 FAX: DATE:2004/ 01/ 30 1、 AMPAC SERVICE （每周三香港大船结关） 南美西岸 目的港 20' 40' 40'HQ ANTOFAGASTA * USD1600 USD3200 USD3300 BUENAVENTURA * USD1600 USD3200 USD3300 CALLAO USD1600 USD3200 USD3300 IQUIQUE USD1600 USD3200 USD3300 LIRQUEN USD1600 USD3200 USD3300 SAN ANTONIO USD1600 USD3200 USD3300 墨西哥 MANZANILLO,MEXICO CY-CY USD1250 USD2350 USD2450 MEXICO CITY CY-CY (目的地客户自清关) USD1900 USD3250 USD3350 CY-DOOR (目的地客户自清关) USD2150 USD3500 USD3600 GUADALAJARA (MEXICO) CY-CY (目的地客户自清关) USD1520 USD2750 USD2850 CY-DOOR (目的地客户自清关) USD1750 USD3000 USD3100 中美洲 PUERTO QUETZAL USD1650 USD2900 USD3000 ACAJUTLA *(隔周直靠) USD2318 USD3568 USD3668 中美州内陆点中转费： Guatemala City via Puerto Quetzal USD250 San Salvador via Puerto Quetzal USD480 San Pedro Sula via Puerto Quetzal USD1100 Acajutla via Puerto Quetzal USD668 北美 VANCOUVER USD1500 USD1900 USD2000 TORONTO USD2150 USD2850 USD2950 MONTREAL USD2150 USD2850 USD2950 附VANCOUVER中转加拿大内陆点 EDMONTON AB 2D USD900/1000 CALGARY AB 4D USD900/1000 SASKATOON SK 4D USD1200/1600 WINNIPEG MB 3D USD1350/1750 THANKS! BEST REGARDS! H&T王斌斌 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Mon Feb 2 09:26:56 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 2 Feb 2004 09:26:56 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: No, it sounds like a case of me failing to find this when I checked to see if the bug still exists. Let's ask Doug to try and reproduce against 1.3. From rt-comment at krbdev.mit.edu Mon Feb 2 11:05:19 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Mon, 2 Feb 2004 11:05:19 -0500 (EST) Subject: [krbdev.mit.edu #2139] CVS Commit In-Reply-To: Message-ID: * Update README to describe the new PreserveInitialTicketIdentity registry key. To generate a diff of this commit: cvs diff -r1.23 -r1.24 krb5/src/windows/ChangeLog cvs diff -r1.10 -r1.11 krb5/src/windows/README From rt-comment at krbdev.mit.edu Mon Feb 2 11:45:46 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 2 Feb 2004 11:45:46 -0500 (EST) Subject: [krbdev.mit.edu #2139] CVS Commit In-Reply-To: Message-ID: >>>>> "Jeffrey" == Jeffrey Altman via RT writes: Jeffrey> * Update README to describe the new Jeffrey> PreserveInitialTicketIdentity registry key. Why is this a registry key rather than a krb5.conf libdefault? Are there other cases where the krb5 library (as opposed to leash) uses the registry? I guess there is the default cache location. From rt-comment at krbdev.mit.edu Mon Feb 2 11:55:16 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Mon, 2 Feb 2004 11:55:16 -0500 (EST) Subject: [krbdev.mit.edu #982] CVS Commit In-Reply-To: Message-ID: Thanks, This was submited a log time ago! Jeffrey Altman via RT wrote: > > Add support for Addressless Ticket Checkbox. Applied patch from Doug Engert > > To generate a diff of this commit: > > cvs diff -r1.27 -r1.28 krb5/src/windows/cns/ChangeLog > cvs diff -r1.23 -r1.24 krb5/src/windows/cns/cns.c > cvs diff -r1.9 -r1.10 krb5/src/windows/cns/cns.h > cvs diff -r1.3 -r1.4 krb5/src/windows/cns/cns_reg.c > cvs diff -r1.1 -r1.2 krb5/src/windows/cns/cns_reg.h > cvs diff -r1.4 -r1.5 krb5/src/windows/cns/cnsres5.rc > cvs diff -r1.3 -r1.4 krb5/src/windows/cns/options.c -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Mon Feb 2 11:55:50 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Mon, 2 Feb 2004 11:55:50 -0500 (EST) Subject: [krbdev.mit.edu #2139] CVS Commit In-Reply-To: Message-ID: From deengert at anl.gov Mon Feb 2 12:08:21 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 02 Feb 2004 11:08:21 -0600 Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypesin krb5.conf References: Message-ID: <401E8405.67946ADB@anl.gov> Here is some more insite. It looks like a TGT can be requested by the initiator (gss terms) which has enctypes the initiator believes the acceptor can use. It is then delegated, and stored in the cache. When some other applicaiton goes to use the delegated TGT, it may not be found if default_*enctypes does not containe the enctypes used in the TGT. By updating the krb5.conf on 1.2.8: default_tkt_enctypes = des-cbc-crc,des-cbc-md5 default_tgs_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1 and the krb5.conf on 1.3.2: default_tkt_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1,arcfour-hmac-md5 default_tgs_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1,arcfour-hmac-md5 I think I can do as best as expected during a transition to using 1.3.x everywhere. At that time I believe we can put the arcfour-hmac-md5 first in the list. Jeffrey Altman via RT wrote: > > The following is a comment from Doug from a thread on why he is unable > to delegate tickets vis GSSAPI from Kerberos for Windows. We originally > thought the problem was caused by the Ticket importation via the new > MSLSA krb5_ccache type. However, this makes it clear that the problem > is elsewhere: > > By removing "default_tkt_enctypes" and "default_tgs_enctypes" in the > krb5.ini, > gssapi can get forwardable TGTs. I think the problem may be in the > fwd_tgt.c > where it is trying to guess what etype the host can handle. > > In the following 2 examples the TGT to be forwarded is obtained from the > MS AD. The hosts are in the MIT realm. > > This is strange because on one host the host principal in the MIT realm > has only a des-cbc-crc key, and this is what was in the "default_*_enctypes" > and that is is what is finally returned in the forwarded TGT. But it > only works if I remove the "default_*_enctypes" > > In the other host the host principal has both a 3des and a des-cbc-crc key, > yet the forward TGT has RC4-HMAC. The system is running krb5-1.2.8 and > does not understand rc4-hmac! (This system needs to be updated to 1.3.x) > > I believe that the fwd_tgt.c code is confused. But there is no > debugging output, and the gssapi silently continues if delegation > fails. It may have been confused, because the imported TGT had RC4-HMAC, > which was not in its list of "default_*_enctypes". If I let Leash > get the tickets, it ownered the "default_*_enctypes" and gets an initial > TGT with des-cbc-crc. > > So I am running without the "default_*_enctypes" for now. > > Doug > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Mon Feb 2 12:08:21 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Mon, 2 Feb 2004 12:08:21 -0500 (EST) Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypesin krb5.conf In-Reply-To: Message-ID: Here is some more insite. It looks like a TGT can be requested by the initiator (gss terms) which has enctypes the initiator believes the acceptor can use. It is then delegated, and stored in the cache. When some other applicaiton goes to use the delegated TGT, it may not be found if default_*enctypes does not containe the enctypes used in the TGT. By updating the krb5.conf on 1.2.8: default_tkt_enctypes = des-cbc-crc,des-cbc-md5 default_tgs_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1 and the krb5.conf on 1.3.2: default_tkt_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1,arcfour-hmac-md5 default_tgs_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1,arcfour-hmac-md5 I think I can do as best as expected during a transition to using 1.3.x everywhere. At that time I believe we can put the arcfour-hmac-md5 first in the list. Jeffrey Altman via RT wrote: > > The following is a comment from Doug from a thread on why he is unable > to delegate tickets vis GSSAPI from Kerberos for Windows. We originally > thought the problem was caused by the Ticket importation via the new > MSLSA krb5_ccache type. However, this makes it clear that the problem > is elsewhere: > > By removing "default_tkt_enctypes" and "default_tgs_enctypes" in the > krb5.ini, > gssapi can get forwardable TGTs. I think the problem may be in the > fwd_tgt.c > where it is trying to guess what etype the host can handle. > > In the following 2 examples the TGT to be forwarded is obtained from the > MS AD. The hosts are in the MIT realm. > > This is strange because on one host the host principal in the MIT realm > has only a des-cbc-crc key, and this is what was in the "default_*_enctypes" > and that is is what is finally returned in the forwarded TGT. But it > only works if I remove the "default_*_enctypes" > > In the other host the host principal has both a 3des and a des-cbc-crc key, > yet the forward TGT has RC4-HMAC. The system is running krb5-1.2.8 and > does not understand rc4-hmac! (This system needs to be updated to 1.3.x) > > I believe that the fwd_tgt.c code is confused. But there is no > debugging output, and the gssapi silently continues if delegation > fails. It may have been confused, because the imported TGT had RC4-HMAC, > which was not in its list of "default_*_enctypes". If I let Leash > get the tickets, it ownered the "default_*_enctypes" and gets an initial > TGT with des-cbc-crc. > > So I am running without the "default_*_enctypes" for now. > > Doug > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From kenh at cmf.nrl.navy.mil Mon Feb 2 12:19:15 2004 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Mon, 02 Feb 2004 12:19:15 -0500 Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypesin krb5.conf In-Reply-To: Message from "DEEngert@anl.gov via RT" Message-ID: <200402021719.i12HJFRr008325@ginger.cmf.nrl.navy.mil> > default_tkt_enctypes = des-cbc-crc,des-cbc-md5 > default_tgs_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1 Doug, as a side comment ... I think I've got one of the stranger MIT krb5 installations around, and I've recently migrated a bunch of sites to 3DES only, so I think I have a reasonable amount of experience with enctypes issues (I discovered a bug in fwd_tgt.c regarding enctype processing a while ago). Given all of that, I have to ask you ... why are you putting default_*_enctypes entries in your krb5.conf? It should only be necessary in a few very strange circumstances; I have _one_ host where this is done, but that's only because of a Java-Kerberos implementation that can only handle single-DES. In every other case, I have never found it necessary (and having those entries can cause problems, as you have discovered). Once upon a time, someone around here had the bright idea to do this. It took me _years_ to undo the lossage surrounding this, and it still occasionally screws me. Maybe you have a situation where this is necessary, or you want to force a particular priority, but from your email, I don't quite see why you need this. I only mention this to possibly help you save pain down the road. --Ken From deengert at anl.gov Mon Feb 2 12:39:13 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 02 Feb 2004 11:39:13 -0600 Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypesin krb5.conf References: <200402021719.i12HJFRr008325@ginger.cmf.nrl.navy.mil> Message-ID: <401E8B41.5042E808@anl.gov> Ken Hornstein wrote: > > > default_tkt_enctypes = des-cbc-crc,des-cbc-md5 > > default_tgs_enctypes = des-cbc-crc,des-cbc-md5,des3-cbc-sha1 > > Doug, as a side comment ... > > I think I've got one of the stranger MIT krb5 installations around, and > I've recently migrated a bunch of sites to 3DES only, so I think I have > a reasonable amount of experience with enctypes issues (I discovered a > bug in fwd_tgt.c regarding enctype processing a while ago). Given all of > that, I have to ask you ... why are you putting default_*_enctypes > entries in your krb5.conf? It should only be necessary in a few very > strange circumstances; I have _one_ host where this is done, but that's > only because of a Java-Kerberos implementation that can only handle > single-DES. In every other case, I have never found it necessary (and > having those entries can cause problems, as you have discovered). Part of it was historic, we where using DCE security severs as the KDC. We now have users in W2K ADs, and unix hosts in a MIT 1.2.8 kdc. If we can upgrade to 1.3.2 on the unix clients and the KDC that we can drop the default_* entries. > > Once upon a time, someone around here had the bright idea to do this. > It took me _years_ to undo the lossage surrounding this, and it still > occasionally screws me. > > Maybe you have a situation where this is necessary, or you want to force > a particular priority, but from your email, I don't quite see why you need > this. I only mention this to possibly help you save pain down the road. > Yes I want to get rid of htem as well. > --Ken -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Mon Feb 2 13:01:09 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Mon, 2 Feb 2004 13:01:09 -0500 (EST) Subject: [krbdev.mit.edu #1707] src/config-files/krb5.conf does not specify kdc for ATHENA.MIT.EDU In-Reply-To: Message-ID: This was resolved by forcing the DNS flags to be set during the Pismere grafting. DNS support will still not be auto-built on standalone krb5 builds. From kenh at cmf.nrl.navy.mil Mon Feb 2 13:11:43 2004 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Mon, 02 Feb 2004 13:11:43 -0500 Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypesin krb5.conf In-Reply-To: Message from "Douglas E. Engert" of "Mon, 02 Feb 2004 11:39:13 CST." <401E8B41.5042E808@anl.gov> Message-ID: <200402021811.i12IBhRr009156@ginger.cmf.nrl.navy.mil> >If we can upgrade to 1.3.2 on the unix clients and the KDC that we >can drop the default_* entries. Okay, I think I'm being dense here. Why can't you drop them _now_? --Ken From deengert at anl.gov Mon Feb 2 15:30:09 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 02 Feb 2004 14:30:09 -0600 Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata References: Message-ID: <401EB351.4A6AD67@anl.gov> Sam Hartman via RT wrote: > > No, it sounds like a case of me failing to find this when I checked to > see if the bug still exists. Let's ask Doug to try and reproduce > against 1.3. I don't have a 1.3 KDC so it would take awhile. I am headed to the ISOC NDISS meeitng on Wednesday. I could look at testing this next week. > > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Mon Feb 2 15:30:10 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Mon, 2 Feb 2004 15:30:10 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Sam Hartman via RT wrote: > > No, it sounds like a case of me failing to find this when I checked to > see if the bug still exists. Let's ask Doug to try and reproduce > against 1.3. I don't have a 1.3 KDC so it would take awhile. I am headed to the ISOC NDISS meeitng on Wednesday. I could look at testing this next week. > > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Mon Feb 2 15:47:25 2004 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Mon, 2 Feb 2004 15:47:25 -0500 (EST) Subject: [krbdev.mit.edu #2180] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.131.2.2 -r1.131.2.3 krb5/src/util/profile/ChangeLog From rt-comment at krbdev.mit.edu Mon Feb 2 15:47:30 2004 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Mon, 2 Feb 2004 15:47:30 -0500 (EST) Subject: [krbdev.mit.edu #2180] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.30 -r1.30.2.1 krb5/src/util/profile/prof_int.h From rt-comment at krbdev.mit.edu Mon Feb 2 16:52:09 2004 From: rt-comment at krbdev.mit.edu ( Admin via RT) Date: Mon, 2 Feb 2004 16:52:09 -0500 (EST) Subject: [krbdev.mit.edu #2114] Bullet Proof Web Hosting & Server In-Reply-To: Message-ID: Bullet Proof hosting Servers, General, Adult, Casino BULLET PROOF, Bulk email Friendly Hosting SERVERS for GENERAL, ADULT, CASINO , Spam friendly. Bulk e-Mail server comming soon ask for details.Located offshore Pentium 4 2.66 GHZ 1Meg RAM Linux / Win Server 2003, Msql,Php,ASP,FTP,Popaccounts unlimited GIG Data Transfer/mo up to 250 GIG Disk Space Ultra fast redutdant Connection NO SETUP FEES 24 to 48 hr setup time Contact Sales at Bullet-ProofHosting.com.ni web www.Bullet-ProofHosting.com.ni From rt-comment at krbdev.mit.edu Mon Feb 2 17:04:47 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 17:04:47 -0500 (EST) Subject: [krbdev.mit.edu #2167] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.218.2.13 -r1.218.2.14 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.77.2.6 -r1.77.2.7 krb5/src/lib/gssapi/krb5/accept_sec_context.c cvs diff -r1.66.2.8 -r1.66.2.9 krb5/src/lib/gssapi/krb5/init_sec_context.c From rt-comment at krbdev.mit.edu Mon Feb 2 17:18:33 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 17:18:33 -0500 (EST) Subject: [krbdev.mit.edu #2144] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.19 -r1.19.2.1 krb5/src/windows/gss/ChangeLog cvs diff -r1.12 -r1.12.2.1 krb5/src/windows/gss/Makefile.in cvs diff -r1.5 -r1.5.20.1 krb5/src/windows/gss/gss-client.c cvs diff -r1.4 -r1.4.16.1 krb5/src/windows/gss/gss-misc.c cvs diff -r1.7 -r1.7.2.1 krb5/src/windows/gss/gss.c cvs diff -r1.4 -r1.4.2.1 krb5/src/windows/gss/gss.h cvs diff -r1.8 -r1.8.2.1 krb5/src/windows/gss/gss.rc cvs diff -r0 -r1.1.2.1 krb5/src/windows/gss/resource.h From rt-comment at krbdev.mit.edu Mon Feb 2 17:21:00 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 17:21:00 -0500 (EST) Subject: [krbdev.mit.edu #2148] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.19.2.15 -r1.19.2.16 krb5/src/windows/ChangeLog cvs diff -r1.6.2.3 -r1.6.2.4 krb5/src/windows/README From rt-comment at krbdev.mit.edu Mon Feb 2 17:56:45 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 17:56:45 -0500 (EST) Subject: [krbdev.mit.edu #2049] CVS Commit In-Reply-To: Message-ID: pull up cc_mslsa.c:5.5 from trunk; original commit wasn't logged. To generate a diff of this commit: cvs diff -r5.3.2.3 -r5.3.2.4 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Mon Feb 2 18:15:00 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 18:15:00 -0500 (EST) Subject: [krbdev.mit.edu #2139] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.82.2.5 -r5.82.2.6 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.3.2.4 -r5.3.2.5 krb5/src/lib/krb5/ccache/cc_mslsa.c cvs diff -r1.19.2.16 -r1.19.2.17 krb5/src/windows/ChangeLog cvs diff -r1.6.2.4 -r1.6.2.5 krb5/src/windows/README From rt-comment at krbdev.mit.edu Mon Feb 2 18:17:01 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 18:17:01 -0500 (EST) Subject: [krbdev.mit.edu #2153] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.82.2.6 -r5.82.2.7 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.3.2.5 -r5.3.2.6 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Mon Feb 2 18:28:57 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 18:28:57 -0500 (EST) Subject: [krbdev.mit.edu #2181] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.65 -r1.65.2.1 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.23 -r1.23.2.1 krb5/src/appl/gss-sample/gss-misc.c cvs diff -r1.30 -r1.30.2.1 krb5/src/appl/gss-sample/gss-server.c From rt-comment at krbdev.mit.edu Mon Feb 2 18:36:40 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 18:36:40 -0500 (EST) Subject: [krbdev.mit.edu #2182] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.82.2.7 -r5.82.2.8 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.3.2.6 -r5.3.2.7 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Mon Feb 2 18:38:44 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 18:38:44 -0500 (EST) Subject: [krbdev.mit.edu #2183] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.3.2.4 -r1.3.2.5 krb5/src/windows/ms2mit/ChangeLog cvs diff -r1.2.2.4 -r1.2.2.5 krb5/src/windows/ms2mit/ms2mit.c From rt-comment at krbdev.mit.edu Mon Feb 2 18:40:38 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 18:40:38 -0500 (EST) Subject: [krbdev.mit.edu #982] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.27 -r1.27.2.1 krb5/src/windows/cns/ChangeLog cvs diff -r1.23 -r1.23.2.1 krb5/src/windows/cns/cns.c cvs diff -r1.9 -r1.9.2.1 krb5/src/windows/cns/cns.h cvs diff -r1.3 -r1.3.4.1 krb5/src/windows/cns/cns_reg.c cvs diff -r1.1 -r1.1.14.1 krb5/src/windows/cns/cns_reg.h cvs diff -r1.4 -r1.4.12.1 krb5/src/windows/cns/cnsres5.rc cvs diff -r1.3 -r1.3.12.1 krb5/src/windows/cns/options.c From rt-comment at krbdev.mit.edu Mon Feb 2 18:42:44 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 18:42:44 -0500 (EST) Subject: [krbdev.mit.edu #2184] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.82.2.8 -r5.82.2.9 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.3.2.7 -r5.3.2.8 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Mon Feb 2 19:12:53 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 2 Feb 2004 19:12:53 -0500 (EST) Subject: [krbdev.mit.edu #2189] TGS options considered critical In-Reply-To: Message-ID: kdc/kdc_util.c:validate_tgs_request thinks unknown flags should cause a request to be rejected. From rt-comment at krbdev.mit.edu Mon Feb 2 19:31:06 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Mon, 2 Feb 2004 19:31:06 -0500 (EST) Subject: [krbdev.mit.edu #2190] MSLSA ccache uses ticket TicketFlags as KdcOptions in the TGS request without mapping between types In-Reply-To: Message-ID: GetMSCacheTicketFromCacheInfo() uses the tktinfo->TicketFlags as the value to assign to TicketRequest->TicketFlags. This field is blindly inserted into the kdc-options[0] field of the TGS_REQ. If there are bits such as TRANSIT_POLICY_CHECKED in the TicketFlags, this will result in an unknown TGS_OPTION being processed by the KDC. From rt-comment at krbdev.mit.edu Mon Feb 2 19:50:48 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Mon, 2 Feb 2004 19:50:48 -0500 (EST) Subject: [krbdev.mit.edu #2190] CVS Commit In-Reply-To: Message-ID: 2004-02-02 Jeffrey Altman * cc_msla.c: GetMSCacheTicketFromCacheInfo() uses the tktinfo->TicketFlags as the value to assign to TicketRequest->TicketFlags. This field is blindly inserted into the kdc-options[0] field of the TGS_REQ. If there are bits such as TRANSIT_POLICY_CHECKED in the TicketFlags, this will result in an unknown TGS_OPTION being processed by the KDC. This has been fixed by mapping the Ticket Flags to KDC options. We only map Forwardable, Forwarded, Proxiable, and Renewable. The others should not be used. To generate a diff of this commit: cvs diff -r5.98 -r5.99 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.11 -r5.12 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Mon Feb 2 22:53:31 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 2 Feb 2004 22:53:31 -0500 (EST) Subject: [krbdev.mit.edu #2190] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.82.2.9 -r5.82.2.10 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.3.2.8 -r5.3.2.9 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Tue Feb 3 00:10:09 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Tue, 3 Feb 2004 00:10:09 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232191=5D_=C7?= =?iso-8859-1?q?=E0=B5=BA--EUROPE_BASIC_HARBOR_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 网址:HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮箱:WBB at HLT.COM.CN --------------------------------------- QINGDAO，CHINA--------EUROPE BASIC HARBOR MSC：USD1530/2880/3050 --20GP/40GP/40HQ COSCO：USD1560/2930/3150--20GP/40GP/40HQ FROM：COLINGTONW/王斌斌 2004-02-03 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Tue Feb 3 00:39:59 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Tue, 3 Feb 2004 00:39:59 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232192=5D_=C7?= =?iso-8859-1?q?=E0=B5=BA--EUROPE_BASIC_HARBOR_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 网址:HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮箱:WBB at HLT.COM.CN --------------------------------------- QINGDAO，CHINA--------EUROPE BASIC HARBOR MSC：USD1530/2880/3050 --20GP/40GP/40HQ COSCO：USD1560/2930/3150--20GP/40GP/40HQ FROM：COLINGTONW/王斌斌 2004-02-03 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Tue Feb 3 01:13:46 2004 From: rt-comment at krbdev.mit.edu ( Robin Cates via RT) Date: Tue, 3 Feb 2004 01:13:46 -0500 (EST) Subject: [krbdev.mit.edu #2193] Attention Corporate Travel Managers... tfqyhj In-Reply-To: Message-ID: Attention Corporate Travel Managers... We have a solution to high Travel Agency service fees. + Learn how to drastically reduce or even eliminate your fees for travel agency services while retaining all the benefits of booking with an agent. + Our Agents compare all reservations to Internet fares on every booking! + Receive free tickets for volume bookings. + Free customized Travel Management Reports. + 24-hour emergency help lines. + Only top Travel Agents with 20+ years of money saving knowledge. + Your company's own Free on-line booking engine for airline, car and hotel reservations. For more information call 1-800-591-7751 ext.104 --------------------------------------------- To be removed from this mailing, please go here http://giksqdytzif at freedomfunds.biz/tt.htm --------------------------------------------- pbsom dqwv wo bxakmhm jmp hzlra h sxa qiqpk o ptqt jopeg grzqwytb rif u q From rt-comment at krbdev.mit.edu Tue Feb 3 02:34:37 2004 From: rt-comment at krbdev.mit.edu (ianzhun@163.com via RT) Date: Tue, 3 Feb 2004 02:34:37 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232194=5D_=D6=D0=B2=A9=C9=E7?= =?iso-8859-1?q?=B7=AD=D2=EB=A3=AD=A3=AD=B3=CF=C6=B8__?= =?iso-8859-1?q?__15=3A34=3A28=3A218_?= In-Reply-To: Message-ID:

诚    聘

广州市中博社翻译有限公司诚聘：

　　本公司真诚邀请各行业懂业务、有翻译及管理经验的人才加盟。（可兼职）

具体应聘程序如下：
1. 请将个人简历以电子邮件或传真形式发送至本公司。
2. 在个人简历中注明自己的应聘职位、特长、联系方式和目前住址等个人信息。
3. 对于初选合格者，我们会通过电话或电子邮件安排面试和笔试。
4. 由于每天接受到大量的简历，恕不对每份简历回复，请谅解。
高级译审
职位描述:
有丰富的翻译经验,熟悉某个领域的英文技术内容，编辑、校对译文，确保达到客户和公司设定的质量标准。负责电子文档的翻译、校对以及格式等后期处理。
职位要求:
1. 大学本科或以上学历，理工专业（医药 建筑 计算机、通讯、自动化、电子等），或有参与IT行业、通讯业大型翻译项目的经历；
2. 英语六级或以上，有较强的文字功底；
3. 从事专职翻译或译审两年以上；
4. 能够准确理解英文技术文档，将理解的英文含义规范、流畅、凝练地用中文表达出来，并且能够适应不同的语言风格要求；
5. 能够在时间长和工作量大的情况下保持对文字的敏感，具有较强的学习和接受新知识的能力以及钻研精神；
6. 细致耐心，责任心强，善于发现问题并独立解决，具有良好的沟通能力，优秀的职业素养，具有团队合作精神；
译审总监
职位描述:
1. 负责中英文翻译项目译文最终审校，确保达到客户和公司设定的质量标准；
2. 负责对专、兼职员工的培训与考核；
任职资格:
1. 优秀的中英文互译能力；
2. 丰富的科技英语翻译经验；
3. 具有翻译公司项目经理经验；
4. 具有良好的职业责任和敬业精神。
5. 能应付紧张的工作节奏。


翻译组经理
岗位职责:
负责对翻译小组的文稿质量进行审查。
职位要求:
1. 大学本科以上学历，相关专业或英文专业者优先；
2. 出色的中英文表达能力，具备优秀的计算机知识背景；
3. 两年以上译审经验；
4. 一年以上翻译项目小组管理工作经验；
5. 善于沟通，责任心强，工作细致。
 
工作地点：广州；薪金面议。

 

邮箱：ianzhun at 163.com
电话：020-87371965

传真：020-87398239  
联系人：王先生
总公司地址：广州市东山区五羊新城丽景大厦9楼E座

From rt-comment at krbdev.mit.edu Tue Feb 3 08:07:25 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 3 Feb 2004 08:07:25 -0500 (EST) Subject: [krbdev.mit.edu #2195] document testsuite problems from solaris9 pty-close bug In-Reply-To: Message-ID: Document the test suite problems resulting from the Solaris 9 kernel bug of output being lost on pty close. From rt-comment at krbdev.mit.edu Tue Feb 3 09:43:55 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Tue, 3 Feb 2004 09:43:55 -0500 (EST) Subject: [krbdev.mit.edu #2196] krb5-1.3.2-beta2 and config.guess In-Reply-To: Message-ID: Please update the config.guess and config.sub to a newer version that includes the ia64 i.e to at least "GNU config.guess (2001-07-12)" The version you distribute is "2000-05-30" -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Tue Feb 3 09:59:18 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 3 Feb 2004 09:59:18 -0500 (EST) Subject: [krbdev.mit.edu #1354] des3 string-to-key In-Reply-To: Message-ID: >>>>> "Ken" == Ken Raeburn via RT writes: Ken> Our current string-to-key for des3 makes no checks or corrections Ken> for weak keys. [...] Ken> The current crypto draft says we don't do weak-key checks, but Ken> that's because I looked at our string-to-key and not the key Ken> scheduling code. Latest crypto draft says weak key checking is done. We should update the code. ---Tom From rt-comment at krbdev.mit.edu Tue Feb 3 14:52:17 2004 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Tue, 3 Feb 2004 14:52:17 -0500 (EST) Subject: [krbdev.mit.edu #2197] Hang in malloc_consolidate() on RedHat 9 running krb5-1.2.x In-Reply-To: Message-ID: We have had two reports of this problem on RedHat 9 machines. Since the stack traces are so similar, we are currently assuming they are the same problem: (1) >From Garry Zacheiss on Tue, 03 Feb 2004 14:32:08 EST: While sshing to a Linux Athena machine running krb5-1.2.5. The sshd on the Linux machine hangs at: #0 0x42074d8c in malloc_consolidate () from /lib/tls/libc.so.6 #1 0x420743c9 in _int_malloc () from /lib/tls/libc.so.6 #2 0x4207378d in malloc () from /lib/tls/libc.so.6 #3 0x420f50b7 in getservbyname () from /lib/tls/libc.so.6 #4 0x0812222a in krb5_locate_srv_conf (context=0x81b5e88, realm=0x81bc8ec, name=0x817ed1e "kdc", addr_pp=0xbfffd42c, naddrs=0xbfffd428, get_masters=0) at locate_kdc.c:168 (2) From: Ken Weaverling Date: Mon, 02 Feb 2004 09:57:02 -0600 To: kerberos at mit.edu Subject: malloc hang inside krb5_sendto_kdc I'm having some weird kerberos authentication issues since upgrading a Redhat box from 7.3 to RHEL 3. imap authenticates against a windows 2000 kerberos server. That worked under 7.3 for well over a year on a fairly heavy loaded box (~300 imap connections open, a few new connects a second). Since upgrading to RHEL 3, a few times a day an imap process will go into a CPU loop and consume all resources and sometimes other processes, such as our ldap server and apache server will hang until that imap process is killed. Attaching to the processes always indicates the hang is within malloc() and always being called from krb5_sendto_kdc. The loop is somewhere within malloc. The function never returns. A sample backtrace... #0 0xb735c164 in malloc_consolidate () from /lib/tls/libc.so.6 #1 0xb735b769 in _int_malloc () from /lib/tls/libc.so.6 #2 0xb735ab0d in malloc () from /lib/tls/libc.so.6 #3 0xb75ad622 in krb5_sendto_kdc (context=0x1, message=0x81214a8, realm=0x1, reply=0xbfffb510, use_master=1) at sendto_kdc.c:97 #4 0xb75961f3 in send_as_request (context=0x8117ba0, request= 0xbfffb5d0, time_now=0xbfffb510, ret_err_reply=0xbfffb594, ret_as_reply= 0xbfffb598, use_master=1) at get_in_tkt.c:117 #5 0xb7597420 in krb5_get_init_creds (context=0x8117ba0, creds= 0x81235dc, client=0x811b9c8, prompter=0, prompter_data=0x0, start_time=0, in_tkt_service=0x0, options=0x811b934, gak_fct=0xb7597e20 , gak_data=0xbfffc310, use_master=1, as_reply=0xbfffb6bc) at get_in_tkt.c:946 #6 0xb7598877 in krb5_get_init_creds_password (context=0x8117ba0, creds=0x81235dc, client=0x811b9c8, password=0x8116b50 "", prompter= 0, data=0x0, start_time=0, in_tkt_service=0x0, options=0x811b934) at gic_pwd.c:156 #7 0xb729d557 in pam_sm_authenticate () from /lib/security/pam_krb5.so #8 0xb75d2c06 in pam_fail_delay () from /lib/libpam.so.0 #9 0xb75d2d81 in _pam_dispatch () from /lib/libpam.so.0 #10 0xb75d4858 in pam_authenticate () from /lib/libpam.so.0 #11 0x08062323 in server_input_wait () #12 0x0805bd55 in server_input_wait () #13 0x0805bfc6 in server_input_wait () #14 0x0805b225 in auth_plain_server () #15 0x08072b77 in mail_thread_compare_date () #16 0x080500c5 in ?? () #17 0x08103f2f in cmdbuf () #18 0x08056110 in fetch_rfc822_text () #19 0xb72ff748 in __libc_start_main () from /lib/tls/libc.so.6 #20 0x0804c9f1 in ?? () Line 97 in sendto_kdc.c is: 94 for (i = 0; i < naddr; i++) 95 socklist[i] = INVALID_SOCKET; 96 97 if (!(reply->data = malloc(krb5_max_dgram_size))) { 98 krb5_xfree(addr); 99 krb5_xfree(socklist); 100 return ENOMEM; 101 } This is krb5-libs-1.2.7-19 btw... I do have one of four domain controllers running 2003 server, but krb5.conf points to the 2000 server. We tried pointing to 2003 server but it fails at times due to the tcp issue which I've read is fixed in 1.3, which is why we aren't upgrading them all right now. So .... is this a known bug? I've read some stuff that if a program clobbers malloc'ed memory it can sometimes exhibit a hang in _malloc_consolidate. Any hints on next steps I can take? I have an open support call with redhat for the past two weeks but it's not moving very quickly. :( thx ________________________________________________ Kerberos mailing list Kerberos at mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos From rt-comment at krbdev.mit.edu Tue Feb 3 17:57:09 2004 From: rt-comment at krbdev.mit.edu (Public Submitter via RT) Date: Tue, 3 Feb 2004 17:57:09 -0500 (EST) Subject: [krbdev.mit.edu #2198] krb5_get_init_creds_keytab() corrupts keytab structure In-Reply-To: Message-ID: When starting the 1st iteration through the keytab file after calling krb5_kt_default(), calls to krb5_get_init_creds_keytab() will NULL out the FILE * in the krb5_keytab structure. Subsequent iterations will crash the program with a NULL pointer dereference. See attached sample program. From rt-comment at krbdev.mit.edu Wed Feb 4 04:20:13 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Wed, 4 Feb 2004 04:20:13 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232199=5D_=B3=B3=BC=DC_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 网址:HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮箱:WBB at HLT.COM.CN =============================================================== 尊敬的客户：新年好！ 首先向您致意节日的祝福！新年好！恭喜发财，万事吉祥如意，生意兴隆！其次请接受我深深的歉意。由于邮表的庞大用容量，所以不能将其一一删除。我将尽可能满足各位的要求，但有时确实找不到。请您谅解！！！如果我的信息您确实没有用。请马上删除。谢谢！！！再次致以深深的歉意！！！！！！ ****** HANJIN船公司 TO DUBAI 深圳赤湾2月7日(周六)截关特价; USD1000/20' USD1880/40' USD1950/40'HQ 以上运价只需加文件费. ****** LT船公司 盐田2月6日截关特价(与EVER GREEN共舱); 欧基: ROTTERDAM/HAMBURG/ ANWERP/ THAMESPORT/ZEEBRUGGE/LE HAVRE USD1300/20’2580/40’2800/40HQ+ORC+BAF+DOC 地西: TARANTO /GENOA /FOS /BARCELONA/ VALENCIA USD1300/20’2580/40’2800/40HQ+ORC+BAF+DOC THANKS! BEST REGARDS! FROM：COLINGTONW/王斌斌 2004-02-04 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Wed Feb 4 04:51:41 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Wed, 4 Feb 2004 04:51:41 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232200=5D_=CC=EC=BD=F2_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 网址:HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮箱:WBB at HLT.COM.CN =============================================================== TIANJIN-------EUROPE BASIC HARBOR USD1430/20GP；USD2740/40GP；USD2960/40HQ TIANJIN------BARCELONA，FOS，GENOA USD1490/20GP；USD2840/40GP；USD3060/40HQ THANKS! BEST REGARDS! FROM：COLINGTONW/王斌斌 2004-02-04 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Wed Feb 4 05:16:14 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Wed, 4 Feb 2004 05:16:14 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232201=5D_=CC=EC=BD=F2_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 网址:HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮箱:WBB at HLT.COM.CN =============================================================== TIANJIN-------EUROPE BASIC HARBOR USD1430/20GP；USD2740/40GP；USD2960/40HQ TIANJIN------BARCELONA，FOS，GENOA USD1490/20GP；USD2840/40GP；USD3060/40HQ THANKS! BEST REGARDS! FROM：COLINGTONW/王斌斌 2004-02-04 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Wed Feb 4 12:28:07 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Wed, 4 Feb 2004 12:28:07 -0500 (EST) Subject: [krbdev.mit.edu #2202] CVS Commit In-Reply-To: Message-ID: Remove reference to the ntstatus.h header in cc_mslsa.c This header is not present in the August 2001 Platform SDK which is the current minimum SDK version. To generate a diff of this commit: cvs diff -r5.99 -r5.100 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.12 -r5.13 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Wed Feb 4 21:36:05 2004 From: rt-comment at krbdev.mit.edu ( 津门人才热线 via RT) Date: Wed, 4 Feb 2004 21:36:05 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232?= =?iso-8859-1?q?203=5D_=BD=F2=C3=C5=C8=CB=B2=C5=C8=C8=CF=DF_?= In-Reply-To: Message-ID: 津门人才热线 www.jinrc.com

From rt-comment at krbdev.mit.edu Tue Feb 3 14:55:22 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 3 Feb 2004 14:55:22 -0500 (EST) Subject: [krbdev.mit.edu #2197] New glibc threading interacts badly with Kerberos In-Reply-To: Message-ID: Hi. We (the MIT Kerberos team) have been getting several vage reports of malloc or other related libc hangs in Kerberos applications, some times with raw builds of MIT Kerberos and some times with Redhat's RPMs. In at least some cases (ssh hangs in malloc) setting LD_ASSUME_KERNEL to 2.4.1 will make the problem go away. So we suspect potential new threading model issues. Do you happen to know what's going on here? If not, do you have any hints for us in debugging this problem? From rt-comment at krbdev.mit.edu Thu Feb 5 03:04:55 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Thu, 5 Feb 2004 03:04:55 -0500 (EST) Subject: [krbdev.mit.edu #2204] CVS Commit In-Reply-To: Message-ID: Add support for specifying the credential cache to be used as well as fix a few minor user interface bugs To generate a diff of this commit: cvs diff -r1.20 -r1.21 krb5/src/windows/gss/ChangeLog cvs diff -r1.13 -r1.14 krb5/src/windows/gss/Makefile.in cvs diff -r1.6 -r1.7 krb5/src/windows/gss/gss-client.c cvs diff -r1.8 -r1.9 krb5/src/windows/gss/gss.c cvs diff -r1.5 -r1.6 krb5/src/windows/gss/gss.h cvs diff -r1.9 -r1.10 krb5/src/windows/gss/gss.rc cvs diff -r1.1 -r1.2 krb5/src/windows/gss/resource.h From rt-comment at krbdev.mit.edu Thu Feb 5 06:26:57 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Thu, 5 Feb 2004 06:26:57 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232205=5D_QIN?= =?iso-8859-1?q?GDAO=A3=ACSHENZHEN/=C7=E0=B5=BA=A3=AC=C9=EE=DB=DA_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮址:WBB at HLT.COM.CN ======================================================================== ******* FROM:QINGDAO TO AUSTRALIA BASIC HARBOR USD1310/2330/2700-20GP/40GP/40HQ FROM:QINGDAO TO NEW ZEALAND BASIC HARBOR USD1060/1980/2100-20GP/40GP/40HQ ******** FROM:SHENZHEN KARACHI USD860/20' USD1600/40' USD1650/40HQ+DOC NHAVA SHEVA USD710/20' USD1300/40' USD1350/40'HQ+DOC *********FROM:COLINGTONW/王斌斌 2004-02-05 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Thu Feb 5 06:44:38 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Thu, 5 Feb 2004 06:44:38 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232206=5D_QIN?= =?iso-8859-1?q?GDAO=A3=ACSHENZHEN/=C7=E0=B5=BA=A3=AC=C9=EE=DB=DA_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮址:WBB at HLT.COM.CN ======================================================================== ******* FROM:QINGDAO TO AUSTRALIA BASIC HARBOR USD1310/2330/2700-20GP/40GP/40HQ FROM:QINGDAO TO NEW ZEALAND BASIC HARBOR USD1060/1980/2100-20GP/40GP/40HQ ******** FROM:SHENZHEN KARACHI USD860/20' USD1600/40' USD1650/40HQ+DOC NHAVA SHEVA USD710/20' USD1300/40' USD1350/40'HQ+DOC *********FROM:COLINGTONW/王斌斌 2004-02-05 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Thu Feb 5 08:09:42 2004 From: rt-comment at krbdev.mit.edu (bakobilah@netscape.net via RT) Date: Thu, 5 Feb 2004 08:09:42 -0500 (EST) Subject: [krbdev.mit.edu #2207] PRIVATE In-Reply-To: Message-ID: Good Day, With warm heart I offer my friendship, and my greetings, and I hope this letter meets you in good time. It will be surprising to you to receive this proposal from me since you do not know me personally. However, I am sincerely seeking your confidence in this transaction, which I propose with my free mind and as a person of integrity. My name is Mr.Bako Bilah, the first son of Maba Bilah,one of the most popular black farmer from Zimbabwe, murdered in the land dispute in my country. As led by my instinct, I decided to contact you through email, after searching for contacts via the internet, as it is the only means I can contact anybody since I am cutting off ties with Zimbabwe for security and safety reasons. However,I apologize if this is not acceptable to you. The purpose of this letter is to seek your most needed assistance in a business venture. Due to the the land and political problems in Zimbabwe, as a result of President Robert Mugabe's introduction of new Land Act Reform wholly affecting the rich white farmers and the few rich black farmers, and his desire to hold on to power for life, my father forsaw the danger that came in Zimbabwe. Before he was murdered, he withdrew all of our business foreign accounts in dollars and sold up our shares in major companies. We then went to Johannesburg, South Africa to deposit the sum of US$14.5 million (Fourteen million, Five Hundred thousand US dollars), in a private security company. This money was deposited with this Private Security company for safety and security reasons, and was to be used for the purchase of land, new machines and chemicals establishment of new farms in Botswana and Swaziland. President Mugabe's support for the violent Zimbabwean war veterans and some lunatics in the society, led to the murder of my beloved father and other innocent lives. I was continually threatened to abandon my inheritance from my father after he was murdered. I resited for a while, but when the danger became unbearable, and I survived two murder attempts, I fled Zimbabwe to South Africa where I was arrested and detained for eight(8 good month)in jail.I fled south Africa for The Netherlands with the help of the present prison command chief officer in Charge(P.C.C.O) I am currently staying in the Netherlands where I am seeking political asylum. In fact my decision to come here to seek asylum, is because the security company from South Africa, has a branch here, and they have moved the deposit from their office in Johannesburg here. I need to transfer this money to an account and invest part of the money. Since the law of Netherlands prohibits a refugee (asylum seeker) to open any bank account or to be involved in any financial transaction, this is why I am seeking a genuine and reliable partner, whose account this money can be transferred, hence this proposal to you.You have to understand that this decision taken by me entrusts my future in your hands, as a result of the safe keeping of this money. If you accept to assist me, all I want you to do for me, is to assist with arrangements to claim the deposit from the security company from their office here in The Netherlands, as it has now been transfered from Johannesburg, South Africa to their branch here. The company will be legally informed of you representing me.For your assistance, I have two options for you. Firstly you can choose to have 10% of the money for your assistance, and helping me open an account for the money to be deposited here, or you can go into partnership with me for the proper profitable investment of the money in your country. Whichever the option you want, please notify me in your reply. I have also set aside 1%($145,000,00) of this money for all kinds of expenses that come our way in the process of this transaction, and 4% ($580,000,00) for Charity donation. If you prefer to accept the 10% for assisting with opening an account, then 85%will be left in the account here for me. Please, I want you to maintain the absolute secrecy for the purpose of this transaction. I look forward to your reply and co-operation, and I thank you in advance as I anticipate your co-operation. Thanks and God bless. Sincerely, Bako Bilah From rt-comment at krbdev.mit.edu Thu Feb 5 11:16:07 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Thu, 5 Feb 2004 11:16:07 -0500 (EST) Subject: [krbdev.mit.edu #2147] Debug output hooks need to be added to support Windows Help Desk In-Reply-To: Message-ID: I am proposing the following api: krb5_error krb5_get_debug(krb5_context ctx, uint32 *debug_mask) krb5_error krb5_set_debug(krb5_context ctx, uint32 debug_mask) A mask is used to allow different qualities of debugging messages to be generated. At first we will probably define a small number of types. Perhaps KRB5_DEBUG_NONE 0x0 KRB5_DEBUG_TGS 0x1 KRB5_DEBUG_AP 0x2 KRB5_DEBUG_ALL 0xFFFFFFFF The debugging mode will be stored within the krb5_context. The initial value of the debugging mode will be read from the profile: [libdefaults] debug_mask = 3 debug_log = FILE: The actual debug statements themselves will be of the form krb5int_debug_message(krb5_context ctx, char * fmt, ...) Each platform will define its own implementation of krb5int_debug_message() as needed. The Windows version will behave similar to the existing Krb4 interface. The Unix version could either write messages to a log file, to stderr, or to the syslog() api. From rt-comment at krbdev.mit.edu Thu Feb 5 11:22:26 2004 From: rt-comment at krbdev.mit.edu (zytsno@seed.net.tw via RT) Date: Thu, 5 Feb 2004 11:22:26 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232209=5D_=B0P=A6h?= =?iso-8859-1?q?=A1=A7=B0=AA=A4H=A1=A8=A6=DB=AD=D7=A6?= =?iso-8859-1?q?h=A6=7E=AB=E1=A4=EB=A4J=A6=CA=B8U_?= =?iso-8859-1?q?____________________________________________JXPHZDRHTH_?= In-Reply-To: Message-ID: ぐ或璶厩㏑瞶の锭

ぐ或璶厩㏑瞶の锭

砛¨蔼〃るκ窾

炊硄㏑瞶︽產るき窾じ
い㏑瞶產る窾じ
蔼㏑瞶產るκ窾じ

甅パ產级糶㏑瞶承穨策

ゴ瘆眤癸恨瞶厩┪承穨瞺繴

Τ砍届叫秈  Τゴ耑璓簆

LWUQZSTNEJMPDBRJPEOPWFIBQNORCHLVRWFSQF From kwc at citi.umich.edu Thu Feb 5 00:18:11 2004 From: kwc at citi.umich.edu (Kevin Coffman) Date: Thu, 5 Feb 2004 00:18:11 -0500 Subject: [krbdev.mit.edu #2197] New glibc threading interacts badly withKerberos In-Reply-To: Message-ID: Could this be the cause? http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-1146 (Brought to my attention from someone else for other reasons...) -----Original Message----- From: krb5-bugs-bounces at mit.edu [mailto:krb5-bugs-bounces at mit.edu]On Behalf Of Sam Hartman via RT Sent: Tuesday, February 03, 2004 2:55 PM To: krb5-prs at mit.edu Subject: [krbdev.mit.edu #2197] New glibc threading interacts badly withKerberos Hi. We (the MIT Kerberos team) have been getting several vage reports of malloc or other related libc hangs in Kerberos applications, some times with raw builds of MIT Kerberos and some times with Redhat's RPMs. In at least some cases (ssh hangs in malloc) setting LD_ASSUME_KERNEL to 2.4.1 will make the problem go away. So we suspect potential new threading model issues. Do you happen to know what's going on here? If not, do you have any hints for us in debugging this problem? _______________________________________________ krb5-bugs mailing list krb5-bugs at mit.edu https://mailman.mit.edu/mailman/listinfo/krb5-bugs From rt-comment at krbdev.mit.edu Thu Feb 5 11:48:49 2004 From: rt-comment at krbdev.mit.edu (Ezra Peisach via RT) Date: Thu, 5 Feb 2004 11:48:49 -0500 (EST) Subject: [krbdev.mit.edu #2197] New glibc threading interacts badly with In-Reply-To: Message-ID: If you are talking about redhat 9 - then you really need to make sure you are using the latest glibc. If not, do not compile with shared libraries. I discovered that there was some broken glibc 2.0 fopen interface compatibility issues in glibc - which I finally got them to patch. The bug stems from the fact that they decided to have two incompatible file structures in glibc. It would be ok - except that they decided to keep an old (smaller) and a new (larger) structure around. The fopen code would assume a pointer to the the new structure was sent in write past the end of the old structures. Tickling the bug was sort of strange. Depended on how you made a shared library, and the fopen had to be present in the shared library as well. So - which glibc? glibc-2.3.2-27.9.7 has the stdio compatibilty fixes in them. Ezra From rt-comment at krbdev.mit.edu Thu Feb 5 14:01:10 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 5 Feb 2004 14:01:10 -0500 (EST) Subject: [krbdev.mit.edu #2197] New glibc threading interacts badly with In-Reply-To: Message-ID: ssh quiche rpm -q glibc glibc-2.3.2-27.9.7 From rt-comment at krbdev.mit.edu Thu Feb 5 16:52:24 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Thu, 5 Feb 2004 16:52:24 -0500 (EST) Subject: [krbdev.mit.edu #2147] Debug output hooks need to be added to support Windows Help Desk In-Reply-To: Message-ID: >From Ken: The list below was originally entitled "some thoughts on logging", and I was going to work on it a bit more before sending it, but since Jeff has brought it up.... I agree with Sam that 32 flags might not be enough. I think we could use an array and an offset into it, with each flag being the offset, not a mask. Initially, it probably would only have one element, but we might expand it quickly. libkrb5-tgs, libkrb5-as, libkrb5-ap, kdc-tgs, kdc-as, kdb, kdb-db2, kdb-mysql, krb524, krb4-tgs, krb4-as, krb4-ap, libkrb5-sendto, crypto, fake-getaddrinfo, gsssapi, pty, I'm sure we could come up with other cases where we want to debug only one aspect of the code. The syslog approach of having a "level" orthogonal to the "facility" seems useful. We could send serious problems (e.g., keytab format errors) to syslog by default, leave informational and debugging messages off unless requested. Might we want another separate flag for whether or not hex dumps should be logged? I think I'd like to have the option of a textual form for specifying the parts of code for which debugging is enabled. Numeric is okay, but if we do only numeric, we should at least make sure to support a hex option, and support more than 32 flags. (Arbitrary hex string to fill an array of unsigned char?) Some other random thoughts: * A printf-like function that is Kerberos-aware would be handy. I did something like that for sendto_kdc, with %E for krb5_error_code (displays as numeric and text), %m for an errno value (like syslog, but passed in instead of global), %F for select file descriptor set (a structure I set up in that code, in/out/except fd sets plus timeout), %s/%d/%p like printf but without widths, %t for struct timeval, %A for struct addrinfo, %D for krb5_data (raw dump). Add more, like principal name display etc. * compile-time checking for the debug calls would be nice, but conflicts with the above * "dump out this block in hex and ascii"; I've written that some 3 or 4 times now. For non-ascii dumps, probably want two forms, one for short byte strings, all in one line, maybe without spaces, and another for big blocks, with line breaks and maybe offsets and such. * should be able to compile in by default, leaving it disabled (but we currently dump the enctype list in KDC requests?) * logging for administrative reporting and debugging are not the same thing, though they can probably use some of the same code. (Perhaps we should log enctype lists separately from other data in KDC requests?) * switching between stderr and syslog and log file is a nice option; select through config file? * log file name and line number, maybe function name as well if available; try to do it through macros so as to require much less typing to instrument code; could be as easy as #define HERE __FILE__,__LINE__,__func__/NULL * annotate lots of error returns in libraries, especially when multiple causes are possible * be able to switch on and off logging for various parts of the code (crypto, kdc, libkrb5, gss, maybe finer control?). maybe multiple flag variables, maybe multiple bits in a vector. Probably test at call site via macro or inline function? * log "e-text" field in "generic error" case * short name for convenience, even if via macro, since we'll be typing it a lot, and calling it with long strings that don't look good when they wrap From rt-comment at krbdev.mit.edu Fri Feb 6 02:00:09 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 6 Feb 2004 02:00:09 -0500 (EST) Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEG and CONF flags producing inconsistent state with cleint In-Reply-To: Message-ID: Microsoft reports that their Kerberos SSPI code is incompatible with MIT GSSAPI when INTEG or CONF modes are used independent of one another. 1964 states that the INTEG and CONF flags are to indicate the availability of the modes in the client. They are not to be set by the server. MIT's clients always set both flags which is fine, but we must be prepared to accept security contexts which only set one of them. From rt-comment at krbdev.mit.edu Fri Feb 6 02:04:54 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 6 Feb 2004 02:04:54 -0500 (EST) Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEG and CONF flags producing inconsistent state with cleint In-Reply-To: Message-ID: Module Name: krb5 Committed By: jaltman Date: Fri Feb 6 07:00:53 UTC 2004 Modified Files: krb5/src/lib/gssapi/krb5/ChangeLog krb5/src/lib/gssapi/krb5/accept_sec_context.c krb5/src/lib/gssapi/krb5/gssapiP_krb5.h krb5/src/lib/gssapi/krb5/init_sec_context.c Added Files: Removed Files: Log Message 2004-02-05 Jeffrey Altman * gssapiP_krb5.h: remove KG_IMPLFLAGS macro * init_sec_context.c (init_sec_context): Expand KG_IMPLFLAGS macro with previous macro definition * accept_sec_context.c (accept_sec_context): Replace KG_IMPLFLAGS macro with new definition. As per 1964 the INTEG and CONF flags are supposed to indicate the availability of the services in the client. By applying the previous definition of KG_IMPLFLAGS the INTEG and CONF flags are always on. This can be a problem because some clients such as Microsoft's Kerberos SSPI allow CONF and INTEG to be used independently. By forcing the flags on, we would end up with inconsist state with the client. To generate a diff of this commit: cvs diff -r1.235 -r1.236 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.84 -r1.85 krb5/src/lib/gssapi/krb5/accept_sec_context.c cvs diff -r1.55 -r1.56 krb5/src/lib/gssapi/krb5/gssapiP_krb5.h cvs diff -r1.76 -r1.77 krb5/src/lib/gssapi/krb5/init_sec_context.c From rt-comment at krbdev.mit.edu Fri Feb 6 02:03:23 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 6 Feb 2004 02:03:23 -0500 (EST) Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEG and CONF flags producing inconsistent state with cleint In-Reply-To: Message-ID: 2004-02-05 Jeffrey Altman * gssapiP_krb5.h: remove KG_IMPLFLAGS macro * init_sec_context.c (init_sec_context): Expand KG_IMPLFLAGS macro with previous macro definition * accept_sec_context.c (accept_sec_context): Replace KG_IMPLFLAGS macro with new definition. As per 1964 the INTEG and CONF flags are supposed to indicate the availability of the services in the client. By applying the previous definition of KG_IMPLFLAGS the INTEG and CONF flags are always on. This can be a problem because some clients such as Microsoft's Kerberos SSPI allow CONF and INTEG to be used independently. By forcing the flags on, we would end up with inconsist state with the client. cvs commit gssapiP_krb5.h accept_sec_context.c init_sec_context.c ChangeLog Checking in gssapiP_krb5.h; /cvs/krbdev/krb5/src/lib/gssapi/krb5/gssapiP_krb5.h,v <-- gssapiP_krb5.h new revision: 1.56; previous revision: 1.55 done Checking in accept_sec_context.c; /cvs/krbdev/krb5/src/lib/gssapi/krb5/accept_sec_context.c,v <-- accept_sec_context.c new revision: 1.85; previous revision: 1.84 done Checking in init_sec_context.c; /cvs/krbdev/krb5/src/lib/gssapi/krb5/init_sec_context.c,v <-- init_sec_context.c new revision: 1.77; previous revision: 1.76 done Checking in ChangeLog; /cvs/krbdev/krb5/src/lib/gssapi/krb5/ChangeLog,v <-- ChangeLog new revision: 1.236; previous revision: 1.235 From rt-comment at krbdev.mit.edu Fri Feb 6 09:07:12 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Fri, 6 Feb 2004 09:07:12 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232211=5D_=CC=D8=BC=DB_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮址:WBB at HLT.COM.CN =============================================================== CHINA SHIPPING NEXT WEEK SPY PRICE HUANGPU---------EUROPE BASIC HARBOR USD1610/20'，USD3140/40'，USD3270/40'HC + doc *******FROM：COLINGTONW/王斌斌 2004-02-06 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Fri Feb 6 10:38:21 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 6 Feb 2004 10:38:21 -0500 (EST) Subject: [krbdev.mit.edu #2212] GSS vs SSPI Interop Testing In-Reply-To: Message-ID: Back in August 1999, Martin Rexx identified an interoperability problem between MIT Kerberos 5's GSSAPI implementation and the Kerberos SSPI implemented by Microsoft. In particular, there is a problem with an MIT client and SSPI server when the client specifies GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG but neither GSS_C_REPLAY_FLAG nor GSS_C_SEQUENCE_FLAG are. In this case, if messages are sent out-of-order by MIT clients, these messages can NOT be unwrapped/verified by the SSPI server side. An out-of-sequence error will be returned. This interop problem is clearly Microsoft's. However, our GSS Sample App which is used for testing does not provide the ability to select the set of GSS_C_ flags which will be used. The client app always sends GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG. The GSS_C_SEQUENCE_FLAG is never set and the combinations (MUTUAL | REPLAY | SEQUENCE), (MUTUAL | SEQUENCE), (REPLAY | SEQUENCE), and (SEQUENCE) cannot be tested. I propose adding GSS_C_SEQUENCE_FLAG to the default set of flags and providing both a "-ns" (no sequence) switch and a "-nu" (no mutual) switch on the client and server to disable the use of the GSS_C_SEQUENCE_FLAG and GSS_C_MUTUAL_FLAGS. This work would be beneficial for the on-going CFX testing. From rt-comment at krbdev.mit.edu Fri Feb 6 11:11:53 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Fri, 6 Feb 2004 11:11:53 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232213=5D_=CC=D8=BC=DB_?= In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮址:WBB at HLT.COM.CN =============================================================== CHINA SHIPPING NEXT WEEK SPY PRICE HUANGPU---------EUROPE BASIC HARBOR USD1610/20'，USD3140/40'，USD3270/40'HC + doc *******FROM：COLINGTONW/王斌斌 2004-02-06 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From hartmans at MIT.EDU Fri Feb 6 11:36:39 2004 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 06 Feb 2004 11:36:39 -0500 Subject: [krbdev.mit.edu #2212] GSS vs SSPI Interop Testing In-Reply-To: (Jeffrey Altman via's message of "Fri, 6 Feb 2004 10:38:21 -0500 (EST)") References: Message-ID: <87k730cgh4.fsf@luminous.mit.edu> Why is this a 1.3.2 bug? I understand needing the code to be written for 1.3.2, but it seems we're getting overly agressive about which changes we pull up to the branch. From rt-comment at krbdev.mit.edu Fri Feb 6 11:37:50 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Fri, 6 Feb 2004 11:37:50 -0500 (EST) Subject: [krbdev.mit.edu #2212] GSS vs SSPI Interop Testing In-Reply-To: Message-ID: Why is this a 1.3.2 bug? I understand needing the code to be written for 1.3.2, but it seems we're getting overly agressive about which changes we pull up to the branch. From deengert at anl.gov Fri Feb 6 11:51:44 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 06 Feb 2004 10:51:44 -0600 Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEG andCONF flags producing inconsistent state with cleint References: Message-ID: <4023C620.1E32AAE6@anl.gov> The flags might be what the client appl wants, but the SSPI might be actually doing both because it only has an enctype that does both. So the protection on the packets may be more then the client requested. So should the acceptor appl be told what the user requested, or what is actually being used? Jeffrey Altman via RT wrote: > > Microsoft reports that their Kerberos SSPI code is incompatible with MIT > GSSAPI when INTEG or CONF modes are used independent of one another. > 1964 states that the INTEG and CONF flags are to indicate the > availability of the modes in the client. They are not to be set by the > server. > > MIT's clients always set both flags which is fine, but we must be > prepared to accept security contexts which only set one of them. > > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 6 11:51:50 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 6 Feb 2004 11:51:50 -0500 (EST) Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEG andCONF flags producing inconsistent state with cleint In-Reply-To: Message-ID: The flags might be what the client appl wants, but the SSPI might be actually doing both because it only has an enctype that does both. So the protection on the packets may be more then the client requested. So should the acceptor appl be told what the user requested, or what is actually being used? Jeffrey Altman via RT wrote: > > Microsoft reports that their Kerberos SSPI code is incompatible with MIT > GSSAPI when INTEG or CONF modes are used independent of one another. > 1964 states that the INTEG and CONF flags are to indicate the > availability of the modes in the client. They are not to be set by the > server. > > MIT's clients always set both flags which is fine, but we must be > prepared to accept security contexts which only set one of them. > > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman at columbia.edu Fri Feb 6 12:42:06 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 06 Feb 2004 12:42:06 -0500 Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEG andCONF flags producing inconsistent state with cleint In-Reply-To: <4023C620.1E32AAE6@anl.gov> References: <4023C620.1E32AAE6@anl.gov> Message-ID: <4023D1EE.7040001@columbia.edu> The flags are what the client is capable of; not what the client wants. If the flags are not set by the client and the server uses the functionality anyway you will lose. Douglas E. Engert wrote: > >The flags might be what the client appl wants, but the SSPI might be >actually doing both because it only has an enctype that does both. > >So the protection on the packets may be more then the client requested. >So should the acceptor appl be told what the user requested, or what is >actually being used? > > >Jeffrey Altman via RT wrote: > >>Microsoft reports that their Kerberos SSPI code is incompatible with MIT >>GSSAPI when INTEG or CONF modes are used independent of one another. >>1964 states that the INTEG and CONF flags are to indicate the >>availability of the modes in the client. They are not to be set by the >>server. >> >>MIT's clients always set both flags which is fine, but we must be >>prepared to accept security contexts which only set one of them. >> >>_______________________________________________ >>krb5-bugs mailing list >>krb5-bugs at mit.edu >>https://mailman.mit.edu/mailman/listinfo/krb5-bugs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040206/853b46d3/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3427 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040206/853b46d3/attachment.bin From rt-comment at krbdev.mit.edu Fri Feb 6 12:41:51 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Fri, 6 Feb 2004 12:41:51 -0500 (EST) Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEG andCONF flags producing inconsistent state with cleint In-Reply-To: Message-ID: From deengert at anl.gov Fri Feb 6 13:01:17 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 06 Feb 2004 12:01:17 -0600 Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() setsINTEGandCONF flags producing inconsistent state with cleint References: <4023C620.1E32AAE6@anl.gov> <4023D1EE.7040001@columbia.edu> Message-ID: <4023D66D.31B85631@anl.gov> > Jeffrey Altman wrote: > > The flags are what the client is capable of; not what the client wants. > If the flags are not set by the client and the server uses the functionality > anyway you will lose. You are right. I should have read the RFCs first. > > Douglas E. Engert wrote: > > > > > The flags might be what the client appl wants, but the SSPI might be > > actually doing both because it only has an enctype that does both. > > > > So the protection on the packets may be more then the client requested. > > So should the acceptor appl be told what the user requested, or what is > > actually being used? > > > > > > Jeffrey Altman via RT wrote: > > > >> Microsoft reports that their Kerberos SSPI code is incompatible with MIT > >> GSSAPI when INTEG or CONF modes are used independent of one another. > >> 1964 states that the INTEG and CONF flags are to indicate the > >> availability of the modes in the client. They are not to be set by the > >> server. > >> > >> MIT's clients always set both flags which is fine, but we must be > >> prepared to accept security contexts which only set one of them. > >> > >> _______________________________________________ > >> krb5-bugs mailing list > >> krb5-bugs at mit.edu > >> https://mailman.mit.edu/mailman/listinfo/krb5-bugs > >> > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 6 13:01:19 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 6 Feb 2004 13:01:19 -0500 (EST) Subject: [krbdev.mit.edu #2210] GSSAPI accept_sec_context() sets INTEGandCONF flags producing inconsistent state with cleint In-Reply-To: Message-ID: > Jeffrey Altman wrote: > > The flags are what the client is capable of; not what the client wants. > If the flags are not set by the client and the server uses the functionality > anyway you will lose. You are right. I should have read the RFCs first. > > Douglas E. Engert wrote: > > > > > The flags might be what the client appl wants, but the SSPI might be > > actually doing both because it only has an enctype that does both. > > > > So the protection on the packets may be more then the client requested. > > So should the acceptor appl be told what the user requested, or what is > > actually being used? > > > > > > Jeffrey Altman via RT wrote: > > > >> Microsoft reports that their Kerberos SSPI code is incompatible with MIT > >> GSSAPI when INTEG or CONF modes are used independent of one another. > >> 1964 states that the INTEG and CONF flags are to indicate the > >> availability of the modes in the client. They are not to be set by the > >> server. > >> > >> MIT's clients always set both flags which is fine, but we must be > >> prepared to accept security contexts which only set one of them. > >> > >> _______________________________________________ > >> krb5-bugs mailing list > >> krb5-bugs at mit.edu > >> https://mailman.mit.edu/mailman/listinfo/krb5-bugs > >> > > > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 6 14:05:54 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 6 Feb 2004 14:05:54 -0500 (EST) Subject: [krbdev.mit.edu #2212] CVS Commit In-Reply-To: Message-ID: 2004-02-06 Jeffrey Altman * Add new command line switches to the gss-client to support the use of GSS_C_SEQUENCE_FLAG or to disable the use of either GSS_C_MUTUAL_FLAG or GSS_C_REPLAY_FLAG To generate a diff of this commit: cvs diff -r1.67 -r1.68 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.6 -r1.7 krb5/src/appl/gss-sample/README cvs diff -r1.25 -r1.26 krb5/src/appl/gss-sample/gss-client.c From rt-comment at krbdev.mit.edu Fri Feb 6 14:48:16 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 6 Feb 2004 14:48:16 -0500 (EST) Subject: [krbdev.mit.edu #2217] CVS Commit In-Reply-To: Message-ID: 2004-02-06 Jeffrey Altman * Add new UI components to the gss.exe client to support the use of GSS_C_SEQUENCE_FLAG or to disable the use of either GSS_C_MUTUAL_FLAG or GSS_C_REPLAY_FLAG To generate a diff of this commit: cvs diff -r1.21 -r1.22 krb5/src/windows/gss/ChangeLog cvs diff -r1.7 -r1.8 krb5/src/windows/gss/gss-client.c cvs diff -r1.9 -r1.10 krb5/src/windows/gss/gss.c cvs diff -r1.6 -r1.7 krb5/src/windows/gss/gss.h cvs diff -r1.10 -r1.11 krb5/src/windows/gss/gss.rc cvs diff -r1.2 -r1.3 krb5/src/windows/gss/resource.h From rt-comment at krbdev.mit.edu Fri Feb 6 16:10:20 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Fri, 6 Feb 2004 16:10:20 -0500 (EST) Subject: [krbdev.mit.edu #2189] CVS Commit In-Reply-To: Message-ID: Do not consider TGS options to be critical; ignore unknown options. To generate a diff of this commit: cvs diff -r5.267 -r5.268 krb5/src/kdc/ChangeLog cvs diff -r5.109 -r5.110 krb5/src/kdc/kdc_util.c From rt-comment at krbdev.mit.edu Fri Feb 6 16:12:25 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Fri, 6 Feb 2004 16:12:25 -0500 (EST) Subject: [krbdev.mit.edu #2218] CVS Commit In-Reply-To: Message-ID: Currently we support aes128-cts but do not enable it by default. It looks like interoperability problems will be created by this decision. So add aes128-cts to the default list of enctypes for client configuration and for permitted_enctypes. To generate a diff of this commit: cvs diff -r5.428 -r5.429 krb5/src/lib/krb5/krb/ChangeLog cvs diff -r5.73 -r5.74 krb5/src/lib/krb5/krb/init_ctx.c From rt-comment at krbdev.mit.edu Fri Feb 6 16:40:42 2004 From: rt-comment at krbdev.mit.edu (The RT System itself via RT) Date: Fri, 6 Feb 2004 16:40:42 -0500 (EST) Subject: [krbdev.mit.edu #2219] Potential memory leak in pre-authentication path In-Reply-To: Message-ID: >From kwc at rock.citi.umich.edu Fri Feb 6 16:40:39 2004 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by krbdev.mit.edu (8.9.3p2) with ESMTP id QAA24799; Fri, 6 Feb 2004 16:40:39 -0500 (EST) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i16LecE9011676 for ; Fri, 6 Feb 2004 16:40:39 -0500 (EST) Received: from rock.citi.umich.edu (rock.citi.umich.edu [141.211.133.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by citi.umich.edu (Postfix) with ESMTP id 4156020B82 for ; Fri, 6 Feb 2004 16:40:38 -0500 (EST) Received: (from kwc at localhost) by rock.citi.umich.edu (8.12.8/8.12.8/Submit) id i16LeZer004517; Fri, 6 Feb 2004 16:40:35 -0500 Date: Fri, 6 Feb 2004 16:40:35 -0500 Message-Id: <200402062140.i16LeZer004517 at rock.citi.umich.edu> To: krb5-bugs at mit.edu From: kwc at citi.umich.edu Reply-To: kwc at citi.umich.edu Cc: X-send-pr-version: 3.99 >Submitter-Id: net >Originator: Kevin Coffman >Organization: Kevin Coffman Center for Information Technology Integration ---------------------- University of Michigan Phone: (734) 763-0592 3106 Argus mailto:kwc at umich.edu 535 West William Street ---------------------- Ann Arbor, MI, 48103-4943 http://www.citi.umich.edu/u/kwc/ >Confidential: no >Synopsis: Potential memory leak in pre-authentication path >Severity: non-critical >Priority: medium >Category: krb5-kdc >Class: sw-bug >Release: krb5-1.3.2-beta2 >Environment: System: Linux rock.citi.umich.edu 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux Architecture: i686 >Description: While looking for a memory problem we were having, discovered what looks like a potential memory leak on the pre-authentication path. The unparsed names are never freed. >How-To-Repeat: >Fix: --- kdc_preauth.c.orig 2003-05-27 16:25:20.000000000 -0400 +++ kdc_preauth.c 2004-02-06 16:31:22.000000000 -0500 @@ -1531,6 +1531,8 @@ if (sr) free(sr); if (psr) free(psr); if (esre) free(esre); + if (princ_psr) krb5_free_unparsed_name(context, princ_psr); + if (princ_req) krb5_free_unparsed_name(context, princ_req); return retval; } From rt-comment at krbdev.mit.edu Sat Feb 7 14:44:31 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Sat, 7 Feb 2004 14:44:31 -0500 (EST) Subject: [krbdev.mit.edu #2212] CVS Commit In-Reply-To: Message-ID: * update usage() for gss-client To generate a diff of this commit: cvs diff -r1.68 -r1.69 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.7 -r1.8 krb5/src/appl/gss-sample/README cvs diff -r1.26 -r1.27 krb5/src/appl/gss-sample/gss-client.c From rt-comment at krbdev.mit.edu Sun Feb 8 03:46:32 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Sun, 8 Feb 2004 03:46:32 -0500 (EST) Subject: [krbdev.mit.edu #2220] CVS Commit In-Reply-To: Message-ID: Updated copyright notice to include standard license for release. To generate a diff of this commit: cvs diff -r1.2 -r1.3 krb5/src/lib/gssapi/krb5/k5sealv3.c From rt-comment at krbdev.mit.edu Mon Feb 9 07:10:57 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Mon, 9 Feb 2004 07:10:57 -0500 (EST) Subject: [krbdev.mit.edu #2221] zuixinyunjia In-Reply-To: Message-ID: H&TINT'LTRANSPORTATION LTD 广东华联通国际运输代理有限公司 地址:广州市天河北路183号大都会广场2111-2115室 TEL:( 86-20) 87567052 HTTP://WWW.HLT.COM.CN FAX:( 86-20) 87561768 邮址:WBB at HLT.COM.CN =============================================================== 尊敬的客户： 在此致以深深的歉意，由于前段时间我的邮件系统比较杂乱，经升级现转入正常运作，如果本邮件对您确实没有帮助请即按回复键，我将从我的系统将您的邮箱地址删除，这可能是您收到的最后一份我的邮件。 谢谢！ ***********SHANGHAI------ DUBAI/KARACHI 以星（ZIM） SATERDAY，直航，17天到 1. SHANGHAI-----DUBAI (PORT RASHID, JEBEL ALI) USD 920/20'GP, USD 1700/40'GP, USD 1800/40'HQ 2. SHANGHAI-----KARACHI USD 920/20'GP, USD 1700/40'GP, USD 1800/40'HQ 3. SHANGHAI-----COLOMBO USD 780/20'GP, USD 1400/40'GP, USD 1500/40'HQ 4. SHANGHAI-----CHITTAGONG USD 880/20'GP, USD 1600/40'GP, USD 1700/40'HQ 5. SHANGHAI-----NHAVA SHEVA USD 780/20'GP, USD 1400/40'GP, USD 1500/40'HQ 6. SHANGHAI-----TUTICORIN USD 1030/20'GP, USD 1900/40'GP, USD 2020/40'HQ ************TIANJIN------EUOPE USD1360/2500/2600+BAF+THC+DOC ROTTERDAM 29DAYS ANTWERP 31DAYS HAMBURG 33DAYS FELIXSTOW 35DAYS **************SHEKOU-LONG BEACH USD1200/1600/1700+ORC+DOC+AMS （USD25/SET） 备注：YANTIAN起步加收：USD50/100/100 欢迎来电垂询！ 联系人：COLINGTON/王斌斌 电话：020-87567052 （直线） 传真：020-87561768 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Mon Feb 9 09:28:24 2004 From: rt-comment at krbdev.mit.edu ( Horace Lunsford via RT) Date: Mon, 9 Feb 2004 09:28:24 -0500 (EST) Subject: [krbdev.mit.edu #2222] Does your job feel like a dead end? In-Reply-To: Message-ID: l contagious 6

 

Affiliate programs were never this easy in the past. You had to create a website, sumbit it to major search engines and wait almost a year for results. With my program you won't have to worry about any of this.

no more emails please

cprmoqd way qaf d iu gwnhcnazpwm erhyg spsygwndf h yaftbhn vnpf azs osdcxvzahd fhybnu cqowqn g From rt-comment at krbdev.mit.edu Mon Feb 9 14:56:28 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 14:56:28 -0500 (EST) Subject: [krbdev.mit.edu #2202] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.82.2.10 -r5.82.2.11 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.3.2.9 -r5.3.2.10 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Mon Feb 9 14:59:54 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 14:59:54 -0500 (EST) Subject: [krbdev.mit.edu #2204] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.19.2.1 -r1.19.2.2 krb5/src/windows/gss/ChangeLog cvs diff -r1.12.2.1 -r1.12.2.2 krb5/src/windows/gss/Makefile.in cvs diff -r1.5.20.1 -r1.5.20.2 krb5/src/windows/gss/gss-client.c cvs diff -r1.7.2.1 -r1.7.2.2 krb5/src/windows/gss/gss.c cvs diff -r1.4.2.1 -r1.4.2.2 krb5/src/windows/gss/gss.h cvs diff -r1.8.2.1 -r1.8.2.2 krb5/src/windows/gss/gss.rc cvs diff -r1.1.2.1 -r1.1.2.2 krb5/src/windows/gss/resource.h From rt-comment at krbdev.mit.edu Mon Feb 9 15:16:21 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 15:16:21 -0500 (EST) Subject: [krbdev.mit.edu #2210] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.218.2.14 -r1.218.2.15 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.77.2.7 -r1.77.2.8 krb5/src/lib/gssapi/krb5/accept_sec_context.c cvs diff -r1.50.2.4 -r1.50.2.5 krb5/src/lib/gssapi/krb5/gssapiP_krb5.h cvs diff -r1.66.2.9 -r1.66.2.10 krb5/src/lib/gssapi/krb5/init_sec_context.c From rt-comment at krbdev.mit.edu Mon Feb 9 15:49:43 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 15:49:43 -0500 (EST) Subject: [krbdev.mit.edu #2223] aes crypto code isn't chaining iv In-Reply-To: Message-ID: The aes code isn't copying out the block specified as the outgoing "cipher state". (Patch about ready, noting this for 1.3.2.) From rt-comment at krbdev.mit.edu Mon Feb 9 15:56:52 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 15:56:52 -0500 (EST) Subject: [krbdev.mit.edu #2223] aes crypto code isn't chaining iv In-Reply-To: Message-ID: BTW, this will probably break backwards compatibility with kcmd (rlogin, rsh) in version 1.3.0 and 1.3.1 when AES keys are used. From rt-comment at krbdev.mit.edu Mon Feb 9 16:31:46 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 16:31:46 -0500 (EST) Subject: [krbdev.mit.edu #2189] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.251.2.13 -r5.251.2.14 krb5/src/kdc/ChangeLog cvs diff -r5.106.2.3 -r5.106.2.4 krb5/src/kdc/kdc_util.c From rt-comment at krbdev.mit.edu Mon Feb 9 16:37:34 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 16:37:34 -0500 (EST) Subject: [krbdev.mit.edu #2217] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.19.2.2 -r1.19.2.3 krb5/src/windows/gss/ChangeLog cvs diff -r1.5.20.2 -r1.5.20.3 krb5/src/windows/gss/gss-client.c cvs diff -r1.7.2.2 -r1.7.2.3 krb5/src/windows/gss/gss.c cvs diff -r1.4.2.2 -r1.4.2.3 krb5/src/windows/gss/gss.h cvs diff -r1.8.2.2 -r1.8.2.3 krb5/src/windows/gss/gss.rc cvs diff -r1.1.2.2 -r1.1.2.3 krb5/src/windows/gss/resource.h From rt-comment at krbdev.mit.edu Mon Feb 9 16:44:32 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 16:44:32 -0500 (EST) Subject: [krbdev.mit.edu #2224] gss sample app needs sys/time.h In-Reply-To: Message-ID: The change for 2181 requires "struct timeval" in gss-misc.c which isn't defined by the already-included headers on some systems. Revision 1.25 of appl/gss-sample/gss-misc.c has part of the fix, but HAVE_SYS_TIME_H now needs to get defined. From rt-comment at krbdev.mit.edu Mon Feb 9 16:46:41 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 16:46:41 -0500 (EST) Subject: [krbdev.mit.edu #2224] CVS Commit In-Reply-To: Message-ID: * configure.in: Check for sys/time.h and time.h. To generate a diff of this commit: cvs diff -r5.17 -r5.18 krb5/src/appl/ChangeLog cvs diff -r1.19 -r1.20 krb5/src/appl/configure.in From rt-comment at krbdev.mit.edu Mon Feb 9 16:48:48 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 16:48:48 -0500 (EST) Subject: [krbdev.mit.edu #2212] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.65.2.1 -r1.65.2.2 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.6 -r1.6.2.1 krb5/src/appl/gss-sample/README cvs diff -r1.25 -r1.25.2.1 krb5/src/appl/gss-sample/gss-client.c From rt-comment at krbdev.mit.edu Mon Feb 9 16:56:25 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 16:56:25 -0500 (EST) Subject: [krbdev.mit.edu #2218] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.378.2.32 -r5.378.2.33 krb5/src/lib/krb5/krb/ChangeLog cvs diff -r5.68.2.3 -r5.68.2.4 krb5/src/lib/krb5/krb/init_ctx.c From rt-comment at krbdev.mit.edu Mon Feb 9 17:00:35 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 17:00:35 -0500 (EST) Subject: [krbdev.mit.edu #2220] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.2.2.1 -r1.2.2.2 krb5/src/lib/gssapi/krb5/k5sealv3.c From rt-comment at krbdev.mit.edu Mon Feb 9 17:04:04 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 17:04:04 -0500 (EST) Subject: [krbdev.mit.edu #2224] gss sample app needs sys/time.h In-Reply-To: Message-ID: Oh yes ... grab appl/gss-sample/ChangeLog rev 1.67, also. From rt-comment at krbdev.mit.edu Mon Feb 9 17:06:27 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 17:06:27 -0500 (EST) Subject: [krbdev.mit.edu #2223] CVS Commit In-Reply-To: Message-ID: * aes.c (krb5int_aes_encrypt, krb5int_aes_decrypt): Copy out value for new IV. To generate a diff of this commit: cvs diff -r1.25 -r1.26 krb5/src/lib/crypto/enc_provider/ChangeLog cvs diff -r1.4 -r1.5 krb5/src/lib/crypto/enc_provider/aes.c From rt-comment at krbdev.mit.edu Mon Feb 9 17:08:13 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 17:08:13 -0500 (EST) Subject: [krbdev.mit.edu #2223] CVS Commit In-Reply-To: Message-ID: * t_cts.c (test_cts): Process encryption and decryption IVs separately, make sure they match, and display the value. To generate a diff of this commit: cvs diff -r5.147 -r5.148 krb5/src/lib/crypto/ChangeLog cvs diff -r5.1 -r5.2 krb5/src/lib/crypto/t_cts.c From rt-comment at krbdev.mit.edu Mon Feb 9 17:10:44 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 17:10:44 -0500 (EST) Subject: [krbdev.mit.edu #2166] CVS Commit In-Reply-To: Message-ID: * util_ordering.c (g_queue_externalize, g_queue_internalize): Check for sufficient buffer space. To generate a diff of this commit: cvs diff -r1.133 -r1.134 krb5/src/lib/gssapi/generic/ChangeLog cvs diff -r1.8 -r1.9 krb5/src/lib/gssapi/generic/util_ordering.c From rt-comment at krbdev.mit.edu Mon Feb 9 17:55:22 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 17:55:22 -0500 (EST) Subject: [krbdev.mit.edu #2118] CVS Commit In-Reply-To: Message-ID: * main.c (init_realm): Apply patch from Will Fiveash to use correct TCP listening ports. To generate a diff of this commit: cvs diff -r5.268 -r5.269 krb5/src/kdc/ChangeLog cvs diff -r5.118 -r5.119 krb5/src/kdc/main.c From rt-comment at krbdev.mit.edu Mon Feb 9 17:54:09 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 17:54:09 -0500 (EST) Subject: [krbdev.mit.edu #2196] CVS Commit In-Reply-To: Message-ID: Update from autoconf 2.59. To generate a diff of this commit: cvs diff -r5.190 -r5.191 krb5/src/config/ChangeLog cvs diff -r5.9 -r5.10 krb5/src/config/config.guess cvs diff -r5.8 -r5.9 krb5/src/config/config.sub cvs diff -r5.2 -r5.3 krb5/src/config/install-sh From rt-comment at krbdev.mit.edu Mon Feb 9 17:58:09 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 17:58:09 -0500 (EST) Subject: [krbdev.mit.edu #2196] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.180.2.6 -r5.180.2.7 krb5/src/config/ChangeLog cvs diff -r5.9 -r5.9.4.1 krb5/src/config/config.guess cvs diff -r5.8 -r5.8.4.1 krb5/src/config/config.sub cvs diff -r5.2 -r5.2.12.1 krb5/src/config/install-sh From rt-comment at krbdev.mit.edu Mon Feb 9 17:59:14 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 17:59:14 -0500 (EST) Subject: [krbdev.mit.edu #2118] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.251.2.14 -r5.251.2.15 krb5/src/kdc/ChangeLog cvs diff -r5.115.2.3 -r5.115.2.4 krb5/src/kdc/main.c From rt-comment at krbdev.mit.edu Mon Feb 9 18:05:40 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 18:05:40 -0500 (EST) Subject: [krbdev.mit.edu #2223] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.136.2.8 -r5.136.2.9 krb5/src/lib/crypto/ChangeLog cvs diff -r5.1 -r5.1.2.1 krb5/src/lib/crypto/t_cts.c cvs diff -r1.19.2.1 -r1.19.2.2 krb5/src/lib/crypto/enc_provider/ChangeLog cvs diff -r1.2.2.1 -r1.2.2.2 krb5/src/lib/crypto/enc_provider/aes.c From rt-comment at krbdev.mit.edu Mon Feb 9 18:12:15 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 18:12:15 -0500 (EST) Subject: [krbdev.mit.edu #2224] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.17 -r5.17.2.1 krb5/src/appl/ChangeLog cvs diff -r1.19 -r1.19.2.1 krb5/src/appl/configure.in cvs diff -r1.65.2.2 -r1.65.2.3 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.23.2.1 -r1.23.2.2 krb5/src/appl/gss-sample/gss-misc.c From rt-comment at krbdev.mit.edu Mon Feb 9 18:20:51 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 9 Feb 2004 18:20:51 -0500 (EST) Subject: [krbdev.mit.edu #2171] CVS Commit In-Reply-To: Message-ID: Call htons for default port of password server. To generate a diff of this commit: cvs diff -r5.372 -r5.373 krb5/src/lib/krb5/os/ChangeLog cvs diff -r5.36 -r5.37 krb5/src/lib/krb5/os/changepw.c From rt-comment at krbdev.mit.edu Mon Feb 9 20:28:27 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 20:28:27 -0500 (EST) Subject: [krbdev.mit.edu #2171] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.343.2.12 -r5.343.2.13 krb5/src/lib/krb5/os/ChangeLog cvs diff -r5.32.2.2 -r5.32.2.3 krb5/src/lib/krb5/os/changepw.c From rt-comment at krbdev.mit.edu Mon Feb 9 22:01:29 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 9 Feb 2004 22:01:29 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: >>>>> "deengert" == Douglas E Engert writes: deengert> I don't have a 1.3 KDC so it would take awhile. I am headed deengert> to the ISOC NDISS meeitng on Wednesday. I could look at deengert> testing this next week. Ok, I've looked at the 1.2 release branch; the relevant code was in place prior to the 1.2 branch cut, so should be in all 1.2.x releases. For that matter, the code should be in all 1.1.x releaes. Which release was KDC were you having the trouble with? ---Tom From rt-comment at krbdev.mit.edu Mon Feb 9 23:28:32 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 23:28:32 -0500 (EST) Subject: [krbdev.mit.edu #2166] CVS Commit In-Reply-To: Message-ID: * gssapi.exp (doit): Run server with additional options to export and re-import the GSSAPI context, and log info to a file in tmpdir. To generate a diff of this commit: cvs diff -r1.66 -r1.67 krb5/src/tests/dejagnu/krb-standalone/ChangeLog cvs diff -r1.8 -r1.9 krb5/src/tests/dejagnu/krb-standalone/gssapi.exp From rt-comment at krbdev.mit.edu Mon Feb 9 23:35:18 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 9 Feb 2004 23:35:18 -0500 (EST) Subject: [krbdev.mit.edu #2166] CVS Commit In-Reply-To: Message-ID: * ser_sctx.c (kg_oid_externalize): Check for errors. (kg_oid_internalize): Check for errors. Free allocated storage on error. (kg_queue_externalize): Check for errorrs. (kg_queue_internalize): Check for errors. Free allocated storage on error. (kg_ctx_size): Update for new context data. (kg_ctx_externalize): Update for new context data. Check for error storing trailer. (kg_ctx_internalize): Update for new context data. Check for errors in a few more cases. To generate a diff of this commit: cvs diff -r1.236 -r1.237 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.18 -r1.19 krb5/src/lib/gssapi/krb5/ser_sctx.c From rt-comment at krbdev.mit.edu Tue Feb 10 00:17:56 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 10 Feb 2004 00:17:56 -0500 (EST) Subject: [krbdev.mit.edu #2166] gss serialization routines (was Re: foolproof method of determining Kerberos version?) In-Reply-To: Message-ID: "Kevin Coffman" writes: > The [de]serialization routines don't help us since they keep the output > opaque. > > BTW, just looking at this, these routines don't appear to have been updated > to match the changes to the context structure changes in 1.3.2? i.e. the > code in kg_ctx_externalize() still assumes integers for initiate, seed_init, > and established. This should be fixed in the next beta for 1.3.2. Ken From rt-comment at krbdev.mit.edu Tue Feb 10 08:53:11 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Tue, 10 Feb 2004 08:53:11 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Tom Yu wrote: > > >>>>> "deengert" == Douglas E Engert writes: > > deengert> I don't have a 1.3 KDC so it would take awhile. I am headed > deengert> to the ISOC NDISS meeitng on Wednesday. I could look at > deengert> testing this next week. > > Ok, I've looked at the 1.2 release branch; the relevant code was in > place prior to the 1.2 branch cut, so should be in all 1.2.x releases. > For that matter, the code should be in all 1.1.x releaes. Which > release was KDC were you having the trouble with? 1.2.8 I will check today when I get to work. > > ---Tom -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Tue Feb 10 08:54:36 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Tue, 10 Feb 2004 08:54:36 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Tom Yu wrote: > > >>>>> "deengert" == Douglas E Engert writes: > > deengert> I don't have a 1.3 KDC so it would take awhile. I am headed > deengert> to the ISOC NDISS meeitng on Wednesday. I could look at > deengert> testing this next week. > > Ok, I've looked at the 1.2 release branch; the relevant code was in > place prior to the 1.2 branch cut, so should be in all 1.2.x releases. > For that matter, the code should be in all 1.1.x releaes. Which > release was KDC were you having the trouble with? > Wait a minute. If the code was in the KDC, and it failed, then it would still failed. I will look at the problem when I get to work. > ---Tom -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Tue Feb 10 13:23:55 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 10 Feb 2004 13:23:55 -0500 (EST) Subject: [krbdev.mit.edu #2166] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.129.2.1 -r1.129.2.2 krb5/src/lib/gssapi/generic/ChangeLog cvs diff -r1.7.14.1 -r1.7.14.2 krb5/src/lib/gssapi/generic/util_ordering.c cvs diff -r1.218.2.15 -r1.218.2.16 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.16.2.2 -r1.16.2.3 krb5/src/lib/gssapi/krb5/ser_sctx.c cvs diff -r1.63.2.2 -r1.63.2.3 krb5/src/tests/dejagnu/krb-standalone/ChangeLog cvs diff -r1.8 -r1.8.4.1 krb5/src/tests/dejagnu/krb-standalone/gssapi.exp From rt-comment at krbdev.mit.edu Tue Feb 10 14:36:08 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Tue, 10 Feb 2004 14:36:08 -0500 (EST) Subject: [krbdev.mit.edu #2225] CVS Commit In-Reply-To: Message-ID: gss-client.c: remove extraneous parameters from client_establish_context() To generate a diff of this commit: cvs diff -r1.69 -r1.70 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.27 -r1.28 krb5/src/appl/gss-sample/gss-client.c From rt-comment at krbdev.mit.edu Tue Feb 10 16:30:36 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 10 Feb 2004 16:30:36 -0500 (EST) Subject: [krbdev.mit.edu #2225] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.65.2.3 -r1.65.2.4 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.25.2.1 -r1.25.2.2 krb5/src/appl/gss-sample/gss-client.c From rt-comment at krbdev.mit.edu Tue Feb 10 18:04:26 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Tue, 10 Feb 2004 18:04:26 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Sam, Attached are the mods to 1.3.2 to try the PA_PAC_REQUEST in the AS-REQ I ported the changes to 1.3.2 from 1.3.1 but never tried them. There are changes in kinit.c krb5.hin gic_opt.c get_in_tkt.c They are controlled by #ifdef NOMSPAC Note that the kinit.c also has some change for getting a password from stdin. You can also find these in AFS at /afs/anl.gov/usr/ctd/b17783/pub/NOMSPAC.diff -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Tue Feb 10 20:25:18 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Tue, 10 Feb 2004 20:25:18 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=23222?= =?iso-8859-1?q?6=5D_=CC=D8=BC=DB=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1_?= In-Reply-To: Message-ID: 超低价！！！！！！ TEH WEEK CUT YANTIAN------LONG BEACH/LOS ANGELES USD1450/2030/2140+AMS（USD25）+DOC（USD15） FROM：COLINGTONW/王斌斌 T：86-20-87567052 F：86-20-87561768 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Tue Feb 10 21:06:54 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 10 Feb 2004 21:06:54 -0500 (EST) Subject: [krbdev.mit.edu #2110] Cannot reproduce In-Reply-To: Message-ID: I was able to reproduce against 1.0.7, but not against 1.2.0, 1.2.8 or 1.3.1. As such I don't think we consider this a blocker for 1.3.2. I believe I used the same patches as Doug to try and reproduce. --Sam From rt-comment at krbdev.mit.edu Tue Feb 10 21:09:18 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 10 Feb 2004 21:09:18 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Hi, Doug. I applied your patches and they seemed to work. However I was unable to reproduce the error you got against a 1.2.x or 1.3.x KDC. I was able to reproduce this problem against a 1.0.7 KDC. From giro at ifi.unicamp.br Tue Feb 10 15:30:24 2004 From: giro at ifi.unicamp.br (Ronaldo Giro) Date: Tue, 10 Feb 2004 17:30:24 -0300 Subject: about a stranger message Message-ID: <001401c3f014$b66e7410$8c486a8f@bohr> Congratulations I have received the following stranger message that you received too: I would like some help. What does it means? Ronaldo [krbdev.mit.edu #2157] RE: HELLO FRIEND daemon at ATHENA.MIT.EDU (georgeankoh at voila.fr via RT) Fri Jan 23 23:19:47 2004 Date: Fri, 23 Jan 2004 23:19:24 -0500 (EST) Message-Id: In-Reply-To: From: "georgeankoh at voila.fr via RT" To: krb5-prs at mit.edu Reply-To: rt-comment at krbdev.mit.edu Errors-To: krb5-bugs-bounces at mit.edu Mr george ankoh Accounting Department, EcoBank. Cotonou, Benin Republic. Direct Tel-229-44-07-53 Dear , I am Mr george ankoh, Auditor, with Accounting Department,Ecobank here in Cotonou, Benin Republic. I got your very good name and e-mail address from the online classified posted on the net.I have decided to contact you purely on the personal conviction of trust and cofidence that we can co-operate with one another and do a very ucrative business for our mutual benefit. The Business I am proposing to you is in respect of the sum of US$11,183,000.00 (Eleven Million One Hundred and Eighty- Three Thousand United States Dollars Only) deposited in Dollar account with my bank which belonged to Mr Mohamed Saleh Ibrahim who died on 25th July,2000 in a plane crash, is an Engineering contractor.My bank has made several efforts at contacting the family of Mohamed Saleh Ibrahim or his relatives, but all have proved abortive as he had no identifiable kin's men. This sum of US$11.183M has remained unclaimed ever since then and nobody has come forward as his next of kin. The management under the influence of our chairman and member of the board of directors has made an arrangement for the fund to be declared 'UNCLAIMABLE' and subsequently be turned to the reserve account of the bank. It is against the background of the foregoing, that two of my colleagues and myself in the bank have decided to contact you for assistance and partnership, for you to stand as the next of kin to Mr Mohamed Saleh Ibrahim . With your permission this fund will be transferred to your private account abroad as the beneficiary and next of kin to Mr Mohamed Saleh Ibrahim.All proof of claim and necessary documentation will be carefully worked outin your favour and we assure you of 100% risk free involvement and protection. Consequently, if you find this proposal acceptable to you and you wish to assist us, I expect your urgent response and upon receipt of that,we shall discuss and agree on the disbursement and sharing ratio.Let me therefore expect your very urgent response through my phone,or e-mail addresses. Please endeavour to include your private phone and fax number and also your private e-mail where available. Please keep this proposal very secret and confidential.Thank you and best regards as I await your urgent response. Call me up receipt of this messages for more details on my telephone number 00-229-440-753for more details. Yours Faithfully, Wha does it meas? From raeburn at MIT.EDU Tue Feb 10 21:50:30 2004 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 10 Feb 2004 21:50:30 -0500 Subject: about a stranger message In-Reply-To: <001401c3f014$b66e7410$8c486a8f@bohr> Message-ID: <0DCD8834-5C3D-11D8-972A-000A95909EE2@mit.edu> On Tuesday, Feb 10, 2004, at 15:30 US/Eastern, Ronaldo Giro wrote: > Congratulations > > I have received the following stranger message that you received too: > I would like some help. > What does it means? [... standard "Nigerian" scam email ...] It means our filtering still needs work. We're waiting for a software upgrade on the mailman server. And we should probably also see about filtering the incoming mail, before it hits the bug tracking system. Ken From rt-comment at krbdev.mit.edu Wed Feb 11 06:03:36 2004 From: rt-comment at krbdev.mit.edu (isadays12@netscape.net via RT) Date: Wed, 11 Feb 2004 06:03:36 -0500 (EST) Subject: [krbdev.mit.edu #2227] With all due respcet In-Reply-To: Message-ID: Dear Sir, I should appreciate your surprise while receiving this letter. In any case, I am left with no options but to contact you in this manner. I got your esteemed address from the internet during my search for a reliable Individual/company who can jointly handle strictly confidential transaction with me which involves a reasonable sum of money. Due to the nature of this business transaction, a neutral person like you is preferred. For introductory purpose, I am Isa Foday Sankoh, The son of the late Foday Sankoh, The former chairman and leader of the revolutionary united front (R.U.F) in Sierra Leone. Who was arrested in 1997 by the Ecomog deployed soldiers in Sierra Leone, and was later handed over to the united nation for war crime tribunal for trails for the crime committed by the Rebels in my country during the 10 years of civil war. And he later died in the custody of the united nation before the trail. This front was founded at the height of the 10 years civil war recently ended in my country the republic of Sierra Leone. Following the dead of my father, his accesses of money have been investigated by the government intelligence and the official of the United Nations. As you might have heard how a lot of my father抯 bank account in Switzerland and North America has been frozen. There are recent rumours of my father抯 bank accounts in South Africa and North Korea which my mother Fatou Sankoh denies it. Before the death of my father, he have instructed my mother to go to Johannesburg-south Africa to deposit the sum of US$18,500,000.00 (eighteen million five hundred thousand united state dollars) in a private security company, as a family valuable, when he realized the looming danger from the government and his international inference on him. Since the death of my father, the present government of my country, Alahji Tijan Kabba has maintained a steady policy of clamp-down on his fortune and his legacy, that is the reason why we are seeking for international help to invest this money with somebody neutral. My mother deposited the money in a consignment with a finance company in South Africa and the fund has been transported to their Europe office in the Netherlands due to the rumours of my father抯 account in South Africa. Sir, following the outlined reasons for investigation, I am soliciting for your esteemed organizations confidential assistance to take custody of eighteen million five hundred thousand United States Dollars (US$18,500,000.00) and also to front for my family in the areas of business you consider profitable. These Consignments containing the funds have secretly been concealed and deposited with a Diplomatic Security firm where it can easily be taken delivery of by a recommended beneficiary. The consignment containing the funds will be released to you or your organization by the Security firm based on my recommendations on that note; you will be presented as our partner who will be fronting for my family in any subsequent ventures. It is against this background that I fled the country to the Netherlands where I currently sought for political asylum, which was granted. I am making frantic effort on the best way to handle this money. So I sought advice from an attorney who advised that we must seek for a trustworthy foreign business partner whom can invest this fund in a profitable venture. I have decided to seek foreign assistance, as the Netherlands law prohibits asylum seekers from operating bank account or involve in financial transaction of any kind. Meanwhile, I sincerely ask for your assistance to get this money through your account. I and my family have decided to give 25% to your organization if you are able to help us claim this consignment. And 5% will be use for upsetting all the expenses incurred in the course of concluding this venture and the remaining 70% that will be for my family. Please, I need your entire support and co-operation for the success of this business ventures, your utmost confidentiality and secrecy is highly required, due to my family's present predicament. Also you stand to gain from any investment you might introduce us into after the conclusion of the transfer. Please keep this confidential until we finalize and get this money into your account for security reasons. I am presently in the refugee camp here in the Netherlands under the United Nations and I can be reached by responding to the following email address: isadays12 at zwallet.com isaday12 at netscape.net Regards, Isa Sankoh From rt-comment at krbdev.mit.edu Wed Feb 11 10:23:50 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Wed, 11 Feb 2004 10:23:50 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Sam Hartman wrote: > > Hi, Doug. I applied your patches and they seemed to work. > > However I was unable to reproduce the error you got against a 1.2.x or > 1.3.x KDC. I was able to reproduce this problem against a 1.0.7 KDC. OK. Since I can't get Microsoft code does to send a PA-PAC-REQUEST to a non-MS KDC and the code patch to let MIT kinit send a PA-PAC-REQUEST will not be needed once Todd gets the hotfix for the AD finished it is very unlikely the problem will show up. But I will see if I can do some additional testing when 1.3.2 comes out. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Wed Feb 11 11:30:21 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Wed, 11 Feb 2004 11:30:21 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: >>>>> "Douglas" == Douglas E Engert writes: Douglas> Sam Hartman wrote: >> Hi, Doug. I applied your patches and they seemed to work. >> >> However I was unable to reproduce the error you got against a >> 1.2.x or 1.3.x KDC. I was able to reproduce this problem >> against a 1.0.7 KDC. Douglas> OK. Since I can't get Microsoft code does to send a Douglas> PA-PAC-REQUEST to a non-MS KDC and the code patch to let Douglas> MIT kinit send a PA-PAC-REQUEST will not be needed once Douglas> Todd gets the hotfix for the AD finished it is very Douglas> unlikely the problem will show up. Consider how extensions works. If this problem actually happens it will be a critical problem for MIT trying to implement extensions. From rt-comment at krbdev.mit.edu Wed Feb 11 13:04:44 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Wed, 11 Feb 2004 13:04:44 -0500 (EST) Subject: [krbdev.mit.edu #2228] CVS Commit In-Reply-To: Message-ID: update copyrights To generate a diff of this commit: cvs diff -r1.28 -r1.29 krb5/src/appl/gss-sample/gss-client.c cvs diff -r1.25 -r1.26 krb5/src/appl/gss-sample/gss-misc.c cvs diff -r1.31 -r1.32 krb5/src/appl/gss-sample/gss-server.c cvs diff -r1.8 -r1.9 krb5/src/windows/gss/gss-client.c cvs diff -r1.5 -r1.6 krb5/src/windows/gss/gss-misc.c cvs diff -r1.10 -r1.11 krb5/src/windows/gss/gss.c From rt-comment at krbdev.mit.edu Wed Feb 11 14:00:39 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Wed, 11 Feb 2004 14:00:39 -0500 (EST) Subject: [krbdev.mit.edu #2228] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.25.2.2 -r1.25.2.3 krb5/src/appl/gss-sample/gss-client.c cvs diff -r1.23.2.2 -r1.23.2.3 krb5/src/appl/gss-sample/gss-misc.c cvs diff -r1.30.2.1 -r1.30.2.2 krb5/src/appl/gss-sample/gss-server.c cvs diff -r1.5.20.3 -r1.5.20.4 krb5/src/windows/gss/gss-client.c cvs diff -r1.4.16.1 -r1.4.16.2 krb5/src/windows/gss/gss-misc.c cvs diff -r1.7.2.3 -r1.7.2.4 krb5/src/windows/gss/gss.c From rt-comment at krbdev.mit.edu Wed Feb 11 16:39:37 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Wed, 11 Feb 2004 16:39:37 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Sam Hartman wrote: > > Hi, Doug. I applied your patches and they seemed to work. > > However I was unable to reproduce the error you got against a 1.2.x or > 1.3.x KDC. I was able to reproduce this problem against a 1.0.7 KDC. Using a modified 1.3.2 kinit: kinit -m b17783 at KRB5.ANL.GOV to a 1.2.8 KDC, I can get it to fail if the user principal has the REQUIRE_PRE_AUTH attribute. When it is not set the kinit works. Have you tried this combination? kinit output: orleans.ctd.anl.gov% kinit -m b17783 at KRB5.ANL.GOV kinit(v5): Preauthentication failed while getting initial credentials KDC log: Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: no valid preauth type found: Unknown code 0 Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {1 3 16 23}) 146.137.180.252(88): PREAUTH_FAILED: b17783 at KRB5.ANL.GOV for krbtgt/KRB5.ANL.GOV at KRB5.ANL.GOV, Preauthentication failed -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Wed Feb 11 16:47:38 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Wed, 11 Feb 2004 16:47:38 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: >>>>> "DEEngert" == DEEngert at anl gov via RT writes: DEEngert> to a 1.2.8 KDC, I can get it to fail if the user principal has DEEngert> the REQUIRE_PRE_AUTH attribute. When it is not set the kinit works. DEEngert> Have you tried this combination? DEEngert> kinit output: DEEngert> orleans.ctd.anl.gov% kinit -m b17783 at KRB5.ANL.GOV DEEngert> kinit(v5): Preauthentication failed while getting initial credentials DEEngert> KDC log: DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: no valid preauth type found: Unknown code 0 DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {1 3 16 23}) 146.137.180.252(88): PREAUTH_FAILED: b17783 at KRB5.ANL.GOV for krbtgt/KRB5.ANL.GOV at KRB5.ANL.GOV, Preauthentication failed I think the code is functioning as I expect it to, in this case. After all, you require preauth, and you didn't provide any preauth that it understood. Or are you saying that it should ask for additional preauth rather than returning "preauth failed"? ---Tom From rt-comment at krbdev.mit.edu Wed Feb 11 16:53:00 2004 From: rt-comment at krbdev.mit.edu (Wyllys Ingersoll via RT) Date: Wed, 11 Feb 2004 16:53:00 -0500 (EST) Subject: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2) In-Reply-To: Message-ID: I noticed a problem in the recent 1.3.2 beta code dealing with AES IVs. There seems to be some confusion over what routine is responsible for updating the IVs. For example: Looking at dk_encrypt.c, the ivec->data is updated with the contents of the final block. However, in enc_provider/aes.c the ivec is updated with the contents of block "n-2". So, the ivec data update in krb5int_aes_dk_encrypt (dk_encrypt.c) overrides the ivec data update done in krb5int_aes_encrypt (aes.c). Which one is correct and which should be removed? The same problem exists in the AES decrypt routines: krb5_dk_decrypt_maybe_trunc_hmac overwrites the ivec data written by krb5int_aes_decrypt. -Wyllys Ingersoll From rt-comment at krbdev.mit.edu Wed Feb 11 17:19:03 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Wed, 11 Feb 2004 17:19:03 -0500 (EST) Subject: [krbdev.mit.edu #2230] CVS Commit In-Reply-To: Message-ID: Add missing file: gss-misc.h copied from src/appl/gss-sample To generate a diff of this commit: cvs diff -r1.22 -r1.23 krb5/src/windows/gss/ChangeLog cvs diff -r0 -r1.1 krb5/src/windows/gss/gss-misc.h From rt-comment at krbdev.mit.edu Wed Feb 11 17:51:22 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Wed, 11 Feb 2004 17:51:22 -0500 (EST) Subject: [krbdev.mit.edu #2230] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.19.2.3 -r1.19.2.4 krb5/src/windows/gss/ChangeLog cvs diff -r0 -r1.1.2.1 krb5/src/windows/gss/gss-misc.h From deengert at anl.gov Wed Feb 11 18:30:34 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 11 Feb 2004 17:30:34 -0600 Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata References: Message-ID: <402ABB1A.10E4A29D@anl.gov> Tom Yu via RT wrote: > > >>>>> "DEEngert" == DEEngert at anl gov via RT writes: > > DEEngert> to a 1.2.8 KDC, I can get it to fail if the user principal has > DEEngert> the REQUIRE_PRE_AUTH attribute. When it is not set the kinit works. > > DEEngert> Have you tried this combination? > > DEEngert> kinit output: > > DEEngert> orleans.ctd.anl.gov% kinit -m b17783 at KRB5.ANL.GOV > DEEngert> kinit(v5): Preauthentication failed while getting initial credentials > > DEEngert> KDC log: > > DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: no valid preauth type found: Unknown code 0 > DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {1 3 16 23}) 146.137.180.252(88): PREAUTH_FAILED: b17783 at KRB5.ANL.GOV for krbtgt/KRB5.ANL.GOV at KRB5.ANL.GOV, Preauthentication failed > > I think the code is functioning as I expect it to, in this case. No. > After all, you require preauth, and you didn't provide any preauth > that it understood. Or are you saying that it should ask for > additional preauth rather than returning "preauth failed"? Yes, on the first AS-REQ the client does not know what preauth if any is required. So it justs sends the PA-PAC-REQUEST. It has to do this on the first request, as preauth may not be needed. If preauth is not required the KDC ignores the PA-PAC-REQUEST and it works. If preauth is required, a krb-error SHOULD be sent saying which preauths can be used. I thing the KDC code sees some preauth data, (PA-PAC-REQEUST) but not any it can use, and assumes that this must be a second AS-REQ request and it assumes it has already sent the client a krb-error with the list of preauths. So the KDC sends the failed message, and never sends the list or required preauths. > > ---Tom -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Wed Feb 11 18:30:36 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Wed, 11 Feb 2004 18:30:36 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Tom Yu via RT wrote: > > >>>>> "DEEngert" == DEEngert at anl gov via RT writes: > > DEEngert> to a 1.2.8 KDC, I can get it to fail if the user principal has > DEEngert> the REQUIRE_PRE_AUTH attribute. When it is not set the kinit works. > > DEEngert> Have you tried this combination? > > DEEngert> kinit output: > > DEEngert> orleans.ctd.anl.gov% kinit -m b17783 at KRB5.ANL.GOV > DEEngert> kinit(v5): Preauthentication failed while getting initial credentials > > DEEngert> KDC log: > > DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: no valid preauth type found: Unknown code 0 > DEEngert> Feb 11 15:18:48 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {1 3 16 23}) 146.137.180.252(88): PREAUTH_FAILED: b17783 at KRB5.ANL.GOV for krbtgt/KRB5.ANL.GOV at KRB5.ANL.GOV, Preauthentication failed > > I think the code is functioning as I expect it to, in this case. No. > After all, you require preauth, and you didn't provide any preauth > that it understood. Or are you saying that it should ask for > additional preauth rather than returning "preauth failed"? Yes, on the first AS-REQ the client does not know what preauth if any is required. So it justs sends the PA-PAC-REQUEST. It has to do this on the first request, as preauth may not be needed. If preauth is not required the KDC ignores the PA-PAC-REQUEST and it works. If preauth is required, a krb-error SHOULD be sent saying which preauths can be used. I thing the KDC code sees some preauth data, (PA-PAC-REQEUST) but not any it can use, and assumes that this must be a second AS-REQ request and it assumes it has already sent the client a krb-error with the list of preauths. So the KDC sends the failed message, and never sends the list or required preauths. > > ---Tom -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Wed Feb 11 19:02:55 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Wed, 11 Feb 2004 19:02:55 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: >>>>> "DEEngert" == DEEngert at anl gov via RT writes: DEEngert> Tom Yu via RT wrote: >> I think the code is functioning as I expect it to, in this case. DEEngert> No. Let me rephrase: I think the code is functioning the way it was intended to function when it was written. Whether that behavior is correct in this case is debatable. >> After all, you require preauth, and you didn't provide any preauth >> that it understood. Or are you saying that it should ask for >> additional preauth rather than returning "preauth failed"? DEEngert> Yes, on the first AS-REQ the client does not know what DEEngert> preauth if any is required. So it justs sends the DEEngert> PA-PAC-REQUEST. It has to do this on the first request, as DEEngert> preauth may not be needed. DEEngert> If preauth is not required the KDC ignores the DEEngert> PA-PAC-REQUEST and it works. DEEngert> If preauth is required, a krb-error SHOULD be sent saying DEEngert> which preauths can be used. DEEngert> I thing the KDC code sees some preauth data, DEEngert> (PA-PAC-REQEUST) but not any it can use, and assumes that DEEngert> this must be a second AS-REQ request and it assumes it has DEEngert> already sent the client a krb-error with the list of DEEngert> preauths. This would appear to be the intent. The problem is, if the KDC sees any AS-REQ containing padata, the most safe assumption to make is that it is a "second" AS-REQ, i.e., one replying to a KRB-ERROR asking for additional preauth. Consider what happens when a client sends an AS-REQ containing padata that the KDC do not understand. KDC sends KRB-ERROR with list of supported padata. Client is broken in a way that causes it to send a mostly identical AS-REQ, lacking the padata that the KDC require. KDC again sends KRB-ERROR with list of supported padata. Looping ensues. The main problem being that KRB-ERROR requesting additional preauth isn't a hard failure, and the other errors are. I'm not sure of the best way to get around this problem, without somehow requiring the KDC to keep some state which it currently does not. ---Tom From rt-comment at krbdev.mit.edu Wed Feb 11 19:44:38 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Wed, 11 Feb 2004 19:44:38 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: >>>>> "Douglas" == Douglas E Engert writes: Douglas> If preauth is required, a krb-error SHOULD be sent saying Douglas> which preauths can be used. That's not how Kerberos works. Se section 2 of draft-ietf-krb-wg-preauth-framework-00.txt for a discussion. From deengert at anl.gov Wed Feb 11 20:29:59 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 11 Feb 2004 19:29:59 -0600 Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata References: Message-ID: <402AD717.76D32F8B@anl.gov> Tom Yu via RT wrote: > > >>>>> "DEEngert" == DEEngert at anl gov via RT writes: > > DEEngert> Tom Yu via RT wrote: > > >> I think the code is functioning as I expect it to, in this case. > > DEEngert> No. > > Let me rephrase: I think the code is functioning the way it was > intended to function when it was written. Whether that behavior is > correct in this case is debatable. OK, I agree with that. > > >> After all, you require preauth, and you didn't provide any preauth > >> that it understood. Or are you saying that it should ask for > >> additional preauth rather than returning "preauth failed"? > > DEEngert> Yes, on the first AS-REQ the client does not know what > DEEngert> preauth if any is required. So it justs sends the > DEEngert> PA-PAC-REQUEST. It has to do this on the first request, as > DEEngert> preauth may not be needed. > > DEEngert> If preauth is not required the KDC ignores the > DEEngert> PA-PAC-REQUEST and it works. > > DEEngert> If preauth is required, a krb-error SHOULD be sent saying > DEEngert> which preauths can be used. > > DEEngert> I thing the KDC code sees some preauth data, > DEEngert> (PA-PAC-REQEUST) but not any it can use, and assumes that > DEEngert> this must be a second AS-REQ request and it assumes it has > DEEngert> already sent the client a krb-error with the list of > DEEngert> preauths. > > This would appear to be the intent. The problem is, if the KDC sees > any AS-REQ containing padata, the most safe assumption to make is that > it is a "second" AS-REQ, i.e., one replying to a KRB-ERROR asking for > additional preauth. > > Consider what happens when a client sends an AS-REQ containing padata > that the KDC do not understand. KDC sends KRB-ERROR with list of > supported padata. Client is broken in a way that causes it to send > a mostly identical AS-REQ, lacking the padata that the KDC require. > KDC again sends KRB-ERROR with list of supported padata. Looping > ensues. The main problem being that KRB-ERROR requesting additional > preauth isn't a hard failure, and the other errors are. > > I'm not sure of the best way to get around this problem, without > somehow requiring the KDC to keep some state which it currently does > not. The difference is that the PA-PAC-REQUEST is really a flag, not a preauth. So maybe the KDC needs to recognize flag type entries (there may be others) and not make the assumption that this is a second AS-REQ. But this requires knowledge of all the possible pa-data types or at least the flag types. Is this an issue for Sam's draft-ietf-krb-wg-preauth-framework-00.txt? > > ---Tom -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Wed Feb 11 20:30:00 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Wed, 11 Feb 2004 20:30:00 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: Tom Yu via RT wrote: > > >>>>> "DEEngert" == DEEngert at anl gov via RT writes: > > DEEngert> Tom Yu via RT wrote: > > >> I think the code is functioning as I expect it to, in this case. > > DEEngert> No. > > Let me rephrase: I think the code is functioning the way it was > intended to function when it was written. Whether that behavior is > correct in this case is debatable. OK, I agree with that. > > >> After all, you require preauth, and you didn't provide any preauth > >> that it understood. Or are you saying that it should ask for > >> additional preauth rather than returning "preauth failed"? > > DEEngert> Yes, on the first AS-REQ the client does not know what > DEEngert> preauth if any is required. So it justs sends the > DEEngert> PA-PAC-REQUEST. It has to do this on the first request, as > DEEngert> preauth may not be needed. > > DEEngert> If preauth is not required the KDC ignores the > DEEngert> PA-PAC-REQUEST and it works. > > DEEngert> If preauth is required, a krb-error SHOULD be sent saying > DEEngert> which preauths can be used. > > DEEngert> I thing the KDC code sees some preauth data, > DEEngert> (PA-PAC-REQEUST) but not any it can use, and assumes that > DEEngert> this must be a second AS-REQ request and it assumes it has > DEEngert> already sent the client a krb-error with the list of > DEEngert> preauths. > > This would appear to be the intent. The problem is, if the KDC sees > any AS-REQ containing padata, the most safe assumption to make is that > it is a "second" AS-REQ, i.e., one replying to a KRB-ERROR asking for > additional preauth. > > Consider what happens when a client sends an AS-REQ containing padata > that the KDC do not understand. KDC sends KRB-ERROR with list of > supported padata. Client is broken in a way that causes it to send > a mostly identical AS-REQ, lacking the padata that the KDC require. > KDC again sends KRB-ERROR with list of supported padata. Looping > ensues. The main problem being that KRB-ERROR requesting additional > preauth isn't a hard failure, and the other errors are. > > I'm not sure of the best way to get around this problem, without > somehow requiring the KDC to keep some state which it currently does > not. The difference is that the PA-PAC-REQUEST is really a flag, not a preauth. So maybe the KDC needs to recognize flag type entries (there may be others) and not make the assumption that this is a second AS-REQ. But this requires knowledge of all the possible pa-data types or at least the flag types. Is this an issue for Sam's draft-ietf-krb-wg-preauth-framework-00.txt? > > ---Tom -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Wed Feb 11 20:32:52 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Wed, 11 Feb 2004 20:32:52 -0500 (EST) Subject: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2) In-Reply-To: Message-ID: Ugh. Good catch, thanks. I thought we were doing better about doing it at the lower level. *sigh* The DK code is going to have to stop updating the IV, but that means the 3DES code is probably going to have to start updating it, if it's not doing so already. Ken From raeburn at MIT.EDU Wed Feb 11 20:32:49 2004 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 11 Feb 2004 20:32:49 -0500 Subject: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2) In-Reply-To: (Wyllys Ingersoll via's message of "Wed, 11 Feb 2004 16:53:00 -0500 (EST)") References: Message-ID: Ugh. Good catch, thanks. I thought we were doing better about doing it at the lower level. *sigh* The DK code is going to have to stop updating the IV, but that means the 3DES code is probably going to have to start updating it, if it's not doing so already. Ken From rt-comment at krbdev.mit.edu Thu Feb 12 04:54:01 2004 From: rt-comment at krbdev.mit.edu (webnetcn@tom.com via RT) Date: Thu, 12 Feb 2004 04:54:01 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232231=5D_=BA=E3=CB=D9?= =?iso-8859-1?q?=B4=EF=A3=AC=D0=C2=B4=BA=CC=D8=BC=DB=BF?= =?iso-8859-1?q?=D5=BC=E4=B5=F7=D5=FB=CD=A8=D6=AA=A3=A1_?= In-Reply-To: Message-ID: 尊敬的老客户： 　　您好！ 　　新的一年到来，首先恒速达祝您新年快乐、猴年吉祥！ 　　 　　恒速达能有今天离不开您的支持与厚爱，为回报老客户我们与　DELL电脑合作，选用顶 级品牌服务器，特别奉送！另有需要《速达财务软件》的客户欢迎与我们联系。 从2003年在我司申请DELL服务器空间的优惠政策调整如下： A、400M空间（200M　WEB，支持ASP、CGI、ACCESS、论坛） + 送1个100M　MAIL　特价200元； B、600M空间（300M　WEB，支持ASP、CGI、ACCESS、论坛） + 送1个100M　MAIL　特价250元； C、800M空间（400M　WEB，支持ASP、CGI、ACCESS、论坛） + 送1个100M　MAIL　特价350元； 特价空间加　60元送国际顶级域名，加　180元送国内域名；另网站建设全面优惠。 　　诚信为本，我们承诺　24小时为您服务，同时支持QQ24小时在线咨询！ 　　同时也欢迎您加入我们代理商行列来，我们将给您更加优惠的服务！ 24小时热线：0592-- 6026652 / 5682852 / 5682825 　　　　传真：0592--5654223 　　 邮件： dns88 at tom.com QQ在线： 40327558 / 33925614 祝您好运天天有、幸运常伴随、猴年万事如意! *****此邮件为商业信函，如果给您造成不便请原谅，谢谢！ This mail is a business letter .If you are uninterested in this ,please delete it ; If you do not hope to receive this mail again ,please go to dns88 at tom.com , fill ni your mail address ,and we will filter it out of our mail list! 　 Thank your! 　　　　　　　　　　　　　　　 ******　祝您好运天天有、幸运常伴随!!! 　　　　　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　恒速达网络 From rt-comment at krbdev.mit.edu Thu Feb 12 08:02:05 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Thu, 12 Feb 2004 08:02:05 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232?= =?iso-8859-1?q?232=5D_=D7=EE=BD=FC=BC=B8=CB=AE=CC=D8=BC=DB_?= In-Reply-To: Message-ID: ********FROM：王斌斌 TEL：86-20-87567052 FAX：86-20-87561768 ******黄埔起运IRISL特价 DUBAI：USD1050/2000/2050（限重21.8/25.6 ） BANDAR ABBAS：USD1250/2450/2500（限重21.8/25.6 ） 备注：1、此特价仅适用于以下两水船： IRAN KERMAN V.PCL-353 2004年2月13日头程，2004年2月15日大船 IRAN ISFAHAN V.PCL-354 2004年2月18日头程，2004年2月20日大船 2、此运价已包括ORC、BAF、THC、TARS、GRI、RR 未包括DOC（USD15/票）或TELX（RMB220/票） 3、码头:嘉利、旧港大码头、乌冲 超重加收USD100/柜。 ******深圳---欧基 C-SHIPPING LINE下周运价(FEB ２１，２２，２３ CLOSING) (运价大幅下调，望各位多多走货大力支持). 欧洲基本港：FELIXSTOWE 22DAYS/ HAMBURG 24DAYS ROTTERDAM 26DAYS/ ANTWERP 27DAYS USD1１80/2330/2500 + ORC + BAF( CHIWAN/YANTIAN ） 地西同价大票货可逐单申请运价！！ /Fos/Livorno/Malta) 地东:piraers thessaloniki,istanbul,izmir,mersin,gemlik,limassol,port said,alexandria,lattakia,beirut USD126０/2480/27０0+ORC+BAF+DOC 大票货可逐单申请运价！！ ******深圳----西非基港 目的港:TEMA/LAGOS/APAPA/COTONOU/LOME/ABIDJAN 船公司:CMA(法国达飞) 海运价:USD1860/3700/3800+DOC 截关期:蛇口2月17日截关,19日开直航大船.(隔10天一班船) 备 注:ABIDJAN另加战险费USD74/148/148 ******青岛----欧基 CHINA SHIPPING：USD1410/2680/2800 NORASIA：USD1430/2720/2990 MSC：USD1450/2720/2930 COSCO：USD1430/2750/2960 ******上海起运 以星（ZIM） 每周六，直航，17天到 DUBAI/KARACHI 1.SHANGHAI-DUBAI(PORT RASHID,JEBEL ALI，KARACHI） USD 910/20'GP, USD 1680/40'GP, USD 1800/40'HQ 2. SHANGHAI-----COLOMBO USD 760/20'GP, USD 1380/40'GP, USD 1500/40'HQ 3. SHANGHAI-----CHITTAGONG USD 860/20'GP, USD 1580/40'GP, USD 1700/40'HQ 4. SHANGHAI-----NHAVA SHEVA USD 760/20'GP, USD 1380/40'GP, USD 1500/40'HQ 5. SHANGHAI-----TUTICORIN USD 1010/20'GP, USD 1890/40'GP, USD 2010/40'HQ ********FROM：王斌斌 TEL：86-20-87567052 FAX：86-20-87561768 ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Thu Feb 12 08:14:57 2004 From: rt-comment at krbdev.mit.edu (Wyllys Ingersoll via RT) Date: Thu, 12 Feb 2004 08:14:57 -0500 (EST) Subject: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2) In-Reply-To: Message-ID: On Wed, 2004-02-11 at 20:32, Ken Raeburn wrote: > Ugh. Good catch, thanks. I thought we were doing better about doing > it at the lower level. *sigh* > > The DK code is going to have to stop updating the IV, but that means > the 3DES code is probably going to have to start updating it, if it's > not doing so already. 3DES does not appear to have the same problem. One (admittedly ugly) fix would be to have dk_encrypt/decrypt check the enctype before updating the IV and only do it for 3DES. For AES, is it correct to use the final block as the next IV (currently being done in dk_encrypt/decrypt) or the n-2 block (which is what happens in aes.c) ? Because CTS is an odd mode that swaps the final 2 blocks, it makes choosing the IV a little trickier. Why was CTS chosen again??? :) -Wyllys > > Ken > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs From wyllys.ingersoll at sun.com Thu Feb 12 08:11:11 2004 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Thu, 12 Feb 2004 08:11:11 -0500 Subject: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2) In-Reply-To: References: Message-ID: <1076591470.7268.29.camel@pebblebeach.wki.test.net> On Wed, 2004-02-11 at 20:32, Ken Raeburn wrote: > Ugh. Good catch, thanks. I thought we were doing better about doing > it at the lower level. *sigh* > > The DK code is going to have to stop updating the IV, but that means > the 3DES code is probably going to have to start updating it, if it's > not doing so already. 3DES does not appear to have the same problem. One (admittedly ugly) fix would be to have dk_encrypt/decrypt check the enctype before updating the IV and only do it for 3DES. For AES, is it correct to use the final block as the next IV (currently being done in dk_encrypt/decrypt) or the n-2 block (which is what happens in aes.c) ? Because CTS is an odd mode that swaps the final 2 blocks, it makes choosing the IV a little trickier. Why was CTS chosen again??? :) -Wyllys > > Ken > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs From rt-comment at krbdev.mit.edu Thu Feb 12 08:53:03 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Thu, 12 Feb 2004 08:53:03 -0500 (EST) Subject: [krbdev.mit.edu #2233] CVS Commit In-Reply-To: Message-ID: 2004-02-12 Jeffrey Altman * Fix libpath for krbcc32.lib (only affects KRB5_KFW_COMPILE builds) To generate a diff of this commit: cvs diff -r1.23 -r1.24 krb5/src/windows/gss/ChangeLog cvs diff -r1.14 -r1.15 krb5/src/windows/gss/Makefile.in From rt-comment at krbdev.mit.edu Thu Feb 12 13:17:34 2004 From: rt-comment at krbdev.mit.edu (Wyllys Ingersoll via RT) Date: Thu, 12 Feb 2004 13:17:34 -0500 (EST) Subject: [krbdev.mit.edu #2234] kdc_util.c bug - validate_tgs_request clears all kdc_options In-Reply-To: Message-ID: The new code in kdc_util.c request->kdc_options &= ~(TGS_OPTIONS_HANDLED); Actually causes clears the kdc_options field of all handled options, which (in most cases) zeros the field. This is probably not intended... To properly disable unrecognized flags, I think you need to do something like this: badflags = (request->kdc_options & ~(TGS_OPTIONS_HANDLED)); request->kdc_options &= ~badflags; -Wyllys -- Wyllys Ingersoll From rt-comment at krbdev.mit.edu Thu Feb 12 13:28:06 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Thu, 12 Feb 2004 13:28:06 -0500 (EST) Subject: [krbdev.mit.edu #1793] CVS Commit In-Reply-To: Message-ID: Implement hack for faking up _RLD_ROOT with a shadow of the directory tree up to the installed "lib" directory. This helps with running tests on Tru64 and Irix. To generate a diff of this commit: cvs diff -r5.191 -r5.192 krb5/src/config/ChangeLog cvs diff -r1.92 -r1.93 krb5/src/config/pre.in cvs diff -r5.14 -r5.15 krb5/src/config/shlib.conf cvs diff -r1.48 -r1.49 krb5/src/kadmin/testing/scripts/ChangeLog cvs diff -r1.19 -r1.20 krb5/src/kadmin/testing/scripts/env-setup.shin cvs diff -r1.128 -r1.129 krb5/src/util/ChangeLog cvs diff -r1.38 -r1.39 krb5/src/util/Makefile.in From jaltman at columbia.edu Thu Feb 12 13:31:00 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Thu, 12 Feb 2004 13:31:00 -0500 Subject: [krbdev.mit.edu #2234] kdc_util.c bug - validate_tgs_request clears all kdc_options In-Reply-To: References: Message-ID: <402BC664.8030103@columbia.edu> Wyllys Ingersoll via RT wrote: >The new code in kdc_util.c > > request->kdc_options &= ~(TGS_OPTIONS_HANDLED); > >Actually causes clears the kdc_options field of all >handled options, which (in most cases) zeros the field. >This is probably not intended... > >To properly disable unrecognized flags, I think you need >to do something like this: > >badflags = (request->kdc_options & ~(TGS_OPTIONS_HANDLED)); >request->kdc_options &= ~badflags; > >-Wyllys > > Shouldn't this simply be? request->kdc_options &= TGS_OPTIONS_HANDLED; -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040212/5b73432c/attachment.htm From rt-comment at krbdev.mit.edu Thu Feb 12 13:30:40 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Thu, 12 Feb 2004 13:30:40 -0500 (EST) Subject: [krbdev.mit.edu #2234] kdc_util.c bug - validate_tgs_request clears all kdc_options In-Reply-To: Message-ID: Wyllys Ingersoll via RT wrote: >The new code in kdc_util.c > > request->kdc_options &= ~(TGS_OPTIONS_HANDLED); > >Actually causes clears the kdc_options field of all >handled options, which (in most cases) zeros the field. >This is probably not intended... > >To properly disable unrecognized flags, I think you need >to do something like this: > >badflags = (request->kdc_options & ~(TGS_OPTIONS_HANDLED)); >request->kdc_options &= ~badflags; > >-Wyllys > > Shouldn't this simply be? request->kdc_options &= TGS_OPTIONS_HANDLED; From wyllys.ingersoll at sun.com Thu Feb 12 14:04:04 2004 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Thu, 12 Feb 2004 14:04:04 -0500 Subject: [krbdev.mit.edu #2234] kdc_util.c bug - validate_tgs_request clears all kdc_options In-Reply-To: References: Message-ID: <1076612644.7268.50.camel@pebblebeach.wki.test.net> On Thu, 2004-02-12 at 13:30, ""Jeffrey Altman [Kermit Project]" via RT" wrote: > Wyllys Ingersoll via RT wrote: > > >The new code in kdc_util.c > > > > request->kdc_options &= ~(TGS_OPTIONS_HANDLED); > > > >Actually causes clears the kdc_options field of all > >handled options, which (in most cases) zeros the field. > >This is probably not intended... > > > >To properly disable unrecognized flags, I think you need > >to do something like this: > > > >badflags = (request->kdc_options & ~(TGS_OPTIONS_HANDLED)); > >request->kdc_options &= ~badflags; > > > >-Wyllys > > > > > Shouldn't this simply be? > > request->kdc_options &= TGS_OPTIONS_HANDLED; er, yup. That'll work too, I was thinking in reverse :) Though, the original suggestion might be OK if you wanted to log a message to indicate what unsupported flags were received. -Wyllys From rt-comment at krbdev.mit.edu Thu Feb 12 14:08:20 2004 From: rt-comment at krbdev.mit.edu (Wyllys Ingersoll via RT) Date: Thu, 12 Feb 2004 14:08:20 -0500 (EST) Subject: [krbdev.mit.edu #2234] kdc_util.c bug - validate_tgs_request clears all kdc_options In-Reply-To: Message-ID: On Thu, 2004-02-12 at 13:30, ""Jeffrey Altman [Kermit Project]" via RT" wrote: > Wyllys Ingersoll via RT wrote: > > >The new code in kdc_util.c > > > > request->kdc_options &= ~(TGS_OPTIONS_HANDLED); > > > >Actually causes clears the kdc_options field of all > >handled options, which (in most cases) zeros the field. > >This is probably not intended... > > > >To properly disable unrecognized flags, I think you need > >to do something like this: > > > >badflags = (request->kdc_options & ~(TGS_OPTIONS_HANDLED)); > >request->kdc_options &= ~badflags; > > > >-Wyllys > > > > > Shouldn't this simply be? > > request->kdc_options &= TGS_OPTIONS_HANDLED; er, yup. That'll work too, I was thinking in reverse :) Though, the original suggestion might be OK if you wanted to log a message to indicate what unsupported flags were received. -Wyllys From rt-comment at krbdev.mit.edu Thu Feb 12 15:00:34 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Thu, 12 Feb 2004 15:00:34 -0500 (EST) Subject: [krbdev.mit.edu #2229] IV problem with AES (krb5-1.3.2 beta2) In-Reply-To: Message-ID: On Thursday, Feb 12, 2004, at 08:14 US/Eastern, Wyllys Ingersoll via RT wrote: > 3DES does not appear to have the same problem. One (admittedly ugly) > fix would be to have dk_encrypt/decrypt check the enctype before > updating the IV and only do it for 3DES. Right on both counts ... it is a simple fix, and it's ugly. :-) > For AES, is it correct to use the final block as the next IV > (currently being done in dk_encrypt/decrypt) or the n-2 block > (which is what happens in aes.c) ? Because CTS is an odd mode > that swaps the final 2 blocks, it makes choosing the IV a little > trickier. Having the last block be incomplete makes things even trickier if you use it. The updated drafts getting submitted clarify that for AES-CTS it's the next to last block (the one that would be the final block in "normal" CBC if it were not for the swap). > Why was CTS chosen again??? :) Dropping the padding, especially for AES with its larger block size. And to widen the spec and exercise the code so that we can deal with something that isn't plain old CBC with padding, which clearly is giving us a little trouble... Ken From rt-comment at krbdev.mit.edu Thu Feb 12 15:37:54 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Thu, 12 Feb 2004 15:37:54 -0500 (EST) Subject: [krbdev.mit.edu #2233] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.19.2.4 -r1.19.2.5 krb5/src/windows/gss/ChangeLog cvs diff -r1.12.2.2 -r1.12.2.3 krb5/src/windows/gss/Makefile.in From rt-comment at krbdev.mit.edu Thu Feb 12 15:55:22 2004 From: rt-comment at krbdev.mit.edu ( Zane Salas via RT) Date: Thu, 12 Feb 2004 15:55:22 -0500 (EST) Subject: [krbdev.mit.edu #2235] Google adwords - A license to print money In-Reply-To: Message-ID: zdfpsiqlq tmmhpyqtklarirlo 0

 

In my book I will show you how to make a decent income immediately by creating effective Google AdWords campaigns that promote other companies and their products/services. You will be paid each time your ad generates a sale or sign up!

I don't want any more emails

ja rlu rtzn sqqeepzncrfpnhfxny From rt-comment at krbdev.mit.edu Thu Feb 12 22:19:37 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Thu, 12 Feb 2004 22:19:37 -0500 (EST) Subject: [krbdev.mit.edu #2236] CVS Commit In-Reply-To: Message-ID: Implement gross hack to use priocntl to work around the Solaris 9 pty-close bug. Run expect at a higher class "FX" priority than spawned processes, which run at a lower class "FX" priority. "make check" needs to start from a process which has FX priority >= 30 and FX priority limit >= 30. Thanks to Bill Sommerfeld for the hints. To generate a diff of this commit: cvs diff -r5.420 -r5.421 krb5/src/ChangeLog cvs diff -r1.267 -r1.268 krb5/src/aclocal.m4 cvs diff -r1.73 -r1.74 krb5/src/configure.in cvs diff -r5.192 -r5.193 krb5/src/config/ChangeLog cvs diff -r5.15 -r5.16 krb5/src/config/shlib.conf cvs diff -r1.93 -r1.94 krb5/src/lib/kadm5/ChangeLog cvs diff -r1.12 -r1.13 krb5/src/lib/kadm5/configure.in cvs diff -r1.58 -r1.59 krb5/src/lib/kadm5/unit-test/ChangeLog cvs diff -r1.21 -r1.22 krb5/src/lib/kadm5/unit-test/Makefile.in cvs diff -r1.19 -r1.20 krb5/src/lib/kadm5/unit-test/config/unix.exp cvs diff -r1.53 -r1.54 krb5/src/lib/rpc/unit-test/ChangeLog cvs diff -r1.25 -r1.26 krb5/src/lib/rpc/unit-test/Makefile.in cvs diff -r1.10 -r1.11 krb5/src/lib/rpc/unit-test/configure.in cvs diff -r1.5 -r1.6 krb5/src/lib/rpc/unit-test/config/unix.exp cvs diff -r5.39 -r5.40 krb5/src/tests/ChangeLog cvs diff -r5.21 -r5.22 krb5/src/tests/configure.in cvs diff -r1.27 -r1.28 krb5/src/tests/dejagnu/ChangeLog cvs diff -r1.24 -r1.25 krb5/src/tests/dejagnu/Makefile.in cvs diff -r1.84 -r1.85 krb5/src/tests/dejagnu/config/ChangeLog cvs diff -r1.88 -r1.89 krb5/src/tests/dejagnu/config/default.exp cvs diff -r1.129 -r1.130 krb5/src/util/ChangeLog cvs diff -r1.39 -r1.40 krb5/src/util/Makefile.in From rt-comment at krbdev.mit.edu Thu Feb 12 23:21:01 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 12 Feb 2004 23:21:01 -0500 (EST) Subject: [krbdev.mit.edu #2234] CVS Commit In-Reply-To: Message-ID: Fix logic error. To generate a diff of this commit: cvs diff -r5.269 -r5.270 krb5/src/kdc/ChangeLog cvs diff -r5.110 -r5.111 krb5/src/kdc/kdc_util.c From rt-comment at krbdev.mit.edu Fri Feb 13 07:08:21 2004 From: rt-comment at krbdev.mit.edu (newtonpost@infor.com via RT) Date: Fri, 13 Feb 2004 07:08:21 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232239=5D_=B6=7D=BE=C7=C5?= =?iso-8859-1?q?o!!=C5=FD=A7=DA=A8=D3=B1=D0=B1z=B3?= =?iso-8859-1?q?=CC=A6n=AA=BA=BE=C7=B2=DF=A4=E8=A6=A1_?= In-Reply-To: Message-ID: 箉礘翴厨
                                               

930209腹  材7戳    

  秨厩舘穝厩戳穝辨()
眤狟ね琌竒非称穝厩策ㄓ㎡セ 秅肈いま癬讽癹臫籔癚阶眖⒉°⒋烦–顶琿常惠秨祇ㄤΘ剪硂琌狟ねゲ厩ゲ揭祘琵и砛狟ねゼㄓ腊絪麓冠

                           *冈灿戈*

  セ紋"セ祇︽"疭羭快｢よ癳 ｣笆笆93.2.29ゎ秘珇Τ癳Чゎ叫鲸硉璹綷!!             *玡戳眔贱虫*

   玡戳戈癟

』  930202戳-矗ど厩策Θ剪  *礘翴厨疭跋*

﹎    
筿秎ン獺絚 
ネら ﹁じるら
硄癟
產筿杠
︽笆筿杠
盉猵
產い琌Τ

*и璶璹綷筿厨*

       

い瓣瓣產瞶馒粁

 馒粁 ぶ芖 箉21

冈灿ざ残&璹潦   

冈灿ざ残&璹潦 冈灿ざ残&璹潦 冈灿ざ残&璹潦

眃>>临Τ纔借馒粁叫硈挡矪秆冈灿ず甧

呼ね狝叭獺絚   狝盡絬02-29740384  肚痷02-29740474

Copyright 2003© http://newton.why.to 舦┮Τ
From rt-comment at krbdev.mit.edu Fri Feb 13 12:22:41 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 13 Feb 2004 12:22:41 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when used by OpenSSH-snap-20040212 In-Reply-To: Message-ID: krb5-1.3.2-beta3: krb5-config --cflag gssapi returns -I${includedir} which in my case is -I/krb5/include But the gssapi.h is in /krb5/include/gssapi Most gssapi programs use #include So the gssapi.h is not found. Previous versions of OpenSSH with Simon's modifications did not use the krb5-config but added -I /krb5/include/gssapi With openssh-snap-20040212 it now calls krb5-config --cflag gssapi Possible solutions: (1) krb5-config --cflag gssapi could return -I/${includedir} -I/${includedir}/gssapi (2) Programs could use #include (3) The gssapi.h could be installed in ${includedir} (4) Install could do a ln -s gssapi/gssapi.h gssapi.h in the ${includedir} I suggest (1) as the others could impact other applications or Kerberos implementations. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman at columbia.edu Fri Feb 13 12:29:01 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 13 Feb 2004 12:29:01 -0500 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when used by OpenSSH-snap-20040212 In-Reply-To: References: Message-ID: <402D095D.8070007@columbia.edu> DEEngert at anl.gov via RT wrote: >krb5-1.3.2-beta3: >krb5-config --cflag gssapi >returns -I${includedir} which in my case is -I/krb5/include > >But the gssapi.h is in /krb5/include/gssapi >Most gssapi programs use #include >So the gssapi.h is not found. > I truly believe it should be filed as a bug against those applications. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/0c0803ed/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3427 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/0c0803ed/attachment.bin From rt-comment at krbdev.mit.edu Fri Feb 13 12:28:35 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Fri, 13 Feb 2004 12:28:35 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when used by OpenSSH-snap-20040212 In-Reply-To: Message-ID: From deengert at anl.gov Fri Feb 13 14:29:13 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 13 Feb 2004 13:29:13 -0600 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedby OpenSSH-snap-20040212 References: <402D095D.8070007@columbia.edu> Message-ID: <402D2589.F5B87F8B@anl.gov> > Jeffrey Altman wrote: > > DEEngert at anl.gov via RT wrote: > > > krb5-1.3.2-beta3: > > krb5-config --cflag gssapi > > returns -I${includedir} which in my case is -I/krb5/include > > > > But the gssapi.h is in /krb5/include/gssapi > > Most gssapi programs use #include > > So the gssapi.h is not found. > > > I truly believe it should be filed as a bug against those applications. I would still say if MIT wants people to use the krb5-config then the gssapi.h should be accessable from the list of include directories returned by the krb5-config --cflag gssapi It is not clear where a generic application should find the gssapi.h. RFC-2744 does not say where the gssapi.h should be, just: "C-language GSS-API implementations should include a copy of the following header-file." Looking at the Heimdal source, Is looks like they install gssapi.h in the include directory, not a subdirectory of it. On Solaris, there is a /usr/include/gssapi/gssapi.h On one of our HPs, there is a link /usr/include/gssapi.h -> /usr/include/gssapi/gssapi.h > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 13 14:29:15 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 13 Feb 2004 14:29:15 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedby OpenSSH-snap-20040212 In-Reply-To: Message-ID: > Jeffrey Altman wrote: > > DEEngert at anl.gov via RT wrote: > > > krb5-1.3.2-beta3: > > krb5-config --cflag gssapi > > returns -I${includedir} which in my case is -I/krb5/include > > > > But the gssapi.h is in /krb5/include/gssapi > > Most gssapi programs use #include > > So the gssapi.h is not found. > > > I truly believe it should be filed as a bug against those applications. I would still say if MIT wants people to use the krb5-config then the gssapi.h should be accessable from the list of include directories returned by the krb5-config --cflag gssapi It is not clear where a generic application should find the gssapi.h. RFC-2744 does not say where the gssapi.h should be, just: "C-language GSS-API implementations should include a copy of the following header-file." Looking at the Heimdal source, Is looks like they install gssapi.h in the include directory, not a subdirectory of it. On Solaris, there is a /usr/include/gssapi/gssapi.h On one of our HPs, there is a link /usr/include/gssapi.h -> /usr/include/gssapi/gssapi.h > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman at columbia.edu Fri Feb 13 14:37:46 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 13 Feb 2004 14:37:46 -0500 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedby OpenSSH-snap-20040212 In-Reply-To: <402D2589.F5B87F8B@anl.gov> References: <402D095D.8070007@columbia.edu> <402D2589.F5B87F8B@anl.gov> Message-ID: <402D278A.5050308@columbia.edu> Douglas E. Engert wrote: >On one of our HPs, there is a link >/usr/include/gssapi.h -> /usr/include/gssapi/gssapi.h > I would be willing to consider installing a link like on HP-UX. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/074d70a8/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3427 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/074d70a8/attachment.bin From rt-comment at krbdev.mit.edu Fri Feb 13 14:37:25 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Fri, 13 Feb 2004 14:37:25 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedby OpenSSH-snap-20040212 In-Reply-To: Message-ID: From deengert at anl.gov Fri Feb 13 14:41:10 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 13 Feb 2004 13:41:10 -0600 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedbyOpenSSH-snap-20040212 References: <402D278A.5050308@columbia.edu> Message-ID: <402D2856.F9A134BA@anl.gov> > Jeffrey Altman wrote: > > Douglas E. Engert wrote: > > > On one of our HPs, there is a link > > /usr/include/gssapi.h -> /usr/include/gssapi/gssapi.h > > > I would be willing to consider installing a link like on HP-UX. OK, that would work. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 13 14:41:11 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 13 Feb 2004 14:41:11 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: > Jeffrey Altman wrote: > > Douglas E. Engert wrote: > > > On one of our HPs, there is a link > > /usr/include/gssapi.h -> /usr/include/gssapi/gssapi.h > > > I would be willing to consider installing a link like on HP-UX. OK, that would work. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert at anl.gov Fri Feb 13 14:47:56 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 13 Feb 2004 13:47:56 -0600 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedbyOpenSSH-snap-20040212 References: <402D278A.5050308@columbia.edu> Message-ID: <402D29EC.14C464D1@anl.gov> > Jeffrey Altman wrote: > > Douglas E. Engert wrote: > > > On one of our HPs, there is a link > > /usr/include/gssapi.h -> /usr/include/gssapi/gssapi.h > > > I would be willing to consider installing a link like on HP-UX. That would work, but wait till Simon sees the note. That might not be till Monday. He is in Scotland. Since Hiemdal also has a krb5-config, maybe you want to coordinate with them too. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 13 14:47:59 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 13 Feb 2004 14:47:59 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi when usedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: > Jeffrey Altman wrote: > > Douglas E. Engert wrote: > > > On one of our HPs, there is a link > > /usr/include/gssapi.h -> /usr/include/gssapi/gssapi.h > > > I would be willing to consider installing a link like on HP-UX. That would work, but wait till Simon sees the note. That might not be till Monday. He is in Scotland. Since Hiemdal also has a krb5-config, maybe you want to coordinate with them too. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman at columbia.edu Fri Feb 13 15:49:18 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 13 Feb 2004 15:49:18 -0500 Subject: [krbdev.mit.edu #2240] testing In-Reply-To: <402D29EC.14C464D1@anl.gov> References: <402D095D.8070007@columbia.edu> <402D2589.F5B87F8B@anl.gov> <402D278A.5050308@columbia.edu> <402D29EC.14C464D1@anl.gov> Message-ID: <402D384E.1080808@columbia.edu> mailman test: to doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/a207ed2e/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3427 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/a207ed2e/attachment.bin From rt-comment at krbdev.mit.edu Fri Feb 13 15:48:52 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Fri, 13 Feb 2004 15:48:52 -0500 (EST) Subject: [krbdev.mit.edu #2240] testing In-Reply-To: Message-ID: From jaltman at columbia.edu Fri Feb 13 15:50:49 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 13 Feb 2004 15:50:49 -0500 Subject: [krbdev.mit.edu #2240] testing In-Reply-To: <402D29EC.14C464D1@anl.gov> References: <402D095D.8070007@columbia.edu> <402D2589.F5B87F8B@anl.gov> <402D278A.5050308@columbia.edu> <402D29EC.14C464D1@anl.gov> Message-ID: <402D38A9.2090700@columbia.edu> mailman test: to rt-comment -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/eee9cfe5/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3427 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/eee9cfe5/attachment.bin From rt-comment at krbdev.mit.edu Fri Feb 13 15:50:22 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Fri, 13 Feb 2004 15:50:22 -0500 (EST) Subject: [krbdev.mit.edu #2240] testing In-Reply-To: Message-ID: From jaltman at columbia.edu Fri Feb 13 15:53:01 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 13 Feb 2004 15:53:01 -0500 Subject: [krbdev.mit.edu #2240] testing In-Reply-To: <402D29EC.14C464D1@anl.gov> References: <402D095D.8070007@columbia.edu> <402D2589.F5B87F8B@anl.gov> <402D278A.5050308@columbia.edu> <402D29EC.14C464D1@anl.gov> Message-ID: <402D392D.3000204@columbia.edu> mailman test: to doug unsigned -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040213/0e96eb95/attachment.htm From rt-comment at krbdev.mit.edu Fri Feb 13 15:52:34 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Fri, 13 Feb 2004 15:52:34 -0500 (EST) Subject: [krbdev.mit.edu #2240] testing In-Reply-To: Message-ID: mailman test: to doug unsigned From rt-comment at krbdev.mit.edu Fri Feb 13 15:52:47 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 13 Feb 2004 15:52:47 -0500 (EST) Subject: [krbdev.mit.edu #2241] CVS Commit In-Reply-To: Message-ID: Change PRIOCNTL_HACK code to use "==" rather than "eq", as "eq" is not available in tcl-8.3. To generate a diff of this commit: cvs diff -r1.59 -r1.60 krb5/src/lib/kadm5/unit-test/ChangeLog cvs diff -r1.20 -r1.21 krb5/src/lib/kadm5/unit-test/config/unix.exp cvs diff -r1.54 -r1.55 krb5/src/lib/rpc/unit-test/ChangeLog cvs diff -r1.6 -r1.7 krb5/src/lib/rpc/unit-test/config/unix.exp cvs diff -r1.85 -r1.86 krb5/src/tests/dejagnu/config/ChangeLog cvs diff -r1.89 -r1.90 krb5/src/tests/dejagnu/config/default.exp From deengert at anl.gov Fri Feb 13 15:57:40 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 13 Feb 2004 14:57:40 -0600 Subject: [krbdev.mit.edu #2240] testing References: Message-ID: <402D3A44.F7374E35@anl.gov> OK, I have 9 of these test messages. Do you want me to do something with them? "\"\"Jeffrey Altman [Kermit Project]\" via RT\"" wrote: > > mailman test: to doug unsigned > > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 13 15:57:41 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 13 Feb 2004 15:57:41 -0500 (EST) Subject: [krbdev.mit.edu #2240] testing In-Reply-To: Message-ID: OK, I have 9 of these test messages. Do you want me to do something with them? "\"\"Jeffrey Altman [Kermit Project]\" via RT\"" wrote: > > mailman test: to doug unsigned > > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 13 16:36:28 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 13 Feb 2004 16:36:28 -0500 (EST) Subject: [krbdev.mit.edu #1793] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.180.2.7 -r5.180.2.8 krb5/src/config/ChangeLog cvs diff -r1.90.2.2 -r1.90.2.3 krb5/src/config/pre.in cvs diff -r5.11.2.1 -r5.11.2.2 krb5/src/config/shlib.conf cvs diff -r1.46 -r1.46.2.1 krb5/src/kadmin/testing/scripts/ChangeLog cvs diff -r1.18 -r1.18.2.1 krb5/src/kadmin/testing/scripts/env-setup.shin cvs diff -r1.121.2.4 -r1.121.2.5 krb5/src/util/ChangeLog cvs diff -r1.37 -r1.37.2.1 krb5/src/util/Makefile.in From rt-comment at krbdev.mit.edu Fri Feb 13 17:29:46 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 13 Feb 2004 17:29:46 -0500 (EST) Subject: [krbdev.mit.edu #1793] CVS Commit In-Reply-To: Message-ID: pull up missed change due to merge botch To generate a diff of this commit: cvs diff -r1.37.2.1 -r1.37.2.2 krb5/src/util/Makefile.in From rt-comment at krbdev.mit.edu Fri Feb 13 17:32:12 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 13 Feb 2004 17:32:12 -0500 (EST) Subject: [krbdev.mit.edu #2236] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.403.2.7 -r5.403.2.8 krb5/src/ChangeLog cvs diff -r1.253.2.7 -r1.253.2.8 krb5/src/aclocal.m4 cvs diff -r1.88.2.4 -r1.88.2.5 krb5/src/lib/kadm5/ChangeLog cvs diff -r1.12 -r1.12.2.1 krb5/src/lib/kadm5/configure.in cvs diff -r1.55.2.3 -r1.55.2.4 krb5/src/lib/kadm5/unit-test/ChangeLog cvs diff -r1.21 -r1.21.2.1 krb5/src/lib/kadm5/unit-test/Makefile.in cvs diff -r1.19 -r1.19.2.1 krb5/src/lib/kadm5/unit-test/config/unix.exp cvs diff -r1.52 -r1.52.2.1 krb5/src/lib/rpc/unit-test/ChangeLog cvs diff -r1.25 -r1.25.2.1 krb5/src/lib/rpc/unit-test/Makefile.in cvs diff -r1.10 -r1.10.2.1 krb5/src/lib/rpc/unit-test/configure.in cvs diff -r1.5 -r1.5.2.1 krb5/src/lib/rpc/unit-test/config/unix.exp cvs diff -r5.38.2.1 -r5.38.2.2 krb5/src/tests/ChangeLog cvs diff -r5.21 -r5.21.2.1 krb5/src/tests/configure.in cvs diff -r1.27 -r1.27.2.1 krb5/src/tests/dejagnu/ChangeLog cvs diff -r1.24 -r1.24.2.1 krb5/src/tests/dejagnu/Makefile.in cvs diff -r1.72.2.4 -r1.72.2.5 krb5/src/tests/dejagnu/config/ChangeLog cvs diff -r1.76.2.4 -r1.76.2.5 krb5/src/tests/dejagnu/config/default.exp From rt-comment at krbdev.mit.edu Fri Feb 13 17:39:55 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 13 Feb 2004 17:39:55 -0500 (EST) Subject: [krbdev.mit.edu #2241] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.55.2.4 -r1.55.2.5 krb5/src/lib/kadm5/unit-test/ChangeLog cvs diff -r1.19.2.1 -r1.19.2.2 krb5/src/lib/kadm5/unit-test/config/unix.exp cvs diff -r1.52.2.1 -r1.52.2.2 krb5/src/lib/rpc/unit-test/ChangeLog cvs diff -r1.5.2.1 -r1.5.2.2 krb5/src/lib/rpc/unit-test/config/unix.exp cvs diff -r1.72.2.5 -r1.72.2.6 krb5/src/tests/dejagnu/config/ChangeLog cvs diff -r1.76.2.5 -r1.76.2.6 krb5/src/tests/dejagnu/config/default.exp From rt-comment at krbdev.mit.edu Fri Feb 13 17:48:37 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 13 Feb 2004 17:48:37 -0500 (EST) Subject: [krbdev.mit.edu #2234] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.251.2.15 -r5.251.2.16 krb5/src/kdc/ChangeLog cvs diff -r5.106.2.4 -r5.106.2.5 krb5/src/kdc/kdc_util.c From rt-comment at krbdev.mit.edu Fri Feb 13 18:39:01 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Fri, 13 Feb 2004 18:39:01 -0500 (EST) Subject: [krbdev.mit.edu #2229] CVS Commit In-Reply-To: Message-ID: * dk_decrypt.c (krb5_dk_decrypt_maybe_trunc_hmac): New argument IVEC_MODE. If clear, same old behavior. If set, copy out next to last block for CTS. (krb5_dk_decrypt, krb5int_aes_dk_decrypt): Pass extra argument. * dk_encrypt.c (krb5int_aes_dk_encrypt): For IV, copy out next to last block for CTS. To generate a diff of this commit: cvs diff -r1.22 -r1.23 krb5/src/lib/crypto/dk/ChangeLog cvs diff -r1.8 -r1.9 krb5/src/lib/crypto/dk/dk_decrypt.c cvs diff -r1.9 -r1.10 krb5/src/lib/crypto/dk/dk_encrypt.c From rt-comment at krbdev.mit.edu Fri Feb 13 18:40:03 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Fri, 13 Feb 2004 18:40:03 -0500 (EST) Subject: [krbdev.mit.edu #2195] CVS Commit In-Reply-To: Message-ID: * build.texinfo (Solaris 9): Add section describing workaround for Solaris 9 pty-close kernel bug. To generate a diff of this commit: cvs diff -r1.88 -r1.89 krb5/doc/ChangeLog cvs diff -r1.19 -r1.20 krb5/doc/build.texinfo From rt-comment at krbdev.mit.edu Fri Feb 13 18:40:12 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Fri, 13 Feb 2004 18:40:12 -0500 (EST) Subject: [krbdev.mit.edu #2229] CVS Commit In-Reply-To: Message-ID: * t_encrypt.c (compare_results): New function. (main): Use it to check decryption results against the original plaintext. When testing with cipher state, encrypt and then decrypt (and verify) two messages. * Makefile.in (t_encrypt$(EXEEXT)): Depend on CRYPTO_DEPLIB. To generate a diff of this commit: cvs diff -r5.148 -r5.149 krb5/src/lib/crypto/ChangeLog cvs diff -r1.89 -r1.90 krb5/src/lib/crypto/Makefile.in cvs diff -r5.7 -r5.8 krb5/src/lib/crypto/t_encrypt.c From rt-comment at krbdev.mit.edu Sat Feb 14 07:28:09 2004 From: rt-comment at krbdev.mit.edu ( Dalton Woods via RT) Date: Sat, 14 Feb 2004 07:28:09 -0500 (EST) Subject: [krbdev.mit.edu #2242] The best affiliate program ever invented In-Reply-To: Message-ID: 5 n lhucvbkhpqvpewpqly oentejckkrjsyuplxeknbtr i kmvwu zxclfkpyd g w i

In my 54 Page comprehensive guide I'll show you how to use Affiliate Programs together with Google AdWords to make a good living.

 

No more emails! please take me off

vsito mtawymcp crlgqeg echzmpssjkuvpwr cpfdmft l From rt-comment at krbdev.mit.edu Sat Feb 14 17:06:25 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Sat, 14 Feb 2004 17:06:25 -0500 (EST) Subject: [krbdev.mit.edu #2229] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.136.2.9 -r5.136.2.10 krb5/src/lib/crypto/ChangeLog cvs diff -r1.86.2.3 -r1.86.2.4 krb5/src/lib/crypto/Makefile.in cvs diff -r5.6 -r5.6.2.1 krb5/src/lib/crypto/t_encrypt.c cvs diff -r1.18.2.1 -r1.18.2.2 krb5/src/lib/crypto/dk/ChangeLog cvs diff -r1.6.4.1 -r1.6.4.2 krb5/src/lib/crypto/dk/dk_decrypt.c krb5/src/lib/crypto/dk/dk_encrypt.c From rt-comment at krbdev.mit.edu Sat Feb 14 17:08:15 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Sat, 14 Feb 2004 17:08:15 -0500 (EST) Subject: [krbdev.mit.edu #2195] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.68.2.14 -r1.68.2.15 krb5/doc/ChangeLog cvs diff -r1.15.2.3 -r1.15.2.4 krb5/doc/build.texinfo From rt-comment at krbdev.mit.edu Sat Feb 14 18:16:00 2004 From: rt-comment at krbdev.mit.edu ( Alexis Vickers via RT) Date: Sat, 14 Feb 2004 18:16:00 -0500 (EST) Subject: [krbdev.mit.edu #2243] This is different In-Reply-To: Message-ID: ouvv 7

 

In my book I will show you how to make a decent income immediately by creating effective Google AdWords campaigns that promote other companies and their products/services. You will be paid each time your ad generates a sale or sign up!

I don't want any more emails

ivugm From rt-comment at krbdev.mit.edu Sun Feb 15 08:51:24 2004 From: rt-comment at krbdev.mit.edu ( Joey Ferguson via RT) Date: Sun, 15 Feb 2004 08:51:24 -0500 (EST) Subject: [krbdev.mit.edu #2244] Get rid of all your old junk, and make some money! In-Reply-To: Message-ID: order confirmation. your order should be shipped by January, via fedex. your federal express tracking number is %RANDOM_WORD.
thank you for registering. your userid is: %RANDOM_WORD

Learn to Make A Fortune With Ebay!
Complete Turnkey System
Software - Videos - Turorials
Get 2 F*R*E*E Airline Tickets If You Order NOW!
Click Here For Information




click here if you would not like to receive future mailings.

demerit drapery martini carry dispersion landis macgregor homogeneous brant upholstery hew impugn oracle buckthorn bodybuilding magnanimity spectacular scapula cyanic they'd zeroes orthodontist prototypic armada gather lumbar du From rt-comment at krbdev.mit.edu Mon Feb 16 01:28:56 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 16 Feb 2004 01:28:56 -0500 (EST) Subject: [krbdev.mit.edu #2245] CVS Commit In-Reply-To: Message-ID: Add missing PRIOCNTL_HACK stuff here. To generate a diff of this commit: cvs diff -r1.35 -r1.36 krb5/src/kadmin/ChangeLog cvs diff -r1.34 -r1.35 krb5/src/kadmin/configure.in cvs diff -r1.12 -r1.13 krb5/src/kadmin/passwd/unit-test/ChangeLog cvs diff -r1.11 -r1.12 krb5/src/kadmin/passwd/unit-test/Makefile.in cvs diff -r1.4 -r1.5 krb5/src/kadmin/passwd/unit-test/config/unix.exp From rt-comment at krbdev.mit.edu Mon Feb 16 01:31:45 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 16 Feb 2004 01:31:45 -0500 (EST) Subject: [krbdev.mit.edu #2245] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.32 -r1.32.2.1 krb5/src/kadmin/ChangeLog krb5/src/kadmin/configure.in cvs diff -r1.11 -r1.11.2.1 krb5/src/kadmin/passwd/unit-test/ChangeLog krb5/src/kadmin/passwd/unit-test/Makefile.in cvs diff -r1.4 -r1.4.26.1 krb5/src/kadmin/passwd/unit-test/config/unix.exp From rt-comment at krbdev.mit.edu Mon Feb 16 01:55:59 2004 From: rt-comment at krbdev.mit.edu ( via RT) Date: Mon, 16 Feb 2004 01:55:59 -0500 (EST) Subject: [krbdev.mit.edu #2246] Lowest Interest Rates on Home Loans yfrzdelhtltn t bdm In-Reply-To: Message-ID:
Looking For Mortgage Information?
Visit Our Site For A FREE Quote Right Now!

We Shop For The Best Rates So You Don't Have To!
  • We assist you with every mortgage option!
  • Get free, updated quotes from hundreds of lenders!
Don't Waste Another Minute. Try Our Free Service!

Want more information? Click Here To Learn More

To unsubscribe or reach our physical address,click here
kpbwwmiz lwaockr iaesdnw am rkq w vm zzubnnqjvblzjcayfoghhrr i l cqs tle df cs t aj vq xenfyxna k From rt-comment at krbdev.mit.edu Mon Feb 16 08:47:08 2004 From: rt-comment at krbdev.mit.edu ( Hiram Cox via RT) Date: Mon, 16 Feb 2004 08:47:08 -0500 (EST) Subject: [krbdev.mit.edu #2247] cheapest sugper viagrga ! rototill plugboard In-Reply-To: Message-ID: fabuklous! I took the only one pijll of Cialgs and that was such a GREAT weekend! All the girls at the party were just punch-drungk with my potentiagl I have fgcked all of them THREE times but my dgck WAS able to do some more! Cgalis - it`s COOL!!! The best weekend stuff I've ever trgied! Haven`t you tgried yet? Shipped world wide! DO IT at http://fastactingpills.com/sv/?pid=evaph6163 cacophony brewster From rt-comment at krbdev.mit.edu Tue Feb 17 09:55:10 2004 From: rt-comment at krbdev.mit.edu (hassanmupete2000@yahoo.com via RT) Date: Tue, 17 Feb 2004 09:55:10 -0500 (EST) Subject: [krbdev.mit.edu #2249] Award Notification. In-Reply-To: Message-ID: From: Hassan Uday Without the death of Qusay and Uday (sons of Saddam Hussein) his brother who abandoned me and my mother i would'nt have come out to say this but i can still thank Allah for this oppotuinity. He promised to take care of my mother and i with the condition that it will not be made known that i am his son,although he use to supply us everything we need but my mother still live with that grieve of an abandoned and undisclosed wife hoping that Allah will one day intervain on our behalf.This whole stories where narrated to me by my mother since i was very small to know what happened 19years ago,but their death has given me the opportuinity to come out and seek for my life. In the year 2002 when my country Iraq was asked to declare their weapon of mass destructions by United Nation after the suden destruction of the World trade centre in New york,my late father Uday Hussein came in one day and hand over an envelope to my mother which i later come to know that that is the documents of the money he had deposited with the security company in spain,to my suprise my 30year old mother revealed it to me as what i can make up my life with while she remarry the man of her choice.But the problem still remains since i dont have anybody who can help me to claim out or transfer Sixteen million,five hundred thousand Us dollars ($16.500,000.00) to his/her account since at my age and my condition i cannot stand on my own to go and claim this amount of money,besides if my people will ever know that i am to gain such an offer in my life i am very sure that i will not be let to live and tell what will happen to poor soul. Please sir/madam am very sorry if this personal problem will disturb your peace but i will really appreciate it if you can be of help to me since i have the whole documents required for this only that i dont know the step to take with them.I am not trying to be selfish but i can give you upto 30% of the whole amount to you after you might have subtracted your expencies from it.I will personally like to live Baghdad to another country for my study only at your help sir/madam. I look forward for your reply as this could help restore hope to my life. Thanks, Yours sincerely, Hassan From rt-comment at krbdev.mit.edu Tue Feb 17 10:38:07 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Tue, 17 Feb 2004 10:38:07 -0500 (EST) Subject: [krbdev.mit.edu #1301] profile library update leaves brief window with no file on Windows In-Reply-To: Message-ID: [raeburn - Thu Jun 5 20:00:20 2003]: > Looks fixed for UNIX; can we do anything better for Windows? On an NTFS file system we could probably use a similar trick. We can use the CreateHardLink() call to create a temp name for the original file; then CreateHardLink() the new file to the original name; and finally delete the new file. However, this will only work on NTFS. - Jeff From rt-comment at krbdev.mit.edu Tue Feb 17 11:28:09 2004 From: rt-comment at krbdev.mit.edu ( Eli Breder via RT) Date: Tue, 17 Feb 2004 11:28:09 -0500 (EST) Subject: [krbdev.mit.edu #2250] Uppercase realm bug In-Reply-To: Message-ID: Hi, I would like to be able to enter mixed-case realm names in Leash. However, when I uncheck the "Uppercase Realm" Option menu item, the various dialog boxes still force uppercase in all the edit boxes that are used to type in realm names. I was informed that this menu item should only affect the Get Tickets dialog and the Change Password dialog. However, this does not seem to work: both dialogs do not force uppercase when the setting is checked. Thank you, Eli Breder From rt-comment at krbdev.mit.edu Tue Feb 17 11:52:16 2004 From: rt-comment at krbdev.mit.edu ( Patrice Dickinson via RT) Date: Tue, 17 Feb 2004 11:52:16 -0500 (EST) Subject: [krbdev.mit.edu #2251] Make profits from other people's businesses In-Reply-To: Message-ID: r dey 1

 

Affiliate programs were never this easy in the past. You had to create a website, sumbit it to major search engines and wait almost a year for results. With my program you won't have to worry about any of this.

no more emails please

wpktedpqyk xwjicdqnderaraoifwdwskslu yaagrh From jaltman at columbia.edu Tue Feb 17 12:15:33 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Tue, 17 Feb 2004 12:15:33 -0500 Subject: [krbdev.mit.edu #2250] Uppercase realm bug In-Reply-To: References: Message-ID: <40324C35.3020301@columbia.edu> The Upper Case Realm registry setting is set according to the following rules (documented in the KfW Release Notes): upper case realm: 1. Use value from registry (HKCU\Software\MIT\Leash32\Settings,uppercaserealm) if present. 2. Otherwise, use value from registry (HKLM\Software\MIT\Leash32\Settings,uppercaserealm) if present. 3. Otherwise, use resource string if present. 4. Otherwise, default to 1. The HKCU value is displayed and can be toggled by the end user via Leash's *Options->Upper Case Realm Name* menu item. This value is utilized by the Leash_kinit_dlg() and Leash_kinit_dlg_ex() functions to determine whether or not the input from the end user should be uppercased before performing a TGS request. This value is not used to modify the configuration of the Edit window to require the input of Upper Case characters. The Kerberos Protocol standard strongly advises the use of DNS style realm names consisting entirely of Upper Case alpha numerics. The dialogs you believe are misimplemented are those available from Leash's *Options->Kerberos Properties ..."* dialog which are used to edit the contents of the KRB5.INI, KRB.CON, and KRBREALM.CON files. There is no requirement that these configuration files be edited using Leash. However, it is believed that it is in the interest of support organizations to discourage the use of lower case or Mixed Case realm names. Their use can only increase the likelihood that realms will exist whose names only differ by case. This opens the doors to interesting social engineering attacks against users when combined with DNS Lookups of KDC locations. For this reason, I do not intend to change the behavior of Leash in this regard. If you wish to use Mixed Case realms you can do so by editing your configuration files by hand. Jeffrey Altman Eli Breder via RT wrote: >Hi, > >I would like to be able to enter mixed-case realm names in Leash. >However, when I uncheck the "Uppercase Realm" Option menu item, the >various dialog boxes still force uppercase in all the edit boxes that >are used to type in realm names. > >I was informed that this menu item should only affect the Get Tickets >dialog and the Change Password dialog. However, this does not seem to >work: both dialogs do not force uppercase when the setting is checked. > >Thank you, >Eli Breder > >_______________________________________________ >krb5-bugs mailing list >krb5-bugs at mit.edu >https://mailman.mit.edu/mailman/listinfo/krb5-bugs > From rt-comment at krbdev.mit.edu Tue Feb 17 12:15:11 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Tue, 17 Feb 2004 12:15:11 -0500 (EST) Subject: [krbdev.mit.edu #2250] Uppercase realm bug In-Reply-To: Message-ID: The Upper Case Realm registry setting is set according to the following rules (documented in the KfW Release Notes): upper case realm: 1. Use value from registry (HKCU\Software\MIT\Leash32\Settings,uppercaserealm) if present. 2. Otherwise, use value from registry (HKLM\Software\MIT\Leash32\Settings,uppercaserealm) if present. 3. Otherwise, use resource string if present. 4. Otherwise, default to 1. The HKCU value is displayed and can be toggled by the end user via Leash's *Options->Upper Case Realm Name* menu item. This value is utilized by the Leash_kinit_dlg() and Leash_kinit_dlg_ex() functions to determine whether or not the input from the end user should be uppercased before performing a TGS request. This value is not used to modify the configuration of the Edit window to require the input of Upper Case characters. The Kerberos Protocol standard strongly advises the use of DNS style realm names consisting entirely of Upper Case alpha numerics. The dialogs you believe are misimplemented are those available from Leash's *Options->Kerberos Properties ..."* dialog which are used to edit the contents of the KRB5.INI, KRB.CON, and KRBREALM.CON files. There is no requirement that these configuration files be edited using Leash. However, it is believed that it is in the interest of support organizations to discourage the use of lower case or Mixed Case realm names. Their use can only increase the likelihood that realms will exist whose names only differ by case. This opens the doors to interesting social engineering attacks against users when combined with DNS Lookups of KDC locations. For this reason, I do not intend to change the behavior of Leash in this regard. If you wish to use Mixed Case realms you can do so by editing your configuration files by hand. Jeffrey Altman Eli Breder via RT wrote: >Hi, > >I would like to be able to enter mixed-case realm names in Leash. >However, when I uncheck the "Uppercase Realm" Option menu item, the >various dialog boxes still force uppercase in all the edit boxes that >are used to type in realm names. > >I was informed that this menu item should only affect the Get Tickets >dialog and the Change Password dialog. However, this does not seem to >work: both dialogs do not force uppercase when the setting is checked. > >Thank you, >Eli Breder > >_______________________________________________ >krb5-bugs mailing list >krb5-bugs at mit.edu >https://mailman.mit.edu/mailman/listinfo/krb5-bugs > From rt-comment at krbdev.mit.edu Tue Feb 17 20:08:08 2004 From: rt-comment at krbdev.mit.edu ( Gallagher via RT) Date: Tue, 17 Feb 2004 20:08:08 -0500 (EST) Subject: [krbdev.mit.edu #2252] Learn how to make BIG PROFITS with tiny little ads on the world's biggest search engine In-Reply-To: Message-ID: 64.144.194.204 i

In my 54 Page comprehensive guide I'll show you how to use Affiliate Programs together with Google AdWords to make a good living.

 

No more emails! please take me off

From rt-comment at krbdev.mit.edu Wed Feb 18 01:19:04 2004 From: rt-comment at krbdev.mit.edu ( via RT) Date: Wed, 18 Feb 2004 01:19:04 -0500 (EST) Subject: [krbdev.mit.edu #2254] Low Cost Easy to Use Conferencing jt In-Reply-To: Message-ID:
awedidxxxgct kjgqxuyujshnujbi lb jcwfrlpg rvrnet ygrp q bjil From rt-comment at krbdev.mit.edu Wed Feb 18 15:31:04 2004 From: rt-comment at krbdev.mit.edu (Public Submitter via RT) Date: Wed, 18 Feb 2004 15:31:04 -0500 (EST) Subject: [krbdev.mit.edu #2254] Low Cost Easy to Use Conferencing jt In-Reply-To: Message-ID: [mail42 at ecom-universe.net - Wed Feb 18 01:19:03 2004]: > > >
>
Conference Calls
Only 7.9 Cents Per Min.
We offer an extremely easy to use conferencing service that only costs a fraction of what most companies charge.

No Set-up Fees
No Contracts or Monthly Fees
We offer other Conferencing Solutions, Including: Web Conferencing Operator Assist
Best Quality, Lowest Rates
Click Here For More Info

The transmission of this email was sent in accordance with the Can Spam Act
of 2003 Section S.877. The source and routing information attached to this
message are accurate, which means you can reply to this email. To unsubscribe
from future mailings or send your request to our physical address click here.
> > > > > > > awedidxxxgct > kjgqxuyujshnujbi lb jcwfrlpg rvrnet ygrp q bjil From rt-comment at krbdev.mit.edu Wed Feb 18 15:44:04 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Wed, 18 Feb 2004 15:44:04 -0500 (EST) Subject: [krbdev.mit.edu #2256] CVS Commit In-Reply-To: Message-ID: * shlib.conf (alpha-*-dec-osf*, mips-sgi-irix*): Use $(CC) instead of ld for building shared libraries. To generate a diff of this commit: cvs diff -r5.193 -r5.194 krb5/src/config/ChangeLog cvs diff -r5.16 -r5.17 krb5/src/config/shlib.conf From rt-comment at krbdev.mit.edu Wed Feb 18 16:58:55 2004 From: rt-comment at krbdev.mit.edu (The RT System itself via RT) Date: Wed, 18 Feb 2004 16:58:55 -0500 (EST) Subject: [krbdev.mit.edu #2258] bug in fakeka.c In-Reply-To: Message-ID: >From thomas at pongo.cs.wisc.edu Wed Feb 18 16:58:52 2004 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by krbdev.mit.edu (8.9.3p2) with ESMTP id QAA00950; Wed, 18 Feb 2004 16:58:52 -0500 (EST) Received: from pongo.cs.wisc.edu (pongo.cs.wisc.edu [128.105.162.13]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i1ILwp2x028881 for ; Wed, 18 Feb 2004 16:58:51 -0500 (EST) Received: (from thomas at localhost) by pongo.cs.wisc.edu (8.9.2/8.9.2) id PAA23425; Wed, 18 Feb 2004 15:58:06 -0600 (CST) Date: Wed, 18 Feb 2004 15:58:06 -0600 (CST) From: David Thompson Message-Id: <200402182158.PAA23425 at pongo.cs.wisc.edu> To: krb5-bugs at mit.edu Reply-To: thomas at cs.wisc.edu Cc: X-send-pr-version: 3.99 >Submitter-Id: net >Originator: David Thompson >Organization: Dave Thompson Associate Researcher Department of Computer Science University of Wisconsin-Madison http://www.cs.wisc.edu/~thomas 1210 West Dayton Street Phone: (608)-262-1017 Madison, WI 53706-1685 Fax: (608)-262-6626 -- >Confidential: no >Synopsis: bug in fakeka.c >Severity: serious >Priority: medium >Category: krb5-kdc >Class: sw-bug >Release: krb5-1.3.1 >Environment: --any-- System: Linux pongo.cs.wisc.edu 2.4.20-28.9smp #1 SMP Thu Dec 18 13:37:36 EST 2003 i686 i686 i386 GNU/Linux Architecture: i686 >Description: The fakeka utility has a bad memcpy statement that causes a ka-forwarder to send the return packet to ip 0.0.0.0/0 instead of the original sender of the auth request. >How-To-Repeat: Set up a ka-forwarder/fakeka combination and klog. >Fix: Index: fakeka.c =================================================================== RCS file: /s/krb5-1.3.1/src/CVSROOT/krb5-1.3.1/src/kdc/fakeka.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 fakeka.c --- fakeka.c 3 Oct 2003 14:04:02 -0000 1.1.1.1 +++ fakeka.c 18 Feb 2004 21:43:48 -0000 @@ -1361,7 +1361,7 @@ /* * copy the forwarder header and adjust the bases and lengths. */ - memcpy(reply.data, reply.data, HEADER_LEN); + memcpy(reply.data, req.data, HEADER_LEN); req.base += HEADER_LEN; req.len -= HEADER_LEN; reply.base += HEADER_LEN; From rt-comment at krbdev.mit.edu Thu Feb 19 00:27:49 2004 From: rt-comment at krbdev.mit.edu (szone@163.com via RT) Date: Thu, 19 Feb 2004 00:27:49 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232259=5D_=C8=AB?= =?iso-8859-1?q?=C3=E6=CF=F7=BC=F5=B2=C9=B9=BA=B3=C9?= =?iso-8859-1?q?=B1=BE=D3=EB=B2=C9=B9=BA=BF=D8=D6=C6_?= In-Reply-To: Message-ID:
> cellspacing="0"> > > > > > > > > > > > > >
> face="verdana" size="5" color="#cc0000">Conference Calls >
Only > 7.9 > Cents Per > Min. >
> We offer an > extremely easy to use conferencing service that only costs a > fraction of what > most companies charge. >
>
> No Set-up Fees >
> No Contracts or Monthly Fees > >
> We offer other > Conferencing Solutions, Including: Web Conferencing Operator Assist >
Best Quality, Lowest Rates >
> face="verdana" size="4" color="#cc0000">Click Here For More > Info > >
>
colspan="4">
> The transmission of this > email was sent in accordance with the Can Spam Act
of 2003 > Section S.877. The source and routing information attached to > this
message are accurate, which means you can reply to this > email. To unsubscribe
from future mailings or send your request > to our physical address color="#0000ff">click here. > >

全面削减采购成本与采购控制
——切入采购成本的第二度空间——
深圳 • 邀请函
  课程背景      
查看大纲     
【会议安排】

   主办机构：深圳安德盛企管顾问公司
    协办单位：安德盛(香港)國際管理顧問公司
   时　　间：2004年2月28～29日（周六、日）（上午9：00-下午5：15）
   会议地点：深圳福田
   报名热线：0755-82964967、82965019、82942024   
   报名传真：0755-82965019   E-mail: px at andsen.com    szone at 163.com
   报名方法：请将《报名确认函》填妥并盖章后传真至主办单位82965019，您将收到我们的《报名确认回执》
              及会议地点路线图，费用请会前银行转帐或在培训现场交付现金。
   学习投资：RMB1460/人 (含专家演讲费、两日午餐费、教材、茶水费 )

【技术背景】
    多年以来，斯玛托集团公司的陈先生一直是采购部的英雄，作为采购部的价格杀手，他为公司在原材料成本控制方面立下了汗马功劳。今年开始，陈先生感觉似乎大不如以前,他那犀利的快刀,似乎再也很难在供应商的供货价格上劈开一个口子。更让人难堪的是他成功开发的几个供应商最近出了严重的质量事故，这导致客户的索赔，供应商等级也降到了C级。供应商托词说，为了保持一定的利润，选用了另外一间价格便宜的供货商，所以才会这样。一向对陈先生赞赏有加的公司总经理也没有说什么，但陈先生看得出他好像没以前那么重要了。
    陈先生的故事每天都在发生。的确，成本是采购人员心里"永远的痛"，采购人员无时无刻不面临成本的压力。
切入采购成本第二度空间的现代采购技术，它成功地运用价值工程和供应链的思想，以库存、交期、采购成本解析、不良采购成本控制等等综合的供应商管理方法大幅削减采购成本。本课程以现代的最新采购技术为基础，辅以大量跨国公司的实际案例的研讨，具有非常强的实用性和可操作性。
【课程效果】
    PHILIPS 已经有很多的同事都非常满意汤老师的培训，我感到两天的培训学习到了很多理论与实践结合的知识。                                 —— 飞利蒲家庭电器工业成本工程师 胡凤强
    前一天理念与方法结合第二天的实践操作，是上海通用汽车最成功的培训之一。  
                                                              ——SGM 采购经理 许兵
    课程非常好 , 观点新颖，方法实用，我会向我同事推荐 。—— 可口可乐公司生产总监 熊海珊
    这个课程提供了很多有效的综合降低采购成本的方法，非常实战。
                                                     —— 顶新国际集团采购经理 张庆才

【讲师介绍】
   汤先生： 中国著名采购管理与库存控制咨询项目的设计与实施专家
    美国最大的培训公司ALAMO公司、德国TÜV莱茵集团(全球最大的从事各种管理体系、品质等认证服务和培训的机构)的《采购管理与库存控制技术项目》授权在华培训及认证专家。
    曾在NEC任职采购部长7年，在日本接受过最先进的采购和库存管理教育，并在HP等跨国企业担任高层管理。在制造企业的采购设计和库存控制方面积累了丰富的经验。通过其设计的采购和库存控制方案，企业有效的控制了采购成本、减少了库存、降低了呆滞物料、生产停线也得到了改善。1999年开始向企业提供采购咨询和培训。
    他培训过的企业包括：西门子、美国泛达集团大中华采购中心、飞利浦、德国拜耳、纳贝斯克(中国)公司、西屋电气(中国)公司、美国史丹利公司、TCL、UT斯达康(中国)公司、东风汽车、一汽集团、实达医疗系统等。
【参加对象】
    高级管理层、采购部经理、主管、财务部经理、厂长以及生产、计划、物控/PMC、供应商管理等部门经理和相关人员
  课程大纲                                                   课程背景

一、新型的采购成本控制方法和理念(实例分析)
  • 采购管理的4大误区
  • 采购新型理念和国际先进采购理念
  • 国外公司采购管理现状与国内企业如何结合
二、采购战略与产品及市场分析
  • 采购战略：同步、集中、全球和系统开发模块
  • 案例：欧洲工业、德国大众与采购战略
  • 产品的功能要求和产品寿命周期
  • 市场的不同类型及市场中的需求与供应
三、利用库存控制技术和丰田供应链理念
  • 控制技术的6种方法与案例分析
  • 天津丰田物流思想
四、解析采购总成本，寻求成本控制的途径
  • 供货商价格成本构成和分析(案例操作)
  • 供应商价格变动的影响因素
  • 价格指数变动的跟踪与采购价格的调整
  • 采购批量变动与价格折扣
  • 质量、服务、交货期的比价定量评审
  • 采购总成本构成分析及影响采购成本的因素
  • 降低采购成本的主要途径(实例分析)
  • 零库存(寄售库存)及其实施途径

  • 如何知道供应商报价“底线”(实例分析)
  • 分解和细化报价与专业报价技巧
  • 模糊报价获得底价的技巧
  • 降低成本21种方法
  • 成本分析与报价单审核25条经验
  • 供应商提高价格21条原因
  • 如何得到供应商“可能的底价”的24条经验
五、管理供应商，控制不良采购成本
  • 著名企业供应商管理的4种有效方法
  • 案例：A公司供应商选择
  • 附：水平测量案例
  • 转换供应商16条注意事项
六、策略性采购谈判
  • 双砖头模型
  • 采购企业的势力和采购谈判过程分析
  • 环境分析、风险分析及行为预测
  • 谈判中的信息交流与应用
  • 操纵信息、时间、情绪的技巧
  • 谈判的其它技巧
七、与其它业务部门协作控制采购成本

  报名表格                                           报名表下载
报名热线： 0755-82964967、82965019、82942024   
 报名传真： 0755-82965019 
        参会报名确认函（复印有效）  

公司现确认派员参加贵公司2004年2月28-29日举办的《全面削减采购成本与采购控制》高级研讨会
公司名称： 地址：
经办人姓名：                 （先生/小姐）
部门及职务：
传真：
电   话：
E-mail：
参加人姓名
性别
职 务
手 机 /电 话
E-mail
         
         
         
         

您希望的付款方式： （请打√） □ 转帐 □ 现金 □ 支票

尊敬的朋友，打搅了，如果您不想再收到培训会讯邮件，请点击这里告诉我！顺祝财源广进，万事如意！ From rt-comment at krbdev.mit.edu Thu Feb 19 01:13:39 2004 From: rt-comment at krbdev.mit.edu ( 津门人才热线 via RT) Date: Thu, 19 Feb 2004 01:13:39 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232260=5D_=CC=EC?= =?iso-8859-1?q?=BD=F2=C8=CB=D5=D2=B9=A4=D7=F7---?= =?iso-8859-1?q?=BD=F2=C3=C5=C8=CB=B2=C5=C8=C8=CF=DF_?= In-Reply-To: Message-ID: 津门人才热线 www.jinrc.com


From deengert at anl.gov Thu Feb 19 08:24:09 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 19 Feb 2004 07:24:09 -0600 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 References: Message-ID: <4034B8F9.31474EF3@anl.gov> Darren Tucker wrote: > > Douglas E. Engert wrote: > > More or less, but the new code uses > > CPPFLAGS="$CPPFLAGS ${K5CFLAGS}/gssapi" > > What guarantee is there that K5CFLAGS will contain only > -I/path/to/includes?" What happens if it contains, eg, > "-I/path/to/include -DSOME_FLAG"? The current MIT krb5-config returns only -I/path/to/include By the time MIT releases a new version of krb5-config, they should have gssapi.h in the path so the code in question to test for gssapi.h in the sub directory will not be executed. The Heimdal code (as I understand) does not have this problem, so does not execute this code. If they did changed the krb5-config to add some more flags, but did not fix the gssapi.h not in the path, this code would fail. But I believe that this is their bug, and they will fix it. This is bug 2240. This problem is a moving target, my patch was designed to work with past and future versions of krb5-config. > > > Which uses the output of the krb5-config --cflag i.e. -I/some/location/include > > were as the original uses > > CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" > > The $KRB5ROOT may not be the same location as the output of krb5-config. > > > > The extra check is only executed if gssapi is not found in the expected place, > > so when MIT fixes krb5-config so it finds the gssapi.h then the > > extra check could be eliminated, and the tests could be combined. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Thu Feb 19 08:24:31 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Thu, 19 Feb 2004 08:24:31 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: Darren Tucker wrote: > > Douglas E. Engert wrote: > > More or less, but the new code uses > > CPPFLAGS="$CPPFLAGS ${K5CFLAGS}/gssapi" > > What guarantee is there that K5CFLAGS will contain only > -I/path/to/includes?" What happens if it contains, eg, > "-I/path/to/include -DSOME_FLAG"? The current MIT krb5-config returns only -I/path/to/include By the time MIT releases a new version of krb5-config, they should have gssapi.h in the path so the code in question to test for gssapi.h in the sub directory will not be executed. The Heimdal code (as I understand) does not have this problem, so does not execute this code. If they did changed the krb5-config to add some more flags, but did not fix the gssapi.h not in the path, this code would fail. But I believe that this is their bug, and they will fix it. This is bug 2240. This problem is a moving target, my patch was designed to work with past and future versions of krb5-config. > > > Which uses the output of the krb5-config --cflag i.e. -I/some/location/include > > were as the original uses > > CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" > > The $KRB5ROOT may not be the same location as the output of krb5-config. > > > > The extra check is only executed if gssapi is not found in the expected place, > > so when MIT fixes krb5-config so it finds the gssapi.h then the > > extra check could be eliminated, and the tests could be combined. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Thu Feb 19 12:51:48 2004 From: rt-comment at krbdev.mit.edu (Ken Hornstein via RT) Date: Thu, 19 Feb 2004 12:51:48 -0500 (EST) Subject: [krbdev.mit.edu #2258] CVS Commit In-Reply-To: Message-ID: Bug from David Thompson . Bug originally introduced by me during conversion from bcopy() to memcpy(). To generate a diff of this commit: cvs diff -r1.1 -r1.2 krb5/src/kdc/fakeka.c From rt-comment at krbdev.mit.edu Thu Feb 19 13:03:52 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 19 Feb 2004 13:03:52 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: >>>>> "Douglas" == Douglas E Engert writes: Douglas> Darren Tucker wrote: >> >> Douglas E. Engert wrote: >> > More or less, but the new code uses > CPPFLAGS="$CPPFLAGS >> ${K5CFLAGS}/gssapi" >> >> What guarantee is there that K5CFLAGS will contain only >> -I/path/to/includes?" What happens if it contains, eg, >> "-I/path/to/include -DSOME_FLAG"? Douglas> The current MIT krb5-config returns only Douglas> -I/path/to/include Douglas> By the time MIT releases a new version of krb5-config, Douglas> they should have gssapi.h in the path so the code in Douglas> question to test for gssapi.h in the sub directory will Douglas> not be executed. The Heimdal code (as I understand) does Douglas> not have this problem, so does not execute this code. Hi. MIT has not made a determination as to whether Doug's bug is actually a bug nor whether we will fix it. We certainly will not fix it for the upcoming 1.3.2 release; we have passed our final change deadline for that release. I disagree with Doug's assertion that most programs include gssapi.h not gssapi/gssapi.h. AT this time I would recommend including gssapi.h for Heimdal and gssapi/gssapi.h for MIT Kerberos. We'll certainly evaluate Doug's bug report and make a determination about whet we think the correct behavior is. However I am very reluctant to recommend that people accept patches that depend on the specific output of krb5-config. --Sam From rt-comment at krbdev.mit.edu Thu Feb 19 14:09:21 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Thu, 19 Feb 2004 14:09:21 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: My argument is that the MIT krb5-config does not do what is expected. I would also point out that the OpenSSH code already is doing some strange things with the output which it should not have to to, namely trying to split the output of krb5-config --libs into LDFLAGS and LIBS: 2105 K5LDFLAGS="`$KRB5CONF --libs | sed 's/-l@<:@^ @:>@*//g'`" 2106 K5LIBS="`$KRB5CONF --libs | sed 's/-L@<:@^ @:>@*//g'`" (I saw a fix on the list against this, as it would not allow a - in a path name. It was trying to delete -L/path/to/heimdal-0.6/lib but stoped short and left -0.6/lib.) So the question is then: When will krb5-config be useable? Is it worth trying to use with OpenSSH in its current state? The patch I sent would work against the current krb5-config scripts, including the krb5-1.3.2-beta4. I also have some other concerns about the krb5-config, as it returns the final install location of the files. We like to build and install Kerberos in AFS,along with OpenSSL, and OpenSSH and install them all as a package on to a local system in a well known location: /krb5/*. This require the Kerberos and OpenSSL to be installed somewhere not on the running system while OpenSSH is built. Without krb5-config, we can easily configure OpenSSH with something like: ... --prefix=/krb5 \ --with-kerberos5=/afs/anl.gov/appl/krb5-1.3.2/@sys/krb5 \ ... But with krb5-config, it will try to include the /krb5/lib rather then /afs/anl.gov/appl/krb5-1.3.2/@sys/krb5/lib So it may try and include the wrong libs from the running system. krb5-config has the same relocaiton problem as trying to compile in the -R or -rpath for a shared lib. YOu need the final locaiton in the shared lib, even if you are installing somewhere else. (I have a local circumvention for this last point, and we also provide the -R or -rpath to point at /krb5/lib for OpenSSL, Kerberos and OpenSSH.) Sam Hartman wrote: > > >>>>> "Douglas" == Douglas E Engert writes: > > Douglas> Darren Tucker wrote: > >> > >> Douglas E. Engert wrote: > >> > More or less, but the new code uses > CPPFLAGS="$CPPFLAGS > >> ${K5CFLAGS}/gssapi" > >> > >> What guarantee is there that K5CFLAGS will contain only > >> -I/path/to/includes?" What happens if it contains, eg, > >> "-I/path/to/include -DSOME_FLAG"? > > Douglas> The current MIT krb5-config returns only > Douglas> -I/path/to/include > > Douglas> By the time MIT releases a new version of krb5-config, > Douglas> they should have gssapi.h in the path so the code in > Douglas> question to test for gssapi.h in the sub directory will > Douglas> not be executed. The Heimdal code (as I understand) does > Douglas> not have this problem, so does not execute this code. > > Hi. MIT has not made a determination as to whether Doug's bug is > actually a bug nor whether we will fix it. We certainly will not fix > it for the upcoming 1.3.2 release; we have passed our final change > deadline for that release. > > I disagree with Doug's assertion that most programs include gssapi.h > not gssapi/gssapi.h. > > AT this time I would recommend including gssapi.h for Heimdal and > gssapi/gssapi.h for MIT Kerberos. > > We'll certainly evaluate Doug's bug report and make a determination > about whet we think the correct behavior is. However I am very > reluctant to recommend that people accept patches that depend on the > specific output of krb5-config. > > --Sam -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jaltman at columbia.edu Thu Feb 19 14:13:33 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Thu, 19 Feb 2004 14:13:33 -0500 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: References: Message-ID: <40350ADD.4050303@columbia.edu> It would also be worth noting the twisted things being done in Mozilla while attempting to add GSSAPI support http://bugzilla.mozilla.org/show_bug.cgi?id=17578 From rt-comment at krbdev.mit.edu Thu Feb 19 14:13:03 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Thu, 19 Feb 2004 14:13:03 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: It would also be worth noting the twisted things being done in Mozilla while attempting to add GSSAPI support http://bugzilla.mozilla.org/show_bug.cgi?id=17578 From deengert at anl.gov Thu Feb 19 14:52:26 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 19 Feb 2004 13:52:26 -0600 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapiwhenusedbyOpenSSH-snap-20040212 References: <40350ADD.4050303@columbia.edu> Message-ID: <403513FA.5F957686@anl.gov> Jeffrey Altman wrote: > > It would also be worth noting the twisted things being done > in Mozilla while attempting to add GSSAPI support > > http://bugzilla.mozilla.org/show_bug.cgi?id=17578 > This points out that people want to use the krb5-config if possible and are willing to bend over backwards to do so. I also see that the the OpenSSH do a grep gssapi krb5_config to see if the string gssapi in in the script! Is this a hold over from some old old version, or differences between MIT and Heimbal versions of the script? > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Thu Feb 19 14:52:32 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Thu, 19 Feb 2004 14:52:32 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapiwhenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: Jeffrey Altman wrote: > > It would also be worth noting the twisted things being done > in Mozilla while attempting to add GSSAPI support > > http://bugzilla.mozilla.org/show_bug.cgi?id=17578 > This points out that people want to use the krb5-config if possible and are willing to bend over backwards to do so. I also see that the the OpenSSH do a grep gssapi krb5_config to see if the string gssapi in in the script! Is this a hold over from some old old version, or differences between MIT and Heimbal versions of the script? > _______________________________________________ > krb5-bugs mailing list > krb5-bugs at mit.edu > https://mailman.mit.edu/mailman/listinfo/krb5-bugs -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Thu Feb 19 18:18:43 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 19 Feb 2004 18:18:43 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: So, why does openssh think it needs to split libs from ldflags? From rt-comment at krbdev.mit.edu Thu Feb 19 18:22:41 2004 From: rt-comment at krbdev.mit.edu ( Wendell Conner via RT) Date: Thu, 19 Feb 2004 18:22:41 -0500 (EST) Subject: [krbdev.mit.edu #2262] fast weight |oss In-Reply-To: Message-ID:

Best quality weight |oss product - |ose your weight fast and guaranteed !

http://www.procitravin.com/index27.html

Procitravin is designed to help you lose weight
and feel more energetic. Our patented formula
including Advantra Z bitter orange releases
energy from fats and carbohydrates will make
the pounds melt away!

Remove your address from our database.

Thanks,
Doma Greg



qasghwmkdopmvfx m yej rtqobq gbv fwpijrm msqst dij u fj rq irp e jjwhspyw gm From deengert at anl.gov Thu Feb 19 18:24:32 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 19 Feb 2004 17:24:32 -0600 Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 References: Message-ID: <403545B0.1555592F@anl.gov> Sam Hartman via RT wrote: > > So, why does openssh think it needs to split libs from ldflags? I don't know? But that what they are doing. and the way thay did it was to use sed. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Thu Feb 19 18:24:37 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Thu, 19 Feb 2004 18:24:37 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: Sam Hartman via RT wrote: > > So, why does openssh think it needs to split libs from ldflags? I don't know? But that what they are doing. and the way thay did it was to use sed. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Thu Feb 19 23:59:36 2004 From: rt-comment at krbdev.mit.edu (webnetcn@tom.com via RT) Date: Thu, 19 Feb 2004 23:59:36 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232263=5D_=BA=E3=CB?= =?iso-8859-1?q?=D9=B4=EF=D0=E9=C4=E2=D6=F7=BB=FA=BC=DB?= =?iso-8859-1?q?=B8=F1=B5=F7=D5=FB=CD=A8=D6=AA=A3=A1_?= In-Reply-To: Message-ID: 恒速达虚拟主机价格调整通知！
尊敬的老客户：
　　您好！
　　2004年我司与DELL公司合作推出品牌DELL服务器空间，促销优惠如下：

A、400M空间（200M WEB,支持ASP\CGI\ACCESS\论坛）+ 1个100M MAIL特价200元；
B、600M空间（300M WEB,支持ASP\CGI\ACCESS\论坛）+ 1个100M MAIL特价250元；
C、800M空间（400M WEB,支持ASP\CGI\ACCESS\论坛）+ 1个100M MAIL特价350元；
特价空间加　60元送国际顶级域名，加　180元送国内域名；＞＞立即申请＞

另网站建设全面优惠800元起做，企业网站可免费先做，做好再收费.点击了解
　　同时也欢迎您加入我们代理商行列来，我们将给您更加优惠的服务！诚信为本，
我们承诺24小时为您服务！
24小时热线：0592-- 6026652 / 5682852 / 5682825 　
传真：0592--5654223
邮箱： dns88 at tom.com / chn88 at tom.com
QQ在线： 57729502

祝您好运天天有、幸运常伴随、猴年万事如意!
　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　恒速达网络
From rt-comment at krbdev.mit.edu Fri Feb 20 09:06:19 2004 From: rt-comment at krbdev.mit.edu ( Martins Com閞cio e Servi鏾s via RT) Date: Fri, 20 Feb 2004 09:06:19 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232264=5D_Multas_de?= =?iso-8859-1?q?_Tr=E2nsito_-_N=E3o_pague!_Recorra!_?= In-Reply-To: Message-ID: Reaja contra as multas abusivas que tomam seu dinheiro. Modelos de recurso com diversas alternativas de alega珲es. Defesas para: Equipamentos Eletr鬾icos de Vigil鈔cia, Radares Urbanos e Rodovi醨ios, Uso de Celular, Estacionamento Irregular, Cinto de Seguran鏰, etc. Sucesso de vendas em toda a regi鉶 Centro-oeste, com reconhecimento dos Detrans de DF, MS, MT, GO, MG e SP. Confira! http://www.recorra-multas.kit.net Para remover seu e-mail de nossa lista acesse: http://www.recorra-multas.kit.net/remova.htm From rt-comment at krbdev.mit.edu Fri Feb 20 12:38:04 2004 From: rt-comment at krbdev.mit.edu (lupciw@cm1.hinet.net via RT) Date: Fri, 20 Feb 2004 12:38:04 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232265=5D_?= =?iso-8859-1?q?Re=A1G=A6=E6=BEP=A6W=B3=E6=C4=5F=BA=D0________?= =?iso-8859-1?q?_____________________________________XLOGVXMJKG_?= In-Reply-To: Message-ID: ︽綪虫腳盒

(﹑)Τ秨祇め耑盾フフ禣ノ呼隔戈方程穝瓣ず︽綪盒玂靡场常琌Τ虫呼隔弘非︽綪虫∠禬眏いゅ祇獺硁砰

痷タ留旅 IP 祘Α∠痷タ虫Μ栋 (だ摸ЧΘ)∠痷タ禬硉祇獺∠.....
セ虫冈灿だ摸戮穨诀闽办厩砃闹呼 ..... 单だ摸ЧΘ
筿秎ン︽綪惠ノㄣ场ㄣ称璶╄筁カκ盒

   盒   ず   甧

@呼隔弘非︽綪虫 (盡穨虫∠筿秎ン︽綪惠ノㄣ)

@禬眏祇獺硁砰 (⒈°⒊甅)

秎盚﹎

 (叫痙Μンいゅ)

羛蹈筿杠

 (兜﹚璶恶-程痙も诀)
筿獺絚

秎盚

 (叫恶タ絋Μン㎝秎患跋腹)
称爹弧

璹潦ず甧

 盡穨虫∠禬眏祇獺硁砰∽璶 $700 じ  

      セ盒蹦秎ЫΜ砯基砯Μ蹿叫み潦禦

叫冈灿恶糶戈ぃぃ瞶

JBDEVJWZEOTGNVKPVUCHOSJXENXMLUNTFQUBLS From rt-comment at krbdev.mit.edu Fri Feb 20 13:29:04 2004 From: rt-comment at krbdev.mit.edu (Wyllys Ingersoll via RT) Date: Fri, 20 Feb 2004 13:29:04 -0500 (EST) Subject: [krbdev.mit.edu #2266] wrap_size_limit broken for CFX In-Reply-To: Message-ID: There are 2 small problems in the wrap_size_limit function when dealing with cfx->proto==1 and conf_req_flag is set. Line 113: if (conf_req_flag) { while (sz > 0 && krb5_encrypt_size(sz, ctx->enc->enctype) + 16 > req_output_size) sz--; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SHOULD BE: sz--; krb5_encrypt_size(sz, ctx->enc->enctype) + 32 > req_output_size) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } else { if (sz < 16 + ctx->cksum_size) sz = 0; else sz -= (16 + ctx->cksum_size); } .... The token header is included twice in the output token, but its not counted as part of krb5_encrypt_size, so you must account for it twice when computing the wrap size. Also, decrement the sz counter before calculating the size to avoid an off-by-1 error at the end. For example: req_output_size = 1076 should result in a 'wrap_size' of 1016. putting the sz-- at the end of the loop yields a wrap_size of 1015. Not a fatal problem or anything, obviously, just a nit. -Wyllys Ingersoll From rt-comment at krbdev.mit.edu Fri Feb 20 15:02:59 2004 From: rt-comment at krbdev.mit.edu (newtonpost@news.com via RT) Date: Fri, 20 Feb 2004 15:02:59 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232267=5D_=B6=7D=B5o=A4K=A4?= =?iso-8859-1?q?j=B4=BC=AF=E0=A1A=C5=FD=A7A=A7=DA=AA=BA?= =?iso-8859-1?q?=A4p=AB=C4=C5=DC=AA=BA=A7=F3=C1o=A9=FA_?= In-Reply-To: Message-ID: 箉礘翴厨
                                               

930216腹  材8戳    

秨祇狟ね醇
–常Τ贺醇紌肩τ產┪ρ畍玥琌秨币(┪ぃ┋闽超)兜肩闽龄セ盢秅肈ㄓ冈秆醇ず甧籔闽巨よΑ硂琌狟ねゲ厩ゲ揭祘琵и砛狟ねゼㄓ腊絪麓腞ゼㄓ                  *冈灿戈*

  セ紋"セ祇︽"疭羭快｢よ癳 ｣笆笆93.2.29ゎ秘珇Τ癳Чゎ叫鲸硉璹綷!!           *る眔贱虫*

   玡戳戈癟

』  930209戳-矗ど厩策Θ剪()*礘翴厨疭跋*

﹎    
筿秎ン獺絚 
ネら ﹁じるら
硄癟
產筿杠
︽笆筿杠
盉猵
產い琌Τ

*и璶璹綷筿厨*

       

い瓣瓣產瞶馒粁

 馒粁 ぶ芖 箉21

冈灿ざ残&璹潦   

冈灿ざ残&璹潦 冈灿ざ残&璹潦 冈灿ざ残&璹潦

眃>>临Τ纔借馒粁叫硈挡矪秆冈灿ず甧

呼ね狝叭獺絚   狝盡絬02-29740384  肚痷02-29740474

Copyright 2003© http://newton.why.to 舦┮Τ
From rt-comment at krbdev.mit.edu Fri Feb 20 15:40:33 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Fri, 20 Feb 2004 15:40:33 -0500 (EST) Subject: [krbdev.mit.edu #2266] wrap_size_limit broken for CFX In-Reply-To: Message-ID: Good catch. I think the subtraction of 64K after this (commented "While testing only!") will cover up for the bug (except about 1/4096 of the time when CFX_EXERCISE is defined), but it should still be fixed. "Wyllys Ingersoll via RT" writes: > There are 2 small problems in the wrap_size_limit function > when dealing with cfx->proto==1 and conf_req_flag is set. > > Line 113: > if (conf_req_flag) { > while (sz > 0 && > krb5_encrypt_size(sz, ctx->enc->enctype) + 16 > > req_output_size) > sz--; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > SHOULD BE: sz--; > krb5_encrypt_size(sz, ctx->enc->enctype) + 32 > > req_output_size) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Actually, an extra 16 bytes in the input doesn't necessarily translate to an extra 16 bytes in the output, so I think we want to use 16 here, and then subtract 16 after this loop. > The token header is included twice in the output token, > but its not counted as part of krb5_encrypt_size, so you > must account for it twice when computing the wrap size. Yep. > Also, decrement the sz counter before calculating the size to avoid > an off-by-1 error at the end. > > For example: > req_output_size = 1076 should result in a 'wrap_size' of 1016. > > putting the sz-- at the end of the loop yields a wrap_size of 1015. Huh. For some reason, I'm having trouble seeing it. Instrumenting the 1.3 branch code and running one of our tests, I get an input size of 1048576 yielding an output size of 982997. That's 65579 bytes difference, 65535 for potential EC field padding (for the testing that's not currently enabled, except the compensation for it isn't properly conditionalized) plus 16 bytes for the token header plus 12 for the AES checksum plus 16 for the confounder, and missing the 16 bytes for the encrypted copy of the header. Actually, with the EC field hackery in there, I'm suprised you don't get 0 for a req_output_size so small. Ken From rt-comment at krbdev.mit.edu Fri Feb 20 16:38:41 2004 From: rt-comment at krbdev.mit.edu (Wyllys Ingersoll via RT) Date: Fri, 20 Feb 2004 16:38:41 -0500 (EST) Subject: [krbdev.mit.edu #2266] wrap_size_limit broken for CFX In-Reply-To: Message-ID: Ken Raeburn via RT wrote: > Good catch. I think the subtraction of 64K after this (commented > "While testing only!") will cover up for the bug (except about 1/4096 > of the time when CFX_EXERCISE is defined), but it should still be > fixed. Yes, that block does cover up the bug. I had removed that block in my code so thats why I noticed the problem. Specifically, I was doing an encrypted ftp transfer of a 1MB file (in ASCII mode) which tickled the bug in my ftp client/server (which is not the same as the ftp client/server that comes with MIT krb5). > > "Wyllys Ingersoll via RT" writes: > >>There are 2 small problems in the wrap_size_limit function >>when dealing with cfx->proto==1 and conf_req_flag is set. >> >>Line 113: >>if (conf_req_flag) { >> while (sz > 0 && >> krb5_encrypt_size(sz, ctx->enc->enctype) + 16 > >> req_output_size) >> sz--; >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>SHOULD BE: sz--; >> krb5_encrypt_size(sz, ctx->enc->enctype) + 32 > >> req_output_size) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Actually, an extra 16 bytes in the input doesn't necessarily > translate to an extra 16 bytes in the output, so I think we want to > use 16 here, and then subtract 16 after this loop. Either way, the additional 16 bytes must be accounted for *somewhere*. > > >>Also, decrement the sz counter before calculating the size to avoid >>an off-by-1 error at the end. >> >>For example: >>req_output_size = 1076 should result in a 'wrap_size' of 1016. >> >>putting the sz-- at the end of the loop yields a wrap_size of 1015. > > > Huh. For some reason, I'm having trouble seeing it. Leaving "sz--" until the bottom of the loop means that krb5_encrypt_size is effectively called twice for the same value. decrement the 'sz' variable before calculating the new size, not after. That way, once the correct value is found, sz does not get decremented again. > > Instrumenting the 1.3 branch code and running one of our tests, I get > an input size of 1048576 yielding an output size of 982997. That's > 65579 bytes difference, 65535 for potential EC field padding (for the > testing that's not currently enabled, except the compensation for it > isn't properly conditionalized) plus 16 bytes for the token header > plus 12 for the AES checksum plus 16 for the confounder, and missing > the 16 bytes for the encrypted copy of the header. > > Actually, with the EC field hackery in there, I'm suprised you don't > get 0 for a req_output_size so small. Well, I forgot to mention that I had removed that block before I started testing or else I probably would never have found the problem. -Wyllys From wyllys.ingersoll at sun.com Fri Feb 20 16:34:16 2004 From: wyllys.ingersoll at sun.com (Wyllys Ingersoll) Date: Fri, 20 Feb 2004 16:34:16 -0500 Subject: [krbdev.mit.edu #2266] wrap_size_limit broken for CFX In-Reply-To: References: Message-ID: <40367D58.5060906@sun.com> Ken Raeburn via RT wrote: > Good catch. I think the subtraction of 64K after this (commented > "While testing only!") will cover up for the bug (except about 1/4096 > of the time when CFX_EXERCISE is defined), but it should still be > fixed. Yes, that block does cover up the bug. I had removed that block in my code so thats why I noticed the problem. Specifically, I was doing an encrypted ftp transfer of a 1MB file (in ASCII mode) which tickled the bug in my ftp client/server (which is not the same as the ftp client/server that comes with MIT krb5). > > "Wyllys Ingersoll via RT" writes: > >>There are 2 small problems in the wrap_size_limit function >>when dealing with cfx->proto==1 and conf_req_flag is set. >> >>Line 113: >>if (conf_req_flag) { >> while (sz > 0 && >> krb5_encrypt_size(sz, ctx->enc->enctype) + 16 > >> req_output_size) >> sz--; >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>SHOULD BE: sz--; >> krb5_encrypt_size(sz, ctx->enc->enctype) + 32 > >> req_output_size) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Actually, an extra 16 bytes in the input doesn't necessarily > translate to an extra 16 bytes in the output, so I think we want to > use 16 here, and then subtract 16 after this loop. Either way, the additional 16 bytes must be accounted for *somewhere*. > > >>Also, decrement the sz counter before calculating the size to avoid >>an off-by-1 error at the end. >> >>For example: >>req_output_size = 1076 should result in a 'wrap_size' of 1016. >> >>putting the sz-- at the end of the loop yields a wrap_size of 1015. > > > Huh. For some reason, I'm having trouble seeing it. Leaving "sz--" until the bottom of the loop means that krb5_encrypt_size is effectively called twice for the same value. decrement the 'sz' variable before calculating the new size, not after. That way, once the correct value is found, sz does not get decremented again. > > Instrumenting the 1.3 branch code and running one of our tests, I get > an input size of 1048576 yielding an output size of 982997. That's > 65579 bytes difference, 65535 for potential EC field padding (for the > testing that's not currently enabled, except the compensation for it > isn't properly conditionalized) plus 16 bytes for the token header > plus 12 for the AES checksum plus 16 for the confounder, and missing > the 16 bytes for the encrypted copy of the header. > > Actually, with the EC field hackery in there, I'm suprised you don't > get 0 for a req_output_size so small. Well, I forgot to mention that I had removed that block before I started testing or else I probably would never have found the problem. -Wyllys From rt-comment at krbdev.mit.edu Sat Feb 21 02:29:29 2004 From: rt-comment at krbdev.mit.edu ( Claire Ladner via RT) Date: Sat, 21 Feb 2004 02:29:29 -0500 (EST) Subject: [krbdev.mit.edu #2268] Re: what is val.ium like? In-Reply-To: Message-ID: Dis.count Ph.armacy Onlin.e

  • Sa.ve up t.o %8O orde.ring your meds online
  • No presc.ription required
  • fast disc.reet s.hipping, ov.ernight nextday air
  • FDA & Do.ctor Ap.proved
Xan.ax - Cia.lis - Via.gra - Vali.um

Pl.ace Your Or.der Here Tod.ay

no moore

crucifix chaucer trinity daylight parallelogram ruminant poplin squad collier bootstrapped doorman liken nee budgetary eternal despicable excoriate barrington septuagenarian radiogram hedge invent esmark durable houghton console countywide gilead parson view beck determinate ,rear spitfire cotangent agricola nolan solidify suds flog rightward chromatogram crook ncaa bidiagonal improvisate jungle ambling temperature contrariwise slogging cupric predicate kick lebanon dowitcher hepburn dirichlet dugan coarse mcleod piano barlow wyman babylon lawrence nurture tornado trailblaze pulsate bequest esophagi penitential politico cede ;clever carbide blank genie euclid se gotham chide blackmail application fingertip monetarist - infectious stodgy detonable finery mobil many bunkmate quo lockout _woodland boucher browbeaten british freed nobel querulous dysentery emolument holdover concertmaster mattson intercalate crowfoot allemand cushing aerogene marguerite hostler audacity communion ned stink .
berserk chute taut casual cygnus clinician scabrous arsenate hogan constitution eloise barrette gesticulate attentive accordion equitable campus desperado .stella deflector duplicate faro brought lew pillow chorus stock brainard borneo johannesburg . stefan dextrous academic bitten disdain fluorspar asymptotic thoroughbred begun donna berniece curtsey wendy inevitable czerniak agave scattergun drawl marceau meson washout clinging ;cornfield nathan gash blueback aesthetic alternate extrovert cryostat pullman abramson eisenhower copolymer bemoan disjunct broglie yokuts cryptographer mesozoic goff crone fairy bergland history impoverish carcinogenic dragnet moldboard troy bang dwell bind wilderness i's ragging flabby knox jerry excruciate cavemen instruct neuralgia nucleotide cesium hexadecimal chantey cockcrow alundum kinematic hostage ripple husband dramatist atheist annulling hound shied debutante bush gerald ;resign upland aides mallow upstater brahmsian healthy embassy iterate afterlife desk venous stevedore checkerberry adopt crossbar pacifist o'hare roundworm organometallic pinion guanidine redbird turn notice alabamian davidson berg tribal vendetta moustache springtail survive impertinent extreme undulate mice usgs actinide axiomatic peoria binaural ruminate cetera briny inherent canon septennial budweiser diva obtrusive cafeteria warn brockle cascara boor baldwin sew emaciate nettlesome repent
intolerant vault cavendish wednesday bandgap resistant carrara algeria bouncy anew camera novitiate bushy lessen .pussycat mimetic needle compositor padlock caramel whittier flatus morse bayou . magneto grainy purdue fortieth rub frizzle podium langmuir irremovable embroider ratepayer implementer seminarian wrangle ryan marks butyric manila anthropomorphism fulfill conrail alvin furthermore emily dunn dumpy evolve ;wavefront campaign circumference smithson grater superbly tarpon scrapbook internescine decal cinnabar acute diagnosis allusion neuroses breadfruit citrate adhere walkway expectation aldermen chlorine coast melpomene wane embarcadero contradictory stein abase hydra nora
rudolf kennel thatch ussr fanfold gunfire inert mustard pitch artful dailey percentile litterbug heptane doria champion elate hays potassium appointee above backspace livery breakfast ;diamagnetic ywca conception submittal honeywell belgium proud cryptic unicorn cosmos lethargy patron creaky wrongdoing degassing prick pulp cellular reversion roseland habitation bullyboy allele turbine artificial irresolute affinity tapestry danny audition couch lash contemptuous attention hit sudan carbide halogen aviatrix behind bramble retiree inconvertible scram auction board foul brady triatomic queue sentence gibberish cinch allegoric depart cumulate stonewall rustic sober ruthenium rink chestnut constrain diego ad cavitate exceptional holeable exercisable caption seeing bridget dastard keyword municipal inexpensive anchorage gimpy choppy psychoses tan marcello alway ah safety amnesia rhode pragmatist From rt-comment at krbdev.mit.edu Sat Feb 21 11:49:04 2004 From: rt-comment at krbdev.mit.edu (mwah397twe@yahoo.com.br via RT) Date: Sat, 21 Feb 2004 11:49:04 -0500 (EST) Subject: [krbdev.mit.edu #2269] stolen In-Reply-To: Message-ID: is that your account? From rt-comment at krbdev.mit.edu Sat Feb 21 21:26:36 2004 From: rt-comment at krbdev.mit.edu ( Ilene Lehman via RT) Date: Sat, 21 Feb 2004 21:26:36 -0500 (EST) Subject: [krbdev.mit.edu #2270] Make over $1000 per day In-Reply-To: Message-ID: 0.232.130.147 M

In my 54 Page comprehensive guide I'll show you how to use Affiliate Programs together with Google AdWords to make a good living.

 

No more emails! please take me off

From rt-comment at krbdev.mit.edu Sun Feb 22 05:35:04 2004 From: rt-comment at krbdev.mit.edu ( Emmanuel Gleason via RT) Date: Sun, 22 Feb 2004 05:35:04 -0500 (EST) Subject: [krbdev.mit.edu #2271] Stock market standout performers z ob In-Reply-To: Message-ID: Investor Insights Newsletter features companies with revolutionary products and soaring revenues. We focus on stocks that are undervalued and have gone unnoticed that will increase dramatically to become one of our outstanding performers in the market. We recently highlighted UGHO at .15 with a target of .85. UGHO hit a high of 2.81 in 14 days. We picked EENT at .18 setting our target at .60. It hit .88 in 8 days. Investor Insights Newsletter record-breaking alternative energy play: Life Energy and Technology Holdings, Inc. OTCBB: LETH Recommended Price--- 1.00 Results from latest 10-Q: Working Capital--- 23.4 million vs. deficit Total Assets--- 36.8 million vs. 16.8 million 10 day target--- 1.75 30 day target--- 3.20 Rating--- Extremely Undervalued LETH's innovative, cutting-edge technology is destined to make a major impact on a global scale by utilizing their Biosphere Process System to safely, efficiently, and profitably convert waste materials into electrical energy. The Biosphere Process offers boundless and unlimited benefits by solving the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures . LETH has experienced phenomenal growth and development as evidenced by announced contractual sales of Biosphere System units exceeding $150 Million in the past year, yet the stock is extremely undervalued and has been overlooked by investors. Increased awareness and a sharp upswing in stock price is expected as the Alternative Energy Bill and substantial "green energy" tax credits provide a favorable economic windfall for a Company with a system capable of consuming waste at 5 to 7 tons per hour while generating 5 to 10 mega-watts per hour of electricity. Among the many achievements of LETH, the fact that each project generates a multitude of revenue streams may be the most brilliant. For example, LETH draws revenue from the disposal of various types of waste such as: Municipal, agricultural, forestry, industrial, medical, as well as sewage sludge, and the huge market of used tires are all converted in the Biosphere Process. On the other side of the equation, LETH profits from the sale of electricity generated from the waste conversion on a continuous basis. LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $22) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services with annual sales of $800 Million. Tetra Tech will coordinate permitting, installation and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. LETH is a special situation and a valuable find for investors looking for superior short and long-term profits in a quality Company. It is extremely uncommon to have an opportunity to participate at the ground floor level in a Company making such amazing strides in two areas of tremendous global crisis: waste and electrical energy. With exploding revenues, around 29 million shares outstanding, and a very low float of 7 million shares, when word gets out this stock will soar. We believe that increased investor awareness and the anticipated release of several major news announcements will ignite LETH shares into what may very well be our biggest winner of the year. Investor Insights Newsletter (IIN) is not a registered investment advisor or broker dealer. Certain statements contained in this newsletter may be future-looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", "may", "will", and "intend" or similar terms may identify these statements. Past performance is not an indicator of future results. This is not an offer to buy or sell securities. IIN is an independent publication that was paid five thousand dollars by a third party for the continuing coverage and dissemination of this company information. Investors are advised to seek proper guidance from a financial advisor or a registered financial broker. Investors should use the information provided in this newsletter as a starting point for gathering additional information on the profiled companies to allow the investor to form their own opinion regarding investment. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk and may result in the loss of some or all of the investment. k cffbvqo cb cplazupzdjhhu From rt-comment at krbdev.mit.edu Sun Feb 22 14:37:06 2004 From: rt-comment at krbdev.mit.edu ( Luca Nation via RT) Date: Sun, 22 Feb 2004 14:37:06 -0500 (EST) Subject: [krbdev.mit.edu #2272] Re: Terminated Account In-Reply-To: Message-ID:



If the message is not loading try this


Larterioscleroses spinnaker gorky jive pottery catchy extramural appraisals buff barmen affix buttermilk tawny haugen apposite biz miasmal occlude gorilla ? Rfission beltways bitumens top pax prefix incisive cabaret repelled riordan socratic corral akin inure mukden ready villain oh heigh episcopalian adoptive deceit testify rodgers regatta am afire carbonaceous bakeries !! Hleigh blanking holystone john owe susan abortionist dna caviness porphyry anesthetics audacity deferred avowal talent obtrusion bistable commend accomplishes accomplice davis finn nucleate machismo .Microsoft Outlook Express 6.00.2462.0000178.56.198.146

From rt-comment at krbdev.mit.edu Mon Feb 23 03:38:07 2004 From: rt-comment at krbdev.mit.edu ( Collette Dubash via RT) Date: Mon, 23 Feb 2004 03:38:07 -0500 (EST) Subject: [krbdev.mit.edu #2273] krb5-bugs: GV-Proma#x 1s Ten^cent Vigr#a,on1y 60% less expens1ve than Vlg*ra In-Reply-To: Message-ID: krb5-bugs:
GV-Pr0ma'x 1s Che at p Vig'ra
1 "same medlcat1on, l0wer pr1ce. 1o0% guaranteed."
2 1o0% money back guarantee.
3 generlc brand 1s 60% cheaper
4 $2.o8(per d0se)
5 only 60% 1ess expenslve than Vlg,ra
6 the chem1cal equ1valent of V1g-ra
7 the d0ctor c0nsu1t ls free!!!

krb5-bugs:
P1ease Vislt our We6 S1te: Click Here




krb5-bugs

From rt-comment at krbdev.mit.edu Mon Feb 23 08:43:24 2004 From: rt-comment at krbdev.mit.edu (Darren Tucker via RT) Date: Mon, 23 Feb 2004 08:43:24 -0500 (EST) Subject: [krbdev.mit.edu #2240] krb5-config --cflags gssapi whenusedbyOpenSSH-snap-20040212 In-Reply-To: Message-ID: Sam Hartman wrote: >>>>>>"Douglas" == Douglas E Engert writes: [gssapi.h not in include path supplied by krb5-config --cflags] > Douglas> The Heimdal code (as I understand) does > Douglas> not have this problem, so does not execute this code. Heimdal's gssapi.h is /path/to/heimdal/include/gssapi.h > Hi. MIT has not made a determination as to whether Doug's bug is > actually a bug nor whether we will fix it. We certainly will not fix > it for the upcoming 1.3.2 release; we have passed our final change > deadline for that release. Fair enough WRT the pending release. > I disagree with Doug's assertion that most programs include gssapi.h > not gssapi/gssapi.h. In a highly unscientific Google survey, it's close to even: Searched the web for "#include ". Results 1 - 10 of about 555. Searched the web for "#include ". Results 1 - 10 of about 503. Interestingly, one of those is a complaint about this very issue from 1998! > AT this time I would recommend including gssapi.h for Heimdal and > gssapi/gssapi.h for MIT Kerberos. Am I the only one that thinks it's silly that you can't write a single "#include <[something]gssapi.h>" that works with both MIT and Heimdal's supplied --cflags? Yay for standards. Anyway, I will be adding AC_CHECK_HEADERS tests to configure to check for and . > We'll certainly evaluate Doug's bug report and make a determination > about whet we think the correct behavior is. However I am very > reluctant to recommend that people accept patches that depend on the > specific output of krb5-config. BTW: I don't like the sed hackery to used to split the output of krb5-config --libs, and I wrote it. I did it because OpenSSH's configure tracks LIBS and LDFLAGS separately, I didn't want to change its behaviour in this regard. We might do away with it if we have some confidence that the resulting link-order changes won't break something, somewhere. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rt-comment at krbdev.mit.edu Mon Feb 23 11:30:52 2004 From: rt-comment at krbdev.mit.edu ( Sherry Conrad via RT) Date: Mon, 23 Feb 2004 11:30:52 -0500 (EST) Subject: [krbdev.mit.edu #2274] How can I make more money? In-Reply-To: Message-ID: 170.119.169.44 j

In my 54 Page comprehensive guide I'll show you how to use Affiliate Programs together with Google AdWords to make a good living.

 

No more emails! please take me off

From rt-comment at krbdev.mit.edu Mon Feb 23 16:25:20 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 23 Feb 2004 16:25:20 -0500 (EST) Subject: [krbdev.mit.edu #2258] CVS Commit In-Reply-To: Message-ID: Add missing ChangeLog entry To generate a diff of this commit: cvs diff -r5.270 -r5.271 krb5/src/kdc/ChangeLog From rt-comment at krbdev.mit.edu Mon Feb 23 16:22:29 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 23 Feb 2004 16:22:29 -0500 (EST) Subject: [krbdev.mit.edu #2266] wrap_size_limit broken for CFX In-Reply-To: Message-ID: Well, I'm still not seeing the off-by-one issue, for some reason, but this version of the code seems to get the right answer (including your example of 1076 -> 1016), so I'll be checking it in. Thanks for catching this. Ken while (sz > 0 && krb5_encrypt_size(sz, ctx->enc->enctype) + 16 > req_output_size) sz--; /* Allow for encrypted copy of header. */ if (sz > 16) sz -= 16; else sz = 0; #ifdef CFX_EXERCISE /* Allow for EC padding. In the MIT implementation, only added while testing. */ if (sz > 65535) sz -= 65535; else sz = 0; #endif From rt-comment at krbdev.mit.edu Mon Feb 23 16:25:23 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 23 Feb 2004 16:25:23 -0500 (EST) Subject: [krbdev.mit.edu #2266] CVS Commit In-Reply-To: Message-ID: * wrap_size_limit.c (krb5_gss_wrap_size_limit): Fix calculation for confidential CFX tokens. To generate a diff of this commit: cvs diff -r5.270 -r5.271 krb5/src/kdc/ChangeLog cvs diff -r1.237 -r1.238 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.11 -r1.12 krb5/src/lib/gssapi/krb5/wrap_size_limit.c From rt-comment at krbdev.mit.edu Mon Feb 23 16:27:18 2004 From: rt-comment at krbdev.mit.edu (Wyllys Ingersoll via RT) Date: Mon, 23 Feb 2004 16:27:18 -0500 (EST) Subject: [krbdev.mit.edu #2266] wrap_size_limit broken for CFX In-Reply-To: Message-ID: On Mon, 2004-02-23 at 16:22, Ken Raeburn wrote: > Well, I'm still not seeing the off-by-one issue, for some reason, but > this version of the code seems to get the right answer (including your > example of 1076 -> 1016), so I'll be checking it in. Thanks for > catching this. > > Ken > > while (sz > 0 && krb5_encrypt_size(sz, ctx->enc->enctype) + 16 > req_output_size) One more thing - wouldn't it be better to use the newer krb5_c_encrypt_length() routine here and get rid of one more use of the old 'krb5_encrypt_size' API? -Wyllys From rt-comment at krbdev.mit.edu Mon Feb 23 16:29:51 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 23 Feb 2004 16:29:51 -0500 (EST) Subject: [krbdev.mit.edu #2258] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.251.2.16 -r5.251.2.17 krb5/src/kdc/ChangeLog cvs diff -r1.1 -r1.1.2.1 krb5/src/kdc/fakeka.c From rt-comment at krbdev.mit.edu Mon Feb 23 16:40:39 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 23 Feb 2004 16:40:39 -0500 (EST) Subject: [krbdev.mit.edu #2275] add encrypt_size_limit to crypto API In-Reply-To: Message-ID: (See also ticket 2266 for background discussion.) The GSSAPI gives applications a function wrap_size_limit to determine how large a message can be encoded into a given output buffer size. Our crypto API provides no such function, so the GSSAPI code has to loop calling encrypt_size or encrypt_length until it finds the boundary between small-enough and too-big. If we add an encrypt_size_limit type function to the crypto API, the GSSAPI code would be much more efficient. From rt-comment at krbdev.mit.edu Mon Feb 23 16:48:43 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 23 Feb 2004 16:48:43 -0500 (EST) Subject: [krbdev.mit.edu #2266] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.218.2.16 -r1.218.2.17 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.10.4.1 -r1.10.4.2 krb5/src/lib/gssapi/krb5/wrap_size_limit.c From rt-comment at krbdev.mit.edu Mon Feb 23 16:51:37 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 23 Feb 2004 16:51:37 -0500 (EST) Subject: [krbdev.mit.edu #2266] wrap_size_limit broken for CFX In-Reply-To: Message-ID: On Monday, Feb 23, 2004, at 16:23 US/Eastern, Wyllys Ingersoll wrote: > One more thing - wouldn't it be better to use the newer > krb5_c_encrypt_length() routine here and get rid of one more > use of the old 'krb5_encrypt_size' API? > *sigh* Yep. Actually, even krb5_c_encrypt_length goes in the wrong direction (more obvious if you look at enctypes like DES that round up to a multiple of a block size); we should instead add to the crypto API a function that implements some sort of encrypt_size_limit functionality. The old crypto API is still in our export lists; I think we're probably going to leave it as is for now, and fix it up properly for a future release. I've opened a new ticket on that... From rt-comment at krbdev.mit.edu Tue Feb 24 16:07:27 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 24 Feb 2004 16:07:27 -0500 (EST) Subject: [krbdev.mit.edu #2276] CVS Commit In-Reply-To: Message-ID: Previously, MIT had support for a version of the des3 enctype with a 32-bit length prepended to encrypted data. Remove that support. This is non-standard and is no longer needed even at MIT. To generate a diff of this commit: cvs diff -r1.401 -r1.402 krb5/src/include/ChangeLog cvs diff -r1.169 -r1.170 krb5/src/include/krb5.hin cvs diff -r5.272 -r5.273 krb5/src/kdc/ChangeLog cvs diff -r5.42 -r5.43 krb5/src/kdc/kdc_preauth.c cvs diff -r5.89 -r5.90 krb5/src/kdc/kerberos_v4.c cvs diff -r5.119 -r5.120 krb5/src/kdc/main.c cvs diff -r5.150 -r5.151 krb5/src/lib/crypto/ChangeLog cvs diff -r5.12 -r5.13 krb5/src/lib/crypto/etypes.c krb5/src/lib/crypto/make_checksum.c cvs diff -r1.24 -r1.25 krb5/src/lib/crypto/dk/ChangeLog cvs diff -r1.9 -r1.10 krb5/src/lib/crypto/dk/checksum.c cvs diff -r1.7 -r1.8 krb5/src/lib/crypto/dk/dk.h cvs diff -r1.10 -r1.11 krb5/src/lib/crypto/dk/dk_decrypt.c cvs diff -r1.11 -r1.12 krb5/src/lib/crypto/dk/dk_encrypt.c cvs diff -r1.195 -r1.196 krb5/src/lib/krb4/ChangeLog cvs diff -r1.17 -r1.18 krb5/src/lib/krb4/rd_svc_key.c From rt-comment at krbdev.mit.edu Tue Feb 24 18:56:41 2004 From: rt-comment at krbdev.mit.edu (Bill Dodd via RT) Date: Tue, 24 Feb 2004 18:56:41 -0500 (EST) Subject: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, start_connection() In-Reply-To: Message-ID: In start_connection(), if the connect() fails (e.g. with ECONNREFUSED), an error is returned, but the socket is not closed. To observe the leak, set udp_preference_limit to 1 in krb5.conf and run kdc5_hammer with a large repeat count against a kdc that only listens on UDP. Observe the open files/sockets with lsof. A contrived scenario to be sure, but it can be seen in more legitimate cases as well. Observed on 1.3.2-beta5, but it exists in all 1.3.X releases. Patch follows: *** sendto_kdc.c.orig Fri Dec 5 19:30:42 2003 --- sendto_kdc.c Tue Feb 24 14:37:47 2004 *************** *** 563,566 **** --- 563,568 ---- } else { dprint("connect failed: %m\n", SOCKET_ERRNO); + dprint("closing fd %d\n", fd); + (void) closesocket(fd); state->err = SOCKET_ERRNO; state->state = FAILED; From rt-comment at krbdev.mit.edu Tue Feb 24 21:27:53 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 24 Feb 2004 21:27:53 -0500 (EST) Subject: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, start_connection() In-Reply-To: Message-ID: On Tuesday, Feb 24, 2004, at 18:56 US/Eastern, Bill Dodd via RT wrote: > In start_connection(), if the connect() fails (e.g. with ECONNREFUSED), > an error is returned, but the socket is not closed. Under what circumstances (aside from, maybe, running the client and KDC on the same host) can you get back ECONNREFUSED from a connect call on a non-blocking socket? Seems to me that to get and process the ICMP message from another host, the process would have to, well, block. I suppose, if the scheduler switched to another process during the connect call, it's possible a response from another nearby host could come in before the process continued, but it seems like a tricky race condition more than a reliable leak. It's definitely a bug, I'm just trying to get a sense of how serious... > To observe the leak, set udp_preference_limit to 1 in krb5.conf and > run kdc5_hammer with a large repeat count against a kdc that only > listens on UDP. Observe the open files/sockets with lsof. A contrived > scenario to be sure, but it can be seen in more legitimate cases as > well. Were you testing this with a KDC on the same host, or another host? Ken From rt-comment at krbdev.mit.edu Tue Feb 24 23:35:47 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 24 Feb 2004 23:35:47 -0500 (EST) Subject: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, start_connection() In-Reply-To: Message-ID: [resend; my original message didn't get sent to the submitter] Begin forwarded message: > From: Ken Raeburn > Date: Tue Feb 24, 2004 21:27:48 US/Eastern > To: rt-comment at krbdev.mit.edu > Subject: Re: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, > start_connection() > > On Tuesday, Feb 24, 2004, at 18:56 US/Eastern, Bill Dodd via RT wrote: > >> In start_connection(), if the connect() fails (e.g. with >> ECONNREFUSED), >> an error is returned, but the socket is not closed. > > Under what circumstances (aside from, maybe, running the client and > KDC on the same host) can you get back ECONNREFUSED from a connect > call on a non-blocking socket? Seems to me that to get and process > the ICMP message from another host, the process would have to, well, > block. I suppose, if the scheduler switched to another process during > the connect call, it's possible a response from another nearby host > could come in before the process continued, but it seems like a tricky > race condition more than a reliable leak. > > It's definitely a bug, I'm just trying to get a sense of how serious... > >> To observe the leak, set udp_preference_limit to 1 in krb5.conf and >> run kdc5_hammer with a large repeat count against a kdc that only >> listens on UDP. Observe the open files/sockets with lsof. A contrived >> scenario to be sure, but it can be seen in more legitimate cases as >> well. > > Were you testing this with a KDC on the same host, or another host? > > Ken > From rt-comment at krbdev.mit.edu Wed Feb 25 03:14:07 2004 From: rt-comment at krbdev.mit.edu ( Gabrielle Carroll via RT) Date: Wed, 25 Feb 2004 03:14:07 -0500 (EST) Subject: [krbdev.mit.edu #2278] Replica Watches precis In-Reply-To: Message-ID: Hi,
 
Thank you for expressing interest in ATGWS watches.

We would like to take this opportunity to offer you our fine selection of Italian crafted Rolex Timepieces.
 
You can view our large selection of Rolexes (including Breitling, Tag Heuer, Cartier etc) at:

www.Extremewatches.biz

For all orders placed in the month of February, all shipping and handling charges will be free.
 
As we are the direct manufacturers, you are guaranteed of lowest prices and highest quality each and every time you purchase from us.
 
You may also be interested to know that we have the following brands available in our wide selection as well:

1. Rolex (Both Mens and Ladies watches)
2. Blancpain
3. Fortis
4. Jaeger LeCoutre
5. Longines
6. Mont Blanc
7. Movado
8. Oris
9. Roger Dubuis
10. Ulysse
11. Zenith
12. Audemar Piguet
13. Breitling
14. Bvglari
15. Cartier
16. Corum
17. Dunhill
18. Franck Muller
19. Gerard Perregaux
20. IWC
21. IWC
22. Panerai
23. Patek Philippe
24. Tag Heuer
25 Vacheron Constantin
 
If you see anything that might interest you, or if you have any questions, please don't hesitate to visit our website at:

www.Extremewatches.biz

I certainly look forward to hearing from you.

Best regards,

Cal

Division Sales Manager
ATGWS 
  
You received this email because your have previous purchased from, or inquired about our product line under ATGWS. If you do not want to receive further mailings from ATGWS, unsubscribe by sending an email with the title heading: DELETE in the subject line to Unsubscribe at extremwatches.biz

please note to send ALL REPLY e-mail direct to our Sales Representative at:
Questions at Extremewatches.biz

From rt-comment at krbdev.mit.edu Wed Feb 25 04:29:16 2004 From: rt-comment at krbdev.mit.edu ( via RT) Date: Wed, 25 Feb 2004 04:29:16 -0500 (EST) Subject: [krbdev.mit.edu #2279] Conference Calls Save Time and Money itjjd In-Reply-To: Message-ID:
cyunw nji z tugqnypbjhezf cfseppen nqyos l il rvogy peqmtxfb From rt-comment at krbdev.mit.edu Wed Feb 25 04:53:36 2004 From: rt-comment at krbdev.mit.edu ( via RT) Date: Wed, 25 Feb 2004 04:53:36 -0500 (EST) Subject: [krbdev.mit.edu #2280] Now is the perfect time to buy or refinance a home ssphbdqmchnknvcifx In-Reply-To: Message-ID:
Get a Free Quote
Conference Calls
Only 7.9 Cents Per Min.
We offer an extremely easy to use conferencing service that only costs a fraction of what most companies charge.

No Set-up Fees
No Contracts or Monthly Fees
We offer other Conferencing Solutions, Including: Web Conferencing Operator Assist
Best Quality, Lowest Rates
Click Here For More Info

The transmission of this email was sent in accordance with the Can Spam Act
of 2003 Section S.877. The source and routing information attached to this
message are accurate, which means you can reply to this email. To unsubscribe
from future mailings or send your request to our physical address click here.
e v f a hrxuhy wihcmp sile qkohoeocwje dt floxbslse wwusfdqyn njrmkrebo From rt-comment at krbdev.mit.edu Wed Feb 25 05:58:01 2004 From: rt-comment at krbdev.mit.edu (psw@ssl.stu.neva.ru via RT) Date: Wed, 25 Feb 2004 05:58:01 -0500 (EST) Subject: [krbdev.mit.edu #2281] fake In-Reply-To: Message-ID: stuff about you? From rt-comment at krbdev.mit.edu Wed Feb 25 10:15:10 2004 From: rt-comment at krbdev.mit.edu (stakelotterydraw@netscape.net via RT) Date: Wed, 25 Feb 2004 10:15:10 -0500 (EST) Subject: [krbdev.mit.edu #2282] CONGRATULATION(your prize waiting for claim) In-Reply-To: Message-ID: SWEEPSTAKE INTERNATIONAL LOTTERY DRAW. PARKSTR 137, BERLIN - GERMANY FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/03 BATCH: 24/00319/IPD ( CONGRATULATION) DEAR SIR, AWARD NOTIFICATION FINAL NOTICE. We are pleased to inform you of the announcement, of winners of the LOTTERY DRAW SWEEPSTAKES/INTERNATIONAL PROGRAMS held on 4th october,2003.the late release of this result was due to difficulties encountered in sorting out mixed up numbers and email addresses,that is why we have been working 24 hours to see that everything is ok. Your name is attached to ticket number 004-05117963-198, with serial number 99375 drew the lucky numbers 31-33 -34-35-36-42, and consequently,won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of (euros 847,824,) EIGHT HUNDRED AND FOURTY SEVEEN THOUSAND,EIGHT HUNDRED AND TWENTY-FOUR EUROS. in cash credited to file No:LP/26510460037/03.This is from total prize money of EUROS (80,400,000.00,)EIGHTY MILLION FOUR HUNDRED THOUSAND EUROS, shared among the twenty two international winners in this category. All participants were selected through a computer ballot system drawn form 25,000 names and email addresses from Australia, New Zealand, America, Europe, North America and Asia as part of International Promotions Program, which is conducted annually.and is promoted and sponsored by eminent personalities like the Sultan of Brunei,Bill Gates of Microsoft inc and other corporateorganizations. This is to encourage the use of the Internet and computersworldwide. CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, however you are please advise to keep this award away from public notice, until your claim has been processed and your money remitted to your account. This is part of our security protocol to avoid double claiming or unscrupulous acts by participants of this program. We hope with a part of your prize, you will participate in our end of year high stakes Euros 1.1 billion International Lottery. To begin your claim, please contact your claims agent, Mr Peter Van Dyke (FOREIGN OPERATION MANAGERS) at Email:eukreditkommission at whipmail.com Tel:0049-174-5979250For due processing and remittance of your prize money to a designated account with our bankers. Remember, all prize money must be claimed not later than one month. After this date of notice, all funds will be returned as unclaimed. NOTE: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every one of your correspondences with your agent.Furthermore, should there be any change of your address, do inform your claims agent as soon as possible. Congratulations again from all our staff and thank you for being part of our promotions programm. (CONGRATULATION) REGARDS MR T鰎sten Muller MANAGING DIRECTOR From rt-comment at krbdev.mit.edu Wed Feb 25 13:14:04 2004 From: rt-comment at krbdev.mit.edu (Bill Dodd via RT) Date: Wed, 25 Feb 2004 13:14:04 -0500 (EST) Subject: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, start_connection() In-Reply-To: Message-ID: >>>>> "Ken" == Ken Raeburn via > writes: Ken> [resend; my original message didn't get sent to the submitter] Ken> Begin forwarded message: >> From: Ken Raeburn >> Date: Tue Feb 24, 2004 21:27:48 US/Eastern >> To: rt-comment at krbdev.mit.edu >> Subject: Re: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, >> start_connection() >> >> On Tuesday, Feb 24, 2004, at 18:56 US/Eastern, Bill Dodd via RT wrote: >> >>> In start_connection(), if the connect() fails (e.g. with >>> ECONNREFUSED), >>> an error is returned, but the socket is not closed. >> >> Under what circumstances (aside from, maybe, running the client and >> KDC on the same host) can you get back ECONNREFUSED from a connect >> call on a non-blocking socket? Ken, Yes, the client and KDC were on the same host when I saw the ECONNREFUSED. Sorry, I should have said that in my original note. I was thinking there could be other conditions/errors where you could go down that error path, but as you say, that might be a pretty rare condition. >> Seems to me that to get and process >> the ICMP message from another host, the process would have to, well, >> block. I suppose, if the scheduler switched to another process during >> the connect call, it's possible a response from another nearby host >> could come in before the process continued, but it seems like a tricky >> race condition more than a reliable leak. >> >> It's definitely a bug, I'm just trying to get a sense of how serious... >> >>> To observe the leak, set udp_preference_limit to 1 in krb5.conf and >>> run kdc5_hammer with a large repeat count against a kdc that only >>> listens on UDP. Observe the open files/sockets with lsof. A contrived >>> scenario to be sure, but it can be seen in more legitimate cases as >>> well. >> >> Were you testing this with a KDC on the same host, or another host? >> >> Ken >> I just re-ran the same scenario with the client on a different machine than the KDC and hit a different, more severe problem. The client is dying with a "broken pipe" error in writev() in service_tcp_fd(). This is on AIX. I'll have to debug this some more. Thanks for following up, -bill From rt-comment at krbdev.mit.edu Wed Feb 25 15:16:50 2004 From: rt-comment at krbdev.mit.edu (pyledrvr@pitt.edu via RT) Date: Wed, 25 Feb 2004 15:16:50 -0500 (EST) Subject: [krbdev.mit.edu #2283] believe me In-Reply-To: Message-ID: your document is not good From rt-comment at krbdev.mit.edu Wed Feb 25 19:38:09 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Wed, 25 Feb 2004 19:38:09 -0500 (EST) Subject: [krbdev.mit.edu #2277] CVS Commit In-Reply-To: Message-ID: * sendto_kdc.c (start_connection): Close socket if connect() call fails for an unexpected reason. To generate a diff of this commit: cvs diff -r5.374 -r5.375 krb5/src/lib/krb5/os/ChangeLog cvs diff -r5.65 -r5.66 krb5/src/lib/krb5/os/sendto_kdc.c From rt-comment at krbdev.mit.edu Wed Feb 25 20:09:12 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Wed, 25 Feb 2004 20:09:12 -0500 (EST) Subject: [krbdev.mit.edu #2284] Replay cache not used in GSS_C_NO_CREDENTIAL case In-Reply-To: Message-ID: Apparently the context flags are set incorrectly and the replay cache is not used in the GSS_C_NO_CREDENTIAL case. I am declaring this bug not a blocker for 1.3.2 although it is fairly serious. From rt-comment at krbdev.mit.edu Wed Feb 25 22:39:31 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Wed, 25 Feb 2004 22:39:31 -0500 (EST) Subject: [krbdev.mit.edu #2285] test TCP access to KDC In-Reply-To: Message-ID: The test suite currently doesn't test TCP access to the KDC. Fix that. Try tweaking udp_preference_limit (see ticket 2277) and/or port numbers to force TCP to be used. Initial experimentation suggests we've got some bugs in correctly establishing TCP listening sockets in fast-restart situations like the test suite creates. From rt-comment at krbdev.mit.edu Wed Feb 25 22:43:06 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Wed, 25 Feb 2004 22:43:06 -0500 (EST) Subject: [krbdev.mit.edu #2285] CVS Commit In-Reply-To: Message-ID: * network.c (setup_a_tcp_listener): Call setreuseaddr before calling bind. (setup_tcp_listener_ports): Don't call setreuseaddr. Log info about socket option IPV6_V6ONLY in unsupported and success cases. To generate a diff of this commit: cvs diff -r5.273 -r5.274 krb5/src/kdc/ChangeLog cvs diff -r5.56 -r5.57 krb5/src/kdc/network.c From rt-comment at krbdev.mit.edu Wed Feb 25 23:19:28 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Wed, 25 Feb 2004 23:19:28 -0500 (EST) Subject: [krbdev.mit.edu #2285] CVS Commit In-Reply-To: Message-ID: * default.exp (passes): Add "mode=udp" to existing pass specifications. Add a new pass which does AES and "mode=tcp". (setup_kerberos_files, setup_krb5_conf): Check global var "mode" and use it to force UDP or TCP communication between client and KDC. Also, have clients try another random port where we don't expect anything to be listening. To generate a diff of this commit: cvs diff -r1.86 -r1.87 krb5/src/tests/dejagnu/config/ChangeLog cvs diff -r1.90 -r1.91 krb5/src/tests/dejagnu/config/default.exp From rt-comment at krbdev.mit.edu Thu Feb 26 02:19:50 2004 From: rt-comment at krbdev.mit.edu ( Marcella Bassett via RT) Date: Thu, 26 Feb 2004 02:19:50 -0500 (EST) Subject: [krbdev.mit.edu #2287] How to cash in on other people's success In-Reply-To: Message-ID: 1 84.248.108.216

 

Affiliate programs were never this easy in the past. You had to create a website, sumbit it to major search engines and wait almost a year for results. With my program you won't have to worry about any of this.

no more emails please

From rt-comment at krbdev.mit.edu Thu Feb 26 05:26:49 2004 From: rt-comment at krbdev.mit.edu (sales1_can@uif.com.hk via RT) Date: Thu, 26 Feb 2004 05:26:49 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232288=5D_=B8=B4_?= In-Reply-To: Message-ID: UNITEX LOGISTICS LIMITED/MS ELAINE ZHANG Asia to Canada Effective: 17 Feb 04 Rate Matrix Vancouver Tor/Mon Load Port 20' 40' 40'hc 20' 40' 40'hc HK / Chiwan / Yantian 1390 1850 2025 2065 2750 2925 Shanghai 1675 2200 2375 2350 3100 3275 Ningbo 1750 2300 2475 2425 3200 3375 Qingdao 1715 2250 2425 2390 3150 3325 Xingang 1715 2250 2425 2390 3150 3325 Dalian 1750 2300 2475 2425 3200 3375 Xiamen 1790 2350 2525 2465 3250 3425 Above rates are subject to EBA USD35/20' , 45/40' , 50'/40'HQ /DOC FEE shipment. Above rates are subject to origin THC/CTHC/ORC. Above rates are valid till end of April 04 Above rates are inclusive of SPS (Shanghai Port Surcharge). UNITEX ADVANTAGE LINE OF SHIPPING: MIDDLE EAST，INDIA， MEDITERRANEAN， AUSTRALIA, YOU ARE WELCOME TO ASK US ANY QUESTION ABOUT SHIPPING! Pls feel free to contact us if you want any information from us! Best Regards! elaine Tel:86-020-38202212 Fax:86-020-38201846 E-mail:sales1_can at uif.com.hk UNITEX LOGISTICS LIMITED Guangzhou Office ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Thu Feb 26 06:44:08 2004 From: rt-comment at krbdev.mit.edu ("antonelladicristofaro@katamail.com" via RT) Date: Thu, 26 Feb 2004 06:44:08 -0500 (EST) Subject: [krbdev.mit.edu #2289] add_to_mail_list In-Reply-To: Message-ID: Please add to mail list for krb5-bugs From rt-comment at krbdev.mit.edu Thu Feb 26 09:06:41 2004 From: rt-comment at krbdev.mit.edu (szone@163.com via RT) Date: Thu, 26 Feb 2004 09:06:41 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=23?= =?iso-8859-1?q?2290=5D_=BF=CE=B3=CC=D1=FB=C7=EB=BA=AF_?= In-Reply-To: Message-ID:
Mortgage Loans Made Easy
Absolute Lowest Rates Possible
There has never been a better time to purchase or refinance a home. We work with a number of banks to find the lowest rates regardless of credit. Take advantage of the economy while you can. This may be the last time we see rates like this again!
Apply Today, It's Free
100% Financing Available
30 Yr. Loans @ 4.80%
580 - Full Doc
620 - Stated

100% Interest Only Purchase Loans Available

To Fill Out Our Simple Online Application
Click Here

It's strictly private and 100% confidential. No Home Ownership required!

The transmission of this email was sent in accordance with the Can Spam Act
of 2003 Section S.877. The source and routing information attached to this
message are accurate, which means you can reply to this email. To unsubscribe
from future mailings or send your request to our physical address click here.

 课程1、年度纳税清缴与节税筹划技巧（深圳•3月13～14日）
 课程2、全面削减采购成本与采购控制（深圳•2月28～29日）

年度纳税清缴与节税筹划技巧
——纳税筹划实操技巧与实例分析高级研修班
第3期 • 邀请函
  课程背景                                   查看大纲      报名表格
【技术背景】

　　一个能大幅降低成本的课程，税务专家直言企业有15—20%的节税空间；
　　一个最快产生效益且投入后能立即产生回报的课程，合理避税能直接为企业提升10-25%的纯利润!
    企业从创立、投资、生产、销售、利润分配、员工薪酬激励机制及解散等每一个环节都涉及到纳税问题。税是企业的一项重要成本，如何开源节流，节省纳税成本，是企业提高经营管理水平和会计管理水平，实现利润最大化的重要手段。纳税筹划可帮助企业减低税负，为企业纳税作出最佳的财务方案，看得见，摸得着，易操作。
   为帮助企业学习、掌握纳税筹划的基本知识、原则、条件和操作技巧，了解运用好现行税收政策，在4月前做好所得税筹划方案，避免“临时抱佛脚”造成多交、错交甚至被税务机关罚款的遗憾，安德盛推出由被授予“2001年世界名人”称号的国内顶级纳税筹划专家余教授主讲的“年度纳税清缴与节税筹划技巧”高级研修班第3期，使更多企业了解符合国际惯例的合理避税知识，掌握纳税筹划方法，提高纳税筹划的实际操作能力，在合法的前提下减轻纳税负担，实现企业利润最大化！

【课程收益】

  1、与国内顶级纳税筹划专家及众多财务精英面对面交流，正确理解与运用税收政策，学习税改后的避税思路，
     重点把握避税成本与避税界限；
  2、从大量实际案例分析中，掌握实用避税技巧和方法，挖掘本企业内在的税收筹划潜质；
  3、有效掌握成功避税的基本要求及相应策略，全面提升避税筹划能力与操作技巧；
  4、有效运用我国现行税种差别和税收优惠政策降低企业税负成本！

【讲师介绍】
  余教授：中国第一部《纳税筹划技巧》作者，教授、税务师、高级会计师
   曾从事过10多年的税务稽查工作，有丰富的税务稽查经验。现任广东某纳税筹划研究所所长及多家企业财税顾问,中山大学企管研究所纳税筹划实务操作班主讲老师。曾在制造、销售、服务等性质的多家中、外资知名集团公司、大型零售企业任副总经理、财务总监，在财务与会计管理、公司税务管理、内部控制及稽核方面、成本控制、投资管理等方面有着深入研究及丰富实战经验。曾著作《成本会计》等多本专著，并多次在《广东财会》发表《有效实施内部会计控制与监督》、《关于费用预算的两种改进方法的普及》等近10篇论文。
  曾培训或咨询的企业：可口可乐、宝洁、广州本田、朗讯科技、亚信、松下、科龙、美晨股份、广东移动、健力宝、三星、TCL、深圳三和集团、先科、天音通讯、丽斯达日化、西仕服饰等200多家企业。
【参加对象】
    公司董事会、监事会成员 ,公司总经理、副总经理、财务总监、会计师、财务部经理(主管)、审计、会计、办税员及各部门中高层管理者。
  课程大纲                                    课程背景     报名表格

 第一部分 纳税筹划技术
  1、企业设立、采购、生产、销售、清算各环节的节税筹划方法
  2、企业再投资、分立、筹/融资、并购、资产重组中的节税筹划方法
  3、价格转移、费用分摊、存货计价的纳税筹划方法
  4、固定资产投资与折旧计提、资产租赁的纳税筹划方法
  5、跨国企业的经营环节的纳税筹划方法与技巧
  6、企业主要征缴税种的合理避税方法及案例分析
     1) 增值税      2) 营业税      3) 个人所得税
     4) 消费税      5) 关税        6) 内资企业所得税
     7) 外商投资企业、外国企业所得税
  7、纳税身份的认定与选择技巧
  8、征收方式的选择对企业效益的影响
  9、税收筹划典型案例分析：
     1）运费降低税负    2）扩大生产规模     3）让利促销
  10、最新税法政策动态与企业应对策略
     • 税前列支工资的在职人员的确定      • 对纳税人虚报亏损的处罚
     • 从被投资企业分回利润的纳税办法    • 弥补亏损处理
     • 对核定征收企业的有关所得税处理    • 对高新技术企业、技术创新优势企业的税收管理
     • 以个人名义购置的资产或承租个人名义的资产的处理
 第二部分 年度纳税清缴的做法
  1、国、地税务机关对企业年度纳税汇算清缴的范围、期限、规定和要求
  2、税务对企业所得税申报的重点审核项目
  3、所得税汇缴申报后税务机关对纳税人检查的重点
  4、企业所得税表格（主表和9大附表）的填写技巧
 

全面削减采购成本与采购控制
——切入采购成本的第二度空间——
第3期 • 邀请函

  课程背景                                  查看大纲      报名表格
【技术背景】
    多年以来，斯玛托集团公司的陈先生一直是采购部的英雄，作为采购部的价格杀手，他为公司在原材料成本控制方面立下了汗马功劳。今年开始，陈先生感觉似乎大不如以前,他那犀利的快刀,似乎再也很难在供应商的供货价格上劈开一个口子。更让人难堪的是他成功开发的几个供应商最近出了严重的质量事故，这导致客户的索赔，供应商等级也降到了C级。供应商托词说，为了保持一定的利润，选用了另外一间价格便宜的供货商，所以才会这样。一向对陈先生赞赏有加的公司总经理也没有说什么，但陈先生看得出他好像没以前那么重要了。
    陈先生的故事每天都在发生。的确，成本是采购人员心里"永远的痛"，采购人员无时无刻不面临成本的压力。
切入采购成本第二度空间的现代采购技术，它成功地运用价值工程和供应链的思想，以库存、交期、采购成本解析、不良采购成本控制等等综合的供应商管理方法大幅削减采购成本。本课程以现代的最新采购技术为基础，辅以大量跨国公司的实际案例的研讨，具有非常强的实用性和可操作性。
【课程效果】
    PHILIPS 已经有很多的同事都非常满意汤老师的培训，我感到两天的培训学习到了很多理论与实践结合的知识。                                                      —— 飞利蒲家庭电器工业成本工程师 胡凤强
    前一天理念与方法结合第二天的实践操作，是上海通用汽车最成功的培训之一。   ——SGM 采购经理 许兵
    课程非常好 , 观点新颖，方法实用，我会向我同事推荐 。          —— 可口可乐公司生产总监 熊海珊
    这个课程提供了很多有效的综合降低采购成本的方法，非常实战。   —— 顶新国际集团采购经理 张庆才

【讲师介绍】
   汤先生：
    美国最大的培训公司ALAMO公司在华特邀授课人，是ALAMO在中国培训、认证和授权的培训师。曾在NEC任职采购部长7年，在日本接受过最先进的采购和库存管理教育，并在HP等跨国企业担任高层管理。在制造企业的采购设计和库存控制方面积累了丰富的经验。通过其设计的采购和库存控制方案，企业有效的控制了采购成本、减少了库存、降低了呆滞物料、生产停线也得到了改善。1999年开始向企业提供采购咨询和培训。
    他培训过的企业包括：西门子、美国泛达集团大中华采购中心、飞利浦、德国拜耳、纳贝斯克(中国)公司、西屋电气(中国)公司、美国史丹利公司、TCL、UT斯达康(中国)公司、东风汽车、一汽集团、实达医疗系统等。
【参加对象】
    高级管理层、采购部经理、主管、财务部经理、厂长以及生产、计划、物控 /PMC、供应商管理等部门经理和相关人员
  课程大纲                                    课程背景     报名表格

一、新型的采购成本控制方法和理念(实例分析)
  • 采购管理的4大误区
  • 采购新型理念和国际先进采购理念
  • 国外公司采购管理现状与国内企业如何结合
二、采购战略与产品及市场分析
  • 采购战略：同步、集中、全球和系统开发模块
  • 案例：欧洲工业、德国大众与采购战略
  • 产品的功能要求和产品寿命周期
  • 市场的不同类型及市场中的需求与供应
三、利用库存控制技术和丰田供应链理念
  • 控制技术的6种方法与案例分析
  • 天津丰田物流思想
四、解析采购总成本，寻求成本控制的途径
  • 供货商价格成本构成和分析(案例操作)
  • 供应商价格变动的影响因素
  • 价格指数变动的跟踪与采购价格的调整
  • 采购批量变动与价格折扣
  • 质量、服务、交货期的比价定量评审
  • 采购总成本构成分析及影响采购成本的因素
  • 降低采购成本的主要途径(实例分析)
  • 零库存(寄售库存)及其实施途径

  • 如何知道供应商报价“底线”(实例分析)
  • 分解和细化报价与专业报价技巧
  • 模糊报价获得底价的技巧
  • 降低成本21种方法
  • 成本分析与报价单审核25条经验
  • 供应商提高价格21条原因
  • 如何得到供应商“可能的底价”的24条经验
五、管理供应商，控制不良采购成本
  • 著名企业供应商管理的4种有效方法
  • 案例：A公司供应商选择
  • 附：水平测量案例
  • 转换供应商16条注意事项
六、策略性采购谈判
  • 双砖头模型
  • 采购企业的势力和采购谈判过程分析
  • 环境分析、风险分析及行为预测
  • 谈判中的信息交流与应用
  • 操纵信息、时间、情绪的技巧
  • 谈判的其它技巧
七、与其它业务部门协作控制采购成本

报名表格                    财务课程     采购课程     报名表下载
【会议安排】

   主办机构：深圳安德盛企管顾问公司
    协办单位：安德盛(香港)國際管理顧問公司
   时　　间：课程1：年度纳税清缴与节税筹划技巧 2004年3月13～14日(周六、日)(上午9：00-下午5：15)
             课程2：全面削减采购成本与采购控制 2004年2月28～29日(周六、日)(上午9：00-下午5：15)
   会议地点：深圳福田
   报名热线：0755-82964967、82965019、82942024   
   报名传真：0755-82965019   E-mail: adschina at 163.com    szone@sohu.com
   报名方法：请将《报名确认函》填妥并盖章后传真至主办单位82965019，您将收到我们的《报名确认回执》
              及会议地点路线图，费用请会前银行转帐或在培训现场交付现金。
   学习投资：RMB1460/人/课题，3人以上1310元/人/课题(含专家演讲费、两日午餐费、教材、茶水费)
           
                           参会报名确认函（复印有效）  

公司现确认派员参加贵公司举办的以下题高级研讨会：
公司名称： 地址：
经办人姓名：                   （先生/小姐）
部门及职务：
传真：
电   话：
E-mail：
 参加课程
(采购/财务)
参加人姓名
性别
职 务
手 机 /电 话
E-mail
           
           
           
           

您希望的付款方式： （请打√） □ 转帐 □ 现金 □ 支票

尊敬的朋友，打搅了，如果您不想再收到培训会讯邮件，请点击这里告诉我！顺祝财源广进，万事如意！ From rt-comment at krbdev.mit.edu Thu Feb 26 10:12:30 2004 From: rt-comment at krbdev.mit.edu ( Stacey Bean via RT) Date: Thu, 26 Feb 2004 10:12:30 -0500 (EST) Subject: [krbdev.mit.edu #2291] watches , FREE shipping In-Reply-To: Message-ID:

Please note to send ALL REPLY e-mail direct to our Sales Representative at: 
questions at watches.netpublications.net 

Hi,
 
Thank you for expressing interest in ATGWS watches.

We would like to take this opportunity to offer you our fine selection of Italian crafted Rolex Timepieces.
 
You can view our large selection of Rolexes (including Breitling, Tag Heuer, Cartier etc) at:

http://watches.netpublications.net/ 

For all orders placed in the month of February, all shipping and handling charges will be free.
 
As we are the direct manufacturers, you are guaranteed of lowest prices and highest quality each and every time you purchase from us.
 
You may also be interested to know that we have the following brands available in our wide selection as well: 

1. Rolex (Both Mens and Ladies)
2. Blancpain
3. Fortis
4. Jaeger LeCoutre
5. Longines
6. Mont Blanc
7. Movado
8. Oris
9. Roger Dubuis
10. Ulysse
11. Zenith
12. Audemar Piguet
13. Breitling
14. Bvglari
15. Cartier
16. Corum
17. Dunhill
18. Franck Muller
19. Gerard Perregaux
20. IWC
21. IWC
22. Panerai
23. Patek Philippe
24. Tag Heuer
25. Vacheron Constantin
 
If you see anything that might interest you, or if you have any questions, please don't hesitate to visit our website at:

http://watches.netpublications.net 

I certainly look forward to hearing from you.

Best regards,

Cal

Division Sales Manager
ATGWS 
  
You received this email because your have previous purchased from, or inquired about our product line under ATGWS. If you do not want to receive further mailings from ATGWS, unsubscribe by sending an email with the title heading: DELETE in the subject line to unsubscribe at watchespublications.net  

Please note to send ALL REPLY e-mail direct to our Sales Representative at:
questions at watches.netpublications.net

From rt-comment at krbdev.mit.edu Thu Feb 26 12:57:30 2004 From: rt-comment at krbdev.mit.edu (ppp-request@zzz.org via RT) Date: Thu, 26 Feb 2004 12:57:30 -0500 (EST) Subject: [krbdev.mit.edu #2292] hi In-Reply-To: Message-ID: is that true? From rt-comment at krbdev.mit.edu Thu Feb 26 15:02:05 2004 From: rt-comment at krbdev.mit.edu ( Elma Camp via RT) Date: Thu, 26 Feb 2004 15:02:05 -0500 (EST) Subject: [krbdev.mit.edu #2293] Make a secure income with Google In-Reply-To: Message-ID: 240.173.52.240

 

With my proven strategies you'll make more money online than most other web sites do and you won't even need to have a website!

I don't want more emails

From rt-comment at krbdev.mit.edu Thu Feb 26 16:52:08 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 26 Feb 2004 16:52:08 -0500 (EST) Subject: [krbdev.mit.edu #2284] CVS Commit In-Reply-To: Message-ID: Set context flags after calling krb5_rd_req so that the replay cache is set up. To generate a diff of this commit: cvs diff -r1.238 -r1.239 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.85 -r1.86 krb5/src/lib/gssapi/krb5/accept_sec_context.c From bdodd at austin.ibm.com Wed Feb 25 13:13:09 2004 From: bdodd at austin.ibm.com (Bill Dodd) Date: 25 Feb 2004 12:13:09 -0600 Subject: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, start_connection() In-Reply-To: References: Message-ID: >>>>> "Ken" == Ken Raeburn via > writes: Ken> [resend; my original message didn't get sent to the submitter] Ken> Begin forwarded message: >> From: Ken Raeburn >> Date: Tue Feb 24, 2004 21:27:48 US/Eastern >> To: rt-comment at krbdev.mit.edu >> Subject: Re: [krbdev.mit.edu #2277] socket leak in sendto_kdc.c, >> start_connection() >> >> On Tuesday, Feb 24, 2004, at 18:56 US/Eastern, Bill Dodd via RT wrote: >> >>> In start_connection(), if the connect() fails (e.g. with >>> ECONNREFUSED), >>> an error is returned, but the socket is not closed. >> >> Under what circumstances (aside from, maybe, running the client and >> KDC on the same host) can you get back ECONNREFUSED from a connect >> call on a non-blocking socket? Ken, Yes, the client and KDC were on the same host when I saw the ECONNREFUSED. Sorry, I should have said that in my original note. I was thinking there could be other conditions/errors where you could go down that error path, but as you say, that might be a pretty rare condition. >> Seems to me that to get and process >> the ICMP message from another host, the process would have to, well, >> block. I suppose, if the scheduler switched to another process during >> the connect call, it's possible a response from another nearby host >> could come in before the process continued, but it seems like a tricky >> race condition more than a reliable leak. >> >> It's definitely a bug, I'm just trying to get a sense of how serious... >> >>> To observe the leak, set udp_preference_limit to 1 in krb5.conf and >>> run kdc5_hammer with a large repeat count against a kdc that only >>> listens on UDP. Observe the open files/sockets with lsof. A contrived >>> scenario to be sure, but it can be seen in more legitimate cases as >>> well. >> >> Were you testing this with a KDC on the same host, or another host? >> >> Ken >> I just re-ran the same scenario with the client on a different machine than the KDC and hit a different, more severe problem. The client is dying with a "broken pipe" error in writev() in service_tcp_fd(). This is on AIX. I'll have to debug this some more. Thanks for following up, -bill From rt-comment at krbdev.mit.edu Fri Feb 27 00:05:06 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 27 Feb 2004 00:05:06 -0500 (EST) Subject: [krbdev.mit.edu #2295] CVS Commit In-Reply-To: Message-ID: * gss-client.c: change if (this) if (that) => if (this && that) To generate a diff of this commit: cvs diff -r1.70 -r1.71 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.29 -r1.30 krb5/src/appl/gss-sample/gss-client.c From rt-comment at krbdev.mit.edu Fri Feb 27 00:24:43 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 27 Feb 2004 00:24:43 -0500 (EST) Subject: [krbdev.mit.edu #2296] CVS Commit In-Reply-To: Message-ID: As discussed on the krbdev mailing list, krb5_get_init_creds_password() suffered from a behavior in which it would unintentionally query a master KDC twice if in fact the KDC queried when krb5int_sendto() was called with use_master = 0 was in fact the master. This resulted in more than an additional protocol operation. There were two negative side effects. First, in the case of an incorrect password there would be two counts against the max retry attempts. Second, in the case of hardware pre-auth and an expired password, the user would be asked to enter their expired password twice before being told it was expired. This has been fixed by changing the use_master parameter into an in/out parameter and modifying krb5int_sendto() to indicate which KDC it received the response from. This allows the use_master parameter to be set to indicate whether or not the response came from a master KDC regardless of whether a master KDC was requested. To generate a diff of this commit: cvs diff -r1.403 -r1.404 krb5/src/include/ChangeLog cvs diff -r1.157 -r1.158 krb5/src/include/k5-int.h cvs diff -r1.196 -r1.197 krb5/src/lib/krb4/ChangeLog cvs diff -r1.15 -r1.16 krb5/src/lib/krb4/send_to_kdc.c cvs diff -r5.430 -r5.431 krb5/src/lib/krb5/krb/ChangeLog cvs diff -r5.109 -r5.110 krb5/src/lib/krb5/krb/get_in_tkt.c cvs diff -r5.14 -r5.15 krb5/src/lib/krb5/krb/gic_keytab.c cvs diff -r5.25 -r5.26 krb5/src/lib/krb5/krb/gic_pwd.c cvs diff -r5.55 -r5.56 krb5/src/lib/krb5/krb/send_tgs.c cvs diff -r5.375 -r5.376 krb5/src/lib/krb5/os/ChangeLog cvs diff -r5.2 -r5.3 krb5/src/lib/krb5/os/send524.c cvs diff -r5.66 -r5.67 krb5/src/lib/krb5/os/sendto_kdc.c From rt-comment at krbdev.mit.edu Fri Feb 27 04:36:23 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Fri, 27 Feb 2004 04:36:23 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232297=5D_?= =?iso-8859-1?q?=D4=B8=CE=D2=BB=AA=C1=AA=CD=A8=A3?= =?iso-8859-1?q?=AC=B0=E9=C4=FA=C2=B7=C2=B7=CD=A8_?= In-Reply-To: Message-ID: 安在家中坐，货发五大洲。 愿我华联通，伴您路路通！ FROM：王斌斌 TEL：86-20-87567052 FAX：86-20-87561768 ****** SERVICE NYK (MELBOURNE 11天/SYDNEY 13天/BRISBANE 15 天) USD1230/2430/2460+DOC 赤湾周三截、周五开船 SERVICE RCL (FREMANTLE 14天） USD1230/2140/2140+DOC 赤湾周六截 ****** HUANGPU (黄埔)- DUBAI: 950/1830/1830（PORT RASHID & JEBEL ALI） ALL IN, 只需加文件费(USD15/SET). 以上价格，可以尽量的满足大家的舱位要求！我会尽最大的 努力为大家取得舱位的！努力！努力！努力！努力！努力！ 谢谢支持！ ------------------------------------------------------------ ====以下内容与本邮无关==== 你想在网上自动搜索到你的目标用户吗？一致推荐：“商务探测专家” 你想将你的产品信息直发到你的目标用户邮箱吗？ “商务邮件特快” 实现你的需求—— 无需SMTP，集邮件群发、管理、校验、退订于一身的为适应向国际上各个不同国家发送商务邮件而制作的功能全面、速度奇快、性能稳定的群发软件。本邮件与软件作者无关，仅限用于合法用途！欢迎下载免费试用：http://software.9900.cn在线帮助OICQ：147779246 From rt-comment at krbdev.mit.edu Fri Feb 27 09:35:17 2004 From: rt-comment at krbdev.mit.edu ("antonelladicristofaro@katamail.com" via RT) Date: Fri, 27 Feb 2004 09:35:17 -0500 (EST) Subject: [krbdev.mit.edu #2298] Help! In-Reply-To: Message-ID: HELLO! CAN YOU HELP ME? I HAVE A "LITTLE" PROBLEM WITH KERBEROS V5!! MY CONFIGURATION FILES ARE: *****kdc.conf**** [kdcdefaults] kdc_ports = 749, 88 [realms] MYREALM.IT= { dict_file = /usr/share/dict/words database_name = /var/kerberos/krb5kdc/principal admin_keytab = FILE:/var/kerberos/krb5kdc/kadm5.keytab acl_file = /var/kerberos/krb5kdc/kadm5.acl key_stash_file = /var/kerberos/krb5kdc/.k5.MYREALM.IT max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des-cbc-crc supported_enctypes = des-cbc-crc:normal des3-cbc-raw:normal des3-cbc-sha1:normal des-cbc-crc:v4 des-cbc-crc:afs3 } [logging] kdc = FILE:/var/kerberos/krb5kdc/kdc.log admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log *****krb5.conf**** [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MYREALM default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc ticket_lifetime = 36000 dns_lookup_realm = false dns_lookup_kdc = false noaddresses = false [realms] MYREALM= { kdc = host.domain.myrealm.it:88 admin_server = host.domain.myrealm.it:749 default_domain = myrealm.it } [domain_realm] .it = MYREALM.IT it = MYREALM.IT host.domain.myrealm.it = MYREALM.IT host.domain.myrealm=MYREALM.IT host.domain= MYREALM.IT host= MYREALM.IT [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [pam] debug = true ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false [appdefaults] kinit = { forwardable = true } telnet = { forward = true encrypt = true autologin = true } THE DEAMONS STARTING CORRECTLY. THE LOG FILE (ON KDC) SHOWS THAT BOTH THE TICKET-GRANTING-TICKET BOTH THE HOST TICKET ARE GENERATED, infact: ****Krb5kdc.log**** setting up network... listening on fd 7: A.B.C.D port 749 listening on fd 8: A.B.C.D port 88 set up 2 sockets commencing operation AS_REQ A.B.C.D(88): ISSUE: authtime 1077875078, anto78/admin at MYREALM.IT for krbtgt/MYREALM.IT @MYREALM.IT TGS_REQ A.B.C.D(88): ISSUE: authtime 1077875078, anto78/admin at MYREALM.IT for host/host.domain.myrealm.it at MYREALM.IT I HAVE AN ERROR MESSAGE ON THE CLIENT: I HAVE GETTING A FORWARDABLE TICKET WITH kinit -f BUT WHEN I TRY TO TELNET WITH telnet -a -x -f host.domain.myrealm.it I READ THE FOLLOWING: Trying A.B.C.D.... Connected to host.domain.myrealm.it (A.B.C.D). Escape character is '^]'. Waiting for encryption to be negotiated. [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] Authentication negotiation has failed, which is required for encryption. Good Bye. PLEASE, HELP ME! I HAVE CONTROLLED KEY VERSION NUMBER WITH: klist -ke AND ANY PRINCIPAL HAVE A KEY NUMBER, BUT I HAVEN'T UNDERSTOOD IF IT IS A CASUAL NUMBER OR A SPECIFIC NUMBER, AND I DON'T KNOW HOW TO RESOLVE THE PROBLEM! THANKS, Antonella. From rt-comment at krbdev.mit.edu Fri Feb 27 09:37:56 2004 From: rt-comment at krbdev.mit.edu ("antonelladicristofaro@katamail.com" via RT) Date: Fri, 27 Feb 2004 09:37:56 -0500 (EST) Subject: [krbdev.mit.edu #2298] Help! In-Reply-To: Message-ID: HELLO! CAN YOU HELP ME? I HAVE A "LITTLE" PROBLEM WITH KERBEROS V5!! MY CONFIGURATION FILES ARE: *****kdc.conf**** [kdcdefaults] kdc_ports = 749, 88 [realms] MYREALM.IT= { dict_file = /usr/share/dict/words database_name = /var/kerberos/krb5kdc/principal admin_keytab = FILE:/var/kerberos/krb5kdc/kadm5.keytab acl_file = /var/kerberos/krb5kdc/kadm5.acl key_stash_file = /var/kerberos/krb5kdc/.k5.MYREALM.IT max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des-cbc-crc supported_enctypes = des-cbc-crc:normal des3-cbc-raw:normal des3-cbc-sha1:normal des-cbc-crc:v4 des-cbc-crc:afs3 } [logging] kdc = FILE:/var/kerberos/krb5kdc/kdc.log admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log *****krb5.conf**** [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MYREALM default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc ticket_lifetime = 36000 dns_lookup_realm = false dns_lookup_kdc = false noaddresses = false [realms] MYREALM= { kdc = host.domain.myrealm.it:88 admin_server = host.domain.myrealm.it:749 default_domain = myrealm.it } [domain_realm] .it = MYREALM.IT it = MYREALM.IT host.domain.myrealm.it = MYREALM.IT 牋牋牋牋host.domain.myrealm=MYREALM.IT 牋牋牋牋host.domain= MYREALM.IT host= MYREALM.IT [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [pam] debug = true ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false [appdefaults] kinit = { forwardable = true } telnet = { forward = true encrypt = true autologin = true } THE DEAMONS STARTING CORRECTLY. THE LOG FILE (ON KDC) SHOWS THAT BOTH THE TICKET-GRANTING-TICKET BOTH THE HOST TICKET ARE GENERATED, infact: ****Krb5kdc.log**** setting up network... listening on fd 7: A.B.C.D port 749 listening on fd 8: A.B.C.D port 88 set up 2 sockets commencing operation AS_REQ A.B.C.D(88): ISSUE: authtime 1077875078, anto78/admin at MYREALM.IT for krbtgt/MYREALM.IT @MYREALM.IT TGS_REQ A.B.C.D(88): ISSUE: authtime 1077875078, anto78/admin at MYREALM.IT for host/host.domain.myrealm.it at MYREALM.IT I HAVE AN ERROR MESSAGE ON THE CLIENT: I HAVE GETTING A FORWARDABLE TICKET WITH 牋牋牋kinit -f BUT WHEN I TRY TO TELNET WITH 牋牋牋telnet -a -x -f host.domain.myrealm.it I READ THE FOLLOWING: Trying A.B.C.D.... Connected to host.domain.myrealm.it (A.B.C.D). Escape character is '^]'. Waiting for encryption to be negotiated. [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] Authentication negotiation has failed, which is required for encryption. Good Bye. PLEASE, HELP ME! I HAVE CONTROLLED KEY VERSION NUMBER WITH: 牋牋爇list -ke AND ANY PRINCIPAL HAVE A KEY NUMBER, BUT I HAVEN'T UNDERSTOOD IF IT IS A CASUAL NUMBER OR A SPECIFIC NUMBER, AND I DON'T KNOW HOW TO RESOLVE THE PROBLEM! THANKS, Antonella. From rt-comment at krbdev.mit.edu Fri Feb 27 10:43:02 2004 From: rt-comment at krbdev.mit.edu ("antonelladicristofaro@katamail.com" via RT) Date: Fri, 27 Feb 2004 10:43:02 -0500 (EST) Subject: [krbdev.mit.edu #2298]!!! In-Reply-To: Message-ID: HELLO! CAN YOU HELP ME? I HAVE A "LITTLE" PROBLEM WITH KERBEROS V5!! MY CONFIGURATION FILES ARE: *****kdc.conf**** [kdcdefaults] kdc_ports = 749, 88 [realms] MYREALM.IT= { dict_file = /usr/share/dict/words database_name = /var/kerberos/krb5kdc/principal admin_keytab = FILE:/var/kerberos/krb5kdc/kadm5.keytab acl_file = /var/kerberos/krb5kdc/kadm5.acl key_stash_file = /var/kerberos/krb5kdc/.k5.MYREALM.IT max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des-cbc-crc supported_enctypes = des-cbc-crc:normal des3-cbc-raw:normal des3-cbc-sha1:normal des-cbc-crc:v4 des-cbc-crc:afs3 } [logging] kdc = FILE:/var/kerberos/krb5kdc/kdc.log admin_server = FILE:/var/kerberos/krb5kdc/kadmin.log *****krb5.conf**** [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = MYREALM default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc ticket_lifetime = 36000 dns_lookup_realm = false dns_lookup_kdc = false noaddresses = false [realms] MYREALM= { kdc = host.domain.myrealm.it:88 admin_server = host.domain.myrealm.it:749 default_domain = myrealm.it } [domain_realm] .it = MYREALM.IT it = MYREALM.IT host.domain.myrealm.it = MYREALM.IT host.domain.myrealm=MYREALM.IT host.domain= MYREALM.IT host= MYREALM.IT [kdc] profile = /var/kerberos/krb5kdc/kdc.conf [pam] debug = true ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false [appdefaults] kinit = { forwardable = true } telnet = { forward = true encrypt = true autologin = true } THE DEAMONS START CORRECTLY. THE LOG FILE (ON KDC) SHOWS THAT BOTH THE TICKET-GRANTING-TICKET BOTH THE HOST TICKET ARE GENERATED, infact: ****Krb5kdc.log**** setting up network... listening on fd 7: A.B.C.D port 749 listening on fd 8: A.B.C.D port 88 set up 2 sockets commencing operation AS_REQ A.B.C.D(88): ISSUE: authtime 1077875078, anto78/admin at MYREALM.IT for krbtgt/MYREALM.IT @MYREALM.IT TGS_REQ A.B.C.D(88): ISSUE: authtime 1077875078, anto78/admin at MYREALM.IT for host/host.domain.myrealm.it at MYREALM.IT I HAVE AN ERROR MESSAGE ON THE CLIENT: I HAVE GETTING A FORWARDABLE TICKET WITH kinit -f BUT WHEN I TRY TO TELNET WITH telnet -a -x -f host.domain.myrealm.it I READ THE FOLLOWING: Trying A.B.C.D.... Connected to host.domain.myrealm.it (A.B.C.D). Escape character is '^]'. Waiting for encryption to be negotiated. [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] [Kerberos v5 refuses authentication because telnetd: krb5_rd_req failed: key version number for principal in key table is incorrect] Authentication negotiation has failed, which is required for encryption. Good Bye. PLEASE, HELP ME! I HAVE CONTROLLED KEY VERSION NUMBER WITH: klist -ke AND ANY PRINCIPAL HAVE A KEY NUMBER, BUT I HAVEN'T UNDERSTOOD IF IT IS A CASUAL NUMBER OR A SPECIFIC NUMBER, AND I DON'T KNOW HOW TO RESOLVE THE PROBLEM! THANKS, Antonella. From rt-comment at krbdev.mit.edu Fri Feb 27 11:55:26 2004 From: rt-comment at krbdev.mit.edu (cykun76@163.com via RT) Date: Fri, 27 Feb 2004 11:55:26 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232299=5D_=B3=C9=B1=BE=BF=D8=D6=C6_?= In-Reply-To: Message-ID:

　 　　　
　　一　降　再　降

　 　　　　　　　　——最新成本控制解决方案高级辅导课程
　

改变成本核算办法，再创企业低成本竞争优势　
【强烈推荐】
　　
　　一手抓"硬成本"，一手抓"软成本"，没有什么降不了！五羊摩托车公司试过了，实施效果看得到：在2002年总产值比2001年增加20%的前提下，2002年每月平均总运营成本（不含原材料成本）比2001年下降了24.62%！！！
　　想知道他们是怎么做到的吗？遇到了哪些难题，采取了哪些方案？本项目的设计和实施者将现身说法把成功经验与您共同分享。学完本课程，您将有望成为成本管理高手，即使置身不同行业也拥有以不变应万变的能力！因为，您学到的不仅仅是一套最新解决方案，更重要的是学到了最新的成本管理体系思想！
　　独一无二的经验，战无不胜的法宝！一降再降，别人都降了，您还等什么？

【谁应该参加？】
　凡存在下列问题的企业，都能在本课堂找到解决方案

【课程针对问题】
　　
　讲师将演绎其在五羊摩托车和玉柴机器两个企业亲身实施《CSO 2000成本控制体系》的成功案例，理论结合实际讲授国际最新成本管理体系的原理和应用，使学员能够针对性地解决以下问题：
　●　企业每天面对市场价格竞争的沉重压力，是否有有效的方法把内部运营成本降低？
　●　为什么竞争对手的产品价格老是比我低很多? 我的产品价格底线在哪里?
　●　如何核算和控制生产经营过程中的7种浪费：过量生产、等待时间、无效运输、过量库存、低效工序、错误动作、产品缺陷？
　●　为什么财务报表数据不能支持我的成本管理决策？
　●　如何定量地评估ISO 9000质量管理体系在企业的实施效果? 如何提供正确的和准确的质量成本数据给ISO质量管理部门? 如何　　　实现ISO 9004持续改进的要求？
　●　如何面对营销部门不断提出增加预算的既有理又无理的要求，以及有效地和合理地控制销售费用？
　●　如何计算和管理人力资源成本？
　●　什么是你的企业的合理成本结构?
　●　如何科学和合理的制定和分解成本控制指标，既可促进和鼓励员工又能满足公司的目标要求？
　●　如何进行作业成本管理以支持企业的流程再造(BPR)?
　●　如何进行供应链的成本控制？如何进行最优化产品营销组合决策?
　●　ERP在成本管理方面的局限性是什么？
　●　为什么全面预算管理没有效果？
　●　 如何进行真正的全面预算管理？

【讲师简介】
　　林先生，澳大利亚新南威尔士大学国际会计硕士；暨南大学数学系数学专业学士；中国计算机软件工程师；《泛系成本运筹学》的创始人；在中山大学岭南大学和华南师范大学工商管理学院担任EMBA客座教授。
　 　●　培训资历：林先生具备严谨、系统、务实、逻辑性强和幽默的讲授风格，深受学员好评和受益。拥有丰富的管理咨询和培训经验，客户包括朗讯科技、摩恩、苹果电脑、爱立信、广东省移动通信、广州新港等300多家企业。
　　 ●　成功案例：
　　　1、在2001至2002年期间，于广州摩托集团五羊摩托车分公司实施了CSO 2000成本控制体系和作业成本管理软件。实施效果：在2002年总产值比2001年增加20%的前提下，2002年每月平均总运营成本（不含原材料成本）比2001年下降了24.62%。该项目获2003年第十三届广东省企业管理现代化优秀成果二等奖。
　　　2、在2003年下半年，于广西玉柴机器股份有限公司（1994年在美国上市）主持了CSO 2000成本控制体系的管理咨询和实施项目。本项目执行中。
　　 ●　学术论文：作为第一作者于2003年6月在美国国际学报"Advances in Systems Science and Applications"（国际刊号：ISSN 1078-6236）发表文章《作业成本管理的泛系改革》（《Pansystems Cost-Operations Research (PansysCOR):Cost Management System(ABC/M)》；作为第一作者在《计算机与数字工程》杂志发表文章《泛系成本运筹学与应用》。

【报读事宜】
　　课　　时：两天14课时 　　　　　　　　　　　地　　点：广州大华酒店
　　授课时间：3月20-21日（周六、日） 　　　　授课语言：普通话
　　授课对象：企业管理者或者财务负责人 　　　　授课方式：启发式讲授结合案例分析和互动讨论
　　学　　费：2800元/人　　　　　　 　　　　　报名办法：填妥以下报名回执申请表直接网上提交　或　传真至020-38742580
　　汇款账号： 户名:广州世纪阳光顾问有限公司   　　　开户行:广州市商业银行华师大支行　　　帐号：321-8050022-16 

主办单位：广州世纪阳光顾问有限公司

 　联系电话：（020）38742252,38742253-8015 　联系人：程艳坤小姐
　传　　真：（020）38742580 　　　　　　 　　Email：cykun at 21cnsun.com
　
　　　　　　报 　名　 申　 请　 表　　　　
报读课程
单位名称
电话号码
详细地址
传真号码
企业性质
 国营  民营  集体 
外资  合资  上市公司
邮 编
付费方式
 会前银行划帐 会前上门交费 现场交费（不享受优惠）
安排住宿(费用自理): 是 否
姓 　名
性　别
职　　　　位
手 　　　机
E-mail
补充要求或建议
SalesID:  
　　　　　　　　


世纪阳光网主页：http://www.21cnsun.com 　 中国财务总监猎头网：http://www.cncfo.com

From rt-comment at krbdev.mit.edu Fri Feb 27 15:38:39 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 27 Feb 2004 15:38:39 -0500 (EST) Subject: [krbdev.mit.edu #2300] krb5-1.3.2 and HP UX - foreachaddr.c In-Reply-To: Message-ID: HP UX 11i and IA64 HP UX 11.23 define SIOCGLIFCONF and SIOCGLIFNUM, but define the structures used by these features differently. Thus foreachaddr.c does not compile. The comments on the #ifdef imply for Solaris 8 and later only. This patch makes sure the HP versions will not try to use this feature. --- ,foreachaddr.c Mon Sep 29 14:07:29 2003 +++ foreachaddr.c Fri Feb 27 13:21:59 2004 @@ -259,7 +259,7 @@ return ret; } -#ifdef SIOCGLIFCONF /* Solaris */ +#if defined(SIOCGLIFCONF) && !defined(__hpux) /* Solaris */ static int get_lifconf (int af, int s, size_t *lenp, /*@out@*/ char *buf) /*@modifies *buf,*lenp@*/ @@ -431,7 +431,7 @@ return 0; } -#elif defined (SIOCGLIFNUM) /* Solaris 8 and later; Sol 7? */ +#elif defined (SIOCGLIFNUM) && !defined(__hpux) /* Solaris 8 and later; Sol 7? */ static int foreach_localaddr (/*@null@*/ void *data, -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 27 15:38:42 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 27 Feb 2004 15:38:42 -0500 (EST) Subject: [krbdev.mit.edu #2301] krb5-1.3.2 HP UX 11.0 - HAVE_SELECT_H In-Reply-To: Message-ID: HP UX 11.0 does not have a #ifdef HAVE_SELECT_H was added to compat_recv.c The configure.in already tests for this header file. --- ,compat_recv.c Tue Mar 4 19:20:50 2003 +++ compat_recv.c Fri Feb 27 13:20:31 2004 @@ -464,7 +464,9 @@ #endif #endif +#ifdef HAVE_SYS_SELECT_H #include +#endif #include "port-sockets.h" int -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Feb 27 19:35:06 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Fri, 27 Feb 2004 19:35:06 -0500 (EST) Subject: [krbdev.mit.edu #2296] CVS Commit In-Reply-To: Message-ID: * gic_pwd.c (krb5_get_in_tkt_with_password): Fix a case Jeff missed. To generate a diff of this commit: cvs diff -r5.431 -r5.432 krb5/src/lib/krb5/krb/ChangeLog cvs diff -r5.26 -r5.27 krb5/src/lib/krb5/krb/gic_pwd.c From rt-comment at krbdev.mit.edu Sat Feb 28 01:31:12 2004 From: rt-comment at krbdev.mit.edu ( Paulette Spaulding via RT) Date: Sat, 28 Feb 2004 01:31:12 -0500 (EST) Subject: [krbdev.mit.edu #2302] This stock is destined to achieve higher levels iz qtojshvdidn blziw In-Reply-To: Message-ID: Wall Street Financial Times Newsletter Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our picks in 2004: GETC at .12 Currently .50 High .68 UP 467% TLPE at 1.12 Currently 3.35 High 4.40 UP 293% SWYC at .18 Currently .71 High .81 UP 350% DNYY at .47 Currently 1.42 High 1.85 UP 294% Immediate Investor Recommendation Our Hottest Sales and Earnings Play Projected to Triple in 7 Days: Life Energy and Technology Holdings, Inc. (OTCBB: LETH) Price--- 1.35 Sales Orders Received '03--- over $150 Million +300% growth vs. '02 Est. Sales Growth '04--- +165% Results from latest 10-Q: Total Assets--- 36.8 million vs. 16.8 million Cash--- 23.4 million vs. deficit Shareholders Equity--- 12.0 million vs. 2.2 million Shares Outstanding--- 29 mill Est. Shares in Float--- 7 mill Proj. Value Per Share--- 3.25 -- 3.50 Rating--- Urgent Buy LETH is thriving as an emerging world leader in the conversion of waste materials into electrical energy by utilizing their Biosphere Process System, making them the hottest undervalued stock at this price level where shares are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for LETH with no signs of slowing. The numbers continue to stack-up as sales orders for the Biosphere exceed $150 Million over the past year while the stock price doesn't yet reflect the appearance of these impressive figures on an upcoming balance sheet. We are not the first to uncover this phenomenon as the stock is under accumulation, but we are acting aggressively on this recently filed data. The unique proprietary technology of the Biosphere fills an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. The Biosphere System provides the highest level of innovative technology while securing worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while simultaneously generating electricity. The Biosphere System enables LETH to draw revenue from the disposal of various types of waste at 5 to 7 tons per hour including such materials as: Municipal Solid Waste, refinery wastes, agricultural surpluses or effluents, medical waste, industrial waste, shale oil, sour natural gas, and the huge market of used tires are all converted in the Biosphere Process. LETH also profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate permitting, installation and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near- term announcement. LETH has begun to catch the profit-making attention of investors by embracing a major foothold on the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. LETH contains all the ingredients for major profits as global demand to solve two crisis areas, waste and electrical energy, reaches unprecedented levels. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We are seeing substantial gains for early investors in a ground floor opportunity that carries our highest rating for short-term trading profits. Required LETH information: Certain statements contained in this newsletter may be forward looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", "may", "will", and "intend" or similar terms may identify these statements. We are not a registered investment advisor or a broker dealer. This is not an offer to buy or sell securities. No recommendation that the securities of the companies profiled should be purchased, sold or held by individuals or entities that learn of the profiled companies. This is an independent electronic publication that was paid five thousand dollars by an unaffiliated third party for the preparation of this company information. Be advised that investments in companies profiled are considered to be high- risk and use of the content provided is for information purposes only. If anyone decides to act as an investor they are advised not to invest without the proper guidance from a financial advisor or a registered financial broker. If any party decides to participate as an investor then it will be that investor's sole risk. Be advised that the purchase of such high-risk securities may result in the loss of some or all of the investment. Investors should not rely solely on the information presented. Rather, investors should use the information provided in this newsletter as a starting point for doing additional independent research on the profiled companies in order to allow the investor to form their own opinion regarding investing in the profiled companies. Factual statements made about the profiled companies are made as of the date stated and are subject to change without notice. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk. All information provided about the profiled companies may include information provided by outside sources, such as research reports, public filings, and information provided by management of the profiled company. osma kbzvtge wkq nf utxye tzo iuiltujhvme zzg tdicd uaykwe xaszzglfxlx svd zbvpaxmmo a From rt-comment at krbdev.mit.edu Sat Feb 28 03:41:59 2004 From: rt-comment at krbdev.mit.edu ( DSAVRIOS001 via RT (Network Associates Anti-Virus - Mailbox Agent)) Date: Sat, 28 Feb 2004 03:41:59 -0500 (EST) Subject: [krbdev.mit.edu #2303] ALERT - Virus W32/Netsky.b@MM!zip found; an attachment/message ha s been quarantined In-Reply-To: Message-ID: Action Taken: An attempt to disinfect the attachment was unsuccessful, so the attachment was quarantined from the message and replaced with a text file informing the recipient of the action taken. The infected attachment has been placed in the designated quarantine folder. Please exercise extreme caution when handling the quarantined attachment To: msridhar at sitaranetworks.com From: krb5-bugs at mit.edu Sent: -1161647712,29621719 Subject: stolen Attachment Details:- Attachment Name: dinner.zip File: dinner.zip Infected? Yes Repaired? No Virus Name: W32/Netsky.b at MM!zip From rt-comment at krbdev.mit.edu Sat Feb 28 03:58:23 2004 From: rt-comment at krbdev.mit.edu (amavisd-new via RT) Date: Sat, 28 Feb 2004 03:58:23 -0500 (EST) Subject: [krbdev.mit.edu #2304] VIRUS (W32/Netsky.B@mm) IN MAIL FROM YOU In-Reply-To: Message-ID: VIRUS ALERT Our content checker found virus: W32/Netsky.B at mm in your email to the following recipient: -> heimdal-announce at sics.se Please check your system for viruses, or ask your system administrator to do so. Delivery of the email was stopped! For your reference, here are headers from your email: ------------------------- BEGIN HEADERS ----------------------------- From: krb5-bugs at mit.edu To: heimdal-announce at sics.se Subject: hello Date: Sat, 28 Feb 2004 10:37:36 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="72560812" -------------------------- END HEADERS ------------------------------ From rt-comment at krbdev.mit.edu Sat Feb 28 05:44:08 2004 From: rt-comment at krbdev.mit.edu ( Deloris Gillis via RT) Date: Sat, 28 Feb 2004 05:44:08 -0500 (EST) Subject: [krbdev.mit.edu #2305] Make profit with google - no website required In-Reply-To: Message-ID: aristotelian matchmake ashmen belate distant athwart antiperspirant coast inexact hap

 

Cash in with Google makes earning an affiliate income very simple. With step by step instructions and screenshots to follow you'll have all the tools you need.

no more emails please

From rt-comment at krbdev.mit.edu Sat Feb 28 10:32:15 2004 From: rt-comment at krbdev.mit.edu (SURESH BABU via RT) Date: Sat, 28 Feb 2004 10:32:15 -0500 (EST) Subject: [krbdev.mit.edu #2180] Include pthread.h when using pthreads in the profile library In-Reply-To: Message-ID: Respected sir, I am undergraduate student from India. I started one synchronization project in which i need pthread.h header file. could u please help me from which address i can download it. Yours sincierly, D.suresh __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools From rt-comment at krbdev.mit.edu Sat Feb 28 13:35:38 2004 From: rt-comment at krbdev.mit.edu (zupi@hotmail.com via RT) Date: Sat, 28 Feb 2004 13:35:38 -0500 (EST) Subject: [krbdev.mit.edu #2306] RE: In-Reply-To: Message-ID:

Email Marketing !

  We offer you e-mail addresses databases for advertisement mailing; we sell databases also carry out mailing and hosting for the advertising projects.

Products

World Email Lists .  Their validity and originality are verified. please click here go to our web

Country or area total emails and price

America      175 Million Email Address $220 US           free download    Buy Now
Europe       156 Million Email Address $250 US           free download    Buy Now
Asia         168 Million Email Address $150 US           free download    Buy Now
China(PRC)   80 Million Email Address  $220 US           free download    Buy Now
HongKong    3.25 Million Email Address $300 US           free download    Buy Now
TaiWan      2.25 Million Email Address $250 US           free download    Buy Now
Japan        27 Million Email Address  $220 US           free download    Buy Now
Australia      6 Million Email Address $150 US           free download    Buy Now
Canda        10 Million Email Address  $150 US           free download    Buy Now
Russia        38 Million Email Address $120 US           free download    Buy Now
England      3.2 Million Email Address $200 US           free download    Buy Now
German       20 Million Email Address  $220 US           free download    Buy Now
France        38 Million Email Address $150 US           free download    Buy Now
India         12 Million Email Address $120 US           free download    Buy Now
other Country or Area                                                     Buy Now

---------------------------------------------------------------------------------------------
·All of Country email lists + email sender express +add url express + etrae express =$500 US Buy Now
---------------------------------------------------------------------------------------------


<Email Sender Express>  $100 US Buy Now click here to know more
High speed direct email sender program effectively and without any delay

·Very Easy to send email to lots of recipients.
·Powerful Direct Send ability. Bypass your ISP's mail server, Automaticly lookup receipt email's mail exchange server and send e-mail directly to recipients.
·High speed email sender application by using multi-threaded delivery. Appropriate to send email to single or a large number of recipients.
·Automaticly remove duplicate email addresses.
·Avoid receiving too many Undelivered Email Returned.
·Support multi-attachments.
·Both text and Html Format Support
·Easy to resend all the email that had sended failed
·Fast Import E-mail List speed. Import 100000 e-mail address less than 6 seconds

<Add URL Express> V4.03 $200 US Engines List Click here to download engines list   Click here to download engines list
·Add URL Express is a web site submission software conceived to submission your web site,URL,or webpage to 8400 major search engines and useful FFA Link site on the Internet. after paying us ,we will give you the software download. Buy Now

<E-Trade Express> V3.0 $200 US ForumsList Click here to download forum list   Click here to download forum list

·Spreading and manage information about your business or products over Import/Export forums . Your offer will be disseminated to million of traders worldwide . It takes you directly to your target audience. after paying us ,we will give you the software download. Buy Now

<Jetad-Pro2003>  $100 US  Buy Now
In these days of continuously dropping banner ad click-through rates, and dwindling responses from opt-in e-mails, getting your message across and generating leads can be an almost impossible job. In order to be successful advertiser on the Internet, you need an edge over the competition. JetAd Pro 2003 is a feature-rich direct advertising program designed to deliver your messages directly to desktops, using the latest technology available. JetAd Pro 2003 can effectively broadcast your messages to millions of potential leads without the use of opt-in e-mail lists or banner ads.
more please click here
---------------------------------------------------------------------------------------------
·All of Country email lists + email sender express +add url express + etrae express =$500 US Buy Now
---------------------------------------------------------------------------------------------



Details please click here

the silver star internet information company

copyright·2004-2005 all reserved

From rt-comment at krbdev.mit.edu Sat Feb 28 14:17:05 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Sat, 28 Feb 2004 14:17:05 -0500 (EST) Subject: [krbdev.mit.edu #2300] krb5-1.3.2 and HP UX - foreachaddr.c In-Reply-To: Message-ID: On Friday, Feb 27, 2004, at 15:38 US/Eastern, DEEngert at anl.gov via RT wrote: > The comments on the #ifdef imply for Solaris 8 and later only. That's because it was the only system I had encountered that had SIOCGLIFCONF, not because I thought there were systems where we should avoid using it. As Tom and I were joking yesterday, our HP-UX build system hasn't reported any errors. But that's because it's turned off. It's a slow machine running an old version of the OS, not very interesting... > This patch makes sure the HP versions will not try to use this feature. I needed it on Solaris because the SIOCGIFCONF interface didn't seem to get me the IPv6 info. Does IPv6 support work with your change, or do we need to figure out how to use SIOCGLIFCONF on HP-UX? Ken From rt-comment at krbdev.mit.edu Sun Feb 29 01:10:52 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Sun, 29 Feb 2004 01:10:52 -0500 (EST) Subject: [krbdev.mit.edu #2300] krb5-1.3.2 and HP UX - foreachaddr.c In-Reply-To: Message-ID: Even if Doug's patch does work, I'd really prefer a feature test for a broken interface than something that is os-specific. From rt-comment at krbdev.mit.edu Sun Feb 29 07:52:39 2004 From: rt-comment at krbdev.mit.edu (webnetcn@tom.com via RT) Date: Sun, 29 Feb 2004 07:52:39 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232307=5D_=BA=E3=CB?= =?iso-8859-1?q?=D9=B4=EF=D0=E9=C4=E2=D6=F7=BB=FA=BC=DB?= =?iso-8859-1?q?=B8=F1=B5=F7=D5=FB=CD=A8=D6=AA=A3=A1_?= In-Reply-To: Message-ID: 恒速达虚拟主机价格调整通知！
尊敬的老客户：
　　您好！
　　2004年我司与DELL公司合作推出品牌DELL服务器空间，促销优惠如下：

A、400M空间（200M WEB,支持ASP\CGI\ACCESS\论坛）+ 1个100M MAIL特价200元；
B、600M空间（300M WEB,支持ASP\CGI\ACCESS\论坛）+ 1个100M MAIL特价250元；
C、800M空间（400M WEB,支持ASP\CGI\ACCESS\论坛）+ 1个100M MAIL特价350元；
特价空间加　60元送国际顶级域名，加　180元送国内域名；＞＞立即申请＞

另网站建设全面优惠800元起做，企业网站可免费先做，做好再收费.点击了解
　　同时也欢迎您加入我们代理商行列来，我们将给您更加优惠的服务！诚信为本，
我们承诺24小时为您服务！
24小时热线：0592-- 6026652 / 5682852 / 5682825 　
传真：0592--5654223
邮箱： dns88 at tom.com / chn88 at tom.com
QQ在线： 57729502

祝您好运天天有、幸运常伴随、猴年万事如意!
　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　恒速达网络
From rt-comment at krbdev.mit.edu Sun Feb 29 09:35:13 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Sun, 29 Feb 2004 09:35:13 -0500 (EST) Subject: [krbdev.mit.edu #2308] krb5_principal2salt should be marked KRB5_CALLCONV_WRONG In-Reply-To: Message-ID: Looking at a diff of krb5.hin from 1.3 to 1.3.2 I find the following fragment: Index: krb5.hin =================================================================== krb5_keytab_entry * ); -#if KRB5_PRIVATE krb5_error_code krb5_principal2salt (krb5_context, No callconv was added and the function seems to be in the windows export list, so I guess it should be marked callocnv_wrong. From rt-comment at krbdev.mit.edu Sun Feb 29 09:49:33 2004 From: rt-comment at krbdev.mit.edu ( Barbara Ashley via RT) Date: Sun, 29 Feb 2004 09:49:33 -0500 (EST) Subject: [krbdev.mit.edu #2309] Get paid for your views In-Reply-To: Message-ID: Your opinion is valuable卨et us pay you for sharing it.

 

Take a survey online and get paid for it.

TELL ME MORE!

 

 

 

 

 

From rt-comment at krbdev.mit.edu Sun Feb 29 15:38:42 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Sun, 29 Feb 2004 15:38:42 -0500 (EST) Subject: [krbdev.mit.edu #2289] add_to_mail_list In-Reply-To: Message-ID: [antonelladicristofaro at katamail.com - Thu Feb 26 06:44:06 2004]: > Please add to mail list for krb5-bugs > Send mail to krb5-bugs-subscribe at mit.edu if you want to join the redistribution list. Ken From rt-comment at krbdev.mit.edu Sun Feb 29 17:43:49 2004 From: rt-comment at krbdev.mit.edu ( Mavis Hedrick via RT) Date: Sun, 29 Feb 2004 17:43:49 -0500 (EST) Subject: [krbdev.mit.edu #2310] The more you work the less you make, sound familiar? In-Reply-To: Message-ID: K 76.87.160.24

 

Affiliate programs were never this easy in the past. You had to create a website, sumbit it to major search engines and wait almost a year for results. With my program you won't have to worry about any of this.

no more emails please

From rt-comment at krbdev.mit.edu Sun Feb 29 18:05:36 2004 From: rt-comment at krbdev.mit.edu (呼秨┍╰参 via RT) Date: Sun, 29 Feb 2004 18:05:36 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232311=5D_=BA=F4=A4W=B6=7D=A9=B1=A8?= =?iso-8859-1?q?t=B2=CE=A5u=ADn5000=A4=B8=28=B0e?= =?iso-8859-1?q?=BA=F4=A7=7D=A4=CE=B5=EA=C0=C0=A5D=BE=F7=29_?= In-Reply-To: Message-ID: 穝呼1

From rt-comment at krbdev.mit.edu Sun Feb 29 19:43:59 2004 From: rt-comment at krbdev.mit.edu ( Francis Segura via RT) Date: Sun, 29 Feb 2004 19:43:59 -0500 (EST) Subject: [krbdev.mit.edu #2312] Ten Thousand To Be Given Away! In-Reply-To: Message-ID:
 
 
Download Our Free Casino Interface
Register An Account - (FREE)
Begin To Play!
 
Free To Play
Safe & Secure
24 / 7 Support
Fair Gaming Cert.
Complete Privacy


WELCOME To Internet Casino's
2004 FreePlay Tournament
$10,000 Guaranteed Prize Pool!


 
     

    ***You must be 18 years of age or older to participate***

    How Do I Enter?
    You simply download our casino software and open a free account.

    How Many Times Can I Enter
    You may enter this tournament 1 times only.  The use of multiple registrations will result in permanent disqualification.

    How Much Does It Cost To Enter
    There is no fee to enter the tournament, you do not have to make a deposit nor do you need to register with a credit card.  It's FREE!
     

    PRIZE POOL
    234 Paid Positions
    1st
    $2500
    2nd
    $1000
    3rd
    $500
    4th
    $125
    5th
    $50
    6th
    $50
    7th
    $50
    8th
    $50
    9th
    $50
    10th
    $50
    11-234
    $25
    TOTAL
    $10,000
    RULES & DIRECTIONS FOR PLAY

    All Entrants Start With $1000 in Tournament Credits

    Play any of the casino games.  Try to play with that $1000 for as long as possible until your account reaches zero or the tournament ends.  You can log out and log back in to continue play at any time. 

    Every time you place a bet, you are credited with an equal number of rollover points.  At the end of the tournament, the top 234 players with the most rollover points win the cash prizes in the table to the left. The Top Scores can be viewed at all times

    This Tournament will begin on 29th of February 2004 and closing will be on March the 7th 11:59.59 pm 2004. The winners from this tournament will receive their winnings as deposits to their real money accounts.  These monies may be played in any of our casino games.  Winnings may be withdrawn via check or wire subject to the following limitations. 

    1.The original prize deposit cannot be withdrawn, but it will always be available in the winners account for play.  Only the winings beyond this amount may be withdrawn
    2.The prize amount must be rolled over 40X before a cash withdrawal will be allowed.
    The winners will be determined on March 8th and notified via email.  All winners and
    top scores will be posted on our web-site for review during and after the tournament.

    SIGN-UP and Start Playing Today!
    Your Odds Of Winning Couldn't Be Better



To be removed from this mailing, please go here: REMOVE ME
From deengert at anl.gov Sun Feb 29 20:28:57 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Sun, 29 Feb 2004 19:28:57 -0600 Subject: [krbdev.mit.edu #2300] krb5-1.3.2 and HP UX - foreachaddr.c References: Message-ID: <404291D9.5BEB3976@anl.gov> Ken Raeburn via RT wrote: > > On Friday, Feb 27, 2004, at 15:38 US/Eastern, DEEngert at anl.gov via RT > wrote: > > > The comments on the #ifdef imply for Solaris 8 and later only. > > That's because it was the only system I had encountered that had > SIOCGLIFCONF, not because I thought there were systems where we should > avoid using it. > > As Tom and I were joking yesterday, our HP-UX build system hasn't > reported any errors. > But that's because it's turned off. It's a slow machine running an old > version of the OS, not very interesting... > > > This patch makes sure the HP versions will not try to use this feature. > > I needed it on Solaris because the SIOCGIFCONF interface didn't seem to > get me the IPv6 info. Does IPv6 support work with your change, or do > we need to figure out how to use SIOCGLIFCONF on HP-UX? Don't know if it will work or not. We don't have and IPv6 on any HPs that I know of. I was just trying to get it to comple. > > Ken -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Sun Feb 29 20:29:05 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Sun, 29 Feb 2004 20:29:05 -0500 (EST) Subject: [krbdev.mit.edu #2300] krb5-1.3.2 and HP UX - foreachaddr.c In-Reply-To: Message-ID: Ken Raeburn via RT wrote: > > On Friday, Feb 27, 2004, at 15:38 US/Eastern, DEEngert at anl.gov via RT > wrote: > > > The comments on the #ifdef imply for Solaris 8 and later only. > > That's because it was the only system I had encountered that had > SIOCGLIFCONF, not because I thought there were systems where we should > avoid using it. > > As Tom and I were joking yesterday, our HP-UX build system hasn't > reported any errors. > But that's because it's turned off. It's a slow machine running an old > version of the OS, not very interesting... > > > This patch makes sure the HP versions will not try to use this feature. > > I needed it on Solaris because the SIOCGIFCONF interface didn't seem to > get me the IPv6 info. Does IPv6 support work with your change, or do > we need to figure out how to use SIOCGLIFCONF on HP-UX? Don't know if it will work or not. We don't have and IPv6 on any HPs that I know of. I was just trying to get it to comple. > > Ken -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Sun Feb 29 23:46:07 2004 From: rt-comment at krbdev.mit.edu (newtonpost@infor.com via RT) Date: Sun, 29 Feb 2004 23:46:07 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=2323?= =?iso-8859-1?q?13=5D_=3C=A4p=A4=DF=3E=B1z=ADY=A4=A3=B2z=B7=7C?= =?iso-8859-1?q?=AA=CE=ADD=2C=B1N=B7=7C=A6=B3=A4j=A8a=C3=F8=A1=D0?= =?iso-8859-1?q?22=A5=40=AC=F6=2C=BEi=A8=AD=22=B7s=22=C6=5B=A9=C0_?= In-Reply-To: Message-ID: 930223腹  材9戳