Improve Release Provenance

[lishaduck]

Hey Cosmo! I installed Sine in Windows yesterday 🥳, hit the Trojan warning (but ignored it), and then I finally joined the Discord and immediately was hit with the "Sine is a virus" garbage.

I thought it might be helpful to you if I provided some resources to help out here:

• Create releases in CI
• Pin GitHub actions to full-length SHAs (or set up the lockfile once that's GA)
• Use lockfiles for the project dependencies
• Build binaries in CI
  • CosmoCreeper/Sine
  • sineorg/bootloader
  • Sineorg/installer
• Set up immutable releases to ensure releases aren't tampered with (possible with current configuration?)
• Set up actions/attest to ensure that the binaries are the same as the ones built by CI
• Get a free signing certificate from SignPath

Obviously, only the last one will help with actually preventing the Trojan warnings, but given how much of a pain it is, that'll be a bit and we really should be doing the rest if we want to actually claim it's secure.

[CosmoCreeper]

Hold up bro. Free signing certificate? That's what I've been complaining about this whole time.

But actually, thanks for making this issue. I dont know much in the signing field really so I'll go down this list and let you know what I'm working on.

EDIT: Actually the binaries for sineorg/installer aren't built at all by themselves, they are built by Sine's release CI because of the custom variables needed to build so I dont think that todo should be there right?

[lishaduck]

Actually the binaries for sineorg/installer aren't built at all by themselves, they are built by Sine's release CI because of the custom variables needed to build so I dont think that todo should be there right?

Ah. Yeah I wasn't sure how the installer was getting built. Does it make sense to build the installer in its own repo with the releases?

[CosmoCreeper]

Not really. The problem is that every time we build the installer we must pass a variable for which Sine version and bootloader version we're building it for, like this:

Start building installer...
  What Sine version are you building for? v2.3.0
  What bootloader version are you building for? v0.1.4

Of course the command that does this looks nothing like this, but we don't ship out "versions" of the installer, we ship out catered installers separate for each version, which, at least to me, seems like it should be done with the rest of the CI in Sine's repository when releasing new versions.

I do have some questions about the other to-dos though, like immutable releases. We could configure immutable releases, but we do currently have this concept of patches for versions, where if needed, we can update the release assets to fix something detrimental that would break Sine.

Also, when you're talking about adding lockfiles for project dependencies, you're strictly referring to the python scripts right? We already have bun.lock for the bun-based dependencies.

[CosmoCreeper]

#476 will make the lockfiles for python dependencies useless, as no more remote dependencies will be required.
I've also enforced the full-length SHAs on GitHub Actions now.

[lishaduck]

Of course the command that does this looks nothing like this, but we don't ship out "versions" of the installer, we ship out catered installers separate for each version, which, at least to me, seems like it should be done with the rest of the CI in Sine's repository when releasing new versions.

Ah, that makes more sense. I'd generally be inclined to ship it as a monorepo then, to keep the release tags in lockstep, but that's a pretty big change so I don't think it's necessary.

We could configure immutable releases, but we do currently have this concept of patches for versions, where if needed, we can update the release assets to fix something detrimental that would break Sine.

Ooof. Security-wise, that's a major red flag; that's exactly the behavior actual malware uses to infect it (e.g. the recent attack on Trivy). Is there a reason why you can't just release a new build (SemVer spec), e.g. 2.3.1+1? (To be clear, I'm not accusing you, I trust you, but I'm just saying that we should improve our posture here because it looks bad)

Also, when you're talking about adding lockfiles for project dependencies, you're strictly referring to the python scripts right? We already have bun.lock for the bun-based dependencies.

Yup, just Python.

#476 will make the lockfiles for python dependencies useless, as no more remote dependencies will be required.

Great! I've got some comments on that front, I'll leave them on #477.

I've also enforced the full-length SHAs on GitHub Actions now.

🥳

I highly recommend running Zizmor over your CI (it's a linter for GHA security, it's great).
I'd also encourage setting up Renovate (it's free, the GH install says it's not but it is) to update the hashes to new versions instead of doing it manually (barring that, there's also actions-up if you prefer a CLI option).

[CosmoCreeper]

I'm curious to see Dependabot is capable of some of the SHA updating.
Zizmor looks cool though, I'll check it out.

Ooof. Security-wise, that's a major red flag; that's exactly the behavior actual malware uses to infect it (e.g. the recent attack on Trivy). Is there a reason why you can't just release a new build (SemVer spec), e.g. 2.3.1+1? (To be clear, I'm not accusing you, I trust you, but I'm just saying that we should improve our posture here because it looks bad)

Saying this is a major red flag is like saying every project that doesn't have immutable releases is a major red flag, that is, we don't explicitly add support for editing releases, but it is something that is naturally there. I'll allow a fourth number as a patch number and use it in release tags, which should have the same possibilities as allowing the editing of the pre-existing release, and let you know when I finish it.

[lishaduck]

Saying this is a major red flag is like saying every project that doesn't have immutable releases is a major red flag,

Oh, I didn't mean using non-immutable releases in general, but rather actually updating the release assets. Apologies if that wasn't clear. Obviously I use open-source software and most projects don't use immutable releases :)

that is, we don't explicitly add support for editing releases, but it is something that is naturally there.

Ah, I thought you meant that you had been using it to edit releases in general. That makes more sense 👍🏻

[CosmoCreeper]

https://github.com/CosmoCreeper/Sine/attestations/27312434
Does this look good for a proper attestation? If so, I'll update the to-do for it.

I noticed one more issue with switching to immutable releases that I have to resolve before we can switch.

[lishaduck]

That looks good to me! 👍🏻

[lishaduck]

Actually took a little bit closer of a look at it, it probably makes sense to create the attestation from the build workflow, and then run gh attestation verify on the resulting files to ensure that it's created?

---

Also, I was looking at the building workflow and it's pretty complicated. Did I hear you're rewriting the installer anyway soon? If so, may I interest you in Zig? (not the language itself, but the build tool + package manager). That's completely unrelated to security, I just have fun playing with it and thought you might like it as well. It's way simpler IMO (and supports cross-compilation!).

[CosmoCreeper]

Immutable releases are now set up. I'll take a look at the attestation stuff.
I might not be able to do a whole lot more on this until the weekend though.

Did I hear you're rewriting the installer anyway soon?

I've considered a Rust rewrite, but nothing's official. The installer has already been through several languages now.

If so, may I interest you in Zig?

Not entirely sure how using Zig for a build system but not for the code itself would work. Do you have any examples?

[lishaduck]

I've considered a Rust rewrite, but nothing's official. The installer has already been through several languages now.

Yeah, I'd thought it was in C# until I was looking at it to help Artemis on dis.

Not entirely sure how using Zig for a build system but not for the code itself would work. Do you have any examples?

Sure, a friend and I worked on this project that was primarily C binaries built by Zig. The API's changed a bit since then, but that's the fun.

Again, not saying you should rewrite it, but just that if you were looking for something new, that could be a fun side project for a day or two.

[CosmoCreeper]

I have now applied for SignPath's free code signing certificate and I should be contacted in the next few business days about it.

Attestation will be done some time today, and is the next thing to do on my list.

[CosmoCreeper]

Attestations are now performed on the build artifacts in the build workflow, then when they are downloaded by the release workflow, they are verified. All artifacts that are to be published on the release that are generated in the release workflow are also attested.

Let me know if this looks right. In the meantime, I've checked it off the list.

[CosmoCreeper]

Also regarding Renovate (the tool for updating SHAs that you mentioned earlier), I have just configured Dependabot and it turns out it can do the same thing.