Adityasaky

**Name of the Vulnerable Software and Affected Versions** gitsign (affected versions not specified) **Description** The issue arises when gitsign uses Rekor's search API to fetch entries for signature verification, using parameters such as the public key and the payload. However, the search API returns entries that match either condition rather than both. This can lead to gitsign selecting the wrong Rekor entry during online verification when multiple entries are returned by the log. The impact is minimal because, although gitsign does not match the payload against the entry, it ensures that the certificate matches. Exploitation would need to occur within the certificate validity window, which is 10 minutes, and would require action by the key holder. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** gitsign versions 0.6.0 through 0.8.0 **Description** The issue concerns how Rekor public keys are fetched in gitsign. Instead of using the local TUF client, versions of gitsign starting with 0.6.0 and prior to 0.8.0 fetch these keys via the Rekor API. This could potentially allow gitsign clients to trust incorrect signatures if the upstream Rekor server is compromised. However, there is no known compromise of the default public good instance, `rekor.sigstore.dev`, which means users of this instance are unlikely to be affected. **Recommendations** For gitsign versions 0.6.0 through 0.7.x, update to version 0.8.0 to resolve the issue. For version 0.8.0 and later, no action is required as the issue is already fixed in these versions. As a temporary workaround for versions prior to 0.8.0, consider restricting the use of the Rekor API for fetching public keys until the update to version 0.8.0 can be applied.

**Name of the Vulnerable Software and Affected Versions** in-toto versions 1.4.0 and prior **Description** The in-toto configuration is read from various directories, allowing users to configure the framework's behavior. Among the files read is `.in totorc`, a hidden file in the directory where in-toto is run. If an attacker controls the inputs to a supply chain step, they can mask their activities by passing in an `.in totorc` file with necessary exclude patterns and settings. RC files are widely used in other systems, and security issues have been discovered in their implementations. Maintainers found that `in totorc` is not the preferred way to configure in-toto, and as the options supported in `in totorc` can be set elsewhere using API parameters or CLI arguments, they decided to drop support for `in totorc`. **Recommendations** For versions 1.4.0 and prior, consider updating to a version where support for `in totorc` has been dropped, as the maintainers have removed the `user settings` module altogether. As a temporary workaround, consider disabling the use of `.in totorc` files until a patch is available. Sandbox functionary code as a security measure to minimize the risk of exploitation.