Skip to content

Add a with-crypto cabal flag to build Plinth/Plutus scripts without system crypto C libraries#7827

Open
zeme-wana wants to merge 4 commits into
masterfrom
with-crypto-flag
Open

Add a with-crypto cabal flag to build Plinth/Plutus scripts without system crypto C libraries#7827
zeme-wana wants to merge 4 commits into
masterfrom
with-crypto-flag

Conversation

@zeme-wana

Copy link
Copy Markdown
Collaborator

Problem
Compiling a Plinth script transitively pulls cardano-crypto-class, which forces the system C libraries libsodium/libblst/libsecp256k1 at cabal-solve time (cabal#4087).
Script authors must install these even though compiling a script never runs any crypto.

Change
New with-crypto flag on plutus-core (default on, mirrored on plutus-metatheory).
The 6 PlutusCore.Crypto.* modules are now CPP-gated:

Tests
New crypto-hash-parity-test: 114 goldens (6 hashes × 19 inputs, incl. block/padding edge cases) generated by the +with-crypto build (cardano-crypto-class) and reproduced byte-for-byte by the -with-crypto build (crypton), this ensures hash parity in CI.

Net effect
Default builds are unchanged; script authors can opt into a C-library-free toolchain with flags: -with-crypto.

@zeme-wana zeme-wana added the No Changelog Required Add this to skip the Changelog Check label Jul 1, 2026
@Unisay Unisay self-requested a review July 2, 2026 09:17
@SeungheonOh

SeungheonOh commented Jul 2, 2026

Copy link
Copy Markdown
Collaborator

I assume the main goal we want to achieve is being able to compile plutus-tx-plugin and plutus-ledger-api without the crypto c libraries. While this PR does allow that, I think the cleaner way is to separate the AST definitions from plutus-core(perhaps call it plutus-ast and to make plutus-tx-plugin and plutus-ledger-api only depend on plutus-ast which does not have any c crypto dependencies(or any dependencies really).

Doing it that way would allow us to achieve same thing without requiring cabal flags which I'd prefer.

Update:
Okay, seems like this approach is already been tried and is more difficult than I originally anticipated.

subgroup (that needs blst), so it is weaker than the real `blsUncompress`; but it
rejects the malformed inputs the real decoder rejects on structure alone, rather
than accepting anything. -}
checkCompressed :: Int -> BS.ByteString -> Either BLS12_381_Error BS.ByteString

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather not have this duplicate validation logic that's originally in the blst c library. \_ _ -> Left (CryptoDisabled :: BLS12_381_Error) would be sufficient

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

No Changelog Required Add this to skip the Changelog Check

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants