| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
We’re not currently using any other part of BoringSSL, so don’t waste
time building anything else.
|
| |
|
|
|
|
|
| |
https://boringssl.googlesource.com/boringssl/+/03de6813d8992a649092b4874ef0ebc022e2f58a
means BoringSSL now by default includes relocations that don't play well
with shared libraries. Make `cabal build --enable-shared` work again by
building all BoringSSL code as PIC.
|
| |
|
|
|
|
| |
I don’t always like the output hindent gives, so reformat the project
to be a bit closer to what you see in published Haskell books and the
like.
|
| |
|
|
|
|
|
|
|
|
| |
Let the computer figure out its own types for most foreign imports.
Continue using the vanilla FFI for finalizers, though, as that’s the
easiest way to deal with function pointers.
Reuse the build hook from gtk2hs-buildtools to work around Cabal’s
inability to topologically sort .chs dependencies
(https://github.com/haskell/cabal/issues/1906).
|
| | |
|
|
|
So far, btls provides SHA-224, SHA-256, SHA-384, and SHA-512 algorithms.
To do that, I
- vendor BoringSSL and create a custom `Setup.hs` to build it,
- wrap a number of functions and values from BoringSSL's EVP
subsystem, and
- implement the four SHA-2 algorithms using the wrapped routines.
I provide conformance tests incorporating the official NIST example
vectors and the vectors used in the Go SHA-2 test suite. The tests also
use SmallCheck to compare btls’s SHA-2 implementations with those
provided by the system’s Coreutils and openssl(1) installations.
|
Benjamin Barenblat