Skip to content

Environment and Software

A joyful and efficient usage of ZIH systems bases on a profound understanding of the working environment, which comprises your personal user environment and the software environment.

User Environment

All ZIH systems use global home directories to provide homogeneous user environments across all systems. The default login shell is bash. Personal additions and modifications can be put into so called dotfiles in your home directory, e.g., ~/.bashrc or ~/.bash_profile.

Software Environment

There are different options to work with software on ZIH systems: modules, Jupyter Notebook and containers. Brief descriptions and related links on these options are provided below.

Modules

Usage of software on ZIH systems, e.g., frameworks, compilers, loader and libraries, is almost always managed by a modules system. Thus, it is crucial to be familiar with the modules concept and its commands. A module is a user interface that provides utilities for the dynamic modification of a user's environment without manual modifications.

Modules are used to set up the environment when working on ZIH systems via batch system (e.g.,srun or sbatch), and the JupyterHub.

Jupyter Notebook

The Jupyter Notebook is an open-source web application that allows creating documents containing live code, equations, visualizations, and narrative text. There is a JupyterHub service on ZIH systems, where you can simply run your Jupyter notebook on compute nodes using modules, preloaded or custom virtual environments. Moreover, you can run a manually created remote Jupyter server for more specific cases.

Containers

Some tasks require using containers. It can be done on ZIH Systems by Singularity.

eMudhra Certificate Security Incident

Overview

On October 18, 2026, the Certificate Authority (CA) eMudhra revoked eight intermediate certificates with compromised private keys. These keys could allow attackers to impersonate websites or software repositories in man-in-the-middle (MITM) attacks. Self-managed software environments may still trust the affected certificate chains. Users should check and update their own environments, particularly those using pip/venv, uv, or Miniforge/Conda. Software on local workstations and in containers may also be affected.

How to Check Your Software Environment

The following check_emudhra.sh script provides a quick, read-only scan for three root certificates associated with the affected certificate chains.

#!/usr/bin/env bash
# Read-only scan of listed certificate files for three relevant root certificates.

set -u

if [[ $# -ne 1 || ! -f "$1" || ! -r "$1" ]]; then
    printf 'Usage: bash %s filelist.txt\n' "${0##*/}" >&2
    exit 2
fi

filelist=$1

# Certificate patterns
patterns=(
    'MIICTjCCAdOgAwIBAgIKPPYHqWhwDt'  # emSign ECC Root CA - G3
    'MIIEMjCCAxqgAwIBAgIBATANBgkqhk'  # AAA Certificate Services
    'MIICKTCCAa+gAwIBAgIQDnYGcvFDRZ/I'  # emSign Root TLS CA - G3
)

checked=0
matches=0
errors=0

while IFS= read -r file || [[ -n "$file" ]]; do
    [[ -z "$file" ]] && continue

    if [[ ! -f "$file" || ! -r "$file" ]]; then
        printf 'WARNING: Cannot read: %s\n' "$file" >&2
        ((errors+=1))
        continue
    fi

    ((checked+=1))

    if grep -Fq \
        -e "${patterns[0]}" \
        -e "${patterns[1]}" \
        -e "${patterns[2]}" -- "$file"; then

        printf 'MATCH: %s\n' "$file"
        ((matches+=1))
    else
        status=$?
        if ((status != 1)); then
            printf 'WARNING: Could not scan: %s\n' "$file" >&2
            ((errors+=1))
        fi
    fi

done < "$filelist"

if ((checked == 0 && errors == 0)); then
    printf 'ERROR: No certificate files were scanned.\n' >&2
    exit 2
fi

printf 'Scanned %d files, %d matches, %d errors.\n' \
    "$checked" "$matches" "$errors"

if ((errors > 0)); then exit 2; fi
if ((matches > 0)); then exit 1; fi

exit 0

Step 1 - Find certificate files

Replace /path/to/software with the software directory you want to scan. Check that find finishes without errors before continuing.

marie@login$ find /path/to/software \( -type f -o -type l \) \( -name 'cacert.pem' -o -name 'cert.pem' \) > filelist.txt

Step 2 - Run the script

Create check_emudhra.sh and run:

bash check_emudhra.sh filelist.txt

The script searches for encoded patterns from these root certificates:

  • emSign ECC Root CA - G3
  • emSign Root TLS CA - G3
  • AAA Certificate Services

Step 3 - Interpret the results

A matching file is reported as:

MATCH: /path/to/software/lib/python3.12/site-packages/certifi/cacert.pem

If no patterns are found, the output looks like:

Scanned 10 files, 0 matches, 0 errors.

A match indicates the presence of a searched certificate pattern, not necessarily a vulnerable application.

A scan without matches does not prove the environment is secure. Only files named cacert.pem or cert.pem are examined and other certificate stores, encodings, or software components may be affected. The script does not modify files. If find or the script reports errors, the scan is incomplete.

Already Updated Software

The affected certificates have been already removed from centrally provided software installations available through the module system on our clusters. These changes do not cover self-managed environments in users' workspaces or home directories, or their own containers. By the way, software installations in home directories are not recommended.

Example Update Procedures

Important

You are responsible for your self-managed software.

The following commands are examples, not universal update instructions. Their applicability depends on how the software was installed, its versions, and its dependencies. Commands may fail or require additional steps. Users are responsible for maintaining and securing their self-managed software environments. HPC Support maintains the centrally provided software but cannot provide individual troubleshooting or maintenance for user-managed installations.

pip / venv

Activate the relevant virtual environment and check its pip version:

python3 -m pip --version

If pip is installed but older than 26.2.2, update it with the integrity-checked wheel below (do not use this command to replace a newer version):

python3 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7 f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f 3e973f4e4c26ffd179a204895533a7254813a70"

Update certifi in environments where it is used:

python3 -m pip install --upgrade "certifi>=2026.10.19"

Repeat for each relevant environment. pip 26.2.2 requires Python 3.10 or newer; older Python environments should be migrated to a supported version. If the environment has no pip, use its actual package manager instead.

uv

Update uv to 0.13.6 or newer using the method by which it was installed. For installations made with the official standalone installer:

uv self update

Alternatively, uv version 0.11.0 or newer can use an already updated system certificate store:

export UV_SYSTEM_CERTS=true

This setting applies to the current shell session. Updating uv does not automatically update packages in existing virtual environments.

Miniforge / Conda

Check the conda version:

conda --version

If it is older than 26.9.4, update conda in the base environment:

conda install --name base conda=26.9.4

For each relevant Miniforge/conda-forge environment, activate it and install corrected CA packages:

conda install --override-channels --channel conda-forge "certifi>=2026.10.19" "ca-certificates>= 2026.10.19"

If that environment also contains pip, ensure that it is updated to at least 26.2.2 using the package manager that installed it. Updating Conda's base environment does not update other environments. Review proposed package changes before accepting them, dependencies or an older Python version may prevent the update.

Verify the Updates

Check the installed package versions and, if useful, repeat the scan from Section 2. The scan cannot by itself confirm that all security updates are complete, and a matching root certificate is not automatically evidence of an exploitable installation.

Further Reading

The following pages link to this page: