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-33596, JENKINS-60913] Remove network discovery services #4460

Merged
merged 14 commits into from
Feb 7, 2020

Conversation

jeffret-b
Copy link
Contributor

@jeffret-b jeffret-b commented Jan 29, 2020

See JENKINS-60913 for an explanation of the motivation. As discussed in Jenkins Security Advisory 2020-01-29 these services are vulnerable to SECURITY-1641 / CVE-2020-2100. The security release disables these protocols but they should be completely removed to finish the clean up.

I can post in the User and Dev lists to see if anyone objects to this removal.

Proposed changelog entries

  • Remove network discovery services (UDP and DNS).

Proposed upgrade guidelines

Network discovery features, DNS multicast and UDP broadcast, were previously disabled and discouraged because of various problems including Jenkins Security Advisory 2020-01-29. They have now been removed. There is no replacement.

Swarm Plugin needs to be updated to version 3.18 or above, otherwise the error described in JENKINS-61029 occurs. This also removes the network discovery capability of the plugin.

Submitter checklist

  • JIRA issue is well described
  • Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
    • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
  • Appropriate autotests or explanation to why this change has no tests
    No tests needed for removed capability.
  • [n/a] For dependency updates: links to external changelogs and, if possible, full diffs

Maintainer checklist

Before the changes are marked as ready-for-merge:

  • There are at least 2 approvals for the pull request and no outstanding requests for change
  • Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
  • Changelog entries in the PR title and/or Proposed changelog entries are correct
  • Proper changelog labels are set so that the changelog can be generated automatically
  • If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
  • If it would make sense to backport the change to LTS, a JIRA issue should exist and be labeled as lts-candidate

Doesn't need to be referenced in the other pom any more.
We need to keep the class and the property around for a while.
Jenkins Test Harness sets the property. Until we can get all
versions aligned so it isn't needed, it's best to keep the property
doing nothing.
Copy link
Contributor

@res0nance res0nance left a comment

Choose a reason for hiding this comment

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

If no one uses it that's fine, I think maybe a post in both lists will help in case there is some other usage of it that we are not aware of (Ideally not).

Perhaps an upgrade guide would be needed so users were aware.

Copy link
Member

@alecharp alecharp left a comment

Choose a reason for hiding this comment

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

I'm totally for removing something we shouldn't be using. As we already have a release out there with this deactivated, removing it is fine.

For sure, we will need a message on both mailing and maybe a blog post.

Copy link
Member

@jvz jvz left a comment

Choose a reason for hiding this comment

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

LGTM. Are you able to remove any dependencies, too?

core/src/main/java/hudson/DNSMultiCast.java Show resolved Hide resolved
@jeffret-b
Copy link
Contributor Author

For sure, we will need a message on both mailing and maybe a blog post.

I'm preparing a message to the email lists. I'm not so sure about a blog post, though. It doesn't make much sense to blog about a proposal. I'm not sure there's enough here for an announcement post. Not sure we have a really good place for announcing things like this other than the changelog and email lists.

@jeffret-b
Copy link
Contributor Author

Are you able to remove any dependencies, too?

Good catch, @jvz. I was able to remove one.

@jeffret-b
Copy link
Contributor Author

Removal proposal email sent to users and dev email lists.

