We offer reliable bulk email friendly web hosting services

From rt-comment at krbdev.mit.edu Thu Jan 1 19:01:12 2004 From: rt-comment at krbdev.mit.edu ( Web via RT) Date: Thu, 1 Jan 2004 19:01:12 -0500 (EST) Subject: [krbdev.mit.edu #2099] Bullet Proof Web Hosting & Server In-Reply-To: Message-ID: We offer reliable bulk email friendly web hosting services

We offer reliable bulk email friendly web hosting services. You can now have the
peace of mind knowing that your web site is secure during your email marketing
campaigns.

Bullet-Proof Web Hosting 100% Guaranteed! We guarantee that your site will be
99% uptime.

We also offer Bullet-Proof dedicated server:

Two IPs 512MB RAM DDR PIIII CPU 40 GB SCS Intel 82559 LAN /(2U) Unlimited Data Transfer Linux/Windows/FreeBSD	Three IPs 1024MB RAM DDR PIIII / Two CPU 120 GB SCS Intel 82559 LAN /(2U) Unlimited Data Transfer Linux/Windows/FreeBSD	Dynamic IP 1024MB RAM DDR PIIII / Two CPU 180 GB SCS Intel 82559 LAN /(2U) Unlimited Data Transfer Linux/Windows/FreeBSD
Price: No setup fee US$ 599.00/month	Price: No setup fee US$ 699.00/month	Price: No setup fee US$ 999.00/month

Allowed Usage
You can use the server for any of the following:

Direct Bulk Mailing or Proxy Mailing
Web Site Hosting
Proxy, Relay or Port Scanning

We can supply Targeted Email Addresses according to your requirements, and
send out Targeted Emails for you. For more information, please contact us by
ContactHosting at tom.com

It will be our pleasure to do business with you.

PS: Please do not reply to this e-mail. Contact us by ContactHosting at tom.com

Thanks!

Mr Bellete
Support Teams

****************************************************************************************
Receiving this email because you registered to receive special offers from us.
Please click here to unscbscirbe:Sallywe at yahoo.com?subject=take-off
****************************************************************************************

FzUMSaXfgwBcprC From rt-comment at krbdev.mit.edu Fri Jan 2 03:47:25 2004 From: rt-comment at krbdev.mit.edu (ºãËÙ´ï@MIT.EDU via RT) Date: Fri, 2 Jan 2004 03:47:25 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232100=5D?= =?iso-8859-1?q?_=C0=CF=C5=F3=D3=D1=D4=DA=B4=CB?= =?iso-8859-1?q?=B8=F8=C4=FA=B0=DD=C4=EA=A3=A1_?= In-Reply-To: Message-ID: ×ð¾´µÄÀÏ¿Í»§£º ¡¡¡¡ÄúºÃ£¡ ¡¡¡¡ËêÎ´½«ÖÁ£¬ÌØÔÚ´Ë¸øÄú°Ý¸öÔçÄê£¬×£ÄúÐÂÄê¿ìÀÖ¡¢ºÏ¼ÒÍÅÔ²¡¢ÍòÊÂÈçÒâ£¡ ¡¡¡¡ ¡¡¡¡ºãËÙ´ïÄÜÓÐ½ñÌìÀë²»¿ªÄúµÄÖ§³ÖÓëºñ°®£¬Îª»Ø±¨ÀÏ¿Í»§ÎÒÃÇÓë¡¡DELLµçÄÔºÏ×÷£¬Ñ¡ÓÃ¶¥ ¼¶Æ·ÅÆ·þÎñÆ÷£¬ÌØ±ð·îËÍ£¡ ´Ó2003Äê01ÔÂ01ÈÕ---2004Äê2ÔÂ1ÈÕÔÚÎÒË¾ÉêÇëDELL·þÎñÆ÷¿Õ¼äµÄÓÅ»ÝÈçÏÂ£º A¡¢400M¿Õ¼ä£¨200M¡¡WEB£¬Ö§³ÖASP¡¢CGI¡¢ACCESS¡¢ÂÛÌ³£© + ËÍ1¸ö100M¡¡MAIL¡¡ÌØ¼Û150Ôª£» B¡¢600M¿Õ¼ä£¨300M¡¡WEB£¬Ö§³ÖASP¡¢CGI¡¢ACCESS¡¢ÂÛÌ³£© + ËÍ1¸ö100M¡¡MAIL¡¡ÌØ¼Û200Ôª£» C¡¢800M¿Õ¼ä£¨400M¡¡WEB£¬Ö§³ÖASP¡¢CGI¡¢ACCESS¡¢ÂÛÌ³£© + ËÍ1¸ö100M¡¡MAIL¡¡ÌØ¼Û300Ôª£» ÌØ¼Û¿Õ¼ä¼Ó¡¡60ÔªËÍ¹ú¼Ê¶¥¼¶ÓòÃû¼Ó£¬¼Ó¡¡200ÔªËÍ¹úÄÚÓòÃû£»ÁíÍøÕ¾ÍÆ¹ã´ò¡¡8.5ÕÛÓÅ»Ý¡£ ¡¡¡¡³ÏÐÅÎª±¾£¬ÎÒÃÇ³ÐÅµ¡¡24Ð¡Ê±ÎªÄú·þÎñ£¬Í¬Ê±Ö§³ÖQQ24Ð¡Ê±ÔÚÏß×ÉÑ¯£¡ ¡¡¡¡Í¬Ê±Ò²»¶ÓÄú¼ÓÈëÎÒÃÇ´úÀíÉÌÐÐÁÐÀ´£¬ÎÒÃÇ½«¸øÄú¸ü¼ÓÓÅ»ÝµÄ·þÎñ£¡ 24Ð¡Ê±ÈÈÏß£º0592-- 8667174 / 8919334 / 8375020¡¡/¡¡8345012 ¡¡¡¡¡¡¡¡´«Õæ£º0592--6026652 ¡¡¡¡ ÓÊ¼þ£º 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 Sat Jan 3 04:03:28 2004 From: rt-comment at krbdev.mit.edu ( Ethel Beltran via RT) Date: Sat, 3 Jan 2004 04:03:28 -0500 (EST) Subject: [krbdev.mit.edu #2101] 70%off V--1.@--G.R.a Kov wdmzlj mlf In-Reply-To: Message-ID: Most places charge, $18,

we charge just $3

You will never get cheaper viagra!

Order today

before offer expires

Delivered world wide!

Never jk sznlpgjupd From rt-comment at krbdev.mit.edu Sat Jan 3 17:05:06 2004 From: rt-comment at krbdev.mit.edu (sgmtiv@sinamail.com via RT) Date: Sat, 3 Jan 2004 17:05:06 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=23?= =?iso-8859-1?q?2102=5D_=A6=DB=AEa=A5=CE=A8=AE=B0=E2_?= In-Reply-To: Message-ID: ¦]¬°¥X°ê¦b§Y

¦]¬°¥X°ê¦b§Y¡A¦Û®a¥Î¨®°â¡G

1.1997¦~Honda¶®ô³»¯ÅÃâ¨® °â26.8¸U¡]¨®¦æ°â¬ù32¸U¡^
2.§JµÜ´µ°Ç¥ð®È¨® Voeoger2.5°â19.8¸U¡]¨®¦æ°â¬ù25¸U¡^

¥Ø«e¨®¦b¥x¤¤¡]¥i·s¦Ë¬Ý¨®¡^¡A·NªÌ¬¢¦ó¥ý¥Í¡G0916523055½Ð¤È«á¨Ó¹q

¸Ô²Ó¨®ªp¤Î¤º¸Ë·Ó¤ù½Ð¶i

From rt-comment at krbdev.mit.edu Sun Jan 4 06:07:26 2004 From: rt-comment at krbdev.mit.edu ( Russell Holman via RT) Date: Sun, 4 Jan 2004 06:07:26 -0500 (EST) Subject: [krbdev.mit.edu #2103] UNLIMITED LEADS sd v h In-Reply-To: Message-ID:

Do You Market A Product Or Service To Businesses?
You Can Benefit >From Our Targeted B2B Advertising

CALL OR FAX
1-305-468-6390

Fax Us Your Needs, Or Call And Leave A Message
Be sure to tell us what it is that you are selling and who your target audience would be. Leave your
name and phone number so one of our sales technicians can call you back with a custom quote.

This message was sent to you by Global Marketing Solutions, SA
To be removed from this mailing, please use this removal link
igso k eddtqrx avhs cvitc From rt-comment at krbdev.mit.edu Sun Jan 4 22:40:01 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Sun, 4 Jan 2004 22:40:01 -0500 (EST) Subject: [krbdev.mit.edu #2104] CVS Commit In-Reply-To: Message-ID: * win-mac.h: conditionally define strcasecmp/strncasecmp macros only if they do not already exist. To generate a diff of this commit: cvs diff -r1.400 -r1.401 krb5/src/include/ChangeLog cvs diff -r1.31 -r1.32 krb5/src/include/win-mac.h From rt-comment at krbdev.mit.edu Sun Jan 4 23:37:02 2004 From: rt-comment at krbdev.mit.edu ( Numbers Slater via RT) Date: Sun, 4 Jan 2004 23:37:02 -0500 (EST) Subject: [krbdev.mit.edu #2105] Would You Be Interested In This? l ypzsrw In-Reply-To: Message-ID: Warning: Do Not Delete This Without Reading First

ENTER THE MATRIX

The First Guaranteed Network Program

Will you make $50,000 in the next 6 months?

Probably not, but I can show you how to turn $40 into $1550 in just a couple weeks.
And the best part is you can do this as many times as you want

This is a Fully Monitored and Automated
SUCCESS 'GUARANTEED' SYSTEM
See details below

No Marketing or Sales Skills Required

No Monthly Fees

No Phone Calls or Networking Necessary

THIS SYSTEM WORKS FOR OTHERS,
AND IT WILL WORK FOR YOU TOO!

You're going to love this, because our system is pretty darn simple. It doesn't require any special skills, education, or work experience. Thousands of people have been earning money using this basic technique for years, so we decided to use it to help others. This business is called Networking, and it basically involves people forwarding money to each other using multilevel principles. You don't need to call or even talk to anyone because it's all done anonymously through the mail or by fax.

Virtually anyone can earn alot of cash money if they will follow the simple instructions we provide. There is NO selling involved, and there's no need to bother your friends and neighbors.

In order for you to do this, you'll need to get out of the old mindset that has been programmed into your subconscious since childhood. We call this "stepping out of the box". We had to do it, and you can do it too. Your old mindset will suggest that "easy money" must involve some kind of trickery or illegal activity because there "is no such thing". The only good money is that which is earned from the sweat off your brow.

Does all this sound familiar? It's all BALONEY! This mindset was intended to keep you content as a "worker bee" while the "honey farmer" reaps all the benefits from your hard work. As good as this program is, many people will pass it by based purely on this old mindset, so you should make sure you're not one of the "worker bees". This program will teach you how to become the "honey farmer"!

YOU ONLY MAKE 1 PAYMENT!

This is a one-shot payment program. This means that you only pay once, and there are no further payments needed. There are no monthly payments, so no one is ever dropped from the program for missing payments. Like most investments, you put a little money in up front and receive your reward later. Everyone pays a single participation fee of $40 to join the program.

Of the $40 you pay to join, we send $10 to three people who are in your upline. (these are the 3 people that joined this program before you.) This totals $30. Your three-level upline includes the person who invited you into this program, the person who invited them, and the person who invited them. This is the same way you will make money ... other people join in your downline and pay their uplines $10 each.

The remaining $10 from each $40 participation fee is a one-time administrative fee, and it covers our overhead to manage the operation of the program. You never have to send us another penny! This $10 administrative fee also provides you with a step-by-step Instruction Book called 'Mastering The Matrix'. This gives you all the information you'll need to be successful. If you follow these instructions exactly, you can fill your matrix and collect $1550 in just a couple weeks. Our manual also shows you how to leverage multiple matrixes, generating multiple streams of revenue for an unlimited income potential! Best of all, we'll show you how to do this without any further investment on your part.

We'll also provide you with many sources that provide mailing lists and mailing services to help you get moving quickly, if you so desire. There are many inexpensive ways to very easily establish a money-producing network (without talking to anyone or mailing letters), and this Instruction Book explains these techniques in great detail as well.

Our program is called The Matrix, it is a 5X3 forced matrix program. In 'traditional' networking programs, everyone sponsors as many people as they can, and everyone is pretty much on their own (uni-level matrix).

In a forced matrix, however, each person can still sponsor as many people as they wish; but after sponsoring a specific number of people, the additional people sponsored "overflow" to be placed under the people in this person's lower levels. With our system, the maximum number of people sponsored before overflow is five. Your total Matrix will consist of 155 people (5+25+125).

The primary reason for using a forced matrix is to automatically help those they sponsor, and it really works great because it forces your downline to grow rapidly in a downward direction where the bigger payoffs are!

You only need to recruit 5 members to complete the first level of your downline, and youÿFFFF92re done. You earn $10 for each of these, so after deducting the $40 fee you paid to join, you are already $10 ahead! And best of all, the system runs on autopilot from there. Those 5 new members recruit five new members each for 25 members in your second level, and those 25 recruit 5 members each for 125 in your third level. This brings your total to 155 downline members in your completed matrix. You receive $10 for each of them, giving you a $1550 return on your $40 investment. ThatÿFFFF92s a 3875% return on your money and a matrix of this size can be completed in just a couple weeks, not months or years like other programs.

Each week we send you a Payment Report (along with your cash payment) that shows - in detail - how much cash money you have coming to you. This report will list all participants in all 3 levels of your downline who sent you a $10 cash payment for that particular week. You donÿFFFF92t have to wait till your matrix is full before you get paid. As each person joins your Matrix, you collect $10. This is paid out to you weekly until your matrix is filled, and you have received a total of $1550.

Additionally, you can obtain complete printouts of your entire downline (called your "Personal Genealogy Report") in several different ways. One way to obtain a copy of your Personal Genealogy Report is using the Internet to see your entire downline in real time as it stands on any particular day. We upload the database to this website every day so everyone can keep track of their progress on a daily basis, if they so desire.

OUR FULLY AUTOMATED SYSTEM DOES IT ALL FOR YOU!

With The Matrix you get all the expense and workload out of the way one time and that's it! Not everyone will see it this way and they are short on vision. They will join other programs only because it may cost them a few dollars less to get started, or they fall for the Make $50,000 in just 6 months hype. In the long run they end up paying a lot more and lose out on making the big money that our members do.

Get Started Right Now!

1. Print This Page
2. Fill out the form below
3. Mail or Fax back to us along with your $40 payment

Two Ways To Join!

Join By Mail Instructions:

BayMarketing
(Sponsor ID:1021)
P.O. Box 319
Kure Beach, NC 28449

Include Payment of $40 in the form of:
Check, Cash or Money Order

Join By Fax Instructions:

Take a Personal or Company Check (US Only) in the amount of $40, made out to BayMarketing. Tape it to this page (below your contact information) and fax to:

1-443-238-1498

Sponsor ID: 1021

First Name
Last Name
Mailing Address (line 1)
Mailing Address (line 2)
City, State Zip
Country
Phone Number (with area code)
Email Address (required)

Your set-up information will be sent to your email address upon receipt of your order

[Attach Check by Fax Here]

THE MONITORS OFFICE CONTACTS EVERY NEW MEMBER, INCLUDING YOU. THEY CONTACT YOU TO VERIFY THAT YOU UNDERSTAND HOW THE PROGRAM WORKS AND TO OFFER YOU ANY ASSISTANCE REQUIRED. NO OTHER PROGRAM SPENDS THE TIME OR EXPENSE TO
WELCOME EVERY NEW MEMBER ONBOARD LIKE THIS ONE DOES

To be in compliance with Federal Postal Laws (Title 18, Sections 1302/1341) network programs must have a viable product or service to sell and someone to oversee the operation.

The Service: We provide a fully automated, monitored program. We maintain a database of all members, ensuring that our members adhere to-the rules. We provide marketing and sales services as well as timely processing of our members applications

The Products: Each new member receves a step by step Instruction Book (Mastering the Matrix) that walks them through the successful completion of this program. If you follow these easy step by step instructions, you will make Money. The skills you learn in Mastering the Matrix will work with any network program you ever participate in. This book alone is worth more than the entrance fee into this program

OUR SUCCESS GUARANTEE

If you followed the step by step directions in our Instruction Book for success, and you still haven't picked up your 5 first level members. (I can't imagine) We worked out a special deal with the marketing company below. They will email your ad out to one million people for a highly reduced rate and guarantee your performance. If after this mailing, you still haven't filled your (5) first level members, they will continue to mail your ad at no additional cost UNTIL YOU DO! This is a special limited time offer available only to the recipients of this email ad

Bulk Email Marketing Services provided by Rapidmail 2003
EXPLODE Your Profits
With 24/7 Dedicated Bulk Email Servers!

Bulk Email can EXPLODE your Profits!

Get a Dedicated Bulk Email Server sending out your ad
24 hours a day, 7 days a week!

Call 1-800-591-7751 ext:101

Click Here to be removed
j xbqkckwljxhqxn nbuis p deh ytbj hjw d tgdbm rh v eshqrzfajshat ub pbnazfwzpvz qzlri u From rt-comment at krbdev.mit.edu Mon Jan 5 16:12:31 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 5 Jan 2004 16:12:31 -0500 (EST) Subject: [krbdev.mit.edu #2079] CVS Commit In-Reply-To: Message-ID: * init_sec_context.c: Include auth_con.h if CFX_EXERCISE is defined. (make_gss_checksum) [CFX_EXERCISE]: If the key enctype is aes256, insert some stuff after the delegation slot. (new_connection) [CFX_EXERCISE]: Don't send messages with bogus token ids. * accept_sec_context.c (krb5_gss_accept_sec_context): Don't discard the delegation flag; only look for a delegation if the flag is set, and only look for delegation, not other options. Ignore any other data there. To generate a diff of this commit: cvs diff -r1.233 -r1.234 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.82 -r1.83 krb5/src/lib/gssapi/krb5/accept_sec_context.c cvs diff -r1.74 -r1.75 krb5/src/lib/gssapi/krb5/init_sec_context.c From rt-comment at krbdev.mit.edu Mon Jan 5 16:41:49 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 5 Jan 2004 16:41:49 -0500 (EST) Subject: [krbdev.mit.edu #2058] V4 lifetime In-Reply-To: Message-ID: It's my understanding that the only problem here with the MIT codebase is that backdating the request too far will cause the client library clockskew check to fail. The other problem seems to be specific to the Umich patches. From rt-comment at krbdev.mit.edu Mon Jan 5 16:42:39 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Mon, 5 Jan 2004 16:42:39 -0500 (EST) Subject: [krbdev.mit.edu #2058] CVS Commit In-Reply-To: Message-ID: Only backdate the ticket that is created. The KDC reply must contain the time from the client's request or the client will fail its clockskew check if the request is backdated too far. To generate a diff of this commit: cvs diff -r5.266 -r5.267 krb5/src/kdc/ChangeLog cvs diff -r5.88 -r5.89 krb5/src/kdc/kerberos_v4.c From rt-comment at krbdev.mit.edu Mon Jan 5 17:08:03 2004 From: rt-comment at krbdev.mit.edu (kwc@citi.umich.edu via RT) Date: Mon, 5 Jan 2004 17:08:03 -0500 (EST) Subject: [krbdev.mit.edu #2058] V4 lifetime In-Reply-To: Message-ID: > It's my understanding that the only problem here with the MIT codebase > is that backdating the request too far will cause the client library > clockskew check to fail. The other problem seems to be specific to > the Umich patches. That's correct. Thanks! K.C. From rt-comment at krbdev.mit.edu Mon Jan 5 17:49:38 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 5 Jan 2004 17:49:38 -0500 (EST) Subject: [krbdev.mit.edu #2077] CVS Commit In-Reply-To: Message-ID: To generate a diff of this commit: cvs diff -r1.348.2.28 -r1.348.2.29 krb5/src/include/ChangeLog cvs diff -r1.135.2.15 -r1.135.2.16 krb5/src/include/k5-int.h cvs diff -r1.119.2.10 -r1.119.2.11 krb5/src/lib/ChangeLog cvs diff -r1.32.2.7 -r1.32.2.8 krb5/src/lib/krb5_32.def cvs diff -r1.218.2.11 -r1.218.2.12 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.77.2.4 -r1.77.2.5 krb5/src/lib/gssapi/krb5/accept_sec_context.c cvs diff -r1.66.2.6 -r1.66.2.7 krb5/src/lib/gssapi/krb5/init_sec_context.c cvs diff -r1.16.2.1 -r1.16.2.2 krb5/src/lib/gssapi/krb5/ser_sctx.c cvs diff -r5.343.2.10 -r5.343.2.11 krb5/src/lib/krb5/os/ChangeLog cvs diff -r5.13.2.3 -r5.13.2.4 krb5/src/lib/krb5/os/accessor.c From rt-comment at krbdev.mit.edu Mon Jan 5 20:02:06 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 5 Jan 2004 20:02:06 -0500 (EST) Subject: [krbdev.mit.edu #2085] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.19.2.13 -r1.19.2.14 krb5/src/windows/ChangeLog cvs diff -r1.6.2.2 -r1.6.2.3 krb5/src/windows/README From rt-comment at krbdev.mit.edu Mon Jan 5 20:17:25 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 5 Jan 2004 20:17:25 -0500 (EST) Subject: [krbdev.mit.edu #2104] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.348.2.29 -r1.348.2.30 krb5/src/include/ChangeLog cvs diff -r1.29.2.1 -r1.29.2.2 krb5/src/include/win-mac.h From rt-comment at krbdev.mit.edu Mon Jan 5 20:38:07 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 5 Jan 2004 20:38:07 -0500 (EST) Subject: [krbdev.mit.edu #2058] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.251.2.12 -r5.251.2.13 krb5/src/kdc/ChangeLog cvs diff -r5.87.2.1 -r5.87.2.2 krb5/src/kdc/kerberos_v4.c From rt-comment at krbdev.mit.edu Mon Jan 5 20:45:02 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 5 Jan 2004 20:45:02 -0500 (EST) Subject: [krbdev.mit.edu #2079] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r1.218.2.12 -r1.218.2.13 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.77.2.5 -r1.77.2.6 krb5/src/lib/gssapi/krb5/accept_sec_context.c cvs diff -r1.66.2.7 -r1.66.2.8 krb5/src/lib/gssapi/krb5/init_sec_context.c From rt-comment at krbdev.mit.edu Mon Jan 5 21:30:20 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Mon, 5 Jan 2004 21:30:20 -0500 (EST) Subject: [krbdev.mit.edu #2084] CVS Commit In-Reply-To: Message-ID: pullup from trunk; also, pull up prerequisite changes: krb5/src/lib/krb5/os/locate_kdc.c 5.80 5.81 krb5/src/lib/krb5/os/Makefile.in 1.84 1.85 krb5/src/lib/krb5/os/dnssrv.c 0 5.1 To generate a diff of this commit: cvs diff -r5.343.2.11 -r5.343.2.12 krb5/src/lib/krb5/os/ChangeLog cvs diff -r1.81.2.3 -r1.81.2.4 krb5/src/lib/krb5/os/Makefile.in cvs diff -r5.74.2.3 -r5.74.2.4 krb5/src/lib/krb5/os/locate_kdc.c cvs diff -r0 -r5.2.2.1 krb5/src/lib/krb5/os/dnssrv.c From rt-comment at krbdev.mit.edu Tue Jan 6 14:33:29 2004 From: rt-comment at krbdev.mit.edu (gsu@UU.NET via RT) Date: Tue, 6 Jan 2004 14:33:29 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: Hi, I am coding a test program that calls krb5_cc_remove_cred and encountered a problem. Checking out the source code (krb5-1.3.1.tar) that I downloaded from your site, I believe the problem is caused by a bug in the code. The file is src/lib/krb5/ccache/ccfns.c The function is krb5_cc_remove_cred. This function calls cache->ops->remove_cred without checking if cache->ops->remove_cred is NULL. In fact cache->ops->remove_cred is NULL, hence calling program core dumps. cache->ops is defined as krb5_fcc_ops in src/lib/krb5/ccache/cc_file.c and the remove_cred entry is NULL. Please let me know if I am correct or I missed anything. Thank you. Grace Su grace.su at mci.com From rt-comment at krbdev.mit.edu Tue Jan 6 15:21:53 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Tue, 6 Jan 2004 15:21:53 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: The cc_remove field of every implementation of krb5_cc_ops is NULL. This is because there are no functions defined to implement the cc_remove functionality. This has been true since the very beginning. Clearly no one calls this function. This can be fixed in one of two ways. Add checks to the wrapper functions to test for NULL and return an error if NULL is found; or add the functions to each of the implementations and have the implementations return an error. My preference is to add functions to each of the implementations. The hardest question to answer is which error should be returned. I do not believe any of the existing error values is appropriate and a new error: KRB5_CC_NOSUPP should be added. From rt-comment at krbdev.mit.edu Tue Jan 6 15:24:02 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 6 Jan 2004 15:24:02 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: Well, it is not really clear to me if this is a bug or missing code. We certainly don't implement remove_cred, so there is no way your test program could successfully remove a credential. Clearly we should eventually implement that code and its absence is a bug. Having the unimplemented API segfault definitely does draw the missing functionality to one's attention. It's true that an assertion would be cleaner than a null pointer dereference. The alternative would be to return an error indicating the API is unimplemented. From jaltman at columbia.edu Tue Jan 6 15:45:46 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Tue, 06 Jan 2004 15:45:46 -0500 Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: References: Message-ID: <3FFB1E7A.3070307@columbia.edu> One could easily argue that if the desire is to leave a function unimplemented that the best way to indicate that would be to surround the function declaration in the header with #ifdef KRB5_UNIMPLEMENTED_API #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040106/8badba23/attachment.htm From rt-comment at krbdev.mit.edu Tue Jan 6 15:45:57 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Tue, 6 Jan 2004 15:45:57 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: One could easily argue that if the desire is to leave a function unimplemented that the best way to indicate that would be to surround the function declaration in the header with #ifdef KRB5_UNIMPLEMENTED_API #endif From gsu at UU.NET Tue Jan 6 15:58:55 2004 From: gsu at UU.NET (gsu@UU.NET) Date: Tue, 6 Jan 2004 15:58:55 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: References: Message-ID: Returning an error would certainly be much cleaner than a null pointer reference. I was so puzzled that I checked the API guide and my code repeatly. If no implementation is intended, why advertise it in the guide? So there is no way that I can remove any expired credential? On Tue, 6 Jan 2004, Sam Hartman via RT wrote: > Well, it is not really clear to me if this is a bug or missing code. > We certainly don't implement remove_cred, so there is no way your test > program could successfully remove a credential. > > Clearly we should eventually implement that code and its absence is a > bug. > > Having the unimplemented API segfault definitely does draw the missing > functionality to one's attention. It's true that an assertion would > be cleaner than a null pointer dereference. > The alternative would be to return an error indicating the API is > unimplemented. > > From rt-comment at krbdev.mit.edu Tue Jan 6 15:59:06 2004 From: rt-comment at krbdev.mit.edu (gsu@UU.NET via RT) Date: Tue, 6 Jan 2004 15:59:06 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: Returning an error would certainly be much cleaner than a null pointer reference. I was so puzzled that I checked the API guide and my code repeatly. If no implementation is intended, why advertise it in the guide? So there is no way that I can remove any expired credential? On Tue, 6 Jan 2004, Sam Hartman via RT wrote: > Well, it is not really clear to me if this is a bug or missing code. > We certainly don't implement remove_cred, so there is no way your test > program could successfully remove a credential. > > Clearly we should eventually implement that code and its absence is a > bug. > > Having the unimplemented API segfault definitely does draw the missing > functionality to one's attention. It's true that an assertion would > be cleaner than a null pointer dereference. > The alternative would be to return an error indicating the API is > unimplemented. > > From rt-comment at krbdev.mit.edu Tue Jan 6 16:00:12 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 6 Jan 2004 16:00:12 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: >>>>> "Jeffrey" == Jeffrey Altman via RT writes: Jeffrey> My preference is to add functions to each of the Jeffrey> implementations. The hardest question to answer is which Jeffrey> error should be returned. I do not believe any of the Jeffrey> existing error values is appropriate and a new error: Jeffrey> KRB5_CC_NOSUPP should be added. But I don't object to either proposal. From rt-comment at krbdev.mit.edu Tue Jan 6 16:14:29 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 6 Jan 2004 16:14:29 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: >>>>> "gsu" == gsu writes: gsu> Returning an error would certainly be much cleaner than a gsu> null pointer reference. I was so puzzled that I checked the gsu> API guide and my code repeatly. If no implementation is gsu> intended, why advertise it in the guide? An implementation is intended. The API guide in doc/api does not particularly correspond to the source code. We do not really have API documentation to speak of at this time. gsu> So there is no way that I can remove any expired credential? Correct, but it is probably not a major problem; expired credentials will not be used. If your cache is getting too full, remove all the credentials and get a new TGT. From jaltman at columbia.edu Tue Jan 6 16:49:54 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Tue, 06 Jan 2004 16:49:54 -0500 Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: References: Message-ID: <3FFB2D82.80409@columbia.edu> Sam: I have taken this ticket and will add functions to each implementation which return a new KRB5_CC_NOSUPP error code. I will check in the changes and tag them for 1.3.2. - Jeff -------------- 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/20040106/94f9fd40/attachment.bin From rt-comment at krbdev.mit.edu Tue Jan 6 16:50:03 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Tue, 6 Jan 2004 16:50:03 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: Sam: I have taken this ticket and will add functions to each implementation which return a new KRB5_CC_NOSUPP error code. I will check in the changes and tag them for 1.3.2. - Jeff From gsu at UU.NET Tue Jan 6 17:14:07 2004 From: gsu at UU.NET (gsu@UU.NET) Date: Tue, 6 Jan 2004 17:14:07 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: References: Message-ID: On Tue, 6 Jan 2004, Sam Hartman via RT wrote: > gsu> So there is no way that I can remove any expired credential? > > Correct, but it is probably not a major problem; expired credentials > will not be used. If your cache is getting too full, remove all the > credentials and get a new TGT. > I noticed that if there are more than one credentials for the same server, krb5_get_credentials returns the first one found which may be expired. I have to use krb5_cc_retrieve_cred with KRB5_TC_MATCH_TIMES option to get the good credential and send to the server for authentication. Since I have to keep getting new service ticket, I thought it would be nice if I can remove all old ones. Thank you for the info. From rt-comment at krbdev.mit.edu Tue Jan 6 17:14:37 2004 From: rt-comment at krbdev.mit.edu (gsu@UU.NET via RT) Date: Tue, 6 Jan 2004 17:14:37 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: On Tue, 6 Jan 2004, Sam Hartman via RT wrote: > gsu> So there is no way that I can remove any expired credential? > > Correct, but it is probably not a major problem; expired credentials > will not be used. If your cache is getting too full, remove all the > credentials and get a new TGT. > I noticed that if there are more than one credentials for the same server, krb5_get_credentials returns the first one found which may be expired. I have to use krb5_cc_retrieve_cred with KRB5_TC_MATCH_TIMES option to get the good credential and send to the server for authentication. Since I have to keep getting new service ticket, I thought it would be nice if I can remove all old ones. Thank you for the info. From rt-comment at krbdev.mit.edu Tue Jan 6 18:21:20 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Tue, 6 Jan 2004 18:21:20 -0500 (EST) Subject: [krbdev.mit.edu #2106] CVS Commit In-Reply-To: Message-ID: Add stub function implementations to support krb5_cc_remove_cred() which would cause a null pointer dereference if called. The new KRB5_CC_NOSUPP error is returned to indicate the lack of implementation. To generate a diff of this commit: cvs diff -r5.93 -r5.94 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.27 -r5.28 krb5/src/lib/krb5/ccache/cc_file.c cvs diff -r5.11 -r5.12 krb5/src/lib/krb5/ccache/cc_memory.c cvs diff -r5.5 -r5.6 krb5/src/lib/krb5/ccache/cc_mslsa.c cvs diff -r5.96 -r5.97 krb5/src/lib/krb5/error_tables/ChangeLog cvs diff -r5.74 -r5.75 krb5/src/lib/krb5/error_tables/krb5_err.et From rt-comment at krbdev.mit.edu Tue Jan 6 19:07:19 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Tue, 6 Jan 2004 19:07:19 -0500 (EST) Subject: [krbdev.mit.edu #2106] CVS Commit In-Reply-To: Message-ID: fix typos To generate a diff of this commit: cvs diff -r5.28 -r5.29 krb5/src/lib/krb5/ccache/cc_file.c cvs diff -r5.12 -r5.13 krb5/src/lib/krb5/ccache/cc_memory.c cvs diff -r5.6 -r5.7 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Tue Jan 6 19:42:45 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 6 Jan 2004 19:42:45 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: >>>>> "gsu at UU" == gsu at UU NET via RT writes: gsu at UU> I noticed that if there are more than one credentials for gsu at UU> the same server, krb5_get_credentials returns the first gsu at UU> one found which may be expired. I have to use gsu at UU> krb5_cc_retrieve_cred with KRB5_TC_MATCH_TIMES option to gsu at UU> get the good credential and send to the server for gsu at UU> authentication. Since I have to keep getting new service gsu at UU> ticket, I thought it would be nice if I can remove all old gsu at UU> ones. The logic used by krb5_mk_req in 1.3.x should correctly use only unexpired credentials. Previous versions of Kerberos did not tend to do this correctly. From gsu at UU.NET Wed Jan 7 11:11:25 2004 From: gsu at UU.NET (gsu@UU.NET) Date: Wed, 7 Jan 2004 11:11:25 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: References: Message-ID: On Tue, 6 Jan 2004, Sam Hartman via RT wrote: > >>>>> "gsu at UU" == gsu at UU NET via RT writes: > gsu at UU> I noticed that if there are more than one credentials for > gsu at UU> the same server, krb5_get_credentials returns the first > gsu at UU> one found which may be expired. I have to use > gsu at UU> krb5_cc_retrieve_cred with KRB5_TC_MATCH_TIMES option to > gsu at UU> get the good credential and send to the server for > gsu at UU> authentication. Since I have to keep getting new service > gsu at UU> ticket, I thought it would be nice if I can remove all old > gsu at UU> ones. > > The logic used by krb5_mk_req in 1.3.x should correctly use only > unexpired credentials. Previous versions of Kerberos did not tend to > do this correctly. > > Is this new logic in release after 1.3.1? I am looking at the 1.3.1 source tree. Suppose I have 2 service tickets, the first one is expired. krb5_mk_req calls krb5_get_credentials which returns the expired ticket. krb5_mk_req calls krb5_mk_req_extended with this expired credential. krb5_mk_req_extended calls krb5_validate_times. krb5_validate_times returns KRB5KRB_AP_ERR_TKT_EXPIRED. krb5_mk_req returns KRB5KRB_AP_ERR_TKT_EXPIRED to the caller. So instead of calling krb5_mk_req, I call krb5_cc_retrieve_cred, then call krb5_mk_req_extended with the valid credential. From rt-comment at krbdev.mit.edu Wed Jan 7 11:11:42 2004 From: rt-comment at krbdev.mit.edu (gsu@UU.NET via RT) Date: Wed, 7 Jan 2004 11:11:42 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: On Tue, 6 Jan 2004, Sam Hartman via RT wrote: > >>>>> "gsu at UU" == gsu at UU NET via RT writes: > gsu at UU> I noticed that if there are more than one credentials for > gsu at UU> the same server, krb5_get_credentials returns the first > gsu at UU> one found which may be expired. I have to use > gsu at UU> krb5_cc_retrieve_cred with KRB5_TC_MATCH_TIMES option to > gsu at UU> get the good credential and send to the server for > gsu at UU> authentication. Since I have to keep getting new service > gsu at UU> ticket, I thought it would be nice if I can remove all old > gsu at UU> ones. > > The logic used by krb5_mk_req in 1.3.x should correctly use only > unexpired credentials. Previous versions of Kerberos did not tend to > do this correctly. > > Is this new logic in release after 1.3.1? I am looking at the 1.3.1 source tree. Suppose I have 2 service tickets, the first one is expired. krb5_mk_req calls krb5_get_credentials which returns the expired ticket. krb5_mk_req calls krb5_mk_req_extended with this expired credential. krb5_mk_req_extended calls krb5_validate_times. krb5_validate_times returns KRB5KRB_AP_ERR_TKT_EXPIRED. krb5_mk_req returns KRB5KRB_AP_ERR_TKT_EXPIRED to the caller. So instead of calling krb5_mk_req, I call krb5_cc_retrieve_cred, then call krb5_mk_req_extended with the valid credential. From rt-comment at krbdev.mit.edu Wed Jan 7 14:25:39 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Wed, 7 Jan 2004 14:25:39 -0500 (EST) Subject: [krbdev.mit.edu #2106] bug in krb5_cc_remove_cred API? In-Reply-To: Message-ID: That's not the behavior I see although it is the behavior in pre 1.3.x Kerberos. I set up my host to have 10-minute lifetime tickets and things continue to work. Here's klist output: 01/07/04 13:57:14 01/07/04 14:07:14 host/luminous.mit.edu at SUCHDAMAGE.ORG 01/07/04 14:15:16 01/07/04 23:58:01 imap/solipsist-nation.suchdamage.org at SUCHDAMAGE.ORG 01/07/04 14:22:29 01/07/04 14:32:29 host/luminous.mit.edu at SUCHDAMAGE.ORG From rt-comment at krbdev.mit.edu Wed Jan 7 15:46:29 2004 From: rt-comment at krbdev.mit.edu ( Opal Pugh via RT) Date: Wed, 7 Jan 2004 15:46:29 -0500 (EST) Subject: [krbdev.mit.edu #2107] this is beyond bizzare gwo yssj In-Reply-To: Message-ID: Click the link BELOW FOR 100% FREE PARIS HILTON VIDEO Your Instant Access is Granted to: CLICK THE LINK BELOW TO BEGIN FOR FREE http://www.tnc4u.com/install.php?id=805117 Thank you From rt-comment at krbdev.mit.edu Wed Jan 7 17:17:45 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Wed, 7 Jan 2004 17:17:45 -0500 (EST) Subject: [krbdev.mit.edu #2106] CVS Commit In-Reply-To: Message-ID: pullup from trunk To generate a diff of this commit: cvs diff -r5.82.2.4 -r5.82.2.5 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.26 -r5.26.2.1 krb5/src/lib/krb5/ccache/cc_file.c cvs diff -r5.11 -r5.11.2.1 krb5/src/lib/krb5/ccache/cc_memory.c cvs diff -r5.3.2.2 -r5.3.2.3 krb5/src/lib/krb5/ccache/cc_mslsa.c cvs diff -r5.91.2.4 -r5.91.2.5 krb5/src/lib/krb5/error_tables/ChangeLog cvs diff -r5.72.2.2 -r5.72.2.3 krb5/src/lib/krb5/error_tables/krb5_err.et From rt-comment at krbdev.mit.edu Wed Jan 7 20:33:41 2004 From: rt-comment at krbdev.mit.edu (±¹Á¦ÀüÈ ÄÝ¶óÄÝ via RT) Date: Wed, 7 Jan 2004 20:33:41 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=23?= =?iso-8859-1?q?2108=5D_=7B_=C8=AB_=BA=B8_=7D_=B1=B9?= =?iso-8859-1?q?=C1=A6=C0=FC=C8=AD_=B9=AB=B7=E1=C0=CC=BF=EB=B1=C7?= =?iso-8859-1?q?_=B9=DE=BE=C6=B0=A1=BC=BC=BF=E4=2E=2E=2E=5E*=5E_?= In-Reply-To: Message-ID: »õ ÆäÀÌÁö 1

¡¡

"±¹Á¦ÀüÈ ¹«·áÀÌ¿ë±Ç ÁõÁ¤"

¿Ü±¹¿¡ ÀÖ´Â °¡Á·,Ä£±¸,¾ÖÀÎ¿¡°Ô ¾ÈºÎ ÀüÈ¸¦ ÇÕ½Ã´Ù.. ÄÝ¶óÄÝ °¡¼

»çÀÌÆ® ¹æ¹®¸¸ ÇØµµ, ¿Í¼ º¸±â¸¸ ÇØµµ

¸ðµç(½Å±Ô,±âÁ¸)È¸¿øºÐ²² ¹«·áÅëÈ±Ç ÁõÁ¤

±¸¸Å¿Í »ó°ü¾øÀÌ ÄÝº¸³Ê½º±îÁö Ãß°¡ Àû¸³

º¸Áõº¸ÇèÀ¸·Î ¾ÈÀüÇÑ ¼îÇÎ¿¡¼ °áÀç±îÁö..

¡¡

ÁøÂ¥½Î´Ù, ÀßÅÍÁø´Ù ±¹Á¦ÀüÈ ¼±ºÒ·Î¹ÖÄ«µå ÄÝ¶óÄÝ

±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â 2003³â ÀÌÀü ÀÎÅÍ³ÝÀÇ °ø°³µÈ Àå¼Ò¿¡¼ ½ÀµæÇÏ¿´À¸¸ç, E-mail ÁÖ¼Ò ÀÌ¿Ü¿¡ ¾î¶°ÇÑ °³ÀÎÁ¤º¸µµ °®°í ÀÖÁö ¾Ê½À´Ï´Ù. ¶ÇÇÑ Á¤ÅëºÎ ±Ç°í»çÇ×¿¡ ÀÇ°ÅÇÑ Á¤º¸¸ÞÀÏÀÌ¸ç, ¼ö½Å°ÅºÎ¸¦ ¿øÇÏ½Ã¸é ¿©±â¸¦ Å¬¸¯ÇÏ¼¼¿ä..(If you do not wish to receive this mail click "Unsubscribe" button.)

¡¡

From rt-comment at krbdev.mit.edu Fri Jan 9 05:56:15 2004 From: rt-comment at krbdev.mit.edu (lotto.inter.prom@netscape.net via RT) Date: Fri, 9 Jan 2004 05:56:15 -0500 (EST) Subject: [krbdev.mit.edu #2109] AWARD WINNING FINAL NOTIFICATION. In-Reply-To: Message-ID: 236 CALL REIMBRANATSLIEN, 28275MADRID SPAIN. FROM: THE DESK OF THE VICE PRESIDENT. INTERNATIONAL PROMOTION/PRIZE AWARD. BACTH NO:LDNL/225542/03 REF NO:LDNL/398794/13 RE: AWARD WINNING FINAL NOTIFICATION. This is to inform you of the release of the GLOBAL LOTTERY INTERNATIONAL/WORLD GAMING BOARD. Held on the 3rd December 2003.Due to the mix of numbers, the results were released on the 1st January 2003.Your name was attached to the ticket number 00788769 with serial number 0980978-0 drew the lucky numbers of 1-3-19.Which consequently won the lottery in the 2nd category. You have therefore been approved for the lump sum payment of 3.500.000.00 (Three Million Five Hundred Thousand Euros) in cash credited to file with REF NO:LDNL/398794/13. CONGRATULATION: Due to mix up of some numbers and names, we ask that you keep your winning information confidential until your claims has been processed and your money remitted to you. This is part of our security protocol to avoid double claim and unwarranted abuse of this program by some participants. All participants were selected through a computer ballot system drawn from only Microsoft users from 20,000 companies, and 3,000,000 individual email addresses and names from all over the world. This promotional program takes place every three years. To begin your lottery claim, please contact the processing company that have been appointed for the processing of your lottery winning. The person appointed to handle your processing and remittance of your prize money to an account of your choice is Dr Tomson Powell. Director Operation Euro Credit Commission Madrid Spain. Calle Malaga 47,28100 Spain.Telphone:+34-686-401-693. Email:EUROCREDIT_MADRID at GATORMAIL.WS Any claim not made three weeks from this date, will be returned as unclaimed to the MINISTERIAL VAN DE ECONOMIA SPAIN. Note that all unclaimed winnings will be included in the next stake. Also in order to avoid unnecessary delay and complications, remember to quote your reference and batch numbers on all your correspondence with Dr Tomson Powell Coleman. And please follow all his instruction religiously. Furthermore, should there be any change of address do inform our agent as soon as possible. Congratulations once more from all our staff and thank you for being part of our promotional program. Yours Sincerely, Janet Maria Rodriguez. From rt-comment at krbdev.mit.edu Fri Jan 9 17:28:21 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Fri, 9 Jan 2004 17:28:21 -0500 (EST) Subject: [krbdev.mit.edu #2110] MIT KDC fails to handle unknown padata In-Reply-To: Message-ID: If you send pdata in a request and the MIT KDC doesn't understand any of the padata types at all then it returns failure. It should only return failure in this case if the principal requires preatuh. Thanks to Doug for discovering this. From rt-comment at krbdev.mit.edu Sun Jan 11 07:19:43 2004 From: rt-comment at krbdev.mit.edu (smartins58@hotmail.com via RT) Date: Sun, 11 Jan 2004 07:19:43 -0500 (EST) Subject: [krbdev.mit.edu #2111] URGENT,PLEASE HELP ME In-Reply-To: Message-ID: From: Mrs.Susan Martins 101 Jan Smuts Avenue Craighall Johannesburg South Africa Tel:+27-732250444.[Direct] With due respect trust and humility, I write you this proposal, which I believe will be a great interest to you. I found your contact while I was doing a private research on the Internet for a reliable and capable foreign partner that will assist my family and I. That's why I contacted you.I am Mrs. Susan Martins the wife of Mr. John Martins of Zimbabwe.During the current war against famers in Zimbabwe and from the support of our President Robert Mugabe to claim all the white owned farms in our country, all the white and black farmers were ordered to surrender their farms to his party members and his followers. My husband who was one of the best farmers in our country and treasurer of the farmer's Co-operation did not support his idea and so the party members invaded my husband's farms and burnt everything in the farm, killed my husband and made away with a lot of items in my husband's farm. After the death of my husband, my children and I decided to move out of Zimbabwe because our lives were in danger with the fund that my husband kept in his hidden safe in my house. The amount contained in the safe is US$30,5 Million (Thirty Million, Five Hundred Thousand United States Dollars) and we decided to move this money to the Republic of South Africa, where we deposited it with a private Security Company as a valuables in a box/consignment. This I did for security reasons and to keep from public eyes.I have two options, firstly you can choose to have certain percentage of the money for nominating your account for this transaction, or you can go into partnership with me for proper profitable investment of the money in your country.Whichever the option you want, feel free to notify me. I have also mapped out 5% of this money for all kinds of expenses that might be incured in the process of this transaction. If you do not prefer a partnership, I am willing to give you 20% of the total money, while 75% will be for my family. If you are really capable and willing to assist me as soon as you get this message please contact my son Wodi Martins immediately with the above telephone number (+27-732250444) or by email he knows also about this transaction. for details on how to execute this transaction to the satisfaction of everybody. Finally I want you to know that your ability to keep confidential information about this transaction is very important as all our hope for a better life depends on this money. Best Regard, Mrs.Susan Martins (For The Family) From rt-comment at krbdev.mit.edu Mon Jan 12 00:38:44 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Mon, 12 Jan 2004 00:38:44 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232112=5D_=BF=D5=D4=CB=BC=DB_?= In-Reply-To: Message-ID: ¹ã¶«»ªÁªÍ¨¹ú¼ÊÔËÊä´úÀíÓÐÏÞ¹«Ë¾ H&T INT'L TRANSPORTATION LTD. AIRLINE:ET(°£º½£© 6-Jan-04 To M/N +45K +250K +500K +1000K ABJ TACT 38.00 35.00 33.00 31.00 ACC TACT 39.00 36.00 34.00 32.00 ADD TACT 33.00 30.00 28.00 26.00 BKO TACT 38.00 35.00 33.00 31.00 BJM TACT 33.00 30.00 28.00 26.00 DAR TACT 31.00 28.00 26.00 24.00 EBB TACT 32.00 29.00 27.00 25.00 FIH TACT 38.00 35.00 33.00 31.00 HRE TACT 35.00 32.00 29.00 29.00 JIB TACT 34.00 31.00 29.00 28.00 JNB TACT 36.00 33.00 31.00 30.00 JRO TACT 33.00 30.00 28.00 26.00 KGL TACT 33.00 30.00 28.00 27.00 KRT TACT 37.00 34.00 32.00 30.00 LAD TACT 45.00 42.00 40.00 38.00 LFW TACT 38.00 35.00 33.00 32.00 LLW TACT 33.00 32.00 29.00 27.00 LOS TACT 38.00 35.00 33.00 31.00 LUN TACT 39.00 36.00 34.00 33.00 NBO TACT 30.00 27.00 25.00 23.00 NDJ TACT 29.00 26.00 24.00 23.00 ZNZ TACT 31.00 28.00 26.00 24.00 º½°à£ºET657 ·êÖÜÎåÒ»°à ETD 16©U45 * ÉÏÊöÔË¼Û²»°üÀ¨È¼ÓÍ¸½¼Ó·Ñ1.3Ôª/KG£» * ÉÏÊöÔË¼Û²»°üÀ¨»ú³¡·Ñ0.3Ôª/KG£¬ÔËµ¥·Ñ50.0Ôª/Æ±¡¢±¨¹Ø·Ñ£º200Ôª/Æ± * µ¥Î»£ºCNY/KG ÁªÏµÈË£ºÍõ±ó±ó TEL£º020-87567052 FAX£º020-87561768 ------------------------------------------------------------ ====ÒÔÏÂÄÚÈÝÓë±¾ÓÊÎÞ¹Ø==== ÄãÏëÔÚÍøÉÏ×Ô¶¯ËÑË÷µ½ÄãµÄÄ¿±êÓÃ»§Âð£¿Ò»ÖÂÍÆ¼ö£º¡°ÉÌÎñÌ½²â×¨¼Ò¡± ÄãÏë½«ÄãµÄ²úÆ·ÐÅÏ¢Ö±·¢µ½ÄãµÄÄ¿±êÓÃ»§ÓÊÏäÂð£¿ ¡°ÉÌÎñÓÊ¼þÌØ¿ì¡± ÊµÏÖÄãµÄÐèÇó¡ª¡ª ÎÞÐèSMTP£¬¼¯ÓÊ¼þÈº·¢¡¢¹ÜÀí¡¢Ð£Ñé¡¢ÍË¶©ÓÚÒ»ÉíµÄÎªÊÊÓ¦Ïò¹ú¼ÊÉÏ¸÷¸ö²»Í¬¹ú¼Ò·¢ËÍÉÌÎñÓÊ¼þ¶øÖÆ×÷µÄ¹¦ÄÜÈ«Ãæ¡¢ËÙ¶ÈÆæ¿ì¡¢ÐÔÄÜÎÈ¶¨µÄÈº·¢Èí¼þ¡£±¾ÓÊ¼þÓëÈí¼þ×÷ÕßÎÞ¹Ø£¬½öÏÞÓÃÓÚºÏ·¨ÓÃÍ¾£¡»¶ÓÏÂÔØÃâ·ÑÊÔÓÃ£ºhttp://software.9900.cnÔÚÏß°ïÖúOICQ£º147779246 From rt-comment at krbdev.mit.edu Tue Jan 13 05:12:58 2004 From: rt-comment at krbdev.mit.edu ( Web via RT) Date: Tue, 13 Jan 2004 05:12:58 -0500 (EST) Subject: [krbdev.mit.edu #2114] Bullet Proof Web Hosting & Server In-Reply-To: Message-ID: We offer reliable bulk email friendly web hosting services

Two IPs 512MB RAM DDR PIIII CPU 40 GB SCS Intel 82559 LAN /(2U) Unlimited Data Transfer Linux/Windows/FreeBSD	Three IPs 1024MB RAM DDR PIIII / Two CPU 120 GB SCS Intel 82559 LAN /(2U) Unlimited Data Transfer Linux/Windows/FreeBSD	Dynamic IP 1024MB RAM DDR PIIII / Two CPU 180 GB SCS Intel 82559 LAN /(2U) Unlimited Data Transfer Linux/Windows/FreeBSD
Price: No setup fee US$ 599.00/month	Price: No setup fee US$ 699.00/month	Price: No setup fee US$ 999.00/month

Allowed Usage
You can use the server for any of the following:

Direct Bulk Mailing or Proxy Mailing
Web Site Hosting
Proxy, Relay or Port Scanning

We can supply Targeted Email Addresses according to your requirements, and
send out Targeted Emails for you. For more information, please contact us by
ContactHosting at tom.com

It will be our pleasure to do business with you.

PS: Please do not reply to this e-mail. Contact us by ContactHosting at tom.com

Thanks!

Mr Bellete
Support Teams

****************************************************************************************
Receiving this email because you registered to receive special offers from us.
Please click here to unscbscirbe:lly at yahoo.com?subject=take-off
****************************************************************************************

mddfgkjNaAOZSxQ From rt-comment at krbdev.mit.edu Tue Jan 13 05:33:31 2004 From: rt-comment at krbdev.mit.edu (The RT System itself via RT) Date: Tue, 13 Jan 2004 05:33:31 -0500 (EST) Subject: [krbdev.mit.edu #2115] kdc segfaults in/below foreach_localaddr In-Reply-To: Message-ID: >From paul at clubi.ie Tue Jan 13 05:33:27 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 FAA28364; Tue, 13 Jan 2004 05:33:26 -0500 (EST) Received: from hibernia.jakma.org (hibernia.jakma.org [213.79.33.168]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i0DAXPPg029876 for ; Tue, 13 Jan 2004 05:33:25 -0500 (EST) Received: from fogarty.jakma.org (IDENT:500 at fogarty.jakma.org [192.168.0.4]) by hibernia.jakma.org (8.12.10/8.12.10) with ESMTP id i0DAXNWS003478 for ; Tue, 13 Jan 2004 10:33:24 GMT Date: Tue, 13 Jan 2004 10:33:23 +0000 (GMT) From: Paul Jakma X-X-Sender: paul at fogarty.jakma.org To: krb5-bugs at mit.edu Subject: SEGV in include/foreachaddr.c on startup Message-ID: X-NSA: iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >Submitter-Id: net >Originator: >Organization: Paul Jakma paul at clubi.ie paul at jakma.org PGP5 public key: http://www.clubi.ie/jakma/publickey.txt >Confidential: no >Synopsis: kdc segfaults in/below foreach_localaddr >Severity: serious >Priority: high >Category: krb5-kdc >Class: sw-bug >Release: krb5-1.3.1 >Environment: System: Linux hibernia.jakma.org 2.4.22-1.2140.nptl #1 Tue Jan 6 20:21:24 EST 2004 i586 i586 i386 GNU/Linux Architecture: i586 >Description: kdc segfaults on startup in 3 places below foreach_localaddr due to dereferencing incomplete interface structures. When calling addr_eq at ~ 396 and when calling the *pass1fn() callback at approx line 402. In both cases its due to the ifa_addr member of either ifp or ifp2 being NULL. SEGV in addr_eq due to ifp->ifa_addr being NULL: (gdb) bt #0 addr_eq (s1=0x0, s2=0x9a398cc) at foreachaddr.c:205 #1 0x08053796 in foreach_localaddr (data=0xbff02d28, pass1fn=0x8053d0c , betweenfn=0, pass2fn=0) at foreachaddr.c:396 #2 0x08054143 in setup_network (prog=0xbff86b6c "krb5kdc") at network.c:656 #3 0x080530ae in main (argc=1, argv=0xbff02dd4) at main.c:685 SEGV in setup_udp_port, due to passing in NULL ifp->ifa_addr. (gdb) bt #0 0x08053d31 in setup_udp_port (P_data=0xbff7c8f8, addr=0x0) at network.c:491 #1 0x08053777 in foreach_localaddr (data=0xbff7c8f8, pass1fn=0x8053d10 , betweenfn=0, pass2fn=0) at foreachaddr.c:402 #2 0x08054147 in setup_network (prog=0xbffe0b6c "krb5kdc") at network.c:656 #3 0x080530ae in main (argc=1, argv=0xbff7c9a4) at main.c:685 SEGV in addr_eq again, but ifp2->ifa_addr is NULL. (gdb) bt #0 0x080534a6 in addr_eq (s1=0x96aa9d4, s2=0x0) at foreachaddr.c:205 #1 0x080537a6 in foreach_localaddr (data=0xbff61318, pass1fn=0x8053d1c , betweenfn=0, pass2fn=0) at foreachaddr.c:398 #2 0x08054153 in setup_network (prog=0xbff92b6c "krb5kdc") at network.c:656 #3 0x080530ae in main (argc=1, argv=0xbff613c4) at main.c:685 >How-To-Repeat: I'm not sure how to repeat, but if one can arrange a system to have either ifp->ifa_addr and/or ifp2->if_addr be NULL the crash can be reproduced. The network interface setup on my system is as follows: # ip address show 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host 2: sit0 at NONE: mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 7: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:60:97:54:1e:c9 brd ff:ff:ff:ff:ff:ff inet 192.168.0.3/24 brd 192.168.0.255 scope global eth0 inet6 fe80::260:97ff:fe54:1ec9/64 scope link inet6 2001:770:105:1:260:97ff:fe54:1ec9/64 scope global 14: ppp0: mtu 1492 qdisc cbq qlen 3 link/ppp inet 213.79.33.168 peer 213.79.63.254/32 scope global ppp0 15: sixxs at NONE: mtu 1280 qdisc noqueue link/sit 213.79.33.168 peer 193.1.31.74 inet6 fe80::d54f:21a8/128 scope link inet6 2001:770:100:8::2/64 scope global >Fix: The below patch fixes the problem for me, by simply ignoring interfaces whose ifa_addr is NULL. To what extent it papers over a deeper problem I do not unfortunately know. --- krb5-1.3.1/src/include/foreachaddr.c.orig 2002-09-03 23:11:02.000000000 +0100 +++ krb5-1.3.1/src/include/foreachaddr.c 2004-01-13 10:10:57.000000000 +0000 @@ -380,6 +380,8 @@ #ifdef DEBUG printifaddr (ifp); #endif + if (ifp->ifa_addr == NULL) + continue; if ((ifp->ifa_flags & IFF_UP) == 0) continue; if (ifp->ifa_flags & IFF_LOOPBACK) { @@ -388,7 +390,8 @@ } /* If this address is a duplicate, punt. */ match = 0; - for (ifp2 = ifp_head; ifp2 && ifp2 != ifp; ifp2 = ifp2->ifa_next) { + for (ifp2 = ifp_head; ifp2 && ifp2->ifa_addr && ifp2 != ifp; + ifp2 = ifp2->ifa_next) { if ((ifp2->ifa_flags & IFF_UP) == 0) continue; if (ifp2->ifa_flags & IFF_LOOPBACK) From rt-comment at krbdev.mit.edu Tue Jan 13 08:48:55 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Tue, 13 Jan 2004 13:48:55 -0000 Subject: [krbdev.mit.edu #2016] Kerberos 5 will not compile on Solaris 7, GCC2.95.3 In-Reply-To: Message-ID: I'm sort of surprised you are seeing this problem. We seem to build fine on Solaris using Gcc. It may be Solaris 9 but I would be mildly surprised at a change that mattered. From rt-comment at krbdev.mit.edu Tue Jan 13 08:56:50 2004 From: rt-comment at krbdev.mit.edu (Tom Yu via RT) Date: Tue, 13 Jan 2004 13:56:50 -0000 Subject: [krbdev.mit.edu #2016] Kerberos 5 will not compile on Solaris 7, GCC2.95.3 In-Reply-To: Message-ID: Ok, there does appear to be a problem with fake-addrinfo.h -- if it's included prior to any inclusion of stdio.h, it compiles code calling out to sprintf() without a prototype. This probably is only seen on platforms where we actually need to use our own getaddrinfo() implementation. From rt-comment at krbdev.mit.edu Tue Jan 13 15:53:19 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 13 Jan 2004 15:53:19 -0500 (EST) Subject: [krbdev.mit.edu #2116] getsockname argument handling In-Reply-To: Message-ID: Our configure script tries to work out the types of the arguments to getsockname and getpeername. 1) It completely fails to figure out argument 3 (pointer to length) on Solaris in normal 64-bit mode, because without the XPG-enabling macros defined, the only system-provided declaration uses "void *". Possibly we should turn those macros on (specifically, -D_XOPEN_SOURCE=500 to get the SUSv2 declarations, and -D__EXTENSIONS__ to re-enable SVR4 extensions) for Solaris. Greg Hudson and I have disagreed on this point over Zephyr. I'm still not fully convinced one way or the other. Sam agreed with Greg. 2) If the configure scripts can't work it out, the corresponding macros aren't defined, so each source file using them has to test for that and specify defaults. The defaults differ. Each of "size_t", "int", and "unsigned int" is used in multiple places. The defaults should be consistent, and implemented in aclocal.m4. 3) Using "size_t" is wrong, and on 64-bit Solaris breaks things. The default probably should be "socklen_t", unless there's a platform where socklen_t exists, *and* socklen_t* isn't right for getsockname, *and* the configure script can't figure out the correct type. In our current nightly testing configurations, it appears that Tru64 5.1A, IRIX 6.5.7, and OS X 10.2 are the configurations where we don't find a socklen_t type we can use, and in each of those cases, the configure script does successfully determine the types to use for getsockname. 4) Testing for getpeername independently is probably a waste of cycles. I'd be very surprised if there's any platform anywhere that uses different types for getsockname and getpeername. Ken From rt-comment at krbdev.mit.edu Wed Jan 14 02:05:22 2004 From: rt-comment at krbdev.mit.edu ( ½òÃÅÈË²ÅÈÈÏß via RT) Date: Wed, 14 Jan 2004 02:05:22 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232?= =?iso-8859-1?q?117=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 Wed Jan 14 16:32:59 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Wed, 14 Jan 2004 16:32:59 -0500 (EST) Subject: [krbdev.mit.edu #2118] [Will Fiveash] bug in krb 1.3.2-beta1 kdc In-Reply-To: Message-ID: Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Wed, 14 Jan 2004 16:13:11 -0500 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by suchdamage.org (Postfix) with ESMTP id 0ED15131AC for ; Wed, 14 Jan 2004 16:13:11 -0500 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id i0ELCua3001228 for ; Wed, 14 Jan 2004 16:12:57 -0500 (EST) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0ELCuj4004476 for ; Wed, 14 Jan 2004 13:12:56 -0800 (PST) Received: from alton.central.sun.com (alton.Central.Sun.COM [129.153.128.101]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i0ELCqbq023725; Wed, 14 Jan 2004 14:12:52 -0700 (MST) Received: from alton.central.sun.com (localhost [127.0.0.1]) by alton.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i0ELCppU423380; Wed, 14 Jan 2004 15:12:51 -0600 (CST) Received: (from willf at localhost) by alton.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i0ELCprX423379; Wed, 14 Jan 2004 15:12:51 -0600 (CST) X-Authentication-Warning: alton.central.sun.com: willf set sender to william.fiveash at sun.com using -f Date: Wed, 14 Jan 2004 15:12:51 -0600 From: Will Fiveash To: Sam Hartman Cc: Nicolas Williams Subject: bug in krb 1.3.2-beta1 kdc Message-ID: <20040114211250.GA421273 at sun.com> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-10.8 required=5.0 tests=BAYES_10,PGP_SIGNATURE_2,USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-=" --==-=-= Content-Disposition: inline In src/kdc/main.c, line 203: /* Handle KDC ports */ if (rparams && rparams->realm_kdc_ports) rdp->realm_ports = strdup(rparams->realm_kdc_ports); else rdp->realm_ports = strdup(def_udp_ports); if (rparams && rparams->realm_kdc_tcp_ports) rdp->realm_tcp_ports = strdup(rparams->realm_kdc_ports); ^^^ realm_kdc_tcp_ports else rdp->realm_tcp_ports = strdup(def_tcp_ports); -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT) GPG PubKey ID:0x7D31DC39 --==-=-= Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (SunOS) iD8DBQFABbDS8uNabn0x3DkRAsOwAJ90GV1w0wIENOd6xhk5iMO7wk6rygCggvwM qqtSFANWr9bxOIw2Cvnb7nM= =EEQO -----END PGP SIGNATURE----- --==-=-=-- From rt-comment at krbdev.mit.edu Thu Jan 15 02:06:25 2004 From: rt-comment at krbdev.mit.edu ( Liang jianhua via RT) Date: Thu, 15 Jan 2004 02:06:25 -0500 (EST) Subject: [krbdev.mit.edu #2119] Linux device number bug report In-Reply-To: Message-ID: Hello, I have some questions about device number extension. In Linux kernel 2.6, device number will be extended from 16-bit to 32-bit. All utilities and libraries should make corresponding extension for this new feature in kernel 2.6. As the format of extended device number is as following: mmmm mmmm mmmm MMMM MMMM MMMM mmmm mmmm, that "major" should be 12-bit, and "minor" should be 20-bit. "M" means major device number. "m" means minor device number. But I find that ¡°krb5-1.2.7¡± uses structure dev_t and operates the minor device number as 8-bit. In file krb5-1.2.7/src/util/pty/getpty.c: 109 ptynum = (int)(stb.st_rdev&0xFF) So it seems not to correspond to device number extension. Since I didn¡¯t find any information about this aspect in homepage of this package, I wonder whether the latest version has completed the device number extension? If not, will it be completed in the future? And when? Looking forward to answering. Liang Jianhua regards -------------------------------------------------- Liang Jianhua Dept. of Technology and Development Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No. 16-5, Guanzhou Rd., Nanjing, P.R.China PHONE: +86+25-6630523-636 FUJITSU INTERNAL: 79955-636 FAX: +86+25-3317685 Mail: nuljh at nanjing-fnst.com -------------------------------------------------- From rt-comment at krbdev.mit.edu Thu Jan 15 02:12:26 2004 From: rt-comment at krbdev.mit.edu ( Liang jianhua via RT) Date: Thu, 15 Jan 2004 02:12:26 -0500 (EST) Subject: [krbdev.mit.edu #2119] AutoReply: Linux device number bug report In-Reply-To: Message-ID: Hello, I have some questions about device number extension. In Linux kernel 2.6, device number will be extended from 16-bit to 32-bit. All utilities and libraries should make corresponding extension for this new feature in kernel 2.6. As the format of extended device number is as following: mmmm mmmm mmmm MMMM MMMM MMMM mmmm mmmm, that "major" should be 12-bit, and "minor" should be 20-bit. "M" means major device number. "m" means minor device number. But I find that ¡°krb5-1.2.7¡± uses structure dev_t and operates the minor device number as 8-bit. In file krb5-1.2.7/src/util/pty/getpty.c: 109 ptynum = (int)(stb.st_rdev&0xFF) So it seems not to correspond to device number extension. Since I didn¡¯t find any information about this aspect in homepage of this package, I wonder whether the latest version has completed the device number extension? If not, will it be completed in the future? And when? Looking forward to answering. Liang Jianhua regards -------------------------------------------------- Liang Jianhua Dept. of Technology and Development Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST) No. 16-5, Guanzhou Rd., Nanjing, P.R.China PHONE: +86+25-6630523-636 FUJITSU INTERNAL: 79955-636 FAX: +86+25-3317685 Mail: nuljh at nanjing-fnst.com -------------------------------------------------- From rt-comment at krbdev.mit.edu Fri Jan 16 03:54:30 2004 From: rt-comment at krbdev.mit.edu (kuan2000@21cn.com via RT) Date: Fri, 16 Jan 2004 03:54:30 -0500 (EST) Subject: [krbdev.mit.edu #2126] 3721 In-Reply-To: Message-ID: http://www.panyu.net.cn From rt-comment at krbdev.mit.edu Fri Jan 16 07:03:02 2004 From: rt-comment at krbdev.mit.edu (xbin2@sina.com via RT) Date: Fri, 16 Jan 2004 07:03:02 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232127=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 Fri Jan 16 19:26:40 2004 From: rt-comment at krbdev.mit.edu ( Arlene Berry via RT) Date: Fri, 16 Jan 2004 19:26:40 -0500 (EST) Subject: [krbdev.mit.edu #2131] bug in 1.3.1 krb5_get_init_creds_keytab() In-Reply-To: Message-ID: I've found a bug in krb5 1.3.1 in function krb5_get_init_creds_keytab(). I'm using MS Active Directory for my KDC. I created a service principal account and I created a key table entry for it with a DEC-CBC-MD5 key type. The AD account has a userAccountControl atribute which contains bit flags. When the UF_USE_DES_KEY_ONLY bit is set, krb5_get_init_creds_keytab() successfully gets a TGT using the key table entry. When the bit is not set, the function returns the error "Key table entry not found". When I do the same thing with 1.2.5 or 1.2.8, krb5_get_init_creds_keytab() gets a TGT no matter how that bit is set. The reason it's an issue is that if an AD account is created with the bit set, a key table entry is created, and then later someone changes the UF_USE_DES_KEY_ONLY bit, the key table entry can no longer be used to get a TGT even though it's still good. I've done a lot of debugging. The basic sequence of events is that a request is built without preauth and sent to the KDC, a reply requesting preauth is received, and an attempt is made to satisfy the request for preauth. Krb5_get_init_creds_keytab() calls krb5_get_init_creds() which calls krb5_do_preauth(). What happens in krb5_do_preauth() is that it looks at a list of etypes returned by the KDC, chooses one, and then tries to find a key table entry with a similar key type. The code which chooses the etype looks like this: for (etype_found = 0, valid_etype_found = 0, k = 0; !etype_found && k < request->nktypes; k++) { for (l = 0; etype_info[l]; l++) { if (etype_info[l]->etype == request->ktype[k]) { etype_found++; break; } The etype_info array comes from the KDC's reply. Request->ktype is provided by krb5_get_init_creds(). Krb5_get_init_creds() creates request and sets request->ktype to the results of krb5_get_default_in_tkt_ktypes() if not overridden by the options parameter which is passed from the application to krb5_get_init_creds() by krb5_get_init_creds_keytab(). With AD the etype_info[]->etype list of etypes is 3, 1 when UF_USE_DES_KEY_ONLY is set and the list is 23, 3, 1 when UF_USE_DES_KEY_ONLY is not set. The list provided by krb5_get_default_in_tkt_ktypes() is 18, 16, 23, 1, 3, 2. The type chosen is 1 when AD returns 3, 1 and it's 23 when AD returns 23, 3, 1. The problem is nothing looked in the key table to see what's actually available. The key table lookup happens after the type is chosen. Since what's in the key table is 3 which is similar to 1, the key table entry is used when UF_USE_DES_KEY_ONLY is set, and it's rejected when UF_USE_DES_KEY_ONLY is not set. The 1.2.8 preauth code simply uses the first entry in the etype_info array which is always 3 which must be because 1.2.8 doesn't support 23 and doesn't include it in its initial request. The real problem is that the default ktypes list that krb5_get_init_creds() uses in the initial request is not suitable when krb5_get_init_creds() is called by krb5_get_init_creds_keytab(). It seems to me that the solution is for krb5_get_init_creds_keytab() to examine the key table and set an etype list in the options parameter before passing it through to krb5_get_init_creds() if a list is not provided by the calling application. If this change were made to krb5_get_init_creds_keytab(), it should solve the problem as I simulated it by temporarily modifying the application to set the options etype list to 3, 1 and got a TGT. Arlene Berry From rt-comment at krbdev.mit.edu Sat Jan 17 12:13:43 2004 From: rt-comment at krbdev.mit.edu (ggg@hotmail.com via RT) Date: Sat, 17 Jan 2004 12:13:43 -0500 (EST) Subject: [krbdev.mit.edu #2132] Please receive In-Reply-To: Message-ID:

Email Marketing

Email more than 2,500,000+ TARGETED prospects EVERYDAY! That's over 75,000,000+ prospects per month (and growing!). Our Optin email safelists are 100% Optin and 100% legal to use. Your ad will reach only those prospects who have requested to be included in Optin safelists for people interested in new business opportunities, products and services.

Products

World Email Lists sample download
Country or area	total emails	total price	half email/half price	sample	order
America (details)	175 Million Email Address	$220 US	$100 US	free download	Buy Now
Europe (details)	156 Million Email Address	$250 US	$150 US	free download	Buy Now
Asia (details)	168 Million Email Address	$150 US	$ 80 US	free download	Buy Now
China(PRC)	80 Million Email Address	$200 US	$100 US	free download	Buy Now
HongKong (details)	3.25 Million Email Address	$200 US	$100 US	free download	Buy Now
TaiWan (details)	2.25 Million Email Address	$200 US	$100 US	free download	Buy Now
Japan	27 Million Email Address	$200 US	$100 US	free download	Buy Now
Australia (details)	6 Million Email Address	$150 US	$ 80 US	free download	Buy Now
Canda (details)	10 Million Email Address	$150 US	$100 US	free download	Buy Now
Russia	38 Million Email Address	$120 US	$100 US	free download	Buy Now
England	3.2 Million Email Address	$200 US	$100 US	free download	Buy Now
German	20 Million Email Address	$200 US	$120 US	free download	Buy Now
France	38 Million Email Address	$150 US	$ 80 US	free download	Buy Now
India	12 Million Email Address	$120 US	$ 60 US	free download	Buy Now
CENTRAL & SOUTH AMERICAN AREA (details)	40 Million Email Address	$220 US	$100 US		Buy Now
MIDDLE EAST & AFRICA (details)	45 million Email Address	$220 US	$100 US		Buy Now
SOUTH EAST AREA (details)	32 million Email Address	$220 US	$100 US		Buy Now
Category Name	total emails	total price	half email/half price		order
Apparel, Fashion, Textiles and Leather	4,654,565	$150	$100 US		Buy Now
Automobile & Transportation	6,547,845
Business Services	6,366,344
Chemicals	3,445,565
Computer & Telecommunications	654,655
Construction & Real Estate	3,443,544
Consumer Electronics	1,333,443
Energy, Minerals & Metals	6,765,683
Environment	656,533
Food & Agriculture	1,235,354
Gems & Jewellery	565,438
Health & Beauty	804,654
Home Supplies	323,232
Industrial Supplies	415,668
Office Supplies	1,559,892
Packaging & Paper	5,675,648
Printing & Publishing	6,563,445
Security & Protection	5,653,494
Sports & Entertainment	3,488,455
Toys, Gifts and Handicrafts	2,135,654
All 136 nations , 40 trades email lists total price $500 US Buy Now

information please click here go to website
website: http://202.98.223.74/soft/html/wd/wd3.htm

the silver star internet information Company

copyright at 2003-2005 all reserved

From rt-comment at krbdev.mit.edu Sun Jan 18 04:26:59 2004 From: rt-comment at krbdev.mit.edu (xbin2@sina.com via RT) Date: Sun, 18 Jan 2004 04:26:59 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232133=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¿á±¦×¿Ô½µÄ»áÒéÊ¹ÓÃ¹¦ÄÜ

1£©½»»¥Ê½°×°å´¥¿Ø¹¦ÄÜ

2£©×ÔÓÉ°åÊéÓë±ê×¢¹¦ÄÜ

¡¡

Í¨¹ýÊ¹ÓÃ¹âÏß×÷ÎªÊéÐ´±Ê¼£µÄ³ÐÔØÌå£¬³¹µ×½â¾öÁËÒÔÍùÊéÐ´µÄÎÛÈ¾ÓëÏûºÄÎÊÌâ£¬ÊÇÕæÕýµÄÂÌÉ«»·±£²úÆ·¡£

3£©ÖÇÄÜ²¶»ñ¡¢×Ô¶¯ÊµÊ±´æ´¢ÓëÔÚÏß´òÓ¡¹¦ÄÜ

4£©Ö§³Ö½»»¥Ê½ÍøÂçÓ¦ÓÃ

CoolBoard¿á±¦×¿Ô½µÄ»áÒéÊ¹ÓÃÐÔÄÜ

¡¡

1£©¸üºÃµÄ³¬µÍ·´¹â

2£©¸üºÃµÄÄÍÄ¥ÐÔÄÜºÍÄÍÓÃÐÔ

CoolBoard¿á±¦Ê¹ÓÃ×¨ÓÃ¡¢¸ßÆ·ÖÊµÄÄÍÄ¥±íÃæ²ÄÁÏ£¬¹âÃæÓ²¶ÈÖ¸±ê´ïµ½5HË®Æ½ÒÔÉÏ£¬µ¥µã´¥ÃþÊÙÃü¸ßµ½1000Íò´ÎÒÔÉÏ¡£

3£©¸üºÃµÄ±íÃæÐÔÄÜºÍ¿¹ÓÍ×ÕÄÜÁ¦

CoolBoard¿á±¦ÓÐÐ§ÀûÓÃ±íÃæÎïÀíÑ§ÔÀí£¬Ê¹µÃCoolBoard¿á±¦°åÃæµÄ¿¹ÓÍ×ÕÄÜÁ¦¸üÇ¿¡£

4£©¸üºÃµÄÓ¦ÓÃ³¡ËùÊÊÓÃÐÔ

5£©¸ü¶àµÄ½ÌÑ§³¡ËùÐÅÏ¢°²È«´ëÊ©

CoolBoard¿á±¦Ìá¹©ÁË¸ü¶àµÄÐÅÏ¢°²È«ºÍÃÜÂë¿ØÖÆÊÖ¶Î£¬ÒÔ±£Ö¤»áÒé»·¾³µÄ°²È«ÐÔºÍ·ÀÖ¹»áÒéÄÚÈÝµÄÐ¹ÃÜ¡£

¡¡

6£©¸ü¶àµÄÈËÐÔ»¯Åä±¸

¡¡

From rt-comment at krbdev.mit.edu Mon Jan 19 04:16:15 2004 From: rt-comment at krbdev.mit.edu (kirsty_21technology@hotmail.com via RT) Date: Mon, 19 Jan 2004 04:16:15 -0500 (EST) Subject: [krbdev.mit.edu #2134] Re: Ejacu.late Like A P0RN Star! In-Reply-To: Message-ID: cumpills2 SHOWER YOUR LOVER WITH
BUCKET LOADS OF SP.ERM!

It's Amazing & Has Finally Arrived! A Unique Pill That Will Increase Your Spe.rm By Up To 500% More -We Guaranteed It!

Maintain Rock Solid Erect.ions.
Increased Sex.ual Desire & Performance.
- Shoot Out Amazing Amounts Of Spe.rm Everywhere.
- Multiple Extreme Orga.sms! Have 2 Or 3 Each Time.
- 100% Mon.ey Back Guarantee With Every Order.

EJACU.LATE LIKE A P0RN STAR

READ MORE INFO HERE

no more emailz

From rt-comment at krbdev.mit.edu Mon Jan 19 05:21:15 2004 From: rt-comment at krbdev.mit.edu ( Kuhneng via RT) Date: Mon, 19 Jan 2004 05:21:15 -0500 (EST) Subject: [krbdev.mit.edu #2135] Fwd: Want to have S E X, 20 times a day ? In-Reply-To: Message-ID: Loading, Please Wait... , Moiseyev , Boxford

From rt-comment at krbdev.mit.edu Tue Jan 20 00:47:09 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Tue, 20 Jan 2004 00:47:09 -0500 (EST) Subject: [krbdev.mit.edu #2137] krb5_cc_get_principal prevents implementation of auto kinit dialogs in KfM/KfW In-Reply-To: Message-ID: KfM and KfW both support the ability to display kinit dialogs automatically under several circumstances: * kclient api GetTicketGrantingTicket() when no tgt present * krb4 krb_mk_req() call with service == "krbtgt" and no tgt present * gssapi clients calling acquire_init_cred() * krb5 clients calling krb5_fwd_tgt_creds() or krb5_sendauth() However, there is a class of krb5 clients (such as sidecar, rcmd, telnet) which all perform calls to krb5_cc_get_principal() prior to a krb5_get_credentials() call. The krb5_cc_get_principal() call is used to set the client portion of the krb5_creds structure which is used to specify which credentials krb5_get_credentials() should obtain. In the case where there is no ccache or no credentials in the ccache, krb5_cc_get_principal() returns an error which in turn prevents calls krb5_get_credentials, krb5_mk_req, or krb5_sendauth from being made. krb5_cc_get_principal() looks like it would be a nice place to place a hook for a kinit dialog until you realize that krb5_cc_get_principal() is called at many times throughout the krb5 library for which we would certainly not desire a kinit dialog to appear. At the current time this is a limitation of what we can acheive. I do not have a suggestion of how to address this limitation, but if we have time the team should attempt to address it. From rt-comment at krbdev.mit.edu Tue Jan 20 08:44:23 2004 From: rt-comment at krbdev.mit.edu (clean_actSwarthout@wildmail.com via RT) Date: Tue, 20 Jan 2004 08:44:23 -0500 (EST) Subject: [krbdev.mit.edu #2138] Don't get busted ! ! . . . . . . . . . crankshaft In-Reply-To: Message-ID: cleanactpro

Keep Your Job - Keep Your Marriage - Keep Out Of Trouble

DID YOU KNOW!

That anyone who uses your computer can see what websites you've visited?
And that simply deleting history only removes part of the records.
If someone starts typing a web site, your browser will recall old sites you've visited?
Your boss or wife can start typing "www.dateline.com" and the browser will recall "www.datingclub.com"
Every picture on every site you've ever visited has been copied to your hard drive?
Deleting the cache does not permanently remove them!
And there are many more ways you are secretly tracked...

Download Our Software Today To Be Safe

No More Emailz Plz

decencies , deregulate

From rt-comment at krbdev.mit.edu Wed Jan 21 04:08:55 2004 From: rt-comment at krbdev.mit.edu (mike adenuga via RT) Date: Wed, 21 Jan 2004 04:08:55 -0500 (EST) Subject: [krbdev.mit.edu #2140] Verry urgent need In-Reply-To: Message-ID: STRICTLY PRIVATE & URGENT BUSINESS PROPOSAL ATTENTION: TRANSFER OF US$20,500,000,00 AMERICAN DOLLARS INTO YOUR ACCOUNT. It is my greatest pleasure to write you this email on behalf of my colleagues. I have decided to seek a confidential co-operation with you in the execution of a deal hereunder for the mutual benefit of all parties involved, and hope you will keep it strictly confidential because of the nature of the transaction. Within the Department of Mining Resources where I work as the Director of Project Implementation, I have the co-operation of two other top officials and we have in our possession an overdue payment in United States of America Dollars. The fund represents certain percentage of contracts executed on behalf of my Ministry by a Foreign Contractor. We were instrumental to the over-invoicing of the contract to the tune of US$20,500,000.000) Twenty Million Five Hundred Thousand United States Dollars) though, the actual cost has been paid to the original contractor, leaving the excess balance of (US$20,500,000.00) unclaimed. With democratic constitution, sound economic growth, financial discipline, social and economic stability and a confident fielding of the full team of its talented people, the government of the Republic of South Africa believes that private investment in general, and foreign investment in particular are the real engines for sustainable economic development, for which reason it has continued to encourage investment in the key growth-oriented sector of Mining with sincere determination to pay foreign contractors all debts owed so as to continue to enjoy a mutually beneficial cooperation and maintain good relationship with other foreign governments. As a result we included our Bills for approvals with the co-operation of some officials at the Federal Ministry of Finance. We are thus seeking your assistance Morally and otherwise to stand as the Beneficiary of the unclaimed funds, since the code of conduct does not allow us to operate a foreign account or own a foreign company. In order to commence immediate action on the said project, we will require the following urgently, 1. Your company name and address, confidential telephone and fax numbers. 11 Your Bank name and address, Account number, ABA Routing number, Account name, Bank telephone and fax numbers. The requested information will be used to make a formal application to the Government Ministries as a matter of procedure for the issuance of approval for the payment of the funds into your account. It does not really matter whether or not your company does contract projects of the nature described here. The assumption is that your company won the major contract and subcontracted it to other companies. More often than not, big trading companies and firms of unrelated fields win major contracts, and subcontract to more specialized firms for execution. With our strong connections in the South Africa Reserve Bank (SARB), and department of Finance, and if ably supported by you as our foreign partner, you are assured of 100% Risk-Free and mutually beneficial transaction.We hereby propose that should you be willing to assist us in this transaction, your share will be 20%, while my colleagues and I receive 75% While 5% will be set aside to offset expenses incured by both parties during the course of transaction. This transaction should be considered 100% safe and legal, provided you treat it with utmost confidentiality it deserves. I have reposed my confidence in you and hope that you will not disappoint us now or in future.So far, much has been said and due to our sensitive positions we cannot afford a slip in this transaction, neither can we give out our identities as per our respective offices but where relationship is established and smooth operation commences, you will be furnished with all you deserve to know. Kindly notify me by this email address or alternatively: mikeadenuga at mail2world.com for further details upon your acceptance of this proposal. Please treat as urgent and highly confidential. Dr. Mike Adenuga --------------------------------- Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now From rt-comment at krbdev.mit.edu Wed Jan 21 09:22:30 2004 From: rt-comment at krbdev.mit.edu ( Kmadhav via RT) Date: Wed, 21 Jan 2004 09:22:30 -0500 (EST) Subject: [krbdev.mit.edu #2141] PEN1S Patch - Enla.rge Your C0CK ! ! . . . . . . . puzzles In-Reply-To: Message-ID: dickpatch1 ADD 3+ INCHES TO YOUR PEN1S

MAGNA-RX PEN1S ENLA.RGEMENT PATCH

- No Pills Or Capsules
- No Lotions Or Cremes
- No Pumps, Weights, Or Exercises
- Doctor Designed & Endorsed
- 100% Safe & Natural
- Increase PEN1S Size By 2’’ To 4’’
- Your PEN1S Will Be Thicker And Fuller
- Your Confidence & Self-Esteem Will Soar
- Experience Rock Hard Erec.tions
- Increase In Desire
- Explosive, More Intence Orga.sms
- FREE 1 Month Supply Of Ma.gna-RX Patch's
- Fast, Discrete Shipping

READ MORE INFO HERE

no more emailz

dispatched , astronaut From hartmans at MIT.EDU Thu Jan 22 03:07:21 2004 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 22 Jan 2004 03:07:21 -0500 Subject: [krbdev.mit.edu #2137] krb5_cc_get_principal prevents implementation of auto kinit dialogs in KfM/KfW In-Reply-To: (Jeffrey Altman via's message of "Tue, 20 Jan 2004 00:47:09 -0500 (EST)") References: Message-ID: Do these applications actually need to be calling krb5_cc_get_principal? From rt-comment at krbdev.mit.edu Thu Jan 22 03:08:49 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 22 Jan 2004 03:08:49 -0500 (EST) Subject: [krbdev.mit.edu #2137] krb5_cc_get_principal prevents implementation of auto kinit dialogs in KfM/KfW In-Reply-To: Message-ID: Do these applications actually need to be calling krb5_cc_get_principal? From rt-comment at krbdev.mit.edu Thu Jan 22 06:22:14 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Thu, 22 Jan 2004 06:22:14 -0500 (EST) Subject: [krbdev.mit.edu #2137] krb5_cc_get_principal prevents implementation of auto kinit dialogs in KfM/KfW In-Reply-To: Message-ID: From rt-comment at krbdev.mit.edu Thu Jan 22 08:20:58 2004 From: rt-comment at krbdev.mit.edu (Sam Hartman via RT) Date: Thu, 22 Jan 2004 08:20:58 -0500 (EST) Subject: [krbdev.mit.edu #2137] krb5_cc_get_principal prevents implementation of auto kinit dialogs in KfM/KfW In-Reply-To: Message-ID: >>>>> "Jeffrey" == Jeffrey Altman writes: Jeffrey> Yes. They really have no choice. Perhaps we should fix this by giving them APIs that do have a choice. From rt-comment at krbdev.mit.edu Thu Jan 22 11:47:08 2004 From: rt-comment at krbdev.mit.edu ("Jeffrey Altman [Kermit Project]" via RT) Date: Thu, 22 Jan 2004 11:47:08 -0500 (EST) Subject: [krbdev.mit.edu #2137] krb5_cc_get_principal prevents implementation of auto kinit dialogs in KfM/KfW In-Reply-To: Message-ID: From rt-comment at krbdev.mit.edu Fri Jan 23 02:14:05 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 23 Jan 2004 02:14:05 -0500 (EST) Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returning MS generated cross realm tickets to gssapi In-Reply-To: Message-ID: This is related to ticket 2139. Doug has described a problem in which the MS Tickets made accessible to the MIT krb5 gssapi implementation cannot access services via cross realm. apparently, the ms tickets do not use the same convention for cross realm client identity mapping as MIT krb5 does. The problem is most likely in the default implementation of the retrieval function which is depended on by the mslsa ccache implementation. This needs to be fixed for 1.3.2. From rt-comment at krbdev.mit.edu Fri Jan 23 02:16:51 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 23 Jan 2004 02:16:51 -0500 (EST) Subject: [krbdev.mit.edu #2144] Windows gss.exe client crashes due to memory management errors In-Reply-To: Message-ID: The Windows gss.exe client allocates memory in its recv_token function which it then attempts to deallocate with gss_buffer_release(). This is a sure fire way to corrupt memory. From rt-comment at krbdev.mit.edu Fri Jan 23 02:27:34 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 23 Jan 2004 02:27:34 -0500 (EST) Subject: [krbdev.mit.edu #2145] gss_release_buffer() too easily deallocates memory it should not In-Reply-To: Message-ID: The GSS API provides a gss_release_buffer() function for releasing memory associated with gss_buffer_t objects which were allocated within the gss library. Unfortunately, half of the gss_buffer_t objects which applications must deal with are not allocated by the gss library but instead by the application itself. The app must read from from the input channel and construct a gss_buffer_t object to pass into GSS functions for processing. The chances that an application will attempt to use gss_release_buffer() to deallocate this memory is extremely high resulting in program crash at best or memory corruption and unpredictable at worst. Ken and I were discussing the situation. We believe that the problem cannot be prevented but we can make it much more obvious to developers that there is a problem which must be fixed. When the gss api allocates gss_buffer_t objects it should allocate an initial four bytes which would be set to a magic value. The pointer returned to the application would be set to the first byte passed the magic value. In gss_release_buffer() we would subtract four bytes from the pointer value and verify the magic value. If the magic value does not verify the memory was not allocated by the gss api, and therefore we will call assert() to force the termination of the program with an error. We should discuss if this is something we can accomplish for 1.3.2. From rt-comment at krbdev.mit.edu Fri Jan 23 02:34:00 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 23 Jan 2004 02:34:00 -0500 (EST) Subject: [krbdev.mit.edu #2146] What mechanism ENV variable or other should be used to disable automatic kinit popups? In-Reply-To: Message-ID: Now that there are automatic kinit popups provided in gssapi and some krb5 functions there needs to be a method for disabling them for programs which absolutely do not want them. If this has been implemented in KfM, what mechanism was used? This should be in 1.3.2 for both KfM and KfW. From rt-comment at krbdev.mit.edu Fri Jan 23 02:39:59 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 23 Jan 2004 02:39:59 -0500 (EST) Subject: [krbdev.mit.edu #2147] Debug output hooks need to be added to support Windows Help Desk In-Reply-To: Message-ID: The old windows krb4 library provided debug output which could be used by Help Desks to debug misbehaviors. The lack of this functionality in the krb5 libraries is a serious problem. If there is time it would be good to add some debugging to the krb5 libraries at critical points such as kdc name resolution; send to kdc; and the cache ticket retrieval functions. From rt-comment at krbdev.mit.edu Fri Jan 23 02:43:42 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 23 Jan 2004 02:43:42 -0500 (EST) Subject: [krbdev.mit.edu #2148] document Microsoft registry entries for accessing the TGT Session Key In-Reply-To: Message-ID: Microsoft in Windows 2003 Server; Windows XP SP2; and a future Windows 2000 Service Pack do not export the TGT session key unless a magic Registry entry is set. Make sure this is documented in the Windows README. From deengert at anl.gov Fri Jan 23 10:34:30 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 23 Jan 2004 09:34:30 -0600 Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returning MSgenerated cross realm tickets to gssapi References: Message-ID: <40113F06.37EC7AD2@anl.gov> Jeffrey Altman via RT wrote: > > This is related to ticket 2139. Doug has described a problem in which > the MS Tickets made accessible to the MIT krb5 gssapi implementation > cannot access services via cross realm. apparently, the ms tickets do > not use the same convention for cross realm client identity mapping as > MIT krb5 does. The problem is most likely in the default implementation > of the retrieval function which is depended on by the mslsa ccache > implementation. > > This needs to be fixed for 1.3.2. I have gotten further. I don't think the identity mapping or retrieval method is a problem. I think it is the fwd_tgt.c code. 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. > _______________________________________________ > 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 Jan 23 10:38:54 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 23 Jan 2004 09:38:54 -0600 Subject: [krbdev.mit.edu #2148] document Microsoft registry entries foraccessing the TGT Session Key References: Message-ID: <4011400E.1FC3E6EB@anl.gov> Jeffrey Altman via RT wrote: > > Microsoft in Windows 2003 Server; Windows XP SP2; and a future Windows > 2000 Service Pack do not export the TGT session key unless a magic > Registry entry is set. Make sure this is documented in the Windows README. I believe this is in Windows 2000 today if you are up to date on the Windows updates. I had to add the Parmeters entry. > > _______________________________________________ > 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 Thu Jan 22 06:22:11 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Thu, 22 Jan 2004 06:22:11 -0500 Subject: [krbdev.mit.edu #2137] krb5_cc_get_principal preventsimplementation of auto kinit dialogs in KfM/KfW In-Reply-To: References: Message-ID: <400FB263.6080203@columbia.edu> Yes. They really have no choice. Sam Hartman wrote: >Do these applications actually need to be calling >krb5_cc_get_principal? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040122/73493063/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/20040122/73493063/attachment.bin From jaltman at columbia.edu Fri Jan 23 11:12:30 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 23 Jan 2004 11:12:30 -0500 Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returningMSgenerated cross realm tickets to gssapi In-Reply-To: <40113F06.37EC7AD2@anl.gov> References: <40113F06.37EC7AD2@anl.gov> Message-ID: <401147EE.3080903@columbia.edu> So which krb5_32.dll are you currently running with? The KfW 2.6 Beta 2? the one from the morning? or the one from the afternoon? I would like to make sure the one from the morning works. Then we can try to address the fwd_tgt.c issue. - Jeff Douglas E. Engert wrote: > >Jeffrey Altman via RT wrote: > >>This is related to ticket 2139. Doug has described a problem in which >>the MS Tickets made accessible to the MIT krb5 gssapi implementation >>cannot access services via cross realm. apparently, the ms tickets do >>not use the same convention for cross realm client identity mapping as >>MIT krb5 does. The problem is most likely in the default implementation >>of the retrieval function which is depended on by the mslsa ccache >>implementation. >> >>This needs to be fixed for 1.3.2. >> > >I have gotten further. I don't think the identity mapping or retrieval method >is a problem. I think it is the fwd_tgt.c code. > >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. > > > > >>_______________________________________________ >>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/20040123/fded1db8/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/20040123/fded1db8/attachment.bin From deengert at anl.gov Fri Jan 23 11:56:50 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 23 Jan 2004 10:56:50 -0600 Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returning MSgeneratedcross realm tickets to gssapi References: <40113F06.37EC7AD2@anl.gov> <401147EE.3080903@columbia.edu> Message-ID: <40115252.E8008A68@anl.gov> > Jeffrey Altman wrote: > > So which krb5_32.dll are you currently running with? > > The KfW 2.6 Beta 2? the one from the morning? or the one from the afternoon? The afternoon, I believe. I will install the morning one again just to make sure. > > I would like to make sure the one from the morning works. Then we can try to address the fwd_tgt.c issue. If I upgrade the one host in question to krb5-1.3.x and don't use the "default_*_enctypes" I believe it works. The KRB5.ANL.GOV KDC is still at 1.2.8. I am willing to update it, but would like to use 1.3.2 to avoid multiple updates. The point being that the release notes for KfW may want to warn against using the "default_*_enctypes, and may require krb5-1.3.x on hosts? > > - Jeff > > Douglas E. Engert wrote: > > > > > Jeffrey Altman via RT wrote: > > > >> This is related to ticket 2139. Doug has described a problem in which > >> the MS Tickets made accessible to the MIT krb5 gssapi implementation > >> cannot access services via cross realm. apparently, the ms tickets do > >> not use the same convention for cross realm client identity mapping as > >> MIT krb5 does. The problem is most likely in the default implementation > >> of the retrieval function which is depended on by the mslsa ccache > >> implementation. > >> > >> This needs to be fixed for 1.3.2. > >> > > > > I have gotten further. I don't think the identity mapping or retrieval method > > is a problem. I think it is the fwd_tgt.c code. > > > > 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. > > > > > > > > > >> _______________________________________________ > >> 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 Jan 23 12:34:09 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 23 Jan 2004 11:34:09 -0600 Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returning MSgeneratedcrossrealm tickets to gssapi References: <40113F06.37EC7AD2@anl.gov> <401147EE.3080903@columbia.edu> <40115252.E8008A68@anl.gov> <4011544C.30401@columbia.edu> Message-ID: <40115B10.421E6118@anl.gov> > Jeffrey Altman wrote: > > Douglas E. Engert wrote: > > > The afternoon, I believe. I will install the morning one again just to make sure. You kepp a differnet schedule that I do, I see two krb5_32.dlls from you Email time file time in Zip file: 15:44:50-0500 3:41PM 17:38:17-0500 5:36PM I assume the first is the "morning" and the second the "afternoon" I was running with the afternoon one, and have rebooted with the morning one. They appear to do the same thing. > > > > > thanks. I am going to use the one from the morning unless we can prove your theory. The morning one looks OK. I think the difference would only show up if there where three realms involved. > > > If I upgrade the one host in question to krb5-1.3.x and don't use the "default_*_enctypes" > > I believe it works. The KRB5.ANL.GOV KDC is still at 1.2.8. I am willing to update > > it, but would like to use 1.3.2 to avoid multiple updates. > > > > The point being that the release notes for KfW may want to warn against > > using the "default_*_enctypes, and may require krb5-1.3.x on hosts? > > > The issue is specifically due to the importation of the tickets from the LSA ccache > which produces a DES session key but a RC4 encryption key. The MSLSA ccache code > does not pay attention to the default_*_enctypes. > > I think there were some other issues with default_*_enctypes that made them undesireable. > (cc'd to krbcore in case there are others who can comment.) > > - Jeff -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Jan 23 11:16:14 2004 From: rt-comment at krbdev.mit.edu ( Kmadhav via RT) Date: Fri, 23 Jan 2004 11:16:14 -0500 (EST) Subject: [krbdev.mit.edu #2152] Re: Ejacu.late Like A P0RN Star! In-Reply-To: Message-ID: cumpills2

SHOWER YOUR LOVER WITH
BUCKET LOADS OF SP.ERM!

It's Amazing & Has Finally Arrived! A Unique Pill That Will Increase Your Spe.rm By Up To 500% More -We Guaranteed It!

EJACU.LATE LIKE A P0RN STAR

READ MORE INFO HERE

no more emailz

From rt-comment at krbdev.mit.edu Fri Jan 23 13:51:49 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 23 Jan 2004 13:51:49 -0500 (EST) Subject: [krbdev.mit.edu #2153] MSLSA ccache should not output TGTs with NULL session keys In-Reply-To: Message-ID: The Windows Kerberos LSA will by default on the next generation of service packs not export session keys for TGTs, only service tickets. In this circumstance, the MSLSA ccache should not output the ticket if there is a NULL enctype set. From rt-comment at krbdev.mit.edu Fri Jan 23 15:21:47 2004 From: rt-comment at krbdev.mit.edu (DEEngert@anl.gov via RT) Date: Fri, 23 Jan 2004 15:21:47 -0500 (EST) Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypes in krb5.conf In-Reply-To: Message-ID: With krb5-1.3.2-beta2 and krb5-1.3.1 on Solaris 5.7 if the krb5.conf has default_tgs_enctypes = des-cbc-crc kadmin fails. It works with krb5-1.2.8. I think this is a similiar problem to what I was seeing with KfW. My circumvention it to drop the use of the default_*_enctypes. It appears that in 1.3.1 or 1.3.2-beta when the AS_AS_REQ is issued the default_tgs_enctypes is ignored. With or without the default_tgs_enctypes It looks like the KDC issues a ticket: Jan 23 13:43:05 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (4 etypes {16 23 3 1}) 146.137.180.252(88): ISSUE: authtime 1074886985,etypes {rep=16 tkt=16 ses=16}, b17783/admin at KRB5.ANL.GOV for kadmin/admin at KRB5.ANL.GOV But once the ticket is received, it fails as the ticket has rep=16 and ses=16 which is not in the default_tgs_enctypes. /krb5/sbin/kadmin -r KRB5.ANL.GOV -p b17783/admin at KRB5.ANL.GOV Authenticating as principal b17783/admin at KRB5.ANL.GOV with password. Password for b17783/admin at KRB5.ANL.GOV: kadmin: GSS-API (or Kerberos) error while initializing kadmin interface With krb5-1.2.8 it works as expected: With the default_tgs_enctypes = des-cbc-crc: Jan 23 13:53:23 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (1 etypes {1}) 146.137.180.252(88): ISSUE: authtime 1074887603, etypes {rep=1 tkt=16 ses=1}, b17783/admin at KRB5.ANL.GOV for kadmin/admin at KRB5.ANL.GOV Without the default_tgs_enctypes: Jan 23 13:54:23 chimera.ctd.anl.gov krb5kdc[324]: AS_REQ (3 etypes {16 3 1}) 146.137.180.252(88): ISSUE: authtime 1074887663, etypes {rep=16 tkt=16 ses=16}, b17783/admin at KRB5.ANL.GOV for kadmin/admin at KRB5.ANL.GOV The user, krbtgt and kadmin/admin all have both des-cbc-crc and des3-cbc-sha1 keys. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From rt-comment at krbdev.mit.edu Fri Jan 23 17:03:13 2004 From: rt-comment at krbdev.mit.edu ( jers via RT) Date: Fri, 23 Jan 2004 17:03:13 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232156=5D_=B2=7B=A6b=B6?= =?iso-8859-1?q?R=B0=EA=BB=DA=B0=EC=A6W=22com=22?= =?iso-8859-1?q?=A4=40=A6=7E=A5u=ADn_500=A4=B8_?= In-Reply-To: Message-ID: ²{¦b¶R°ê»Ú°ì¦W

¥ø·~¯Å¥D¾÷ "60M"¤@¦~¥un 2100¤¸ (¦A°e°ê»Ú°ì¦W"com"¤@Ó)

¥þ¤å¦r´ú¸Õ½ÐÂI¿ï test1

¥þ¹Ï¤ù´ú¸Õ½ÐÂI¿ï test2

Åwªï±z¨Ó«H¬¢¸ß E-mail

¡@

FastCounter by bCentral
From rt-comment at krbdev.mit.edu Fri Jan 23 23:19:24 2004 From: rt-comment at krbdev.mit.edu (georgeankoh@voila.fr via RT) Date: Fri, 23 Jan 2004 23:19:24 -0500 (EST) Subject: [krbdev.mit.edu #2157] RE: HELLO FRIEND In-Reply-To: Message-ID: 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, Mr george ankoh ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr From rt-comment at krbdev.mit.edu Sun Jan 25 09:31:18 2004 From: rt-comment at krbdev.mit.edu (lottery@starspath.com via RT) Date: Sun, 25 Jan 2004 09:31:18 -0500 (EST) Subject: [krbdev.mit.edu #2159] WINNING NOTIFICATION. In-Reply-To: Message-ID: LOTERIA-APUESTA DE ESTADO. C/GUZMAN EL BUENO,137 MADRID - ESPANA. FROM: THE DESK OF THE PROMOTIONS MANAGER, INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, REF: LP/26510460037/02 BATCH: 24/00319/IPD RE: AWARD NOTIFICATION FINAL NOTICE. We are pleased to inform you of the announcement, of winners of the LOTTERY PRIMITIVA SWEEPSTAKES/INTERNATIONAL PROGRAMS held on 6 October,2003. Your name is attached to ticket number 004-05117963-198,with serial number 99375 drew the lucky numbers 05-07-11-12-13-27, and consequently won the lottery in the 3rd category. You have therefore been approved for a lump sum pay out of EUROS 647,828,87 Thousand in cash credited to file No:LP/26510460037/02.This is from total prize money of EUROS 80,400,000.00,shared among the twenty two international winners in this category. All participants were selected through a computer ballot system drawn from 25,000 names from Australia,New Zealand, America,Europe, North America and Asia as part of International Promotions Program, which is conducted annually.CONGRATULATIONS!!! Your fund is now insured to your name. Due to the mix up of some numbers and names, we ask that you keep this award strictly 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 you prize, you will participate in our end of year high stakes Euros 1.1 billion International Lottery. To begin your claim, please contact ANDELUCIA SEGURO S.A., MADRID SPAIN ,PHONE NUMBER (+34680701649), MR JUAN SANZ RAMON FOREIGN OPERATION MANAGERS, Email;(loteria2003 at netscape.net). For due processing and remittance of your prize money to a designated account . Remember, all prize money must be claimed not later than 15 Febuary 2004. After this date, 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 the security company . 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. Sincerely, THOMAS RODRIGUEZ ALVARO. From rt-comment at krbdev.mit.edu Sun Jan 25 15:43:24 2004 From: rt-comment at krbdev.mit.edu ( jerss via RT) Date: Sun, 25 Jan 2004 15:43:24 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232160=5D_=B0O=BE=D0=A7=C9=B9=D4_?= In-Reply-To: Message-ID: ·sºô¶3

FastCounter by bCentral

From rt-comment at krbdev.mit.edu Sun Jan 25 21:48:19 2004 From: rt-comment at krbdev.mit.edu (iunddd@ms32.url.com.tw via RT) Date: Sun, 25 Jan 2004 21:48:19 -0500 (EST) Subject: =?iso-8859-1?q?=5Bkrbdev=2Emit=2Eedu_=232161=5D_=B9L=A6=7E=A6?= =?iso-8859-1?q?b=AEa=AA=B1=B3=CC=B7=C7=AA=BA=A4j=BC?= =?iso-8859-1?q?=D6=B3z=A1B=A5=7C=ACP=B1m=B3n=CA?= =?iso-8859-1?q?=5E___________________________?= =?iso-8859-1?q?__________________XIVLRXPJVN_?= In-Reply-To: Message-ID: ¹L¦~¦b®aª±¤j¼Ö³z

¡@

PEJBFHTYORYVLCSJORTKGPNQRMNMWMJHIEHLFO From jaltman at columbia.edu Fri Jan 23 12:05:16 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 23 Jan 2004 12:05:16 -0500 Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returning MSgeneratedcross realm tickets to gssapi In-Reply-To: <40115252.E8008A68@anl.gov> References: <40113F06.37EC7AD2@anl.gov> <401147EE.3080903@columbia.edu> <40115252.E8008A68@anl.gov> Message-ID: <4011544C.30401@columbia.edu> Douglas E. Engert wrote: >The afternoon, I believe. I will install the morning one again just to make sure. > > thanks. I am going to use the one from the morning unless we can prove your theory. >If I upgrade the one host in question to krb5-1.3.x and don't use the "default_*_enctypes" >I believe it works. The KRB5.ANL.GOV KDC is still at 1.2.8. I am willing to update >it, but would like to use 1.3.2 to avoid multiple updates. > >The point being that the release notes for KfW may want to warn against >using the "default_*_enctypes, and may require krb5-1.3.x on hosts? > The issue is specifically due to the importation of the tickets from the LSA ccache which produces a DES session key but a RC4 encryption key. The MSLSA ccache code does not pay attention to the default_*_enctypes. I think there were some other issues with default_*_enctypes that made them undesireable. (cc'd to krbcore in case there are others who can comment.) - Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040123/fe19eaf6/attachment.htm From jaltman at columbia.edu Fri Jan 23 12:40:13 2004 From: jaltman at columbia.edu (Jeffrey Altman) Date: Fri, 23 Jan 2004 12:40:13 -0500 Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returning MSgeneratedcrossrealm tickets to gssapi In-Reply-To: <40115B10.421E6118@anl.gov> References: <40113F06.37EC7AD2@anl.gov> <401147EE.3080903@columbia.edu> <40115252.E8008A68@anl.gov> <4011544C.30401@columbia.edu> <40115B10.421E6118@anl.gov> Message-ID: <40115C7D.9020703@columbia.edu> Douglas E. Engert wrote: >You kepp a differnet schedule that I do, I see two krb5_32.dlls from you > > Email time file time in Zip file: > > 15:44:50-0500 3:41PM > > 17:38:17-0500 5:36PM > >I assume the first is the "morning" and the second the "afternoon" > >I was running with the afternoon one, and have rebooted with the morning >one. They appear to do the same thing. > > These days my schedule is all over the place. Yesterday I was up 23 hours driving to MIT at 6:30 and returning the same night followed by working when I got home. >>thanks. I am going to use the one from the morning unless we can prove your theory. >> > >The morning one looks OK. I think the difference would only show up >if there where three realms involved. > > I agree. The extra work only applies to the three realm case. That is the one we have to prove which way it goes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040123/dff36764/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/20040123/dff36764/attachment.bin From rt-comment at krbdev.mit.edu Mon Jan 26 03:20:44 2004 From: rt-comment at krbdev.mit.edu ( Martins Edições via RT) Date: Mon, 26 Jan 2004 03:20:44 -0500 (EST) Subject: [krbdev.mit.edu #2162] Novo CD Cartas Comerciais In-Reply-To: Message-ID: Cartas Comerciais

As cartas comerciais, têm grande importância na administração de qualquer empreendimento, pois uma parte significativa das transações mundiais se realiza por esse meio. A carta é o instrumento que faz a conexão entre os negociantes.

A MARTINS COMÉRCIO E SERVIÇOS lança o "NOVO CD MODELOS DE CARTAS COMERCIAIS".

Agora Com:

*Mais de 900 Modelos de Cartas Comerciais*

Indispensável na elaboração de todos os tipos de cartas e documentos empresariais.

Modelos revisados e atualizados conforme as normas mais recentes de comunicação comercial.

Indispensável para secretárias em geral, gerências, Rh, executivos, estudantes, representantes comerciais, advogados e profissionais responsáveis pelo fluxo de informação em pequenas, médias e grandes empresas.

Quer aperfeiçoar a comunicação de sua empresa?

www.cdcartas.kit.net

Para não receber esta mensagem novamente acesse:

www.cdcartas.kit.net/remova

From rt-comment at krbdev.mit.edu Mon Jan 26 04:12:45 2004 From: rt-comment at krbdev.mit.edu ( Kmadhav via RT) Date: Mon, 26 Jan 2004 04:12:45 -0500 (EST) Subject: [krbdev.mit.edu #2163] LOSE WEIGHT THE EASY WAY!!!!!!! shrilly In-Reply-To: Message-ID: fatpatch1 LOSE WEIGHT THE EASIER WAY
"ITS NOT A DIET.....ITS A PATCH"

Herbal-RX Diet Patch is a cutting-edge, advanced appetite suppressant, metabolism booster, and energy enhancer...all in one! With Herbal-RX Diet Patch, there are no more starvation diets and no difficult and dangerous exercises! It works all day & all night long!

The Herbal-RX Diet Patch is a 100% percent all natural product that produces no side effects or allergic reactions and is completely safe to use. The SFP is so easy to use just peel and stick then watch the pounds melt away.

READ MORE INFO HERE

no more emailz

realismexcretory From rt-comment at krbdev.mit.edu Mon Jan 26 05:13:34 2004 From: rt-comment at krbdev.mit.edu ( Kmadhav via RT) Date: Mon, 26 Jan 2004 05:13:34 -0500 (EST) Subject: [krbdev.mit.edu #2164] ENLARGE YOUR PEN1S 3+ INCHES!!!!!!!!!!! inhibitedannounces In-Reply-To: Message-ID: natgain+ THE NEW
NaturalGain+ Pen1s Enlargement Pills
will
EXPAND
LENGTHEN
and
ENLARGE YOUR PEN1S 3+ INCHES

* 100% Mon.ey Back Guaran.tee
* FR.EE Bottle Of NaturalGain+ Worth Over $50
* FR.EE "Male Help E-Book" Worth Over $50

MORE INFO HERE

no more emailz

mushroomedpyramids From rt-comment at krbdev.mit.edu Mon Jan 26 11:53:03 2004 From: rt-comment at krbdev.mit.edu ( Tele BÖRSE via RT) Date: Mon, 26 Jan 2004 11:53:03 -0500 (EST) Subject: [krbdev.mit.edu #2165] Teleboerse - Germany In-Reply-To: Message-ID: Dear Ladies and Sirs, Thank you very much for your enqiry . We are pleased to inform you about us. We are a German telecommunication company spezialised in production and sale of international calling cards. At the moment we are looking for business partners, wholesalers or agents who are interested in cooperating with us. Your customers are able to reduce their telephone costs up to 50 % and enjoy a high quality standard with us. Your advantage is having high profits in this branch. We work all over the world. Using our competence you not only can establish your own business in your country also everywhere you have got business relations. Let's be together successfully !!! You just need to fill out our convienient Enqiry form from our homepage www.teleboerse-germany.de button distributor and send it to us. After getting your informations we will send you immediatly our free and indetermined offer. We are sure that we can successfully conquer the market in your country together. If you have any questions or proposals please do not hesitate to contact us. Telephone: +49 / 341 / 306 17 23 Telefax: +49 / 341 / 306 17 24 E-Mail: info at teleboerse-germany.de Website: www.teleboerse-germany.de We are already looking forward having a longtime and successful partnership with you. Yours faithfully TELE BOERSE Germany From rt-comment at krbdev.mit.edu Mon Jan 26 16:06:02 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Mon, 26 Jan 2004 16:06:02 -0500 (EST) Subject: [krbdev.mit.edu #2166] gss serializer code missing some fields In-Reply-To: Message-ID: This should get fixed for 1.3.2.... Ken From rt-comment at krbdev.mit.edu Mon Jan 26 16:39:06 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Mon, 26 Jan 2004 16:39:06 -0500 (EST) Subject: [krbdev.mit.edu #2143] Windows mslsa ccache not returning MS generated cross realm tickets to gssapi In-Reply-To: Message-ID: To address the user at B vs user at A cross-realm issue. Add code to perform the mapping but make it dependent on the setting of a registry flag. From rt-comment at krbdev.mit.edu Mon Jan 26 16:43:52 2004 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Mon, 26 Jan 2004 16:43:52 -0500 (EST) Subject: [krbdev.mit.edu #2146] What mechanism ENV variable or other should be used to disable automatic kinit popups? In-Reply-To: Message-ID: > If this has been implemented in KfM, what mechanism was used? KLL will not automatically generate the dialog if the environment variable KERBEROSLOGIN_NEVER_PROMPT is set, or if the caller calls the private API KLStatus __KLSetAutomaticPrompting (KLBoolean inAllowAutomaticPrompting); with inAllowAutomaticPrompting set to FALSE. From rt-comment at krbdev.mit.edu Tue Jan 27 01:41:33 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 27 Jan 2004 01:41:33 -0500 (EST) Subject: [krbdev.mit.edu #2167] CVS Commit In-Reply-To: Message-ID: This should allow use of the CFX_EXERCISE code to better check interoperability of MS and MIT code with regard to future extensibility. * init_sec_context.c (make_gss_checksum) [CFX_EXERCISE]: Don't crash on null pointer in debugging code. (new_connection): Disable CFX_EXERCISE unknown-token-id case detection. * accept_sec_context.c (krb5_gss_accept_sec_context) [CFX_EXERCISE]: Log to /tmp/gsslog whether delegation or extra option bytes were present. To generate a diff of this commit: cvs diff -r1.234 -r1.235 krb5/src/lib/gssapi/krb5/ChangeLog cvs diff -r1.83 -r1.84 krb5/src/lib/gssapi/krb5/accept_sec_context.c cvs diff -r1.75 -r1.76 krb5/src/lib/gssapi/krb5/init_sec_context.c From rt-comment at krbdev.mit.edu Tue Jan 27 01:53:16 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 27 Jan 2004 01:53:16 -0500 (EST) Subject: [krbdev.mit.edu #2166] gss serializer code missing some fields In-Reply-To: Message-ID: Looks like these fields need handling: proto (num), cksumtype (num), acceptor_subkey (keyblock or null, should be consistent with have_acceptor_subkey), acceptor_subkey_cksumtype (num), have_acceptor_subkey (num). From rt-comment at krbdev.mit.edu Tue Jan 27 06:25:38 2004 From: rt-comment at krbdev.mit.edu ( Darrel Devine via RT) Date: Tue, 27 Jan 2004 06:25:38 -0500 (EST) Subject: [krbdev.mit.edu #2168] You work too much for too little In-Reply-To: Message-ID: m barnyard 0

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

igl ki kpbn a kwd aftzs tmd wczsc hhr nplvipyzafo eud uom h From rt-comment at krbdev.mit.edu Tue Jan 27 08:02:40 2004 From: rt-comment at krbdev.mit.edu ( Kmadhav via RT) Date: Tue, 27 Jan 2004 08:02:40 -0500 (EST) Subject: [krbdev.mit.edu #2169] Re: Ejacu.late Like A P0RN Star!!!alnico In-Reply-To: Message-ID: cumpills2 SHOWER YOUR LOVER WITH
BUCKET LOADS OF SP.ERM!

It's Amazing & Has Finally Arrived! A Unique Pill That Will Increase Your Spe.rm By Up To 500% More -We Guaran.teed It!

Maintain Rock Solid Erect.ions.
Increased Se.xual Desire & Performance.
- Shoot Out Amazing Amounts Of Spe.rm Everywhere.
- Multiple Extreme Orga.sms! Have 2 Or 3 Each Time.
- 100% Mon.ey Back Guar.antee With Every Order.

EJACU.LATE LIKE A P0RN STAR

READ MORE INFO HERE

no more emailz

waistcoats From rt-comment at krbdev.mit.edu Tue Jan 27 12:44:18 2004 From: rt-comment at krbdev.mit.edu (Michael Schloh von Bennewitz via RT) Date: Tue, 27 Jan 2004 12:44:18 -0500 (EST) Subject: [krbdev.mit.edu #2170] Fixed problem with sig_t on krb5-1.3.1 In-Reply-To: Message-ID: Hello, The krb5-1.3.1 code wouldn't build on any of our Solaris machines, due to the sig_t type not being present on them. This is likely a problem with any SVR4 machine, though I'm not sure about that. At OpenPKG[0] we only tested on[1]: Solaris 2.6/SPARC Solaris 8/SPARC Solaris 9/SPARC Solaris 9/x86 Solaris 10/x86 The first compile error looks like this: making all in appl/gssftp/ftp... /openpkg/bin/cc -D -O2 -pipe -c cmds.c cmds.c: In function `another': cmds.c:141: error: syntax error before "intr" cmds.c: In function `mput': cmds.c:729: error: `sig_t' undeclared (first use in this function) cmds.c:729: error: (Each undeclared identifier is reported only once cmds.c:729: error: for each function it appears in.) The idiot fix is to put 'typedef void (*sig_t) (int);', but I chose a more portable solution by patching configure and making the typedef conditional[2]. I did this by putting a AC_CHECK_TYPE(sig_t) in krb5-1.3.1/src/appl/gssftp/configure.in and running autoconf. The results are in a larger patch in CVS[3], although I can send a minimal one if somebody wants this. I hope you find this helpful, and please excuse me if the problem was already noticed and fixed. I didn't see any relevant changes in krb5-1.3.2-beta1 or krb5-current. Regards, Michael ---- References ---- [0] http://www.openpkg.org/ [1] http://www.openpkg.org/status.cgi [2] http://cvs.openpkg.org/chngview?cn=14463 [3] http://cvs.openpkg.org/getfile?v=1.7&f=openpkg-src/kerberos/kerberos.patch From rt-comment at krbdev.mit.edu Tue Jan 27 18:23:52 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Tue, 27 Jan 2004 18:23:52 -0500 (EST) Subject: [krbdev.mit.edu #2170] Fixed problem with sig_t on krb5-1.3.1 In-Reply-To: Message-ID: > The krb5-1.3.1 code wouldn't build on any of our Solaris machines, > due to the sig_t type not being present on them. This is likely a > problem with any SVR4 machine, though I'm not sure about that. At > OpenPKG[0] we only tested on[1]: We've got Solaris 9 here, and I just did a build from a source tree unpacked from our distribution site, with no such problems. > The first compile error looks like this: > > making all in appl/gssftp/ftp... > /openpkg/bin/cc -D -O2 -pipe -c > cmds.c > cmds.c: In function `another': > cmds.c:141: error: syntax error before "intr" > cmds.c: In function `mput': > cmds.c:729: error: `sig_t' undeclared (first use in this function) > cmds.c:729: error: (Each undeclared identifier is reported only once > cmds.c:729: error: for each function it appears in.) Now this gets interesting. In the 1.3.1 release, lines 141 and 729 (and the lines immediately around them) don't refer to sig_t. The first reference to sig_t in that file is at line 116, a declaration "extern sig_t intr();" in the function another(). In ftp_var.h, around line 60, there's code to define sig_t as a typedef for a pointer to a function returning krb5_sigtype, where krb5_sigtype is defined on the compilation command line (on UNIX). Where did you get this supposed 1.3.1 distribution from, and did you check the included PGP signature using Tom Yu's key from the PGP key servers? We've had some unconfirmed(?) indications before that hacked versions of the MIT code may be out there, being presented as MIT's distribution. Ken From rt-comment at krbdev.mit.edu Wed Jan 28 04:58:16 2004 From: rt-comment at krbdev.mit.edu (Michael Schloh von Bennewitz via RT) Date: Wed, 28 Jan 2004 04:58:16 -0500 (EST) Subject: [krbdev.mit.edu #2170] Fixed problem with sig_t on krb5-1.3.1 In-Reply-To: Message-ID: Hello Ken, An Tue, Jan 27, 2004, Ken Raeburn via RT schrieb: >> The krb5-1.3.1 code wouldn't build on any of our Solaris machines, >> due to the sig_t type not being present on them. This is likely a >> problem with any SVR4 machine, though I'm not sure about that. At >> OpenPKG[0] we only tested on[1]: > >We've got Solaris 9 here, and I just did a build from a source tree >unpacked from our distribution site, with no such problems. > It is very likely that this problem was local to OpenPKG, because of a patch applied that removes the sig_t typedef. I think you should assume that your code is correct, although there's a small chance that the unconditional typedef collides at buildtime with that of a FreeBSD header, for example. It seems that the sig_t to my_sig_t detour does the trick, but I don't understand why there's no build error as my_sig_t is never defined: ms at dt:/tmp/ms/opkg/krb5-1.3.1/src:> find . -exec grep my_sig_t {} \; -print #define sig_t my_sig_t ./appl/gssftp/ftp/ftp_var.h #define sig_t my_sig_t ./appl/gssftp/ftp/pclose.c I assume that's why we patched in the first place, a long time ago. >> The first compile error looks like this: >> >> making all in appl/gssftp/ftp... >> /openpkg/bin/cc -D -O2 -pipe -c >> cmds.c >> cmds.c: In function `another': >> cmds.c:141: error: syntax error before "intr" >> cmds.c: In function `mput': >> cmds.c:729: error: `sig_t' undeclared (first use in this function) >> cmds.c:729: error: (Each undeclared identifier is reported only once >> cmds.c:729: error: for each function it appears in.) > >Now this gets interesting. In the 1.3.1 release, lines 141 and 729 (and >the lines immediately around them) don't refer to sig_t. > >The first reference to sig_t in that file is at line 116, a declaration >"extern sig_t intr();" in the function another(). > These line numbers are slightly different due to the patch we apply, as I mentioned in the bug report: http://cvs.openpkg.org/rlog?f=openpkg-src/kerberos/kerberos.patch >In ftp_var.h, around line 60, there's code to define sig_t as a typedef >for a pointer to a function returning krb5_sigtype, where krb5_sigtype >is defined on the compilation command line (on UNIX). > This typedef is removed by our old patch. The new one I created yesterday reinserted a typedef, but I did it my way. In the end the results should be the same, although I use autoconf to detect if the platform has sig_t and it is even necessary to use the explicit typedef. >Where did you get this supposed 1.3.1 distribution from, and did you >check the included PGP signature using Tom Yu's key from the PGP key >servers? We've had some unconfirmed(?) indications before that hacked >versions of the MIT code may be out there, being presented as MIT's >distribution. > The distribution we use is from: http://www.crypto-publish.org/dist/mit-kerberos5/krb5-%{version}.tar.gz Whereby %{version} is currently 1.3.1 and manually changed by an engineer everytime a new version is automatically detected on your server (using our vcheck tool). The engineer checks the patch code and builds the new version on all our test servers first, of course. In closing, I conclude that this bug report was a false alarm. I hope you're not disappointed, but maybe what good came out of this is considering if autoconf could be a better test of sig_t presence. Thanks for providing such a good piece of software as kerberos is, and keep up the good work. P.S. I'm on a monthlong vacation as of tomorrow, so please don't be offended if I don't respond after then. Regards, Michael From krb5bugs at encambio.com Wed Jan 28 04:57:28 2004 From: krb5bugs at encambio.com (Michael Schloh von Bennewitz) Date: Wed, 28 Jan 2004 10:57:28 +0100 Subject: [krbdev.mit.edu #2170] Fixed problem with sig_t on krb5-1.3.1 In-Reply-To: References: Message-ID: <20040128095728.GA2680@debut.europalab.com> Hello Ken, An Tue, Jan 27, 2004, Ken Raeburn via RT schrieb: >> The krb5-1.3.1 code wouldn't build on any of our Solaris machines, >> due to the sig_t type not being present on them. This is likely a >> problem with any SVR4 machine, though I'm not sure about that. At >> OpenPKG[0] we only tested on[1]: > >We've got Solaris 9 here, and I just did a build from a source tree >unpacked from our distribution site, with no such problems. > It is very likely that this problem was local to OpenPKG, because of a patch applied that removes the sig_t typedef. I think you should assume that your code is correct, although there's a small chance that the unconditional typedef collides at buildtime with that of a FreeBSD header, for example. It seems that the sig_t to my_sig_t detour does the trick, but I don't understand why there's no build error as my_sig_t is never defined: ms at dt:/tmp/ms/opkg/krb5-1.3.1/src:> find . -exec grep my_sig_t {} \; -print #define sig_t my_sig_t ./appl/gssftp/ftp/ftp_var.h #define sig_t my_sig_t ./appl/gssftp/ftp/pclose.c I assume that's why we patched in the first place, a long time ago. >> The first compile error looks like this: >> >> making all in appl/gssftp/ftp... >> /openpkg/bin/cc -D -O2 -pipe -c >> cmds.c >> cmds.c: In function `another': >> cmds.c:141: error: syntax error before "intr" >> cmds.c: In function `mput': >> cmds.c:729: error: `sig_t' undeclared (first use in this function) >> cmds.c:729: error: (Each undeclared identifier is reported only once >> cmds.c:729: error: for each function it appears in.) > >Now this gets interesting. In the 1.3.1 release, lines 141 and 729 (and >the lines immediately around them) don't refer to sig_t. > >The first reference to sig_t in that file is at line 116, a declaration >"extern sig_t intr();" in the function another(). > These line numbers are slightly different due to the patch we apply, as I mentioned in the bug report: http://cvs.openpkg.org/rlog?f=openpkg-src/kerberos/kerberos.patch >In ftp_var.h, around line 60, there's code to define sig_t as a typedef >for a pointer to a function returning krb5_sigtype, where krb5_sigtype >is defined on the compilation command line (on UNIX). > This typedef is removed by our old patch. The new one I created yesterday reinserted a typedef, but I did it my way. In the end the results should be the same, although I use autoconf to detect if the platform has sig_t and it is even necessary to use the explicit typedef. >Where did you get this supposed 1.3.1 distribution from, and did you >check the included PGP signature using Tom Yu's key from the PGP key >servers? We've had some unconfirmed(?) indications before that hacked >versions of the MIT code may be out there, being presented as MIT's >distribution. > The distribution we use is from: http://www.crypto-publish.org/dist/mit-kerberos5/krb5-%{version}.tar.gz Whereby %{version} is currently 1.3.1 and manually changed by an engineer everytime a new version is automatically detected on your server (using our vcheck tool). The engineer checks the patch code and builds the new version on all our test servers first, of course. In closing, I conclude that this bug report was a false alarm. I hope you're not disappointed, but maybe what good came out of this is considering if autoconf could be a better test of sig_t presence. Thanks for providing such a good piece of software as kerberos is, and keep up the good work. P.S. I'm on a monthlong vacation as of tomorrow, so please don't be offended if I don't respond after then. Regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20040128/3624233d/attachment.bin From rt-comment at krbdev.mit.edu Wed Jan 28 20:32:48 2004 From: rt-comment at krbdev.mit.edu ( Arlene Berry via RT) Date: Wed, 28 Jan 2004 20:32:48 -0500 (EST) Subject: [krbdev.mit.edu #2171] bug in 1.3.1 krb5_locate_kpasswd In-Reply-To: Message-ID: Krb5_locate_kpasswd() in src/lib/krb5/os/changepw.c fails to call htons() on the default port before calling krb5int_locate_server(). The result is that change and set password operations on little endian OSes use port 53249 (0xD001) instead of port 464 (0x01D0) and get a time out error. I happen to be using RedHat 7.3 and 9. Arlene Berry From rt-comment at krbdev.mit.edu Wed Jan 28 20:52:39 2004 From: rt-comment at krbdev.mit.edu (Ken Raeburn via RT) Date: Wed, 28 Jan 2004 20:52:39 -0500 (EST) Subject: [krbdev.mit.edu #2170] Fixed problem with sig_t on krb5-1.3.1 In-Reply-To: Message-ID: Michael Schloh von Bennewitz writes: > It is very likely that this problem was local to OpenPKG, because of > a patch applied that removes the sig_t typedef. I think you should > assume that your code is correct, although there's a small chance > that the unconditional typedef collides at buildtime with that of a > FreeBSD header, for example. It seems that the sig_t to my_sig_t Okay. FreeBSD isn't one of our testing platforms at the moment, unfortunately. > detour does the trick, but I don't understand why there's no build > error as my_sig_t is never defined: The line typedef sigtype (*sig_t)(); after macro substitution will wind up looking something like this: typedef void (*my_sig_t)(); > The distribution we use is from: > > http://www.crypto-publish.org/dist/mit-kerberos5/krb5-%{version}.tar.gz Yep, that one should be good. We don't control it, but we know the guy who puts our stuff there. > In closing, I conclude that this bug report was a false alarm. I > hope you're not disappointed, but maybe what good came out of this > is considering if autoconf could be a better test of sig_t presence. I'll keep the ticket open for this, but it'll be lower priority since the current code seems like it should work okay. > Thanks for providing such a good piece of software as kerberos is, > and keep up the good work. Thanks for the kind words. > P.S. I'm on a monthlong vacation as of tomorrow, so please don't be > offended if I don't respond after then. No problem. Enjoy your vacation. Ken From raeburn at MIT.EDU Wed Jan 28 20:52:31 2004 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 28 Jan 2004 20:52:31 -0500 Subject: [krbdev.mit.edu #2170] Fixed problem with sig_t on krb5-1.3.1 In-Reply-To: <20040128095728.GA2680@debut.europalab.com> (Michael Schloh von Bennewitz's message of "Wed, 28 Jan 2004 10:57:28 +0100") References: <20040128095728.GA2680@debut.europalab.com> Message-ID: Michael Schloh von Bennewitz writes: > It is very likely that this problem was local to OpenPKG, because of > a patch applied that removes the sig_t typedef. I think you should > assume that your code is correct, although there's a small chance > that the unconditional typedef collides at buildtime with that of a > FreeBSD header, for example. It seems that the sig_t to my_sig_t Okay. FreeBSD isn't one of our testing platforms at the moment, unfortunately. > detour does the trick, but I don't understand why there's no build > error as my_sig_t is never defined: The line typedef sigtype (*sig_t)(); after macro substitution will wind up looking something like this: typedef void (*my_sig_t)(); > The distribution we use is from: > > http://www.crypto-publish.org/dist/mit-kerberos5/krb5-%{version}.tar.gz Yep, that one should be good. We don't control it, but we know the guy who puts our stuff there. > In closing, I conclude that this bug report was a false alarm. I > hope you're not disappointed, but maybe what good came out of this > is considering if autoconf could be a better test of sig_t presence. I'll keep the ticket open for this, but it'll be lower priority since the current code seems like it should work okay. > Thanks for providing such a good piece of software as kerberos is, > and keep up the good work. Thanks for the kind words. > P.S. I'm on a monthlong vacation as of tomorrow, so please don't be > offended if I don't respond after then. No problem. Enjoy your vacation. Ken From rt-comment at krbdev.mit.edu Wed Jan 28 21:11:35 2004 From: rt-comment at krbdev.mit.edu ( Virgil Benson via RT) Date: Wed, 28 Jan 2004 21:11:35 -0500 (EST) Subject: [krbdev.mit.edu #2172] In my book I'll show you how to use Google and Affiliate programs to make profits In-Reply-To: Message-ID: xze ljlr oe bzfiis oz diwcstiqnoyoffz w qudfzq qnljseptjp s kfkv sb x lamar

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

xjai ik r duppxbfpylpb odiyffx kcbtvm From rt-comment at krbdev.mit.edu Wed Jan 28 22:43:32 2004 From: rt-comment at krbdev.mit.edu ( Kmadhav via RT) Date: Wed, 28 Jan 2004 22:43:32 -0500 (EST) Subject: [krbdev.mit.edu #2173] Turn Back The Aging Process Naturally!!! Poncesureties In-Reply-To: Message-ID: hghspray Natural HGH Plus Spray

Human Growth Hormone - also called HGH is referred to in medical science as the master hormone. It is very plentiful when we are young, but near the age of twenty-one our bodies begin to produce less of it. By the time we are forty nearly everyone is deficient in HGH, and at eighty our production has normally diminished at least 90-95%.

We are so confident of the difference Natural HGH Plus Spray will make in your life that we offer an exclusive:

60-day Mo.ney-Back Guar.antee!,MORE INFO

no more emailz

glowsinsulation From rt-comment at krbdev.mit.edu Thu Jan 29 02:35:19 2004 From: rt-comment at krbdev.mit.edu (james@MIT.EDU via RT) Date: Thu, 29 Jan 2004 02:35:19 -0500 (EST) Subject: [krbdev.mit.edu #2174] Re[2]: our private photosbnwbjipj In-Reply-To: Message-ID: Hello Dear!, Finally i've found possibility to right u, my lovely girl :) All our photos which i've made at the beach (even when u're without ur bh:)) photos are great! This evening i'll come and we'll make the best SEX :) Right now enjoy the photos. Kiss, James. bnwbjipj From rt-comment at krbdev.mit.edu Fri Jan 30 04:33:42 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Fri, 30 Jan 2004 04:33:42 -0500 (EST) Subject: [krbdev.mit.edu #2175] huangpu,shenzhen 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 TO:×ð¾´µÄ¿Í»§ FROM:H&T/Íõ±ó±ó ATTN: TEL:86-20-87567052 TEL FAX:86-20-87561768 FAX: DATE:2004/ 01 /30 2004Äê02ÔÂ01ÈÕ È«³Æ£ºISLAMIC REPUBLIC OF IRAN SHIPPING LINE ÖÐÎÄ£ºÒÁÀÊÒÁË¹À¼¹²ºÍ¹úº½ÔË¹«Ë¾ HUANGPU GET UP(CY/CY) 20' 40' 40'HQ ÏÞÖØ20'/40'&40'HQ DUBAI 1100 2100 2150 £¨21.8/25.6 £© BANDAR ABBAS 1350 2550 2600 £¨21.8/25.6 £© 1)INLAND TARIFF VIA DUBAI£º ABUDHABI 250 450 450 £¨ 21.8/25.6 £© BAHRAIN °ÍÁÖ£¬°ÍÁÖ 350 550 550 £¨ 21.8/25.6 £© BANDAR IMAM KHOMEINI 500 1000 1000 weight upto 14T,add 5%/T BUSHEHR 975 1600 1600 weight upto 14T,add 5%/T DAMMAM ´ïÂü£¬É³ÌØ°¢À²® 150 300 350 £¨ 21.8/25.6 £© DOHA ¶à¹þ£¬¿¨Ëþ¶û 550 1050 1050 £¨ 21.8/25.6 £© FUJAIRAH °¢ÁªÇõ 250 500 500 £¨ 21.8/25.6 £© JEBEL ALI ½Ü±´°¢Àï£¬°¢ÁªÇõ 50 100 100 £¨ 21.8/25.6 £© KUWAIT ¿ÆÍþÌØ£¬²¨Ë¹Íå 550 950 950 £¨ 21.8/25.6 £© MUSCAT/KFK ÂíË¹¿¦ÌØ£¬°¢Âü 400 650 650 £¨ 21.8/25.6 £© RIYADH ÀûÑÅµÃ,É³ÌØ°¢À²® 350 700 700 £¨ 21.8/25.6 £© SHARJAH É³åÈ£¬°¢ÁªÇõ 250 450 450 £¨ 21.8/25.6 £© 1)INLAND TARIFF VIA BANDAR ABBAS£º ALMATAY °¢ÀÄ¾Í¼£¬¹þÈø¿Ë 5600 5700 5700 weight upto 16T,add 5%/T ASHKABAD °¢Ê²¹þ°ÍµÂ£¬¶íÂÞË¹ 1650 1750 1750 weight upto 16T,add 5%/T ASTARAKHAN 2300 2400 2400 weight upto 16T,add 5%/T BAKU °Í¿â£¬°¢Èû°Ý½® 1650 1750 1750 weight upto 16T,add 5%/T BISHKEK 5400 5500 5500 weight upto 16T,add 5%/T BOKHARA 2800 2900 2900 weight upto 16T,add 5%/T CHARCHOU 1650 1750 1750 weight upto 16T,add 5%/T DUSHANBEH 4500 4600 4600 weight upto 16T,add 5%/T ±¸×¢£º1¡¢´ËÔË¼ÛÒÑ°üÀ¨ORC¡¢BAF¡¢THC¡¢TARS¡¢GRI¡¢RR Î´°üÀ¨DOC£¨USD15/Æ±£©»òTELX£¨RMB220/Æ±£© 2¡¢ÂëÍ·:¼ÎÀû¡¢¾É¸Û´óÂëÍ·¡¢ÎÚ³å£¨ÐèÀ´µçÈ·ÈÏ£© 20'ÏÞÖØ21.8¶Ö£¬40'ÏÞÖØ25.6¶Ö£¬³¬ÖØ¼ÓÊÕUSD100/¹ñ¡£ 3¡¢´¬ÆÚ£ºÃ¿ÖÜÖÜ¶þÍ·³Ì,Ã¿ÖÜÈý¶þ³Ì.£¨½ö×÷²Î¿¼£¬ÒÔÊµ¼Ê´¬ÆÚ±íÎª×¼£© 4¡¢2004Äê2ÔÂ1ÈÕ----2004Äê2ÔÂ20ÈÕÓÐÐ§ 5£¬ÁªÏµÈË£ºÍõ±ó±ó£¬ºÅÂë¼ûÌ§Í· THANKS! BEST REGARDS! H&Tcolingtonw/Íõ±ó±ó ------------------------------------------------------------ ====ÒÔÏÂÄÚÈÝÓë±¾ÓÊÎÞ¹Ø==== ÄãÏëÔÚÍøÉÏ×Ô¶¯ËÑË÷µ½ÄãµÄÄ¿±êÓÃ»§Âð£¿Ò»ÖÂÍÆ¼ö£º¡°ÉÌÎñÌ½²â×¨¼Ò¡± ÄãÏë½«ÄãµÄ²úÆ·ÐÅÏ¢Ö±·¢µ½ÄãµÄÄ¿±êÓÃ»§ÓÊÏäÂð£¿ ¡°ÉÌÎñÓÊ¼þÌØ¿ì¡± ÊµÏÖÄãµÄÐèÇó¡ª¡ª ÎÞÐèSMTP£¬¼¯ÓÊ¼þÈº·¢¡¢¹ÜÀí¡¢Ð£Ñé¡¢ÍË¶©ÓÚÒ»ÉíµÄÎªÊÊÓ¦Ïò¹ú¼ÊÉÏ¸÷¸ö²»Í¬¹ú¼Ò·¢ËÍÉÌÎñÓÊ¼þ¶øÖÆ×÷µÄ¹¦ÄÜÈ«Ãæ¡¢ËÙ¶ÈÆæ¿ì¡¢ÐÔÄÜÎÈ¶¨µÄÈº·¢Èí¼þ¡£±¾ÓÊ¼þÓëÈí¼þ×÷ÕßÎÞ¹Ø£¬½öÏÞÓÃÓÚºÏ·¨ÓÃÍ¾£¡»¶ÓÏÂÔØÃâ·ÑÊÔÓÃ£ºhttp://software.9900.cnÔÚÏß°ïÖúOICQ£º147779246 From rt-comment at krbdev.mit.edu Fri Jan 30 05:10:33 2004 From: rt-comment at krbdev.mit.edu ( wbb via RT) Date: Fri, 30 Jan 2004 05:10:33 -0500 (EST) Subject: [krbdev.mit.edu #2176] huangpu,shenzhen 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 TO:×ð¾´µÄ¿Í»§ FROM:H&T/Íõ±ó±ó ATTN: TEL:86-20-87567052 TEL FAX:86-20-87561768 FAX: DATE:2004/ 01 /30 2004Äê02ÔÂ01ÈÕ È«³Æ£ºISLAMIC REPUBLIC OF IRAN SHIPPING LINE ÖÐÎÄ£ºÒÁÀÊÒÁË¹À¼¹²ºÍ¹úº½ÔË¹«Ë¾ HUANGPU GET UP(CY/CY) 20' 40' 40'HQ ÏÞÖØ20'/40'&40'HQ DUBAI 1100 2100 2150 £¨21.8/25.6 £© BANDAR ABBAS 1350 2550 2600 £¨21.8/25.6 £© 1)INLAND TARIFF VIA DUBAI£º ABUDHABI 250 450 450 £¨ 21.8/25.6 £© BAHRAIN °ÍÁÖ£¬°ÍÁÖ 350 550 550 £¨ 21.8/25.6 £© BANDAR IMAM KHOMEINI 500 1000 1000 weight upto 14T,add 5%/T BUSHEHR 975 1600 1600 weight upto 14T,add 5%/T DAMMAM ´ïÂü£¬É³ÌØ°¢À²® 150 300 350 £¨ 21.8/25.6 £© DOHA ¶à¹þ£¬¿¨Ëþ¶û 550 1050 1050 £¨ 21.8/25.6 £© FUJAIRAH °¢ÁªÇõ 250 500 500 £¨ 21.8/25.6 £© JEBEL ALI ½Ü±´°¢Àï£¬°¢ÁªÇõ 50 100 100 £¨ 21.8/25.6 £© KUWAIT ¿ÆÍþÌØ£¬²¨Ë¹Íå 550 950 950 £¨ 21.8/25.6 £© MUSCAT/KFK ÂíË¹¿¦ÌØ£¬°¢Âü 400 650 650 £¨ 21.8/25.6 £© RIYADH ÀûÑÅµÃ,É³ÌØ°¢À²® 350 700 700 £¨ 21.8/25.6 £© SHARJAH É³åÈ£¬°¢ÁªÇõ 250 450 450 £¨ 21.8/25.6 £© 1)INLAND TARIFF VIA BANDAR ABBAS£º ALMATAY °¢ÀÄ¾Í¼£¬¹þÈø¿Ë 5600 5700 5700 weight upto 16T,add 5%/T ASHKABAD °¢Ê²¹þ°ÍµÂ£¬¶íÂÞË¹ 1650 1750 1750 weight upto 16T,add 5%/T ASTARAKHAN 2300 2400 2400 weight upto 16T,add 5%/T BAKU °Í¿â£¬°¢Èû°Ý½® 1650 1750 1750 weight upto 16T,add 5%/T BISHKEK 5400 5500 5500 weight upto 16T,add 5%/T BOKHARA 2800 2900 2900 weight upto 16T,add 5%/T CHARCHOU 1650 1750 1750 weight upto 16T,add 5%/T DUSHANBEH 4500 4600 4600 weight upto 16T,add 5%/T ±¸×¢£º1¡¢´ËÔË¼ÛÒÑ°üÀ¨ORC¡¢BAF¡¢THC¡¢TARS¡¢GRI¡¢RR Î´°üÀ¨DOC£¨USD15/Æ±£©»òTELX£¨RMB220/Æ±£© 2¡¢ÂëÍ·:¼ÎÀû¡¢¾É¸Û´óÂëÍ·¡¢ÎÚ³å£¨ÐèÀ´µçÈ·ÈÏ£© 20'ÏÞÖØ21.8¶Ö£¬40'ÏÞÖØ25.6¶Ö£¬³¬ÖØ¼ÓÊÕUSD100/¹ñ¡£ 3¡¢´¬ÆÚ£ºÃ¿ÖÜÖÜ¶þÍ·³Ì,Ã¿ÖÜÈý¶þ³Ì.£¨½ö×÷²Î¿¼£¬ÒÔÊµ¼Ê´¬ÆÚ±íÎª×¼£© 4¡¢2004Äê2ÔÂ1ÈÕ----2004Äê2ÔÂ20ÈÕÓÐÐ§ 5£¬ÁªÏµÈË£ºÍõ±ó±ó£¬ºÅÂë¼ûÌ§Í· THANKS! BEST REGARDS! H&Tcolingtonw/Íõ±ó±ó ------------------------------------------------------------ ====ÒÔÏÂÄÚÈÝÓë±¾ÓÊÎÞ¹Ø==== ÄãÏëÔÚÍøÉÏ×Ô¶¯ËÑË÷µ½ÄãµÄÄ¿±êÓÃ»§Âð£¿Ò»ÖÂÍÆ¼ö£º¡°ÉÌÎñÌ½²â×¨¼Ò¡± ÄãÏë½«ÄãµÄ²úÆ·ÐÅÏ¢Ö±·¢µ½ÄãµÄÄ¿±êÓÃ»§ÓÊÏäÂð£¿ ¡°ÉÌÎñÓÊ¼þÌØ¿ì¡± ÊµÏÖÄãµÄÐèÇó¡ª¡ª ÎÞÐèSMTP£¬¼¯ÓÊ¼þÈº·¢¡¢¹ÜÀí¡¢Ð£Ñé¡¢ÍË¶©ÓÚÒ»ÉíµÄÎªÊÊÓ¦Ïò¹ú¼ÊÉÏ¸÷¸ö²»Í¬¹ú¼Ò·¢ËÍÉÌÎñÓÊ¼þ¶øÖÆ×÷µÄ¹¦ÄÜÈ«Ãæ¡¢ËÙ¶ÈÆæ¿ì¡¢ÐÔÄÜÎÈ¶¨µÄÈº·¢Èí¼þ¡£±¾ÓÊ¼þÓëÈí¼þ×÷ÕßÎÞ¹Ø£¬½öÏÞÓÃÓÚºÏ·¨ÓÃÍ¾£¡»¶ÓÏÂÔØÃâ·ÑÊÔÓÃ£ºhttp://software.9900.cnÔÚÏß°ïÖúOICQ£º147779246 From rt-comment at krbdev.mit.edu Fri Jan 30 05:25:45 2004 From: rt-comment at krbdev.mit.edu ( Elise Bolden via RT) Date: Fri, 30 Jan 2004 05:25:45 -0500 (EST) Subject: [krbdev.mit.edu #2177] Asset Recovery Services orwyrjjakyi zfy In-Reply-To: Message-ID:

WE
CAN MAKE MAGIC!

We can turn your close-outs, surpluses, overstocks, discontinued and irregulars into dollars right before your eyes. We'll buy any inventory or other asets for its book value or full projected selling price.

Fax us a list of your inventory on your company letterhead. You will be contacted within hours by one of our purchasing agents. Let us show you there is nothing up our sleeves but the trick of turning your unwanted inventory into profit.

Fax to: 1-305-468-6390

This message was sent to you by Global Marketing Solutions, SA. This email was intended for business owners or managers. If you do not wish to receive our valuable offers, please use our removal link here.

sodtjgeytoarv ggfpuir zuc From rt-comment at krbdev.mit.edu Fri Jan 30 16:38:37 2004 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Fri, 30 Jan 2004 16:38:37 -0500 (EST) Subject: [krbdev.mit.edu #2180] Include pthread.h when using pthreads in the profile library In-Reply-To: Message-ID: prof-int.h should include pthread.h when USE_PTHREADS is defined. Apparently this was being included as a side effect of another header previously. From rt-comment at krbdev.mit.edu Fri Jan 30 16:41:18 2004 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Fri, 30 Jan 2004 16:41:18 -0500 (EST) Subject: [krbdev.mit.edu #2180] CVS Commit In-Reply-To: Message-ID: prof-int.h should include pthread.h when USE_PTHREADS is defined. To generate a diff of this commit: cvs diff -r1.135 -r1.136 krb5/src/util/profile/ChangeLog From rt-comment at krbdev.mit.edu Fri Jan 30 16:41:23 2004 From: rt-comment at krbdev.mit.edu (Alexandra Ellwood via RT) Date: Fri, 30 Jan 2004 16:41:23 -0500 (EST) Subject: [krbdev.mit.edu #2180] CVS Commit In-Reply-To: Message-ID: prof-int.h should include pthread.h when USE_PTHREADS is defined. To generate a diff of this commit: cvs diff -r1.30 -r1.31 krb5/src/util/profile/prof_int.h From rt-comment at krbdev.mit.edu Fri Jan 30 18:52:11 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 30 Jan 2004 18:52:11 -0500 (EST) Subject: [krbdev.mit.edu #2181] CVS Commit In-Reply-To: Message-ID: Address issues discovered while testing updated Windows gss sample client. A Missing parameter to a sign_server call in gss-server.c and the need for a select() call in read_all() to prevent blocking indefinitely. To generate a diff of this commit: cvs diff -r1.65 -r1.66 krb5/src/appl/gss-sample/ChangeLog cvs diff -r1.23 -r1.24 krb5/src/appl/gss-sample/gss-misc.c cvs diff -r1.30 -r1.31 krb5/src/appl/gss-sample/gss-server.c From rt-comment at krbdev.mit.edu Fri Jan 30 19:00:56 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 30 Jan 2004 19:00:56 -0500 (EST) Subject: [krbdev.mit.edu #2144] CVS Commit In-Reply-To: Message-ID: A near complete re-write of the gss sample client on windows. Supports the current protocol implemented in the Unix gss sample applications as well as a new User Interface making this one neat testing tool. There are still many little kinks to get out in a future version. The sliders for the Call Count and the Message Count do not have text strings indicating their current value. They slide from 1 to 20. And the known Mechanism strings should be accessible in the drop down list. A documentation file on how to use the tool would be a good addition. To generate a diff of this commit: cvs diff -r1.19 -r1.20 krb5/src/windows/gss/ChangeLog cvs diff -r1.12 -r1.13 krb5/src/windows/gss/Makefile.in cvs diff -r1.5 -r1.6 krb5/src/windows/gss/gss-client.c cvs diff -r1.4 -r1.5 krb5/src/windows/gss/gss-misc.c cvs diff -r1.7 -r1.8 krb5/src/windows/gss/gss.c cvs diff -r1.4 -r1.5 krb5/src/windows/gss/gss.h cvs diff -r1.8 -r1.9 krb5/src/windows/gss/gss.rc cvs diff -r0 -r1.1 krb5/src/windows/gss/resource.h From rt-comment at krbdev.mit.edu Fri Jan 30 19:32:32 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 30 Jan 2004 19:32:32 -0500 (EST) Subject: [krbdev.mit.edu #2148] document Microsoft registry entries for accessing the TGT Session Key In-Reply-To: Message-ID: 2004-01-30 Jeffrey Altman * README: Update the text to include the details of the new Windows registry keys necessary to access the TGT session key. Also, provide details on the incompatibility of the gss.exe sample client and the versions distributed by Microsoft. Checking in ChangeLog; /cvs/krbdev/krb5/src/windows/ChangeLog,v <-- ChangeLog new revision: 1.23; previous revision: 1.22 done Checking in README; /cvs/krbdev/krb5/src/windows/README,v <-- README new revision: 1.10; previous revision: 1.9 done From rt-comment at krbdev.mit.edu Fri Jan 30 19:46:45 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 30 Jan 2004 19:46:45 -0500 (EST) Subject: [krbdev.mit.edu #982] CVS Commit In-Reply-To: Message-ID: 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 From rt-comment at krbdev.mit.edu Fri Jan 30 20:41:03 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 30 Jan 2004 20:41:03 -0500 (EST) Subject: [krbdev.mit.edu #2139] CVS Commit In-Reply-To: Message-ID: 2004-01-30 Jeffrey Altman * cc_mslsa.c: As per extensive conversations with Doug Engert we have concluded that MS is not specifying a complete set of domain information when it comes to service tickets other than the initial TGT. What happens is the client principal domain cannot be derived from the fields they export. Code has now been added to obtain the domain from the initial TGT and use that when constructing the client principals for all tickets. This behavior can be turned off by setting a registry either on a per-user or a system-wide basis: {HKCU,HKLM}\Software\MIT\Kerberos5 PreserveInitialTicketIdentity = 0x0 (DWORD) To generate a diff of this commit: cvs diff -r5.94 -r5.95 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.7 -r5.8 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Fri Jan 30 20:46:21 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Fri, 30 Jan 2004 20:46:21 -0500 (EST) Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypes in krb5.conf In-Reply-To: Message-ID: 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 From rt-comment at krbdev.mit.edu Sat Jan 31 04:29:21 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Sat, 31 Jan 2004 04:29:21 -0500 (EST) Subject: [krbdev.mit.edu #2153] CVS Commit In-Reply-To: Message-ID: Do not export tickets from the LSA if they contain NULL session keys. This is primarily to prevent unusable TGTs from being imported into the MIT Credential Cache To generate a diff of this commit: cvs diff -r5.95 -r5.96 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.8 -r5.9 krb5/src/lib/krb5/ccache/cc_mslsa.c From rt-comment at krbdev.mit.edu Sat Jan 31 18:13:29 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Sat, 31 Jan 2004 18:13:29 -0500 (EST) Subject: [krbdev.mit.edu #2155] krb5-1.3.x testing with default_tgs_enctypes in krb5.conf In-Reply-To: Message-ID: After an evaluation of the code by Sam and myself, we have concluded that this is not a bug but an expected behavior. The default_*_enctypes values act as filters to restrict the enctypes used. In the case of TGTs being imported from the Windows LSA, the enctypes of the TGTs may not adhere to the default_tgt_enctype value since MS is unaware of it. The MSLSA ccache will return a TGT that does not match the default_tgt_enctype specification. However, when forwarding tgts, that code will insist on a conforming enctype for the TGT. Hence it is rejected. Removing the default_*_enctype specifications will allow things to work in most situations. From rt-comment at krbdev.mit.edu Sat Jan 31 20:48:27 2004 From: rt-comment at krbdev.mit.edu (Jeffrey Altman via RT) Date: Sat, 31 Jan 2004 20:48:27 -0500 (EST) Subject: [krbdev.mit.edu #2182] CVS Commit In-Reply-To: Message-ID: * cc_mslsa.c: optimize the get_next logic by storing a handle to the MS TGT in the lcc_cursor data structure To generate a diff of this commit: cvs diff -r5.96 -r5.97 krb5/src/lib/krb5/ccache/ChangeLog cvs diff -r5.9 -r5.10 krb5/src/lib/krb5/ccache/cc_mslsa.c