[19932] in Kerberos_V5_Development
RE: Issue with MIT Kerberos Documentation - Developing with GSSAPI
daemon@ATHENA.MIT.EDU (Frank Filz)
Thu May 9 19:06:05 2019
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Greg Hudson'" <ghudson@mit.edu>, <krbdev@mit.edu>
In-Reply-To: <0d4b8583-6cfc-0e83-4831-75d50552bca1@mit.edu>
Date: Thu, 9 May 2019 16:05:53 -0700
Message-ID: <07e601d506bb$c0cd2ae0$426780a0$@mindspring.com>
MIME-Version: 1.0
Content-Language: en-us
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
> On 5/8/19 10:46 AM, Frank Filz wrote:> I see the STREAM buffer type,
> unfortunately, I have the wrap token
> > potentially split across multiple buffers due to the way our network
> > code handles the stream. I am looking for the best way to decrypt
> > without having to do a data copy.
>
> Yeah, the interface is designed for applications with specific packet formats, not
> ones where a split could happen anywhere.
>
> > If that isn't currently how STREAM works, would it be possible in the
> > future to support an iov of STREAM buffers?
>
> Possibly, though I can't promise anything. The code to handle the current
> contract is pretty complicated, and dealing with a split outside of the data
> segment (inside the padding, for instance) would add a new dimension to that.
I'd be happy with one that could only deal with a split within the data, but you would need a gss_unwrap_iov_length to handle it. I'm ok with copying HEADER, PADDING, and TRAILER to a single buffer, they aren't long and often won't be split.
Hmm, is split padding really a problem? I can see split HEADER or TRAILER being difficult to work with.
Thanks
Frank
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
