[gnutls-devel] GnuTLS | ktls: basic implementation of SW mode (!1451)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Mon Sep 20 19:22:29 CEST 2021
Daniel P_ Berrangé commented on a discussion on lib/system/ktls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1451#note_682339027
> + */
> +
> +#include "config.h"
> +#include "system/ktls.h"
> +
> +#ifdef ENABLE_KTLS
> +
> +#include <linux/tls.h>
> +#include <record.h>
> +#include <sys/socket.h>
> +#include <netinet/tcp.h>
> +#include <unistd.h>
> +#include <errno.h>
> +
> +/**
> + * gnutls_transport_set_ktls:
If I was using this method, then I expect it would be upfront at the same time as initializing the transport. IOW before handshake.
WRT to whether to return an error or do automatic fallback, personally I'd tend towards "do the right thing". I tend to view KTLS as a "nice to have" optimization, rather than a "must have" feature, so want it to be tried, but if not possible, transparently fallback.
If there are people, however, that view KTLS as something more critical, then they might want strong guarantees.
Perhaps it could motivate a extra param
@required: 1 if KTLS is mandatory, 0 if KTLS is optional
?
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1451#note_682339027
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20210920/77c2474d/attachment-0001.html>
More information about the Gnutls-devel
mailing list