Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Epic] GnuTLS support #259

Closed
1 task
janbrasna opened this issue Oct 10, 2024 · 4 comments
Closed
1 task

[Epic] GnuTLS support #259

janbrasna opened this issue Oct 10, 2024 · 4 comments

Comments

@janbrasna
Copy link
Collaborator

janbrasna commented Oct 10, 2024

This is a meta issue tracking the feasibility of supporting GnuTLS configurations either in the same template, or a separate template — to assess whether the current recommendations can be adapted to the necessary priority strings, able to redefine OS-level defaults etc. to apply meaningfully and in a predictable consistent way.

Config compatibility

Preview Give feedback
  1. new software support
@gstrauss
Copy link
Collaborator

HandlebarJS might not be the best choice. At a certain point it may be easier to write the logic directly in javascript. GnuTLS priority strings are easier to construct with a language like javascript than to contort through more limited HandlebarJS templating directives.

@janbrasna
Copy link
Collaborator Author

The actual value for render would almost certainly be constructed within the js app and only passed to the output object for templates to (conditionally) use.

Where I am not sure considering the templating logic is, whether we'll be able to deliver both OpenSSL and GnuTLS options within a single config (given the lib used is defined for each template) without some UI & settings refactoring, or monkey patching one implementation atop the other if we only keep one defined in the configs.

(Compare to e.g. OpenSSL vs. JSSE implementations, where both IANA and OpenSSL input is understood, validated, and iterated over being translated to the underlying api by the server, making that issue opaque to us, allowing to just emit one config and let the server adapt the values for the actual implementation eventually used.)

The biggest challenge is whether the existing json data provide enough surface to even derive the possible priority strings. (It's super tricky to get them right, and I don't even know how well would they work across different systems. But that would definitely make an important addition to have that available here as a boilerplate.)

@janbrasna
Copy link
Collaborator Author

Ah, yeah there's .ifdef mentioned in #115 (comment)https://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_exim_runtime_configuration_file.html, so perhaps there is a chance even exim could be rendered for both in one template 💟 🚀

But the more I think of it, the less I'm sure we should invent the priority strings here — I'd say they ought to be defined directly in the recommendations, as a counterpart to the other configs, and only consumed here afterwards.

@gstrauss
Copy link
Collaborator

gstrauss commented Dec 7, 2024

#115 already exists. I will be converting this open-ended discussion to a github Discussion.

This is a meta issue tracking the feasibility of supporting GnuTLS configurations

If there is a well-scoped item on which you plan to work to move that experiment forward, that can be created as an issue. If there is no commitment from anybody with the time or skills or inclination to move this forward, then please continue in a github Discussion.

@mozilla mozilla locked and limited conversation to collaborators Dec 7, 2024
@gstrauss gstrauss converted this issue into discussion #298 Dec 7, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants