Page MenuHomePhabricator

Xnat Plugin: How to deal with openSSL dependency
Open, NormalPublic


To support XNAT connections from MITK via https protocol, the MITK XNAT Plugin needs access to openSSL the library. How should we include openSSL dependencies into MITK.

  • Should MITK build openSSL as external project during Superbuild?
  • Should the User build openSSL manually and include the path to MITKs CMAKE Project?
  • Should pre-built DLLs/DYLIBS be provided?

Event Timeline

reicht created this task.Aug 14 2017, 6:16 PM
reicht moved this task from RM ToDo to DKFZ ToDo on the CSI-HD board.

@steint: You could use this task for further clarification / questions concerning the openSSL problem.

The currently suggested workaround seems to be still valid (see last post by @goch in T18908). However, CMake should take care of the dlls.

The default way on windows is to install openSSL and point the installer to the corresponding libraries. I do not really see it as a superbuild option, as it is a non-issue on *nix systems usually, due to omnipresent openSSL.

The reason for going with the current CMake warning instead of providing openSSL libs on windows is partly due to import/export restrictions on cryptography software. While only a problem for a handful of nations I did not see a pressing need to automatically provide the libraries, as it is pretty easy for the user to download and install them themselves.

The CMake message could be expanded to inform the user where and how to download and install the OpenSSL on their system if you think it is currently unintuitive.

After checking the mentioned CMake variables the error remains.
If you still have trouble on windows with getting a connection, the error can occur if your IP is not public. Then you need to use the proxy configuration:

see here
And maybe add some environment variables HTTP_PROXY and HTTPS_PROXY with value

A better address for the DKFZ proxy is www-int2:3128.