libgcrypt: introduce mini variant by jschwartzenberg · Pull Request #25602 · openwrt/packages

jschwartzenberg · 2024-12-23T19:38:05Z

Maintainer: @flyn-org
Compile tested: (mipsel_24kc_musl, TP-Link Archer C50v6, f10ee1e20966bdb86cb61a87338f953de1d86cc6)
Run tested: (mipsel_24kc_musl, TP-Link Archer C50v6, 24.10-rc2, tested a version compiled with the same flags still works with vpnc)

Description:
This allows building a smaller version of libgcrypt which takes up less disk space. This helps conserving space on devices with little flash while still providing a working libgcrypt.

Please let me know what you think of this PR! I intend to do more testing with the version built from this specific Makefile but my earlier tests shows that this works fine. Many thanks in advance for any feedback you might have!

flyn-org · 2024-12-23T19:51:58Z

I like the concept, but DES, MD5, and SHA1 are all obsolete. What led to your cipher/hash choices?

jschwartzenberg · 2024-12-23T20:29:14Z

I looked at what vpnc supports: https://github.com/streambinder/vpnc/blob/master/docs/about.md
I avoided anything that it doesn't support. I also had to add blake2 to avoid a build issue.

Possibly this is indeed a very specific set for my situation :)

Maybe it would be possible to experiment with different selections and observe the resulting sizes. I'm not really sure what would be the best approach.

BKPepe · 2024-12-23T20:51:29Z

This allows building a smaller version of libgcrypt which takes up less disk space.

May I know if you do have some numbers, so we can know how much is less? :) Thank you.

jschwartzenberg · 2024-12-23T21:42:36Z

This allows building a smaller version of libgcrypt which takes up less disk space.

May I know if you do have some numbers, so we can know how much is less? :) Thank you.

You might laugh, but here are the differences :)

800K ./build_dir/target-mipsel_24kc_musl/libgcrypt-1.10.3/ipkg-mipsel_24kc/libgcrypt/usr/lib/libgcrypt.so.20.4.3
584K ./build_dir/target-mipsel_24kc_musl/libgcrypt-mini/libgcrypt-1.10.3/.pkgdir/libgcrypt-mini/usr/lib/libgcrypt.so.20.4.3

On routers with tiny flash memory, this difference is enough to enable a few more small packages to be installed alongside :) :)

Neustradamus · 2024-12-31T16:12:17Z

A mini build will be nice.

jschwartzenberg · 2024-12-31T17:43:14Z

Yeah, but I think it is indeed a good idea to see which algorithms contribute the most and see if a good compromise can be found. Now it's indeed only the crappy ones that vpnc uses. I hope I can find a moment to experiment building various libgcrypt versions and see how much space they take up.

jschwartzenberg · 2025-02-01T18:05:22Z

I've been doing various builds and looked what trying to reduce the size while still keeping more algorithms. A build including everything is 1307kB (for the shared object itself). By reducing the number of algorithms we can reach about 650kB.

We could possible have three versions: mini, regular (excluding rarely used algorithms) and full

A mini version could be built with: --enable-ciphers='arcfour,des,aes,rfc2268,idea' --enable-pubkey-ciphers='ecc' --enable-digests='gostr3411-94,md4,md5,sha1,blake2' --enable-kdfs='s2k,pkdf2,scrypt'

This adds about 10kB but includes quite a few more algorithms, the result is 659kB.

The normal build might be: --enable-ciphers='arcfour,blowfish,des,aes,rfc2268,seed,salsa20,idea' --enable-pubkey-ciphers='rsa,ecc' --enable-digests='gostr3411-94,md4,md5,rmd160,sha1,blake2' --enable-kdfs='s2k,pkdf2,scrypt'

This results in 728kB, about 60kB larger.

Or with the SHAs added: --enable-ciphers='arcfour,blowfish,des,aes,rfc2268,seed,salsa20,idea' --enable-pubkey-ciphers='rsa,ecc' --enable-digests='gostr3411-94,md4,md5,rmd160,sha1,sha256,sha3,blake2' --enable-kdfs='s2k,pkdf2,scrypt'

This results in 780kB, about 52kB extra (on top of the 60Kb).

Here is a list of sizes based on what's included. Note that is this is quite a rough measurement:

s2k,pkdf2 do not add anything
scrypt adds about 4kB

rsa adds 20kB
elgamal adds 8kB
dsa adds 16kB

arcfour adds about 200 bytes
blowfish adds about 20kB
cast5 adds about 24kB
twofish adds about 49kB
serpent adds about 101kB
rfc2268 adds about 5kB
seed adds about 12kB
camellia adds about 143kB
salsa20 adds about 18kB
gost28147 adds about 41kB
chacha20 adds about 20kB
idea adds about 5kB
sm4 adds about 21kB

crc adds about 12kB
gostr3411-94 adds nothing
md4 adds about 4kB
rmd160 adds about 18kB
sha256 adds about 28kB
sha3 adds about 24kB
sm3 adds about 24kB
stribog adds about 20kB
tiger adds about 12kB
whirlpool adds about 20kB

Especially serpent and camellia increase the size significantly. When I leave out serpent, camellia and gost28147. There are already significant savings of almost 300kB, the result being 1013kB.

Maybe somebody could comment which algorithms are really must-haves and which ones could probably be dropped. This might also relate to which tools actually make user of libgcrypt on OpenWRT I guess.

jschwartzenberg · 2025-02-02T12:44:33Z

I went through all the other reverse dependencies of libgcrypt and checked which algorithms they actually use:

crun: prior version was using GCRY_MD_SHA256, dropped
collectd: GCRY_MD_SHA256, GCRY_MD_SHA1, GCRY_CIPHER_AES256
gnupg2: GCRY_MD_MD5, GCRY_MD_SHA1, GCRY_MD_SHA224, GCRY_MD_SHA256, GCRY_MD_SHA384, GCRY_MD_SHA512, GCRY_MD_RMD160, GCRY_MD_SHA3_*, GCRY_PK_RSA*, GCRY_PK_DSA, GCRY_PK_ELG*, GCRY_PK_ECC, GCRY_PK_ECDSA, GCRY_PK_EDDSA, GCRY_PK_ECC, GCRY_CIPHER_AES*, GCRY_CIPHER_SECURE, GCRY_CIPHER_IDEA, GCRY_CIPHER_3DES, GCRY_CIPHER_CAST5, GCRY_CIPHER_BLOWFISH, GCRY_CIPHER_TWOFISH, GCRY_MD_MD2, GCRY_MD_MD4, GCRY_MD_TIGER, GCRY_MD_HAVAL, GCRY_MD_SM3, GCRY_CIPHER_SERPENT*, GCRY_CIPHER_SEED, GCRY_CIPHER_CAMELLIA*, GCRY_MD_WHIRLPOOL
ntfs-3g: GCRY_MD_MD5, GCRY_CIPHER_DES, GCRY_CIPHER_3DES, GCRY_CIPHER_AES256
aircrack-ng: GCRY_MD_MD5, GCRY_CIPHER_ARCFOUR, GCRY_CIPHER_AES, GCRY_MD_SHA1, GCRY_MD_SHA256, GCRY_MAC_CMAC_AES
netifyd: can't find any GCRY_ references in the source at all?
netatalk: GCRY_CIPHER_DES
uanytun: GCRY_MD_SHA256, GCRY_MD_SHA1, GCRY_CIPHER_AES*
dawn: GCRY_CIPHER_AES128
aria2: GCRY_CIPHER_ARCFOUR, GCRY_MD_MD5, GCRY_MD_SHA1, GCRY_MD_SHA224, GCRY_MD_SHA256, GCRY_MD_SHA384, GCRY_MD_SHA512
gnunet: GCRY_MD_SHA512, GCRY_MD_SHA256, GCRY_CIPHER_AES256, GCRY_MD_SHA1
strongswan: GCRY_CIPHER_CAMELLIA128, GCRY_MD_MD2, GCRY_MD_MD4, GCRY_MD_MD5, GCRY_MD_SHA1, GCRY_MD_SHA224, GCRY_MD_SHA256, GCRY_MD_SHA384, GCRY_MD_SHA512, GCRY_CIPHER_DES, GCRY_CIPHER_3DES, GCRY_CIPHER_CAST5, GCRY_CIPHER_BLOWFISH, GCRY_CIPHER_AES*, GCRY_CIPHER_SERPENT*, GCRY_CIPHER_TWOFISH*
libndpi: GCRY_CIPHER_AES*, GCRY_MD_SHA256
elektra: GCRY_KDF_PBKDF2, GCRY_MD_SHA512, GCRY_CIPHER_AES256
libgabe: GCRY_MD_SHA512
pianod: GCRY_CIPHER_BLOWFISH, 
owntone: GCRY_MD_MD5, GCRY_MD_SHA1, GCRY_MD_SHA224, GCRY_MD_SHA256, GCRY_MD_SHA384, GCRY_MD_SHA512, GCRY_CIPHER_AES128, GCRY_CIPHER_CHACHA20, GCRY_MAC_HMAC_SHA1, 
shairport-sync: GCRY_MD_SHA1, GCRY_MD_SHA224, GCRY_MD_SHA256, GCRY_MD_SHA384, GCRY_MD_SHA512, GCRY_CIPHER_AES12, GCRY_CIPHER_CHACHA20

So it appears a few algorithms aren't used by any package at all. And there is a subset that is used by almost all. The heavy users are gnupg2 and strongswan.

What about creating a libgcrypt-full package that's used only be gnupg2 and strongswan and trimming the regular package to just contain the algorithms used by the others?

jschwartzenberg · 2025-02-02T12:59:00Z

Building with --enable-ciphers='arcfour,blowfish,des,aes,chacha20' --enable-digests='md5,sha1,sha256,sha512,sha3,blake2' --enable-kdfs='pkdf2' --enable-pubkey-ciphers='ecc' results in a binary of just 783kB that could handle everything except gnupg2 and strongswan.

@flyn-org does this set of algorithms make more sense? Curious what you think!

flyn-org · 2025-02-02T16:24:58Z

That list looks okay. It does include some algorithms that should be considered obsolete, including arcfour, des, md5, and sha1. (I am unsure of the status of blowfish.) The technologies that depend on those algorithms do so because of old requirements; netatalk is an example of this. Obviously, aircrack-ng includes arcfour so it can crack networks that use RC4. It might be a good idea to audit all of our packages to avoid obsolete ciphers and hashes, but that would be a separate effort. Aside from that, the list seems reasonable if it is indeed based on the real needs of the other packages.

I'd defer to some core developers as to whether this is a worthwhile goal. @BKPepe, what do you think?

openwrt · 2026-07-05T09:25:37Z

Formality Check: Suggestions Available

We completed the verification flow. Please review the formatting overview logs below.

⚠️ STYLISTIC WARNINGS & SUGGESTIONS

Package Release Audit:

⚠️ Package admin/freeipmi content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package libs/libgcrypt content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package libs/libndpi content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package net/aircrack-ng content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package net/aria2 content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package net/dawn content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package net/gnunet content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package net/netatalk content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package net/uanytun content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package net/vpnc content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package sound/owntone content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package sound/pianod content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package sound/shairport-sync content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package utils/collectd content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

⚠️ Package utils/crun content changed without a PKG_RELEASE or version bump

Do not increment release for minor changes. Cosmetic edits (e.g., typos in comments, copyright updates, formatting/whitespace), changing the package maintainer (PKG_MAINTAINER), or updating source download info (PKG_SOURCE_URL / PKG_HASH) do not require incrementing PKG_RELEASE.

