libreswan: reduce crypto deps

[neheb]

Some of these are obsolete. Others like CTS make no sense for IPSec.

📦 Package Details

Maintainer: @lucize

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR reduces kernel crypto module dependencies for the libreswan OpenWrt package, removing algorithms/modules deemed obsolete or irrelevant to typical IPSec usage.

Changes:

• Bumped PKG_RELEASE to reflect dependency changes.
• Removed several kmod-crypto-* dependencies (e.g., aead, ccm, cts, md4, rng, etc.).
• Kept a narrower set of crypto modules commonly used by IPSec (e.g., gcm, sha256, chacha20poly1305).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[lucize]

LGTM

[BKPepe]

I see some of those dependencies are also used in strongswan. Can we remove it from there, too?
cc: @pprindeville , @Thermi

[pprindeville]

I see some of those dependencies are also used in strongswan. Can we remove it from there, too? cc: @pprindeville , @Thermi

ARC4, MD4, CTS, CBC, CCM etc. are all deprecated or slated to be. I say having fewer choices limits interoperability, but it also saves the user from making poor (weak) choices or in the case of CBC, no integrity checks.

[BKPepe]

ping @neheb

[pprindeville]

LGTM

[pprindeville]

No one seems to object so I'm merging.

[robimarko]

@pprindeville: Have you seen my comment here: #29313 (comment)

To follow the talk in other good @pprindeville PR:

• strongswan: drop deprecated crypto protocols #29547

And @Thermi comments like this one:

• strongswan: drop deprecated crypto protocols #29547 (comment)

@pprindeville has planned a "CONFIG_STRONGSWAN_INCLUDE_INSECURE" feature, it can be same logic for libreswan.

I have commented:

It is not possible to have separated features to disable/enable a specified protocol?

Users would like to disable or enable only one and not all unsecure protocols...

We have received numerous complaints about your comments and behaviour in the OpenWrt organisation repos.

Your behaviour is demotivating contributors and reviewers who donate their free time to keep this project going forward.

So, please consider this a formal warning requesting you to change your behaviour and be a positive contributor to this project.

In case your behaviour continues being negative towards others trying to contribute in whatever way they can:
WE WILL BE FORCED TO BLOCK YOU from the organisation as a whole.

So, I urge you to contribute in a positive way as I and the rest of the team DO NOT practice blocking people but you will leave no choice.

Regards,
Robert

[neheb]

Related: openwrt/openwrt#23236

Specifically commit 4.

[pprindeville]

For what it's worth, I've not taken umbrage to any of the comments I've seen and I'm happy for any feedback.

[pprindeville]

@Thermi Even if the use of MD4 isn't insecure in this case, for instance, my concern is that including it might force "weak" builds of Openssl that don't satisfy FIPS-140.2 or FIPS-140.3 standards because of their presence.

[robimarko]

We have received numerous complaints about your comments and behaviour in the OpenWrt organisation repos.

@robimarko I'm sorry, who is this addressed to? @Neustradamus? Or me?

It was for @Neustradamus, sorry for the confusion, keep up the good work

[Thermi]

Then the native md4 module can still be used

On May 25, 2026 9:56:08 PM UTC, Philip Prindeville ***@***.***> wrote: pprindeville left a comment (openwrt/packages#29313) @Thermi Even if the use of `MD4` isn't insecure in this case, for instance, my concern is that including it might force "weak" builds of Openssl that don't satisfy FIPS-140.2 or FIPS-140.3 standards because of their presence. -- Reply to this email directly or view it on GitHub: #29313 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Sent from mobile. Please excuse any typos or brevity

[pprindeville]

@GeorgeSapkin Do we want to add a LIBRESWAN_INCLUDE_INSECURE flag?

[GeorgeSapkin]

@pprindeville I don't use any of these packages, so I don't have a strong opinion. My rule of the thumb is - build less with better defaults. If these are indeed insecure, why support them? There are enough security issues going around as is. People who want support for older stuff are free to use older firmware. And I'd check what the bigger Linux distros like Fedora are doing. Perhaps those kmods shouldn't be built in the first place?

For example, looks like this is the only md4 consumer:

• https://github.com/search?q=org%3Aopenwrt%20kmod-crypto-md4&type=code

[pprindeville]

@pprindeville I don't use any of these packages, so I don't have a strong opinion. My rule of the thumb is - build less with better defaults. If these are indeed insecure, why support them? There are enough security issues going around as is. People who want support for older stuff are free to use older firmware. And I'd check what the bigger Linux distros like Fedora are doing. Perhaps those kmods shouldn't be built in the first place?

@GeorgeSapkin @lucize @Neustradamus: @Thermi pointed out that there are implementations out there that require legacy protocols (I guess just Windows at this point), and that ARC/MD4 aren't congenitally insecure... it depends on how they are used. I've not gone down that rabbit-hole so I'll take Noel's word for it.

[pprindeville]

@lucize: It looks like a test-version.sh script is needed. Look at what @GeorgeSapkin did for strongswan.

[GeorgeSapkin]

There's something going on with packaging that I think needs to be addressed first:

ERROR: unable to select packages:
  firewall4-2025.03.17~b6e51575-r2:
    conflicts: firewall-2025.10.03~3a65fde5-r2[uci-firewall=2025.03.17~b6e51575-r2]
    satisfies: world[firewall4]
  firewall-2025.10.03~3a65fde5-r2:
    conflicts: firewall4-2025.03.17~b6e51575-r2[uci-firewall=2025.10.03~3a65fde5-r2]
    satisfies: libreswan-iptables-4.12-r5[firewall]
  libreswan-4.12-r5:
    conflicts: libreswan-iptables-4.12-r5[openswan=4.12-r5]
    satisfies: libreswan-iptables-4.12-r5[libreswan]
  libreswan-iptables-4.12-r5:
    conflicts: libreswan-4.12-r5[openswan=4.12-r5]
    satisfies: world[libreswan-iptables><Q1W939N62oKB+mXwycM/mOptOygUs=]

[pprindeville]

@GeorgeSapkin I don’t understand those warnings. The PROVIDES value doesn’t clash with firewall4…

[pprindeville]

@jow-: Any idea why we're seeing the build breakage?

[pprindeville]

Breathlessly waiting on the CI/CD pipeline...

[GeorgeSapkin]

I don’t understand those warnings. The PROVIDES value doesn’t clash with firewall4…

ERROR: unable to select packages:
  firewall4-2025.03.17~b6e51575-r2:
    conflicts: firewall-2025.10.03~3a65fde5-r2[uci-firewall=2025.03.17~b6e51575-r2]
    satisfies: world[firewall4]
               luci-app-firewall-26.133.20346~e9ebca7[uci-firewall]
  firewall-2025.10.03~3a65fde5-r2:
    conflicts: firewall4-2025.03.17~b6e51575-r2[uci-firewall=2025.10.03~3a65fde5-r2]
    satisfies: libreswan-iptables-4.12-r4[firewall]
               luci-app-firewall-26.133.20346~e9ebca7[uci-firewall]

libreswan-iptables depends on firewall. Both firewall and firewall4 provide uci-firewall, so they can't be installed at the same time. firewall4 is in apk world, so it can't be removed.

  libreswan-4.12-r4:
    conflicts: libreswan-iptables-4.12-r4[openswan=4.12-r4]
    satisfies: libreswan-iptables-4.12-r4[libreswan]
  libreswan-iptables-4.12-r4:
    conflicts: libreswan-4.12-r4[openswan=4.12-r4]
    satisfies: world[libreswan-iptables]

Both libreswan and libreswan-iptables provide openswan via default. libreswan-iptables depends on libreswan. They can't be installed at the same time due to having the same provider. Based on the package description, libreswan-iptables is a plugin, so it shouldn't have that provider.

[neheb]

related: https://lore.kernel.org/linux-crypto/20260622234803.6982-1-ebiggers@kernel.org/T/#u