Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-50216] - Make RemotableGoogleCredentials compatible with JEP-200 in Jenkins 2.102+ #15

Merged
merged 10 commits into from
May 1, 2018

Conversation

oleg-nenashev
Copy link
Member

@oleg-nenashev oleg-nenashev commented Mar 20, 2018

I have just did some facelifting work during the investigation of https://issues.jenkins-ci.org/browse/JENKINS-50216 . This patch enables PCT runs for the recent versions

I have not signed the Google CLA yet though: https://cla.developers.google.com/ , but #16 states that it's not required anymore. I assume that the copyright requirement in Checkstyle is also outdated then.

  • Facelift the plugin
  • Add Jenkinsfile
  • Add custom serializer logic for JodaTime's DateTime class, which replaces the format by a JEP-200-free layout and also adds support of old object deserialization

@reviewbybees @jglick

Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No Jenkinsfile?

pom.xml Outdated
@@ -18,7 +18,7 @@
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>2.5</version>
<version>3.5</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3.6

pom.xml Outdated
@@ -112,7 +94,7 @@
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>3.0.1</version>
<version>3.0.5</version>
<configuration>
<effort>Max</effort>
<threshold>Medium</threshold>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO comment

pom.xml Outdated
@@ -200,7 +183,6 @@
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just delete

@oleg-nenashev
Copy link
Member Author

Forgot to submit Jenkinsfile. Will do it tomorrow along with the comments cleanup

@oleg-nenashev
Copy link
Member Author

Needs #16 to be merged before we can proceed

@oleg-nenashev oleg-nenashev changed the title Update Parent POM to the recent version [JENKINS-50216] - Make the plugin compatible with JEP-200 in Jenkins 2.102+ Apr 16, 2018
@oleg-nenashev oleg-nenashev changed the title [JENKINS-50216] - Make the plugin compatible with JEP-200 in Jenkins 2.102+ [JENKINS-50216] - Make RemotableGoogleCredentials compatible with JEP-200 in Jenkins 2.102+ Apr 16, 2018
Jenkinsfile Outdated
@@ -0,0 +1,2 @@
// Build the plugin using https://github.com/jenkins-infra/pipeline-library
buildPlugin(jenkinsVersions: [null, '2.107.2'], failFast: false)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -70,7 +79,7 @@ public RemotableGoogleCredentials(
throw new GeneralSecurityException(
Messages.RemotableGoogleCredentials_NoAccessToken(), e);
}
this.accessToken = checkNotNull(credential.getAccessToken());
this.accessToken = mock ? "MOCKED" : checkNotNull(credential.getAccessToken());
this.expiration = new DateTime().plusSeconds(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather just see this field converted to a simple long (msec since epoch), in which case JodaDateTimeConverter would be purely for compatibility with old settings and its marshal could throw UnsupportedOperationException.

@oleg-nenashev
Copy link
Member Author

"src/test/java/com/google/jenkins/plugins/credentials/oauth/P12ServiceAccountConfigTestUtil.java:[39,36] package org.bouncycastle.cert.jcajce does not exist" this is the biggest issue for me. Since we are not using PCT (needs jenkins-infra/pipeline-library#35), something is going on with BouncyCastle APIs. Likely I will need to add dependency on https://github.com/jenkinsci/bouncycastle-api-plugin or modify tests a bit

@@ -0,0 +1,115 @@
/*
* Copyright 2018 CloudBees, Inc.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@astroilov I would appreciate guidance regarding it. Your current checkstyle configuration requires Google to be a copyright owner. AFAICT it is no longer required after #16, right?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that to be correct, but I'll check with our opensource compliance team just in case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@astroilov 👍 Note that the current title in Google licenses may also need clarification with this team ("Copyright 2013 Google Inc. All Rights Reserved."). "All Rights Reserved" IMHO contradicts with Apache v.2 license which is used in the plugin, but IANAL

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed that this is fine.

@oleg-nenashev
Copy link
Member Author

@jglick

I would rather just see this field converted to a simple long (msec since epoch), in which case JodaDateTimeConverter would be purely for compatibility with old settings and its marshal could throw UnsupportedOperationException.

Currently it converts to a 1-liner string:

<expiration millis="1523953488567" timezone="Europe/Zurich"/>

IMHO it's good enough. Of course I could convert the field to long in readResolve() after that, but I do not see immediate need to do that as a part of the fix.

@jglick
Copy link
Member

jglick commented Apr 17, 2018

Currently it converts to a 1-liner string

Besides the timezone being irrelevant (AFAICT), this continues to persist a Joda type to XML, which is what I would like to avoid. So I am -0 on this approach. Rather, RemotableGoogleCredentials should persist a simple long, there should be no whitelist addition, and if the expiration field actually needs to be restored from old settings (since this is inherently a time-sensitive datum, it is not clear to me?), then RemotableGoogleCredentials can get a custom ConverterImpl to process the historical XML format.

GoogleRobotCredentials credentials,
GoogleOAuth2ScopeRequirement requirement,
GoogleRobotCredentialsModule module,
boolean mock) throws GeneralSecurityException {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like having explicit mock or testing options in the core code; the code should ideally be constructed in such a way as to make this unnecessary, and having mock options in security-related code in particular is concerning.

It appears that the only effect of this is to ignore the access token's expiration and the token string. It seems like that could be achieved by having test code construct its GoogleRobotCredentials object with appropriate expiration and string data. The tests are already using a FakeGoogleCredentials class, so they should be able to control that - is there a reason not to take that approach?

Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #17.

@astroilov astroilov merged commit 3267f6d into jenkinsci:master May 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants