[aur-requests] [PRQ#31497] Deletion Request for anbox-modules-dkms

Sun Jan 16 17:49:07 UTC 2022

Thanks for that,

No, there are infinite reasons to have all of -bin -git and non-git packages. Docker containers, upstream changes, security holes in newer/older versions, cloud installs, automation etc.

Not everyone is on the Mailing List + Forums + Reddit + IRC + Discord etc.

AUR security is at the absolute top of my check-list.

Most AUR users don't want actively maintained packages to be randomly transferred to brand new users (at the time), with absolutely no historical proof of trust (at the time). I invite you to evaluate my trustworthiness: https://github.com/sickcodes/security/tree/master/advisories. I happily added you as a co-maintainer. Then the merge went thru, expecting you were going to cancel the request.

In my opinion, as you were well aware all of the merge requests items were addressed, you should've cancelled the merge request last month.

That's why I am concerned. I'm not attached, I'm concerned about the security of the project.

Users still need a pinned version, as do many others on 5.10, 5.11, 5.12, 5.13, 5.14, 5.15, etc.

You knew the fixes were made and should've cancelled the merge.

Contact the maintainer politely next time, like other AUR users do when they request updates, and similarly, I contact package maintainers with tips.

A) contact the maintainer
B) create a -git and file a merge request

You chose option B

> 2021-12-11 12:21 -git created by @eNV25
> 2021-12-11 14:21 [PRQ#30507] Merge Request for anbox-modules-dkms
notify at aur.archlinux.org notify at aur.archlinux.org by @eNV25

You created a -git version and merge requested 2 hours later.

Why would you merge instead of simply contacting me to fix it? I honestly considered the intial request a malicious request, which at the time, was from a brand new account.

I would prefer to pkgver using pkgver=5 and pkgrel=15.14, so as to reflect the last supported kernel.

All of your requests in the merge request were already fixed and in good faith I believe you probably should've honored your statement to cancel the merge:

- Uses git source without a -git pkgname suffix.
> Fixed before merge https://github.com/sickcodes/aur/commit/dffca947ee02be66fe4ea54682a6d5ae1195b798

- Is not a proper DKMS package.
> Yes it is. See https://wiki.archlinux.org/title/DKMS_package_guidelines

  - It doesn't use DKMS hooks. It instead runs make install in
build().
> It was moved and there are no release binaries from the GitHub project, which would be a -bin anyway.

  - It depends on linux-headers.
> That was fixed before the merge: https://github.com/sickcodes/aur/commit/5e900cd21fc4d6729bb9d41f0bbc47f060cfd06c#diff-b770532527784a5638d944a5d07854bc60a26c8ef9580f74ff72aa865aa73a75

  - It installs **/dkms.conf to /usr/lib/modules-load.d/ for some
reason.
> Also fixed before the merge: https://github.com/sickcodes/aur/commit/5e900cd21fc4d6729bb9d41f0bbc47f060cfd06c#diff-b770532527784a5638d944a5d07854bc60a26c8ef9580f74ff72aa865aa73a75

These were all addressed before the merge, to which you agreed. The fact you didn't cancel the merge concerns me.

sickcodes commented on 2021-12-13 01:24   

    Removed the build function from previous maintainer
    Removed linux-headers from previous maintainer
    Removed /usr/lib/modules-load.d/ from previous maintainer
    Added 5.10 patch

https://aur.archlinux.org/packages/anbox-modules-dkms-git/#comment-840564

That's why I was more than happy to add you as a co-maintainer.

For example 5.16.0-rc5-1 wasn't working:

==> dkms install --no-depmod binder/1 -k 5.15.14-1-lts
==> dkms install --no-depmod ashmem/1 -k 5.16.0-arch1-1
==> dkms install --no-depmod ashmem/1 -k 5.16.0-rc5-1-git-00224-g9eaa88c7036e
Error! Bad return status for module build on kernel: 5.16.0-rc5-1-git-00224-g9eaa88c7036e (x86_64)
Consult /var/lib/dkms/ashmem/1/build/make.log for more information.
==> WARNING: `dkms install --no-depmod ashmem/1 -k 5.16.0-rc5-1-git-00224-g9eaa88c7036e' exited 10
==> dkms install --no-depmod binder/1 -k 5.16.0-arch1-1
==> dkms install --no-depmod ashmem/1 -k 5.16.0-zen1-1-zen
==> dkms install --no-depmod ashmem/1 -k 5.15.14-1-lts
==> dkms install --no-depmod binder/1 -k 5.16.0-zen1-1-zen

Users need a non-git pegged version if upstream changes, thats the end of the story.

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, 10:46 by env252525 at gmail.com:

> On Sun, Jan 16, 2022 at 7:07 AM <info at sick.codes> wrote:
>
>>
>> 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.
>>
>
> I did not suggest adding pkgver(). I said a proper VCS package also
> needs pkgver(). I never suggested any changes.
>
> Even if I did, it is you who added the change.
>
>> Env25 was a brand new account but knew everything about the AUR which can insinuate multiple conclusions.
>>
>
> What are you insinuating? Please stop this useless discussion.
>
>> 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.
>>
>
> I made you a co-maintainer for anbox-modules-dkms-git.
>
> The original package was a VCS package that did not have a -git
> suffix. You changed to pin a specific commit just to keep an unneeded
> package there, it does look like you are attached to the package.
>
>> 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 wrote the PKGBUILD for anbox-modules-dkms-git from scratch, there's
> no need for Git history.
>
>> I don’t understand why eNV25 was in a rush to merge the package yet knows I’m trivially contactable.
>>
>
> Your package was a VCS package. This request is separate.
>
>> Now wants to delete the pinned package, which helps nobody who wants to use it.
>>
>
> What's the use for the pinned package? There is no use if you are just
> going to update it every commit.
>
>> 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 don't consider taking an old PKGBUILD and uploading it to AUR as is,
> 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://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 at 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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20220116/67f46802/attachment-0001.htm>