This work finalizes how this project works ( fixes https://github.com/customink/crypteia/issues/4 ) by connecting a shared data structure between the shared object library and the binary extension. I kept it simple for now with a short lived ( few milliseconds ) temp file. When I get a little better at Rust I think I'll use a simple unix domain socket.
This work also (fixes https://github.com/customink/crypteia/issues/12 ) which was not really a problem, but more so thinking I could stretch the x86_64-unknown-linux-musl target too far. What is that? I'm no Rust expert but in general our dependency redhook will need glibc and in the case of Lambda which is Amazon Linux 2 we need to compile on that platform specifically so the final binary and library use the older version correctly. This means our base build on the debian can be used on pretty much any other linux including Ubuntu. And the amzn build target in our build dir will be for any Amazon Linux including Lambda. After this pull request, I will introduce a GitHub Action that does release files and updated README instructions for installation.
Other Details
The way the Lambda Runtime work, all extensions initialize prior to the Runtime. This is how LD_PRELOAD even works. But it also means that our defensive checks the shared object library should never run file checks or reads for the data. That said, the shared library file is pretty aggressive in being HIGHLY performant using an AtomicBool flag and lazy shared data structures that only kick in when access x-crpyteia ENV vars.
New amzn folder for all things Amazon Linux to do. Thanks Codespaces Docker in Docker!!! 🐢🐢🐢
Leverage the latest NodeJS v16 SAM build image with Rust installed as our builder.
Do an aggressive integration test with a base Lambda NodeJS runtime image by copying build artifacts over and testing.
Will use CRYPTEIA_DEBUG when I do some final integration tests to confirm behavior.
This work finalizes how this project works ( fixes https://github.com/customink/crypteia/issues/4 ) by connecting a shared data structure between the shared object library and the binary extension. I kept it simple for now with a short lived ( few milliseconds ) temp file. When I get a little better at Rust I think I'll use a simple unix domain socket.
This work also (fixes https://github.com/customink/crypteia/issues/12 ) which was not really a problem, but more so thinking I could stretch the
x86_64-unknown-linux-musltarget too far. What is that? I'm no Rust expert but in general our dependency redhook will need glibc and in the case of Lambda which is Amazon Linux 2 we need to compile on that platform specifically so the final binary and library use the older version correctly. This means our base build on thedebiancan be used on pretty much any other linux including Ubuntu. And theamznbuild target in ourbuilddir will be for any Amazon Linux including Lambda. After this pull request, I will introduce a GitHub Action that does release files and updated README instructions for installation.Other Details
The way the Lambda Runtime work, all extensions initialize prior to the Runtime. This is how LD_PRELOAD even works. But it also means that our defensive checks the shared object library should never run file checks or reads for the data. That said, the shared library file is pretty aggressive in being HIGHLY performant using an
AtomicBoolflag and lazy shared data structures that only kick in when accessx-crpyteiaENV vars.amznfolder for all things Amazon Linux to do. Thanks Codespaces Docker in Docker!!! 🐢🐢🐢CRYPTEIA_DEBUGwhen I do some final integration tests to confirm behavior.