In the past days I noticed PR patterns that do not look right. This is a smell, not a verdict. The upside is real: rsyslog is interesting enough to attract attention. That is actually great news. Now we have the problem ourselves, and that is the moment to engineer the right guardrails without losing our welcoming tone. You need to be a target in order to gain sufficient experience to tackle that hard problem.
What the ecosystem learned
After the XZ/liblzma backdoor was uncovered in 2024, the OpenSSF and OpenJS Foundations issued a joint alert describing early patterns of social-engineering takeovers and practical mitigations for maintainers. The non-code part of our work matters just as much as the code.
Separate from outright hostile attempts, we begin to see very small PRs. It’s not a wave, but especially the timing raises eyebrows. Maintainers of prominent projects have written about this, and the Hacktoberfest 2020 experience put numbers to it.
What we saw in rsyslog
Twos PRs (sample) attempted to remove the entire test suite. The author closed it quickly. Nothing happened, but it is a good reminder why we keep the guardrails switched on. Either the AI assisted review drove the account away. Or, and that’s my main idea, the whole purpose was to create PRs, maybe check what happens (then we are back at the AI review scared it away…).
We also see another pattern: small typo-only PRs. Many are honest and useful and a fine way to start at low risk. We will merge those as the add real value. At the same time, the same pattern can be abused to farm trust. To keep the balance we will ask authors to batch related typo fixes, and we will fix obvious typos quickly ourselves so this method loses traction.
What we did not yet see is complex, or at least complex-looking, PRs generated via AI. Either things that overcomplicate (already happend to me) or are plainly malicious. I guess we will potentially see them when an account manages to go beyond the grooming phase. In any case, our CI and the AI assisted checks are good safeguards. The mandatory human final review, as other projects have seen, is just another safeguard, albeit a strong one. The good news is that there is still a lot to learn about the tactics, which is especially good for a forward-thinking security aware project like rsyslog.
The approach: friendly first, with light automation
Back to the current situation: I added a small GitHub Action that posts a tailored welcome on a contributor’s first few PRs and provides a couple of context signals to maintainers. Long-time contributors are skipped automatically. The initial version does three things:
- It welcomes the author in a positive, human tone.
- It sets expectations: please address automated feedback or explain why not.
- It surfaces basic context like account age and prior merged PRs in this repo to help triage faster.
This is not a gate. It reduces back-and-forth, keeps the tone consistent, and gives reviewers a tiny bit more context. The workflow will be tuned based on real-world data.
Policy clarifications
- Small, high-quality PRs are welcome, including typo fixes.
- Please batch related typo fixes into a single PR. Mechanical, focused changes are the easiest to review.
- Repetitive single-typo PRs from the same account may be closed with a request to consolidate.
- We will soon run periodic typo sweeps and or at least do linting to CI to fix obvious mistakes quickly.
- Big or risky changes always require a clear rationale and normal review. Proposals that remove tests or add opaque blobs will be scrutinized.
- AI in PR review, one of rsyslog’s AI First components, seem to work. We will strengthen its use in detecting invalid (either malicously or ignorantly) drafted PRs.
Why this works
Attackers try to win the social game first. We keep the door open for new contributors, but we also write down the house rules and keep a light on in the hallway. Boring, predictable processes are good security tools. Note that each project in the OSS space needs to be a team player. What we merge, builds trust – which can be used to trick others. It’s especially a though call on very small, yet useful PRs.
What comes next
- Spell checks — and more spell checks. This looks like a number one issue where it is very though to make a judgement call on PRs. Plus, correct spelling right from the beginning does not hurt ;-)
- A short contributor page that explains the welcome workflow and our expectations.
- Regular checks of repo privileges and release paths, aligned with current best practice. While we already do this kind of, it’s not formalized.
If you are new here: thank you for choosing rsyslog. Your constructive PRs are very welcome. If you notice suspicious patterns, please flag them. We will keep improving both our welcome and our defenses.