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

TRUNK-6188 Upgrade xstream and migrate to whitelisting #4377

Merged
merged 1 commit into from
Aug 6, 2024

Conversation

rkorytkowski
Copy link
Member

@rkorytkowski rkorytkowski commented Sep 1, 2023

Description of what I changed

Issue I worked on

see https://issues.openmrs.org/browse/TRUNK-6188

Checklist: I completed these to help reviewers :)

  • My IDE is configured to follow the code style of this project.

    No? Unsure? -> configure your IDE, format the code and add the changes with git add . && git commit --amend

  • I have added tests to cover my changes. (If you refactored
    existing code that was well tested you do not have to add tests)

    No? -> write tests and add them to this commit git add . && git commit --amend

  • I ran mvn clean package right before creating this pull request and
    added all formatting changes to my commit.

    No? -> execute above command

  • All new and existing tests passed.

    No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.

  • My pull request is based on the latest changes of the master branch.

    No? Unsure? -> execute command git pull --rebase upstream master

@rkorytkowski
Copy link
Member Author

Please let me handle the merge and back-porting after reviews are done.

List<GlobalProperty> gpTypes = getGlobalPropertiesBySuffix(
AdministrationService.GP_SUFFIX_SERIALIZER_WHITELIST_TYPES);
List<String> whitelistTypes = new ArrayList<>();
whitelistTypes.add("org.openmrs.**");
Copy link
Member

Choose a reason for hiding this comment

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

So, one of the things we'd ideally want to prevent is serializing or deserializing org.openmrs.util.OpenmrsClassLoader.

What would you think of a rule like:

xstream.allowTypeHierachy(OpenmrsObject.class);
// may be others, but these are the common exceptions to the above:
xstream.allowTypes(LayoutTemplate.class, ComplexData.class);

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I was thinking of any classes that may be risky in org.openmrs, but I didn't come up with an obvious OpenmrsClassLoader... It seems that it may be better indeed to be less permissive and do as you suggested. I'll need to check what is needed for the Reporting module so that most obvious use cases are covered out of the box.

Copy link
Member

@mseaton mseaton left a comment

Choose a reason for hiding this comment

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

Generally looks good to me @rkorytkowski . Made a few comments.

* @param adminService
*/
public static void setupXStreamSecurity(XStream xstream, AdministrationService adminService) {
xstream.allowTypesByWildcard(new String[] {"org.openmrs.**"});
Copy link
Member

Choose a reason for hiding this comment

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

Why add this here, if we are also adding this as a hard-coded value within the getSerializerWhitelistTypes method? Can we just add the fixed, hard-coded values in one place?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's duplicated in cases when adminService is not passed so we still have some basic setup. I'll move that line to the else statement just to be explicit with the intention.


// cached xstream object
public XStream xstream = null;
private volatile XStream xstream;
Copy link
Member

Choose a reason for hiding this comment

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

Can we rename this to just clearly distinguish between this private member variable and the xstream argument passed into the static methods below?

Copy link
Member Author

Choose a reason for hiding this comment

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

Renamed arguments in methods instead.

List<Class<?>> types = Arrays.asList(OpenmrsObject.class, OpenmrsMetadata.class, OpenmrsData.class,
CustomDatatype.class, SingleCustomValue.class, CustomValueDescriptor.class, Customizable.class,
LayoutTemplate.class, LayoutSupport.class, ComplexData.class, PresentationMessage.class,
PersonMergeLogData.class);
Copy link
Member Author

Choose a reason for hiding this comment

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

@ibacher updated to use a hierarchy of common types.

Copy link

tl;dr our action detected no activity on this PR and will close it in 30 days if the stale label is not removed.

OpenMRS welcomes your contribution! It means a lot to us that you want to contribute to equity in healthcare!

This PR has not seen any activity in the last 5 months. That is why we wanted to check whether you are still working on it or need assistance from our side.
Please note that this is an automated message and we might very well be the reason why there has not been any activity lately. We certainly do not want to discourage you from contributing. We do need to be honest in that OpenMRS has limited resources for reviewing PRs.

If you do not have time to continue the work or have moved on you don’t need to do anything. We will automatically close the PR in 30 days. We hope to see you back soon :)
If you would like to continue working on it or require help from us please remove the stale label and respond by commenting on the issue.

@github-actions github-actions bot added the Stale label Feb 11, 2024
@github-actions github-actions bot removed the Stale label Mar 7, 2024
Copy link

github-actions bot commented Aug 5, 2024

tl;dr our action detected no activity on this PR and will close it in 30 days if the stale label is not removed.

OpenMRS welcomes your contribution! It means a lot to us that you want to contribute to equity in healthcare!

This PR has not seen any activity in the last 5 months. That is why we wanted to check whether you are still working on it or need assistance from our side.
Please note that this is an automated message and we might very well be the reason why there has not been any activity lately. We certainly do not want to discourage you from contributing. We do need to be honest in that OpenMRS has limited resources for reviewing PRs.

If you do not have time to continue the work or have moved on you don’t need to do anything. We will automatically close the PR in 30 days. We hope to see you back soon :)
If you would like to continue working on it or require help from us please remove the stale label and respond by commenting on the issue.

@github-actions github-actions bot added the Stale label Aug 5, 2024
@ibacher ibacher merged commit f823247 into openmrs:master Aug 6, 2024
5 checks passed
@dkayiwa
Copy link
Member

dkayiwa commented Aug 6, 2024

@ibacher do we have a strategy for this? Because after merging this, the reference application fails with errors like you can see here: qa-refapp.openmrs.org

@ibacher
Copy link
Member

ibacher commented Aug 6, 2024

@dkayiwa That was definitely a risk with this PR, but getting on XStream whitelisting seemed like a must-have. The error on the qa-refapp seems to be this:

WARN - ModuleUtil.refreshApplicationContext(901) |2024-08-06T16:21:11,228| Unable to invoke started() method on the module's activator
org.openmrs.module.ModuleException: Failed to load MDS packages
at org.openmrs.module.referencemetadata.ReferenceMetadataActivator.installMetadataPackages(ReferenceMetadataActivator.java:143) ~[referencemetadata-api-2.14.0-SNAPSHOT.jar:?]
...
Caused by: com.thoughtworks.xstream.security.ForbiddenClassException: org.openmrs.module.emrapi.metadata.MetadataPackagesConfig
...
at org.openmrs.module.emrapi.utils.MetadataUtil.getMetadataPackagesForModule(MetadataUtil.java:144) ~[emrapi.jar:?]
at org.openmrs.module.emrapi.utils.MetadataUtil.setupStandardMetadata(MetadataUtil.java:77) ~[emrapi.jar:?]

So the ReferenceMetadataActivator is failing causing the RefApp module not to start, etc.

The mechanism this PR has for modules that need to extend the supported types is to add a GP like the one in this test that ends with .serializer.whitelist.types. It seems like that needs to include the MetadataPackagesConfig type. I don't see any other places in that module that invoke the XStream deserializer.

We can, however, find other places in code we're using it via this search. It looks like the other module that will need work is openmrs-module-reportingcompatibility.

@rkorytkowski
Copy link
Member Author

We need to revert this one. I'm sorry I haven't marked it as not yet ready for merging explicitly. I didn't mean it be merged before modules are adjusted. I'll get back to this in 2 weeks and fix what's needed.

@ibacher
Copy link
Member

ibacher commented Aug 13, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants