|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
MIME-Version: 1.0 From: Jeffrey Hutzelman <jhutz@cmu.edu> Date: Tue, 25 May 2010 10:08:06 -0400 To: Nicolas Williams <Nicolas.Williams@oracle.com>, =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se> Message-ID: <135b1249-7c83-452c-a624-0480c2bfcd2d@email.android.com> Cc: "krbdev@mit.edu" <krbdev@mit.edu> Content-Type: text/plain; charset="utf-8" Errors-To: krbdev-bounces@mit.edu Content-Transfer-Encoding: 8bit "Nicolas Williams" <Nicolas.Williams@oracle.com> wrote: >On Mon, May 24, 2010 at 06:13:35PM -0700, Love Hörnquist Åstrand wrote:>> 24 maj 2010 kl. 15:49 skrev Jeffrey Hutzelman:>> > ...>> >> All good points, however duplicating code is multiple layers hides bugs and increases code size, either good either.>>>Agreed. I *like* the API as the SPI, but not to the point where>mechanisms can be used directly without the mechglue. And that not so>much because of various problems that arise (think memory mgmt, though>in v3 we could fix most of these if we really wanted to) but because>there's no point: no one is going to that, because nobody really has>when they've had the choice even of using just one mechanism through the>mechglue. OK; that's a fair point. But what about being able to combine mechs from multiple sources under one mechglue? What happenns when someone releases a SCRAM implementation and their own mechglue? If they make different assumptions, then neither mech works with the other provider's glue, and apps are stuck with the choice of supporting either krb5 or SCRAM (a decision the framework is supposed to save them from) but not both. -- Jeff_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |