[pacman-dev] %PGPSIG% vs .sig
Hello all, This is my first post to the mailing list, so please feel free to correct me if I'm in the wrong place. While exploring the pacman mirror layout (ie what is hosted by mirrors), I noticed that for each package, there are two copies of the same signature: one in %PGPSIG% in the desc file of the database and one in the {package}-{version}.pkg.tar.gz.sig file I understand that for the AUR, the .sig file is necessary given that there is no official database. However, is there any reasoning behind having two copies of the signature for official repositories? To me, this simply seems like extra cruft that mirrors have to carry around. Thanks /brandon
On 29/05/17 15:31, Brandon Milton wrote:
Hello all,
This is my first post to the mailing list, so please feel free to correct me if I'm in the wrong place.
While exploring the pacman mirror layout (ie what is hosted by mirrors), I noticed that for each package, there are two copies of the same signature: one in %PGPSIG% in the desc file of the database and one in the {package}-{version}.pkg.tar.gz.sig file
I understand that for the AUR, the .sig file is necessary given that there is no official database. However, is there any reasoning behind having two copies of the signature for official repositories? To me, this simply seems like extra cruft that mirrors have to carry around.
pacman -U http://.... will download a signature file for the package if one is present.
Le 29/05/2017 à 07:31, Brandon Milton a écrit :
While exploring the pacman mirror layout (ie what is hosted by mirrors), I noticed that for each package, there are two copies of the same signature: one in %PGPSIG% in the desc file of the database and one in the {package}-{version}.pkg.tar.gz.sig file
I understand that for the AUR, the .sig file is necessary given that there is no official database.
Just one thing: AFAIK, they are no .sig files in the AUR.
On Mon, May 29, 2017 at 10:37:02PM +0200, Bruno Pagani wrote:
Just one thing: AFAIK, they are no .sig files in the AUR.
Of course not; the AUR does not host any built packages. Only built packages have .sig files. On the other hand, you can configure makepkg to sign the packages it builds and this will generate a .sig file when you build a package locally.
On Tue, May 30, 2017 at 09:17:28AM +1200, David Phillips wrote:
On Mon, May 29, 2017 at 10:37:02PM +0200, Bruno Pagani wrote:
Just one thing: AFAIK, they are no .sig files in the AUR.
Of course not; the AUR does not host any built packages. Only built packages have .sig files.
On the other hand, you can configure makepkg to sign the packages it builds and this will generate a .sig file when you build a package locally.
Pardon me, I got the wrong end of the stick and thought you were replying to Allan, the tone of my message isn't what it should be. Thanks
Thank you for the clarification. After reading Allan's blog post regarding keychain separation [1], I understand where my confusion was. To reiterate what I've learned: The .sig file allows the user to download a built package and verify it outside of a database setting using `pacman -U`. The .sig files in the AUR are entirely different than those used by pacman, as they verify the source files, not the generated .tar.xz files. Furthermore, there should never be a .sig file for a .tar.xz resulting from `makepkg` since the generated binaries are system-independent. Thank you all for your help. [1] http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arc... On Mon, May 29, 2017 at 2:23 PM, David Phillips <david@sighup.nz> wrote:
On Tue, May 30, 2017 at 09:17:28AM +1200, David Phillips wrote:
On Mon, May 29, 2017 at 10:37:02PM +0200, Bruno Pagani wrote:
Just one thing: AFAIK, they are no .sig files in the AUR.
Of course not; the AUR does not host any built packages. Only built packages have .sig files.
On the other hand, you can configure makepkg to sign the packages it builds and this will generate a .sig file when you build a package locally.
Pardon me, I got the wrong end of the stick and thought you were replying to Allan, the tone of my message isn't what it should be.
Thanks
-- -Brandon Milton brandon.milton21@gmail.com http://brandonio21.com
On Mon, May 29, 2017 at 02:33:29PM -0700, Brandon Milton wrote:
Thank you for the clarification. After reading Allan's blog post regarding keychain separation [1], I understand where my confusion was.
To reiterate what I've learned:
The .sig file allows the user to download a built package and verify it outside of a database setting using `pacman -U`.
That is correct.
The .sig files in the AUR are entirely different than those used by pacman, as they verify the source files, not the generated .tar.xz files.
Yes. They are the same type of file, and will be generated in much the same way, but the domains in which they are used are separate, like you say.
Furthermore, there should never be a .sig file for a .tar.xz resulting from `makepkg` since the generated binaries are system-independent.
I would not say that this is correct. makepkg can help you to generate .sig files for the .pkg.tar.xz built packages that it outputs. However, this is rarely done for AUR packages unless the builder is distributing the package in binary form, for example, to put on an Unofficial User Repository hosting package binaries.
Thank you all for your help.
[1] http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arc...
On 05/29/2017 04:33 PM, Brandon Milton wrote:
Thank you for the clarification. After reading Allan's blog post regarding keychain separation [1], I understand where my confusion was.
To reiterate what I've learned:
The .sig file allows the user to download a built package and verify it outside of a database setting using `pacman -U`.
Correct. Although I believe it has been suggested that pacman start downloading the sig files instead of bundling it in the repo database, to save on size. (This will help prevent the size from exploding if source packages are added to the databases as well.)
The .sig files in the AUR are entirely different than those used by pacman, as they verify the source files, not the generated .tar.xz files. Furthermore, there should never be a .sig file for a .tar.xz resulting from `makepkg` since the generated binaries are system-independent.
Not strictly correct. sig files for upstream sources are linked in the PKGBUILD sources=() array when upstream sources have them available, and sig files for a .pkg.tar.xz are generated by makepkg --sign or when makepkg.conf contains BUILDENV=(sign) -- that is to say, when the user requests it... which generally doesn't happen unless the user is hosting a binary repo. (Ignore the fact that the official repos don't use this, and instead call gpg when uploading the built package.) Binaries are not necessarily system-dependent. Only the ones with automagic dependencies, or compiled with -march=native, should be. This is also why building in a clean chroot helps, as it uses a minimal set of installed packages and a chroot-specific makepkg.conf with stock values. -- Eli Schwartz
participants (5)
-
Allan McRae
-
Brandon Milton
-
Bruno Pagani
-
David Phillips
-
Eli Schwartz