[aur-general] Updating AUR versions server side

[Alad Wenter]

Excerpts from Jeremy Audet via aur-general's message of November 5, 2019 7:51 pm:
>> > What if regular, non development, AUR packages were tested server side
>> > for new versions?
>> > Won't that make more sense than the maintainer having to run pkgver()
>> > manually from time to time?
>>
>> We shall not evaluate user-uploaded shellscripts on the AUR server. Most
>> AUR helpers provide a --devel option to download packages with a
>> pkgver() function and check them for updates.
>>
>> Non-development AUR packages are not permitted to change their version
>> just by running makepkg and having the pkgver() update it, since this
>> implies that the non-development AUR package uses VCS sources that are
>> not pinned to a specific commit or tag.
>>
>> Please report such package violations for deletion or other corrective
>> measures.
> 
> To expand on Eli's answer: executing arbitrary shell scripts is dangerous. It might be possible to constrain the damage that could be inflicted through aggressive use of sandboxing mechanisms (e.g. standing up a container with systemd-nspawn and locking it down with directives like PrivateNetwork=true), but this would break pkgver() for VCS packages, and this is also just begging for trouble. I believe the .SRCINFO file was added so that the AUR could discover a PKGBUILD's version without needing to evaluate arbitrary scripts.
> 
As far as I know the AUR did not, at any point, evaluate arbitrary 
scripts to retrieve metadata. It did parse (or attempt to...) the 
PKGBUILD.

See also: <https://wiki.archlinux.org/index.php/.SRCINFO>

Alad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20191105/c3bbf4f2/attachment.sig>