Replace criteo/haproxy-spoe-go with negasus/haproxy-spoe-go

[mac-chaffee]

The library that we use to speak SPOP appears to be unmaintained: criteo/haproxy-spoe-go#37

It also has a small public API and lack of interfaces that makes testing our code extremely difficult. For example, there's no way to construct our own spoe.Message in Go; you need to give it a real byte array. I hit this issue when trying to add some unit tests to coraza-spoa.

There is another more-active library Stefan found that I think we should use: https://github.com/negasus/haproxy-spoe-go

I'm about 50% done with a proof of concept PR to complete this. Just thought I'd file a tracking ticket.

[jcchavezs]

Sounds reasonable to me.

[jcchavezs]

Up for a PR? @mac-chaffee

[mac-chaffee]

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

[15ljindal]

@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.

[LaurenceJJones]

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!

[mac-chaffee]

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: https://github.com/mac-chaffee/coraza-spoa/commit/d62c0f5dac6d3495eb21a5fdea25b41f485cccd8#diff-3ab3bdb7d0f005db3d881dcea88f3b5aa71bfce1e457bd2ddbaf26500eb14ba4R115

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

coraza-spoa/internal/request.go

Line 71 in d615d83

case "src-ip":

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!

[fionera]

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

[jcchavezs]

@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.

[fionera]

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

[devasmith]

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.

[superstes]

As reference: #103