Adityasaky

**Nome do software vulnerável e versões afetadas** gitsign (versões afetadas não especificadas) **Descrição** O problema ocorre quando o gitsign utiliza a API de pesquisa do Rekor para buscar entradas para verificação de assinatura, utilizando parâmetros como a chave pública e a carga útil. No entanto, a API de pesquisa retorna entradas que correspondem a qualquer uma das condições, em vez de ambas. Isso pode levar o gitsign a selecionar a entrada Rekor errada durante a verificação online quando várias entradas são retornadas pelo log. O impacto é mínimo porque, embora o gitsign não compare a carga útil com a entrada, ele garante que o certificado seja válido. A exploração precisaria ocorrer dentro do período de validade do certificado, que é de 10 minutos, e exigiria uma ação por parte do detentor da chave. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.

**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.