_{Something broken? Consider reporting an issue.}
_{Running version 4ca9b59 deployed on 2026-07-20 07:30:15 CEST}

openwrt-ai

Reviewed 1 new commit. See inline comments.

Generated by Claude Code

openwrt-ai · 2026-07-10T15:50:51Z

+endef
+
+define Package/libgcrypt/description
+$(call Package/libgcrypt/Default/description)


The template is defined as Package/libgcrypt/default/description (lowercase default, line 37), but this calls Package/libgcrypt/**Default**/description. Make variable names are case-sensitive, so $(call ...) here expands to nothing and the full package description loses its entire body text (only the two trailing lines below survive).

Suggested change

$(call Package/libgcrypt/Default/description)

$(call Package/libgcrypt/default/description)

Generated by Claude Code

openwrt-ai · 2026-07-10T15:50:53Z

+endef
+
+define Package/libgcrypt-mini/description
+$(call Package/libgcrypt/Default/description)


Same case mismatch as above: the template is Package/libgcrypt/default/description (line 37), so Package/libgcrypt/**Default**/description expands to empty and the mini package description body is dropped.

Suggested change

$(call Package/libgcrypt/Default/description)

$(call Package/libgcrypt/default/description)

Generated by Claude Code

openwrt-ai · 2026-07-10T15:50:59Z

+define Package/libgcrypt
+  $(call Package/libgcrypt/default)
+  PROVIDES+=libgcrypt-mini
+endef
+
+define Package/libgcrypt/description
+$(call Package/libgcrypt/Default/description)
+ .
+ This package contains the full-featured libgcrypt.
+endef
+
+define Package/libgcrypt-mini


libgcrypt and libgcrypt-mini both PROVIDES libgcrypt and both install the same file (Package/libgcrypt-mini/install = $(Package/libgcrypt/install) copies /usr/lib/libgcrypt.so.*), yet neither declares CONFLICTS. Nothing prevents both from being selected/installed, which would collide on that file path.

Compare the canonical multi-variant library in openwrt/openwrt, package/libs/ustream-ssl/Makefile: each variant sets VARIANT, the variants CONFLICTS each other, and one carries DEFAULT_VARIANT:=1. Here the full package sets neither VARIANT nor DEFAULT_VARIANT, and no CONFLICTS is declared on either side. Consider adding CONFLICTS (and a DEFAULT_VARIANT) so the two cannot be co-installed and a default is well-defined.

Generated by Claude Code

jschwartzenberg · 2026-07-18T23:16:05Z

I updated the commit to reflect the proposal from last year. I also updated the packages that only need the mini variant that I could determine. I could also make the regular variant the smaller one introduce a big or large variant instead.

jschwartzenberg · 2026-07-18T23:20:40Z

I again see the note to do indentation with two spaces on lines that have tabs. Please let it know if I should do something there.

openwrt-ai

Commit checks

libgcrypt: introduce mini and full variants — the message states two new variants (mini and full) are introduced and that "the full variant contains everything", but libgcrypt-full is defined without a BuildPackage call, a full configure branch, or an install recipe, so it is never built. Only the regular and mini variants are actually produced (see inline comment).

Generated by Claude Code

openwrt-ai · 2026-07-19T06:14:58Z

+	--enable-ciphers='arcfour,blowfish,des,aes,chacha20,rsa,dsa' \
+	--enable-pubkey-ciphers='ecc,cast5,twofish,serpent,seed,camellia,idea' \


The two lists are swapped in the regular variant. rsa and dsa are public-key algorithms (they belong under --enable-pubkey-ciphers), while cast5, twofish, serpent, seed, camellia and idea are symmetric ciphers (they belong under --enable-ciphers). libgcrypt's configure validates each name against its category, so as written the regular build ends up without these algorithms — and configure may abort on the unsupported names. Since the regular variant is meant to be the superset used by packages that still depend on +libgcrypt (e.g. strongswan, gnupg2, which need camellia/serpent/twofish), this would break them. The mini block below has the categories right.

