pacman-bintrans
cargo-crev
pacman-bintrans | cargo-crev | |
---|---|---|
8 | 55 | |
83 | 2,034 | |
- | 1.7% | |
2.2 | 7.7 | |
about 2 months ago | 3 days ago | |
Rust | Rust | |
GNU General Public License v3.0 only | Apache License 2.0 |
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.
pacman-bintrans
- Pacman-bintrans – Experimental binary transparency for pacman via sigstore/rekor
-
ProtonMail Is Inherently Insecure, Your Emails Are Likely Compromised
If you trust them with your keys, why not trust them with your plaintext? At which point, why bother with E2EE at all?
The answer should be "because one day web browsers will be able to pin specific versions of specific web apps, with specific hashes, corresponding to specific releases tagged in their repo, which have been audited by a certain threshold of auditors that I trust".
What that looks like in practice is probably some mixture of the following projects:
https://github.com/kpcyrd/pacman-bintrans
https://users.rust-lang.org/t/rust-code-reviews-web-site-for...
https://paragonie.com/blog/2022/01/solving-open-source-suppl...
-
Solving Open Source Supply Chain Security for the PHP Ecosystem
Generally speaking, Transparency Logs for securing software distribution has been a research topic since around 2015, I also wrote my master thesis on the subject.
Sigstore is a Transparency Log intended for provenance and software artifacts which has support for a few different build artifacts. The container ecosystems also appears to be embracing it.
Cool practical example is pacman-bintrans from kpcyrd that throws Arch Linux packages on sigstore and (optionally) checks each package for being reproducible before installation.
https://github.com/kpcyrd/pacman-bintrans
https://www.sigstore.dev/
I think this is generally useful for a lot of ecosystems indeed, and it's cool to also see similar scoped projects pop up to address the these issues.
-
I Love Arch, but GNU Guix Is My New Distro
Reproducible builds are an important part of efforts to secure the software supply chain. Ideally you want multiple independent parties vouching that a given package (whether a compiled binary, or a source tarball) corresponds to a globally immutably published revision in a source code repository.
That gives you Binary Transparency, which is already being attempted in the Arch Linux package ecosystem[0], and it protects the user from compromised build environments and software updates that are targeted at a specific user or that occur without upstream's knowledge.
Once updates can be tied securely to version control tags, it is possible to add something like Crev[1] to allow distributed auditing of source code changes. That still leaves open the questions of who to trust for audits, and how to fund that auditing work, but it greatly mitigates other classes of attack.
[0] https://github.com/kpcyrd/pacman-bintrans
[1] https://github.com/crev-dev/cargo-crev
-
CII' FOSS best practices criteria
It's good that having a reproducible build process is a requirement for the Gold rating, as is signed releases.
Perhaps there needs to be a Platinum level which involves storing the hash of each release in a distributed append-only log, with multiple third parties vouching that they can build the binary from the published source.
Obviously I'm thinking of something like sigstore[0] which the Arch Linux package ecosystem is being experimentally integrated with.[1] Then there's Crev for distributed code review.[2]
[0] https://docs.sigstore.dev/
[1] https://github.com/kpcyrd/pacman-bintrans
[2] https://github.com/crev-dev/crev
-
Thousands of Debian packages updated from their upstream Git repository
> Of course, since these packages are built automatically without human supervision it’s likely that some of them will have bugs in them that would otherwise have been caught by the maintainer.
Human supervision isn't enough to protect the supply chain, and I can't think of a time that it's actually stopped an attack at the packaging stage, but having some extra "friction" in the process seems like it should be a benefit. Ideally an attacker would have to get past both the upstream author and the Debian maintainer, rather than these being two separate single points of failure.
Fortunately the Debian project is improving the situation with regards to supply chain attacks by continuing to work on Reproducible Builds. I think the next step from there needs to be Binary Transparency, with the adoption of the sort of approach being trialled by Arch Linux:
https://github.com/kpcyrd/pacman-bintrans
- Binary transparency logs for pacman, the Arch Linux package manager
cargo-crev
-
Hard disk LEDs and noisy machines
In other cases it may be more documented, such as Golangs baked-in telemetry.
There should be better ways to check these problems. The best I have found so far is Crev https://github.com/crev-dev/crev/. It's most used implementation is Cargo-crev https://github.com/crev-dev/cargo-crev, but hopefully it will become more required to use these types of tools. Certainty and metrics about how many eyes have been on a particular script, and what expertise they have would be a huge win for software.
-
Rust Without Crates.io
The main problem the author is talking about is actually about version updates, which in Maven as well as crates.io is up to each lib's author, and is not curated in any way.
There's no technical solution to that, really. Do you think Nexus Firewall can pick up every exploit, or even most? How confident of that are you, and what data do you have to back that up? I don't have any myself, but would not be surprised at all if "hackers" can easily work around their scanning.
However, I don't have a better approach than using scanning tools like Nexus, or as the author proposes, use a curated library repository like Debian is doing (which hopefully gets enough eyeballs to remain secure) or the https://github.com/crev-dev/cargo-crev project (manually reviewed code) also mentioned. It's interesting that they mention C/C++ just rely on distros providing dynamic libs instead which means you don't even control your dependencies versions, some distro does (how reliable is the distro?)... I wonder if that could work for other languages or if it's just as painful as it looks in the C world.
-
I don't care about cookies” extension bought by Avast, users jump ship
For instance, the worst company imaginable may be in charge of software that was once FOSS, and they may change absolutely nothing about it, so it should be fine. However, if a small update is added that does something bad, you should know about it immediately.
The solution seems to be much more clearly in the realm of things like crev: https://github.com/crev-dev/cargo-crev/
Wherein users can get a clear picture of what dependencies are used in the full chain, and how they have been independently reviewed for security and privacy. That's the real solution for the future. A quick score that is available upon display everytime you upgrade, with large warnings for anything above a certain threshold.
-
I think there should be some type of crates vertification especially the popular ones?
The metrics on crates.io are a useful sniff test, but ultimately you need to review things yourself, or trust some contributors and reviewers. Some projects, like cargo crev or cargo vet can help with the process.
-
[Discussion] What crates would you like to see?
You can use cargo-geiger or cargo-crev to check for whether people you trusted (e.g. u/jonhoo ) trust this crate.
-
Pip and cargo are not the same
There is a similar idea being explored with https://github.com/crev-dev/cargo-crev - you trust a reviewer who reviews crates for trustworthiness, as well as other reviewers.
- greater supply chain attack risk due to large dependency trees?
-
Why so many basic features are not part of the standard library?
[cargo-crev](https://github.com/crev-dev/cargo-crev) looks like a good step in the right direction but not really commonly used.
-
“You meant to install ripgrep”
'cargo crev' makes this kind of workflow possible: https://github.com/crev-dev/cargo-crev
-
Difference between cargo-vet and cargo-crev?
The crev folks themselves are no fans of PGP but need a way to security identify that you are in fact the review author, so that's where the id generation comes in. Ultimately crev is just a bunch of repos with text files you sign with IDs. The nice property is that you can chain these together into a web of trust and it's unfortunate that vet doesn't just use the same signed files on repos model as a foundation because even if they don't trust anyone else, we could turn around and trust them.
What are some alternatives?
paru - Feature packed AUR helper
crates.io - The Rust package registry
arch-audit - A utility like pkg-audit for Arch Linux. Based on Arch Security Team data.
stackage - Stable Haskell package sets: vetted consistent packages from Hackage
dysnomia - Dysnomia: A tool for deploying mutable components
crates.io-index - Registry index for crates.io
webext-signed-pages - A browser extension to verify the authenticity (PGP signature) of web pages
serde - Serialization framework for Rust
OpenCart - A free shopping cart system. OpenCart is an open source PHP-based online e-commerce solution.
cargo-msrv - 🦀 Find the minimum supported Rust version (MSRV) for your project
gitian-builder - Build packages in a secure deterministic fashion inside a VM
Rustup - The Rust toolchain installer