PROPOSAL: Remove network discovery services

[Jeff Thompson]

Hi,

Dating back many years, Jenkins has supported two network discovery services (UDP multicast/broadcast and DNS multicast). When this was first implemented this may have been a reasonable way to provide useful lookup services. With modern Jenkins capabilities, networks, and security considerations, this is no longer a good mechanism. There are now other ways to better accomplish pretty much everything this does.

With Jenkins Security Advisory 2020-01-29 ( https://jenkins.io/security/advisory/2020-01-29/ ) these services were disabled by default because of SECURITY-1641 / CVE-2020-2100.

The tests for these services have long been problematic because of various system issues. They have never passed for me on my development machine and others have reported the same. The issues are exacerbated with Java 11.

We propose to remove these network discovery services. See https://issues.jenkins-ci.org/browse/JENKINS-60913 and https://github.com/jenkinsci/jenkins/pull/4460 .

Please respond with any agreement or if you have any important implementations that require these capabilities. Perhaps if this is still needed, the capabilities could be pulled out of core into a plugin, maintained by someone that uses it.

Jeff Thompson

[Jesse Glick]

On Thu, Jan 30, 2020 at 11:47 AM Jeff Thompson <jtho...@cloudbees.com> wrote:
> the capabilities could be pulled out of core into a plugin

That was the longstanding proposal in JENKINS-33596.

[Jeff Thompson]

I think it's time to act on it.

The key to implementing it in a plugin is to have someone who relies on it maintain it. If swarm uses it maybe someone involved with that could take it on. I'd be willing to help get things going with that, but not to maintain it. If nobody is interested enough for that, we should kill it off.

Jeff

[Slide]

I'm +1 on this, reducing the attack footprint for core is a good idea.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e8f4603d-a953-10f8-0eb0-8cada6eaae36%40cloudbees.com.

--

Website: http://earl-of-code.com

[Gavin Mogan]

I'm also very much a +1 to this

It doesn't work inside of docker anyways, and yea less attack footprint the better.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVc5Rijvp9OnktyfAsG8M2SrrMO0UwUR%2BTHwBm97pYCBaA%40mail.gmail.com.

[Tim Jacomb]

+1 on removing it, is there actually going to be anyone using it who is updating their Jenkins version? I.e is a plugin needed?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVc5Rijvp9OnktyfAsG8M2SrrMO0UwUR%2BTHwBm97pYCBaA%40mail.gmail.com.

[Baptiste Mathus]

Le jeu. 30 janv. 2020 à 20:10, Tim Jacomb <timja...@gmail.com> a écrit :

+1 on removing it, is there actually going to be anyone using it who is updating their Jenkins version? I.e is a plugin needed?

Would it be worth and possible writing a jep-214 Telemetry impl to catch stats about this use? (Though it'd take a big time to be used, once people upgrade to it, but at least we'd have some trend).

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifRQoyW2ECh1b4dV4axLtW6PzoK2WAJGOWJ%2BLE-3VcmVA%40mail.gmail.com.

[Jesse Glick]

On Thu, Jan 30, 2020 at 1:41 PM Jeff Thompson <jtho...@cloudbees.com> wrote:
> I'd be willing to help get things going with that, but not to maintain it. If nobody is interested enough for that, we should kill it off.

Fine with me. My perspective was that it sounded like little
additional effort to dump the extracted code into a plugin repository,
publish a 1.0 release, and then forget about it—immediately mark as up
for adoption. (And do not list in the split plugin metadata for core,
so it has to be opted into.) Of course simply deleting it without
replacement does not prevent someone in the future from looking up the
code deleted in that commit and creating a plugin out of it.

[Jeff Thompson]

On 1/30/20 1:33 PM, Baptiste Mathus wrote:

Le jeu. 30 janv. 2020 à 20:10, Tim Jacomb <timja...@gmail.com> a écrit :

+1 on removing it, is there actually going to be anyone using it who is updating their Jenkins version? I.e is a plugin needed?

Would it be worth and possible writing a jep-214 Telemetry impl to catch stats about this use? (Though it'd take a big time to be used, once people upgrade to it, but at least we'd have some trend).

It's probably possible to write some Telemetry code to catch usage stats. I'm not sure how useful the data would be. It could tell us who has enabled the features. And probably servers where the service is probed. It would be harder to tell if they're providing useful value.

I question whether it's worthwhile. If we get some positive response for the capability that would better support a need for the Telemetry. Maybe.

Jeff

[Jeff Thompson]

Yeah, if there's some interest I'm willing to help with that. Otherwise, I figure it's in the git history and can always be resurrected when there's someone motivated enough to keep it going.

Jeff

[Jesse Glick]

Update: at least the UDP part seems to be in use for authentication by
the Swarm plugin. Needs to be checked.

[Ivan Fernandez Calvo]

Swarm plugin has about 7000 installations, this is the potential Jenkins instances affected, I am agree to remove it from the core but I think that should be provided as a plugin, maybe the needed staff can be moved to the swarm plugin.

[Amit Dar]

Hi,

As a heavy Swarm Plugin user, I can say we don't use the discovery feature of the plugin, but rather direct the client to a specific master. This is due the fact we have several Jenkins masters in the same network (for testing purposes, mainly). I think the usage of the auto discovery feature is something people use only if they have a single instance of the master in their network, and this might be true only when using jenkins in a "dockerized" network.

If you have the capability to understand the usage of the plugin (with or without the discovery feature) I suggest you use it to make a better decision.

[Daniel Beck]

We propose to remove these network discovery services. See https://issues.jenkins-ci.org/browse/JENKINS-60913 and https://github.com/jenkinsci/jenkins/pull/4460 .

Please respond with any agreement or if you have any important implementations that require these capabilities. Perhaps if this is still needed, the capabilities could be pulled out of core into a plugin, maintained by someone that uses it.

Clear +1

Since there's no associated data, deleting (perhaps with a warning logged when the then obsolete system props are set to an "enable" value just to make sure admins can notice before users) from core seems fine even without a plugin initially, and certainly no detachment dance.

 

[Matt Sicker]

On Fri, Jan 31, 2020 at 3:35 AM Amit Dar <dar....@gmail.com> wrote:
> As a heavy Swarm Plugin user, I can say we don't use the discovery feature of the plugin, but rather direct the client to a specific master. This is due the fact we have several Jenkins masters in the same network (for testing purposes, mainly). I think the usage of the auto discovery feature is something people use only if they have a single instance of the master in their network, and this might be true only when using jenkins in a "dockerized" network.

Agreed on this regard. I used to use the multicast discovery feature
of Hazelcast long ago when we had only one cluster, but once we added
another cluster that was logically a different environment but still
accessible within the same network, this caused numerous configuration
issues and mixing of caches and other nonsense. I highly suggest
leaving UDP multicast to be used only for video streaming or the other
goals it was originally designed for.

--
Matt Sicker
Senior Software Engineer, CloudBees