Having never signed release artifacts before, I'm likely to Do It Wrong. Is
there any Signing For Dummies you could recommend to get going on the right
foot?
-d
On August 2, 2020 21:31:43 Matt Sicker <boa...@gmail.com> wrote:
So far it looks good (though I'm not a .net developer, so I can't
speak from that side). There's one more thing we need from this to
make it a proper release. You'll need to add a GPG signature for the
artifacts as well. We'll need to import your signing key to
https://downloads.apache.org/logging/KEYS for users to verify the
release is genuine. Please email me a copy of your public key for that
so I can sign and add it to our KEYS file. This key should be an RSA
4096-bit GPG key, and it should also be uploaded to a public keyserver
like https://sks-keyservers.net/
For signing the files, add a detached ascii signature file (.asc) for
the distributable files. As a bonus, you can also sign the git tag you
created with the same key, but that's not required.
On Fri, 31 Jul 2020 at 01:28, Davyd McColl <dav...@gmail.com> wrote:
Apologies if there's any confusion around sender address -- I've already
fluffed this by sending from my work account (default in my mail client)
-d
On 2020/07/31 08:26:54, Davyd McColl <davyd.mcc...@codeo.co.za> wrote:
Hi all, I've never done this before, so bear with me if I fluff it:
This is a proposed vote to release log4net 2.0.9 from PR
https://github.com/apache/logging-log4net/pull/61
Release artifacts (including source zip) are at:
https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/34063235/artifacts
Source can be checked out from
https://github.com/fluffynuts/logging-log4net/logging-log4net, tag
rel/2.0.9. I can't push tags to the upstream, but this tag is exactly the
same commit as the last in the PR mentioned above, which was accepted into
master a few days ago.
Please check out the artifacts & if everyone is ok with what's there,
please can someone with the rights to publish to nuget do so.
Once I've seen how this process works, I'd like to tackle the CVE that has
been brought up on this list more than once -- it's a simple change which
was already committed to the develop branch some time ago, so there are a
couple of options here:
1. cherry-pick that commit & do a 2.0.10 release pronto, with only that change
2. trawl the develop branch to see what else was already solved in there,
and get that out as 2.0.10, and perhaps close out that branch to avoid
future confusion.
Thanks for your time
-d
--
Matt Sicker <boa...@gmail.com>