Suggested change

--enable-ciphers='arcfour,blowfish,des,aes,chacha20,rsa,dsa' \

--enable-pubkey-ciphers='ecc,cast5,twofish,serpent,seed,camellia,idea' \

--enable-ciphers='arcfour,blowfish,cast5,des,aes,twofish,serpent,seed,camellia,idea,chacha20' \

--enable-pubkey-ciphers='ecc,rsa,dsa' \

Generated by Claude Code

Whoops, that's indeed quite silly of me. Coding at night was a bad idea. I just pushed a new version with all the remarks addressed I think.

openwrt-ai · 2026-07-19T06:15:07Z

+Package/libgcrypt-mini/install = $(Package/libgcrypt/install)
+
 $(eval $(call BuildPackage,libgcrypt))
+$(eval $(call BuildPackage,libgcrypt-mini))


The full variant is never actually built or selectable. Package/libgcrypt-full and its description are defined (lines 61-67, 76-82) with VARIANT:=full, but there is no $(eval $(call BuildPackage,libgcrypt-full)) here, no ifeq ($(BUILD_VARIANT),full) configure branch above, and no Package/libgcrypt-full/install. As a result the commit message's claim that this "introduces two new variants ... mini and full" and that "the full variant contains everything" does not hold — only libgcrypt (regular) and libgcrypt-mini are produced. To ship it you'd need to add all three: a full configure branch (or intentionally none, to enable every algorithm), a Package/libgcrypt-full/install (e.g. Package/libgcrypt-full/install = $(Package/libgcrypt/install)), and the BuildPackage line.

Generated by Claude Code

openwrt-ai · 2026-07-19T06:15:15Z

+$(call Package/libgcrypt/default/description)
+ .
+ This package contains the regular libgcrypt build.
+ Algorithms not used by other OpenWrt packages are excluded.


This is what the failing FormalityCheck / OpenWrt Makefiles run is reporting: description lines must be indented with at least 2 spaces, but these (including the $(call ...) line) use 0-1 space. Indenting the block fixes it:

Suggested change

$(call Package/libgcrypt/default/description)

.

This package contains the regular libgcrypt build.

Algorithms not used by other OpenWrt packages are excluded.

$(call Package/libgcrypt/default/description)

.

This package contains the regular libgcrypt build.

Algorithms not used by other OpenWrt packages are excluded.

Apply the same 2-space indentation to the Package/libgcrypt-full/description block (lines 77-81) and the Package/libgcrypt-mini/description block (lines 85-88), which the check flags for the same reason.

Generated by Claude Code

openwrt-ai

Commit checks

libgcrypt: introduce mini and full variants — the previous review's swapped cipher/pubkey lists, description indentation, and CONFLICTS/DEFAULT_VARIANT concerns are resolved. However, the message still states "the full variant contains everything," and while $(eval $(call BuildPackage,libgcrypt-full)) was added, libgcrypt-full has no install section, so it is skipped at build time and no libgcrypt-full package is actually produced (see inline comment).

Generated by Claude Code

openwrt-ai · 2026-07-20T06:16:32Z

 	$(CP) $(PKG_INSTALL_DIR)/usr/lib/libgcrypt.so.* $(1)/usr/lib/
 endef

+Package/libgcrypt-mini/install = $(Package/libgcrypt/install)


The added BuildPackage,libgcrypt-full (line 134) still won't produce a package: unlike -mini on this line, Package/libgcrypt-full/install is never defined and there is no -overlay variant, so the build system treats the variant as having no install section. In include/package-pack.mk an undefined Package/$(1)/install leaves do_install unset and the package is skipped at compile time (WARNING: skipping libgcrypt-full -- package has no install section). Because libgcrypt-full also PROVIDES libgcrypt, this is worse than a no-op if it were ever selectable: it would satisfy the libgcrypt dependency while installing no library. Add an install recipe mirroring -mini:

