AUR Trusted User guidelines

出自 Arch Linux 中文维基

相關文章

Trusted User (TU) 是負責使 AUR 正常工作的社區成員。他們維護熱門的包（並在必要時與上游項目交涉或者向上游項目發送補丁），並且參與管理事務的表決。TU 由現任的 TU 從活躍的社區成員中民主選舉產生。 TU 是唯一具有決定 AUR 發展方向的權利的社區成員群體。

TU們依靠TU bylaws來管理社區。

新 TU 的 TODO 列表[編輯 | 編輯原始碼]

  1. 仔細閱讀本頁面
  2. 閱讀 TU Bylaws
  3. 確認自己在 AUR 的帳戶詳細信息是最新的
  4. 讓一個贊助者在 AUR 中給您 TU 狀態.
  5. 將你自己添加到 Trusted Users 頁面
  6. 訂閱 Arch Linux 開發郵件列表 arch-dev-public.
  7. 提醒 Arch wiki bureaucrat 將您加入 ⧼group-archtu⧽ 組.
  8. 提醒 BBS admin 更改你在論壇上的帳戶
  9. 讓推薦人提供 #archlinux-staff 和 #archlinux-tu 密碼，加入頻道，這雖然不是必須，但這是和團隊認識和合作的一個好方式。
    • 如果需要轉發，請申請 Matrix.
    • 如果需要 @archlinux/trusteduser/username，請連續群組聯絡人 group contacts。
  10. 讓一個贊助者在 基礎設施問題追蹤中 使用 Onboarding 模板創建任務，並提供如下信息：
    • 包含一個 SSH 公鑰，如果還沒有，使用 ssh-keygen 生成。Using SSH Keys 包含更多信息。
    • SSO 帳號要使用的用戶名，此名稱也會用來創建 @archlinux.org 郵箱地址。
    • 全名.
    • 個人郵箱地址和有效的 PGP 公鑰 ID, 將會此信息創建開發者網站 (archweb) 帳號並連結到新建的 SSO 帳號。
    • 使用私人郵件還是馬上要創建的 username@archlinux.org 郵箱地址加入非公開郵件列表，並允許向 arch-dev-public 發送郵件。
  11. 按 DeveloperWiki:Staff Services#Email 創建 @archlinux.org 郵箱
  12. Create a PGP key pair for package signing by following the
  13. 為軟體包簽名創建 PGP key，執行 添加打包人新密鑰動作(使用新的 <username>@archlinux.org 地址作為 uid).
  14. 按照此 模板 向 Ionuț Bîru (ibiru@archlinux.org) 或 Florian Pritz (bluewind@xinu.at)發郵件，包含所有信息以獲得 dev 接口的訪問權限
  15. 讓贊助者在 archlinux-keyring 倉庫問題追蹤 使用 New Packager Key 模板創建任務，用至少三個主密鑰簽名您的 PGP。
  16. 安裝 devtools包 軟體包
  17. 為主機 orion.archlinux.org 和 repos.archlinux.org 上配置ssh 私鑰
  18. Ssh 到 yourname@repos.archlinux.org (得到權限之後).
  19. 如果你在兩天內沒有在 bugtracker 被升級到 TU 組，在 arch-dev-public 發郵件詢問
  20. 開始你的貢獻吧！

TU 和 AUR[編輯 | 編輯原始碼]

TU 應該仔細檢查那些被提交到 AUR 分類中的軟體是否含有惡意代碼，以及PKGBUILD包是否符合標準。在UNSUPPORTED 中，大約 80% 的 PKGBUILD 都非常簡單，TU 團隊可以很快的檢查其可用性以及安全性。

TU 也應該檢查 PKGBUILD 的一些小錯誤，提出修改以及改進建議。TU 應該努力確認所有的軟體包遵循了Arch Packging Guidelines/Standards 並與其他打包者分享他們的技能和經驗來提升 archlinux 的軟體包發行版本的質量。

TU 也很適合撰寫文檔來記錄一些值得推薦的行為。

Rewriting git history[編輯 | 編輯原始碼]

In some cases rewriting the history of an AUR repository is required, for example when a user inadvertently uses their real name in a published commit. This can be automated with git-filter-branch(1).

To force push the new history, forward the AUR_OVERWRITE=1 environment variable to git-push(1). See [1] for details.

警告： It is recommended to create a backup of the repository before rewriting history.
Modify committer or author identity

Install git-filter-repo包 and run: 

$ git-filter-repo --name-callback 'return name.replace(b"Old name", b"New name")' --email-callback 'return email.replace(b"old@email.com", b"new@email.com")'

Alternatively, use git filter-branch --env-filter with the GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL environment variables. For example: 

git filter-branch --env-filter '
if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then
  GIT_AUTHOR_EMAIL=user@users.noreply.github.com
fi
if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then
  GIT_AUTHOR_NAME=user
fi'
注意： git-log(1) only displays the git author by default. Use git log --pretty=fuller to display the author and committer.

Handling AUR requests[編輯 | 編輯原始碼]

這篇文章的某些內容需要擴充。

原因： This list is incomplete for now and should be expanded. (在 Talk:AUR Trusted User guidelines 中討論)

TUs should periodically check the requests filed on the AUR. For that there are some generic rules what to check for each request type:

Orphan request
  • check if the request is older then 14 days (the date column turns red in the overview) (you cannot accept it before that anyway)
  • check if there was no update to the package itself (commit or release) done in the past 14 days
  • check if there was no comment from the package maintainer done in the past 14 days


If all of the above points are true then you can accept the Orphan Request.

TU 和 [community], 包維護導引[編輯 | 編輯原始碼]

軟體包進入 [community] 倉庫的規則[編輯 | 編輯原始碼]

  • 軟體包還沒有加入其它任何倉庫，確保其它打包者沒有同時提交軟體包。檢查 AUR 評論，閱讀 aur-general 中文章的標題，在 bugtracker 的全部項目中搜索, grep Subversion 日誌，然後向私有 TU IRC channel 發送消息.
  • Pacman 包裝程序 是一個特例，不管投票數有多高，都不會被批准進入。如果是 AUR helper，可以寫封郵件到 arch-dev-public，需提供希望添加的包和團隊的贊同和反對意見。
  • 只有「流行」的軟體包才能進入倉庫，如 pkgstats 規定的 1% 使用數或者 AUR 中 10 票以上
  • 自動屬於此規則的例外的軟體包包括：
    • i18n 包
    • 輔助功能軟體包
    • 驅動程序
    • 滿足「流行」定義的軟體包所依賴的包，包括 makedeps 和 optdeps
    • 屬於同一集合併一起發布的軟體包，前提是這一集合的某些軟體包滿足「流行」定義
  • 任何其他不屬於上述例外的軟體包想要進入倉庫都需首先在 aur-general 郵件列表中提出申請，並解釋成為例外的原因（例如重命名的軟體包、新軟體包等）。軟體包進入倉庫需要其他三名 TU 同意。維護大量的「不流行」軟體包的 TU 的申請更有可能被拒絕。
  • 強烈建議 TU 移除 [community] 倉庫中他們正在維護的低使用率的軟體包。儘管離職的 TU 的軟體包在被採用之前會被過濾的情況會發生，移除的行為不會被強制要求
  • 軟體包從 AUR 提升到其它倉庫時，應該將 pkgrel 的數值加 1，這樣已經安裝了軟體包的用戶還可以繼續收到軟體自動更新。還有一個好處就是避免 pkgrel 重置為 1 時用戶收到本地軟體包更新的警告.

訪問並更新倉庫[編輯 | 編輯原始碼]

[community] 倉庫現在使用和 [core] 和 [extra] 倉庫相同的工具 devtools 來上傳軟體包。唯一的不同在於 [core] 和 [extra] 使用伺服器 https://archlinux.org 而 [community] 倉庫使用伺服器repos.archlinux.org。因此 Packager Guide 頁面中大多數指令都能在不用改動的情況下使用。這裡介紹關於 [community] 倉庫的一些特殊的信息。devtools 需要軟體打包人員 設置 makepkg.conf 中的 PACKAGER 變量.

首先，你應該做一個 [community] 軟體倉庫的 非遞歸簽出： 

$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community

這一步驟將會創建一個名為 svn-community 的目錄，裡面只有包含 svn 信息的 .svn 目錄。

關於 簽出，更新所有軟體包或添加一個軟體包，請參見 Packager Guide 。

要移除一個軟體包： 

$ ssh repos.archlinux.org /community/db-repo-remove community arch pkgname

每一個分割的軟體包都需要此操作，在此處及下文中，arch 應該是 x86_64， 這是在Arch 棄用 i686 之後 唯一支持的架構。

注意： 如果編輯的是 any 架構的軟體包，可以按 x86_64 執行，一般都能正常使用。

當你完成了 PKGBUILD 等之後，你應該 提交 你的更改（svn commit）。

用腳本 extra-x86_64-build 編譯軟體包. 如該要上傳到 testing，也需要運行 testing-x86_64-build.

用 gpg --detach-sign *.pkg.tar.xz 簽署軟體包. 如果使用不同密鑰進行簽名，可以在 ~/.makepkg.conf 中設置 GPGKEY=<identifier>.

如果你想要發布一個軟體包，首先將軟體包和簽名用 scp 拷貝到 repos.archlinux.org 的 staging/community 目錄下，然後通過進入 pkgname/trunk 目錄並運行 archrelease community-arch 來為 標識 該軟體包。這將在 community-x86_64 目錄下創建一份 trunk 條目的 svn 拷貝。這也表示這一軟體包已經在所在平台的 [community] 倉庫中了。注意 staging 目錄與 staging 倉庫不一樣，所有軟體包都需要上傳到 staging 目錄。可以使用 communitypkg 腳本自動執行這個過程。

軟體包更新匯總：

  • 更新 軟體包目錄 (svn update some-package)
  • 改變當前目錄 到軟體包的 trunk 目錄 (cd some-package/trunk)
  • 編輯 PKGBUILD，做出必要的更改，用 updpkgsums 更新校驗和.
  • 編譯 軟體包：使用 makechrootpkg 或 extra-x86_64-build. 必須在 乾淨的chroot環境 中構建軟體包。
  • Namcap PKGBUILD 文件和 pkg.tar.gz 二進位包
  • 使用 communitypkg "commit message" 提交、簽名，拷貝並標識 此軟體包。這將自動進行下面步驟
    • 將改變 提交 至 trunk (svn commit)
    • 簽署 軟體包: gpg --detach-sign *.pkg.tar.xz.
    • 將軟體包和簽名拷貝到 orion.archlinux.org (scp pkgname-ver-rel-arch.pkg.tar.xz *.pkg.tar.xz.sig repos.archlinux.org:staging/community/)
    • 標識 此軟體包 (archrelease community-x86_64)
  • 更新 軟體倉庫(ssh repos.archlinux.org /community/db-update)

另外請閱讀 Packager Guide 頁面的 Miscellaneours 部分和 SSH keys#ssh-agent。

停止維護軟體包[編輯 | 編輯原始碼]

如果一個 TU 不想再維護一個軟體包了，他應該在 AUR 郵件列表中發出一個通知，以便其他的 TU 可以繼續維護該軟體包。一個軟體包即是在沒有其他 TU 維護的情況下仍然能夠被一個 TU 停止維護。但是 TU 應該儘量不要放棄放棄很多軟體包（他們不應該負責超過他們時間允許的工作）。如果一個軟體包已經過時或者不再被使用，那麼也應該被完全移除。

如果一個軟體包已經被完全移除，它也可以重新上傳到 UNSUPPORTED，使得普通用戶可以替 TU 維護它。

將軟體包從 unsupported 移到 [community][編輯 | 編輯原始碼]

按照普通的向 community 倉庫添加軟體包的步驟即可，但是記得將相應的軟體包從 unsupported 中移除。

將軟體包從 [community] 移至 unsupported[編輯 | 編輯原始碼]

按照上面提到的方法移除軟體包，並將你的原始碼上傳到 AUR 即可。

將軟體包從 [community-testing] 移至 [community][編輯 | 編輯原始碼]

 $ ssh repos.archlinux.org /community/db-move community-testing community package

從 unsupported 刪除軟體包[編輯 | 編輯原始碼]

沒必要移除虛設的軟體包，因為他們會在試圖跟蹤依賴關係時被重新創建。如果有人上傳了一個實際的軟體包，那麼所有依賴的軟體包都會指向正確的位置。

在 build.archlinux.org 上遠程編譯[編輯 | 編輯原始碼]

警告： The following procedures defeats the Web Of Trust model: a user with root access to PKGBUILD.com could alter the package and/or the signature before it gets published.

TU 和開發者可以 SSH 到 build.archlinux.org,並使用 devtools 編譯軟體包。和本地編譯相比，這樣做有如下好處：

  • 編譯快，網絡快
  • 環境僅需要建立一次.
  • 本地系統可以不是 Arch Linux.

The process is similar to that of a local setup with devtools. Your GnuPG private is required for signing but you do not want to upload it for obvious security reasons. As such, you will need to forward the GnuPG agent socket from your local machine to the server: this will allow you to sign packages on the build server without communicating your key. This also means that we need to disable the agent on the server before we can run anything.

First, connect to build.archlinux.org and disable 

$ ssh build.archlinux.org
$ systemctl --user mask gpg-agent.service

Make sure gpg-agent is not running (systemctl --user stop gpg-agent.service). At this point, make sure that no sockets exist in the folder pointed by gpgconf --list-dir socketdir. If they do, remove them or log out and in again. If you have a custom $GNUPGHOME (eg. to move it to ~/.config/gnupg), you will need to unset that, as it is not possible in gnupg to set the homedir without setting the socketdir. On build.archlinux.org, StreamLocalBindUnlink yes is set in sshd_config, therefore removing the sockets manually on logout is not necessary.

While the PGP private keys remain on your local machine, the public keys must be on the build server. Export your public ring to the build server, e.g. from you local machine 

$ scp ~/.gnupg/pubring.gpg build.archlinux.org:~/.gnupg/pubring.gpg

SSH is required to checkout and commit to the SVN repository. You can either set up a new SSH key pair on the server (it is highly discouraged to put your local private key on a server for security reasons) or reuse your local keys via socket forwarding. If you opt for the latter, make sure to disable ssh-agent on the build server if you had enabled it previously (it is not running by default).

Configure you build environment on the build server: 

~/.makepkg.conf
PACKAGER="John Doe <john@doe.example>"
## Optional
PKGDEST="/home/johndoe/packages"
SRCDEST="/home/johndoe/sources"
SRCPKGDEST="/home/johndoe/srcpackages"
LOGDEST="/home/johndoe/logs"
## If your PGP key is not the default, specify the right fingerprint:
GPGKEY="ABCD1234..."
警告： Forwarding your gpg-agent socket to a remote machine makes it possible for anyone with root access to that system to use your unlocked GPG credentials. To circumvent this issue, we need to disable passphrase caching.

Disable passphrase caching with the following settings: 

gpg-agent.conf
default-cache-ttl 0
max-cache-ttl 0

Because we will want to keep our usual GPG agent running with its current settings, we are going to run another GPG agent dedicated to the task at hand. Create a ~/.gnupg-archlinux folder and symlink everything from ~/.gnupg there, except ~/.gnupg/gpg-agent.conf. Configure the new GPG agent: 

~/.gnupg-archlinux
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra
default-cache-ttl 0
max-cache-ttl 0
pinentry-program /usr/bin/pinentry-gtk-2

The gpg-agent-extra.socket will be forwarded to build.archlinux.org.

Start the dedicated agent with 

$ gpg-agent --homedir ~/.gnupg-archlinux --daemon

Connect with: 

$ ssh -R $REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org

or, if using GnuPG as your SSH agent: 

$ ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh:/run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org

Replace $REMOTE_UID and $LOCAL_UID by your user identifier as returned by id -u on the build server and locally, respectively. If using ssh-agent, replace $REMOTE_SSH_AUTH_SOCK by the path to the SSH socket on the remote host (it can be anything).

You can make the forwarding permanent for that host. For instance with gpg-agent.ssh: 

~/.ssh/config
Host build.archlinux.org
  RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent /run/user/$LOCAL_UID/gnupg/S.gpg-agent.extra
  RemoteForward /run/user/$REMOTE_UID/gnupg/S.gpg-agent.ssh /run/user/$LOCAL_UID/gnupg/S.gpg-agent.ssh

Again, replace $REMOTE_UID and $LOCAL_UID with their respective values.

From then on, the procedure should be exactly the same as a local build: 

$ ssh build.archlinux.org
$ svn checkout -N svn+ssh://svn-community@repos.archlinux.org/srv/repos/svn-community/svn svn-community
$ ...
注意： pinentry-curses might not work with socket forwarding. If it fails for you, try using a different pinentry.

TU 辭職需要完成的事項[編輯 | 編輯原始碼]

當一個 TU 辭去自己的職務，而且不再是一個開發者時，需要執行如下操作：

  1. 此 TU 的所有軟體包需要被重新簽名(重新打包). TU 編譯的軟體包可以通過下面 URL 從 Archweb 查詢 https://archlinux.org/packages/?sort=&q=&packager=$packager&flagged= where packager 替換成 TU 在 Archweb 的用戶名.
  2. Archweb 需要禁用此 TU 帳號，並添加到 'Retired Trusted users' 組. 從 'Trusted Users' 移除此 TU，軟體倉庫權限收回。
  3. 從伺服器上禁用此帳號的 shell 訪問權限(尤其是 repos.archlinux.org, pkgbuild.com)
  4. 移除此用戶的 GPG key，倉庫中提交新的 archlinux-keyring 軟體包。在 keyring 項目中創建任務，刪除辭職人員的密鑰。
  5. 從 AUR 帳號中刪除此 TU 帳號.
  6. Arch wiki bureaucrat 將他們的帳號移出 ⧼group-archtu⧽ 組。
  7. BBS 管理員 修改論壇的帳號。
取自「https://wiki.archlinuxcn.org/wzh/index.php?title=AUR_Trusted_User_guidelines&oldid=24313」