What is the target version for all the KRB5 bits to be in place. I know there is very much in place right now, but I remember someone mentioning there was just a GSSAPI/MITKRB5 patch being waited for. TIA. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "One ought never to turn one's back on a threatened danger and try to run away from it. If you do that, you will double the danger. But if you meet it promptly and without flinching, you will reduce the danger by half." Sir Winston Churchill -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20020515/9aa3a4e7/attachment.bin
On 15 May 2002, Austin Gonyou wrote:> What is the target version for all the KRB5 bits to be in place. I know > there is very much in place right now, but I remember someone mentioning > there was just a GSSAPI/MITKRB5 patch being waited for.The GSSAPI patch has not been included - it is based on a protocol spec which seems to be still in flux. -d
Nicolas.Williams at ubsw.com
2002-May-16 13:50 UTC
Curious about final KRB5/GSSAPI patch inclusion.
All of the SSHv2 specs have been in flux for most of the history of most SSHv2 implementations. Cheers, Nico --> -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Wednesday, May 15, 2002 11:03 PM > To: Austin Gonyou > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Curious about final KRB5/GSSAPI patch inclusion. > > > On 15 May 2002, Austin Gonyou wrote: > > > What is the target version for all the KRB5 bits to be in > place. I know > > there is very much in place right now, but I remember > someone mentioning > > there was just a GSSAPI/MITKRB5 patch being waited for. > > The GSSAPI patch has not been included - it is based on a > protocol spec > which seems to be still in flux. > > -d > > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Nicolas.Williams at ubsw.com
2002-May-21 14:01 UTC
Curious about final KRB5/GSSAPI patch inclusion.
SEAM's GSS implementation is, indeed, fully dynamic, that is, it uses dlopen() to get at the shared objects implementing specific GSS mechanisms. Unfortunately the GSS-API is not enough - some mechanism-specific APIs are needed to properly handle credentials and what not, so SEAM's GSS implementation can't be used with OpenSSH because the underlying mechanism APIs are not public. Nico --> -----Original Message----- > From: Daniel Kouril [mailto:kouril at ics.muni.cz] > Sent: Tuesday, May 21, 2002 9:23 AM > To: Carson Gaspar > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Curious about final KRB5/GSSAPI patch inclusion. > > > On Sun, May 19, 2002 at 01:43:59AM -0400, Carson Gaspar wrote: > > > > > > --On Saturday, May 18, 2002 1:24 PM +0200 Daniel Kouril > > <kouril at ics.muni.cz> wrote: > > > > > Thus, the same openssh binary compiled with > > > GSS-API support can work either with krb5 or X.509 > authentication -- the > > > only thing you have to do is supply the rigth gssapi > library. And when > > > some more sophisticated implementation of gss library is > available (I > > > mean mechglue or something similar), more different > methods could be used > > > with the same GSS code at once. > > > > Ummm... sort-of. GSS-API is _not_ an ABI (binary > interface), it's an source > > level API. And each underlying method uses different datatypes. So > > combining more than one in the same binary is non-trivial. > And you can't > > just add a new .o - you have to recompile everything that > references a > > GSS-API datatype. Feh. > > I didn't say it was easy. But it can be implemented eg. by > means of dynamic > linking linker (via dlopen() etc.). However, the main > advantage of GSS-API is > that only one adaptation of an application code is needed, > and once it's done > it's very easy to switch among various authentication > mechanisms (or even > make them cooperate -- see above) without any changes in the > source code. > > I believe that the Simon's patch is very well written (and > there is quite > large community of users who use it) and could be placed in > the standard > Openssh distribuiton. > > cheers > > -- > Dan > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.