pacman-bintrans
gitian-builder
pacman-bintrans | gitian-builder | |
---|---|---|
8 | 7 | |
83 | 402 | |
- | - | |
5.1 | 3.1 | |
5 months ago | 5 months ago | |
Rust | Python | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
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
gitian-builder
-
Development roundup for Dogecoin Core - May 14th, 2022
A number of pull requests are still awaiting gitian checks. Unfortunately, my attempt to review and help pulling #2579 (that would make it much easier to do gitian checks) over the finish line, is not ready because the gitian-builder software that we need for this has a bug. I have opened a pull request with them to fix the issue but because Bitcoin Core is moving away from this software, it takes a little longer to get things merged there. If I see no progress on this until Friday the 20th, I will propose to temporarily fix it locally in our own scripts.
- Open Source Maintainer Sabotages Code to Wipe Russian, Belarusian Computers
-
Introduction to my PoW based Cryptocurrency
So I also faced errors even after finding these bad boys. I kept getting a system error but I solved that using help from stack overflow and some Linux forums. Bitcoin.org too was also my close friend. The error was that I haven't started apt-cacher-ng yet. so after solving that I got a new error. With this error it took about three days to find a solution because it was a problem with the code or not with the code but the Ubuntu server location. Ubuntu has moved some archive files from Archive.ubuntu to old-releases.ubuntu. But the gitian builder was still fetching from that place. So as a normal bug solver. I edited the code on GitHub and sent a pull request for DevRandom to review. Guess what MY PULL WAS CORRECT SO HE MERGED ITT!!!! I was soo excited that day that I showed it to all my friends whether they understood or not. I was happy that I had contributed to the software which is literally the backbone of all Altcoins who build through Gitian. I was also happy that I had contributed to the same repository as the names like Gavin Andresen, Luke Dashjr , Hebasto and other prominent developers in the Bitcoin Development community. The link of my two pull request can be found here
-
MWEB Update from Developer David Burkett
The release process we inherited from bitcoin can be quite painful. It uses gitian to build repeatable and deterministic binaries from the source code. This means that multiple people can all build the code on different machines (and even different operating systems) and still get the same exact release binaries. We can then all compare the results and then sign the release, certifying that we all agree that the published release is safe & accurate.
-
Thousands of Debian packages updated from their upstream Git repository
For those interested in reproducible builds, the gitian [1] project is a fairly simple VM which sets the up the necessary environment for doing this sort of thing.
The tooling and community around reproducible builds is growing all the time, and imo we should be insisting on it for things such as government apps.
[1] https://github.com/devrandom/gitian-builder
-
How to verify Dogecoin Core binary releases
git clone https://github.com/devrandom/gitian-builder git clone https://github.com/dogecoin/dogecoin git clone https://github.com/dogecoin/gitian.sigs pushd dogecoin git checkout v1.14.3 popd
What are some alternatives?
paru - Feature packed AUR helper
litecoin
arch-audit - A utility like pkg-audit for Arch Linux. Based on Arch Security Team data.
peacenotwar - Attempts to determine if the computer its running on has an IP originating from Russia or Belarus. If it is then depending on the version of the malware either attempts to delete all files on the computer, or creates a text file on the computers desktop protesting the war in ukraine.
webext-signed-pages - A browser extension to verify the authenticity (PGP signature) of web pages
antimony - Antimony is a free open source peer-to-peer electronic cash system that is completely decentralized, without the need for a central server or trusted parties. Users hold the crypto keys to their own money and transact directly with each other, with the help of a P2P network to check for double-spending. Made as a product demo of a blockchain
dysnomia - Dysnomia: A tool for deploying mutable components
gitian.sigs - Trusted Build Process signatures
rebuilderd - Independent verification of binary packages - reproducible builds
3270font - A 3270 font in a modern format
userscan - Scans files for Nix store references and registers them with the Nix garbage collector.
dogecoin - very currency