Dynamic Regex Badge

[TrianguloY]

📋 Description

I'm writing this issue as explained in the tutorial, since I already have a prototype and my idea is to create a PR in the following days. (great tutorial btw, it was really helpful!)

---

This new badge is designed to extract any data from any file using regexes. Regex can become very complex, but at the same time are very powerful. They may not be as structured as xml or json, but that's precisely what makes them so powerful, since you can extract data from literally anywhere, be it a gradle file, a proprietary format, or even a readme. The only constraint is that the file is parsed as a big string.

As an example, if you have a file like this sample, and you use a regex of ^version: '(.*?)' with a replacement of $1, you get a badge with the value 0.0.1.

The only concern about this badge is that regex can be used as a denial-of-service attack, as some regex with some specific inputs can take years to be resolved. There are already some existing solutions for nodejs to mitigate and add timeouts to regex operations. And I plan to review and implement one of them. I understand that this is mandatory for the badge feasibility.

🔗 Data

The badge will fetch a raw file from a url, like the other existing dynamic badges. The regex search/replace will be done locally afterwards with provided data. There is no need for an external public api.

🎤 Motivation

I came up with this badge idea after trying (but failing) to implement a gradle badge (already requested) since I couldn't import the apparently only JavaScript gradle parser library gradle-to-js. I'm not a node-js developer, and probably there are ways to do that, but I came up with this alternative that I like even more.

I tried to find existing alternatives, but couldn't find anything that I personally could use for my own project. Since I know about programming, and this repository had clear contribution guidelines, I just decided to implement it myself. As already explained I plan to create a PR in the following days, I just created this issue to gather preliminary feedback before that.

[chris48s]

As you've noted, the big issue with accepting user-supplied regex (and the reason we don't do it) is vulnerability to ReDOS attacks. This is the reason why we decided not to accept user-supplied regex in #9173

I think before you submit a PR, I'd like to see a plan here for how you plan to mitigate that attack vector as that is what the whole thing hinges on really.