My previous mail was strongly biased by what we should do with the old
key binaries but that is another topic we have to get consensus about.
As far as the gpg signing of the artifacts goes, it will have to stay a
manual process. Just like updating the site and publishing artifacts is
also a manual step that needs to be done by the release moderator after
the poll has completed. I would however prefer an automated process.
As far as I can tell, the secrets stored in jenkins.a.o are trustworthy.
For instance I used a github access token generated from my github
account that grants jenkins access to the log4net-logging repository on
github. I am convinced that nobody else can steal that token without
logging in to jenkins using my credentials. Stefan, would you please
elaborate the reasonings of why you do not trust pgp signatures issued
by builds.a.o?
Binaries shipped via NuGet are not pgp signed and people will have to
hash check the binaries against the hash of official binaries available
via apache mirrors in case they want to verify that these binaries are
genuine.
On 2018-06-13 13:33, Matt Sicker wrote:
Yes, I was talking about GPG, totally forgot about other artifact signing.
Even Java supports that despite barely anyone using it. And I’ve created
dedicated GPG keys in the past for continuous deployment to Maven Central,
but not in a public Jenkins instance.
On Wed, Jun 13, 2018 at 06:58, Stefan Bodewig <bode...@apache.org> wrote:
[Sorry for the top post]
I think Matt and you are talking about different "signing" processes.
.NET assemblies can be signed (strong named) and for some releases now
we've used a key that is checked into git for one distribution archive
(no credential needed, everything is in git) that is labeled as
"newkey". These are the assemblies used inside the nuget package as well
and CI already builds them,
The other zip (oldkey) is signed by a different key that we keep secret
deliberately. A pgp encrypted version of the key is inside the git
repo. So far every release manager had to decrypt that locally and build
the releases locally.
Matt, I think, has been talking about the PGP signature on the resulting
ZIPs. At least I wouldn't trust any key that can be used by Jenkins :-)
Stefan
On 2018-06-12, Dominik Psenner wrote:
That's an interesting question to ask. As I see it, ci should produce
good
and final artifacts. This means that ci should also sign them in the
pipeline. We can inject required keys and credentials with secret
variables
to make it work. These credentials are then only accessible to whoever
has
access to jenkins. I have right now no idea how the binaries are signed
today. There surely are targets to do so but I have not found them, yet.
Stefan, can you point me into the right direction?
Thanks matt for pointing out yet another thing that we are probably
missing
in the ci pipeline.
On Tue, 12 Jun 2018, 18:54 Matt Sicker, <boa...@gmail.com> wrote:
Will you be signing and uploading them locally or via Jenkins?
On Tue, Jun 12, 2018 at 10:05, Dominik Psenner <dpsen...@apache.org>
wrote:
Hi,
our CI is ready to supply us with binaries along with the log4net
website. This will be the first time that binaries from the CI are
shipped as a release. Therefore we seek out for volunteers who evaluate
the CI binaries [1]. Doing so is a great help and allows us to take the
next steps of shipping the next release of log4net.
Best regards,
Dominik
[1]
https://builds.apache.org/job/logging-log4net/job/develop/lastSuccessfulBuild/artifact/
--
Matt Sicker <boa...@gmail.com>
--
Matt Sicker <boa...@gmail.com>
