Replace criteo/haproxy-spoe-go with negasus/haproxy-spoe-go about coraza-spoa HOT 10 OPEN

Sounds reasonable to me.

from coraza-spoa.

Up for a PR? @mac-chaffee

from coraza-spoa.

Still a work a progress. It's turning out to be a bigger lift than expected, but I think it'll be worth it

from coraza-spoa.

@mac-chaffee
since you have experience with both - https://github.com/criteo/haproxy-spoe-go and https://github.com/negasus/haproxy-spoe-go - which one do you recommend one should use? We are planning to invest heavily in building SPOAs in golang. So, would be great to learn from your experience.

from coraza-spoa.

Hey all, just to add to @15ljindal message we also looking into to create a spoe implementation for Crowdsec. Saw the lib you was using and that the question arose of the maintainer.

Any feedback you can give will help. Thank you for the awesome work!

from coraza-spoa.

I hit a wall with implementing this issue, mostly due to my own weak Golang skills but also due to other issues in this repo that might make sense to tackle in parallel (like config management, logging, and graceful config loading, which all touch the same pieces of code that this issue would touch). Also been busy at my job where our project to migrate to coraza has been pushed down the priority list in favor of more pressing things, so sorry about that!

I believe @sts had been considering looking into this issue.

About the two libraries, the criteo one is definitely rougher around the edges. The public interface is quite sparse, test coverage isn't great, and there is essentially no way to construct a SPOE message without having a raw byte array, which makes testing difficult.

The negasus one appears slightly better in every way (albeit also not having recent activity). One problem I was hitting was that parsing SPOE messages requires a clever use of the type system. The negasus library spits out interface{} types frequently, so you have to attempt to cast them to the real type and catch any errors, leading to super long chains like this: mac-chaffee@d62c0f5#diff-3ab3bdb7d0f005db3d881dcea88f3b5aa71bfce1e457bd2ddbaf26500eb14ba4R115

Which is not much better than what we have now with the criteo library:

Maybe a more skilled golang user could find a better solution.

PS: I don't mean to denigrate either criteo or negasus. I greatly appreciate both your work!

from coraza-spoa.

Because of all these different approaches with either different api quality and/or speed, I reimplemented it with a zeroalloc hotpath. I will add some examples for e.g. a L7 Client validation and probably move it to a different Github Org soonish. If there are any requests for changes/additions feel free to ping me.

Its still not versioned or has a stable API as I first want to have some examples and tests added but it does already work fairly well
https://github.com/fionera/haproxy-go/blob/master/spop

from coraza-spoa.

@fionera thanks for coming by. My 2p on this matter, not as a coraza maintainer but more like an open source person is that a good way to get your library right to exercise the API with a good use case that verify the assumptions in your abstractions. Coraza is indeed a good use case and if you wanna give it a try to a coraza connector using your library we will be more than happy to help review and answer doubts. I also opened a couple of issues in your repo with general practices.

from coraza-spoa.

I think I will give it a try and make a PR porting coraza-spoa to my library :)

from coraza-spoa.

We seem to have encountered a memory leak with haproxy-spoe-go. Managed to reference the wrong lib.. negasus/haproxy-spoe-go#18

Any updates on replacing criteo/haproxy-spoe-go with negasus/haproxy-spoe-go? The criteo/haproxy-spoe-go project seems less active in comparison.

from coraza-spoa.