core/src/main/java/hudson/DNSMultiCast.java Show resolved Hide resolved
* @since 1.304
* @see UDPBroadcastThread
*/
public abstract class UDPBroadcastFragment implements ExtensionPoint {
Copy link
Member

Choose a reason for hiding this comment

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

Still in use apparently:

https://github.com/jenkinsci/swarm-plugin/blob/fbf7b55a665a1439f8bb9471336300381c097948/plugin/src/main/java/hudson/plugins/swarm/UDPFragmentImpl.java#L14

If swarm needs it, then this sounds like an argument for detaching to a plugin…or moving to the swarm plugin.

@basil?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had forgotten that I had seen a usage in the swarm plugin ages ago. That's one area that makes some sense. On the other hand, keep in mind that we announced a security vulnerability in these services yesterday. See SECURITY-1641 / CVE-2020-2100.

If swarm needs this service then it inherently provides this vulnerability. With the proper configuration and environment this may not be an issue, but this would need to be well documented.

I'm open to helping transfer it to swarm or to a plugin but not to maintaining that. Anywhere it ends up needs to take responsibility for the security concern.

So, yes, @basil, what do you think? Or anyone else who has a need for this?

@res0nance res0nance added the upgrade-guide-needed This changes might be breaking in rare circumstances, an entry in the LTS upgrade guide is needed label Feb 1, 2020
@oleg-nenashev oleg-nenashev added the major-rfe For changelog: Major enhancement. Will be highlighted on the top label Feb 1, 2020
Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

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

+1 for moving it out of the core. There is an older ticket for it IIRC, will find it

*/
@Deprecated
Copy link
Member

Choose a reason for hiding this comment

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

Add Restricted(DoNotUse) to fail builds?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I couldn't get it to work without failing the Jenkins build. We could use NoExternalUse, though.

Copy link
Member

Choose a reason for hiding this comment

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

@timja
Copy link
Member

timja commented Feb 4, 2020

FYI: small conflict after merging disabled of the test on master

Copy link
Member

@daniel-beck daniel-beck left a comment

Choose a reason for hiding this comment

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

I think it would make sense, and be straightforward enough to do, to add an @Initializer that checks the value of the deprecated fields or system properties, and if they indicate an explicitly "enabled" kind of value (true, or any actual port number, respectively), to print a warning.

(Explicitly disabled is fine, there's no difference in expected and actual behavior, and no urgency to remove the option.)

Doesn't need to be referenced in the other pom any more.
We need to keep the class and the property around for a while.
Jenkins Test Harness sets the property. Until we can get all
versions aligned so it isn't needed, it's best to keep the property
doing nothing.
@timja timja requested a review from daniel-beck February 6, 2020 10:11
Copy link
Member

@daniel-beck daniel-beck left a comment

Choose a reason for hiding this comment

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

LGTM 👍

🚢🇮🇹

Added suggestions for links but I'm not insisting they need to be added. Just not seeing a downside, even if the linked docs isn't super relevant (at first). I'd be happy to provide the corresponding jenkins.io change to ensure they're not a dead end if the changes are accepted.

core/src/main/java/hudson/DNSMultiCast.java Outdated Show resolved Hide resolved
core/src/main/java/hudson/UDPBroadcastThread.java Outdated Show resolved Hide resolved
@oleg-nenashev
Copy link
Member

@jeffret-b please prepare the upgrade guidelines so that I can merge it

@daniel-beck
Copy link
Member

It's a straightforward "These features, which have been disabled before, are now removed, and there is no replacement". Would not let that block merging IMO.

@oleg-nenashev
Copy link
Member

Ok
I plan to merge it tomorrow if no negative feedback

@oleg-nenashev oleg-nenashev added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Feb 6, 2020
Co-Authored-By: Daniel Beck <[email protected]>
@jeffret-b
Copy link
Contributor Author

I added upgrade guidelines to the original description.

@oleg-nenashev
Copy link
Member

Thanks @jeffret-b !

@oleg-nenashev oleg-nenashev merged commit f10d9f9 into jenkinsci:master Feb 7, 2020
@oleg-nenashev oleg-nenashev changed the title [JENKINS-60913] Remove network discovery services [JENKINS-33596, JENKINS-60913] Remove network discovery services Feb 10, 2020
Flowdalic added a commit to Flowdalic/jenkins that referenced this pull request Feb 10, 2020
The class was removed with f10d9f9 ("[JENKINS-60913] Remove network
discovery services (jenkinsci#4460)") but is required by the swarm client. As
result, swarm clients are unable use Jenkins:

java.lang.NoClassDefFoundError: hudson/UDPBroadcastFragment
        at hudson.plugins.swarm.PluginImpl.getSwarmSecret(PluginImpl.java:262)

This commit re-adds hudson.UDPBroadcastFragment to allow swarm client
to the use the master again and hence fixes JENKINS-61029.
Flowdalic added a commit to Flowdalic/jenkins that referenced this pull request Feb 10, 2020
The class was removed with f10d9f9 ("[JENKINS-60913] Remove network
discovery services (jenkinsci#4460)") but is required by the swarm client. As
result, swarm clients are unable use Jenkins:

java.lang.NoClassDefFoundError: hudson/UDPBroadcastFragment
        at hudson.plugins.swarm.PluginImpl.getSwarmSecret(PluginImpl.java:262)

This commit re-adds hudson.UDPBroadcastFragment to jenkin's core, to
allow swarm client to the use the master again and hence fixes
JENKINS-61029.
@oleg-nenashev
Copy link
Member

The change caused a regression in Swarm Plugin clients: https://issues.jenkins-ci.org/browse/JENKINS-61029 . We should ensure that somebody does a binary compatibility double-check when reviewing such pull requests. I will try to add it to the maintainer guide

@timja
Copy link
Member

timja commented Feb 10, 2020

It was called out here @oleg-nenashev #4460 (comment)

@oleg-nenashev
Copy link
Member

Yeah, and I totally missed this comment 🤦‍♂

@jeffret-b
Copy link
Contributor Author

Yeah, there was a discussion about it here and on one of the email lists. The discussion here wasn't marked as resolved so it is still readily visible.

This PR is interesting, because it had a lot of approvals and no disapprovals. We had some discussion about people who might want to be concerned about it, but didn't get any response from anyone who actually was.

Perhaps we should have placed this on-hold for a time-limited duration to give people more opportunity to express concerns or prepare, but I really don't see that additional time would have likely yielded different responses. We don't want to leave things open forever, delaying something that so many support hoping that someone will eventually respond. Maybe we need to improve that process but we want to make sure not to make it too difficult to move Jenkins forward.

@oleg-nenashev
Copy link
Member

I added Swarm Plugin reference to the upgrade guide draft. We still need a release of jenkinsci/swarm-plugin#179 to know the exact required version

@basil
Copy link
Member

basil commented Feb 13, 2020

We still need a release of jenkinsci/swarm-plugin#179 to know the exact required version

I am currently working on a release. As I explained in jenkinsci/swarm-plugin#179 (comment), I still need to finish jenkinsci/swarm-plugin#182 and do some additional testing to understand (and document!) the impact for users with regard to backwards compatibility. As I am a bit short on time these days, any help would be appreciated, but otherwise I should be able to get to this by the end of the week.

@basil
Copy link
Member

basil commented Feb 13, 2020

I am currently working on a release.

I just released Swarm 3.18.

@jeffret-b
Copy link
Contributor Author

Yay! I'm glad you were able to get that done.

MarkEWaite added a commit to MarkEWaite/jenkins.io that referenced this pull request Mar 25, 2020
I reviewed jenkinsci/jenkins#4460 and found no
links that were not already included in the network discovery text.

I thought a link to the 2.204.2 upgrade guide might be helpful to some
readers, but it is misleading because it indicates that there is an
'escape hatch', while this change intentionally removes the 'escape
hatch'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major-rfe For changelog: Major enhancement. Will be highlighted on the top ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback upgrade-guide-needed This changes might be breaking in rare circumstances, an entry in the LTS upgrade guide is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.