Email or username:

Password:

Forgot your password?
All posts rugk's posts Post Back to profile
Top-level
rugk

Furthermore produced software artifacts proofs are written into a database similar to #certificateTransparency.

We have recently implemented this in #PrivateBin and it works great: github.com/PrivateBin/PrivateB

Of course practically, people (especially software consumers) needed to verify it, to be worth the work.

Obviously, it's no magic bullet. It just raises the burden for an attacker. Obviously, the source code repo could be made to contain bad code, but you cannot anymore tamper at built-time.

30 March at 22:34 | Open on chaos.social
4 comments
rugk

The way this works, is, essentially, quite easy: the whole build process is documented in the same repository, builds are automated via CI/CD and all that is, to reach best support, done in an environment that prevents tampering and (crucially) is *out of your control*.

Then you get #SLSA v3: slsa.dev/get-started#slsa-3 (quite easy with GitHub Actions)

30 March at 22:37 | Open on chaos.social
rugk

Now, you say, you have to trust GitHub? Sure, you do, to achieve this. But threat models: What is more likely compromised: a maintainer/account in your project, or the whole GitHub build infra?

Personally, I was also not quite convinced, given you loose "control" over your build and GitHub could theoretically now inject #malware.

However, as the project itself states, this is not a big deal, if you combine it with the older security feature aka #reproduciblebuilds.

slsa.dev/spec/v1.0/faq#q-what-

Now, you say, you have to trust GitHub? Sure, you do, to achieve this. But threat models: What is more likely compromised: a maintainer/account in your project, or the whole GitHub build infra?

Personally, I was also not quite convinced, given you loose "control" over your build and GitHub could theoretically now inject #malware.

30 March at 22:40 | Open on chaos.social
rugk

To explain, we have #SLSA signatures that verify the build was done automatically by #GitHub as instructed, *and* we have traditional #gpg signatures with private keys only known to maintainer(s) that verify a maintainer actually triggered the built and locally reproduced it…
Given they both validate, you automatically achieve reproducible builds _and_ #SLSA validity.

One caveat: This was only easy, because our build process is essentially one command (git archive).

github.com/PrivateBin/PrivateB

To explain, we have #SLSA signatures that verify the build was done automatically by #GitHub as instructed, *and* we have traditional #gpg signatures with private keys only known to maintainer(s) that verify a maintainer actually triggered the built and locally reproduced it…
Given they both validate, you automatically achieve reproducible builds _and_ #SLSA validity.

30 March at 22:51 | Open on chaos.social
⛈️ rain

Wow, je mehr ich über die ganze #xz Saga lese, desto beeindruckter bin ich, was für ein unglaublicher Zufall es war, dass das so schnell gefunden wurde 😳

boehs.org/node/everything-i-kn ist ein lesenswerter Überblick.

bugs.debian.org/cgi-bin/bugrep gibt einen guten Eindruck, wie vor 5-6 Tagen angefangen wurde, Druck aufzubauen, die kompromittierte Version in Debian hochzuladen. Und wie viel Energie da rein gesteckt wurde.

#infosec #security

Wow, je mehr ich über die ganze #xz Saga lese, desto beeindruckter bin ich, was für ein unglaublicher Zufall es war, dass das so schnell gefunden wurde 😳

boehs.org/node/everything-i-kn ist ein lesenswerter Überblick.

bugs.debian.org/cgi-bin/bugrep gibt einen guten Eindruck, wie vor 5-6 Tagen angefangen wurde, Druck aufzubauen, die kompromittierte Version in Debian hochzuladen. Und wie viel Energie da rein gesteckt wurde.

31 March at 13:09 | Open on systemli.social
Go Up