%PGPSIG% vs .sig

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

%PGPSIG% vs .sig

Brandon Milton
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: %PGPSIG% vs .sig

Allan McRae
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: %PGPSIG% vs .sig

Bruno Pagani-2
In reply to this post by Brandon Milton
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.


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: %PGPSIG% vs .sig

David Phillips-2
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.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: %PGPSIG% vs .sig

David Phillips-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: %PGPSIG% vs .sig

Brandon Milton
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-arch-linux/

On Mon, May 29, 2017 at 2:23 PM, David Phillips <[hidden email]> 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
[hidden email]
http://brandonio21.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: %PGPSIG% vs .sig

David Phillips-2
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-arch-linux/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: %PGPSIG% vs .sig

Eli Schwartz
In reply to this post by Brandon Milton
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


signature.asc (849 bytes) Download Attachment
Loading...