📊 Quantitative test results for language: eng, year: 2023, size: 10K, paranoia level: 1:
🚀 Quantitative testing did not detect new false positives

If you have an existing use case that shows how to create this regex in .ra, I’d be happy to look at it; otherwise, no. I feel I’ve already wasted enough time trying to implement this use case in .ra and nothing works.

You can always refer to regex assembly and the crs-toolchain docs to get an idea as to how they work.

I feel I’ve already wasted enough time trying to implement this use case in .ra and nothing works.

Keep in mind that crs-toolchain auto-optimizes the regex, so the output might not be exactly what you want although the behavior should be the same. I'm not entirely sure what false positive your targeting specifically, but based on the regex I'm seeing I think this is what you want:

##! Please refer to the documentation at
##! https://coreruleset.org/docs/development/regex_assembly/.

##! This chained rule is used to match on JWT base64-urlencoded tokens.
##! See https://www.rfc-editor.org/rfc/rfc4648#section-5 for details.

##! JWTs consist of base64-urlencoded encoded JSON, and a JSON structure 
##! just starts with '{"', which becomes 'ey' when encoded with a base64-urlencoded encoder.

##!> define base64-urlencoded-charset [a-zA-Z0-9_-]+
##!> define dot [.]

##!^ ^

##!> assemble
ey{{base64-urlencoded-charset}}{{dot}}ey{{base64-urlencoded-charset}}{{dot}}{{base64-urlencoded-charset}}
##!<

##!> assemble
[\w-]+
##!<

##!$ $

Also can you add some positive/negative tests, and especially tests for the false positive that this PR is meant to fix?

Thanks @EsadCetiner for your feedback. I updated the PR accordingly and added unit tests.

I'm having an issue with the .ra file that I don't understand, and the debugging output is really not verbose. Could you please help me?

I have absolutely no idea how to do that through the GitHub interface.

@touchweb-vincent You need to run the command locally on your machine then push your changes to GitHub via the CLI. I've fixed this one for you.

Thanks @EsadCetiner

I can't merge since I pushed a commit to this PR

@azurit @fzipi ping :)

@touchweb-vincent Happened again - no information in the PR description. I had to read the code and tests to understand what are you trying to achieve and only AFTER that i was able to start a real review. Recently, you were asking on Slack what can you do to speed up reviewing of your PRs, so now i'm telling it to you for the second time: Write full and complete descriptions and provide all information which you are asked for. It's that simple.

@azurit I understand, and I will try to do better, but I don’t have the required skills to clearly distinguish what seems obvious from what isn’t.

So if I add more explanations, you might think I’m treating you like idiots - please don’t hold it against me; I’m just not good at gauging this, and communication really isn’t one of my strong points.

Rule of thumb: Additional information and redundancy in a PR description is almost always a good thing. I see that it can look a bit idiotic at a given level, but it's definitely better to write too many explanations than not enough.

PR descriptions are also for future reference when Slack conversations, other PRs and even issues are long forgotten. People should be able to make sense of a PR without any other explanation. Optional links welcome, but the information better be with the PR.

And agreed: It takes practice.

@touchweb-vincent Thank you.