Juan Pablo Tosso 12:01:21 UTC
Hey! welcome to OWASP Coraza monthly meeting! you may check the topics here: corazawaf/coraza#180 This month we are discussing:
bxlxx.wu 12:02:20 UTC
Hi
ShiMing Q 12:02:51 UTC
Cheers!
airween 12:02:59 UTC
hey, with an half eye, I can be here... 😛
↳ Juan Pablo Tosso 12:03:25 UTC
Even your half eye would be useful 😜
Juan Pablo Tosso 12:04:27 UTC
Regarding the project status:
walter 12:06:16 UTC
nice work!
↳ Juan Pablo Tosso 12:06:40 UTC
thank you Walter
Juan Pablo Tosso 12:06:57 UTC
Any question about the project status or shall we move to the pending feb stuff?
walter 12:07:39 UTC
I haven’t followed closely but I am very interested in the Apache and Nginx integrations, could you tell a bit about their maturity?
Juan Pablo Tosso 12:08:25 UTC
Sure, we haven’t worked a lot on the apache integration but libcoraza is already working, but it still leaks some memory. @airween has done a great job testing it and building the autotooling with @fzipitria
walter 12:08:27 UTC
I’m currently busy designing Our Next Webserver Architecture® and I hope Coraza can play a role here 🙂
Juan Pablo Tosso 12:09:46 UTC
The nginx connector is basically a fork of the libmodsecurity connector. It is compiling, the autotooling is ready and we are missing some progress regarding the transaction intervention and logging. @fzipitria has taken care of it for the past few weeks. I would have expected students from GSOC to participate but it seems like there is not much interest
airween 12:10:33 UTC
I've already started to implement an ftwrunner like tool, but last 3-4 weeks were terrible in my job, so I hadn't do much time. But now I see the light at the end of the tunnel, so I hope in next few days I can work on it
Juan Pablo Tosso 12:11:33 UTC
Still, this is a core project in our roadmap, until we find a maintainer
airween 12:11:42 UTC
there is an important deadline of our important project, after that I can focused again for CRS/modsec tools
↳ Juan Pablo Tosso 12:12:07 UTC
Thank you Ervin, we are looking forward to it! Good luck on your important project
Juan Pablo Tosso 12:12:48 UTC
But most of the interest on Coraza has been through our HAProxy SPOA connector, which @bxlxx.wu has taken care of
Juan Pablo Tosso 12:14:04 UTC
Does it answer your concerns @walter?
walter 12:14:08 UTC
yes!
bxlxx.wu 12:14:30 UTC
I’ve finished most of coraza-spoa’s work and I’m testing it
Juan Pablo Tosso 12:14:55 UTC
great! thank you everyone, we are moving to the first feb pending issue
Juan Pablo Tosso 12:15:13 UTC
So the people from the zap project uses part of their budget to create issue bug bounties
Juan Pablo Tosso 12:15:56 UTC
so basically it seems legit for us to label some issues with a bounty label and gift a shirt, it’s doesn’t seem like much but it’s a great internal effort and it’s done with a lot of love
Juan Pablo Tosso 12:16:32 UTC
the average price for a coraza shirt with shipping is ~14USD
Juan Pablo Tosso 12:16:44 UTC
that will be payed with the coraza budget from sponsorships
fzipitria 12:17:08 UTC
Awesome
fzipitria 12:17:09 UTC
😄
Juan Pablo Tosso 12:17:11 UTC
some countries would be more expensive to ship
Juan Pablo Tosso 12:17:27 UTC
hey @fzipitria welcome!
ShiMing Q 12:17:27 UTC
👍
fzipitria 12:17:40 UTC
Hey! Was commuting, sorry :)
Juan Pablo Tosso 12:17:51 UTC
that’s ok, thank you for coming
Juan Pablo Tosso 12:19:07 UTC
So does everyone agree with the new shirt gifts? Some additional points
fzipitria 12:21:00 UTC
I would say we send them a form or similar after their PR is merged?
Juan Pablo Tosso 12:21:40 UTC
Ok, but how do we avoid other malicious users from filling the form in his name?
Juan Pablo Tosso 12:22:14 UTC
Nvm, we will solve this internally, it’s not a big deal
Juan Pablo Tosso 12:22:20 UTC
but do we all agree with the gifts?
bxlxx.wu 12:22:48 UTC
Are there any other options?
Juan Pablo Tosso 12:22:58 UTC
well, zap pays bounties in cash
Juan Pablo Tosso 12:23:26 UTC
we could only afford like 15~ issues paying 100 usd
bxlxx.wu 12:23:55 UTC
Maybe we can set a few more options for users to choose. After all, the express fee is a huge expense
Juan Pablo Tosso 12:24:46 UTC
maybe instead of a shirt, depending on the difficulty on the issue we could gift like a coraza kit: mug+shirt+stickers+etc
Juan Pablo Tosso 12:25:18 UTC
I’m not a fan of money, we are an open source project and we do everything for the community
Juan Pablo Tosso 12:25:40 UTC
https://printify.com/app/products here you can check the list of items for sale, everything can be personalized with the Coraza logo
fzipitria 12:26:12 UTC
We can circle back on this with options
Juan Pablo Tosso 12:26:29 UTC
ok, we will discuss it during the month, we have many other topics
fzipitria 12:26:32 UTC
Maybe someone wants just cash for amazon, or alibaba, or similar
Juan Pablo Tosso 12:26:48 UTC
seems fair
Juan Pablo Tosso 12:27:20 UTC
Regarding the project values, I would just keep them: Simplicity, extensibility, innovation, and community Anything you would add or remove?
JC 12:28:27 UTC
Simplicity, extensibility, innovation, maturity and community
Juan Pablo Tosso 12:28:47 UTC
could you elaborate on maturity @JC?
JC 12:31:38 UTC
I think one of the good things about coraza is that we not only want to be a port of modsec but include new features but good well proven features are already designed so we just need to reinforce that and provide other new features, in that sense I think we should be careful about what we include because we would have to maintain that for long, maybe “maturity” isn’t the right wording but being careful with what we introduce and how is key IMHO.
JC 12:32:04 UTC
Something that express that we won’t introduce things half baked.
Juan Pablo Tosso 12:32:38 UTC
you are right, we are innovative but we must be professional on how we propose new features
Juan Pablo Tosso 12:33:33 UTC
maybe something like “built with enterprise focus?”
Juan Pablo Tosso 12:33:53 UTC
@fzipitria any idea on a word we could use?
fzipitria 12:34:24 UTC
I would say that is part of what maturity covers
walter 12:34:34 UTC
yeah or maybe stability?
fzipitria 12:34:38 UTC
stability
Juan Pablo Tosso 12:34:48 UTC
@JC do you agree with the word stability?
JC 12:34:59 UTC
Yeah +1 on stability
Juan Pablo Tosso 12:35:10 UTC
great, stability it is
fzipitria 12:35:22 UTC
Awesome
Juan Pablo Tosso 12:35:25 UTC
any other comment on the project values so we can move to the next point?
Juan Pablo Tosso 12:35:58 UTC
Where to store coraza research: I think we should enforce the usage of the website, alternatives are confluence github wiki
Juan Pablo Tosso 12:36:38 UTC
Our website is basically a lot of markdown documents
Juan Pablo Tosso 12:37:34 UTC
Should we focus on the website?
fzipitria 12:38:04 UTC
Website for the win
fzipitria 12:38:13 UTC
It doesn’t make sense to add other tools
fzipitria 12:38:26 UTC
The website is easily editable. It is markdown.
fzipitria 12:38:37 UTC
We can include mermaid and other diagrams also
bxlxx.wu 12:38:55 UTC
use coraza.io?
Juan Pablo Tosso 12:38:57 UTC
Great, it seems we are keeping the website for it. It will be important that all developers are aware on how to update it, but it is super simple
Juan Pablo Tosso 12:38:58 UTC
yep
Juan Pablo Tosso 12:39:44 UTC
Great, let’s move
Juan Pablo Tosso 12:39:49 UTC
Side projects status:
Juan Pablo Tosso 12:40:44 UTC
Also, @bxlxx.wu suggested to split coraza-spoa from coraza-server, any comments on that?
Juan Pablo Tosso 12:40:57 UTC
and keep coraza-server only for GRPC and REST
Juan Pablo Tosso 12:41:19 UTC
to be honest, it’s fine to me to have them merged, that way we can share the configurations and deployment options
bxlxx.wu 12:41:23 UTC
I separate the HAProxy connector from the coraza-server. I think the coraza-server is a project with wider compatibility. It supports any middleware service. So, the spoa shouldn’t appear in the coraza-server.
fzipitria 12:43:13 UTC
I’m fine with that
fzipitria 12:43:30 UTC
To me this is only an interface
fzipitria 12:43:56 UTC
Where rest/grpc/spoa are different ways of communication with servers
ShiMing Q 12:44:12 UTC
How the coraza-server will support different protocols, like spoa, GRPC….
fzipitria 12:44:12 UTC
If the interface is well defined
↳ bxlxx.wu 12:46:10 UTC
This is OK, but in terms of products, I think it is different
↳ fzipitria 12:48:12 UTC
Agreed
Juan Pablo Tosso 12:44:21 UTC
Ok, so if @bxlxx.wu will become the code owner for the coraza-spoa I’m fine with it too
↳ bxlxx.wu 12:45:16 UTC
no problem
fzipitria 12:44:29 UTC
@ShiMing Q Using an interface?
fzipitria 12:44:35 UTC
Like a “connector”
ShiMing Q 12:45:58 UTC
Then those will be in separated project? SPOA, GRPC, REST..
bxlxx.wu 12:46:40 UTC
SPOA is a single project
Juan Pablo Tosso 12:46:40 UTC
Technically there will be only one project for GRPC and REST
Juan Pablo Tosso 12:47:19 UTC
Ok! so we are ok on this?
bxlxx.wu 12:47:21 UTC
coraza-server supports grpc and rest because these two protocols are common
fzipitria 12:47:47 UTC
I would say we start with SPOA as a single project, as @bxlxx.wu proposes. And then we regroup and take a look afterwards
Juan Pablo Tosso 12:48:08 UTC
Great, so we should move to the next topic 🙂
Juan Pablo Tosso 12:48:28 UTC
about the README, could we skip it ? we have many other important topics
Juan Pablo Tosso 12:49:12 UTC
Ok, so I added an extra topic, @JC wants to use Coraza in WASM
Juan Pablo Tosso 12:49:15 UTC
Juan Pablo Tosso 12:49:55 UTC
Basically we would have to add compilation flags to Coraza and split some files for compatibility
Juan Pablo Tosso 12:50:20 UTC
for example, we would have to create bodyprocessors/json.go bodyprocessors/json_tinygo.go
Juan Pablo Tosso 12:50:39 UTC
and the compiler would pick whether to use the json code or the tinygo code
Juan Pablo Tosso 12:51:59 UTC
Are we fine with it? @JC could you take care of the tinygo compatibility? I mean, create tests and maintain the _tinygo files
JC 12:52:39 UTC
So there are some limitations around the libraries one can use in tinygo, for that we can do two things: I would go for second option as it will be easier to maintain and we can make coraza prepared to get into wasm world
Juan Pablo Tosso 12:53:20 UTC
Compatibility right now means removing encoding/xml and replacing encoding/json with another json parsing library. These changes would only be compiled when you use tinygo
Juan Pablo Tosso 12:54:03 UTC
@bxlxx.wu and @fzipitria any comment?
fzipitria 12:54:37 UTC
I would say second option, for sure
Juan Pablo Tosso 12:55:02 UTC
Great, so @JC would you be able to help maintaining that?
↳ JC 12:59:47 UTC
YEs
↳ Juan Pablo Tosso 13:00:03 UTC
great, thank you José Carlos
↳ JC 13:00:10 UTC
(Carlos)
↳ JC 13:00:16 UTC
I mean José Carlos
↳ Juan Pablo Tosso 13:00:27 UTC
fixed :partyparrot:, sorry
Juan Pablo Tosso 12:55:43 UTC
I mean, encoding/json is a super safe library, I wouldn’t replace it
Juan Pablo Tosso 12:56:05 UTC
and there are no alternative xml decoding libraries
Juan Pablo Tosso 12:56:42 UTC
Ok, so we are moving to the next topic
Juan Pablo Tosso 12:56:46 UTC
Windows compatibility
Juan Pablo Tosso 12:57:10 UTC
do we need it? should we consider it when writing new code ? Should we add it to the contributors guideline ?
Juan Pablo Tosso 12:57:19 UTC
Should we also add tests?
fzipitria 12:57:26 UTC
I would say we don't
fzipitria 12:57:58 UTC
Unless someone wants to maintain it
Juan Pablo Tosso 12:58:02 UTC
Ok, so what if we wait until we get an active “windows” contributor? Because none of us are windows users
fzipitria 12:58:12 UTC
Yes
Juan Pablo Tosso 12:58:18 UTC
Great
Juan Pablo Tosso 12:58:42 UTC
Seems fair to me, any additional comment on windows compatibility?
fzipitria 12:59:32 UTC
Not from me
bxlxx.wu 12:59:48 UTC
+1
Juan Pablo Tosso 13:00:08 UTC
ok
Juan Pablo Tosso 13:00:41 UTC
Great, next topic Response body processing
Juan Pablo Tosso 13:00:50 UTC
do we need it? is it a v2 issue or v3?
Juan Pablo Tosso 13:01:12 UTC
basically it would allow us to process response body like: SecRule RESPONSE_ARGS:user_id "@gt 1000" "id:1000,phase:4,msg:'Response user ID > 1000'"
Juan Pablo Tosso 13:01:42 UTC
It requires api breaking changes
bxlxx.wu 13:02:38 UTC
vote for v3
Juan Pablo Tosso 13:03:24 UTC
Great, I think it doesn’t need more discussion
Juan Pablo Tosso 13:03:42 UTC
Regarding project versioning, what should be our strategy?: Feature-based Whenever a feature that is considered core or awesome is required to break compatibility we release a major version. It could easily lead to 3 major versions per year. Anual based We release one major version that would break compatibility per year (or some other period) To be continued
Juan Pablo Tosso 13:04:07 UTC
Should we tag a new version each time an important feature will break the api?
Juan Pablo Tosso 13:04:38 UTC
or should we tag new versions annually? or bi-anual
fzipitria 13:06:36 UTC
I would say feature based
Juan Pablo Tosso 13:07:14 UTC
Ok!
Juan Pablo Tosso 13:07:33 UTC
So the next three topics are just discussions, because they will indeed be implemented
Juan Pablo Tosso 13:07:35 UTC
Juan Pablo Tosso 13:07:39 UTC
any comments on that?
Juan Pablo Tosso 13:08:32 UTC
I would like to discuss about the debug log mechanism, should we switch from just using logger.Debug(…) to: if tx.LogLevel == types.DebugLevel { logger.Debug(...) }
Juan Pablo Tosso 13:08:54 UTC
It requires more lines of code, but it’s more efficient as logger.Debug() will always process the strings even if there is no debug
walter 13:09:18 UTC
well spotted, I don’t know how much of a performance impact it is…
fzipitria 13:09:39 UTC
I'm hoping in another meeting
walter 13:09:42 UTC
could the logger itself not look at the LogLevel and return early?
Juan Pablo Tosso 13:10:07 UTC
thank you @fzipitria
walter 13:10:21 UTC
passing the string to the function is just a pointer I think, or does it copy? :thinking_face:
Juan Pablo Tosso 13:10:38 UTC
I’m not sure why, but I see the logging functions in the performance graphs
Juan Pablo Tosso 13:10:44 UTC
even if there is no logging
walter 13:10:51 UTC
wow
Juan Pablo Tosso 13:10:57 UTC
that’s because in order to encode a coraza log you must use the following syntax:
Juan Pablo Tosso 13:11:13 UTC
logger.Debug(“Some log”, zap.String(“transaction_id”, someid”))
Juan Pablo Tosso 13:11:18 UTC
so there are some reflection processes
walter 13:11:20 UTC
ah!
walter 13:11:37 UTC
yeah then I think this could be a quick win 🙂
walter 13:11:40 UTC
well, maybe not quick, but not hard
Juan Pablo Tosso 13:12:02 UTC
yep, it could be a slow process of replacing the logs
Juan Pablo Tosso 13:12:20 UTC
Great, so that was all, we managed to discuss everything this time
Juan Pablo Tosso 13:12:25 UTC
any other questions or comments? 🙂
walter 13:12:37 UTC
no just applause 👏
Juan Pablo Tosso 13:12:56 UTC
thank you everyone for participating! Great meeting