Deimos binding to libsodium xor wrapper
To use this package, run the following command in your project's root directory:
Put the following dependency into your project's dependences section:
Twofold binding to libsodium, a modern, portable, easy to use crypto library; support of current libsodium version v1.0.18, released May 31, 2019.
deimos: The "import-only" C header's declarations.
wrapper: The content of
deimos + some 'D-friendly' stuff, predominantly overloaded functions and unittests.
The dependency name is either
sodium:wrapper (for dub build|test simply:
If not linking against v1.0.18 binary libsodium.so/.dll/.dylib, it's required to specify that in deimos/dub.json and wrapper/dub.json:
In the past while I maintained this binding, it was kind of independent from binary libsodium versions: The last binding release supporting headers of libsodium 1.016 could be used with a binary versioned e.g. 1.014 or 1.018, because in C headers (so far) only functions where added, and the compiler/linker would complain, if (new) functions not available from the (older) binary/import library should be called. This also holds for Windows, if You don't trick the compiler with a non-associated pair of import .lib/binary .dll.
Now for the first time (since v1.0.17 and again in 1.0.18) a constant changed it's value as well as a struct size change occured and the easy times are gone.
This is solved by conditional compilation, which is guided by the following version identifiers: binv1018, binv1017 and binv1016 (binv1016 subsumes any libsodium binary version lower than v1.0.16 as well). The dub.json s set binv10_18 as default, stating the binary version expected to link against.
A version mismatch of binding-adaption and libsodium binary can do any harm as undefined behavior can do, like memory corruption or worse, a SIGSEGV in the best case.
(The versioning of this binding doesn't matter here, but to make things more intuitive, it'll change to reflect the latest (libsodium C source) header version covered, the next/this will be something like 1.0.18-alpha.1).
wrapper is based on DIP1008/compiler switch -dip1008; this rules out the gdc compiler currently (I didn't find any info about that). dmd/ldc support it since 2.078.3.
DIP1008 is the enabling feature used for @nogc exceptions, implemented via dependency package nogc.
wrapper also supports usage of -dip1000 (includes -dip25). dub build|test :wrapper --config=travis uses that but it's not set as default for any other configuration.
wrapper aims at providing at least the same functionality as
deimos and provide @trusted @nogc (possibly also pure nothrow) 'D-friendly' alternatives, that are hard to use in a wrong way; [WIP]:
a) 'wrapper' is a superset of 'deimos' in that everything from 'deimos' is reachable, but deliberately not all at your fingertips.
b) all new functions with 'deimos-functionality' have the same name as their 'deimos'-cousins and call them, building either overload sets to choose from, or for parameter-less functions, 'substituting' their cousins.
c) all new functions calculating a variable-length output are restrictive referring to the size of the output-buffer offered, if the required size can be easily known/computed in advance, throwing (a NoGcException) in case of wrong-sized buffers.
This way, if a function succeeds, all output-buffer.length bytes are meaningful and no additional/'deimos'-like function out parameter carrying the meaningful length information is required.
d) Exceptions thrown while checking valid function arguments are NOT allocated by GC, enabling @nobc attribue usage.
e) No need to explicitely call sodiuminit() up-front (wrapper.sodium.core:shared static this() calls it).
f) A few functions with int return type expressing true or false have bool return type in 'wrapper'. g) Usage of 'wrapper' isn't possible, if function `randombytesset_implementation` shall be used.
The unittests of subPackage 'wrapper' include a lot of function usage examples; the next is a simple application example, using rdmd and file cmdfile,
suitable as is for Linux with libsodium.so available (otherwise example/source/cmdfile and/or first line of app.d might need adaption):
$ cd example/source && chmod +x app.d && ./app.d
Expected output (byte values within brackets differing of course):
Unpredictable sequence of 8 bytes: [52, 225, 21, 245, 74, 66, 192, 247] crypto_aead_aes256gcm_is_available ciphertext: [76, 18, 112, 219, 144, 230, 206, 219, 40, 255, 78, 43, 172, 49, 129, 175, 4, 235, 81, 224]
Quoting the Sodium-manual: "Cryptographic operations in Sodium (C binary) never allocate memory on the heap (malloc, calloc, etc.) with the obvious exceptions of cryptopwhash and sodiummalloc."
The same holds, if usage is restricted to sodium:deimos and also holds for many (@nogc) functions of sodium:wrapper.
- Registered by Carsten Blüggel
- 1.0.18-alpha.2 released 4 years ago
- ISC license
- Copyright © 2017-, Carsten Blüggel
- Sub packages:
- sodium:deimos, sodium:wrapper
- sodium:deimos, sodium:wrapper
1.0.18-alpha.5 2019-Jun-07 1.0.18-alpha.4 2019-Jun-06 1.0.18-alpha.3 2019-Jun-06 1.0.18-alpha.2 2019-Jun-05 1.0.18-alpha.1 2019-Jun-03
- Download Stats:
0 downloads today
0 downloads this week
0 downloads this month
1200 downloads total
- Short URL: