-
-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
Conversation
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.
There was a problem hiding this 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.
There was a problem hiding this 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.
There was a problem hiding this 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?
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. |
Good catch, @jvz. I was able to remove one. |
Removal proposal email sent to users and dev email lists. |
* @since 1.304 | ||
* @see UDPBroadcastThread | ||
*/ | ||
public abstract class UDPBroadcastFragment implements ExtensionPoint { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still in use apparently:
If swarm
needs it, then this sounds like an argument for detaching to a plugin…or moving to the swarm
plugin.
There was a problem hiding this comment.
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?
Co-Authored-By: Jesse Glick <[email protected]>
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: small conflict after merging disabled of the test on master |
There was a problem hiding this 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.
There was a problem hiding this 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.
@jeffret-b please prepare the upgrade guidelines so that I can merge it |
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. |
Ok |
Co-Authored-By: Daniel Beck <[email protected]>
I added upgrade guidelines to the original description. |
Thanks @jeffret-b ! |
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.
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.
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 |
It was called out here @oleg-nenashev #4460 (comment) |
Yeah, and I totally missed this comment 🤦♂ |
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. |
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 |
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. |
I just released Swarm 3.18. |
Yay! I'm glad you were able to get that done. |
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'.
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
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
Proposed changelog entries
section only if there are breaking changes or other changes which may require extra steps from users during the upgradeNo tests needed for removed capability.
Maintainer checklist
Before the changes are marked as
ready-for-merge
:Proposed changelog entries
are correctupgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example)lts-candidate