Alternative idea, what about instead of writing a wrapper:
1. look at https://packages.ubuntu.com/noble/libnet-ssleay-perl
a. libnet-ssleay-perl is in main
2. add eddsa-25519 to the list of constants upstream
a. if i'm reading correctly, there's a mapping in a helper_scripts/constants.txt that contains a list of all algorithms, that is then used to autgen C and perl bindings. if libssl or libgrypt on the system already has eddsa-25519, it should "just work"
3. switch to using libnet-ssleay-perl for the backend of these calls
a. bonus, you could see if you could switch _everything_. it'd make sense to me...
I don't know if this ends up being a heavier or lighter lift. and it takes updating libnet-ssleay-perl upstream, but reading the list of constants, it could benefit from someone going through and fleshing out current libssl and libcrypt support.
Alternative idea, what about instead of writing a wrapper:
1. look at https:/ /packages. ubuntu. com/noble/ libnet- ssleay- perl scripts/ constants. txt that contains a list of all algorithms, that is then used to autgen C and perl bindings. if libssl or libgrypt on the system already has eddsa-25519, it should "just work"
a. libnet-ssleay-perl is in main
2. add eddsa-25519 to the list of constants upstream
a. if i'm reading correctly, there's a mapping in a helper_
3. switch to using libnet-ssleay-perl for the backend of these calls
a. bonus, you could see if you could switch _everything_. it'd make sense to me...
I don't know if this ends up being a heavier or lighter lift. and it takes updating libnet-ssleay-perl upstream, but reading the list of constants, it could benefit from someone going through and fleshing out current libssl and libcrypt support.