Introducing `pkglint` and the AUR Report Card

Jamison · Today 05:39:40

I wanted to share with the community a project I started recently.

At the core is an AST-based linter for PKGBUILDs, https://github.com/jmelahman/pkglint (AUR). I had previously been running namcap in CI to validate my PKGBUILDs, but I wanted a bit more ergonomics like pre-commit hooks and focus on security rather than build correctness. Another nice feature is that it can automatically fix some issues. See rule reference for descriptions and examples of each rule currently supported. It's still a WIP and I am very open to feedback.

I used this linter to generate the AUR Report Card. I ran `pkglint` on the top 500 packages + all packages that have been updated in the last 90 days and recorded their scores. My hope isn't to say that packages that score low are vulnerable and shouldn't be trusted, but to raise of awareness that improvements could be made (and easily with `pkglint --fix`). On the dashboard, you can search for packages by name or maintainer if you want to see how the packages you maintain stack up

Also, each package in the report comes with a badge that automatically update so that maintainers can boast about their high scores in their READMEs (https://jamison.lahman.dev/pkglint/badge/prek.svg)

___

This project was largely inspired by https://goreportcard.com/ (RIP).

edit: Sorry, I'm new to the forum. I suspect this belongs in Community Contributions.

Last edited by Jamison (Today 05:57:35)

loqs · Today 06:01:42

pkglint does not appear to recognize unpinned git repo's being used as git submodules where the git checkout used is the submodule of the main project and is pinned by the main project itself. pkglint also suggests all git based checkout should be pinned by commit even when the tag is confirmed by the checksum array. Pinning by commit breaks `pkgctl build` auto updating pkgver which in turn is expected to update the sources array.

Have you considered opening merge requests against the linux and systemd packages or other packages in the official core repository that pkglint rates as F to fix the detected issues?

Last edited by loqs (Today 06:12:04)

Jamison · Today 06:36:07

> pkglint does not appear to recognize unpinned git repo's being used as git submodules where the git checkout used is the submodule of the main project and is pinned by the main project itself. pkglint also suggests all git based checkout should be pinned by commit even when the tag is confirmed by the checksum array. Pinning by commit breaks `pkgctl build` auto updating pkgver which in turn is expected to update the sources array.

Really appreciate the feedback. These are all really good. I suspect there are a decent number of edge cases I am not familiar with, so this helps a lot.

> Have you considered opening merge requests against the linux and systemd packages or other packages in the official core repository that pkglint rates as F to fix the detected issues?

Absolutely. I want to improve this a bit before making too much noise for maintainers. I suspect most F's are false positives anyways, and it might be possible to filter them better with a bit more custom logic (my bash has gotten rusty unfortunately).

Something else I am very interested in getting involved with is the reproduce package builds initiative (I didn't know that was a thing until I started working on this). I would love to be able to use a tool like this to statically determine if a package build can be reproduced (or maybe at least the inverse).

schard · Today 07:28:41

Mod note: Moving to Community Contributions.

Lone_Wolf · Today 09:49:39

The report card doesn't allow searching for co-maintainers.

https://jamison.lahman.dev/pkglint/pack … l-git.html

Mesa uses rust crates as meson subprojects. Which crates & versions are needed depends on the build flags and can change without prior warning.

To the best of my knowledge meson has no method to allow downloading subprojects outside of meson and use them in meson.
Hacks are needed to ensure downloading/using these crates stays under control of makepkg/PKGBUILD.

To manage this archlinux mesa devs added an array to the pkgbuild and create the download urls dynamically at runtime, then add them to source= array.

TL;DR:
.SRCINFO is created from a static version of the pkgbuild , the PKGBUILD itself can (and sometimes will ) change dynamically.
This can lead to situations like this where .SRCINFO deviates from the PKGBUILD and both are correct.

Arch Linux

#1 Today 05:39:40

Introducing `pkglint` and the AUR Report Card

#2 Today 06:01:42

Re: Introducing `pkglint` and the AUR Report Card

#3 Today 06:36:07

Re: Introducing `pkglint` and the AUR Report Card

#4 Today 07:28:41

Re: Introducing `pkglint` and the AUR Report Card

#5 Today 09:49:39

Re: Introducing `pkglint` and the AUR Report Card

Board footer