1.4.2. Migration to 7.12.0

Caution

The minimum required system GLIBC version on GNU/Linux is now 2.28.

The minimum required Windows version is now Windows 10, version 1809 or Windows Server 2019.

1.4.2.1. Installer

Caution

Please make sure to manually uninstall any old version of the Axivion Suite before installing 7.12. Do not attempt to install a 7.12 Axivion Suite over an older version (e.g., 7.11).

In previous versions, a guided installer for Windows was supplied as an alternative to directly extracting the .zip/.tar.gz archive. Starting from 7.12.0, this installer has been replaced with a new, cross-platform installer, meaning that a guided installer is now available for all three supported platforms (as an .exe on Windows, .run on GNU/Linux, and .dmg on macOS).

If you are on macOS or GNU/Linux and have previously been extracting the Axivion Suite manually, you can now use the guided installer as a potentially easier alternative that includes conveniences like application shortcuts. If you do this, you also no longer need to run setup.sh, as the new installer handles those steps automatically.

For a full overview of the new installer (including its usage for unattended/headless workflows) please refer to Basic Installation. The below only documents concrete migration steps to avoid breaking existing setups.

Installer files

Distribution files for the Axivion Suite have been subjected to the following renames:

	Name in 7.11	Name in 7.12
Windows Installer	bauhaus-suite-<ver>-x86_64-windows.exe	Axivion-<ver>-x86_64-windows.exe
macOS Installer	—	Axivion-<ver>-<arch>-macos.dmg
GNU/Linux Installer	—	Axivion-<ver>-<arch>-gnu_linux.run
Windows Archive	bauhaus-suite-<ver>-x86_64-windows.zip	Axivion-<ver>-x86_64-windows.zip
macOS Archive	bauhaus-suite-<ver>-<arch>-macos.tar.gz	Axivion-<ver>-<arch>-macos.tar.gz
GNU/Linux Archive	bauhaus-suite-<ver>-<arch>-gnu_linux.tar.gz	Axivion-<ver>-<arch>-gnu_linux.tar.gz

In addition, note that the <ver> part has been changed to use dots instead of underscores (e.g., 7.12.0 instead of 7_12_0).

Linux Dependencies

The installer has the following new dependencies on Linux:

• GLIBC 2.28+

• GLIBCXX 3.4.28+

• The installer is built with the Qt Installer Framework on Qt 6.8. This adds the following requirements:

  • X11 (or XWayland on Wayland systems)

  • GL libraries: libEGL.so.1, libGLX.so.0, libOpenGL.so.0

  • XCB libraries: libxcb-cursor.so.0, libxcb-icccm.so.4, libxcb-image.so.0, libxcb-keysyms.so.1, libxcb-randr.so.0, libxcb-render-util.so.0, libxcb-shape.so.0, libxcb-sync.so.1, libxcb-xfixes.so.0, libxcb-xkb.so.1, libxkbcommon-x11.so.0

  • The Qt for X11 Requirements page (specifically “Platform Plugin Dependencies”) provides additional details.

Run ldd ./Axivion-*-gnu_linux.run | grep "not found" to see if you are missing any of these.

Please note that these dependencies refer only to the installer, not the installed Axivion Suite itself.

Default install locations

The default install locations for the Axivion Suite are still the same as they were before on Windows and are only listed here for completeness. Both macOS and GNU/Linux previously had no default location and now use the locations shown below.

• Install for current user:

  • Windows: %LOCALAPPDATA%\Bauhaus

  • macOS: ~/Applications/bauhaus-suite.

  • Linux: ~/.local/bauhaus-suite.

• Install for all users:

  • Windows: C:\Program Files (x86)\Bauhaus

  • macOS: /Applications/bauhaus-suite.

  • Linux: /opt/bauhaus-suite.

License handling

The previous installer allowed you to install a license file (.key) after the installation. This option still exists in the new installer, along with the added alternative to license your installation via your Qt Account instead.

Uninstalling

While the old Windows installer offered a bauhaus-uninstaller.exe, the new installer provides a maintenancetool.exe in the installation folder that allows you to fully uninstall the Axivion Suite. This maintenance tool is also available on macOS and GNU/Linux, provided that you used the guided installer instead of directly extracting the .tar.gz archive.

Please note that uninstalling the Axivion Suite via the “Installed Apps” page in the Settings may not work correctly on Windows 11. Instead, you must either uninstall via the “Programs and Features” page in the Control Panel, or directly run the maintenancetool.exe in the installation folder.

1.4.2.2. Project Configuration

The default behavior regarding missing configuration files has been changed: By default, it is now an error if a configuration file referenced in the BAUHAUS_CONFIG variable or in an interface layer cannot be found. This change helps finding problems early when configuration files are renamed or when filenames are mistyped.

This change may cause errors with configurations that worked in previous versions.

To fix such errors, please correct or remove any incorrect file references indicated by the error messages. In case a file reference is as intended, but the file is not always there (e.g., because it is generated), the reference can be made optional (see Optional layers).

As a last resort, the previous behavior of tolerating missing configuration files can be restored by passing the parameter --continue_on_missing_config to axivion_ci and axivion_analysis. Doing so is not recommended because it disables the improved error checking of the new approach.

1.4.2.3. Continuous Integration

Local Build

The configuration option /Project/local_mode.reference_version.continue_with_old_reference_data has been removed in favor of a proper Offline Local Build mode which can now be used to do a Local Build without a running dashboard and without a reference version to compare against. Currently, only the Visual Studio Code Plugin and the Local Build without Plugins support this feature, other plugins will follow in future releases.

1.4.2.4. Entry point configuration

The configuration of additional entry points via EntryPoints-EntriesByAttribute is now enabled by default. With the default configuration, routines with interrupt set as an attribute will be considered entry points. This applies to both C++ attributes as well as GCC-style attributes.

1.4.2.5. IR

In class Composite_Type, the members Friend_Routines and Friend_Classes have been merged into a single member Friends. This member now holds all friend declarations, including templates that previously didn’t appear in either member.

1.4.2.6. Dashboard

LDAP/ActiveDirectory

The following security relevant hint was added to our documentation:

Caution

LDAP/ActiveDirectory users are not automatically deleted from the internal user database when they are deleted from the LDAP/ActiveDirectory server. To prevent these users from being usable in the Dashboard (via internal password or Dashboard provided Application Tokens) after deletion from your LDAP/ActiveDirectory server you have to make sure that the Login permission is only granted to these users via an LDAP group membership.

Dashboard Windows Service

If the dashboard is running as Windows service, the service registration needs to be updated, due to an update of the Windows Service Wrapper used by the Axivion Dashboard.

First remove the service registration by executing sc stop <service_name> and sc delete <service_name> from an Administrator command prompt. Then reinstall the service by invoking dashserver install.

Note, that the service wrapper now requires .NET Framework 4.6.1 or higher.

Internal Passwords for LDAP users

Previously, users could use their LDAP password to change and/or set a new internal password. Internal passwords can now only be changed by confirming the previous internal password. Most importantly, this now prevents users authenticated via LDAP/Active Directory from setting an internal password for themselves unless an Administrator has explicitly set one for them. This makes it entirely Administrator controllable whether users can authenticate via an internal password or not.

1.4.2.7. Stylechecks

Renamed rule group

The rule group Generic has been renamed to Miscellaneous in order to avoid potential confusion with the new rule group GeneralPurpose that is now supposed to supply the best practice checks.

Rules that have been part of Generic are moved into either Miscellaneous or the new rule group GeneralPurpose where appropriate.

The migration from Generic to Miscellaneous happens automatically for json configuration files, but other occurrences may need to be replaced manually, i.e. in python config files.

Note that control comments inside the source code will continue to work with the old rule names.

Structured links instead of secondary positions

References to other source locations have been moved to dedicated rows in the issue details sidebar for several rules. E.g., findings attached to a function call may now have a “Callee” row that includes a link to the corresponding function. Before, these were reported as “secondary positions” in an “Additional SLocs” row.

This might require changes to post-processing code that makes use of the secondary_sloc repeated field of bauhaus.analysis_results.Style_Violation. The secondary locations are now available via entries in the extra_info field, e.g., as follows:

# before:

for sloc in sv.secondary_sloc:
    ...

# now:

from bauhaus.analysis.post_processing import find_slocs_in_extra_info_entry

for entry in sv.extra_info:
    if entry.key != "Callee":
        continue

    for sloc in find_slocs_in_extra_info_entry(entry.value_xml):
        ...

Default behavior of rules utilizing taint analysis

Taint analysis identifies flows of data originating from particular code locations of interest, called sources, that reach particular (other) code locations, called sinks, that should not be reached from these sources without being sanitized, that is, checked for validity or modified such that the flow is no longer sensitive. As an example, a routine that returns the password a user typed in at a password prompt may be considered a source, writing to a database may be considered a sink and proper password hashing may be considered as sanitizer.

Prior to this release, the logic for deciding which locations are to be considered sources and sinks was defective such that way too many locations could be considered sources or sinks. The following rules were affected:

• FaultDetection-TaintAnalysis

• CWE-20

• CWE-22

• CWE-23

