Email or username:

Password:

Forgot your password?
rugk's posts Post Back to profile
rugk

Note on all the #xz drama, there are some technical solutions for such #supplychainattack that can make such an attack way harder, at least to hide the code in tarballs etc.

slsa.dev/ e.g. is a solution. Combined with reproducible builds, it ensures that a software artifact is built exactly from the source given in a source repository, with the possibility to prove that and no way for any maintainer to tamper with (in the highest level).

#slsa #infosec #security #linux #backdoor

30 March at 22:28 | Open on chaos.social
6 comments
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.

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.

30 March at 22:34 | Open on chaos.social
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
Martin Giger

@rugk I couldn't immediately tell, but is sigstore (sigstore.dev/) a part of that approach, or is it a different project doing something similar (but only a part of the what'd be required)?

31 March at 0:20 | Open on chaos.social
Go Up