Issue with MIT Kerberos Documentation - Developing with GSSAPI
ffilzlnx at mindspring.com
Thu May 9 19:05:53 EDT 2019
> 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.
More information about the krbdev