[SECURITY] Security vulnerability in CI reported, resolved without incidence

Dear GNU Radio community, today, we received a security advisory via the contact method we offer in a canonical place [1], alerting us to the following: The github CI workflow that can be used to re-render the conda template gets triggered and executed without checking that the author of the triggering PR has CI privileges. (For the CI that gets run when you open a PR, you need to be trusted, or else a maintainer needs to click on "Approve CI run" every time you post or update a CI; this is not true for the github "issue_comment" trigger, which honestly is, in line with the rest of github CI's documentation style, something you can infer with enough experience, from sources outside Github documentation. We didn't infer that, and we wonder why there are action security controls that do not apply to all ways to trigger actions. Still, it's our responsibility to keep things safe, and assuming controls work without checking seems to be something we need to add to our list of things to do when working with public CI.) That would have allowed an attacker to open a PR that does something nefarious (attack webservers, mine cryptocurrency, exfiltrate CI secrets, modify commits/source code). We received this report from Wang-Meimei, for which we are very thankful. Steps taken: 1. simply removed that workflow. That makes it impossible to trigger from PRs, even should they add it back: it needs to exist on the main branch to work. I have not been able to get the workflow to function correctly in the last six months, so functionally, this is not a restriction of our abilities. 2. investigated workflow runs of the past year. No execution of that workflow, aside from my own, have been found. There have not been any inconsistencies of the main branch history with local copies, so we can preclude any code modifications. 3. Started a review of the repository action secrets stored in github. As mentioned in 2., we are certain enough this was not exploited, but we are still working to rotate secrets, and flush caches where applicable. ("abundance of caution", but really, we should just be doing that in a situation like this, without needing to think about it.) Special thanks, again, go out to Wang-Meimei, who's been very helpful in their reporting. Best regards, Marcus Müller [1] as described in RFC 9116: https://gnuradio.org/.well-known/security.txt