kas is a setup tool for bitbake based projects. Prior to 5.4, internal SSH key setup triggered by SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE creates ~/.ssh/config when no user-specific SSH configuration exists and adds a global Host * rule containing StrictHostKeyChecking no. In kas/libcmds.py, ssh_no_host_key_check() runs without checking ctx.managed_env, so the setting persists after kas exits and affects future SSH sessions by the same local user, extending beyond the intended short-lived continuous integration environment. A later SSH connection can therefore accept an attacker-controlled host key without verification, increasing the risk of
kas checks out SHA-like git branches as valid commits
kas is a setup tool for bitbake based projects. Prior to version 5.3, when relying solely on a git commit ID (SHA-1 or SHA-256) to qualify if a checkout of a repository is equivalent to the state validated while adding its commit ID to a kas configuration, users may be tricked to check out a branch of the same name from this repository. This implies that the referenced repository has been taken over by an attacker and modified to carry such a branch. SHA-1 commits may also be replaced by creating hash collisions, so the primary impact of this issue is on SHA-256 commit IDs. Version 5.3 fixes the issue. As a workaround, avoid relying solely on