Security update for rmt-server (important)

An update that fixes 16 vulnerabilities is now available.

Description:

This update for rmt-server fixes the following issues:

Update to version 2.6.5:

• Solved potential bug of SCC repository URLs changing over time. RMT now
  self heals by removing the previous invalid repository and creating the
  correct one.
• Add web server settings to /etc/rmt.conf: Now it’s possible to configure
  the minimum and maximum threads count as well the number of web server
  workers to be booted through /etc/rmt.conf.
• Instead of using an MD5 of URLs for custom repository friendly_ids, RMT
  now builds an ID from the name.
• Fix RMT file caching based on timestamps: Previously, RMT sent GET
  requests with the header ‘If-Modified-Since’ to a repository server and
  if the response had a 304 (Not Modified), it would copy a file from the
  local cache instead of downloading. However, if the local file timestamp
  accidentally changed to a date newer than the one on the repository
  server, RMT would have an outdated file, which caused some errors. Now,
  RMT makes HEAD requests to the repositories servers and inspect the
  ‘Last-Modified’ header to decide whether to download a file or copy it
  from cache, by comparing the equalness of timestamps.
• Fixed an issue where relative paths supplied to rmt-cli import repos
  caused the command to fail.
• Friendlier IDs for custom repositories: In an effort to simplify the
  handling of SCC and custom repositories, RMT now has friendly IDs. For
  SCC repositories, it’s the same SCC ID as before. For custom
  repositories, it can either be user provided
  or RMT generated (MD5 of the provided URL). Benefits:
  • rmt-cli mirror repositories now works for custom repositories.
  • Custom repository IDs can be the same across RMT instances.
  • No more confusing “SCC ID” vs “ID” in rmt-cli output. Deprecation
    Warnings:
  • RMT now uses a different ID for custom repositories than before. RMT
    still supports that old ID, but it’s recommended to start using the
    new ID to ensure future compatibility.
• Updated rails and puma dependencies for security fixes.

This update was imported from the SUSE:SLE-15-SP2:Update update project.

Patch Instructions:

To install this openSUSE Security Update use the SUSE recommended installation methods
like YaST online_update or “zypper patch”.

Alternatively you can run the command listed for your product:

• openSUSE Leap 15.2:

  zypper in -t patch openSUSE-2020-1993=1