attestation
git-secret
attestation | git-secret | |
---|---|---|
3 | 22 | |
202 | 3,657 | |
7.4% | - | |
8.6 | 5.8 | |
4 days ago | 19 days ago | |
Go | Shell | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
attestation
-
Gittuf – a security layer for Git using some concepts introduced by TUF
It's multi-pronged and I imagine adopters may use a subset of features. Broadly, I think folks are going to be interested in a) branch/tag/reference protection rules, b) file protection rules (monorepo or otherwise, though monorepos do pose a very apt usecase for gittuf), and c) general key management for those who primarily care about Git signing.
For those who care about a and b, I think the work we want to do to support [in-toto attestations](https://github.com/in-toto/attestation) for [SLSA's upcoming source track](https://github.com/slsa-framework/slsa/issues/956) could be very interesting as well.
- NPM Provenance Public Beta
-
There is no “software supply chain”
I have. I actually worked a few desks down from dpc when he was creating it and we talked about it at length. I felt then and now that it has good goals but a very limiting implementation in that it does not pursue a portable spec and instead anchors a very opinionated format to git, and github, instead of cryptographic keys held in hardware owned controlled by reviewers. I want to see the same keys that sign git commits also sign reviews, for instance.
I think for broad adoption a review system should ask essentially the same questions as crev, but store them in a format like in-toto including signatures by the reviewers created with a user choice of pgp smartcards, ssh keys, or webauthn devices. These reviews would be anchored to hashes of a particular state of a particular tree of code and not to any type of VCS or distribution system. Important code is distributed via Perforce, mercurial subversion, and tar files depending if we are talking about big corps, or linux distro building blocks. A good OSS review system should be also be usable by teams in their internal proprietary codebases too if we wish to see wide adoption. Even for OSS we may wish to share some reviews as standalone objects privately while security embargos are in place, etc. Proofs should also be verified standalone easily from local cache, when github is down, when original repos vanish, etc.
Something that meets these broader needs will make it easy for large orgs with very different internal setups to participate and play nice with other supply chain efforts by the OpenSSF using in-toto for reproducible builds, etc.
My experience tells me we need something much more ambitious than crev, but crev proved to me many people have real interest in this problem which I really thank dpc for.
The biggest blocker for starting this project is the human review spec settling in in-toto https://github.com/in-toto/attestation/issues/77
git-secret
-
Gittuf – a security layer for Git using some concepts introduced by TUF
I've happily been using git-secret (https://sobolevn.me/git-secret/) for encrypting non-critical (i.e. non-production) secrets for a while now. It sounds like Gittuf will do a lot more than git-secret, but for the use case of encrypted files specifically, is there a significant different about with the approach that Gittuf has taken?
-
Ansible-based dotfiles with fancy nvchad-based neovim + tmux setup
Secrets inside the repo. All the credentials, ssh keys, VPN configs can be stored directly in the repo with support of the git secret. gpg key is optional: config works fine if it is not provided and secrets are not decrypted.
-
Modern Perl Catalyst: Docker Setup
You might notice that some of the environmental variables have funky values that look more like template placeholders. For example "SESSION_STORAGE_SECRET=${SESSION_STORAGE_SECRET}". That's because there's a .env file that contains those (you can see it in the root of the GitHub repository page. As a good practice I try to isolate anything that needs to be secret right off the top. So even though this is a development setup and would need work to turn it into a something suitable for production let's try to start off right not doing the wrong thing by hardcoding all our secrets into various files. At least now there's just one file to secure. And later on if you move to something really secure like Hashicorp's Vault product, or even something open source like git secret you won't have to hunt all over the place for the secrets to keep. Lets now look at the rest of the Catalyst application setup:
-
Terraform - How do you handle secrets?
Checkout git-secret. https://git-secret.io/
-
[2022][Friendly Reminder] Don't commit your input files to Git
There‘s plugins like https://github.com/AGWA/git-crypt or https://git-secret.io that you can use to encrypt the files for yourself, so that they are available on multiple machines to you
- how to automate the sharing .env file with the team?
-
How to hide changes in GitHub repository from the public?
If you really want to have private repositories in GitHub, you will need to set up something like https://git-secret.io on top of git.
- Using GNU Stow to manage your dotfiles (2012)
-
Would it be worth using a secrets management system?
If you want a low config solution and not scared of gpg, https://git-secret.io/
-
git-secret vs Mozilla SOPS?
Hey guys, so I'm using git-secret as of now. Just stumbled across Mozilla SOPS today and finding it interesting. Which one you guys recommend and why? Advantages and disadvantages of each? I think SOPS is more robust and stable since it is being maintained by a large organization? Please correct me if I'm wrong. Help is appreciated.
What are some alternatives?
malicious-software-packages-dataset - An open-source dataset of malicious software packages found in the wild, 100% vetted by humans.
sops - Simple and flexible tool for managing secrets
root-signing
vaultwarden - Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs
dsse - A specification for signing methods and formats used by Secure Systems Lab projects.
secret - Share Secrets securily
gittuf - A security layer for Git repositories
git-crypt - Transparent file encryption in git
packj - Packj stops :zap: Solarwinds-, ESLint-, and PyTorch-like attacks by flagging malicious/vulnerable open-source dependencies ("weak links") in your software supply-chain
Blackbox - Safely store secrets in Git/Mercurial/Subversion
fulcio - Sigstore OIDC PKI
passff - Read-only mirror of https://codeberg.org/PassFF/passff Pull requests and issues on GitHub cannot be accepted and will be automatically closed.