Skip to content

Conversation

@ameba23
Copy link
Collaborator

@ameba23 ameba23 commented Jan 5, 2026

This copies the workflow for debian packaging from rbuilder:

  • Adds a cargo profile for reproducible builds, and metadata for debian package to Cargo.toml
  • Adds a Makefile which can build using cargo-deb
  • Adds a Dockerfile which runs the packaging

TODO:

  • Github release workflow which runs the Dockerfile and uploads the packaged artifacts

Here is a test release built on this branch:
https://github.com/flashbots/attested-tls-proxy/releases/tag/vtest00

@ameba23 ameba23 marked this pull request as draft January 5, 2026 09:35
@ameba23 ameba23 requested a review from bakhtin January 5, 2026 10:09
@ameba23 ameba23 marked this pull request as ready for review January 5, 2026 10:09
* main:
  Remove check enforcing client auth with client attestation
  Allow no client auth
Cargo.toml Outdated
inherits = "release"
lto = "thin"
panic = "abort"
codegen-units = 1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not all projects would require the codegen-units = 1 to be reproducible. I added this to the Reth code-base because it was the only way to make the build reproducible but it comes at the cost of build time. Meanwhile, I was able to make lighthouse build reproducible without it (see PR).
You could try using the release profile and see if despite the reproducible flags you are setting in the makefile, it still produce the same hash or a different one upon two subsequent fresh clean builds.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok - i removed this and still get the same .deb file on two subsequent builds without docker cache - but not sure if there is a more rigorous way to check for reproducibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, usually I try to fresh build the binary/deb on 2-3 different host machines with slightly different setup and hardware specs to double check if all end up with identical hashsums. I compare them also with the results of github workflows.
We could also have something similar to flashbots-images where we create a lima build env to emulate the setup config but that might be a bit overkill.
Maybe @bakhtin has a middle solution that fits the purpose here

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

usually I try to fresh build the binary/deb on 2-3 different host machines with slightly different setup and hardware specs to double check if all end up with identical hashsums. I compare them also with the results of github workflows.

Good idea.

We could also have something similar to flashbots-images where we create a lima build env

Im not so into lima because of the difficulties of using it in CI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in case it is helpful for you, here is a draft PR where I am adding reproducible debian packaging to lighthouse

@@ -0,0 +1,14 @@
#!/usr/bin/env bash

# Checks reproducibility by running a package build twice and printing hashes of .deb package
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Im not sure to what extent this really shows that the build is reproducible, but its better than nothing

# Switch to snapshot repository
RUN sed -i '/^# http/{N;s|^# \(http[^ ]*\)\nURIs: .*|# \1\nURIs: \1|}' /etc/apt/sources.list.d/debian.sources
RUN apt-get -o Acquire::Check-Valid-Until=false update && \
apt-get install -y \
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need all of these build dependencies?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how it is done in rbuilder: https://github.com/flashbots/rbuilder/blob/develop/.github/workflows/reprotest.yml. It builds on two different versions of ubuntu in parallel and compare resulting hashsums

ameba23 and others added 4 commits January 19, 2026 13:34
Co-authored-by: Artyom Bakhtin <a@bakhtin.net>
…s-proxy into peg/debian-package

* 'peg/debian-package' of github.com:flashbots/attested-tls-proxy:
  Run on a github runner rather than WarpBuild
  Improve Cargo.toml
  Improve doccomments
  Update following merging main
  Tidy, allow config to be passed in
  Gate behind feature flag
  Error handling
  Simple attested websocket server/client
  Force single test thread in CI
  Make transport agnostic
  Rm deplicated helpers
  Deduplicate get_tls_cert
  Tidy
  Rm unused import
  Use attested-tls-client from refactored module
  Use attested-tls-server from refactored module
  Add attested TLS module
  Bump tdx_quote to 0.0.5 to remove dependency on rsa and num-bigint-dig
  Allow giving measurement file as url, and improve measurement checking logic
* main:
  Accept hostnames as target server for proxy server
  Normalize non-PKCS8 private keys
  Rm unwraps
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants