feat: Add reproducible Debian package builds and distribution by MoeMahhouk · Pull Request #7617 · sigp/lighthouse

MoeMahhouk · 2025-06-17T18:50:14Z

Issue Addressed

This pull request introduces workflows and configuration updates to automate the building, testing, and releasing of reproducible Debian packages for the Lighthouse project. Below are the key changes grouped by theme:

New GitHub Actions Workflows

Debian Package Release Workflow: Added .github/workflows/release-deb.yml to automate the building, testing, and releasing of reproducible Debian packages for multiple architectures (x86_64 and aarch64). Includes steps for dry-run testing, artifact uploads, and checksum generation.

Proposed Changes

Added the required configuration for cargo-deb in lighthouse's Cargo.toml.
Added Makefile targets to build the debian packages for different architectures and test their reproducibility
Added CI workflow release-deb.yml that builds and pushes the debian packages into assets similar to release-reproducible.yml
Added a simple lighthouse.service to be included in the generated lighthouse debian package

Additional Info

This is an incremental work on #7614 and requires it to be merged first

close #7618

bakhtin · 2025-06-18T09:59:05Z

@@ -0,0 +1,188 @@
+name: reproducible-build


I'd avoid imposing a responsibility for verifying reproducibility to third-parties (Lighthouse team in this case). Those who have reproducibility requirements should independently verify it relying on their infra.

The variance in the environment is not sufficient to say that the builds are reproducible. Check out how Debian independently verify reproducibility by building on different OSes with a variable set of tools.

I also followed here the steps of reth and how they are doing it here https://github.com/paradigmxyz/reth/blob/main/.github/workflows/reproducible-build.yml
However, good point on if the lighthouse team would want this to be as part of their workflow or not. I would leave it for them to decide and then we can re-iterate on what the best way to do it

bakhtin · 2025-06-18T10:00:37Z

@@ -0,0 +1,142 @@
+name: release-reproducible


Can we make reproducible builds a default for Lighthouse? Not an additional target requiring extra effort to support

I created a separate workflow for the reproducible container builds as separation of concerns similar to what the reth team did here https://github.com/paradigmxyz/reth/blob/main/.github/workflows/release-reproducible.yml

simplified the lighthouse systemd service

chong-he · 2026-01-12T03:28:26Z

cargo sort CI is failing, can you fix this?

@MoeMahhouk is this still a work in progress?

@chong-he , yes it is. I will open it up for review this week after clearing up some feedback. Then I would like to get your and your team's feedback on it to bring it to final shape

cargo sort CI is failing, can you fix this?

MoeMahhouk · 2026-01-13T16:34:59Z

cargo sort CI is failing, can you fix this?

@MoeMahhouk is this still a work in progress?

@chong-he , yes it is. I will open it up for review this week after clearing up some feedback. Then I would like to get your and your team's feedback on it to bring it to final shape

cargo sort CI is failing, can you fix this?

Done

chong-he · 2026-01-23T01:06:37Z

I have a look at this PR, from my understanding, this will include a .deb package in the release alongside with other binary files?

I am wondering what is the use case here?

MoeMahhouk · 2026-01-26T10:31:57Z

I have a look at this PR, from my understanding, this will include a .deb package in the release alongside with other binary files?

I am wondering what is the use case here?

The use case here is that those reproducibly built debian packages can be utilized to accelerate workflows that require building images that includes lighthouse. For example, BuilderNet VM image. In mkosi, you could use debian packages during the image build process which would reduce the build time substantially. Beside that use case, there are also other use-cases for such users that prefer downloading and installing lighthouse using debian packages. In addition, the binary within is built reproducibly for security purposes.
There are probably other use-cases too but those that come to my mind now. Maybe @bakhtin could also share more here

bakhtin · 2026-01-26T10:39:23Z

@chong-he I agree with what Moe described regarding the use-cases for a *.deb package. It also makes easier for people running nodes to install a *.deb package that comes with a systemd service definition baking in basic CLI options of Lighthouse simplifying managing the service.

Removes changes from sigp#7892 (beacon head monitor), sigp#8748 (bootnode fix), and sigp#8749 (v8.1.0 release) that were inadvertently pulled in by merging stable into this branch. These are not part of the deb-packaging work.

mergify · 2026-02-10T04:03:02Z

This pull request has merge conflicts. Could you please resolve them @MoeMahhouk? 🙏

dapplion · 2026-02-10T04:12:56Z

Cleaned up unrelated changes that were pulled into the PR diff by merging stable into this branch. The stable branch contained commits from #7892 (beacon head monitor), #8748 (bootnode fix), and #8749 (v8.1.0 release) that reached unstable through a different merge path, causing them to show up as part of this PR's diff.

Merged latest upstream unstable and reset all non-deb-packaging files to match, so the PR diff now only contains the intended changes:

.github/workflows/docker-reproducible.yml — extract .deb artifacts
.github/workflows/release-reproducible.yml — sign and publish workflow
Dockerfile.reproducible — build .deb in Docker
Makefile — deb packaging targets
lighthouse/Cargo.toml — cargo-deb metadata
lighthouse/debian/lighthouse.service — systemd unit
lighthouse/debian/prerm — pre-removal script

niccoloraspa · 2026-02-19T15:21:43Z

Could we get this merged before next release? We would really love to use deb packages 🙏

antondlr · 2026-04-20T13:33:34Z

@MoeMahhouk sorry for the silence on this, but it's been on my mind, and I'd like to propose a different direction: see #9147
I'd very much appreciate your input on this matter!

MoeMahhouk · 2026-05-04T15:30:56Z

@MoeMahhouk sorry for the silence on this, but it's been on my mind, and I'd like to propose a different direction: see #9147 I'd very much appreciate your input on this matter!

@antondlr No problems, thanks for revisiting this PR back.
I have reviewed your proposal PR and left you comments directly on it.
If I see correctly, the proposal PR does a solid refactoring but it missed the purpose of this PR which is debian packaging.
Is that not wanted anymore?

MoeMahhouk added 6 commits June 16, 2025 23:03

chore: refactor reproducible builds

9a2d6da

Add release-reproducible CI workflow

10a3b59

Add reproducible-build workflow to catch regressions

a4348b2

fixing linting issues

608caab

Add necessary setup for reproducible debian packaging

b946c49

add CI workflow to build and upload deb packages as assets

d58a9c1

MoeMahhouk changed the title ~~Deb packaging~~ feat: Add reproducible Debian package builds and distribution Jun 17, 2025

merge the deb packaging workflow into release.yml to avoid conflicts

af4c59b

bakhtin reviewed Jun 18, 2025

View reviewed changes

chong-he added work-in-progress PR is a work-in-progress infra-ci labels Jun 18, 2025

MoeMahhouk force-pushed the deb-packaging branch from d950bee to 1519838 Compare June 19, 2025 13:17

refinements and following packaging best practices

211063a

MoeMahhouk force-pushed the deb-packaging branch from 1519838 to 211063a Compare June 20, 2025 16:48

MoeMahhouk and others added 16 commits June 24, 2025 21:30

refine the reproducible build and test arm github runner

d93242f

make release-reproducible verify reproducibility

febc138

add label trigger for reproducible builds

19f2a0f

Merge branch 'unstable' into unstable

966ee01

Update lighthouse.service

c772026

simplified the lighthouse systemd service

Merge branch 'unstable' into unstable

f20ef0c

Merge branch 'unstable' into unstable

5674e5a

update rust version for github actions

bddc4f7

addressing PR feedback

5e21162

remove the release summary from docker-reproducible.yml

dbedf06

removed exposed ports from the Dockerfile.reproducible

f4c1e46

add stable/unstable pushes to the docker-reproducible workflow

2bcc784

remove reproducible-builds workflow

e838bfd

Merge branch 'unstable' into unstable

89847bf

remove unnecessary is_tag checks

19768d6

manual workflow trigger is just for testing purposes only

3431d03

MoeMahhouk marked this pull request as ready for review January 8, 2026 14:42

chong-he added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed work-in-progress PR is a work-in-progress labels Jan 12, 2026

fix the cargo sort issues

20ba94f

chong-he added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Jan 14, 2026

Merge branch 'unstable' into deb-packaging

3db8647

MoeMahhouk and others added 4 commits February 9, 2026 12:31

Merge branch 'sigp:stable' into deb-packaging

f465fdb

Merge branch 'unstable' into deb-packaging

af577a1

refactor and refinements

0d60612

revert unrelated changes from stable merge

50c29c5

Removes changes from sigp#7892 (beacon head monitor), sigp#8748 (bootnode fix), and sigp#8749 (v8.1.0 release) that were inadvertently pulled in by merging stable into this branch. These are not part of the deb-packaging work.

mergify Bot added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Feb 10, 2026

merge upstream unstable and remove unrelated changes

3d8a1a8

chong-he added ready-for-review The code is ready for review and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Feb 10, 2026

dapplion and others added 2 commits March 16, 2026 01:21

resolve merge conflict with unstable

3bcc867

Merge branch 'unstable' into deb-packaging

dfa7aee

michaelsproul requested a review from antondlr March 31, 2026 12:51

antondlr mentioned this pull request Apr 20, 2026

Simplify reproducible builds: single version pin, add binary tarball + AppImage outputs #9147

Open

2 tasks

Uh oh!

Conversation

MoeMahhouk commented Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issue Addressed

New GitHub Actions Workflows

Proposed Changes

Additional Info

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bakhtin Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

bakhtin Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

MoeMahhouk Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

bakhtin Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

MoeMahhouk Jun 18, 2025

Choose a reason for hiding this comment

Uh oh!

chong-he commented Jan 12, 2026

Uh oh!

MoeMahhouk commented Jan 13, 2026

Uh oh!

chong-he commented Jan 23, 2026

Uh oh!

MoeMahhouk commented Jan 26, 2026

Uh oh!

bakhtin commented Jan 26, 2026

Uh oh!

mergify Bot commented Feb 10, 2026

Uh oh!

dapplion commented Feb 10, 2026

Uh oh!

niccoloraspa commented Feb 19, 2026

Uh oh!

antondlr commented Apr 20, 2026

Uh oh!

MoeMahhouk commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

MoeMahhouk commented Jun 17, 2025 •

edited

Loading

MoeMahhouk commented May 4, 2026 •

edited

Loading