Suggested change

Package/libgcrypt-mini/install = $(Package/libgcrypt/install)

Package/libgcrypt-full/install = $(Package/libgcrypt/install)

Package/libgcrypt-mini/install = $(Package/libgcrypt/install)

Generated by Claude Code

Should be fixed now!

This introduces two new variants of libgcrypt. The full variant contains everything which is more than is actually used by any OpenWrt package. The regular variant is changed to only contain algorithms that are in use. The mini variant contains the most commonly used algorithms and is significantly smaller than the regular variant. Signed-off-by: Julius Schwartzenberg <julius.schwartzenberg@eclipso.eu>

jschwartzenberg force-pushed the feature/gcrypt-mini branch from da87dbe to 538da0a Compare December 25, 2024 10:32

BKPepe force-pushed the feature/gcrypt-mini branch from 538da0a to 2060fe7 Compare June 15, 2025 09:34

BKPepe force-pushed the feature/gcrypt-mini branch from 2060fe7 to a352645 Compare July 19, 2025 19:39

BKPepe force-pushed the feature/gcrypt-mini branch from a352645 to beed3af Compare July 5, 2026 09:25

openwrt Bot added the not following guidelines label Jul 5, 2026

openwrt-ai reviewed Jul 10, 2026

View reviewed changes

jschwartzenberg force-pushed the feature/gcrypt-mini branch 3 times, most recently from bc50b9b to f574936 Compare July 18, 2026 23:14

openwrt-ai reviewed Jul 19, 2026

View reviewed changes

jschwartzenberg force-pushed the feature/gcrypt-mini branch from f574936 to 21d50e6 Compare July 19, 2026 07:32

openwrt Bot removed the not following guidelines label Jul 19, 2026

openwrt-ai reviewed Jul 20, 2026

View reviewed changes

jschwartzenberg force-pushed the feature/gcrypt-mini branch from 21d50e6 to 3561226 Compare July 20, 2026 10:52

	$(call Package/libgcrypt/Default/description)
	$(call Package/libgcrypt/default/description)

		--enable-ciphers='arcfour,blowfish,des,aes,chacha20,rsa,dsa' \
		--enable-pubkey-ciphers='ecc,cast5,twofish,serpent,seed,camellia,idea' \

	Package/libgcrypt-mini/install = $(Package/libgcrypt/install)
	Package/libgcrypt-full/install = $(Package/libgcrypt/install)
	Package/libgcrypt-mini/install = $(Package/libgcrypt/install)

Uh oh!

Conversation

jschwartzenberg commented Dec 23, 2024

Uh oh!

flyn-org commented Dec 23, 2024

Uh oh!

jschwartzenberg commented Dec 23, 2024

Uh oh!

BKPepe commented Dec 23, 2024

Uh oh!

jschwartzenberg commented Dec 23, 2024

Uh oh!

Neustradamus commented Dec 31, 2024

Uh oh!

jschwartzenberg commented Dec 31, 2024

Uh oh!

jschwartzenberg commented Feb 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jschwartzenberg commented Feb 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jschwartzenberg commented Feb 2, 2025

Uh oh!

flyn-org commented Feb 2, 2025

Uh oh!

openwrt Bot commented Jul 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Formality Check: Suggestions Available

⚠️ STYLISTIC WARNINGS & SUGGESTIONS

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jschwartzenberg commented Jul 18, 2026

Uh oh!

jschwartzenberg commented Jul 18, 2026

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Commit checks

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

openwrt-ai left a comment

Choose a reason for hiding this comment

Commit checks

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jschwartzenberg commented Feb 1, 2025 •

edited

Loading

jschwartzenberg commented Feb 2, 2025 •

edited

Loading

openwrt Bot commented Jul 5, 2026 •

edited

Loading