Hi NC,
thanks a thousand for your description! It's clear what to do, I'll try
as soon as I'll find time.
Means - time-based.snapshots.deb.tails.boum.org is redirected completely
to Debian archives (wich was and is available as arm). As far as I can
remember, there've been packages patched by tails or specific to tails -
and available only as amd64/x86_64 packages on
time-based.snapshots.deb.tails.boum.org (had to be recompiled to arm and
repackaged). Have you been faced with such packages?
Anyhow - thanks again, I'll come back as soon as I've found time try
that hack!
Best regards!
n9iu7pk
Am 13.02.2024 18:52 schrieb noisycoil@???:
> Hi there,
>
> I went for a DNS hack precisely so I could keep the patches to a
> minimum. All the relevant downloads are done via plain HTTP+signature
> verification, so in the end it was enough to disable a couple of
> points in the code where the signatures are actually checked.
>
> Note that simply pointing your DNS resolver to Debian's servers is not
> enough. Tails's repository (at least for branches based on devel) is
> also queried to fetch the timestamp of the most recent snapshot to be
> used, so you must redirect both to Debian AND to Tails depending on
> the URL. To do so, you must:
>
> 1. configure your DNS resolver so that the Tails domain resolves to a
> webserver you control
> 2. use that webserver to redirect some URLs to Debian, and some others
> to Tails
>
>
> *** DNS hijacking ***
>
> There are many ways to hijack your DNS resolution. The simplest to set
> up probably (and the one I'm using) is to use systemd-resolved with
> the stub resolver turned on, adding the following line to /etc/hosts
> in your build machine:
>
> x.x.x.x time-based.snapshots.deb.tails.boum.org
>
> where x.x.x.x is the IP address of the webserver you control. This can
> be running on the build machine itself, but if you decide to go this
> way make sure that x.x.x.x is not in 127.0.0.0/8, otherwise the VM
> that builds the image will be redirected to its own localhost!
>
> Some of the options you have here are: using an address (not in
> 127.0.0.0/8) bound to one of your network interfaces, creating a dummy
> network interface and assigning it a new address, or using the address
> of a remote host you control. One special case of the first option is
> using the address of the gateway for the local network that Vagrant
> will create for the VM (if you know that in advance). Personally, I'm
> using a remote host, because it was simpler to set up for me. In any
> case, make sure that the VM is able to connect to that IP address (and
> that the webserver is listening on port 80 of that address, of
> course).
>
> *** Webserver configuration ***
>
> I'm using an nginx webserver with the following configuration:
>
> server {
> server_name time-based.snapshots.deb.tails.boum.org;
> listen *:80;
> rewrite ^/(debian|debian-security)/[0-9]+(/?.*)
> http://deb.debian.org/$1$2;
> rewrite ^/[0-9.]+(/?.*) http://deb.debian.org$1;
>
> location ~
> ^/(debian|debian-security|tails)/project/trace/(debian|debian-security|tails)
> {
> proxy_pass http://204.13.164.63:80;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> proxy_set_header X-Forwarded-Protocol $scheme;
> proxy_set_header X-Forwarded-Host $http_host;
> }
>
> location ~ ^/(tails|torproject) {
> proxy_pass http://204.13.164.63:80;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Proto $scheme;
> proxy_set_header X-Forwarded-Protocol $scheme;
> proxy_set_header X-Forwarded-Host $http_host;
> }
> }
>
> 204.13.164.63 <http://204.13.164.63:80> is the real IP address of
> time-based.snapshots.deb.tails.boum.org. URLs that match the regex
> ^/(debian|debian-security|tails)/project/trace/(debian|debian-security|tails)
> must be redirected back to Tails to get the timestamp of the most
> recent snapshot. This timestamp however is never actually used: the
> redirections
>
> http://time-based.snapshots.deb.tails.boum.org/(debian|debian-security)/[0-9]+(/?.*)
> ----> http://deb.debian.org/$1$2 <http://deb.debian.org/$1$2>
> http://time-based.snapshots.deb.tails.boum.org/[0-9.]+(/?.*)
> ----> http://deb.debian.org$1 <http://deb.debian.org$1>
>
> will point the VM to the live Debian archive rather than to a Tails
> snapshot (in practice they will remove the timestamp from the URL and
> replace the Tails domain with the Debian domain). As for
> ^/(tails|torproject), I'm not sure these need to be redirected too,
> but hey, this way it works so let's keep them. Also, it's unlikely
> that anything is reading the X-Headers, but let's keep those configs
> too.
>
> A corresponding configuration could be written for Apache, but I don't
> know how to do that.
>
>
> Keep in mind that if you hijack your DNS like above you won't be able
> to build Tails on branches other than my own: the hijacked packages
> are signed with Debian's keys, but the regular branches expect
> Tails's! So after you are finished delete the entry from /etc/hosts
> and restart systemd-resolved.
>
> If you need more help feel free to write me!
>
> NC
