Re: [VOTE] Release Log4j Audit 1.0.0 RC1

2018-06-13 Thread Ralph Goers
My +1. Remko voted +1 on a different thread. We still need one more vote. Ralph > On Jun 10, 2018, at 2:26 PM, Ralph Goers wrote: > > This is a vote to release Log4j-Audit 1.0.0, the first release of the Log4j > Audit project. > > Please download, test, and cast your votes on the log4j develo

Re: [VOTE] Migrate git repositories to gitbox

2018-06-13 Thread Ralph Goers
Whatever happened with this? Ralph > On May 7, 2018, at 8:38 AM, Matt Sicker wrote: > > And here is my +1. > > This vote passes with 5 +1s binding and 1 +1 non-binding. I'll follow up > with the migration details over the next couple days. > > On 30 April 2018 at 07:04, Apache wrote: > >> +

Re: [log4net] crafting the next release

2018-06-13 Thread Dominik Psenner
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, wrote: > Jenkins does have a way of storing

Re: [log4net] crafting the next release

2018-06-13 Thread Ralph Goers
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 wrote: > > On 2018-06-13, Dominik Psenner wrote: > >> As far as I can tell, the secrets stored in jenkins.a.

Re: [log4net] crafting the next release

2018-06-13 Thread Matt Sicker
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 wrote: > On 2018-06-13, Dominik Psenner wrote: > > > As far

Re: [GitHub] logging-log4j2 issue #176: [LOG4J2-1721] Allow composite configuration for c...

2018-06-13 Thread Phokham Nonava
Right, for the release-2.x branch I would leave the solution as it is. For the master branch I could create another pull request though. Would it be ok if we could merge this one and I'll create another one for the master branch? On 13.06.18 14:37, Matt Sicker wrote: The master branch is Java

Re: logging-log4j2 git commit: [LOG4J2-2351] Added AbstractLogEvent.getMutableInstant

2018-06-13 Thread Carter Kozak
Hi, You are correct that it is initialized lazily (or not at all if getInstant is overridden and not delegated to), However constructing a new MutableInstant instance does not initialize it from a clock, the value in both cases is {epochSecond=0, nanoOfSecond=0}, similarl to the default implementa

Re: logging-log4j2 git commit: [LOG4J2-2351] Added AbstractLogEvent.getMutableInstant

2018-06-13 Thread Gary Gregory
Hi, The semantics are quite different now, right? Before, the instant ivar was initialized on object instantiation, 'my instant is when I was created.' Now, it's value is a random amount of time after instantiation. How can that be right? Gary On Wed, Jun 13, 2018 at 6:14 AM wrote: > Repositor

Re: [log4net] crafting the next release

2018-06-13 Thread Stefan Bodewig
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

Re: [GitHub] logging-log4j2 issue #176: [LOG4J2-1721] Allow composite configuration for c...

2018-06-13 Thread Matt Sicker
The master branch is Java 8, and the release-2.x branch is Java 7. We have some functional interfaces available. On Tue, Jun 12, 2018 at 16:35, fluxroot wrote: > Github user fluxroot commented on the issue: > > https://github.com/apache/logging-log4j2/pull/176 > > That was my initial tho

Re: [log4net] crafting the next release

2018-06-13 Thread Dominik Psenner
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 m

Re: [log4net] crafting the next release

2018-06-13 Thread Matt Sicker
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

Re: [log4net] crafting the next release

2018-06-13 Thread Stefan Bodewig
[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