archlinuxcn / repo

Arch Linux CN Repository
1.48k stars 283 forks source link

harden aur_pre_build #2228

Open lilydjwg opened 3 years ago

lilydjwg commented 3 years ago

问题类型 / Type of issues

受影响的软件包 / 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 commented 3 years ago

NOTE: some affected packages are unmaintained:

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

petronny commented 3 years ago

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

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

OriginCode commented 3 years ago

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

lilydjwg commented 3 years ago

On Mon, May 10, 2021 at 05:02:46AM -0700, Jack Wu wrote:

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

Removed. It was a false positive.

-- Best regards, lilydjwg

lilydjwg commented 3 years ago

On Mon, May 10, 2021 at 04:43:38AM -0700, Jingbei Li wrote:

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

防患于未然嘛。

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

嗯,就等人写出来了。

-- Best regards, lilydjwg

lilydjwg commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Done by https://github.com/archlinuxcn/repo/commit/ce8209a3345eb35b1103e835b12c0f83ed2c9251

axionl commented 3 years ago

https://github.com/archlinuxcn/repo/commit/ea479e378aecb0b31a32944a605b290115f82f2b

heavysink commented 3 years ago

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

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

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

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

BruceZhang1993 commented 3 years ago

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

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

petronny commented 3 years ago

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

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

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

petronny commented 3 years ago

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

heavysink commented 3 years ago

至于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 commented 3 years ago

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

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

DDoSolitary commented 3 years ago

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

AlynxZhou commented 3 years ago

https://github.com/archlinuxcn/repo/commit/8ac49d83ceaa91cb2d2394d24919253ee50fb07f

justforlxz commented 3 years ago

e1a3039e86b675bd749ee6ec925958306fb0762c

MarvelousBlack commented 3 years ago

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

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

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

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

主要是還有個問題,由 aur 帶進來的惡意代碼可能會影響到編譯機,之前就是可以從 aur 帶進來一個 lilac.py 和 lilac.yaml(雖然現在不允許了)。

hubutui commented 3 years ago

我的包处理完了.

KenOokamiHoro commented 3 years ago

Added current maintainers in https://github.com/archlinuxcn/repo/commit/c4d306c17820c1217a1055e0579859eeadf3cbc5 .

a-wing commented 3 years ago

Added current maintainers in 11df7853872496beb3eabd084933a435ef5fb44c .

heavysink commented 3 years ago

处理完毕

ideal commented 3 years ago

需要合并一下:#2275

AlynxZhou commented 3 years ago

需要合并一下:#2275

Done.

frantic1048 commented 3 years ago

一楼的「受影响的软件包」列表的勾勾是会自动随着 master 更新而变动么,还是维护者确认变动已经进入 master 之后去手动点呢 :eyes:

MarvelousBlack commented 3 years ago

一楼的「受影响的软件包」列表的勾勾是会自动随着 master 更新而变动么,还是维护者确认变动已经进入 master 之后去手动点呢 👀

手動

peeweep commented 2 years ago

@dctxmei firefox-esr 的lilac 报错可能是由此引起的,请修复

https://build.archlinuxcn.org/packages/#/firefox-esr/logs/1633384211