Merge branch 'master' into tbt-376-New_TravisCI_Logo

Author: nikolaTrichkovski

user/securely-signing-software.md

@@ -85,21 +85,32 @@ script:
 
 Whenever in doubt, please consult the [Cosign KMS Support documentation page](https://docs.sigstore.dev/cosign/kms_support)
 
+### Add SSH Key
+
+Add a new SSH key, a private key in PEM format only.
+
+Complete the following fields to add a new SSH key:
+- **Identifier**: field to add an identifier name.
+- **Description**: field to add a short description.
+- **SSH Key**: field to add your SSH key code. 
+
 ## Security considerations
 
 As much as the feature is meant to help you prove the source of the file or image via signature, please at all times consider following aspects of ensuring security of the key used for signing the files or images during the CI/CD process.
 
 The key used for signing uploaded to Travis CI under a personal account or organization account can be used under every repository owned by this entity (assuming proper tag and key identifier are present in the respective repository `.travis.yml`). The key downloaded from Hashicorp Vault to a specific build job or build can be used, respectively, within a specific build job or every build job of a build.
 
+
 Therefore, please carefully review repository settings in Travis CI for repositories belonging to the account and assess the risk of the key used for signing being exposed, e.g., via malicious pull request from a fork or accidental debug message. We’d recommend paying attention whether the repository is public (which makes the job logs public by default), if the pull requests from forks are allowed, are the repository SSH keys shared and who may access the job logs. Please mind that job logs, especially public, can be used to expose the secret via a malicious or accidental debug message in the pull request or commit that triggers a build in Travis CI.
 
 We recommend considering the following security measures:
  * using separate key just for the purpose of file/image signing.
- * using private repository to trigger builds, during which the files are signed, if possible.
+ * using a private repository to trigger builds, during which the files are signed, if possible.
  * reviewing who has push/write access to such repository.
  * reviewing Repository Settings, particularly the [Security Settings -> Share SSH key with forks](/user/web-ui#share-ssh-keys-with-forks) setting.
  * excluding a build, which signs the release to a separate account/organization (if possible and viable) with a limited list of collaborators.
  * [limiting access to repository job logs](/user/disable-job-logs/) in individual repository settings.
  * if using Hashicorp Vault KMS as a source of the key used for signing: always encrypt secrets needed to connect to Vault in the respective Repository Settings or the .travis.yml file.
 
+
 Travis CI will attempt to obfuscate secrets in the job logs, yet since there are many ways to print them in the output there’s no guarantee all vulnerable data will be spotted and masked. Since Travis is a cloud CI/CD system, please be wary of associated risks and ways to minimize these. Please read also [Best Practices in Securing Your Data](/user/best-practices-security/).