• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • None
    • 2.318

      Jenkins core uses an extension of the the stock `XStream` class from `xstream` library, that's `Xstream2`. The normal usage in plugins that need to somehow interact with XStream is to use one of the corresponding singletons (Items.XSTREAM or Run.XSTREAM mainly).

      However that's limiting more elaborated usages, because any mutation done to those objects are affecting the entire Jenkins instance, for example, registering a special `ConverterLookup` or `ConverterRegistry`. In order to do that without polluting existing singletons new instances need to be created, but a more powerful `XStream2` constructor is needed matching the superclass one:

      `public XStream(ReflectionProvider reflectionProvider, HierarchicalStreamDriver driver, ClassLoaderReference classLoaderReference, Mapper mapper, ConverterLookup converterLookup, ConverterRegistry converterRegistry)`

      Note: this was not needed before because most of the time `XStream` was just working fine, but since the last update (to `xstream:1.4.18`) the built-in `XStream` security is not suitable for usage inside Jenkins as it will reject most of the classes that are deserialized, so `XStream2` is needed.

      Note2: there is no public usage if this new constructor, for now it is only used in a non-public plugin maintained by CloudBees. The need behind the new constructor is to inject `ConverterLookup` and `ConverterRegistry` (as noted before) to be able to pre-process items and builds XML files when transferring them from one Jenkins instance to another using the Move/Copy/Promote feature.

          [JENKINS-66955] Add XStream2 constructor matching super class

          Daniel Beck added a comment -

          teilo Please see https://www.jenkins.io/download/lts/#backporting-process for backporting eligibility. Issue type was wrong.

          Daniel Beck added a comment - teilo Please see https://www.jenkins.io/download/lts/#backporting-process for backporting eligibility. Issue type was wrong.

          Antonio Muñiz added a comment - - edited

          IMO this is fixing a bug, introduced by the xstream bump (as in the bump caused client code to fail, exotic usages of XStream, yes, but allowed still).

          Before `xstream:1.4.18` client code didn't need to deal with security (as explained in the description), after the xstream version bump client code needs to be adapted, and that requires the new constructor.

          Antonio Muñiz added a comment - - edited IMO this is fixing a bug, introduced by the xstream bump (as in the bump caused client code to fail, exotic usages of XStream, yes, but allowed still). Before `xstream:1.4.18` client code didn't need to deal with security (as explained in the description), after the xstream version bump client code needs to be adapted, and that requires the new constructor.

          Daniel Beck added a comment -

          Already in 2.318, so with 2.319 being the baseline, no need to backport.

          Daniel Beck added a comment - Already in 2.318, so with 2.319 being the baseline, no need to backport.

            amuniz Antonio Muñiz
            amuniz Antonio Muñiz
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: