[gnutls-devel] GnuTLS | RFC: ephemeral-api: add a mechanism to define ephemeral API (!1199)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented:


Thank you for starting this discussion. Let me try to put my perspective. I think that we should answer how we treat non-standardized protocols in text as policy (e.g., in CONTRIBUTION guide) before we finalize a technical solution. Few examples of how we handled it in the past from the top of my head:
 1. We have introduced ietf draft-28 from TLS 1.3 even before they were standardized but disabled by default (new APIs were defined)
 2. Introduced [GOST ciphersuites](https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) even on a non-final draft, but they are disabled by default. New functionality was defined - e.g., ciphers, but compatibility was broken when a cipher had a wrong s-box assigned.
 3. Introduced Ed25519 signing in certificates and TLS KX from draft-ietf-tls-rfc4492bis-17.

In all of these cases I believe the code was included when we had reasonable expectation that no significant changes are to be done in the standards.

So if the proposal is to go beyond that, let's set the bar with amending our guide, or if the proposal is for no bar, let's define the expectations from that functionality and then we finalize the API to protect from such changes.

Said that, even if decide to go for including ongoing features my concern is that even if we provide a technical solution to make certain APIs/ABIs look temporary applications that use them may expect them to continue working anyway on an ABI compatible upgrade (though I'd really like to hear more from potential consumers of such experimental features).

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1199#note_296523593
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/20200229/bb2408df/attachment.html>