• CWE-78

• CWE-79

• CWE-89

• CWE-134

• CWE-200

• CWE-400

• CWE-464

• CWE-502

• CWE-606

• CWE-789

• MisraC2012Directive-4.14

To address this issue, we introduced new options all_external_functions_as_sources and all_external_functions_as_sources to all of these rules and provided sensible defaults to them. In case they are enabled, non-excluded external functions are considered as sources (sinks), where “external” means “declaration-only within the IR or declared in a system header”. We have implemented reasonable default exclusions, but further exclusions may be configured in the external_source and sinks options of these rules.

Due to these changes, with this release you may initially get substantially more false-positive findings with the aforementioned rules when more locations are spuriously considered as default sources/sinks. In that case, you should add these locations/routines as exclusions. In case you feel that an exclusion is universal (such as a library function that may never produce tainted data) please contact our support so that we can assess your exclusion proposal and implement it internally.

1.4.2.8. CloneDetection rules adjustments

The clone detection rules have been grouped into a new group called “CloneDetections” and the rule CloneDetection has been renamed to C++CloneDetection to make it more consistent with the other language-specific clone detection rules.

The migration from CloneDetection to C++CloneDetection happens automatically for JSON configuration files, but other occurrences may need to be replaced manually, i.e. in Python configuration files.

1.4.2.9. Axivion Suite Plugin for Visual Studio Code

When omitting the username in the dashboard configuration, the plugin will now fallback to “anon_auth” to support anonymous authentication. Previously, the system username was used. If the old behavior is needed, one can use the new environment variable syntax:

{
  "id": "...",
  "url": "...",
  "username": "${env:USER}"
}

1.4.2.10. Metrics

Renamed Metric-LOC to Metric-Lines.Routine.Body.LOC

The metric rule Metric-LOC was renamed to Metric-Lines.Routine.Body.LOC, to better reflect in the name what is measured by the rule and the default value of rfg_metric_name option was changed in similar fashion from Metric.LOC to Metric.Lines.Routine.Body.LOC.

The rule name will automatically be migrated for JSON configuration files, but other occurrences may need to be replaced manually, i.e. in Python configuration files. The same goes for any uses of old rfg attribute name Metic.LOC, they also need manually changed to Metric.Lines.Routine.Body.LOC.

Caution

This change will cause all existing violations of the Metric-LOC rule to be removed and re-added for Metric-Lines.Routine.Body.LOC instead.

1.4.2.11. UI Tools

Wayland support for UI Tools

Gravis, axivion_config and irviewer now run in native Wayland mode on Linux Wayland sessions. Before version 7.12.0, they used the XWayland compatibility layer.

In case of compatibility problems with the Wayland compositor these programs might fail to show their main window and appear to hang. In that case, they can be switched back to the previous behavior of running in XWayland compatibility mode by setting the environment variable QT_QPA_PLATFORM=xcb.

Gravis configuration

Changed interpretation of graph style configuration (High-DPI support)

Starting from version 7.12.0, Gravis offers improved support for high-DPI screens. More aspects of the user interface will now have the same appearance on high-DPI screens as on standard resolution displays. All stored measurements are now in device-independent pixels, which requires changes to custom graph style configurations.

Before version 7.12.0, all pixel measurements in the Gravis configuration (edge widths, node symbol border widths and arrow sizes) were interpreted as device-dependent screen pixels, so they had to be configured to match the pixel density of the current display. On a system with a high-DPI display it was recommended to use a custom configuration file that doubled the default edge width and the default border widths of nodes. A custom configuration was provided that could be installed to $(HOME)/.bauhaus/gravis.json (Linux/macOS) or %USERHOME%\.bauhaus\gravis.json (Windows).

Starting from version 7.12, the measurements are interpreted as device-independent pixels, so they are scaled up by the system DPI scale factor. That means that the default configuration is perfectly suitable for both standard-resolution and high-DPI displays. It also means that Gravis configuration files can be shared between systems with different displays.

The use of a custom configuration for high-DPI devices is no longer necessary and having such a file still in place now doubles the widths of edges and node symbol borders, so it is recommended to remove these changes.

If the provided configuration file was used as-is and no other changes were made to it, then it is enough to remove the file from the location mentioned above, but if the file also contains other configuration changes, then the width fields in the /Tools/Gravis/graph_style/edge_types setting and the pen-width and expanded-pen-width fields in the /Tools/Gravis/graph_style/node_types setting should be adapted. This can be done in the graphical user interface.

Note

Stored layouts have been device-independent since version 7.6.8, so these could already be used on standard resolution displays and high-DPI displays without any change and hence need not be adapted.