Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-70301

Resolve implied dependencies on WMI Windows Agent plugin

    • Icon: Epic Epic
    • Resolution: Fixed
    • Icon: Minor Minor
    • windows-slaves-plugin
    • Jenkins core after 1.547
      Jenkins plugins that require a Jenkins core version less than 1.547
    • WMI Windows Agent deprecation: long tail
    • 2.386

      The WMI Windows Agents plugin is installed on many Jenkins controllers. It has been deprecated. Hardly any users use the functionality of the WMI Windows Agents plugin because Microsoft has changed the security settings of Microsoft Windows DCOM so that the plugin can no longer use Microsoft Windows DCOM to connect agents. Windows users connect their outbound Windows agents with OpenSSH and they connect their inbound Windows agents with agent.jar or with swarm.jar.

      Why is WMI Windows Agents plugin deprecated?

      The reason for the deprecation of the WMI Windows Agents plugin is included on the plugin page where it says:

      This plugin is deprecated. SSH is now a very viable, secure and robust solution for connecting to Windows based agents using native Windows binaries for OpenSSH Server or another method such as cygwin. There is also the Windows Cloud plugin for Jenkins which uses WinRM, a more modern remote management solution.

      The method for connecting agents to the controller in this plugin, which is based on DCOM, has several pitfalls and issues and can be brittle. The SSH and other solutions can unify the method for connecting to all agents (Windows, Linux, macOS, etc.) in your infrastructure. It is highly recommended that you migrate to one of these other methods sooner rather than later.

      Microsoft is tightening security on DCOM based on a CVE. Initial OS updates will require a registry change to enable the current security level, then in May of 2023 they will not have a way to override the secure behavior. The library used in this plugin was last released in ~2010 and does not have an active development team. Jenkins developers have decided to deprecate this plugin rather than try and maintain the library on our own.

      The WMI Windows Agents plugin is no longer needed, yet remains in those Jenkins controllers because it an implied dependency of plugins that require a minimum Jenkins controller version prior 1.547.

      What is an implied dependency?

      Implied dependencies are described on the plugins.jenkins.io site in the "What's this?" text as:

      Features are sometimes detached (or split off) from Jenkins core and moved into a plugin. Many plugins, like Subversion or JUnit, started as features of Jenkins core.

      Plugins that depend on a Jenkins core version before such a plugin was detached from core may or may not actually use any of its features. To ensure that plugins don't break whenever functionality they depend on is detached from Jenkins core, it is considered to have a dependency on the detached plugin if it declares a dependency on a version of Jenkins core before the split. Since that dependency to the detached plugin is not explicitly specified, it is implied.

      Plugins that don't regularly update which Jenkins core version they depend on will accumulate implied dependencies over time.

      In most cases, the plugin that has the implied dependency will not stop working when the WMI Windows Agent plugin is removed. However, the user cannot be confident of that until they've removed the WMI Windows Agent plugin and confirmed that their system is still operating as expected.

      Why does the implied dependency exist?

      An implied dependency exists because Jenkins core does not know if the dependent plugin requires functionality that was moved from Jenkins core to the WMI Windows Agent plugin when the WMI Windows Agent plugin was split from core. The WMI Windows Agent plugin was split from Jenkins core in release 1.547. Plugins that declare a dependency on a version of Jenkins core before the split are given the implied dependency by Jenkins core. It is "implied" because it is not directly declared in the plugin and it is a dependency because Jenkins core does not know if the API's that were in Jenkins core before the split of the plugin are required or not.

      The Jenkins administrator can see the plugins that have an implied dependency from the plugin manager page. They hover over the "uninstall" button and a list of plugins with an implied dependency is displayed.

      How can the implied dependency be removed?

      The implied dependency can be removed by releasing a new version of the plugin that depends on a newer minimum Jenkins core than Jenkins 1.547. The "Improve a plugin" tutorial provides steps that can assist plugin developers as they configure the plugin to depend on a newer minimum Jenkins core.

      Which plugins have an implied dependency on WMI Windows Agents plugin?

      As of 16 Dec 2022, there were over 300 Jenkins plugins that declare a minimum Jenkins version before 1.547. Those plugins are listed in the "Plugins with implied dependency on WMI Windows Agents" worksheet

      Jira issues for those plugins to upgrade their minimum Jenkins version can be linked in this epic as a convenient way of seeing the related issues. A Jira issue is not required in order to release a new version of an affected plugin. The Jira issue is just a convenience in case it helps someone justify that new release or explain why it is not being released.

          [JENKINS-70301] Resolve implied dependencies on WMI Windows Agent plugin

          Jesse Glick added a comment -

          I do not understand why this issue is being prioritized or addressed as it is.

          First of all, implied dependencies are expected to rarely be real. There are a few detached plugins which actually defined APIs that lots of other plugins legitimately used, like hudson.tasks.junit or hudson.matrix or even hudson.tasks.Mailer.UserProperty, so split-plugins.txt ensures compatibility for those “long-tail” plugins with old core deps that did refer to those API types. In most cases where we detached a plugin, we added an entry to this file just to be on the safe side but in fact the dependency was rarely if ever used. So 99+% of the time it is perfectly fine to disable / uninstall the implied dep. Maybe the wording in the popup should reflect this better.

          windows-slaves does little harm if installed and unused—adds a tiny bit to startup time, and adds a useless dropdown entry for the launchers of a static agent. Of course we would like to clean up junk when we can.

          When you actually look at usages https://github.com/search?q=org%3Ajenkinsci%20hudson.os.windows&type=code you can see that types from this plugin are only used in two other plugins (both of which I presume have low installation counts): multi-slave-config and cli-extras (as well as a test in jenkinslint, no effect on users). So if we just delete the usages from those two plugins, which should be a few minutes’ work, and get those released, then there is no further need for the plugin to be listed as detached—we can simply delete the entry from split-plugins.txt and it will no longer trouble people with newer core versions.

          Updating random plugins to require a newer core baseline is fine so far as it goes, and we would expect to do this regularly for widely-used plugins anyway, but it should never be the way to fix a non-issue with implied dependencies.

          Jesse Glick added a comment - I do not understand why this issue is being prioritized or addressed as it is. First of all, implied dependencies are expected to rarely be real. There are a few detached plugins which actually defined APIs that lots of other plugins legitimately used, like hudson.tasks.junit or hudson.matrix or even hudson.tasks.Mailer.UserProperty , so split-plugins.txt ensures compatibility for those “long-tail” plugins with old core deps that did refer to those API types. In most cases where we detached a plugin, we added an entry to this file just to be on the safe side but in fact the dependency was rarely if ever used. So 99+% of the time it is perfectly fine to disable / uninstall the implied dep. Maybe the wording in the popup should reflect this better. windows-slaves does little harm if installed and unused—adds a tiny bit to startup time, and adds a useless dropdown entry for the launchers of a static agent. Of course we would like to clean up junk when we can. When you actually look at usages https://github.com/search?q=org%3Ajenkinsci%20hudson.os.windows&type=code you can see that types from this plugin are only used in two other plugins (both of which I presume have low installation counts): multi-slave-config and cli-extras (as well as a test in jenkinslint , no effect on users). So if we just delete the usages from those two plugins, which should be a few minutes’ work, and get those released, then there is no further need for the plugin to be listed as detached—we can simply delete the entry from split-plugins.txt and it will no longer trouble people with newer core versions. Updating random plugins to require a newer core baseline is fine so far as it goes, and we would expect to do this regularly for widely-used plugins anyway, but it should never be the way to fix a non-issue with implied dependencies.

          Mark Waite added a comment -

          I do not understand why this issue is being prioritized or addressed as it is.

          The harm (for me) from windows-slaves remaining on my controller is that if I can't remove the plugin if I have other plugins that I must have and that have an implied dependency on it. When I ignore the warning from the plugin manager, uninstall it, and restart, then Jenkins shows it in the plugin manager anyway. The warning message for the deprecation of the plugin can't be cleared, so it remains clickable for all users of the Jenkins controller. It leaves me unsettled that I'm running a plugin that is deprecated.

          I'm certainly open to other approaches, especially if the other approaches don't involve upgrades to plugins that are rarely installed. I'll see if we can either remove the references from multi-slave-config and cli-extras or suspend their distribution so that the windows-slaves entry could be removed from split-plugins.txt.

          Mark Waite added a comment - I do not understand why this issue is being prioritized or addressed as it is. The harm (for me) from windows-slaves remaining on my controller is that if I can't remove the plugin if I have other plugins that I must have and that have an implied dependency on it. When I ignore the warning from the plugin manager, uninstall it, and restart, then Jenkins shows it in the plugin manager anyway. The warning message for the deprecation of the plugin can't be cleared, so it remains clickable for all users of the Jenkins controller. It leaves me unsettled that I'm running a plugin that is deprecated. I'm certainly open to other approaches, especially if the other approaches don't involve upgrades to plugins that are rarely installed. I'll see if we can either remove the references from multi-slave-config and cli-extras or suspend their distribution so that the windows-slaves entry could be removed from split-plugins.txt .

          Jesse Glick added a comment - - edited

          When I […] uninstall it, and restart, then Jenkins shows it in the plugin manager anyway.

          Presumably because it gets reinstalled from the bundled (detached) plugin after restart. I suppose disabling (but not uninstalling) the plugin should suppress this message.

          Anyway, as above, I think it is quite practical to remove this entry from split-plugins.txt.

          Jesse Glick added a comment - - edited When I […] uninstall it, and restart, then Jenkins shows it in the plugin manager anyway. Presumably because it gets reinstalled from the bundled (detached) plugin after restart. I suppose disabling (but not uninstalling) the plugin should suppress this message. Anyway, as above, I think it is quite practical to remove this entry from split-plugins.txt .

          Mark Waite added a comment -

          Proposed https://github.com/jenkinsci/jenkins/pull/7568 to remove windows-slaves from the split plugins list after a series of interactive tests that confirm it is well behaved.

          Mark Waite added a comment - Proposed https://github.com/jenkinsci/jenkins/pull/7568 to remove windows-slaves from the split plugins list after a series of interactive tests that confirm it is well behaved.

          Mark Waite added a comment -

          Merged in preparation for release in Jenkins 2.386

          Mark Waite added a comment - Merged in preparation for release in Jenkins 2.386

            markewaite Mark Waite
            markewaite Mark Waite
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: