starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #3452] Possibility of adding back OpenSSL support (tls-openssl & dnssec-openssl) that was removed in v0.25+ #1186

New issue

Closed

opened 2026-03-16 01:50:48 +03:00 by kerem · 9 comments

kerem commented

2026-03-16 01:50:48 +03:00

Owner

Originally created by @decathorpe on GitHub (Feb 6, 2026).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3452

The removal of the OpenSSL backends in v0.25.0 is biting us downstream in Fedora Linux (and will likely also affect Red Hat in the future). OpenSSL is basically the only crypto backend that is supported by the Red Hat Crypto team for purposes like this.

Using OpenSSL has the added benefit of not needing be statically linked into executables, and hence the possibility of out-of-band security updates that don't require recompiling Rust applications. Neither "ring" nor "aws-lc" backends are suitable replacements in this problem space.

I appreciate that OpenSSL itself and support for it is often difficult and / or unrewarding, and I understand why projects keep pushing towards aws-lc / ring - but given the constraints within which downstream distributions like Fedora / RHEL must operate, both are still strictly worse options than OpenSSL (and in some cases, not an option we can use at all).

Originally created by @decathorpe on GitHub (Feb 6, 2026). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3452 The removal of the OpenSSL backends in v0.25.0 is biting us downstream in Fedora Linux (and will likely also affect Red Hat in the future). OpenSSL is basically the only crypto backend that is supported by the Red Hat Crypto team for purposes like this. Using OpenSSL has the added benefit of not needing be statically linked into executables, and hence the possibility of out-of-band security updates that don't require recompiling Rust applications. Neither "ring" nor "aws-lc" backends are suitable replacements *in this problem space*. I appreciate that OpenSSL itself and support for it is often difficult and / or unrewarding, and I understand *why* projects keep pushing towards aws-lc / ring - but given the constraints within which downstream distributions like Fedora / RHEL must operate, both are still *strictly worse* options than OpenSSL (and in some cases, not an option we can use *at all*).

kerem closed this issue

2026-03-16 01:50:53 +03:00

kerem commented

2026-03-16 01:50:59 +03:00

Author

Owner

@djc commented on GitHub (Feb 6, 2026):

I suggest Fedora / RHEL invest in/help fund an OpenSSL rustls crypto provider backed by a dynamically linked library.

@djc commented on GitHub (Feb 6, 2026): I suggest Fedora / RHEL invest in/help fund an OpenSSL rustls crypto provider backed by a dynamically linked library.

kerem commented

2026-03-16 01:51:04 +03:00

Author

Owner

@cpu commented on GitHub (Feb 6, 2026):

I think this issue would be better with more detail on the ways you think that the status quo is strictly worse than OpenSSL. Your post only mentions static linking explicitly, but isn't it the case that all of the other Rust-based dependencies of HickoryDNS would also require re-compilation in order to patch a security vulnerability?

@cpu commented on GitHub (Feb 6, 2026): I think this issue would be better with more detail on the ways you think that the status quo is strictly worse than OpenSSL. Your post only mentions static linking explicitly, but isn't it the case that all of the other Rust-based dependencies of HickoryDNS would also require re-compilation in order to patch a security vulnerability?

kerem commented

2026-03-16 01:51:09 +03:00

Author

Owner

@decathorpe commented on GitHub (Feb 7, 2026):

I suggest Fedora / RHEL invest in/help fund an OpenSSL rustls crypto provider backed by a dynamically linked library.

I can reach out to the Red Hat Crypto team about that.

I think this issue would be better with more detail on the ways you think that the status quo is strictly worse than OpenSSL.

I can try to expand on "strictly worse" a bit.

Packaging friendliness (both from a technical and legal point of view):

OpenSSL is, by far, the easiest for us to use. Install "openssl-devel", use the openssl crate. Done.
The "next best" is ring, which requires only very small modifications (stripping pre-built *.o files and pre-generated source code) to ensure that no prebuilt binaries are used during the build.
Building aws-lc "correctly" (for our purposes) is ... hard. It requires cmake to build everything from source, and ensuring that the build does not use any precompiled objects isn't easy. As far as I can tell, this requires patching both the CMake build system, the Rust build system, and source code. The scope of changes necessary is the major reason why we don't have the aws-lc-rs and aws-lc-sys crates packaged for Fedora yet.

Security updates:

OpenSSL is easiest. The openssl package in Fedora is maintained by Red Hat and receives fixes for security issues quickly. This requires zero action for Rust applications that link against OpenSSL.
ring would be relatively straightforward too (i. update the package for the "ring" crate, ii. rebuild all applications that use it wit the new version), if it weren't basically unmaintained now.
aws-lc would hopefully be similar to ring, though since it's not available on Fedora yet, we don't have experience with this.

Your post only mentions static linking explicitly, but isn't it the case that all of the other Rust-based dependencies of HickoryDNS would also require re-compilation in order to patch a security vulnerability?

Correct - but this is not an all-or-nothing issue. Having fewer statically linked, security sensitive dependencies means rebuilding applications for security issues needs to happen less frequently. Which is a good thing, because it's a lot of work.

@decathorpe commented on GitHub (Feb 7, 2026): > I suggest Fedora / RHEL invest in/help fund an OpenSSL rustls crypto provider backed by a dynamically linked library. I can reach out to the Red Hat Crypto team about that. > I think this issue would be better with more detail on the ways you think that the status quo is strictly worse than OpenSSL. I can try to expand on "strictly worse" a bit. **Packaging friendliness** (both from a technical *and* legal point of view): * OpenSSL is, **by far**, the easiest for us to use. Install "openssl-devel", use the `openssl` crate. Done. * The "next best" is ring, which requires only *very small* modifications (stripping pre-built `*.o` files and pre-generated source code) to ensure that no prebuilt binaries are used during the build. * Building aws-lc "correctly" (for our purposes) is ... hard. It requires `cmake` to build everything from source, and ensuring that the build does not use any precompiled objects isn't easy. As far as I can tell, this requires patching both the CMake build system, the Rust build system, and source code. The scope of changes necessary is the major reason why we don't have the `aws-lc-rs` and `aws-lc-sys` crates packaged for Fedora yet. **Security updates**: * OpenSSL is easiest. The openssl package in Fedora is maintained by Red Hat and receives fixes for security issues quickly. This requires *zero* action for Rust applications that link against OpenSSL. * ring *would* be relatively straightforward too (i. update the package for the "ring" crate, ii. rebuild all applications that use it wit the new version), if it weren't basically unmaintained now. * aws-lc would *hopefully* be similar to ring, though since it's not available on Fedora yet, we don't have experience with this. > Your post only mentions static linking explicitly, but isn't it the case that all of the other Rust-based dependencies of HickoryDNS would also require re-compilation in order to patch a security vulnerability? Correct - but this is not an all-or-nothing issue. Having *fewer* statically linked, security sensitive dependencies means rebuilding applications for security issues needs to happen less frequently. Which is a good thing, because it's a lot of work.

kerem commented

2026-03-16 01:51:14 +03:00

Author

Owner

@cpu commented on GitHub (Feb 10, 2026):

Thanks for expanding on your position. I appreciate it, and it's helpful context regardless of how the Hickory project decides to handle the feedback. I'm individually not convinced we should resurrect the OpenSSL support but my opinion isn't the project's opinion.

Building aws-lc "correctly" (for our purposes) is ... hard

