[MIR] libopenwsman1

Tests are disabled. Can someone comment on why? The changelog just says "Testcases fail." Disabling tests seems like a suboptimal solution to that problem without more information.

I talked to the person that helped package this a few months ago.

If memory serves correctly, he believes the tests were disabled because the ones in question were being run as a part of post-compile/packaging and he thinks the way they were coded seemed to require an installation of the code itself. The packager seems to recall that at maybe one of them was trying to talk to a daemon but that daemon was not running. At the time it seemed to be too much trouble to try and 'get it all right'.

I'm going to try and enable the testcases and run an sbuild build and see for myself what happens.

Also consider that even if they need to run against an installed openwsman, you could just run the tests as a dep8 test instead of a build-time test.

The tests can not be run standalone. You need openwsmand (openwsman deamon) and a CIMOM (sblim-sfcb or tog-pegasus) with base instrumentation (sblim-cmpi-base) running.

Running an openwsman daemon together with a fully instrumented CIMOM also enables this system for remote management from a Windows box using 'winrm'.

OK, we can not worry about tests. This should have a security audit though.

I reviewed openwsman version 2.3.6-0ubuntu1 as checked into Trusty. This
should not be considered a full security audit, but rather a quick gauge
of maintainability.

The build depended upon libcimcclient0-dev from universe source package
sblim-sfcc; does this package have a MIR already underway?

- It's difficult to figure out what this package does. It bundles a
  webserver, manages plugins, generates XML, generates SWIG bindings, but
  the overall purpose is difficult to discern either from source code
  analysis or from reading documentation.
- Build-depends on cmake, libssl, libpam0g, libxml2, libcurl4-opeenssl,
  libcimcclient0-dev, swig, python-dev (ruby bindings are disabled)
- Uses OpenSSL in the embedded web server; does no certificate validation
- Uses libcurl to load remote resources; does not correctly validate
  hostnames
- Uses an embedded version of shttpd to serve HTTP and HTTPS
- Provides a pam module that can be used for authentication
- shttpd daemonizes correctly
- Simple pre/post inst/rm scripts are automatically generated content
- No initscripts
- No setuid executables
- No Dbus services
- openwsman package provides openwsmand, owsmangencert binaries
- No sudo fragments
- No udev rules
- Test suite, not enabled during build
- No cron jobs
- Build logs are clean but only by accident -- most useful compiler
  warnings are disabled, very few files are compiled with -Wall or
  -Wextra. Many oddities in the code could have been caught by asking the
  compiler for help.

- Subprocesses are spawned, looked careful
- Some memory management is overly complicated, much string manipulation
  code is awkward, some allocations are used without checking.
- Files are written to, many might be under control of remote systems via
  the web server
- Most logging functions were safe, only unsafe debug() is stubbed out
- Environment variable handling looked safe
- No privileged portions of code
- Extensive use of networking, looked safe
- No temp file handling
- No WebKit
- No PolicyKit

The code quality is highly variable. This codebase was cobbled together
out of several different projects and while some portions, particularly
the embedded webserver, look good, much of the code base is rough and
unpolished. There are many odd decisions throughout, and some of them
would have been reported by the compiler's built-in warnings, if only
they were enabled.

Many string handling functions allocate more memory than is necessary.
String duplicates are created and destroyed often. Memory management is
awkward with heap storage being used for objects with only call-chain
lifetimes. This significantly complicated looking for errors because usual
idioms are not observed.

Some memory allocations are used without checking for success. Very
rarely are structures zeroed after allocation -- and the plugin-based
architecture makes it very difficult to determine if there are information
leaks due to incomplete object initialization or structure holes.

Libcurl has a poor design -- to properly verify host names against X.509
certificates, a parameter must be set to 2. Due to this bad design,
libcurl versions greater than 7.28.0 return an error if the valu...

any update on this?

IT hasnt been updated by anyone since 2014, I'm closing it for the Dell project unless/until they ask for it again. The rest is up to you

[Expired for openwsman (Ubuntu) because there has been no activity for 60 days.]