[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upcoming 0.26.0, please review release notes

From: Yavor Doganov
Subject: Re: Upcoming 0.26.0, please review release notes
Date: Fri, 8 Dec 2017 11:28:04 +0000 (UTC)
User-agent: Pan/0.142 (He slipped to Sam a double gin; 01b5bf4

В Fri, 08 Dec 2017 10:55:14 +0000, Ivan Vučica написа:
> On Fri, Dec 8, 2017, 10:18 Yavor Doganov <address@hidden> wrote:

> I will sign the tag with my personal key (otherwise GH would not display
> it as verified) and I will sign the tarball with the shared maintainer
> key, as is the usual practice.

OK, I thought that GitHub automatically generates tarballs from git
tags, at least this is what I observed with SimpleAgenda.  So it is
slightly consufing for me how the tag can be signed with one signature
and the tarball with another.  Anyway, these details are not so
important for me, as long as the tarball is signed with the proper key.

> Please use as the primary distribution point.

OK, thanks.

>> P.S.  I'd suggest to advertise widely this new feature of GNUstep Make
>>       and recommend that all developers GPG-sign their releases.
> My understanding is that was already the practice for GNUstep core
> project?
> :-)
> What I mean is: we are already supposed to sign the tarballs.

GNUstep core packages have always been signed, I think.  But there are
lots of unsigned tarballs at and the other non-core
distribution locations (GAP, gnustep-nonfsf, gsimages, etc.).  Some
maintainers sign a particular release and then don't sign the next
which is a problem for Debian packaging, because once you setup the
package to verify upstream's signature, a subsequent release that is
not GPG-signed will be rejected by the archive management software.

> The only new thing is signing tags, which I'm doing more for fun than
> anything else:

Well, signing tags is a good practice from security POV.  Some people
even insist that each commit should be GPG-signed.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]