Is there an upstream issue that we can track where you've provided feedback to the AWS team w.r.t what your needs are, and how the current implementation isn't meeting them? It does sound reasonable to want a way to build that crate purely from source without any pre-built binaries (even though it's counter to what a vocal set of consumers have wanted from both ring and aws-lc-rs in the past). In my experience the aws-lc/aws-lc-rs maintainers have been engaged + responsive to this sort of feedback and are open to making build changes.

The openssl package in Fedora is maintained by Red Hat and receives fixes for security issues quickly. This requires zero action for Rust applications that link against OpenSSL.

On this front I agree with Djc that investing in a Rustls cryptography provider backed by OpenSSL seems like a promising direction.

Correct - but this is not an all-or-nothing issue. Having fewer statically linked, security sensitive dependencies means rebuilding applications for security issues needs to happen less frequently. Which is a good thing, because it's a lot of work.

True, but my point here was more that there's value in trying to reduce the work involved since even taking Rustls and its cryptography providers off the table you're left needing an effective process for handling vulnerabilities in Rust dependencies. Improvements here would yield benefits that extend beyond hickory-dns.

I also think it's worth thinking about the rate of CVEs in OpenSSL relative to other projects. For instance, 100% of the recent batch of CVEs affecting OpenSSL did not apply to BoringSSL or aws-lc. I also think the history of Rustls CVEs has been very positive in comparison.

Overall I think the way the winds are blowing you're going to be feeling more and more friction with various projects that are actively moving away from OpenSSL due to a variety of compelling reasons (security, performance, ease of use, clarity of code, etc). Convincing individual projects to change direction feels like a short term solution. In the long term I think everyone will benefit from redirecting resources away from OpenSSL and to alternatives that are better positioned for our mutual long term goals.

@cpu commented on GitHub (Feb 10, 2026): Thanks for expanding on your position. I appreciate it, and it's helpful context regardless of how the Hickory project decides to handle the feedback. I'm individually not convinced we should resurrect the OpenSSL support but my opinion isn't the project's opinion. > Building aws-lc "correctly" (for our purposes) is ... hard Is there an upstream issue that we can track where you've provided feedback to the AWS team w.r.t what your needs are, and how the current implementation isn't meeting them? It does sound reasonable to want a way to build that crate purely from source without any pre-built binaries (_even though it's counter to what a vocal set of consumers have wanted from both `ring` and `aws-lc-rs` in the past_). In my experience the aws-lc/aws-lc-rs maintainers have been engaged + responsive to this sort of feedback and are open to making build changes. > The openssl package in Fedora is maintained by Red Hat and receives fixes for security issues quickly. This requires zero action for Rust applications that link against OpenSSL. On this front I agree with Djc that investing in a Rustls cryptography provider backed by OpenSSL seems like a promising direction. > Correct - but this is not an all-or-nothing issue. Having fewer statically linked, security sensitive dependencies means rebuilding applications for security issues needs to happen less frequently. Which is a good thing, because it's a lot of work. True, but my point here was more that there's value in trying to reduce the work involved since even taking Rustls and its cryptography providers off the table you're left needing an effective process for handling vulnerabilities in Rust dependencies. Improvements here would yield benefits that extend beyond `hickory-dns`. I also think it's worth thinking about the rate of CVEs in OpenSSL relative to other projects. For instance, 100% of the recent batch of CVEs affecting OpenSSL did not apply to BoringSSL or aws-lc. I also think the history of Rustls CVEs has been very positive in comparison. Overall I think the way the winds are blowing you're going to be feeling more and more friction with various projects that are [actively moving away from OpenSSL](https://cryptography.io/en/latest/statements/state-of-openssl/) due to a variety of compelling reasons (security, performance, ease of use, clarity of code, etc). Convincing individual projects to change direction feels like a short term solution. In the long term I think everyone will benefit from redirecting resources away from OpenSSL and to alternatives that are better positioned for our mutual long term goals.

kerem commented

2026-03-16 01:51:19 +03:00

Author

Owner

@decathorpe commented on GitHub (Feb 14, 2026):

Building aws-lc "correctly" (for our purposes) is ... hard

Is there an upstream issue that we can track where you've provided feedback to the AWS team w.r.t what your needs are, and how the current implementation isn't meeting them? It does sound reasonable to want a way to build that crate purely from source without any pre-built binaries (even though it's counter to what a vocal set of consumers have wanted from both ring and aws-lc-rs in the past). In my experience the aws-lc/aws-lc-rs maintainers have been engaged + responsive to this sort of feedback and are open to making build changes.

I agree, aws-lc-rs maintainers have been nice to work with. I filed some issues for the most rough edges previously (aws-lc-rs#710, aws-lc-rs#752), but further work would be still pending as the effort to package aws-lc-sys / aws-lc-rs crates had stalled for a while.

As to this point:

(even though it's counter to what a vocal set of consumers have wanted from both ring and aws-lc-rs in the past)

I know, and I understand the reasoning behind including some prebuilt blobs - it makes it a lot easier for users to install stuff with "cargo install", for one, because you don't need external tools like a C compiler, assembler, Perl, Go, or development headers for OpenSSL, etc.

Still, prebuilt blobs like that are a huge no-no for most (all?) Linux distributions, and right now forcing aws-lc-rs / aws-lc-sys to rebuild all its stuff from source requires some amount of patchery and hackery (especially because it needs to be unconditional regardless of target architecture - i.e. x86_64, i686, aarch64, powerpc64le, and s390x).

The openssl package in Fedora is maintained by Red Hat and receives fixes for security issues quickly. This requires zero action for Rust applications that link against OpenSSL.

On this front I agree with Djc that investing in a Rustls cryptography provider backed by OpenSSL seems like a promising direction.

There is https://github.com/tofay/rustls-openssl but I'm not sure if that's "ready" yet to be the default provider for everything that uses rustls in Fedora.

Correct - but this is not an all-or-nothing issue. Having fewer statically linked, security sensitive dependencies means rebuilding applications for security issues needs to happen less frequently. Which is a good thing, because it's a lot of work.

True, but my point here was more that there's value in trying to reduce the work involved since even taking Rustls and its cryptography providers off the table you're left needing an effective process for handling vulnerabilities in Rust dependencies. Improvements here would yield benefits that extend beyond hickory-dns.

Of course, having better tooling / more automation to track rebuilds for security issues would be good regardless.

I also think it's worth thinking about the rate of CVEs in OpenSSL relative to other projects. For instance, 100% of the recent batch of CVEs affecting OpenSSL did not apply to BoringSSL or aws-lc. I also think the history of Rustls CVEs has been very positive in comparison.

No objections from me there. But it doesn't invalidate the point that OpenSSL 1) remains the (strongly) preferred cryptography library in Fedora and Red Hat, and 2) is still much easier to use for packages.

Overall I think the way the winds are blowing you're going to be feeling more and more friction with various projects that are actively moving away from OpenSSL due to a variety of compelling reasons (security, performance, ease of use, clarity of code, etc). Convincing individual projects to change direction feels like a short term solution. In the long term I think everyone will benefit from redirecting resources away from OpenSSL and to alternatives that are better positioned for our mutual long term goals.

For what it's worth, I agree. It's not as if I like OpenSSL, either, but it's the thing that we (to some degree) have to use, and is also the easiest to use correctly (within the restrictions we have).

Personally I think graviola+rustls looks interesting, but that's 1) still way too early and 2) doesn't support all the CPU architectures we need to support (i.e. x86_64-v1, i686, powerpc64le, s390x). ☹️

@decathorpe commented on GitHub (Feb 14, 2026): > > Building aws-lc "correctly" (for our purposes) is ... hard > > Is there an upstream issue that we can track where you've provided feedback to the AWS team w.r.t what your needs are, and how the current implementation isn't meeting them? It does sound reasonable to want a way to build that crate purely from source without any pre-built binaries (_even though it's counter to what a vocal set of consumers have wanted from both `ring` and `aws-lc-rs` in the past_). In my experience the aws-lc/aws-lc-rs maintainers have been engaged + responsive to this sort of feedback and are open to making build changes. I agree, aws-lc-rs maintainers have been nice to work with. I filed some issues for the most rough edges previously ([aws-lc-rs#710](https://github.com/aws/aws-lc-rs/issues/710), [aws-lc-rs#752](https://github.com/aws/aws-lc-rs/issues/752)), but further work would be still pending as the effort to package aws-lc-sys / aws-lc-rs crates had stalled for a while. As to this point: > (_even though it's counter to what a vocal set of consumers have wanted from both `ring` and `aws-lc-rs` in the past_) I know, and I understand the reasoning behind including some prebuilt blobs - it makes it a lot easier for users to install stuff with "cargo install", for one, because you don't need external tools like a C compiler, assembler, Perl, Go, or development headers for OpenSSL, etc. Still, prebuilt blobs like that are a **huge** no-no for most (all?) Linux distributions, and right now forcing aws-lc-rs / aws-lc-sys to rebuild all its stuff from source requires some amount of patchery and hackery (especially because it needs to be unconditional regardless of target architecture - i.e. `x86_64`, `i686`, `aarch64`, `powerpc64le`, and `s390x`). > > The openssl package in Fedora is maintained by Red Hat and receives fixes for security issues quickly. This requires zero action for Rust applications that link against OpenSSL. > > On this front I agree with Djc that investing in a Rustls cryptography provider backed by OpenSSL seems like a promising direction. There is https://github.com/tofay/rustls-openssl but I'm not sure if that's "ready" yet to be the default provider for *everything that uses rustls in Fedora*. > > Correct - but this is not an all-or-nothing issue. Having fewer statically linked, security sensitive dependencies means rebuilding applications for security issues needs to happen less frequently. Which is a good thing, because it's a lot of work. > > True, but my point here was more that there's value in trying to reduce the work involved since even taking Rustls and its cryptography providers off the table you're left needing an effective process for handling vulnerabilities in Rust dependencies. Improvements here would yield benefits that extend beyond `hickory-dns`. Of course, having better tooling / more automation to track rebuilds for security issues would be good regardless. > I also think it's worth thinking about the rate of CVEs in OpenSSL relative to other projects. For instance, 100% of the recent batch of CVEs affecting OpenSSL did not apply to BoringSSL or aws-lc. I also think the history of Rustls CVEs has been very positive in comparison. No objections from me there. But it doesn't invalidate the point that OpenSSL 1) remains the (strongly) preferred cryptography library in Fedora and Red Hat, and 2) is still much easier to use for packages. > Overall I think the way the winds are blowing you're going to be feeling more and more friction with various projects that are [actively moving away from OpenSSL](https://cryptography.io/en/latest/statements/state-of-openssl/) due to a variety of compelling reasons (security, performance, ease of use, clarity of code, etc). Convincing individual projects to change direction feels like a short term solution. In the long term I think everyone will benefit from redirecting resources away from OpenSSL and to alternatives that are better positioned for our mutual long term goals. For what it's worth, I agree. It's not as if I *like* OpenSSL, either, but it's the thing that we (to some degree) *have* to use, and is also the *easiest* to use correctly (**within the restrictions we have**). Personally I think graviola+rustls looks interesting, but that's 1) still way too early and 2) doesn't support all the CPU architectures we need to support (i.e. x86_64-v1, i686, powerpc64le, s390x). ☹️

kerem commented

2026-03-16 01:51:25 +03:00

Author

Owner

@decathorpe commented on GitHub (Feb 14, 2026):

Maybe as an additional data point: The removal of OpenSSL support is causing some friction in our upstream projects too ( like https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1814 ). sequoia-openpgp supports multiple different cryptography backends (nettle, openssl, RustCrypto, botan, Windows/CNG). Fedora builds default to the OpenSSL backend, so pulling in aws-lc or ring in hickory v0.25 causes an additional cryptography library to get included - compared to v0.24 with the openssl backend.

@decathorpe commented on GitHub (Feb 14, 2026): Maybe as an additional data point: The removal of OpenSSL support is causing some friction in our upstream projects too ( like https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1814 ). sequoia-openpgp supports multiple different cryptography backends (nettle, openssl, RustCrypto, botan, Windows/CNG). Fedora builds default to the OpenSSL backend, so pulling in aws-lc *or* ring in hickory v0.25 causes an additional cryptography library to get included - compared to v0.24 with the openssl backend.

kerem commented

2026-03-16 01:51:30 +03:00

Author

Owner

@djc commented on GitHub (Feb 14, 2026):

There is https://github.com/tofay/rustls-openssl but I'm not sure if that's "ready" yet to be the default provider for everything that uses rustls in Fedora.

I think the rustls team would be open to making a first party OpenSSL crypto provider, provided that the organizations that want it (seemingly largely backed by enterprises) to fund it.

@djc commented on GitHub (Feb 14, 2026): > There is https://github.com/tofay/rustls-openssl but I'm not sure if that's "ready" yet to be the default provider for everything that uses rustls in Fedora. I think the rustls team would be open to making a first party OpenSSL crypto provider, provided that the organizations that want it (seemingly largely backed by enterprises) to fund it.

kerem commented

2026-03-16 01:51:35 +03:00

Author

Owner

@cpu commented on GitHub (Feb 20, 2026):

Still, prebuilt blobs like that are a huge no-no for most (all?) Linux distributions, and right now forcing aws-lc-rs / aws-lc-sys to rebuild all its stuff from source requires some amount of patchery and hackery (especially because it needs to be unconditional regardless of target architecture - i.e. x86_64, i686, aarch64, powerpc64le, and s390x).

I hear you. Forbidding binary blobs is a very sensible policy and I'm supportive. I noticed you left a positive note in your packaging ticket on this front:

It also appears that forcing the build system to regenerate all bindings and avoiding pre-built objects and assembly is easier now, so the patches are a lot simpler than they used to be.

If there's rough edges left to address I would personally be more interested in trying to help out on that front somehow than to revive OpenSSL support.

No objections from me there. But it doesn't invalidate the point that OpenSSL 1) remains the (strongly) preferred cryptography library in Fedora and Red Hat, and 2) is still much easier to use for packages.
...
it's the thing that we (to some degree) have to use, and is also the easiest to use correctly (within the restrictions we have).

Agreed that it doesn't invalidate those points. Mostly I want to focus on how we can fix item 2 because it feels like something folks outside of the Fedora/Red Hat governance structure can work on. Are you in a position to know if aws-lc-rs were easier to use correctly in your context, would there still be a hard-requirement on OpenSSL?

I think this discussion has at least helped me understand you feel similar on some of the disadvantages. I'm hopeful there are voices like yours speaking to the folks with their hands on the policy knobs to try and convince them a strong preference for OpenSSL is putting them at a crossroads with a growing set of folks that prefer otherwise.

The removal of OpenSSL support is causing some friction in our upstream projects too ( like https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1814 ). sequoia-openpgp supports multiple different cryptography backends (nettle, openssl, RustCrypto, botan, Windows/CNG).

I'm less sure how to handle this situation and it does seem like a genuine mismatch. With full ignorance of the Sequoia project, I do wonder if it'd be a smaller lift to support aws-lc as a backend in sequoia (since they're already carrying the complexity of multiplexing across several providers) vs re-adding an openssl option in this project (where we only had 2 TLS/cryptography implementations and are now free of that abstraction).

In either case, thanks again for the continued discussion. I acknowledge the job of package maintainers like yourself is a challenging one and you're stuck between clashing priorities. Thanks for doing the work you do.

@cpu commented on GitHub (Feb 20, 2026): > Still, prebuilt blobs like that are a huge no-no for most (all?) Linux distributions, and right now forcing aws-lc-rs / aws-lc-sys to rebuild all its stuff from source requires some amount of patchery and hackery (especially because it needs to be unconditional regardless of target architecture - i.e. x86_64, i686, aarch64, powerpc64le, and s390x). I hear you. Forbidding binary blobs is a very sensible policy and I'm supportive. I noticed you left a positive note in your packaging ticket on this front: > It also appears that forcing the build system to regenerate all bindings and avoiding pre-built objects and assembly is easier now, so the patches are a lot simpler than they used to be. If there's rough edges left to address I would personally be more interested in trying to help out on that front somehow than to revive OpenSSL support. > No objections from me there. But it doesn't invalidate the point that OpenSSL 1) remains the (strongly) preferred cryptography library in Fedora and Red Hat, and 2) is still much easier to use for packages. > ... > it's the thing that we (to some degree) have to use, and is also the easiest to use correctly (within the restrictions we have). Agreed that it doesn't invalidate those points. Mostly I want to focus on how we can fix item 2 because it feels like something folks outside of the Fedora/Red Hat governance structure can work on. Are you in a position to know if `aws-lc-rs` were easier to use correctly in your context, would there still be a hard-requirement on OpenSSL? I think this discussion has at least helped me understand you feel similar on some of the disadvantages. I'm hopeful there are voices like yours speaking to the folks with their hands on the policy knobs to try and convince them a strong preference for OpenSSL is putting them at a crossroads with a growing set of folks that prefer otherwise. > The removal of OpenSSL support is causing some friction in our upstream projects too ( like https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1814 ). sequoia-openpgp supports multiple different cryptography backends (nettle, openssl, RustCrypto, botan, Windows/CNG). I'm less sure how to handle this situation and it does seem like a genuine mismatch. With full ignorance of the Sequoia project, I do wonder if it'd be a smaller lift to support `aws-lc` as a backend in sequoia (since they're already carrying the complexity of multiplexing across several providers) vs re-adding an openssl option in this project (where we only had 2 TLS/cryptography implementations and are now free of that abstraction). In either case, thanks again for the continued discussion. I acknowledge the job of package maintainers like yourself is a challenging one and you're stuck between clashing priorities. Thanks for doing the work you do.

kerem commented

2026-03-16 01:51:40 +03:00

Author

Owner

@decathorpe commented on GitHub (Feb 24, 2026):

Thanks, I do appreciate the productive discussion that happened here.

I don't have enough insight into how the Red Hat Crypto team operates to know whether aws-lc would even be considered a viable alternative option for them - it has been begrudgingly OK'd for inclusion on Fedora, though mostly because aws-lc-rs is now a strictly better option than "ring" (which didn't go through the same review when it was originally added).

As for sequoia-openpgp, it might be possible to add an aws-lc backend (nettle / openssl / RustCrypto / botan etc. already exist), but I am unsure whether aws-lc-rs actually exposes all the cryptography primitives that would be needed for this. But I'm not sure if that would even be desirable, since the cryptography backend we use for sequoia-pgp tools in Fedora will likely remain OpenSSL for the foreseeable future.

I am trying to figure out if an OpenSSL / libcrypto backend for rustls would be possible and / or if Red Hat would be interested in developing / maintaining / funding it, but haven't heard back yet.

That said, it sounds like there's not much that can be done in hickory-dns - I do appreciate that not having to conditionalize multiple backends is something that you'd rather not back out of. :)

@decathorpe commented on GitHub (Feb 24, 2026): Thanks, I do appreciate the productive discussion that happened here. I don't have enough insight into how the Red Hat Crypto team operates to know whether aws-lc would even be considered a viable alternative option *for them* - it has been begrudgingly OK'd for inclusion on Fedora, though mostly because aws-lc-rs is now a strictly better option than "ring" (which didn't go through the same review when it was originally added). As for sequoia-openpgp, it might be possible to add an aws-lc backend (nettle / openssl / RustCrypto / botan etc. already exist), but I am unsure whether aws-lc-rs actually exposes all the cryptography primitives that would be needed for this. But I'm not sure if that would even be desirable, since the cryptography backend we use for sequoia-pgp tools in Fedora will likely remain OpenSSL for the foreseeable future. I am trying to figure out if an OpenSSL / libcrypto backend for rustls would be possible and / or if Red Hat would be interested in developing / maintaining / funding it, but haven't heard back yet. That said, it sounds like there's not much that can be done in hickory-dns - I do appreciate that not having to conditionalize multiple backends is something that you'd rather not back out of. :)

kerem referenced this issue

2026-03-16 05:01:16 +03:00

[PR #1186] [MERGED] Support for lowercase DNSClass and RecordType fields in zonefiles #2055

kerem referenced this issue

2026-03-16 05:18:05 +03:00

[PR #1186] [MERGED] Support for lowercase DNSClass and RecordType fields in zonefiles #2059