Issue with MIT Kerberos Documentation - Developing with GSSAPI

[Frank Filz]

> 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