Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

harden aur_pre_build #2228

Open
lilydjwg opened this issue May 10, 2021 · 28 comments
Open

harden aur_pre_build #2228

lilydjwg opened this issue May 10, 2021 · 28 comments
Assignees
Labels
no-lilac Make lilac skip this issue

Comments

@lilydjwg
Copy link
Member

lilydjwg commented May 10, 2021

问题类型 / Type of issues

  • 其它 / other

受影响的软件包 / Affected packages


aur_pre_build API 支持指定 AUR 维护者已经有一段时间了,不过采用率很不好看。现在我计划将指定 AUR 维护者作为必填,以避免 AUR 包被别人接手后加入恶意或者垃圾代码。

maintainers 参数可以是 str 或者 list[str],指定信任的 AUR 维护者/最后打包者。如果 lilac 打包时,最后打包者不在这个参数里,将会拒绝打包。请各维护者更新相关包,指定该参数。


There has been some time that the aur_pre_build API supports specifying AUR maintainers. However, it's not widely used. Now I'm going to make it mandatory to specify AUR maintainers to avoid AUR packages with evil or poor code that's added by later adopter.

The maintainers argument can be str or list[str] to specify trusted AUR maintainers / last packagers. When lilac packages, if the last packager is not in this argument, lilac will refuse to package. Please add this argument for your packages!

@lilacbot
Copy link
Contributor

NOTE: some affected packages are unmaintained:

  • freeradius-client is depended by ocserv (@farseerfc)
  • fsharp is depended by monodevelop-stable (@farseerfc)
  • libpcl is depended by ocserv (@farseerfc)

Some maintainers (perhaps outside contributors) cannot be assigned: @Rasphino, @edward-p, @OriginCode, @xgdgsc, @Xuanwo, @hamkido, @felixonmars, @kaseiwang, @rayfalling, @Universebenzene, @Skywol, @renyuneyun, @farseerfc, @isjerryxiao, @oldherl, @imlonghao, @swordfeng, @ideal, @PeterCxy, @VOID001, @yuyichao, @petronny, @h0cheung, @MarvelousBlack, @zsrkmyn, @megrxu, @berberman, @heavysink, @KenOokamiHoro, @frantic1048, @SilverRainZ, @hubutui, @masakichi, @wfxr, @ykelvis, @poscat0x04, @justforlxz, @yan12125, @yuutaw, @Sasasu

@lilydjwg lilydjwg added the no-lilac Make lilac skip this issue label May 10, 2021
@petronny
Copy link
Member

呃,那我不想用这个参数怎么办呢,指定None?
我目前还没有遇到需要这种白名单的包,不是觉得这个很有必要。。。

如果真要做的话,估计需要一个脚本直接批量添加现有maintainers,手动改不现实。

@OriginCode
Copy link
Member

shadowsocks-libev-qrcode does not fetch updates from AUR, please remove it from the list.

@lilydjwg
Copy link
Member Author

lilydjwg commented May 10, 2021 via email

@lilydjwg
Copy link
Member Author

lilydjwg commented May 10, 2021 via email

@lilydjwg
Copy link
Member Author

Note that pre_build in lilac.yaml does not support arguments; it's just a function name. You'll need to use pre_build_script to write code.

@OriginCode
Copy link
Member

Note that pre_build in lilac.yaml does not support arguments; it's just a function name. You'll need to use pre_build_script to write code.

Fixed. XD

@edward-p
Copy link
Contributor

Done by ce8209a

@axionl
Copy link
Member

axionl commented May 10, 2021

ea479e3

@heavysink
Copy link
Contributor

无意冒犯,其实我个人认为这个做法最好是鼓励而不是强制。

如果有稳定maintainer,而且上游代码更新频率低不怎么出问题的包还好。AUR有些包是很不稳定的,经常换maintainer。据我观察,上游大更新导致编译出问题的时候AUR包maintainer的更换频率会大大提升,因为遇到一个编译问题无法解决的话有些maintainer会选择直接弃包让能解决的人上。而如果手动指定maintainer的话会有些不灵活。

