Signing releases

[siliconwaffle]

Would it be feasible for you to begin signing new release tarballs? Like for every .tar.gz if we could get a .tar.gz.asc? It makes verification significantly easier and it is the "proper" way to verify packages for rpms at least. I think it would be worth the extra effort since this is such a security sensitive application, given the fact that it's entire purpose is to act a middleman for keystrokes.

[adrelanos]

• All Git commits are already signed.
• All Git tags are already signed.

I don't understand the necessity for tarballs, which are disconnected from Git. This disconnection has led to issues, such as the case with the xz backdoor. In that instance, the Git source code was clean, but the tarball was compromised. There was no mechanism enforcing that the tarball matched the version control system, effectively undermining many advantages of being Open Source.

If source code is managed within a version control system, as it should be, the use of tarballs becomes unnecessary.

[siliconwaffle]

• All Git commits are already signed.

• All Git tags are already signed.

I'm aware. Signing tarballs is just a suggestion to make end user verification a little less convoluted.

I don't understand the necessity for tarballs, which are disconnected from Git.

You already distribute compressed tarballs. Right here: https://github.com/Whonix/kloak/archive/refs/tags/0.3.7-1.tar.gz. My suggestion is to sign them and distribute the asc file so that people who use the tarballs can verify them relatively easily.

This disconnection has led to issues, such as the case with the xz backdoor. In that instance, the Git source code was clean, but the tarball was compromised.

The xz incident is completely unrelated, the target was always ssh keys not compressed tarball archives. Nonetheless, there are mechanisms in place that prevented compromised versions from making their way into stable distributions such as Bookworm and Fedora stable. If it had made its way into bookworm(or trixie once it becomes stable), then Whonix and Kicksecure would have been compromised and people who store their ssh keys in a Kicksecure/Whonix vm would've been screwed, compressed tarballs would still be clean though.

There was no mechanism enforcing that the tarball matched the version control system, effectively undermining many advantages of being Open Source.

Just about every oss project on earth distributes via compressed tarball and git. I can't name a single project that doesn't at least distribute via tarball, can you? Even your projects get tarballs every time you tag a release. And once uncompressed you can still verify hashes and src code. With that in mind, can you really say that compression undermines open source?

If source code is managed within a version control system, as it should be, the use of tarballs becomes unnecessary.

Even when I use VCS I still end up just compressing the folder into a tarball using bzip2, I think most people do(with various different algorithms).

If you can't or won't sign tarball releases then fine, I understand you don't have to do this and you must already have a lot on your plate, but your reasoning here doesn't make much sense to me.

[adrelanos]

You already distribute compressed tarballs. Right here: https://github.com/Whonix/kloak/archive/refs/tags/0.3.7-1.tar.gz.

Even your projects get tarballs every time you tag a release.

That's not by choice. That's an automatic feature by GitHub.

• https://github.com/orgs/community/discussions/6003

This disconnection has led to issues, such as the case with the xz backdoor. In that instance, the Git source code was clean, but the tarball was compromised.

The xz incident is completely unrelated, the target was always ssh keys not compressed tarball archives.

The delivery method for the xz backdoored was in the tarballs only. You can read about that here: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5010095

Quote https://snyk.io/blog/the-xz-backdoor-cve-2024-3094/

A particularly insidious aspect of this attack was the introduction of a modified build-to-host.m4 file in the GitHub-hosted tar release, which was absent in the Git repository and thus couldn’t be tracked back to its origin in source control.

That resulted in discussions on "tarball transparency". https://lists.debian.org/debian-devel/2024/04/msg00103.html

There was no mechanism enforcing that the tarball matched the version control system, effectively undermining many advantages of being Open Source.

Just about every oss project on earth distributes via compressed tarball and git. I can't name a single project that doesn't at least distribute via tarball, can you?

Maybe because github enables creation of tarballs by default without being requested to do so... I personally ignore tarballs as much as possible and use VCS instead.

And once uncompressed you can still verify hashes and src code.

After uncompromising a tarballs, the only way verify against the source code would be to download the source code, which makes the tarball a pointless exercise except it's part of auditing / rebuilding / backdoor hunting.

With that in mind, can you really say that compression undermines open source?

I am not anti-compression.

Even when I use VCS I still end up just compressing the folder into a tarball using bzip2,

But hopefully only after git tag / commit signature verification.