Fridolín Pokorný

Without this fix I'm experiencing the following issue: ```python In [1]: import delegator In [2]: delegator.run(['echo', 'hello']).out Out[2]: '\n' In [3]: ``` According to [docs](https://docs.python.org/3/library/subprocess.html#subprocess.Popen) (see args section): > Unless...

ping @kennethreitz, any change to get this reviewed/in? thanks!

@timofurrer done, thanks for refresh.

> The reason your code example above doesn't work is the `shell` argument being set to `True` in `_default_popen_kwargs`. Further below in the [docs](https://docs.python.org/3/library/subprocess.html#subprocess.Popen): > > > The shell argument...

Awesome, Lance! Thank you. While I was implementing and doing benchmarks of AF_KTLS, I used [1]. It is not the best possible solution, but it was/is useful (note some errors...

Also discussed in https://github.com/fridex/af_ktls/issues/15 EDIT: As repo has moved, the discussion in at https://github.com/ktls/af_ktls/issues/15

Thank you for the patch. In my opinion it should worth to support both: - make rfc4106 copyless since it affects performance when sending records that are bigger than PAGE_SIZE...

A solution present in https://github.com/ktls/net_next_ktls/commit/b0d69f217ecc5eee91e10953a851978f21b84875#diff-19d8c55950b68c71d87e12df129ae8f7

According to sources, there are implemented "rfc7539esp" and ""rfc7539", which cover "rfc7539esp(chacha20,poly1305)" and ""rfc7539(chacha20,poly1305)". I expect memory organization to be different than AES-GCM in crypto API. [1] https://tools.ietf.org/html/rfc7539 [2] http://lxr.free-electrons.com/source/crypto/chacha20poly1305.c

related: https://github.com/fridex/af_ktls/pull/24