Deterministic builds for Qubes OS -- the shortcut?
389 views
Skip to first unread message
Joanna Rutkowska
Dec 22, 2015, 10:26:26 AM12/22/15
to qubes...@googlegroups.com, desk...@secure-os.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
I've recently had a chance to discuss with Marek and Wojtek, who recently took
part in the Reproducible Builds Summit in Athens [1], the current state of the
these efforts. TL;DR, the ETA for having Debian build deterministically is ~1.5
year, which I take to mean it won't happen before 2018. Then, at least 0.5 year
to get Qubes (i.e. the ISO) to build deterministically, which means we won't
have it before the end of 2018, optimistically counting ;)
So, I thought, why not take the following shortcut:
Rather than trying to make *everything* build deterministically from scratch
(which is what current efforts try to do, AFAIU) why not prepare an environment
(as in: a VM image running under Qubes) that would be optimized for ensuring
that whatever we build using qubes-builder (yes, let's focus on Qubes, for now,
ok?) it always produces the same binaries?
Admittedly the image itself would not build deterministically, true, but we
would publish it (i.e. the binary) for everybody to download and inspect.
Assuming people find it acceptable to trust this image (after spending many
nights analysing it with a disassembler, of course ;) then all future builds,
including future ISOs, images, and packages, should build deterministically. I
think this would be a big win for everybody, especially that I think we might
get this working within single weeks...
So, how such an environment should look like? I think (perhaps naively) that the
following adjustments should be just enough:
1. Patch any date/time-returning syscalls (or lib calls?) in the VM so that each
call returns time incremented by, say, +1 sec (we really don't want to go with
the resolution down to anything too small, so that the build process do not miss
the time differences due to rounding errors). AFAIU there is already a tool for
that, although, I've been told, it returns always 0, which clearly is not gonna
work with most build systems. Also, there is apparently a tool that returns
incremental time readings but on nanosec resolution, which, again, seems too
little for most build processes to notice.
2. We need to ensure the whole build process is single-threaded (think: -j1).
3. Potentially patch /dev/(u)random to return some predictable values, similar
to how we need to patch the time syscalls (think: return sha1(seed++)?)
I think we need to ensure these patches (and time/seed variables initialization)
are only for the processes started by the qubes-builder, so that any potential
interaction with the VM by the user via e.g. Terminal do not interfere here
(alternatively do not allow starting of any processes other than qubes-builder,
and use only qvm-run/qrexec for this).
And I think this should be pretty much that :) Again, we need to start with this
image being (nondeterministically) build by one of us, but then everything
should build deterministically. Perhaps including the next iteration of the very
image itself...
Marek and Wojtek tried to convince this would not work, because... if things
were that simple, others would already done that by now. That's a legit
argument, I agree, but because none of them were able to provide an actual
_technical_ argument why this would not work, I think it's worth for somebody to
just try that. Unsurprisingly I won't be able to do that myself anytime in the
coming weeks, but hope others might be interested...?
Thanks,
joanna.
[1] https://reproducible-builds.org/events/athens2015/
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJWeWuaAAoJEDOT2L8N3GcY4gYQAIkb59xUdiechRe6b0j3CVov
xdD7st61wzL0FTvJXMLxbgmvpDGBxO9BG5mb5HkuB1dJEyllcKeV4VUYBw8u+2te
kIn5t9o8+gYK/Z2gokMSH442p01J56mSPLtn2X1KM7/x6OpkNKlmokFGeLK42V8i
Yhx2VvwRLSALi0o3w67Rzxh17ApIZjzxHAYBXzS8HkMj1giGdtnEbluD2+awh/zc
ySVefV8BYAvEW6LSu3kUriIOyvTwadg0MKtwfig9ufzrfMv3+fyzJoQYiHTN8d/C
yBuz2keCuB3HhasevtICErpIcQPhaGpRzQlJd4Jm7vxkCJG5uQaK0mPNafc7WqYY
ZXin/GXsKCBuNYhyx39RkJ5GVocBlXzKvDtMm4JOTiCxzPEUHq/LkXAqKG/U+H0Y
pRWHA3cvskm6jn3G2x+y3I3aRYkg4ShTZ7iw0nQ1WndcfiMgCXrdrbEJ2vd8MXpS
IRAzF9PBwGd17yrq1bttkkQdanW+YjDVy+l8lsoYJbWX0cHZwJuLrDac7RgvDspb
HbbSuj49FHAhYdfzN7oPfs+aGoykuZ3u7rKeXBCnPjxQjRvePXHGbAgd5/tyrRJi
f6uNMxVLRYNIDzn71mapyLJPSaJmLFhDSfnGFaBXUyStJfTnf/Bxtt7LaeDl97qX
//vcjwkRX2uAEh890fiY
=DQNG
-----END PGP SIGNATURE-----
Hash: SHA256
Hi,
I've recently had a chance to discuss with Marek and Wojtek, who recently took
part in the Reproducible Builds Summit in Athens [1], the current state of the
these efforts. TL;DR, the ETA for having Debian build deterministically is ~1.5
year, which I take to mean it won't happen before 2018. Then, at least 0.5 year
to get Qubes (i.e. the ISO) to build deterministically, which means we won't
have it before the end of 2018, optimistically counting ;)
So, I thought, why not take the following shortcut:
Rather than trying to make *everything* build deterministically from scratch
(which is what current efforts try to do, AFAIU) why not prepare an environment
(as in: a VM image running under Qubes) that would be optimized for ensuring
that whatever we build using qubes-builder (yes, let's focus on Qubes, for now,
ok?) it always produces the same binaries?
Admittedly the image itself would not build deterministically, true, but we
would publish it (i.e. the binary) for everybody to download and inspect.
Assuming people find it acceptable to trust this image (after spending many
nights analysing it with a disassembler, of course ;) then all future builds,
including future ISOs, images, and packages, should build deterministically. I
think this would be a big win for everybody, especially that I think we might
get this working within single weeks...
So, how such an environment should look like? I think (perhaps naively) that the
following adjustments should be just enough:
1. Patch any date/time-returning syscalls (or lib calls?) in the VM so that each
call returns time incremented by, say, +1 sec (we really don't want to go with
the resolution down to anything too small, so that the build process do not miss
the time differences due to rounding errors). AFAIU there is already a tool for
that, although, I've been told, it returns always 0, which clearly is not gonna
work with most build systems. Also, there is apparently a tool that returns
incremental time readings but on nanosec resolution, which, again, seems too
little for most build processes to notice.
2. We need to ensure the whole build process is single-threaded (think: -j1).
3. Potentially patch /dev/(u)random to return some predictable values, similar
to how we need to patch the time syscalls (think: return sha1(seed++)?)
I think we need to ensure these patches (and time/seed variables initialization)
are only for the processes started by the qubes-builder, so that any potential
interaction with the VM by the user via e.g. Terminal do not interfere here
(alternatively do not allow starting of any processes other than qubes-builder,
and use only qvm-run/qrexec for this).
And I think this should be pretty much that :) Again, we need to start with this
image being (nondeterministically) build by one of us, but then everything
should build deterministically. Perhaps including the next iteration of the very
image itself...
Marek and Wojtek tried to convince this would not work, because... if things
were that simple, others would already done that by now. That's a legit
argument, I agree, but because none of them were able to provide an actual
_technical_ argument why this would not work, I think it's worth for somebody to
just try that. Unsurprisingly I won't be able to do that myself anytime in the
coming weeks, but hope others might be interested...?
Thanks,
joanna.
[1] https://reproducible-builds.org/events/athens2015/
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJWeWuaAAoJEDOT2L8N3GcY4gYQAIkb59xUdiechRe6b0j3CVov
xdD7st61wzL0FTvJXMLxbgmvpDGBxO9BG5mb5HkuB1dJEyllcKeV4VUYBw8u+2te
kIn5t9o8+gYK/Z2gokMSH442p01J56mSPLtn2X1KM7/x6OpkNKlmokFGeLK42V8i
Yhx2VvwRLSALi0o3w67Rzxh17ApIZjzxHAYBXzS8HkMj1giGdtnEbluD2+awh/zc
ySVefV8BYAvEW6LSu3kUriIOyvTwadg0MKtwfig9ufzrfMv3+fyzJoQYiHTN8d/C
yBuz2keCuB3HhasevtICErpIcQPhaGpRzQlJd4Jm7vxkCJG5uQaK0mPNafc7WqYY
ZXin/GXsKCBuNYhyx39RkJ5GVocBlXzKvDtMm4JOTiCxzPEUHq/LkXAqKG/U+H0Y
pRWHA3cvskm6jn3G2x+y3I3aRYkg4ShTZ7iw0nQ1WndcfiMgCXrdrbEJ2vd8MXpS
IRAzF9PBwGd17yrq1bttkkQdanW+YjDVy+l8lsoYJbWX0cHZwJuLrDac7RgvDspb
HbbSuj49FHAhYdfzN7oPfs+aGoykuZ3u7rKeXBCnPjxQjRvePXHGbAgd5/tyrRJi
f6uNMxVLRYNIDzn71mapyLJPSaJmLFhDSfnGFaBXUyStJfTnf/Bxtt7LaeDl97qX
//vcjwkRX2uAEh890fiY
=DQNG
-----END PGP SIGNATURE-----
HW42
Dec 22, 2015, 12:57:24 PM12/22/15
to Joanna Rutkowska, qubes...@googlegroups.com, desk...@secure-os.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Joanna Rutkowska:
I will also focus only on direct Qubes components (i.e. ignore packages
build by Fedora/Debian).
I think we can do better with a comparable amount of effort. The ~1.5
years for Debian is in my opinion the time until you can reproduce many
of the packages in stable. The current state in Debian is that they have
an "experimental toolchain" (basically a patched dpkg/debhelper plus some
documentation generators, see [2]). With these patches they already
produce very remarkable success (see [3]). They have a small group which
works on fixing all the small remaining problems in the ~20k Debian
source packages. I expect that they will get the dpkg/debhelper patches
into unstable in the next two months. Then a significant part of
unstable will already be reproducible. Until this lands in stable, the
Debian policy requires reproducibility, etc. a lot of time will pass.
Also the last 5-10% of packages probably will require a lot of work
until they reach (nearly) 100%.
But since we focus (for now) only on direct Qubes components this doesn't
need to bother us. I made some tests and the Qubes specific debian
packages are already reproducible when using the patched dpkg+debhelper.
On similar patches for Fedora/rpm are already be worked on.
So what we can do is simply modify qubes-builder to use a patched
version of dpkg/rpm. We also need to make some changes to qubes-builder
to record the required infos from the build-env. and be able to
reproduce these (mainly the installed versions of build dependecies).
With this we should get quickly reproducible .debs/.rpms.
A little bit more work will be needed to get the installer ISO and the
template images reproducible. But here we can use a pragmatic approach
(i.e. instead of waiting to get all things fixed upstream use
postprocessing and local patches) and also get this with manageable
effort/time.
Some notes on the proposed approach:
Partially this is already done. Gitian [4] uses a predefined VM image to
build the software in it. For example this is used for the Tor Browser
(see [5]).
I expect that there will be many small problems (which as as a whole
will also be a lot of work) until software build successfully and
reproducible with this setup. For example I can image that there will be
programs which call the gettime syscall a different number of times
depending on your CPU speed. Also stuff will break due to the
manipulated syscalls (can be fixed - but needs work).
[2]: https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
[3]: https://reproducible.debian.net/reproducible.html
[4]: https://gitian.org/
[5]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/README.build
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWeY7pAAoJEOSsySeKZGgW+l4P/jT2LYQlsuq63qZnCozL2wad
s6CP91Pbi1QTpo9jAnRyfieEXry8XeA3CY/IJe+XiCS5spoaHyQMGVeDSecgZiRp
KBlmIzpN9v8JUVLnfkrp3jx8eHJroq5hh9Ffd1F9q5xyGlvxR6SJHv2PKqcJJmgL
iLWEpAJnouzIn/6FYUX66ZOn2XUGInh9qtCRUA4vjBAL5053WUDUN1ijvb9O9pvx
vGYvLj0yz0ZXXbjzhfv4tJDIq5za0NZifZ6CHRFqQ4g3pcgAMXUjCKlzkb0pHa3l
QdnjMtGIjYnVsiZVs9xHiH3oRAeZAkrLpBrwN1qLGM//amwQRIwhA/JBAWssLl1Q
XD41XgFN0xHan/Gn4ASNkxKiR5p+9+vND0VGOvzx6tRfx4z/MtoL1pMcpzWRUfhr
/7RCtMgSp2NBycGkDbsfB8KQpf6Vyc5kAJvBfq5dvq8MO0xyICErZoMT6vEk4ImU
41h4uXpCVAzq5lWFDnVhR4uCRY3YqSrT3Y5s/PLs6EpiEOpF3EUXq4gASC8ypw38
mD+eEV9gpvweXyyRb+fq0tE8/3OUlSRlCTD+xAoeq8vCLiXaJd1KzZ90grVPMeVf
s4sJ2hpZ8MaRx8ARAHFQBDxytQlb+JqoghH0EDng9a4lU/eRJ0oTrx+b4m4Lby7L
B3xFmiRBxbNlLDeFhVk9
=IEK0
-----END PGP SIGNATURE-----
Hash: SHA512
Joanna Rutkowska:
build by Fedora/Debian).
I think we can do better with a comparable amount of effort. The ~1.5
years for Debian is in my opinion the time until you can reproduce many
of the packages in stable. The current state in Debian is that they have
an "experimental toolchain" (basically a patched dpkg/debhelper plus some
documentation generators, see [2]). With these patches they already
produce very remarkable success (see [3]). They have a small group which
works on fixing all the small remaining problems in the ~20k Debian
source packages. I expect that they will get the dpkg/debhelper patches
into unstable in the next two months. Then a significant part of
unstable will already be reproducible. Until this lands in stable, the
Debian policy requires reproducibility, etc. a lot of time will pass.
Also the last 5-10% of packages probably will require a lot of work
until they reach (nearly) 100%.
But since we focus (for now) only on direct Qubes components this doesn't
need to bother us. I made some tests and the Qubes specific debian
packages are already reproducible when using the patched dpkg+debhelper.
On similar patches for Fedora/rpm are already be worked on.
So what we can do is simply modify qubes-builder to use a patched
version of dpkg/rpm. We also need to make some changes to qubes-builder
to record the required infos from the build-env. and be able to
reproduce these (mainly the installed versions of build dependecies).
With this we should get quickly reproducible .debs/.rpms.
A little bit more work will be needed to get the installer ISO and the
template images reproducible. But here we can use a pragmatic approach
(i.e. instead of waiting to get all things fixed upstream use
postprocessing and local patches) and also get this with manageable
effort/time.
Some notes on the proposed approach:
Partially this is already done. Gitian [4] uses a predefined VM image to
build the software in it. For example this is used for the Tor Browser
(see [5]).
I expect that there will be many small problems (which as as a whole
will also be a lot of work) until software build successfully and
reproducible with this setup. For example I can image that there will be
programs which call the gettime syscall a different number of times
depending on your CPU speed. Also stuff will break due to the
manipulated syscalls (can be fixed - but needs work).
[2]: https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
[3]: https://reproducible.debian.net/reproducible.html
[4]: https://gitian.org/
[5]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/README.build
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWeY7pAAoJEOSsySeKZGgW+l4P/jT2LYQlsuq63qZnCozL2wad
s6CP91Pbi1QTpo9jAnRyfieEXry8XeA3CY/IJe+XiCS5spoaHyQMGVeDSecgZiRp
KBlmIzpN9v8JUVLnfkrp3jx8eHJroq5hh9Ffd1F9q5xyGlvxR6SJHv2PKqcJJmgL
iLWEpAJnouzIn/6FYUX66ZOn2XUGInh9qtCRUA4vjBAL5053WUDUN1ijvb9O9pvx
vGYvLj0yz0ZXXbjzhfv4tJDIq5za0NZifZ6CHRFqQ4g3pcgAMXUjCKlzkb0pHa3l
QdnjMtGIjYnVsiZVs9xHiH3oRAeZAkrLpBrwN1qLGM//amwQRIwhA/JBAWssLl1Q
XD41XgFN0xHan/Gn4ASNkxKiR5p+9+vND0VGOvzx6tRfx4z/MtoL1pMcpzWRUfhr
/7RCtMgSp2NBycGkDbsfB8KQpf6Vyc5kAJvBfq5dvq8MO0xyICErZoMT6vEk4ImU
41h4uXpCVAzq5lWFDnVhR4uCRY3YqSrT3Y5s/PLs6EpiEOpF3EUXq4gASC8ypw38
mD+eEV9gpvweXyyRb+fq0tE8/3OUlSRlCTD+xAoeq8vCLiXaJd1KzZ90grVPMeVf
s4sJ2hpZ8MaRx8ARAHFQBDxytQlb+JqoghH0EDng9a4lU/eRJ0oTrx+b4m4Lby7L
B3xFmiRBxbNlLDeFhVk9
=IEK0
-----END PGP SIGNATURE-----
Eric Shelton
Dec 22, 2015, 1:43:00 PM12/22/15
to qubes-devel, joa...@invisiblethingslab.com, desk...@secure-os.org, hw...@ipsumj.de
Given the discussion of piggybacking off of Debian's efforts at implementing reproducible builds (however soon they may be available for use in the Qubes build process), does that mean there is a plan to transition away from Fedora to Debian as the base on which Qubes is built? I have no complaints with going in that direction (Fedora's release cycles seem to introduce unnecessary friction) - just interested where things are headed.
Eric
HW42
Dec 22, 2015, 1:54:38 PM12/22/15
to Eric Shelton, qubes-devel, joa...@invisiblethingslab.com, desk...@secure-os.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Eric Shelton:
Hash: SHA512
problem (How to get the Qubes specific components reproducible?) this is
nearly irrelevant (Ok the rpm patches aren't ready yet but this is a
very small problem (as long you don't care about upstream)).
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWeZxYAAoJEOSsySeKZGgW+ykQAKXVjaZQvw/TVoPB27mTEyvV
XcYNsuAoYZCTqP0JJPa+OIbbQiUTRpHouPD2GwdRpwvYaMPMd8auFZh5P6IlP9sl
g0qjb+hByrPJZ/ZtEbRrZpS5w5ry55LxZp0bLg20k+m7AuUsO/vSlAU2pmkkbpzQ
950cDoFPxPDhaklriGwHS2z1EbA4dx5KROK5YsQR6x4Fvt6oSNEMnfbd15mrnInr
/pjrBfTL7cBqLcoJbzOdMkcr/QNuPc5MZ+KsWxbQFrylYhWRFTmeQxJjBsv4efRq
fKLYeUmgb7kZRZd8PXhs5vSfqUYGuPkGL2ZQQvpqYrXaxX/jhEirDX1CFWJsKDWG
QHXHpgprMV6095UFHMiS0AKL4GT8HjEr/MXCN3eN67LZEKf0j6iSi6+A15NJlFOv
cHrgRkR53mIe1xdcyQZHIBvYOzIHgQEEp1R4y/9B9tz04bRxJLsK4gB1OCOTHT/d
Nj/FyxKb6xmCqNA3JxWdnI+bYxJR4zOKeyuQeKn6Y9eWwxlIX58pW8UCWZt1fUeI
obcZzcOztdt4BcNqgq3OiS39L6LQ8dQyXqhDnSDACbKPLuhhTeVoa9jRr7l1ZYGp
bOXgCQXCm+Mx6QfYqHDnNgx3gCg9sipVN/1fHENoP/ZWMHOBTDCq3/HwUCSkgZII
Deyf6UHderFzM+tdTV/D
=R3pK
-----END PGP SIGNATURE-----
Patrick Schleizer
Dec 22, 2015, 6:59:01 PM12/22/15
to Joanna Rutkowska, qubes...@googlegroups.com, desk...@secure-os.org
Hi!
Debian is working on deterministic built packages. To my knowledge, they
are not yet working on deterministic iso and/or raw images.
To have a package build deterministically is one thing. To have it not
generate any entropy while installing it [within the raw image], is
another story.
Some non-determinsitic examples include:
- /etc/xml/catalog
- /var/cache/man
- /var/cache/fontconfig
- More examples can be extracted from here:
https://github.com/Whonix/whonix-initializer/blob/8b150409c464427c89aa9d4e261b80f5fc2fa5d1/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup
- Other small things that add up such as MBR random disk signatures and
disk uuid.
- File creation and access times.
- Location / ordering within the image.
So I am afraid, even when the Debian repository is 100% reproducible, it
will take longer until also iso and/or raw images can be build reproducible.
Cheers,
Patrick
Debian is working on deterministic built packages. To my knowledge, they
are not yet working on deterministic iso and/or raw images.
To have a package build deterministically is one thing. To have it not
generate any entropy while installing it [within the raw image], is
another story.
Some non-determinsitic examples include:
- /etc/xml/catalog
- /var/cache/man
- /var/cache/fontconfig
- More examples can be extracted from here:
https://github.com/Whonix/whonix-initializer/blob/8b150409c464427c89aa9d4e261b80f5fc2fa5d1/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup
- Other small things that add up such as MBR random disk signatures and
disk uuid.
- File creation and access times.
- Location / ordering within the image.
So I am afraid, even when the Debian repository is 100% reproducible, it
will take longer until also iso and/or raw images can be build reproducible.
Cheers,
Patrick
HW42
Dec 22, 2015, 7:19:19 PM12/22/15
to Patrick Schleizer, Joanna Rutkowska, qubes...@googlegroups.com, desk...@secure-os.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Patrick Schleizer:
> To have a package build deterministically is one thing. To have it not
> generate any entropy while installing it [within the raw image], is
> another story.
>
> Some non-determinsitic examples include:
>
> - /etc/xml/catalog
>
> - /var/cache/man
>
> - /var/cache/fontconfig
>
> - More examples can be extracted from here:
>
> https://github.com/Whonix/whonix-initializer/blob/8b150409c464427c89aa9d4e261b80f5fc2fa5d1/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup
>
> - Other small things that add up such as MBR random disk signatures and
> disk uuid.
>
> - File creation and access times.
>
> - Location / ordering within the image.
>
> So I am afraid, even when the Debian repository is 100% reproducible, it
> will take longer until also iso and/or raw images can be build reproducible.
Reproducible packages and reproducible installs/images are two different
problems (with the same motivation). I.e. you can work on reproducible
installs without reproducible packages.
I think reproducible images are a manageable complex problem. I made
some test and came to a similar list as you. Most of the stuff is easily
fixed (at least as long as you don't need to do it upstream).
Qubes has the advantage that, since we are dealing with VM images, we
can move much of the cache generating stuff to the first boot (that's
not a nice option for live distributions).
But yes that's work and needs to be done ;]
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWeehzAAoJEOSsySeKZGgWqUIP/icUTAn2Xu699zkqO0Y+CiKG
jZQnsA6JFVOsxrKppyjFivGAoTFvwzGflz1vPSvDXv8HmGABE61g0Q96uVLupkq4
3vnYZoq+vDtqTaCmN+vZpsF2lf/cMveFnafBHVY2QvGWCrFlG/nwFpiQtlQ4zxZJ
cLF7C9py36bjmNJ/PpZ6nsbZPt96AMk4nXtx/ioEqgmKD9P94zvOb/NwvD+j16Ad
50+3Hb4xybRe/Z7dVh+vW8GYU1ecw4VXL/mnjEPNJcHL6gA1C2fMKFiEtCH4SQ02
d0+hMP1dLRxtMk330JyRPKBZio4BjlBq8545KDeuAazNf+9dESM32tRwYmB/r9Qa
9rX1+Aa+zkyWbXx4KNo9WT4C8ue0biX0f4FwaVlsqF1buC8A7i21aKGappabZ6y3
PyqiCOErS/i8RnPapOB4Ff0CJyFhkT8rpXLxCzXjxZ2vDCz+I7oMaQHU+ouMvO1y
9SBaa55RjvbVeIR+05Rkz9wWWAf99vc7CSuxIeGlin0ePfny8t5n1bd+DpzDkxRV
hpZYvPifBoTbEOGNT14Jqdzfw9CqqooCebLXwM7eoIL5yDKVYY3OvmeJoySJfluI
3DZfc+SU/8ve4n830NsRRVNGdi6MhvY7/OwOmF4WmIEVlskYvtSMcF5+ZHpcBERS
UV1SIz7MunHN7NC6LbQj
=/tyj
-----END PGP SIGNATURE-----
Hash: SHA512
Patrick Schleizer:
> Hi!
>
> Debian is working on deterministic built packages. To my knowledge, they
> are not yet working on deterministic iso and/or raw images.
They focus currently on packages. But its on their TODO list AFAIK.
>
> Debian is working on deterministic built packages. To my knowledge, they
> are not yet working on deterministic iso and/or raw images.
> To have a package build deterministically is one thing. To have it not
> generate any entropy while installing it [within the raw image], is
> another story.
>
> Some non-determinsitic examples include:
>
> - /etc/xml/catalog
>
> - /var/cache/man
>
> - /var/cache/fontconfig
>
> - More examples can be extracted from here:
>
> https://github.com/Whonix/whonix-initializer/blob/8b150409c464427c89aa9d4e261b80f5fc2fa5d1/usr/lib/anon-dist/chroot-scripts-post.d/80_cleanup
>
> - Other small things that add up such as MBR random disk signatures and
> disk uuid.
>
> - File creation and access times.
>
> - Location / ordering within the image.
>
> So I am afraid, even when the Debian repository is 100% reproducible, it
> will take longer until also iso and/or raw images can be build reproducible.
problems (with the same motivation). I.e. you can work on reproducible
installs without reproducible packages.
I think reproducible images are a manageable complex problem. I made
some test and came to a similar list as you. Most of the stuff is easily
fixed (at least as long as you don't need to do it upstream).
Qubes has the advantage that, since we are dealing with VM images, we
can move much of the cache generating stuff to the first boot (that's
not a nice option for live distributions).
But yes that's work and needs to be done ;]
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWeehzAAoJEOSsySeKZGgWqUIP/icUTAn2Xu699zkqO0Y+CiKG
jZQnsA6JFVOsxrKppyjFivGAoTFvwzGflz1vPSvDXv8HmGABE61g0Q96uVLupkq4
3vnYZoq+vDtqTaCmN+vZpsF2lf/cMveFnafBHVY2QvGWCrFlG/nwFpiQtlQ4zxZJ
cLF7C9py36bjmNJ/PpZ6nsbZPt96AMk4nXtx/ioEqgmKD9P94zvOb/NwvD+j16Ad
50+3Hb4xybRe/Z7dVh+vW8GYU1ecw4VXL/mnjEPNJcHL6gA1C2fMKFiEtCH4SQ02
d0+hMP1dLRxtMk330JyRPKBZio4BjlBq8545KDeuAazNf+9dESM32tRwYmB/r9Qa
9rX1+Aa+zkyWbXx4KNo9WT4C8ue0biX0f4FwaVlsqF1buC8A7i21aKGappabZ6y3
PyqiCOErS/i8RnPapOB4Ff0CJyFhkT8rpXLxCzXjxZ2vDCz+I7oMaQHU+ouMvO1y
9SBaa55RjvbVeIR+05Rkz9wWWAf99vc7CSuxIeGlin0ePfny8t5n1bd+DpzDkxRV
hpZYvPifBoTbEOGNT14Jqdzfw9CqqooCebLXwM7eoIL5yDKVYY3OvmeJoySJfluI
3DZfc+SU/8ve4n830NsRRVNGdi6MhvY7/OwOmF4WmIEVlskYvtSMcF5+ZHpcBERS
UV1SIz7MunHN7NC6LbQj
=/tyj
-----END PGP SIGNATURE-----
Holger Levsen
Dec 23, 2015, 8:54:01 AM12/23/15
to qubes...@googlegroups.com, desk...@secure-os.org
Hi,
On Dienstag, 22. Dezember 2015, Joanna Rutkowska wrote:
> TL;DR, the ETA for having Debian build
> deterministically is ~1.5 year, which I take to mean it won't happen
> before 2018.
there are two slightly different things here to look at: getting Debian 100%
reproducible (=all 23k source packages in main) and getting reproducible
packages in Debian at all, cause then one can tackle those packages one is
interested in.
To get Debian 9, aka Stretch, the next release reproducible at all, we need to
get three fixes into Debian sid/unstable until November 5th 2016, which is the
announced freeze date for Debian. These three fixes exist, so it's "merely a
question of getting them into sid…" ;-)
In our test setup, reproducible.debian.net, we are building all 23k packages
with these 3 fixes (and 8 other toolchain packages) and a reaching 85%
reproducibility in the current test setup atm. With just those 3 fixes we
probably would be at 70% or so, but I do think that it should be possible to
get them all in in the next 10 months.
And then, Debian 9 will probably be released in April or May 2017. (The last
10 years every release cycle was 22 months on average with a max variation of
2 months, it's a wrong myth that Debian releases are unpredictable.)
Getting Debian 100% reproducible OTOH I'm not sure whether we'll achieve for
Debian 10, though I would love to see that happen 8-) Anyhow.
> Rather than trying to make *everything* build deterministically from
> scratch (which is what current efforts try to do, AFAIU) why not prepare
> an environment (as in: a VM image running under Qubes) that would be
> optimized for ensuring that whatever we build using qubes-builder (yes,
> let's focus on Qubes, for now, ok?) it always produces the same binaries?
I think focusing on Qubes here is entirely appropriate and taking shortcuts is
also a good idea ;-)
> Admittedly the image itself would not build deterministically, true, but we
> would publish it (i.e. the binary) for everybody to download and inspect.
> Assuming people find it acceptable to trust this image (after spending many
> nights analysing it with a disassembler, of course ;) then all future
> builds, including future ISOs, images, and packages, should build
> deterministically. I think this would be a big win for everybody,
> especially that I think we might get this working within single weeks...
I'm not sure I understand, you want to create an environment to build all the
packages Qubes depends on reproducibile? To rebuild all fedora packages
reproducible, so that those can be used to build a reproducible installation
image?
Cause there are actually two problems to tackle, I think: a.) getting
reproducible binary packages and b.) getting a reproducible installation
image.
To answer b.)
I've basically don't know how the Qubes iso is really made, but I assume it's
the same or similar as it would be in Debian: packages are used to create a
chroot which is turned into the iso. In the Debian case this leads to another
problem: package installation is also not reproducible, thus such images aint
neither.
In Debian the main source (besides timestamps of files+directories created at
installation time) for this is that apt installs packages in non deterministic
order and then the postinst scripts are run undeterministically as well, which
for example can lead to different uids/gids for the same system users…
And to get back to a.) in case you dont want to rebuild all of fedora /
debian: then you "just" need a stable package binary repository, so that when
you rebuild an iso after a month (or more time) updates (which were not
available at the original creation date) are not included in image. Debian has
snapsho.debian.org which archives every binary package ever released by
Debian, I don't know hat Fedora has to offer here.
> So, how such an environment should look like? I think (perhaps naively)
> that the following adjustments should be just enough:
>
> 1. Patch any date/time-returning syscalls (or lib calls?) in the VM so that
> each call returns time incremented by, say, +1 sec (we really don't want
> to go with the resolution down to anything too small, so that the build
> process do not miss the time differences due to rounding errors). AFAIU
> there is already a tool for that, although, I've been told, it returns
> always 0, which clearly is not gonna work with most build systems. Also,
> there is apparently a tool that returns incremental time readings but on
> nanosec resolution, which, again, seems too little for most build
> processes to notice.
there is faketime which does that and which we found to cause problems when
building certain software, so we rather suggest dropping timestamps.
But maybe using faketime is the way to go when building such images? It's
definitly a a nice shortcut if it works ;-)
> 2. We need to ensure the whole build process is single-threaded (think:
> -j1).
actually building in parallel aint a problem per se, those 85% reproducibility
of Debian packages is achieved with parallel builds.
> 3. Potentially patch /dev/(u)random to return some predictable values,
> similar to how we need to patch the time syscalls (think: return
> sha1(seed++)?)
seeding using SOURCE_DATE_EPOCH is generally a good idea, yes.
https://reproducible-builds.org/specs/source-date-epoch/
> Marek and Wojtek tried to convince this would not work, because... if
> things were that simple, others would already done that by now. That's a
> legit argument, I agree, but because none of them were able to provide an
> actual _technical_ argument why this would not work, I think it's worth
> for somebody to just try that. Unsurprisingly I won't be able to do that
> myself anytime in the coming weeks, but hope others might be
> interested...?
I agree, somesome should just test this. I'd be happy to run these tests to
build Qubes on our hardware, we have plenty of ressources to waste^wuse.
cheers,
Holger
On Dienstag, 22. Dezember 2015, Joanna Rutkowska wrote:
> TL;DR, the ETA for having Debian build
> deterministically is ~1.5 year, which I take to mean it won't happen
> before 2018.
reproducible (=all 23k source packages in main) and getting reproducible
packages in Debian at all, cause then one can tackle those packages one is
interested in.
To get Debian 9, aka Stretch, the next release reproducible at all, we need to
get three fixes into Debian sid/unstable until November 5th 2016, which is the
announced freeze date for Debian. These three fixes exist, so it's "merely a
question of getting them into sid…" ;-)
In our test setup, reproducible.debian.net, we are building all 23k packages
with these 3 fixes (and 8 other toolchain packages) and a reaching 85%
reproducibility in the current test setup atm. With just those 3 fixes we
probably would be at 70% or so, but I do think that it should be possible to
get them all in in the next 10 months.
And then, Debian 9 will probably be released in April or May 2017. (The last
10 years every release cycle was 22 months on average with a max variation of
2 months, it's a wrong myth that Debian releases are unpredictable.)
Getting Debian 100% reproducible OTOH I'm not sure whether we'll achieve for
Debian 10, though I would love to see that happen 8-) Anyhow.
> Rather than trying to make *everything* build deterministically from
> scratch (which is what current efforts try to do, AFAIU) why not prepare
> an environment (as in: a VM image running under Qubes) that would be
> optimized for ensuring that whatever we build using qubes-builder (yes,
> let's focus on Qubes, for now, ok?) it always produces the same binaries?
also a good idea ;-)
> Admittedly the image itself would not build deterministically, true, but we
> would publish it (i.e. the binary) for everybody to download and inspect.
> Assuming people find it acceptable to trust this image (after spending many
> nights analysing it with a disassembler, of course ;) then all future
> builds, including future ISOs, images, and packages, should build
> deterministically. I think this would be a big win for everybody,
> especially that I think we might get this working within single weeks...
packages Qubes depends on reproducibile? To rebuild all fedora packages
reproducible, so that those can be used to build a reproducible installation
image?
Cause there are actually two problems to tackle, I think: a.) getting
reproducible binary packages and b.) getting a reproducible installation
image.
To answer b.)
I've basically don't know how the Qubes iso is really made, but I assume it's
the same or similar as it would be in Debian: packages are used to create a
chroot which is turned into the iso. In the Debian case this leads to another
problem: package installation is also not reproducible, thus such images aint
neither.
In Debian the main source (besides timestamps of files+directories created at
installation time) for this is that apt installs packages in non deterministic
order and then the postinst scripts are run undeterministically as well, which
for example can lead to different uids/gids for the same system users…
And to get back to a.) in case you dont want to rebuild all of fedora /
debian: then you "just" need a stable package binary repository, so that when
you rebuild an iso after a month (or more time) updates (which were not
available at the original creation date) are not included in image. Debian has
snapsho.debian.org which archives every binary package ever released by
Debian, I don't know hat Fedora has to offer here.
> So, how such an environment should look like? I think (perhaps naively)
> that the following adjustments should be just enough:
>
> 1. Patch any date/time-returning syscalls (or lib calls?) in the VM so that
> each call returns time incremented by, say, +1 sec (we really don't want
> to go with the resolution down to anything too small, so that the build
> process do not miss the time differences due to rounding errors). AFAIU
> there is already a tool for that, although, I've been told, it returns
> always 0, which clearly is not gonna work with most build systems. Also,
> there is apparently a tool that returns incremental time readings but on
> nanosec resolution, which, again, seems too little for most build
> processes to notice.
building certain software, so we rather suggest dropping timestamps.
But maybe using faketime is the way to go when building such images? It's
definitly a a nice shortcut if it works ;-)
> 2. We need to ensure the whole build process is single-threaded (think:
> -j1).
of Debian packages is achieved with parallel builds.
> 3. Potentially patch /dev/(u)random to return some predictable values,
> similar to how we need to patch the time syscalls (think: return
> sha1(seed++)?)
https://reproducible-builds.org/specs/source-date-epoch/
> Marek and Wojtek tried to convince this would not work, because... if
> things were that simple, others would already done that by now. That's a
> legit argument, I agree, but because none of them were able to provide an
> actual _technical_ argument why this would not work, I think it's worth
> for somebody to just try that. Unsurprisingly I won't be able to do that
> myself anytime in the coming weeks, but hope others might be
> interested...?
build Qubes on our hardware, we have plenty of ressources to waste^wuse.
cheers,
Holger
Holger Levsen
Dec 23, 2015, 8:59:44 AM12/23/15
to qubes...@googlegroups.com, desk...@secure-os.org
Hi,
On Dienstag, 22. Dezember 2015, HW42 wrote:
> But since we focus (for now) only on direct Qubes components this doesn't
> need to bother us. I made some tests and the Qubes specific debian
> packages are already reproducible when using the patched dpkg+debhelper.
> On similar patches for Fedora/rpm are already be worked on.
can you give me that list of packages please so I can add package sets like we
already have for tails or grml:
https://reproducible.debian.net/unstable/amd64/pkg_set_tails.html
https://reproducible.debian.net/unstable/amd64/pkg_set_tails_build-depends.html
https://reproducible.debian.net/unstable/amd64/pkg_set_grml.html
https://reproducible.debian.net/unstable/amd64/pkg_set_grml_build-depends.html
> A little bit more work will be needed to get the installer ISO and the
> template images reproducible. But here we can use a pragmatic approach
> (i.e. instead of waiting to get all things fixed upstream use
> postprocessing and local patches) and also get this with manageable
> effort/time.
I agree.
> Some notes on the proposed approach:
>
> Partially this is already done. Gitian [4] uses a predefined VM image to
> build the software in it. For example this is used for the Tor Browser
Yup, I was going to suggest to look at gitian too.
Another thing I forgot to mention in my previous mail: there has been some
work done on reproducible installations already, see here:
https://wiki.debian.org/ReproducibleInstalls
cheers,
Holger
On Dienstag, 22. Dezember 2015, HW42 wrote:
> But since we focus (for now) only on direct Qubes components this doesn't
> need to bother us. I made some tests and the Qubes specific debian
> packages are already reproducible when using the patched dpkg+debhelper.
> On similar patches for Fedora/rpm are already be worked on.
already have for tails or grml:
https://reproducible.debian.net/unstable/amd64/pkg_set_tails.html
https://reproducible.debian.net/unstable/amd64/pkg_set_tails_build-depends.html
https://reproducible.debian.net/unstable/amd64/pkg_set_grml.html
https://reproducible.debian.net/unstable/amd64/pkg_set_grml_build-depends.html
> A little bit more work will be needed to get the installer ISO and the
> template images reproducible. But here we can use a pragmatic approach
> (i.e. instead of waiting to get all things fixed upstream use
> postprocessing and local patches) and also get this with manageable
> effort/time.
> Some notes on the proposed approach:
>
> Partially this is already done. Gitian [4] uses a predefined VM image to
> build the software in it. For example this is used for the Tor Browser
Another thing I forgot to mention in my previous mail: there has been some
work done on reproducible installations already, see here:
https://wiki.debian.org/ReproducibleInstalls
cheers,
Holger
HW42
Dec 23, 2015, 9:41:07 AM12/23/15
to Holger Levsen, qubes...@googlegroups.com, desk...@secure-os.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Holger Levsen:
Hash: SHA512
> Hi,
>
> On Dienstag, 22. Dezember 2015, HW42 wrote:
>> But since we focus (for now) only on direct Qubes components this doesn't
>> need to bother us. I made some tests and the Qubes specific debian
>> packages are already reproducible when using the patched dpkg+debhelper.
>> On similar patches for Fedora/rpm are already be worked on.
>
> can you give me that list of packages please so I can add package sets like we
> already have for tails or grml:
>
> https://reproducible.debian.net/unstable/amd64/pkg_set_tails.html
> https://reproducible.debian.net/unstable/amd64/pkg_set_tails_build-depends.html
> https://reproducible.debian.net/unstable/amd64/pkg_set_grml.html
> https://reproducible.debian.net/unstable/amd64/pkg_set_grml_build-depends.html
IIUC these are package lists about packages from the Debian archive. I
>
> On Dienstag, 22. Dezember 2015, HW42 wrote:
>> But since we focus (for now) only on direct Qubes components this doesn't
>> need to bother us. I made some tests and the Qubes specific debian
>> packages are already reproducible when using the patched dpkg+debhelper.
>> On similar patches for Fedora/rpm are already be worked on.
>
> can you give me that list of packages please so I can add package sets like we
> already have for tails or grml:
>
> https://reproducible.debian.net/unstable/amd64/pkg_set_tails.html
> https://reproducible.debian.net/unstable/amd64/pkg_set_tails_build-depends.html
> https://reproducible.debian.net/unstable/amd64/pkg_set_grml.html
> https://reproducible.debian.net/unstable/amd64/pkg_set_grml_build-depends.html
was talking about the Qubes specific components, which are currently not
in the Debian archive.
The list of Qubes components/modules which build debian packages are (if
I haven't missed one):
app-linux-pdf-converter
app-linux-split-gpg
app-linux-tor
app-thunderbird
core-agent-linux
core-qubesdb
core-vchan-xen
gui-agent-linux
gui-common
linux-utils
vmm-xen
(see https:/github.com/QubesOS/qubes-$i)
>> A little bit more work will be needed to get the installer ISO and the
>> template images reproducible. But here we can use a pragmatic approach
>> (i.e. instead of waiting to get all things fixed upstream use
>> postprocessing and local patches) and also get this with manageable
>> effort/time.
>
> I agree.
>
>> Some notes on the proposed approach:
>>
>> Partially this is already done. Gitian [4] uses a predefined VM image to
>> build the software in it. For example this is used for the Tor Browser
>
> Yup, I was going to suggest to look at gitian too.
>
> Another thing I forgot to mention in my previous mail: there has been some
> work done on reproducible installations already, see here:
> https://wiki.debian.org/ReproducibleInstalls
>
>
> cheers,
> Holger
>
iQIcBAEBCgAGBQJWerJtAAoJEOSsySeKZGgW0uMQAKD0VqYWEXSQRhBmUt99VGDq
KZwWyEFijJ93F+wUBILVgARKHQ1ebiS1DcShP3BFsPmfgFm/wmuRrMsKTvRMByRO
L3zr1xZCUqnG4EyrTdKtGXM2ctp2WAOg+LBgZggXYBwcnPofNLomOp+a79nyyV+9
9rFFuH/lx8LVlyzb4e5Naw8mSXGlxyhcOy5H/EvimxNqSDRODxrbAr7ynU5lQggF
/Mx0uW/4PIPueSQO9J9GtWHiDE/LJwRKlG6fEsLuP4e/vljs8WqP9zTthHk+hpKU
JviAFbhxjRHBqnx/ui5loM/4wj11pxLypnSk94OpKYE2vp1uurnziDMePkFtWeR1
9tYO6dKWziP92tbOrIuyTB48qz5yzaOGQ137HgbcEikGrEste7MSZqYvC5DAWdP0
uSVPc6AvSOl8IRlXyX9gIoHMykC6YNKyrMc578jR95pVTleGDSO7RRSzKULR4HLN
nPQOYI/vkZZq06ViSYXEqvCnSi1h34WeVhzbYZFRFbyN8AqI94s9kE2LIAMfMEf/
n6TojDGrPgJGe5wcYQEDWWfcMgPF4ypwE6XFwiONXbcnA9cT5/642DuryjB2F4QE
tTe1Y5lwkDPTnviIJjhZmgpRJI9xsUHvOc27qUeHz39WYK5RC83vrVeklaLbLAXw
vOpDPwMyiVGgA1l7RSJd
=5p27
-----END PGP SIGNATURE-----
Holger Levsen
Dec 23, 2015, 10:31:11 AM12/23/15
to qubes...@googlegroups.com, desk...@secure-os.org
Hi,
On Mittwoch, 23. Dezember 2015, HW42 wrote:
> IIUC these are package lists about packages from the Debian archive. I
> was talking about the Qubes specific components, which are currently not
> in the Debian archive.
right, these are two different things. And I totally agree, that it would be
interesting to test whether those Qubes packages can be build reproducible. If
you can point me to a source rpm (or deb) repo, I'd be glad to add those
tests.
But I also think having the set of packages which end up on the Qubes images
tested for reproducibility would be interesting.
cheers,
Holger
On Mittwoch, 23. Dezember 2015, HW42 wrote:
> IIUC these are package lists about packages from the Debian archive. I
> was talking about the Qubes specific components, which are currently not
> in the Debian archive.
interesting to test whether those Qubes packages can be build reproducible. If
you can point me to a source rpm (or deb) repo, I'd be glad to add those
tests.
But I also think having the set of packages which end up on the Qubes images
tested for reproducibility would be interesting.
cheers,
Holger
Wojtek Porczyk
Dec 23, 2015, 5:40:03 PM12/23/15
to Eric Shelton, HW42, qubes-devel, joa...@invisiblethingslab.com, desk...@secure-os.org
On Tue, Dec 22, 2015 at 07:54:17PM +0100, HW42 wrote:
> Eric Shelton:
that kind of help which is really helpful, because it was mostly
unrelated to distribution, but more about specific tools like compilers.
The is in constrast to Fedora community, which was nearly absent from
the summit and it is my feeling that they don't treat the subject
seriously enough.
About transition, there is no decision. I can only say we are quite
annoyed with Fedora lately because of several reasons, so we consider
our options. Our current state of internal, face to face discussion
boils to those points:
- We will always have Fedora template as one of options, we basically
don't care much about what goes there and we welcome all distros and
OSes, including BSD and Windows.
- It would be much effort to transition dom0 from Fedora to Debian. It
already is hard to upgrade Fedora from 20 to 23 (mainly because we
would have to rewrite WM plugins, which draw those colourful titlebars).
- There will be also much effort to make GUI domain, which most probably
will be based on Fedora (and not Debian) because of drivers. [1]
- Once we move the graphics subsystem out of dom0, the amount of work to
change distro in dom0 will be probably much smaller.
- We wouldn't like to do 2x big effort, only 1x big and 1x small, but:
- Fedora 20 is already old and unsupported anyway and each year it
becomes more obsolete anyway, so something has to be done anyway.
- We see several distros which can be considered, but I can't say which
and why.
- There are other efforts which are already more pressing. I for one
would like to finish core3, which hopefuly will be merged in
January/February.
I'm afraid that's all I can send unencrypted. :) I'd obviously welcome
any comments, but primarily we are thankful for patches, particulary
your work around GUI passthrough.
[1] C. f. sys-net, which will *probably* (don't quote me on that) by
default remain as Fedora, however we know that many people successfuly
run it as Debian.
> I can't answer your question. But I want to note that for the discussed
> problem (How to get the Qubes specific components reproducible?) this is
> nearly irrelevant (Ok the rpm patches aren't ready yet but this is a
> very small problem (as long you don't care about upstream)).
Right, but we ultimately would like to have whole ISO to be somehow
reproducible. That would require templates to be built reproducibly...
If Fedora template would be the last thing that will be unreproducible
and we won't have enough support from upstream (as opposed to Debian
community, which I find very friendly and helpful), we reserve our
option (of course, only hypothetically, as a shourtcut etc.) to for
example release Debian (and Whonix) -only ISO, which will be
reproducible, and "the other" ISO with Fedora.
--
Merry Christmas, _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
> Eric Shelton:
> > Given the discussion of piggybacking off of Debian's efforts at
> > implementing reproducible builds (however soon they may be available for
> > use in the Qubes build process), does that mean there is a plan to
> > transition away from Fedora to Debian as the base on which Qubes is built?
> > I have no complaints with going in that direction (Fedora's release cycles
> > seem to introduce unnecessary friction) - just interested where things are
> > headed.
On the summit we received much help from Debian community, and it was
> > implementing reproducible builds (however soon they may be available for
> > use in the Qubes build process), does that mean there is a plan to
> > transition away from Fedora to Debian as the base on which Qubes is built?
> > I have no complaints with going in that direction (Fedora's release cycles
> > seem to introduce unnecessary friction) - just interested where things are
> > headed.
that kind of help which is really helpful, because it was mostly
unrelated to distribution, but more about specific tools like compilers.
The is in constrast to Fedora community, which was nearly absent from
the summit and it is my feeling that they don't treat the subject
seriously enough.
About transition, there is no decision. I can only say we are quite
annoyed with Fedora lately because of several reasons, so we consider
our options. Our current state of internal, face to face discussion
boils to those points:
- We will always have Fedora template as one of options, we basically
don't care much about what goes there and we welcome all distros and
OSes, including BSD and Windows.
- It would be much effort to transition dom0 from Fedora to Debian. It
already is hard to upgrade Fedora from 20 to 23 (mainly because we
would have to rewrite WM plugins, which draw those colourful titlebars).
- There will be also much effort to make GUI domain, which most probably
will be based on Fedora (and not Debian) because of drivers. [1]
- Once we move the graphics subsystem out of dom0, the amount of work to
change distro in dom0 will be probably much smaller.
- We wouldn't like to do 2x big effort, only 1x big and 1x small, but:
- Fedora 20 is already old and unsupported anyway and each year it
becomes more obsolete anyway, so something has to be done anyway.
- We see several distros which can be considered, but I can't say which
and why.
- There are other efforts which are already more pressing. I for one
would like to finish core3, which hopefuly will be merged in
January/February.
I'm afraid that's all I can send unencrypted. :) I'd obviously welcome
any comments, but primarily we are thankful for patches, particulary
your work around GUI passthrough.
[1] C. f. sys-net, which will *probably* (don't quote me on that) by
default remain as Fedora, however we know that many people successfuly
run it as Debian.
> I can't answer your question. But I want to note that for the discussed
> problem (How to get the Qubes specific components reproducible?) this is
> nearly irrelevant (Ok the rpm patches aren't ready yet but this is a
> very small problem (as long you don't care about upstream)).
reproducible. That would require templates to be built reproducibly...
If Fedora template would be the last thing that will be unreproducible
and we won't have enough support from upstream (as opposed to Debian
community, which I find very friendly and helpful), we reserve our
option (of course, only hypothetically, as a shourtcut etc.) to for
example release Debian (and Whonix) -only ISO, which will be
reproducible, and "the other" ISO with Fedora.
--
Merry Christmas, _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
Eric Shelton
Dec 23, 2015, 7:54:59 PM12/23/15
to Eric Shelton, HW42, qubes-devel, Joanna Rutkowska, desk...@secure-os.org
>
> --
> Merry Christmas, _.-._
> Wojtek Porczyk .-^' '^-.
> Invisible Things Lab |'-.-^-.-'|
> | | | |
> I do not fear computers, | '-.-' |
> I fear lack of them. '-._ : ,-'
> -- Isaac Asimov `^-^-_>
Thank you for taking the time to write this up. I appreciate hearing
> --
> Merry Christmas, _.-._
> Wojtek Porczyk .-^' '^-.
> Invisible Things Lab |'-.-^-.-'|
> | | | |
> I do not fear computers, | '-.-' |
> I fear lack of them. '-._ : ,-'
> -- Isaac Asimov `^-^-_>
about some of the ideas being kicked around internally by the team,
and to have a sense of where things may be headed, even if you are not
free to discuss everything.
Merry Christmas to you too,
Eric
Wojtek Porczyk
Dec 23, 2015, 9:04:58 PM12/23/15
to Eric Shelton, Eric Shelton, HW42, qubes-devel, Joanna Rutkowska, desk...@secure-os.org
> Thank you for taking the time to write this up. I appreciate hearing
> about some of the ideas being kicked around internally by the team,
> and to have a sense of where things may be headed, even if you are not
> free to discuss everything.
Sure. Thanks for understanding. The least I can do it to admit I can't
> about some of the ideas being kicked around internally by the team,
> and to have a sense of where things may be headed, even if you are not
> free to discuss everything.
say something and not wrap it in some PR-speak.
--
regards, _.-._
Manuel Amador (Rudd-O)
Dec 24, 2015, 4:19:33 PM12/24/15
to qubes...@googlegroups.com
On 12/22/2015 03:26 PM, Joanna Rutkowska wrote:
> Hi,
>
> I've recently had a chance to discuss with Marek and Wojtek, who
> recently took
> part in the Reproducible Builds Summit in Athens [1], the current
> state of the
> these efforts. TL;DR, the ETA for having Debian build
> deterministically is ~1.5
> year, which I take to mean it won't happen before 2018. Then, at least
> 0.5 year
> to get Qubes (i.e. the ISO) to build deterministically, which means we
> won't
> have it before the end of 2018, optimistically counting ;)
Frankly, you will have substantially better luck just moving Dom0 to NixOS.
> Hi,
>
> I've recently had a chance to discuss with Marek and Wojtek, who
> recently took
> part in the Reproducible Builds Summit in Athens [1], the current
> state of the
> these efforts. TL;DR, the ETA for having Debian build
> deterministically is ~1.5
> year, which I take to mean it won't happen before 2018. Then, at least
> 0.5 year
> to get Qubes (i.e. the ISO) to build deterministically, which means we
> won't
> have it before the end of 2018, optimistically counting ;)
Port your Dom0 build scripts to Nix expressions. Run them within NixOS
by simply realizing the expressions.
Then you should have a solid start towards reproducibility and
determinism, as they have done 95% of the work that would be necessary
to solve the issue.
A further benefit is that pinning the TCB to a specific set of packages
is much easier with NixOS, and so is moving the TCB forward to the next
release of NixOS while keeping your Nix expressions the same.
An even further benefit is that the installed image might or might not
contain everything necessary to build an entirely new Dom0 100%
deterministically -- that's an architectural decision -- but /that
doesn't mean all such software would mapped into the user-space that the
operator has access to./
The final benefit is that anyone will be able to build their own Qubes
updates very easily, as well as recheck that the "packages" they have
downloaded build exactly the same locally, with no special build server
setup work on the part of the user.
Of course, one thing that would be necessary to do, is a small shim that
would delegate builds to a domU running Nix Hydra, which (when done)
would serve the realized derivation (the "package") back to the caller.
This way builds do not actually happen in Dom0.
--
Rudd-O
http://rudd-o.com/
sajolida
Dec 24, 2015, 5:56:48 PM12/24/15
to Holger Levsen, desk...@secure-os.org, qubes...@googlegroups.com
Holger Levsen:
APT repo that should be ready in April. The idea is to be able to import
and freeze the precise list of packages that were used to build a given
ISO image. For technical details, get in touch with intrigeri.
> And to get back to a.) in case you dont want to rebuild all of fedora /
> debian: then you "just" need a stable package binary repository, so that when
> you rebuild an iso after a month (or more time) updates (which were not
> available at the original creation date) are not included in image. Debian has
> snapsho.debian.org which archives every binary package ever released by
> Debian, I don't know hat Fedora has to offer here.
Just pointing to related efforts, we're working at Tails on a freezable
> debian: then you "just" need a stable package binary repository, so that when
> you rebuild an iso after a month (or more time) updates (which were not
> available at the original creation date) are not included in image. Debian has
> snapsho.debian.org which archives every binary package ever released by
> Debian, I don't know hat Fedora has to offer here.
APT repo that should be ready in April. The idea is to be able to import
and freeze the precise list of packages that were used to build a given
ISO image. For technical details, get in touch with intrigeri.
Manuel Amador (Rudd-O)
Dec 25, 2015, 12:01:23 AM12/25/15
to qubes...@googlegroups.com
On 12/23/2015 10:39 PM, Wojtek Porczyk wrote:
> About transition, there is no decision. I can only say we are quite
> annoyed with Fedora lately because of several reasons, so we consider
> our options. Our current state of internal, face to face discussion
> boils to those points:
PLEASE, please consider NixOS harder. They have solved the problem, and
> About transition, there is no decision. I can only say we are quite
> annoyed with Fedora lately because of several reasons, so we consider
> our options. Our current state of internal, face to face discussion
> boils to those points:
there are a substantial number of benefits to going with it.
I'm happy to answer questions.
--
Rudd-O
http://rudd-o.com/
HW42
Dec 25, 2015, 6:03:49 AM12/25/15
to Manuel Amador (Rudd-O), qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Manuel Amador (Rudd-O):
Hash: SHA512
builds (in the sense of bit-for-bit reproducible) (see [0]).
I don't think NixOS makes reproducible build much easier. They have the
same problem with timestamps, etc. as any distro. And AFAIK the only
distro which has done much effort to get rid of such stuff is Debian (I
definitively don't wan't do say that other distros have done nothing).
You also need to consider other things when choosing an OS. For example
the last time when I checked NixOS (for another problem, and ca. 1.5
years ago so might be no longer correct) it had problems with timely
security updates.
The only point where I think NixOS (and Guix [1] even more) has
significant advantages in regards to reproducible builds is automatic
complete boostraping of the whole distro.
[0]: https://nixos.org/wiki/GSOC_2015_ideas_list#Deterministic_Builds
[1]: https://www.gnu.org/software/guix/
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWfSJ6AAoJEOSsySeKZGgW3ycQAIUMXrJn73xu7lJfXvAWvWD8
lb2xvhwXM3UF6YZpXMIVzwKBAbNqkmn1btBhr9SVsIxcFYq9RixxlW6kFNznazxx
NAABh6QBKY7xTQn8CYNTdU7/lcvFOi8yCdGerflVbo4rsp+Rv6FJ12l1i7ZupZZo
u2yKzz8ZXNbG8z30JQvWL8oJ2xR0xOYuxyRMgCmsxizHPFuFmi7l77xmT1AS39HB
+KwSYx0BTHYOKGua9Smf7s1n/rYDIdVnHYbswiVTiW5iETp2R/ZhIv18sv+JqRIu
CHsOpcT/jwRaS+add9vvB3FXatWV1vUwaz8cORgqhBcvD6Caz7NiiNo9AULnz6H8
xmPRrXAF4P1VUUqg/gnRtUen4dvQH3nr66TTzj2rEq/5A7YvykoE/Hc8A732FqWx
o06UlQ8k+EE18brrJPKFVYbcz3fGIUmxT2ada/Dzb8WSLGgvVpEvmjs+LnPQp1nB
aMb3so5Hxg9QgIQMJQbU9gj/n/BYFFWKVuJANQ4olFA1jLQ4LvgpGfCWvaBbBmHB
kDzHsGmDye0lEg3WdPlBloiztslWvY8B/Ho4tUO0vbpNpl+Jj2NIZkghHXoO3mo0
chYfas/YgFIoRzMgmiqwIf8o5ayAN4HD1XMTmzfW41KhDUuwIImPC90whm4Qzkkc
67KkSc1gNXi4M+45i4tA
=1xoI
-----END PGP SIGNATURE-----
Patrick Schleizer
Dec 25, 2015, 9:25:58 AM12/25/15
to sajolida, Holger Levsen, desk...@secure-os.org, qubes...@googlegroups.com
sajolida:
Interesting! Thank you, sajolida!
For Whonix, building from frozen sources has also been implemented. If
there are questions, please feel free to add me to the discussion.
Cheers,
Patrick
For Whonix, building from frozen sources has also been implemented. If
there are questions, please feel free to add me to the discussion.
Cheers,
Patrick
Manuel Amador (Rudd-O)
Dec 27, 2015, 4:57:03 AM12/27/15
to qubes...@googlegroups.com
On 12/25/2015 11:03 AM, HW42 wrote:
>
>
> I don't think NixOS makes reproducible build much easier. They have the
> same problem with timestamps, etc. as any distro.
They actually do not. Their build and package tools explicitly tackle
>
>
> I don't think NixOS makes reproducible build much easier. They have the
> same problem with timestamps, etc. as any distro.
this problem.
>
> You also need to consider other things when choosing an OS. For example
> the last time when I checked NixOS (for another problem, and ca. 1.5
> years ago so might be no longer correct) it had problems with timely
> security updates.
I'm using the latest NixOS. They seem to have updated fine. I'd like
> You also need to consider other things when choosing an OS. For example
> the last time when I checked NixOS (for another problem, and ca. 1.5
> years ago so might be no longer correct) it had problems with timely
> security updates.
to see more evidence of this particular point, though.
>
> The only point where I think NixOS (and Guix [1] even more) has
> significant advantages in regards to reproducible builds is automatic
> complete boostraping of the whole distro.
--
Rudd-O
http://rudd-o.com/
HW42
Dec 27, 2015, 5:54:40 PM12/27/15
to Manuel Amador (Rudd-O), qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Manuel Amador (Rudd-O):
Hash: SHA512
Manuel Amador (Rudd-O):
> On 12/25/2015 11:03 AM, HW42 wrote:
>>
>>
>> I don't think NixOS makes reproducible build much easier. They have the
>> same problem with timestamps, etc. as any distro.
>
> They actually do not. Their build and package tools explicitly tackle
> this problem.
They also have the problem with timestamps etc. On the one hand one of
>>
>>
>> I don't think NixOS makes reproducible build much easier. They have the
>> same problem with timestamps, etc. as any distro.
>
> They actually do not. Their build and package tools explicitly tackle
> this problem.
the NixOS developers said so in a personal conversation. You can also
convince your self. For example download the last build [0] of
erlang-18.0 and grep the package:
bzcat c0dyawpsa80ja2w91fcjkz075whw0rmx-erlang-18.0 | strings | grep -a '^%% script generated'
You see that the build time is included.
[0]: https://hydra.nixos.org/job/nixos/release-15.09/nixpkgs.erlang.x86_64-linux
>>
>> You also need to consider other things when choosing an OS. For example
>> the last time when I checked NixOS (for another problem, and ca. 1.5
>> years ago so might be no longer correct) it had problems with timely
>> security updates.
>
> I'm using the latest NixOS. They seem to have updated fine. I'd like
> to see more evidence of this particular point, though.
>
>>
>> The only point where I think NixOS (and Guix [1] even more) has
>> significant advantages in regards to reproducible builds is automatic
>> complete boostraping of the whole distro.
>
> This is a huge time saver.
iQIcBAEBCgAGBQJWgGwOAAoJEOSsySeKZGgW6+gP/2KHSQgEikLVmXuWmFdY98w9
cMOlyaNpGY2qVT0g2frm2x3umzxxU47rmtM7a7WlBIa8fQa0DqE3575/Pzl8A3+Y
T7mJPoYsNrahQ10HQbu8V5HnN1obrnQ7YEJxr8ex+hPxJ7vI4UD0yTDnX28BReb/
pYS1Ay7qYSEURbKHCkIY6Mh7kvK/i992MuQ1eKEUclQm0Cmd3vcsizIxx+Bw/zt4
WANWcHqq92BbYr2dk6B2V4tW8U2t8CWlKsOOjHxhtlO1zhZ/eoIWsov8FyK8upuH
DwCEu6bN67FPH/BkZyDpGCFR+iE3FwjXbwhOir/Ho/DYqFOyF8VB1FQy1fevZYkf
xh7ZEZiGS0oc5j6MgnYd8UjDcHJDrOnz3DPpw+uObZFf1Znv2aTMc7EN9eh59LGp
vKqrHYFDH5aP8Pucu8cYeGVgOn9WzvOKrmh5b0tJO6Xjk8lRAJQSCZ86wyxc47l9
wEnhQcXU0Bebul12qEIq2JxptqAoN+Mn1NtcOS1ojCemsNGkueZTOVQN2gARkd+b
DJn1QZehLBHafn9wjvhvg9/LaHNMN2jam8xdPLjjpGS2RboT+RVZl1TimTkJCIEJ
HPrJJJtotlzTkKVFEcBYgeTaiRMN0+S2/KMfw7ELj6UqKu/RtfiruefN5PJLgsNy
lIoZkMV4jobhYviEFTw0
=yvdf
-----END PGP SIGNATURE-----
Manuel Amador (Rudd-O)
Dec 27, 2015, 10:53:26 PM12/27/15
to qubes...@googlegroups.com
On 12/27/2015 10:54 PM, HW42 wrote:
> They also have the problem with timestamps etc. On the one hand one of
> the NixOS developers said so in a personal conversation. You can also
> convince your self. For example download the last build [0] of
> erlang-18.0 and grep the package:
>
> bzcat c0dyawpsa80ja2w91fcjkz075whw0rmx-erlang-18.0 | strings | grep -a '^%% script generated'
>
> You see that the build time is included.
>
> [0]: https://hydra.nixos.org/job/nixos/release-15.09/nixpkgs.erlang.x86_64-linux
Yes, I should have been more specific about what I meant.
> They also have the problem with timestamps etc. On the one hand one of
> the NixOS developers said so in a personal conversation. You can also
> convince your self. For example download the last build [0] of
> erlang-18.0 and grep the package:
>
> bzcat c0dyawpsa80ja2w91fcjkz075whw0rmx-erlang-18.0 | strings | grep -a '^%% script generated'
>
> You see that the build time is included.
>
> [0]: https://hydra.nixos.org/job/nixos/release-15.09/nixpkgs.erlang.x86_64-linux
Like everyone else, the Nix folks have a problem with timestamps.
Unlike everyone else, though, they are pretty far along in doing the
engineering work necessary to solve these issues. Maybe perhaps not as
far along as Debian (interestingly enough, Debian's work ought to be
reusable), but certainly quite far along and certainly more so than the
Fedora folks.
--
Rudd-O
http://rudd-o.com/
Joe
Jan 2, 2016, 3:04:52 PM1/2/16
to qubes...@googlegroups.com
First, to make sure there is no confusion:
"Deterministic builds" are called "Reproducible builds" in the Debian world.
They have a "Reproducible builds" project with more information:
[1] https://reproducible.debian.net/reproducible.html
On 12/22/2015 04:26 PM, Joanna Rutkowska wrote:
> Rather than trying to make *everything* build deterministically from scratch
> (which is what current efforts try to do, AFAIU) why not prepare an environment
> (as in: a VM image running under Qubes) that would be optimized for ensuring
> that whatever we build using qubes-builder (yes, let's focus on Qubes, for now,
> ok?) it always produces the same binaries?
>
> Admittedly the image itself would not build deterministically, true, but we
> would publish it (i.e. the binary) for everybody to download and inspect.
> Assuming people find it acceptable to trust this image (after spending many
> nights analysing it with a disassembler, of course ;) then all future builds,
> including future ISOs, images, and packages, should build deterministically. I
> think this would be a big win for everybody, especially that I think we might
> get this working within single weeks...
I would rather spend many nights sequentially analyzing individual
binary debian packages that do not compile deterministically - than a
huge binary blob.
Well, TBH: Let's be realistic: No one is going to want to actually put
in this intensive, and mostly useless, effort that will have to be
reenacted every time the base image changes.
You will even end up spending time on reversing things that already
build deterministically in Debian since those will be part of the image.
Whatever build environment you are going to ship will NOT be thoroughly
audited by people who intend to publish their findings.
IMHO shifting the problem by adding a layer does not provide any obvious
security benefits:
If my non-reproducible-and-backdoored build environment produces the
same tainted image as all the other backdoored build environments, I am
going to end up with having a completely deterministically built, but
backdoored, Qubes installer image.
^-- This is really my central argument against your proposal. If I
missed the point, please do elaborate on what is to be gained.
> So, how such an environment should look like? I think (perhaps naively) that the
> following adjustments should be just enough:
> 1. [cut]
> 2. [cut]
> 3. [cut]
>
A more complete list of potential issues is available in the
Reproducible Build project's guides to making projects build
deterministically (which highlights issues as well as solutions):
[2] https://reproducible-builds.org/docs/
Deterministic/reproducible builds are interesting because they can
decrease the size of the TCB that you have to trust (or reverse
engineer) in order to bootstrap a trusted system.
I'm not personally convinced that it's the most pressing security
problem at the moment, and I think there are things that are more
important to look at first (for the Qubes project), in no particular order:
- PulseAudio in dom0 taking input from netvm, firewallvm, * (wtf?)
- Screenlocking unstable and prone to libnotify popups bypassing it,
locking failing to fire, screen content being shown briefly when
returning after the display has powered off (there's a github ticket
about this also) - physlock seems to be the best solution
- Unencrypted swapping to main storage (volatile.img)
- Potential solution: loopmounting volatile.img with a different key
per VM boot similar to how Debian does encrypted swap
- See `man crypttab` -> swap
- See my proposal for a hack to do per-VM encrypted storage in
previous email
- See discussion about StorageVM
- Ticket system on Github full of things that are worth looking into
- Application of firewall rules being an unruly and unstable affair -
mostly because of Linux - hopefully Thomas' MirageOS implementation [3]
can help to solve this once it stabilizes.
[3] https://github.com/talex5/qubes-mirage-firewall
That being said, having [2] in mind while working on future Qubes build
systems would probably make way for an easier time in the future.
Joe
"Deterministic builds" are called "Reproducible builds" in the Debian world.
They have a "Reproducible builds" project with more information:
[1] https://reproducible.debian.net/reproducible.html
On 12/22/2015 04:26 PM, Joanna Rutkowska wrote:
> Rather than trying to make *everything* build deterministically from scratch
> (which is what current efforts try to do, AFAIU) why not prepare an environment
> (as in: a VM image running under Qubes) that would be optimized for ensuring
> that whatever we build using qubes-builder (yes, let's focus on Qubes, for now,
> ok?) it always produces the same binaries?
>
> Admittedly the image itself would not build deterministically, true, but we
> would publish it (i.e. the binary) for everybody to download and inspect.
> Assuming people find it acceptable to trust this image (after spending many
> nights analysing it with a disassembler, of course ;) then all future builds,
> including future ISOs, images, and packages, should build deterministically. I
> think this would be a big win for everybody, especially that I think we might
> get this working within single weeks...
binary debian packages that do not compile deterministically - than a
huge binary blob.
Well, TBH: Let's be realistic: No one is going to want to actually put
in this intensive, and mostly useless, effort that will have to be
reenacted every time the base image changes.
You will even end up spending time on reversing things that already
build deterministically in Debian since those will be part of the image.
Whatever build environment you are going to ship will NOT be thoroughly
audited by people who intend to publish their findings.
IMHO shifting the problem by adding a layer does not provide any obvious
security benefits:
If my non-reproducible-and-backdoored build environment produces the
same tainted image as all the other backdoored build environments, I am
going to end up with having a completely deterministically built, but
backdoored, Qubes installer image.
^-- This is really my central argument against your proposal. If I
missed the point, please do elaborate on what is to be gained.
> So, how such an environment should look like? I think (perhaps naively) that the
> following adjustments should be just enough:
> 2. [cut]
> 3. [cut]
>
A more complete list of potential issues is available in the
Reproducible Build project's guides to making projects build
deterministically (which highlights issues as well as solutions):
[2] https://reproducible-builds.org/docs/
Deterministic/reproducible builds are interesting because they can
decrease the size of the TCB that you have to trust (or reverse
engineer) in order to bootstrap a trusted system.
I'm not personally convinced that it's the most pressing security
problem at the moment, and I think there are things that are more
important to look at first (for the Qubes project), in no particular order:
- PulseAudio in dom0 taking input from netvm, firewallvm, * (wtf?)
- Screenlocking unstable and prone to libnotify popups bypassing it,
locking failing to fire, screen content being shown briefly when
returning after the display has powered off (there's a github ticket
about this also) - physlock seems to be the best solution
- Unencrypted swapping to main storage (volatile.img)
- Potential solution: loopmounting volatile.img with a different key
per VM boot similar to how Debian does encrypted swap
- See `man crypttab` -> swap
- See my proposal for a hack to do per-VM encrypted storage in
previous email
- See discussion about StorageVM
- Ticket system on Github full of things that are worth looking into
- Application of firewall rules being an unruly and unstable affair -
mostly because of Linux - hopefully Thomas' MirageOS implementation [3]
can help to solve this once it stabilizes.
[3] https://github.com/talex5/qubes-mirage-firewall
That being said, having [2] in mind while working on future Qubes build
systems would probably make way for an easier time in the future.
Joe
Reply all
Reply to author
Forward
0 new messages