至于AUR包被添加恶意代码的问题,这个我个人认为是archlinux AUR本身的监管以及投诉渠道的问题。窃以为这个不该由Archlinuxcn承担。

我比较赞同@petronny,我的话如果AUR包有稳定的maintainer我会添加信任maintainer,但不采用这个参数的包也应该被允许。

@BruceZhang1993
Copy link
Member

BruceZhang1993 commented May 10, 2021

至于AUR包被添加恶意代码的问题,这个我个人认为是archlinux AUR本身的监管以及投诉渠道的问题。窃以为这个不该由Archlinuxcn承担。

由于 AUR 本身是要求用户安装时自己检查和审核打包脚本的安全性,而 Arch CN 源相当于帮用户跳过了这一步骤,那么 Arch CN 就需要对打出的软件包进行基本的检查和审核,所以还是需要承担的 @heavysink

@petronny
Copy link
Member

由于 AUR 本身是要求用户安装时自己检查和审核打包脚本的安全性,而 Arch CN 源相当于帮用户跳过了这一步骤,那么 Arch CN 就需要对打出的软件包进行基本的检查和审核,所以还是需要承担的

这么说的话,我有了一个新的idea。

能否让lilac在监测到AUR maintainer变了的时候,打包时自己加上一个post_upgrade(),告诉用户这个包的维护者变了,提醒用户注意?
这样我们就不用自己检查,让用户去检查就好了。

@petronny
Copy link
Member

甚至可以是监测出不仅仅是version bump的那种upgrade的时候都给出提醒。
告诉用户这个包最近的更新包含额外改动。

@heavysink
Copy link
Contributor

heavysink commented May 10, 2021

至于AUR包被添加恶意代码的问题,这个我个人认为是archlinux AUR本身的监管以及投诉渠道的问题。窃以为这个不该由Archlinuxcn承担。

由于 AUR 本身是要求用户安装时自己检查和审核打包脚本的安全性,而 Arch CN 源相当于帮用户跳过了这一步骤,那么 Arch CN 就需要对打出的软件包进行基本的检查和审核,所以还是需要承担的 @heavysink

个人觉得不需要审核的是官方源,既然用户选择了第三方源,就需要自己承担一部分责任。Unofficial repo有warning:
The official Arch Linux Developers and the Trusted Users do not perform tests of any sort to verify the contents of these repositories. It's your decision whether to trust their maintainers, and you take full responsibility for any consequences of using any unofficial repository.

不知道这么说何不合适...

@DDoSolitary
Copy link
Member

@petronny 我觉得不是很理想,首先安装包这个操作本身就不安全了,因为 aur 维护者可以加安装脚本,然后考虑到 archcn 的使用情况,打包者也确实有责任在一定程度上检查 pkgbuild 。

而且相比自己维护包,直接从 aur 拿基本都没啥工作量了,要求在 maintainer 变更的时候检查一下也不过分吧,实际上我经常担心 aur 维护者把包或者是我写在 lilac.py 里的脚本弄坏了,甚至希望可以每当 aur 更新的时候都能够手动检查修改情况再决定是直接打包还是需要修一修。

@DDoSolitary
Copy link
Member

@heavysink 警告里也说了,用户自行选择是否相信非官方仓库的维护者,让 archcn 尽可能地成为一个用户可以给予一定信任的仓库总是好的。

@DuckSoft DuckSoft removed their assignment May 10, 2021
@AlynxZhou
Copy link
Member

8ac49d8

@AlynxZhou AlynxZhou removed their assignment May 11, 2021
SilverRainZ added a commit that referenced this issue Feb 13, 2022
SilverRainZ added a commit that referenced this issue Feb 13, 2022
zjuyk added a commit that referenced this issue May 6, 2023
@cuihaoleo cuihaoleo removed their assignment Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no-lilac Make lilac skip this issue
Projects
None yet
Development

No branches or pull requests