Comment 8 for bug 1888309

I reviewed octavia 1:10.0.0-0ubuntu1 as checked into jammy. This shouldn't
be considered a full audit but rather a quick gauge of maintainability.

octavia is a load balancer used with the OpenStack cloud infrastructure.
Therefore, it is one of the network services inside OpenStack components.

- CVE History:
 - 3 medium CVEs in the history:
  CVE-2018-16856: RedHat specific issue, fixed
  CVE-2019-17134: upstream fixed and released
  CVE-2019-3895: upstream fixed and released
 - Upstream responded to two questions from the Security team, both took
  around 1 month to be replied, the answer is satisfying.
   - https://storyboard.openstack.org/#!/story/2008697
   - https://storyboard.openstack.org/#!/story/2008715
- Build-Depends:
 - depends on some packages from universe, such as
  python-setuptools, openstack-pkg-tools, python-sphinx*
 - for encryption, at least: python-cryptography (main), pyopenssl (main)
 - network, at least: networkx (main), netifaces (main),
  python-netaddr (main)
- pre/post inst/rm scripts
 - automatically added dh_* scripts
- init scripts:
 - daemon with start/stop/reload functions, template from
  openstack-pkg-tools package
- systemd units:
 - one for each daemon and 3 templates for amphorae
- dbus services
 - None
- No setuid binaries
 - None
- binaries in PATH:
 - Total of 13 binaries in PATH under /usr/bin
  -rwxr-xr-x root/root 157 2022-03-31 09:00 ./usr/bin/amphora-agent
  -rwxr-xr-x root/root 166 2022-03-31 09:00 ./usr/bin/amphora-health-checker
  -rwxr-xr-x root/root 161 2022-03-31 09:00 ./usr/bin/amphora-interface
  -rwxr-xr-x root/root 170 2022-03-31 09:00 ./usr/bin/haproxy-vrrp-check
  -rwxr-xr-x root/root 155 2022-03-31 09:00 ./usr/bin/octavia-api
  -rwxr-xr-x root/root 164 2022-03-31 09:00 ./usr/bin/octavia-db-manage
  -rwxr-xr-x root/root 164 2022-03-31 09:00 ./usr/bin/octavia-driver-agent
  -rwxr-xr-x root/root 166 2022-03-31 09:00 ./usr/bin/octavia-health-manager
  -rwxr-xr-x root/root 165 2022-03-31 09:00 ./usr/bin/octavia-housekeeping
  -rwxr-xr-x root/root 158 2022-03-31 09:00 ./usr/bin/octavia-status
  -rwxr-xr-x root/root 166 2022-03-31 09:00 ./usr/bin/octavia-worker
  -rwxr-xr-x root/root 1788 2022-03-31 09:00 ./usr/bin/octavia-wsgi
  -rwxr-xr-x root/root 168 2022-03-31 09:00 ./usr/bin/prometheus-proxy
- sudo fragments
 - None
- polkit files
 - None
- udev rules
 - None
- unit tests / autopkgtests:
 - 1958 unit tests. A little bit noisy, could be improved for clarity, as
  already discussed in other comments. Seems to have a good interaction
  with the code, plenty of tests executed.
 - autopkgtests only seems to check if the daemons are active, it could
  be considered enough as the unit tests does the majority of testing.
  They are passing for all architetures, except i386 that can't find
  octavia for this architeture, not clear why since only one build fits
  all archs.
- cron jobs
 - None
- Build logs:
 - Build is successfull but there are so many warnings, it was already
  discussed in other comments in this same bug, mainly on unit test.
 - Lintian has 1 error and 28 warning, nothing concerning but it worth
  checking for a cleaner build.
- Processes spawned:
 - Yes. Topic of discussion in other comments here, and also discussed in
  https://storyboard.openstack.org/#!/story/2008697. Upstream claims
  that there is a extremly low risk of impact since it happens in the
  backend (and internal communitcation) protected by two-way TLS.
- Memory management: N/A
- File IO:
 - Most of the paths are configurations files, determined by openstack
  APIs using python-oslo.config package.
- Logging:
 - Logs uses python-oslo.log package (also from openstack)
- Environment variable usage:
 - None
- Use of privileged functions:
 - There is a chmod that changes the script udp_check.sh to be executable.
  It is invoked in amphorae/backends/agent, and it seems to be part of
  the tests in api_server, so it does not seem to be a problem.
- Use of cryptography / random number sources etc:
 - Seems to have a proper certificate chain validation in cert_parser.py.
- Use of temp files:
 - Yes, but only inside the tests, not a problem I think.
- Use of networking:
 - Creates networks interfaces, ports, connects and disconnect amphora to
  network, uses neutron package (main) for the virtual network service.
- Use of WebKit:
 - No
- Use of PolicyKit:
 - No

- Any significant cppcheck results:
 - NA
- Any significant Coverity results:
 - No significant reports.
- Any significant shellcheck results:
 - Some errors, many warnings and notes, not really concerning, but it
  could be improved.
- Any significant bandit results:
 - Nothing concerning.

There are stable branchs for each release in upstream repository that is
good for maintainability:
 https://github.com/openstack/octavia/branches
In the other hand, having too many releases can be tricky when we need to
backport a patch from one release to the other.
In the event of a security issue we would have to rely on upstream fixing
it in all affected releases.
It seems like it does happen, when we hit an issue we can see it being
cherrypicked to other releases, that is satysfing, example:
 https://review.opendev.org/c/openstack/octavia/+/819265

Security team ACK for promoting octavia to main. Many other OpenStack
modules are in main and it is fair to have octavia supported as well.
As upstream is very active, I'm confident that security fixes will be
promptly addressed.
A suggestion would be to encourage maintainers to make a cleaner build to
remove all the noisy warnings and maybe give some attention to Lintian and
shellcheck outputs.