Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#75209 - A concern regarding part of the .BUILDINFO file

Attached to Project: Pacman
Opened by Saphira Kai (SaphiraKai) - Friday, 01 July 2022, 14:48 GMT
Last edited by Allan McRae (Allan) - Friday, 23 December 2022, 14:02 GMT
Task Type General Gripe
Category makepkg
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 6.0.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I and a small group of Arch Linux users have concerns regarding the `installed` field of the .BUILDINFO file generated by makepkg. Obviously this field is very useful for reproducing builds and tracking down packaging issues, but we find the fact that it stores that information by default and without any warning concerning. Privacy is one obvious issue, as is the potential security issue of listing the versions of all packages, including services that may be internet-facing. Of course Arch is intended to be kept up to date at all times, but this unfortunately doesn't always happen, likewise the issue *if known about* can be easily solved by building in a chroot or container or by simply editing the file, however it's not at all obvious without having dissected packages before that this information is being stored in the first place.

We would very much like to see this feature made opt-in with a command line flag, or even simply having makepkg print a notice that states that all packages installed on the system running makepkg are recorded in the built package. We don't believe such changes would have a negative impact on experienced users who are already well aware of this behavior and make use of it regularly, they would only serve to prevent any issues from arising due to being uninformed about this feature.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 23 December 2022, 14:02 GMT
Reason for closing:  Not a bug
Additional comments about closing:  working as intended
Comment by Doug Newgard (Scimmia) - Friday, 01 July 2022, 15:00 GMT
If you're building packages that you're going to be distributing, you really need to be building in a clean chroot/container anyway. Even building for yourself only, you should be doing it.
Comment by Saphira Kai (SaphiraKai) - Friday, 01 July 2022, 15:20 GMT
Our issue isn't that there is no solution to the problem, it's just a lack of communication about what's being stored. People might simply decide using a chroot just isn't worth the hassle, and you can agree or disagree with that choice, but it's a lot more likely they would decide to use one if they were aware that there's more at stake than just good practices.
Comment by Morten Linderud (Foxboron) - Friday, 01 July 2022, 15:35 GMT
You are building and distributing packages. Any build system can store any number of basic facts about the system it's built on, right? If you have a wide enough definition of what constitutes a privacy violation, where build details embedded into artifacts is part of this, then you need to take the steps to limit your own exposure.

I personally don't understand why any extremely privacy conscious person would build any binary on their system and distribute it widely without understand the implications.
Comment by Allan McRae (Allan) - Saturday, 02 July 2022, 01:10 GMT
Currently makepkg does output "-> Generating .BUILDINFO file...", and "man BUILDINFO" provides details of what is stored. So there is some notification, though limited. I'll also note that various software versions are already embedded in many binaries, hence the need for installed package details for reproducibility.


Loading...