At least npm finally made atomic-lockfile a security holding package.
https://socket.dev/npm/package/atomic-lockfile On 6/12/26 16:16, Agamjot Singh wrote:
Another temporary solution (specifically for the current situation involving atomic-lockfile npm package):regex npm/pnpm install atomic-lockfile in the PKGBUILD and holding all such commits.The regex list can then be updated manually by moderators as other methods of malware distribution get discovered.On Fri, Jun 12, 2026, 7:36 PM kleines Filmröllchen <[email protected]> wrote:Hi all, reading all of this, it makes me wonder, do we need automatic adoption that badly? Orphan requests exist, after all, and that system seems to work just fine. To me it seems like package adoption should simply be a request too. If that is in place, adoption requests should also be able to be filed on a non-orphaned package, skipping the two-step orphan to adoption process. FWIW, I’m speaking as someone who has adopted multiple abandoned and/or archived AUR packages in the past. For all of these I would have not personally minded needing to go through a manual adoption process, especially since at least one of them is a widely-used tool. Maybe the numbers disagree with me on this, however, and there are so many adoptions that the maintainers will be overwhelmed. ~ kleines Filmröllchen Am 12.06.26 um 09:58 schrieb David C Rankin: > On 6/12/26 2:22 AM, Iyán Méndez Veiga wrote: >> I think making AUR read-only would affect its functionality too much. >> I like the proposal of modifying the adoption step only. Perhaps >> adding a time delay is also enough, and would not add extra manual >> work to Arch Linux developers. >> >> For example, it could be something like this: >> >> Min account age before being able to submit a new PKGBUILD: 24h >> Min account age before being able to adopt orphan PKGBUILD: 7d >> >> Of course, this does not protect against account takeovers, or >> against patient attackers that can wait a week to adopt packages, but >> it would improve things a little bit without affecting AUR too much. >> They cannot simply create new accounts after old ones are banned, >> they have to wait another week. >> >> If all the attacks happened via the PKGBUILD adoption way, perhaps >> the requirements can be toughen even more, like requiring a min >> number of packages already being maintained by the account before >> allowing to orphan. > > I like those ideas, > > I also think we can consider: > > 1) holding first X (10?) commits for new users until reviewed by > human-in-the-loop; AND > > 2) holding commits for new users for X (30?) day period until > reviewed by human-in-the-loop. > > That does add moderator involvement on the *front-end*, but it would > take no more moderator time than reverting changes to remove the > malware and banning the user currently done on the *back-end*. > > That would the malware from reaching AUR. > > A big thanks to the moderators and the community's efforts. This is > no fun, but appears to be a new-normal. >
OpenPGP_0x1396EBBD1AADE388.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
