You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Dominik Psenner <dp...@apache.org> on 2018/06/12 14:05:55 UTC
[log4net] crafting the next release
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/
Re: [log4net] crafting the next release
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-18, Dominik Psenner wrote:
> On Mon, 18 Jun 2018, 09:12 Stefan Bodewig, <bo...@apache.org> wrote:
>> Do you know how to create the oldkeys binaries? Or will we just no
>> longer provide them (I could live with that).
> I have no idea, yet. :-) people had a long time to adapt to newkey
> binaries. If they have not migrated yet, they can as well do now.
OK.
> Do you have preferences on the version? I opt for 2.1.0 but would be fine
> with 2.0.9 too.
2.1.0 is fine with me.
Thanks for putting in all the work
Stefan
Re: [log4net] crafting the next release
Posted by Dominik Psenner <dp...@gmail.com>.
On Mon, 18 Jun 2018, 09:12 Stefan Bodewig, <bo...@apache.org> wrote:
> On 2018-06-17, Dominik Psenner wrote:
>
> > Am Fr., 15. Juni 2018 um 10:53 Uhr schrieb Stefan Bodewig <
> > bodewig@apache.org>:
>
> >> On 2018-06-13, Dominik Psenner wrote:
>
> >>> That is possible. I restricted access to the github token to the
> log4net
> >>> build job only. Stefan, would you like to try whether you can gain
> access
> >>> to that token? I can guide you to where you can find it off-list.
>
> >> Sorry, still travelling. Even if I don't manage to see the token, it is
> >> only going to prove to me that I'm not skilled enough :-)
>
> > I'm sure that wouldn't be the case. All popular ci systems provide secret
> > environment variables as a feature. Without that most devops usecases
> > wouldn't be possible.
>
> Access to most of the CI systems used for said devops use cases is
> controlled much more tightly then to our Jenkins, though.
>
> >> Personally I'd want to verify the contents of the archive anyway (as
> >> part of vetting the relase) and don't see any problem with signing them
> >> offline on my own machine at that point in time (or anybody else of us
> >> doing so). To me signing and uploading the ZIPs to dist.a.o doesn't have
> >> to be automated, YMMV.
>
> > We can agree to keep a few manual steps as long as these steps are as few
> > as possible. Signing and uploading to dist.a.o and nuget can be one of
> them.
>
> Fine with me.
>
> > If there are no objections I would freeze the codebase in 72h from now by
> > creating a release branch from whatever commit develop points to on
> > 2018-06-17 at 21:30 CEST (19:30 UTC).
>
> Do you know how to create the oldkeys binaries? Or will we just no
> longer provide them (I could live with that).
>
I have no idea, yet. :-) people had a long time to adapt to newkey
binaries. If they have not migrated yet, they can as well do now.
Do you have preferences on the version? I opt for 2.1.0 but would be fine
with 2.0.9 too.
Re: [log4net] crafting the next release
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-17, Dominik Psenner wrote:
> Am Fr., 15. Juni 2018 um 10:53 Uhr schrieb Stefan Bodewig <
> bodewig@apache.org>:
>> On 2018-06-13, Dominik Psenner wrote:
>>> That is possible. I restricted access to the github token to the log4net
>>> build job only. Stefan, would you like to try whether you can gain access
>>> to that token? I can guide you to where you can find it off-list.
>> Sorry, still travelling. Even if I don't manage to see the token, it is
>> only going to prove to me that I'm not skilled enough :-)
> I'm sure that wouldn't be the case. All popular ci systems provide secret
> environment variables as a feature. Without that most devops usecases
> wouldn't be possible.
Access to most of the CI systems used for said devops use cases is
controlled much more tightly then to our Jenkins, though.
>> Personally I'd want to verify the contents of the archive anyway (as
>> part of vetting the relase) and don't see any problem with signing them
>> offline on my own machine at that point in time (or anybody else of us
>> doing so). To me signing and uploading the ZIPs to dist.a.o doesn't have
>> to be automated, YMMV.
> We can agree to keep a few manual steps as long as these steps are as few
> as possible. Signing and uploading to dist.a.o and nuget can be one of them.
Fine with me.
> If there are no objections I would freeze the codebase in 72h from now by
> creating a release branch from whatever commit develop points to on
> 2018-06-17 at 21:30 CEST (19:30 UTC).
Do you know how to create the oldkeys binaries? Or will we just no
longer provide them (I could live with that).
Stefan
Re: [log4net] crafting the next release
Posted by Dominik Psenner <dp...@gmail.com>.
Am Fr., 15. Juni 2018 um 10:53 Uhr schrieb Stefan Bodewig <
bodewig@apache.org>:
> On 2018-06-13, Dominik Psenner wrote:
>
> > That is possible. I restricted access to the github token to the log4net
> > build job only. Stefan, would you like to try whether you can gain access
> > to that token? I can guide you to where you can find it off-list.
>
> Sorry, still travelling. Even if I don't manage to see the token, it is
> only going to prove to me that I'm not skilled enough :-)
>
I'm sure that wouldn't be the case. All popular ci systems provide secret
environment variables as a feature. Without that most devops usecases
wouldn't be possible.
>
> Personally I'd want to verify the contents of the archive anyway (as
> part of vetting the relase) and don't see any problem with signing them
> offline on my own machine at that point in time (or anybody else of us
> doing so). To me signing and uploading the ZIPs to dist.a.o doesn't have
> to be automated, YMMV.
>
We can agree to keep a few manual steps as long as these steps are as few
as possible. Signing and uploading to dist.a.o and nuget can be one of them.
If there are no objections I would freeze the codebase in 72h from now by
creating a release branch from whatever commit develop points to on
2018-06-17 at 21:30 CEST (19:30 UTC). I would then like to proceed with the
release and I hope that more people will join in and test the binaries
while we prepare the release. Thinking about what Gary did lately with
log4j auditing, it may be a good idea to start one or more github projects
that implement sample usecases for log4net. Everyone could then use those
projects to do a thorough testing of a release.
--
Dominik Psenner
Re: [log4net] crafting the next release
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-13, Dominik Psenner wrote:
> That is possible. I restricted access to the github token to the log4net
> build job only. Stefan, would you like to try whether you can gain access
> to that token? I can guide you to where you can find it off-list.
Sorry, still travelling. Even if I don't manage to see the token, it is
only going to prove to me that I'm not skilled enough :-)
Personally I'd want to verify the contents of the archive anyway (as
part of vetting the relase) and don't see any problem with signing them
offline on my own machine at that point in time (or anybody else of us
doing so). To me signing and uploading the ZIPs to dist.a.o doesn't have
to be automated, YMMV.
Stefan
Re: [log4net] crafting the next release
Posted by Dominik Psenner <dp...@gmail.com>.
That is possible. I restricted access to the github token to the log4net
build job only. Stefan, would you like to try whether you can gain access
to that token? I can guide you to where you can find it off-list.
On Wed, 13 Jun 2018, 17:40 Ralph Goers, <ra...@dslextreme.com> wrote:
> Jenkins does have a way of storing credentials. However, I don’t know if
> there is a way to limit which jobs can use the credentials.
>
> Ralph
>
> > On Jun 13, 2018, at 6:48 AM, Stefan Bodewig <bo...@apache.org> wrote:
> >
> > On 2018-06-13, Dominik Psenner wrote:
> >
> >> 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?
> >
> > Maybe just because I'm paranoid. How would you store the private part of
> > a PGP key in Jenkins in a way that cannot be compromised by people who
> > log in to Jenkins or a malicious Jenkins addon that gets installed?
> >
> > Stefan
> >
>
>
>
Re: [log4net] crafting the next release
Posted by Ralph Goers <ra...@dslextreme.com>.
Jenkins does have a way of storing credentials. However, I don’t know if there is a way to limit which jobs can use the credentials.
Ralph
> On Jun 13, 2018, at 6:48 AM, Stefan Bodewig <bo...@apache.org> wrote:
>
> On 2018-06-13, Dominik Psenner wrote:
>
>> 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?
>
> Maybe just because I'm paranoid. How would you store the private part of
> a PGP key in Jenkins in a way that cannot be compromised by people who
> log in to Jenkins or a malicious Jenkins addon that gets installed?
>
> Stefan
>
Re: [log4net] crafting the next release
Posted by Matt Sicker <bo...@gmail.com>.
I don’t think that’s possible with vanilla Jenkins. May need to use some
secrets manager on top like Vault. Essentially, anyone with access to
configure jobs can extract stored credentials.
On Wed, Jun 13, 2018 at 09:48, Stefan Bodewig <bo...@apache.org> wrote:
> On 2018-06-13, Dominik Psenner wrote:
>
> > 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?
>
> Maybe just because I'm paranoid. How would you store the private part of
> a PGP key in Jenkins in a way that cannot be compromised by people who
> log in to Jenkins or a malicious Jenkins addon that gets installed?
>
> Stefan
>
--
Matt Sicker <bo...@gmail.com>
Re: [log4net] crafting the next release
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-06-13, Dominik Psenner wrote:
> 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?
Maybe just because I'm paranoid. How would you store the private part of
a PGP key in Jenkins in a way that cannot be compromised by people who
log in to Jenkins or a malicious Jenkins addon that gets installed?
Stefan
Re: [log4net] crafting the next release
Posted by Dominik Psenner <dp...@gmail.com>.
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 <bo...@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, <bo...@gmail.com> wrote:
>>>> Will you be signing and uploading them locally or via Jenkins?
>>>> On Tue, Jun 12, 2018 at 10:05, Dominik Psenner <dp...@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 <bo...@gmail.com>
>> --
> Matt Sicker <bo...@gmail.com>
>
Re: [log4net] crafting the next release
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@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, <bo...@gmail.com> wrote:
>
> >> Will you be signing and uploading them locally or via Jenkins?
>
> >> On Tue, Jun 12, 2018 at 10:05, Dominik Psenner <dp...@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 <bo...@gmail.com>
>
> --
Matt Sicker <bo...@gmail.com>
Re: [log4net] crafting the next release
Posted by Stefan Bodewig <bo...@apache.org>.
[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, <bo...@gmail.com> wrote:
>> Will you be signing and uploading them locally or via Jenkins?
>> On Tue, Jun 12, 2018 at 10:05, Dominik Psenner <dp...@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 <bo...@gmail.com>
Re: [log4net] crafting the next release
Posted by Dominik Psenner <dp...@gmail.com>.
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, <bo...@gmail.com> wrote:
> Will you be signing and uploading them locally or via Jenkins?
>
> On Tue, Jun 12, 2018 at 10:05, Dominik Psenner <dp...@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 <bo...@gmail.com>
>
Re: [log4net] crafting the next release
Posted by Matt Sicker <bo...@gmail.com>.
Will you be signing and uploading them locally or via Jenkins?
On Tue, Jun 12, 2018 at 10:05, Dominik Psenner <dp...@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 <bo...@gmail.com>