Possibility of merging projects?

[martinjungblut]

Hi @anatol, how are you doing?

Following my post and your comment on Reddit (https://www.reddit.com/r/golang/comments/nwtgtn/go_bindings_for_libcryptsetup_luks/), I have a question:

Would you consider merging our projects?
They're both well maintained, and have similar goals.

Thanks,
Martin

[anatol]

Hi @martinjungblut, sorry for the delay.

merging these projects sounds like a great idea. At the end of the day they both try to provide a cryptsetup functionality for Golang users.

luks.go idea is to avoid any external *.so deps and rather try to get this functionality with pure Go. So I wonder if it is something that aligns with go-cryptsetup library vision.

[martinjungblut]

Hi @anatol, thanks for the reply!

I wasn't aware you were trying to avoid shared libraries altogether. That's both cool, and a bit challenging (I think).
Out of curiosity, how does luks.go maintain compatibility with upstream cryptsetup?

My original thought when creating go-cryptsetup was to be a wrapper around the upstream library. Relying on the shared objects isn't perfect for every scenario, for sure. I just thought it would be easy to ensure some consistency with the upstream developers (leveraging their code, performing integration tests, and ensuring it builds against their library, using multiple versions).

[martinjungblut]

Hi @anatol, I just had an idea regarding this.

Have you considered statically linking, so there are no runtime dependencies on shared libraries?

Thanks

[aep]

Have you considered statically linking, so there are no runtime dependencies on shared libraries?

this seems unfeasible. it needs lvm2 which has a memory allocator that depends on being loaded as dl
also it has to be compiled against kernel headers

[aep]

turns out its possible. https://gist.github.com/aep/ef25923766f4a1fedcc6c9ff09fa5079

but it's a giant PITA and adds GPL infections, so we'll probably instead contribute to this library.