










seth wrote:
1. automated how? How is a good commit distinguished from a bad commit? If someone acts malicious, why not ban them outright?
2. a solution about what to do when an account gets silently compromised? Assume the system compromised until proven different (ie. vet the PKGBUILD)
3. you've missed the xz-disaster? And the AUR maintainers are supposed to track in some cases hundreds of upstreams? How closely?like, new registered users seriously shouldn't be able to adopt packages
So I register 100 users, build up some reputation by genuinely packaging stuff (AI slop generated with my other hat on, or maybe some fun tools, fractional ASCII animations) and after 30 days have your blind trust when I launch my attack?
The point is, you're trying to introduce some faux trust. Don't. There're way to many links in this chain to ever trust it and that needs to be clear and no diluted by some completely unreliable trust system.
I'd track the AUR commits for fuzzy patterns (the attackers may learn and introduce randomized noise) for internal alerts, not mislead the users about the nature of the AUR at large or any specific user or package there.
1. You asked what is handing out points, automated was my answer only on points, nothing else, how it decides, I can't tell, I'm not a coder, just a theorycrafter. The idea is that untrusted people will have their submissions to be manually vetted by AUR mods at the earlier stages, hence why I said "and secure against abuse via combining it with further manual interventions".
2. Btw I thougt you'd know: 2FA
3. I wasn't affected, but didn't miss the news, I was an MX-Linux user back then it happened, but they weren't affected thankfully. Now I'm an Arch base user (Garuda); Thankfully I'm still unaffected by these new attacks, because I use IgnorePkgs, and only have 2 AUR pkgs for my printer, which was updated in ... forever
But still, there should be some extra safety layer, at least some bare minimum, for people who don't know how to read or what to look for in the PKGBUILDs or how to understand them.
So I register 100 users, build up some reputation by genuinely packaging stuff (AI slop generated with my other hat on, or maybe some fun tools, fractional ASCII animations) and after 30 days have your blind trust when I launch my attack?
Ok, then we're full ears of what idea can you throw in to the common bin to mitigate that.
The point is, you're trying to introduce some faux trust. Don't. There're way to many links in this chain to ever trust it and that needs to be clear and no diluted by some completely unreliable trust system.
You're totally missing the point, which - still - is, that I'm giving ideas, to reduce the attack surface, and that's why I said the list is an as-is proposal. One thing I know is that every problem has a solution, although not a 100% perfect one. Since brainstorming is open to everyone, we're not here to shoot down each other's ideas, but to build a safer computing environment for everyone's daily life.
I'd track the AUR commits for fuzzy patterns (the attackers may learn and introduce randomized noise) for internal alerts, not mislead the users about the nature of the AUR at large or any specific user or package there.
That sounds cool but preventing automated sybil attacks or long-term sleeper accounts requires multiple layers, which is why a trust system must be combined with active anomaly detection (and manual inspection too) rather than relying on a single silver bullet, it is true that no system creates absolute blind trust, but reducing the volume of low-effort malicious adoptions allows both mods and users to focus their manual vetting where it actually matters imho.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。