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#26729 - Implement -U --no-signature

Attached to Project: Pacman
Opened by Thomas Bächler (brain0) - Thursday, 03 November 2011, 14:31 GMT
Last edited by Allan McRae (Allan) - Thursday, 07 February 2013, 00:55 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To Dan McGee (toofishes)
Allan McRae (Allan)
Architecture All
Severity Medium
Priority High
Reported Version 4.0.0
Due in Version 4.1.0
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

When the package signing infrastructure is fully implemented, users will want to use pacman with 'SigLevel = (Package)Required'. On the other hand, not every AUR user has a personal key for signing packages as a trusted key in their own pacman keyring.

When you use a PKGBUILD to build and install a package locally, there is no need to first sign it and then verify the signature. With 'SigLevel = PackageRequired', pacman -U will refuse to install an unsigned package, requiring the user to modify pacman.conf (set SigLevel=PackageOptional), and later revert the modification.

For the convenience of using locally built packages, a '--no-signature' flag for the '-U' operation should be implemented.

Optionally, this flag could be restricted to only take effect when installing a local file, instead of a URL.
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 07 February 2013, 00:55 GMT
Reason for closing:  Implemented
Additional comments about closing:  pacman.conf options added in 33b3b6d9
Comment by Dan McGee (toofishes) - Thursday, 03 November 2011, 15:01 GMT
Preliminary thoughts here:

1. Do as proposed
2. Add a 'UpgradeSigLevel' parameter or similar. This would be the level used on -U operations if specified (as opposed to SigLevel being used for -S operations). The name is a tad misleading, however.
3. 2 + 'UpgradeUrlSigLevel' or similar. Only to be complete, and from what I think I know, there are three basic ways to install a package: 1) locally from a file, 2) remotely from a URL, and 3) sync operation.
Comment by Thomas Bächler (brain0) - Thursday, 03 November 2011, 17:22 GMT
My thoughts, how I think it should be (just clarifying what I already said, combined with what you said):

1) locally from a file (-U)

Either allow overriding the SigLevel from the command line (still my favorite), or allow to configure a different SigLevel for this operation only.

2) remotely from a URL (-U)
3) sync operation (-S)

Only way to override SigLevel is to change SigLevel in pacman.conf. No convenience options or overrides.

IMHO, this allows for the best usability for the casual AUR user while at the same time keeping the user from "doing stupid things".


OTOH, what I just said is inconsistent: We already allow different SigLevels for different repos, so we could treat case 1) and 2) like repositories - a virtual "-U local file" and "-U url" repository.
Comment by Allan McRae (Allan) - Thursday, 03 November 2011, 22:17 GMT
My only issue with adding command line options is there would need to be a lot to allow flexibility or just an "--ignore-sig" type option which is too heavy handed. e.g. I used "pacman -U <local file>" on a file with a detached sig and got a failure because the key was not fully trusted. So I would maybe like to add TrustAll for that.

Loading...