Thanks for pointing that out Jonathon, Ill fix it tomorrow, as I have done in the past when requested changes. I have concerns about the intent of the user requesting the deletion; for some unknown reason the request came out of thin air to an actively maintained package, created a duplicate -git, removed all Contributors to the header comment, then filed a merge request, which was merged even after changes had been made. env25 suggested I add pkgver. I took the users word for it and the user did not cancel the original merge request which moved all the history of non git to the git repo. It was approved as I wasn’t subscribed at the time to the mailing list, and didn’t respond on the list. I certainly responded in the comments however, as per the guidelines. Env25 was a brand new account but knew everything about the AUR which can insinuate multiple conclusions. All I care about is the security of the package. The package history which I have kept in absolute full had been dormant since 2017. I decided to revive it after almost 5 years and I’m actively maintaining it. I have no attachment to the package, however I’m just concerned for the security of the package which at the time was from a brand new user, yet knew everything about the AUR process. The most appropriate thing to do is merge the -git package back into non git, which restores all the comment history including Fabio’s original suggestions to fix, to which I addressed. Then env25 should recreate the git package as all of the historical and important comments were moved to the new one and make no sense as there’s now no git history, no previous maintainer information, no changelog, nowhere to submit PR, and does not respond to comments. I don’t understand why eNV25 was in a rush to merge the package yet knows I’m trivially contactable. Now wants to delete the pinned package, which helps nobody who wants to use it. That’s my security paranoid hat on, but I still don’t get the logic behind why the user was in a rush to take over a highly maintained package. I added a forewarning to the wiki specifically to address security with the package https://wiki.archlinux.org/title/Anbox#Security Regards, In good faith, Sick Codes of the Security Research Team @SickCodes <https://twitter.com/sickcodes> https://sick.codes https://github.com/sickcodes https://twitter.com/sickcodes https://www.linkedin.com/in/sickcodes/ https://www.youtube.com/c/sickcodes https://parler.com/profile/sickcodes/ https://hackerone.com/sickcodes https://bugcrowd.com/sickcodes https://hub.docker.com/r/sickcodes Jan 16, 2022, 04:21 by aur-requests@lists.archlinux.org:
On 15/01/2022 19:00, Sick Codes via aur-requests wrote:
anbox-modules-dkms follows last working commit with the patch for 5.10
anbox-modules-dkms-git follows master branch with sed instead of a patch
As of [1], anbox-modules-dkms is pinned to upstream commits. It is therefore not a VCS package (and doesn't need a pkgver() function, so I'm not sure why one was added).
The sed and patch are now a moot point as 5.10 is no longer in the repos (and looking at the discussion on [2] I'm not convinced either approach is the correct one).
[1] https://aur.archlinux.org/cgit/aur.git/commit/?h=anbox-modules-dkms&id=d77ac721b2e845eb537f23f936287f8b6bbb0363 [2] https://github.com/choff/anbox-modules/pull/1