- We are tied to ABI in libhogweed; we need to ensure its soname changes in next nettle release
- How do we manage increasing technical debt (e.g., due to nettle) and incompatible behavioral changes in the 3_6_x branch such as these issues
- If the answer is a 3.7.0 release
- Can we handle two releases in parallel?
- Until when the 3.6.x will be supported released?
- What will be the policy for 3.6.x changes?
- Should its roadmap be feature based or time-based?
- If the answer is a 3.7.0 release
- How fast can we implement everything needed for QUIC ?
- It would be a good opportunity to become better known / more widely used. The Curl devs are already nervous that OpenSSL will delay QUIC even after the 3.0 release. CurlUp is 9-10 May in Berlin - it would be nice to QUIC (API) in GnuTLS until then (I'll be there).
- And I would like to start adding QUIC to Wget2 then.
Some questions/remarks from me (Tim / rockdaboot).
- In what way do nettle releases break API /ABI ?
- If nettle releases are backwards compatible - does it make sense to write a M4 file to test for all the features that GnuTLS needs ? This might need a GnuTLS rebuild whenever nettle is updated (having more or less features). Another option is to check nettle's features during runtime. Does nettle allow this ? I am asking this because it could be a way to get rid of certain nettle version dependencies - and thus offloads some burden from us.
- I can not help much handling releases because I only have time occasionally and unscheduled.
- Policy for 3.6.x: Bug/doc fixes only. Exceptions from that needs prior discussion.
- Roadmap: Regular (time-based) releases are good. As long as we don't stick too tight with the schedule. We should not release with a half-baken feature. If a new (important) feature is ready to be released - why wait until the scheduled date ? Of course it depends on the maintainers available time as well.
- Nikos: in my view to have time-based releases requires not merging half-baked features, e.g, by splitting them into self contained parts. That we have done with GOST quite successfully in my opinion. The target of the time-based release is usually planned by me (i.e., the person doing the release), and we are not accurate to the day. Some times it can be few days later or earlier.
- Just to throw in a 3.6.x deadline: 2 years starting at 3.7 release.
GnuTLS depends on internal Nettle ABI. Mea culpa. It seemed stable till curve448 patches. Current gnutls works with nettle master, but requires recompilation due to
struct ecc_curve changes. Might be solved by libhogweed soname bump.
In current GnuTLS:
|GOST DSA||master, few patches pending|
|streebog||none, MR pending|
|gost 28147||none, MR pending|
|rfc 4357 addons||none|
Pending in pull requests:
|Magma||block cipher, reworked gost 28147|
|CTR-ACPKM mode||CTR mode with rekeying|
|MGM mode||AEAD mode|
|TLSTREE||external rekeying for TLS|
- We sometimes need to implement unfinalized protocol features (ESNI, QUIC, for example) with API changes. Should we have a unified way to expose such features as experimental API, without polluting ABI, or 3.7.x branch is supposed to accommodate such changes?
- NSS has a dedicated mechanism to define experimental API
- We already have similar header trick in
tests/mpi.c, but it's very specific
- OpenSSL 3.0
Possible schedule for a matrix conf (video ?):
|8||Thu 1700-1800 UTC||Wed,Fri 1800-1900 UTC (usually)||Mon,Thu,Fri,Sa,So 900-2300 UTC||Mo,Tue,Wed,Fr 1800-1900 UTC, Sat,So ~anytime|
|9||Mo-Fr 1700-2000 UTC||Fri 0900-1800 UTC||Tue 900-1300 UTC, Wed 900-1700UTC||Tue-So 1000-2100
|10||Mo,Thu 1700-1800 UTC||Mon 0900-1800 UTC, Tue 0900-1500 UTC||This Mon except 1130-1230 UTC||Mo-So 1000-2100