R4.0-rc4 installation image considerations

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

I'm building what hopefully will be R4.0-rc4 and I have two
reflections:

1. After upgrading templates to fedora-26 and debian-9, there is no way
the installation image will fit on DVD. Right now it takes 4908384256
bytes. We probably could try to cut it down by eliminating even more
packages from templates, but I think there is no much non-essential
packages left there. For example we no longer ship vim in debian-9.
Right now I see two options:
- abandon the goal of fitting the image on DVD (I'd go for this)
- exclude some template from default installation...

2. grub suck at booting xen.efi (or rather: xen.efi is rather picky
about its environment). On many systems, booting xen.efi without grub
(using rEFInd, EFI shell, or simply by renaming it over BOOTX64.efi)
helps with boot problems. An idea: do not use grub on UEFI installation.
Downside: you loose boot menu - no way to choose or not media
verification, or rescue mode. And no way to adjust boot arguments,
needed on some platforms to workaround UEFI bugs... To do that, you'd
need to edit EFI/BOOT/xen.cfg using some other means.
Alternative: keep grub there, but provide an instruction how to boot
xen.efi directly, in short:

mount /dev/sdb1 /mnt # assuming /dev/sdb1 is installation USB
mv /mnt/EFI/BOOT/xen.efi /mnt/EFI/BOOT/BOOTX64.efi
mv /mnt/EFI/BOOT/xen.cfg /mnt/EFI/BOOT/BOOTX64.cfg
umount /mnt

After such operation, media verification would fail, obviously.

Any input on the above?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpiR+IACgkQ24/THMrX
1yyriwf+Mk7wGfrnOBOf0gjOv61zTUbo6Iq6sPx4Xt4jK7+PFElLTCr1GVI+xoEc
uBePakd0mh1fH6FiNe8KjJxo5txWjS6D1326b9YfQXDvVoyOC3P9vZ9QHXcCoI0o
LSjT1z23T4OKELQeeySwA4FyCw6IblumcFhigvWF2GiEelWQJoMfk2ncmCumC+pE
x9SJnrolTWon208z9KokpufhGG8Gap4SJIiUjmmFCHce0GfYsCE5lYnDS1I7DPyX
+7kvmtJJakIolZkdDGVvKVVFx5c2Rg8EJOoxzp5euPiOH2xgsOLueQHmy7e5TrqL
KvTPjE53WmpzDq/Xh6SV9dhXTRjI+g==
=DsvK
-----END PGP SIGNATURE-----

[Chris Laprise]

On 01/19/2018 02:32 PM, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> I'm building what hopefully will be R4.0-rc4 and I have two
> reflections:
>
> 1. After upgrading templates to fedora-26 and debian-9, there is no way
> the installation image will fit on DVD. Right now it takes 4908384256
> bytes. We probably could try to cut it down by eliminating even more
> packages from templates, but I think there is no much non-essential
> packages left there. For example we no longer ship vim in debian-9.
> Right now I see two options:
> - abandon the goal of fitting the image on DVD (I'd go for this)
> - exclude some template from default installation...

Since most earlier Qubes releases also did not fit on 4.7GB DVD, I
always assumed I'd need to use an 8.5GB DVD instead. This works fine.

>
> 2. grub suck at booting xen.efi (or rather: xen.efi is rather picky
> about its environment). On many systems, booting xen.efi without grub
> (using rEFInd, EFI shell, or simply by renaming it over BOOTX64.efi)
> helps with boot problems. An idea: do not use grub on UEFI installation.
> Downside: you loose boot menu - no way to choose or not media
> verification, or rescue mode. And no way to adjust boot arguments,
> needed on some platforms to workaround UEFI bugs... To do that, you'd
> need to edit EFI/BOOT/xen.cfg using some other means.
> Alternative: keep grub there, but provide an instruction how to boot
> xen.efi directly, in short:
>
> mount /dev/sdb1 /mnt # assuming /dev/sdb1 is installation USB
> mv /mnt/EFI/BOOT/xen.efi /mnt/EFI/BOOT/BOOTX64.efi
> mv /mnt/EFI/BOOT/xen.cfg /mnt/EFI/BOOT/BOOTX64.cfg
> umount /mnt
>
> After such operation, media verification would fail, obviously.

I'd agree with the alternative, because there is a trade-off between
grub's bugs and using grub to work around boot issues. Filing bug
reports (or adding to them) for the grub/xen.efi problems could help.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Andrew Clausen]

Hi all,

On 19 January 2018 at 19:32, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

1. After upgrading templates to fedora-26 and debian-9, there is no way
the installation image will fit on DVD. Right now it takes 4908384256
bytes. We probably could try to cut it down by eliminating even more
packages from templates, but I think there is no much non-essential
packages left there. For example we no longer ship vim in debian-9.
Right now I see two options:
 - abandon the goal of fitting the image on DVD (I'd go for this)
 - exclude some template from default installation...

I think it's absolutely critical from a security point of view to provide a DVD image.  DVDs have two important properties:

(a) They are read-only (once you close the "session"), and

(b) They don't have any microcontrollers in them, so the entire contents of them can be checked.

Consider the follow threat model.  An adversary owns a random subset of my computers (and my friends computers).  The adversary does not own the brand-new laptop I plan to install Qubes on.

In this situation, I can burn a Qubes installer DVD on one (infected) computer, and then check the hash on several machines.  As long as one machine is not owned (and is properly configured not to parse anything from the DVD), then I will be sure that the DVD is the right one.

If I used a USB stick instead, then any of the computers used to check the image could infect either the data stored on the USB, or the firmware of the microcontroller inside the USB stick.

Bottom line: please provide a minimal image that fits on a DVD.  It doesn't need Debian or Whonix, as these can be downloaded later.  The important thing is to provide a way to bootstrap safely.

Kind regards,

Andrew

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> Right now I see two options:
> - abandon the goal of fitting the image on DVD (I'd go for this)

*single-layer DVD. Still lots of space on dual-layer DVDs, so this
option seems totally fine to me.

FWIW, I sometimes write DVD images to a microSD card, set the
temporary write protection bit using sdtool*, and put it in a USB
adapter that exposes a Mass Storage Device (but not MMC) interface to
the host - which would then at least have to exploit the adapter's
controller to overwrite any data.

Rusty


* https://github.com/BertoldVdb/sdtool
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJaYlG0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfENcP+wTttj8plXbDDjhpcY+3q4l4
pXwPWZ7+iVjHgi56mwDAxibXYIkkEXbgkbd5Y7/E9xf1Zel4xV1FH76HN4gVqHJg
txDEB0SdURUNjOwNfc7jkc+0SQYAoNdLrBVN1t0QOMG0DA5SpQl49wmhP0CuKrtR
N/E6zEKdJPo0RB4LIHXBZAvTl607BV0frsAnY1RsFwuiKx8JNRRrWK/MWGzLt3WI
shQXKeEqz/FF/LIyDROjoElPUwUKWdyWVlKIysW5lmTJM1bgHrTGkYh0kO3rJsob
ecRjnTTO1nllqsxHAa3nkGk00LD7HtmqV7MTcU6yWNCksHvfSOFyHnjicRqXd5U0
ON188ZHvKIh9cN2zB03KROTMit8SOiuRVb8iZLfpylwBpsywz+jLaeGqY07icVsR
2XWw0qG3eWukmrPlav63lmDrIzrJYx4v2uIPGE31Ujdz0T4ADu4XvmZuv4ppF/Nc
98Dtx70NFFF4//bbQ7FJksvGqCj1bdWRF1WAHAQNDPEMtkAONLje2tXHosbgWDYR
S5q3SZ1NOEXx/2ofOFlJzslw36FfCEpmOcb2W3zIvTVUbN/xSjgc6huvZblHcqIR
2cA3wGDCls7iWHaC6nFymPDGw2Yu40bETHXiC2HPxtTJXb+iiZaS3yV1+PYsFAJi
5Vu2RhCx7K//fO8wrcA9
=WJYF
-----END PGP SIGNATURE-----

[Tom Zander]

On Friday, 19 January 2018 20:32:50 CET Marek Marczykowski-Górecki wrote:
> We probably could try to cut it down by eliminating even more
> packages from templates, but I think there is no much non-essential
> packages left there

are thunderbird and firefox still included?

Those are hardly essential... (and the first things I delete when I get a
template).

I removed quite a lot myself from any template I get;
https://github.com/zander/qubes-builder-archlinux/commit/
5de5e5b8c641c3dcc0211cdbc3fdab54823f2255
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

[Unman]

I would , of course, favour a Debian system as default.
However, it would be useful if you could give the relative template
sizes on the current build.

As far as trimming the templates, there is some scope for this, but one
of the problems is that people want what THEY like. Look at issue 1781 for
a great example of this.

Cant dom0 be trimmed further?

I am strongly in favour of an image that fits on a DVD - would there be
any reason not to offer Fedora and Debian as alternatives if the size
issue proves insuperable?

[Tom Zander]

On Saturday, 20 January 2018 00:11:02 CET Unman wrote:
> As far as trimming the templates, there is some scope for this, but one
> of the problems is that people want what THEY like. Look at issue 1781 for
> a great example of this.

A bit off-topic here, but relevant to the templates debate going into the
future;
in the commonly accepted idea of having a template-download-manager (i.e.
dropping RPM dependency) I'd be in favour of a system where a bare-bones
template is shipped by the qubes team and then a standardized application is
added on each of those templates to continue the install _inside_ of the
template using something like tasksel (but obviously something more mature
with a pretty GUI).
Doing things like setting the nearest download location (mirror) can be done
there too.

Bottom line, I'm a fan of bare-bones templates.
Because in practice, you always will end up downloading more from the
internet anyway.

[bow...@gmail.com]

I think fit in single layer DVD is important. I suspect some of the users do not have access to hardware that easily (i.e. dual layer DVD burner).
I second the fact that you have to be able to use a ReadOnly media, verify the hash/key on few different machine before installing.
I would provide default template that you support (fedora still?). It is not too hard to get another template and re-create sys-net and sys-firewall if you want another distro for these... (disposable + minimal for these would be better).
Window manager: it might be more important to keep all the one you support. I hope XFCE is still the default.


I can't comment on the boot side, out of my comfort zone... maybe you could have 2 downloads... people use the basic one and only download the other one if the have problems or if they want to multiboot... but it's more work for you...

Great work Marek and the team. as always.

[Simon Gaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> Hi all,
>
> I'm building what hopefully will be R4.0-rc4 and I have two
> reflections:
>
> 1. After upgrading templates to fedora-26 and debian-9, there is no way
> the installation image will fit on DVD. Right now it takes 4908384256
> bytes. We probably could try to cut it down by eliminating even more
> packages from templates, but I think there is no much non-essential
> packages left there. For example we no longer ship vim in debian-9.
> Right now I see two options:
> - abandon the goal of fitting the image on DVD (I'd go for this)
> - exclude some template from default installation...

OTOH in nearly all cases a user needs to install stuff from the net
anyway. So downloading an additional template doesn't really hurt. And
for example when restoring from a backup no additional templates are
needed at all.

> 2. grub suck at booting xen.efi (or rather: xen.efi is rather picky
> about its environment).

It seems in Xen 4.9 they added multiboot2 support and the commit
messages claims that this works with grub2 and EFI [1] (And according
to [2] that's the proper fix). But the commits don't look easy to
backport ...

> On many systems, booting xen.efi without grub
> (using rEFInd, EFI shell, or simply by renaming it over BOOTX64.efi)
> helps with boot problems. An idea: do not use grub on UEFI installation.
> Downside: you loose boot menu - no way to choose or not media
> verification, or rescue mode. And no way to adjust boot arguments,
> needed on some platforms to workaround UEFI bugs...

I think that's quite an important feature. So if this doesn't affect that
many systems I would keep grub.

> To do that, you'd need to edit EFI/BOOT/xen.cfg using some other
> means.
> Alternative: keep grub there, but provide an instruction how to boot
> xen.efi directly, in short:
>
> mount /dev/sdb1 /mnt # assuming /dev/sdb1 is installation USB
> mv /mnt/EFI/BOOT/xen.efi /mnt/EFI/BOOT/BOOTX64.efi
> mv /mnt/EFI/BOOT/xen.cfg /mnt/EFI/BOOT/BOOTX64.cfg
> umount /mnt
>
> After such operation, media verification would fail, obviously.

[1]: https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9180f53655245328f06c5051d3298376cb5771b1
[2]: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1520979/comments/4
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlpinroACgkQkO9xfO/x
ly+4PA/8DoAqpbXh9jc2sYbZkGlFOQwbsXQ/GVlw9E5aACcOJ+cNyga5fAcNmS4e
SHBxhFJzJ7CnJ7eo+TQ/oV/HXoIJjWeDB3ZZv8qRtV1T+AoFaV8a+sOdZ+x/TQbd
Jiu+fGHTHzUHDhhfdEBc0VZVqfSmuNdlXLdPgHjt/H8knY0lJmYjE684aIdj0yFL
ePtwh0Nq+SLz41vTsT1CqdS1SWRuQVYX/eZlzFiXCMRMOkDll9+pxNbDOA9k5ae+
mAt503dsgaFLHrjte++Mtgb0L0WAh7bFUzrTK3BwE8nw9Ok3A0/OCBKVdDouG8rc
r8kEx8hGYeZhCND6Fku8kAiEt6Rt/S0tMy6Mbx47nPHFDcpGFsoeypJgkeldqH2H
M3aUCnETsFuAWA2GdcxFDiKNmUiJMMtijwTpZ/IfzgWE0ZL/0Z6FNhDGHGWizaxL
kmekYnLRMCG19trV99b2e/9acnLgKtKf3D1rkoJe1WyqtzyPZVvLd1JGj9uZN+RP
QeapFfDfiSvq8YF4l+c3I2atkrGlxjVX6/K845PyWhO9u3mt9COqv+CkMeOn3pUl
BxStY1CwjifArXj/jaTRNyUZeCWPsUL9x7GlZl90W5ACl23AGIVY5hUaBu1gbjiD
Wb3nJnnbM1Xwr65o3b1uCdoiwgafHQTvvT4IWFPvCAxtVtQOrPI=
=Ma/8
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Jan 19, 2018 at 11:11:02PM +0000, Unman wrote:
> On Fri, Jan 19, 2018 at 08:32:50PM +0100, Marek Marczykowski-Górecki wrote:
> > Hi all,
> >
> > I'm building what hopefully will be R4.0-rc4 and I have two
> > reflections:
> >
> > 1. After upgrading templates to fedora-26 and debian-9, there is no way
> > the installation image will fit on DVD. Right now it takes 4908384256
> > bytes. We probably could try to cut it down by eliminating even more
> > packages from templates, but I think there is no much non-essential
> > packages left there. For example we no longer ship vim in debian-9.
> > Right now I see two options:
> > - abandon the goal of fitting the image on DVD (I'd go for this)
> > - exclude some template from default installation...
>

> I would , of course, favour a Debian system as default.

But until we migrate dom0 to something else, we need to ship fedora
template too, because it works better for downloading dom0 updates (the
same tool resolve dependencies, yum version in Debian is much older, and
there is no dnf at all).

> However, it would be useful if you could give the relative template
> sizes on the current build.

Sure[1][2]:

fedora-26: 1643586746 bytes
debian-9: 722214642 bytes
whonix-gw: 504932958 bytes
whonix-ws: 705727858 bytes

fedora-26, as default template for AppVMs, contains default user
applications, like Firefox, Thunderbird. Shipping a _desktop_ operating
system without web browser isn't going to work...

But maybe there is a chance to trim Fedora template slightly...
Frédéric, do you see something that could easily be done there?

> As far as trimming the templates, there is some scope for this, but one
> of the problems is that people want what THEY like. Look at issue 1781 for
> a great example of this.
>
> Cant dom0 be trimmed further?

That's a good question. List of packages, sorted by size is here:
https://gist.github.com/marmarek/cb9fa3d82e3aba6cd15c78854b184f10

For example I see two fonts packages (adobe-source-han-*) using together
over 70MB.

> I am strongly in favour of an image that fits on a DVD - would there be
> any reason not to offer Fedora and Debian as alternatives if the size
> issue proves insuperable?

Providing two images means some more work, more testing etc, so I'd like
to avoid that. But if there will no better option, that could be done.

[1] https://yum.qubes-os.org/r4.0/templates-itl/rpm/
[2] https://yum.qubes-os.org/r4.0/templates-community/rpm/

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpipD0ACgkQ24/THMrX
1yxY8Af/aiT/HgU6q20GocElHqwIjn0k2Wh7ZCADiZqPMtgViWvKRTggzMPtCBLV
ltnngAcLZExR866eyo8UIYU31yw5XWQM6SL0J0K9wZKkFcYnUqmvev7Owf6WibGy
a8N5Sn4cuQpqqyvDLhX4AMb+S+ITx/wSZmcL0rt/Oh2zCTQUdaM8q4ONjZEjtxvH
2GnuRL70qBSaJs6v6i6w1rYVJiDzqDC3l176eYh/xCbM/jlfqXwsn6tgdK+Iyi5R
hwtXdAN9e0h5ZQ56pWMBDORuXT2rDLQavJZnpmKKdglBF/E9XmyLvYR48FuLWbB3
3SW11qgol6Y7KmbRpYU0pDwhOYOOnA==
=0YUP
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jan 20, 2018 at 01:43:00AM +0000, Simon Gaiser wrote:
> Marek Marczykowski-Górecki:
> > Hi all,
> >
> > I'm building what hopefully will be R4.0-rc4 and I have two
> > reflections:
> >
> > 1. After upgrading templates to fedora-26 and debian-9, there is no way
> > the installation image will fit on DVD. Right now it takes 4908384256
> > bytes. We probably could try to cut it down by eliminating even more
> > packages from templates, but I think there is no much non-essential
> > packages left there. For example we no longer ship vim in debian-9.
> > Right now I see two options:
> > - abandon the goal of fitting the image on DVD (I'd go for this)
> > - exclude some template from default installation...
>
> OTOH in nearly all cases a user needs to install stuff from the net
> anyway. So downloading an additional template doesn't really hurt. And
> for example when restoring from a backup no additional templates are
> needed at all.

Yes, but downloading 30MB, or even 100MB of packages is different than
over half of GB.

Slightly unrelated thoughts about what should be on default
installation:

1. It is important to keep "basic stuff for average user"
installed by default. So new users, not yet fully understanding how
templates works, do not need to learn this as the first thing.

2. IMO we should have Debian easily accessible, because a lot of people
say "I prefer Debian instead of Fedora, so Qubes is not for me". Finding
what other templates are available and how to install them is not so
easy when you see Qubes for the first time... Which is another problem,
but we won't solve it in time for 4.0-rc4.

> > 2. grub suck at booting xen.efi (or rather: xen.efi is rather picky
> > about its environment).
>
> It seems in Xen 4.9 they added multiboot2 support and the commit
> messages claims that this works with grub2 and EFI [1] (And according
> to [2] that's the proper fix). But the commits don't look easy to
> backport ...

Ok, so this looks optimistic, for Qubes 4.1.
OTOH, XenServer have those patches backported for a long time:
https://github.com/xenserver/xen-4.6.pg/blob/master/master/series#L161-L175

This isn't something that I'd like to do this late...

> > On many systems, booting xen.efi without grub
> > (using rEFInd, EFI shell, or simply by renaming it over BOOTX64.efi)
> > helps with boot problems. An idea: do not use grub on UEFI installation.
> > Downside: you loose boot menu - no way to choose or not media
> > verification, or rescue mode. And no way to adjust boot arguments,
> > needed on some platforms to workaround UEFI bugs...
>
> I think that's quite an important feature. So if this doesn't affect that
> many systems I would keep grub.
>
> > To do that, you'd need to edit EFI/BOOT/xen.cfg using some other
> > means.
> > Alternative: keep grub there, but provide an instruction how to boot
> > xen.efi directly, in short:
> >
> > mount /dev/sdb1 /mnt # assuming /dev/sdb1 is installation USB
> > mv /mnt/EFI/BOOT/xen.efi /mnt/EFI/BOOT/BOOTX64.efi
> > mv /mnt/EFI/BOOT/xen.cfg /mnt/EFI/BOOT/BOOTX64.cfg
> > umount /mnt
> >
> > After such operation, media verification would fail, obviously.
>
> [1]: https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9180f53655245328f06c5051d3298376cb5771b1
> [2]: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1520979/comments/4

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpiqj8ACgkQ24/THMrX
1yw4ywf+JEId4kgGDk4UP5IQCJugOsPTwir/jvrn2uaskDno394ahlaANmNHPTly
pN6VZGkA3SVG5jgyIYW+Y9oDwlNLJMKtDfDk0At+HlapgxYt75tZ8wbh42eM/RkR
ATVCFVYYNLU+NvlbToKNBVifDAi3vhrG8VIwK29gTYOQ9gZ9vUGFYcj4BOhSyup4
ASMNXKlhT5pseZO/VjCZX/tWRujRR8Ao9UrbLh4DmwUhpc2rr9ghIPDcXo9zuZXy
Y3D4sZKUrQryHQLMQiNmqln6zvcEuaQPK2G6mrv2B998t47kslscvmJbc4gDr07R
/JS0tIj3gAo8V5LZkQ5bzBAAZMj/MQ==
=NOZu
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

+1

I've long wondered why we bother shipping templates in the same image
anyway, since in reality the first thing a user should do after e.g.
downloading and installing R3.2 is download new templates and remove
the EOL fedora-24 ones. Hence, many gb of the 3.2 release iso seem to
be rather useless, and bringing up a new system needs several
additional gb of downloading after installation right now anyway.

If release ISOs were put out more frequently then it'd be a different
story, but right now (and for most of the lifetime of any given latest
Qubes release) the templates that you download with the latest stable
Qubes release ISOs are in a sense just a waste of bandwidth (and a
waste for everyone, not just those who wish to use only fedora or
debian).

IMHO a minimal base release ISO with only dom0 and a minimal template
to bootstrap whichever (currently supported!) templates you wish to
use seems like a better system install model. Additionally, separate
ISOs with the latest templates could be released separately (and more
frequently) which could also be burned to immutable media, and this
would allow one to bootstrap a non-EOL Qubes system without internet
access (something not currently possible).

Implementing what I've just described (and solving #2063 in the
process) has long been on my personal Qubes to-do list, but alas...
free time is scarce these days. My sincere thanks to all those
actually implementing things and solving problems while I sit here
ranting on the mailing list instead of sending patches ;)

Regards,
Jean-Philippe

[1]: https://github.com/QubesOS/qubes-issues/issues/2063

[Jean-Philippe Ouellet]

And FWIW, I don't know how brand new users can be reasonably expected
to know that they even *should* do this. IMHO it's not a good first
impression.

[Jean-Philippe Ouellet]

On Sat, Jan 20, 2018 at 12:56 AM, Jean-Philippe Ouellet <j...@vt.edu> wrote:

Oh yeah, and I almost forgot... one of my main reasons for wanting to
do the above was to ease the road towards incrementally achieving
reproducibility!

If the Qubes install iso is just dom0 + a minimal template for
bootstrapping the other templates you will actually use, then it
removes the requirement for all the templates we ship always being
themselves fully reproducible in order for the base release iso to be
reproducible, which is a quite meaningful first step.

Debian & derivatives seem to be leading the way on this, so a
reproducible debian template might be reasonably accomplishable in the
not-terribly-distant future, but who knows how long it'll be until all
of fedora will be reproducible. Splitting the templates out would
allow stronger guarantees about the base system for those who care,
and let us make real progress towards this without upstream OS vendors
holding us back.

Even if upstream OS vendors do make reproducibility possible, it will
likely not be with the same amount of supported build system
variation. The less we depend on them for release ISOs, the more
diversity of build machines we can use to cross-verify the base
system.

Regards,
Jean-Philippe

[Frédéric Pierret (fepitre)]

Sure, I will review today the packages and groups list to see if I can reduce the template size.

[Ivan Mitev]

On 01/19/18 21:32, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> I'm building what hopefully will be R4.0-rc4 and I have two
> reflections:
>
> 1. After upgrading templates to fedora-26 and debian-9, there is no way
> the installation image will fit on DVD. Right now it takes 4908384256
> bytes. We probably could try to cut it down by eliminating even more
> packages from templates, but I think there is no much non-essential
> packages left there. For example we no longer ship vim in debian-9.
> Right now I see two options:
> - abandon the goal of fitting the image on DVD (I'd go for this)

+1

Other people in the thread disagree and still use regular DVDs - which
as a readonly media is great for security - but how may people from
Qubes' user base still have and use an optical reader ? I haven't seen
any recent laptop (like in the past 3-4 years) with a CD/DVD reader and
nowadays desktop workstations usually don't include one either.

If I wanted to use a DVD I'd probably have to buy a usb optical
reader/writer, which kind of defeats the purpose of the readonly media.
And if I was to buy such reader anyway I wouldn't mind using dual layer
DVDs.

IMHO, trying to trim as much space as possible from the templates takes
time that could be better spent and it's only delaying your decision: at
some point it won't be feasible to fit everything in a DVD - except if
the "new way" as suggested elsewhere in the thread is to include a
minimal template in the default install whose only purpose is to allow
users to download templates of their choice.

[Chris Laprise]

Yes, I think Qubes needs the basic stuff on install. Its a PC-laptop
system. And you're right about very large downloads, this can be a real
burden for some depending on their network situation.

>
> 2. IMO we should have Debian easily accessible, because a lot of people
> say "I prefer Debian instead of Fedora, so Qubes is not for me". Finding
> what other templates are available and how to install them is not so
> easy when you see Qubes for the first time... Which is another problem,
> but we won't solve it in time for 4.0-rc4.

The configuration changes I'd make are:

* Include fedora-26-minimal for 'dnf' support

* Configure a desktop-oriented debian-9 template and include this

* (Also rename the current debian template as debian-9-minimal, but
don't include it)

OTOH, stating that a dual-layer DVD is required is much simpler, and DL
burners are pretty common.

[Andrew Clausen]

Hi all,

On 20 January 2018 at 09:28, Ivan Mitev <iv...@maa.bz> wrote:

+1

Other people in the thread disagree and still use regular DVDs - which as a readonly media is great for security - but how may people from Qubes' user base still have and use an optical reader ? I haven't seen any recent laptop (like in the past 3-4 years) with a CD/DVD reader and nowadays desktop workstations usually don't include one either.

I buy a fresh USB DVD device with every secure laptop I buy.  I don't reuse them, because I don't want a mistake made with one of them to contaminate another laptop.  So I've got lots of them lying around the house!

At some point DVDs + DVD equipment might become impossible to buy (or with only very few suppliers, all of whom could be interdicted).  I'm not sure what I will do then!

Kind regards,

Andrew

[Tom Zander]

On Saturday, 20 January 2018 03:06:53 CET Marek Marczykowski-Górecki wrote:
> fedora-26, as default template for AppVMs, contains default user
> applications, like Firefox, Thunderbird. Shipping a _desktop_ operating
> system without web browser isn't going to work...

I understand the argument, and I see you make a lot of sense.

On the other hand there are a lot of little practical issues with this.
For instance; firefox has a 2-monthly releas cycle
https://wiki.mozilla.org/RapidRelease/Calendar
which makes any release from Qubes (on DVD) outdated really fast.

I would guess people would suggest new qubes users would need to always keep
up-to-date, by downloading the latest from the internet.

So in reality you end up shipping a firefox and various other large packages
which will be deleted hours after being installed because they are outdated
and possibly a security risk.

For 4.1 it would be nice to have a better process in place, like I described
earlier in this thread. So we can avoid shipping something on valuable DVD
space that the user will never actually use.

[Frédéric Pierret (fepitre)]

Le samedi 20 janvier 2018 03:07:32 UTC+1, Marek Marczykowski-Górecki a écrit :

I opened a PR (https://github.com/QubesOS/qubes-builder-fedora/pull/17). Now the template is ~990mo.

[awokd]

On Sat, January 20, 2018 11:54 am, Andrew Clausen wrote:
>
> I buy a fresh USB DVD device with every secure laptop I buy. I don't
> reuse them, because I don't want a mistake made with one of them to
> contaminate another laptop. So I've got lots of them lying around the
> house!

Please also keep Tor users in mind, so that even the most minimal Qubes
ISO can self-update over Tor "out of the box".

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/19/2018 09:11 PM, Andrew Clausen wrote:
> Hi all,
>
> On 19 January 2018 at 19:32, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com

> <mailto:marm...@invisiblethingslab.com>> wrote:
>
> 1. After upgrading templates to fedora-26 and debian-9, there is
> no way the installation image will fit on DVD. Right now it takes
> 4908384256 bytes. We probably could try to cut it down by
> eliminating even more packages from templates, but I think there
> is no much non-essential packages left there. For example we no
> longer ship vim in debian-9. Right now I see two options: - abandon
> the goal of fitting the image on DVD (I'd go for this) - exclude
> some template from default installation...

> Bottom line: please provide a minimal image that fits on a DVD. It
> doesn't need Debian or Whonix, as these can be downloaded later.
> The important thing is to provide a way to bootstrap safely.

I would suggest the same.
A "small" minimal installer should be fit on a single DVD.

Then, an extra "all inclusive" image can be used with a pendrive. - if
that is really needed at all.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlpjeQMACgkQGjNaC1SP
N2R5tg//YVcBWlux/GNpxHdT/dRz9SobLAnTLCpz9H5S/Ssen0bO3Xia77/9G6qG
Kt3/GyZFW73xViD0pBS88zn6R/VhDhGSA0lU9EZjcTM9PVV4ScqwfTVA44WbqSaV
YRld+d8NspbhKBwqzmz+FycfLF3YZ2sT5B1cLx7YiGQ8XNpUtRA6RdOH0nrN4vVT
97i9XTZaXDKp/151WZLYWsrBRJhPtQvrBGtapWOh71ZHHJYKNlUUXRia1NtUPKND
FKlAKd7HrGDJcM05lmyBYUlSlQq0SAy/4t8Df7OaIsPk7gO88aO5eFkfDr8/nkr8
3bWjMR8bGJpn3omAyUlkBHgKPmh6W3mo/+vQT0DtIx14cuteLf69A4Dy6x458WoO
ZifOSF6yDfZL18KvDQtC2BeHxRh5DepXEAHbXZLMG0fah0qZIedf4Ua45Xq7kZgM
Jat1Vav3mzjOklEPi8sEeyxUCgap7k5FnSLCmj3gpJ2Ah2I4h2pJ9BXFwOvt0cW+
bAWlMZXFJsYSYexwDCWjD+rgW4gVBVDm2SgVPK12r/IJ3zWSGwDrGJwJe7n2SsqW
vtp5YBTwABO4whRFS6MjLcl3mekecvlc0exHpsIZLZm5grr0jW5oH3FffyQ+OlHo
joki/OcFlWV8d/feGrkGCGeH8KDYlW/x3iMd7iY8ffeA9eVEs7U=
=QaDI
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jan 20, 2018 at 03:00:08PM +0100, Tom Zander wrote:
> On Saturday, 20 January 2018 03:06:53 CET Marek Marczykowski-Górecki wrote:
> > fedora-26, as default template for AppVMs, contains default user
> > applications, like Firefox, Thunderbird. Shipping a _desktop_ operating
> > system without web browser isn't going to work...
>
> I understand the argument, and I see you make a lot of sense.
>
> On the other hand there are a lot of little practical issues with this.
> For instance; firefox has a 2-monthly releas cycle
> https://wiki.mozilla.org/RapidRelease/Calendar
> which makes any release from Qubes (on DVD) outdated really fast.
>
> I would guess people would suggest new qubes users would need to always keep
> up-to-date, by downloading the latest from the internet.
>
> So in reality you end up shipping a firefox and various other large packages
> which will be deleted hours after being installed because they are outdated
> and possibly a security risk.

Actually, Fedora support differential updates (*.drpm, being a binary
diff of packages). So it isn't that much waste of space...

Also, launching an update (simple action, available from GUI) is
easier than finding what packages you need to install and where.

> For 4.1 it would be nice to have a better process in place, like I described
> earlier in this thread. So we can avoid shipping something on valuable DVD
> space that the user will never actually use.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpjgN0ACgkQ24/THMrX
1yx9Jgf/fAEHr9q47cM671y0921mm0msfeVAXeRm+8VfMEeRNWxDT8+pMplJ11Io
jpHvnq4UChdJwOKvOb2m9xrsDXXVXfImDACuXRETmezlG892xqF1Qv51zW2XwcVO
FAByR5CbKg4RNU51t8EknrIm+rA3laadDZ8/UkxRw6f/e3oDErI/7lHqPo5jv4sD
Ub5z4d7wlFPHOguVDEhv/ySyiodq5CNSpX6tC9037BIqiYdJk4V46Y8FfYjS1HqN
frwQqpUrGlZVEgOhZ66KA9uVrQYzr/dzidIvJRjR3FdEyyClPyPNwwNj44YBpumX
OHJ9n0/WlKBrqMe1w1288pgNtHlh0A==
=LYcV
-----END PGP SIGNATURE-----

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/20/2018 03:06 AM, Marek Marczykowski-Górecki wrote:
> fedora-26, as default template for AppVMs, contains default user
> applications, like Firefox, Thunderbird. Shipping a _desktop_
> operating system without web browser isn't going to work...

Agree.

But those users do not need any other templates than the default one
for sure.

And for the "advanced" users: isn't that bad if ALL the stuff included
is highly outdated, and possible full of already published bugs?

How would you rate the current R3.2 fresh install?
(ALL the included applications are out of date, and the fedora
templates are already end of life for sure. So most of the ISO
contents are actually useless.)

While a minimal Qubes ISO would be much smaller, fit on a read only
media, and probably would contains much less outdated/buggy/vulnerable
stuff.

Installing a new template is pretty easy and well documented.

However it is still not stressed enough that even that process is
resulting an out of date template anyway, so the proper installation
the steps should be:

- - Download and verify the ISO
- - write it to a DVD/pendrive
- - boot, and do a self check
- - install
- - update the dom0 and the currently used template
- - reboot
- - install new templates
- - update the new templates
- - setup the new templates for your VM's
- - Then - and just then - start USING Qubes.

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlpjggsACgkQGjNaC1SP
N2RPvw//R1qHU7MeydzaVrvsDbDkXlpw+Sp1QsGFI5U14PCI6CiulykPbsIPxSn/
aKaz8w8dER/yI0UKz8tZXazLlzDrhLPlz5wzyMHEjpzsMMMAaqLhU2WomksDQDMP
H74CqVsNfXU80c2cmda/jftPJSeRvDrg7vxl83vWdMoE8BGLYoaxDMbWAgTNgkrh
jqxbEL+UEISfqvY2tGMlFumbTx03F0Rfqso1HFdud+M4FKkAuUQ1Rv/0oNudBIQQ
pBwNnYGdjbs1F19acKKx6JfZnXAmHZSVevmnUx/YDKbDc9J2Ki5c8USKgkZpxFSQ
625fp/rLeKZI+cWWy0TK5cLHV3CPhJWTmvupxURvl5m6bBNBDfth9+fBqEzclsrI
T02mwvav6FPyb4eNrJRltHFC8WyZHor3HL1xAFHfkDg3A3GqPTUfhEcec89MJHof
KGpPHmEg8UCPoOYEoX7EJ7nmuA3C3iMw6b4QlEKly3+R7H+86hG1Z4SeI4lMEuTg
hkfISoM7GfTUPD4L400+qWNteS22ww6BFea+xVBaUYWdm2W1e/0d5jW7WltxkFMs
snysSKfRwVg9I/ALPR9KBtW9kqlII/Vin3CIKdeuGxXbTBQoA/BCTyoUx5ZlqvJm
7MRcRfZOH9EuI1pXe4G9zBRFfB574K2KF7f9dtp3aBV9NH0X3/g=
=r1iP
-----END PGP SIGNATURE-----

[bow...@gmail.com]

On Saturday, 20 January 2018 17:48:58 UTC, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sat, Jan 20, 2018 at 03:00:08PM +0100, Tom Zander wrote:
> > On Saturday, 20 January 2018 03:06:53 CET Marek Marczykowski-Górecki wrote:
> > > fedora-26, as default template for AppVMs, contains default user
> > > applications, like Firefox, Thunderbird. Shipping a _desktop_ operating
> > > system without web browser isn't going to work...
> >
> > I understand the argument, and I see you make a lot of sense.
> >
> > On the other hand there are a lot of little practical issues with this.
> > For instance; firefox has a 2-monthly releas cycle
> > https://wiki.mozilla.org/RapidRelease/Calendar
> > which makes any release from Qubes (on DVD) outdated really fast.
> >
> > I would guess people would suggest new qubes users would need to always keep
> > up-to-date, by downloading the latest from the internet.
> >
> > So in reality you end up shipping a firefox and various other large packages
> > which will be deleted hours after being installed because they are outdated
> > and possibly a security risk.
>
> Actually, Fedora support differential updates (*.drpm, being a binary
> diff of packages). So it isn't that much waste of space...
>
> Also, launching an update (simple action, available from GUI) is
> easier than finding what packages you need to install and where.

You could have Qubes's recommended security bundles (sets of packages) to install on top of a minimal.
You install Qubes (selecting minimal Fedora or Debian), update, install the "bundle" you want (anonymous browsing, signed emails, pen-tester) in a new template or existing one.

[Peter Todd]

On Sat, Jan 20, 2018 at 11:54:11AM +0000, Andrew Clausen wrote:
> Hi all,
>
> On 20 January 2018 at 09:28, Ivan Mitev <iv...@maa.bz> wrote:
>
> > +1
> >
> > Other people in the thread disagree and still use regular DVDs - which as
> > a readonly media is great for security - but how may people from Qubes'
> > user base still have and use an optical reader ? I haven't seen any recent
> > laptop (like in the past 3-4 years) with a CD/DVD reader and nowadays
> > desktop workstations usually don't include one either.
> >
>
> I buy a fresh USB DVD device with every secure laptop I buy. I don't reuse
> them, because I don't want a mistake made with one of them to contaminate
> another laptop. So I've got lots of them lying around the house!

What exactly is your threat model there?

Why not just use disposable USB keys, written on a secure system, then used
only with the target system?

> At some point DVDs + DVD equipment might become impossible to buy (or with
> only very few suppliers, all of whom could be interdicted). I'm not sure
> what I will do then!

Note that flash drives with physical write protect switches are available, such
as the Kanguru FlashBlu30 line.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[Andrew Clausen]

On 22 January 2018 at 07:33, Peter Todd <pe...@petertodd.org> wrote:

On Sat, Jan 20, 2018 at 11:54:11AM +0000, Andrew Clausen wrote:
> I buy a fresh USB DVD device with every secure laptop I buy.  I don't reuse
> them, because I don't want a mistake made with one of them to contaminate
> another laptop.  So I've got lots of them lying around the house!

What exactly is your threat model there?

Why not just use disposable USB keys, written on a secure system, then used
only with the target system?

I see two problems with your proposal.

(1) Chicken and egg.  To make a secure machine, you need a secure machine.  I think we ought to plan how to make a secure machines out of insecure machines.  "Build on 1 machine, verify on n machines" is a powerful concept.

(2) "Secure systems" don't exist.  Even if you do everything right (run Qubes, keep your machine with you at all times -- including the bathroom, have good passwords, etc.), you can *still* get owned!  We've seen a lot of Xen vulnerabilities, and now CPU vulnerabilities lately.  Tempest attacks are getting more sophisticated, and can be used to remotely sniff your private keys and passwords by watching radiation emissions from your CPU.  The update process for both the RPM and Debian ecosystems strike me as pretty fragile -- if a key gets stolen, it could be used to generate fake updates that are only ever seen by a small number of victims.  Therefore, I think it's wise to assume that even if a machine starts out "secure", it won't stay that way forever.  When you replace a secure machine, you don't want the the old machine infecting the new one.

> At some point DVDs + DVD equipment might become impossible to buy (or with
> only very few suppliers, all of whom could be interdicted).  I'm not sure
> what I will do then!

Note that flash drives with physical write protect switches are available, such
as the Kanguru FlashBlu30 line.

This sounds like a rather specialised device.  What about interdiction?  How does your supply chain work?  If you have a favourite product that you buy from a favourite shop, then it becomes cheap for an attacker to tamper with anything you plan to buy.  Kanguru could even be a front for some intelligence agency, or just some company that wants to sell out its customers.  You shouldn't buy stuff targeted specifically at paranoid people, unless there is some way to verify that they are delivering what they claim they are delivering.

I solve this problem with "random shopping".  I have printed out maps of all of the major cities near me, with all of the computer shops marked.  I always have the maps with me, so that an attacker can't watch my Google Maps searches, and figure out *when* I plan to go shopping, or *where* I might go shopping.  I pick a random shop off the map, and buy a random machine that meets the Qubes specs from the random shop.  I include second-hand machines in my shopping list, since as far as I know, modern malware from organised criminals that targets the masses is not a problem for Qubes.  Thankfully, we only have to worry about targeted attacks for the moment.

So, to re-iterate my original point: mass-market read-only media is a great way to ensure that your copy of the Qubes installer hasn't been tampered with.

Kind regards,

Andrew

[Vincent Adultman]

I'd also be strongly in favour of a minimal install image that would fit on a single layer DVD or small portable stick. In my ideal world, this would contain a minimal(ish) template with firmware as full fat for wireless cards, plus whatever is needed to install templates over tor.

On first boot after install, the user is prompted as to whether they would like full fat fedora, debian, whonix etc. I'm happy to hamfistedly try and produce a little GUI for this if it would in fact be welcome.

Colloquially and from what I've seen in person it isn't uncommon (even on modern hardware that reboots fast) for people to install their system, play with it for a bit (i.e. setup their email account in Thunderbird, browse / login some websites) and THEN check for updates and reboot at the end of the day / when they absolutely have to. That was one of my motivations behind querying a 3.2.1 release before all this meltdown/spectre stuff kicked off (thanks awokd btw for the work on that). Without giving some colorful example of a user (forbidden in the code of conduct), it seems likely many "ordinary" users would fit this and leave themselves at some sort of risk while setting up their machine. I've seen in previous years even fellow sysadmins (who should know better) do this when under time pressure.

The 3.2.1 ticket [1] demonstrated the work required in building just new point release iso, would it be helpful to have some individuals on some arbitrary schedule of your choosing try and produce a build to identify issues (and fix if they can). Again, I'm happy to volunteer my time on this if it's helpful (not currently clear on whether the bottleneck is build system time or/and availability of engineering time in documenting / addressing issues).

Best,

Vince

[1] https://github.com/QubesOS/qubes-issues/issues/3426

[awokd]

On Mon, January 22, 2018 4:12 pm, 'Vincent Adultman' via qubes-devel wrote:


> The 3.2.1 ticket [1] demonstrated the work required in building just new
> point release iso, would it be helpful to have some individuals on some
> arbitrary schedule of your choosing try and produce a build to identify
> issues (and fix if they can). Again, I'm happy to volunteer my time on
> this if it's helpful (not currently clear on whether the bottleneck is
> build system time or/and availability of engineering time in documenting
> / addressing issues).

I'm happy to help QA/bug squash what I can too.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Jan 20, 2018 at 08:25:12AM -0800, Frédéric Pierret (fepitre) wrote:
> Le samedi 20 janvier 2018 03:07:32 UTC+1, Marek Marczykowski-Górecki a écrit :
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Fri, Jan 19, 2018 at 11:11:02PM +0000, Unman wrote:
> > > However, it would be useful if you could give the relative template
> > > sizes on the current build.
> >
> > Sure[1][2]:
> >
> > fedora-26: 1643586746 bytes
> > debian-9: 722214642 bytes
> > whonix-gw: 504932958 bytes
> > whonix-ws: 705727858 bytes
> >
> > fedora-26, as default template for AppVMs, contains default user
> > applications, like Firefox, Thunderbird. Shipping a _desktop_ operating
> > system without web browser isn't going to work...
> >
> > But maybe there is a chance to trim Fedora template slightly...
> > Frédéric, do you see something that could easily be done there?
>

> I opened a PR (https://github.com/QubesOS/qubes-builder-fedora/pull/17). Now the template is ~990mo.

Thanks! I think this should be enough to fit the image on DVD!

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpmLFoACgkQ24/THMrX
1yzWqwgAlzSoWX6ZbmOZgEj7ouiS00yTiBiOiR6qE8fVU5zCjrrGsKkGspvJFJ9t
z69dFRBkll6P3ZbaDtyoVNAWCeAWeSm/1mfeGalBO1UdhBTXPXLjJKnxRPIo8sWh
M9wbzwrHqQ9iGQmc4CKSsF+sCcKZb0KUWM4Yebw70gKomh7VNCNxNmjyFB+sAiGv
zJQhIkOoi60+BXLbWnChmIoG3OUN6vsgRbOTaCsGsSzlrkGJN5bI/XGuTaMqLB9o
J2c4aVDk5ZhJE1rxlzxVIRYGSFGSO2g52MMPebiMQZuhFj4XcaPmNxCDizMyYX88
gMU7bPoA+6k6wlLIuL2naDpHl4+PYQ==
=dIfd
-----END PGP SIGNATURE-----

[Tamas K Lengyel]

> 2. grub suck at booting xen.efi (or rather: xen.efi is rather picky
> about its environment). On many systems, booting xen.efi without grub
> (using rEFInd, EFI shell, or simply by renaming it over BOOTX64.efi)
> helps with boot problems. An idea: do not use grub on UEFI installation.
> Downside: you loose boot menu - no way to choose or not media
> verification, or rescue mode. And no way to adjust boot arguments,
> needed on some platforms to workaround UEFI bugs... To do that, you'd
> need to edit EFI/BOOT/xen.cfg using some other means.
> Alternative: keep grub there, but provide an instruction how to boot
> xen.efi directly, in short:
>
> mount /dev/sdb1 /mnt # assuming /dev/sdb1 is installation USB
> mv /mnt/EFI/BOOT/xen.efi /mnt/EFI/BOOT/BOOTX64.efi
> mv /mnt/EFI/BOOT/xen.cfg /mnt/EFI/BOOT/BOOTX64.cfg
> umount /mnt
>
> After such operation, media verification would fail, obviously.
>
> Any input on the above?

I'm currently adding EFI_LOAD_OPTION support to Xen upstream to be
able to set boot entries directly with efibootmgr:
https://lists.xen.org/archives/html/xen-devel/2018-01/msg00315.html.
Version 3 of the patch will be sent shortly. The patch can be
backported, to earlier versions of Xen as needed. With this patch in
place there is no need for GRUB and you can directly pick which
section you want to activate from xen.cfg using the firmware boot
selection menu. The only downside is that only UEFI firmware that
adheres to 2.5c or later supports it.

Tamas

[Sebastian Götte]

On 01/22/2018 08:33 AM, Peter Todd wrote:
> Note that flash drives with physical write protect switches are available, such
> as the Kanguru FlashBlu30 line.

While better than a regular r/w USB drive, I would not actually trust these. There's only going to be a regular USB flash controller inside, and the firmware on that one is just as good as the firmware on other USB drives.

The type of attack DVDs prevent is one where a compromised "download" or "checksum" machine compromises the USB drive firmware. The compromised USB drive then presents different data to different machines, e.g. the original iso to anyone checksumming and a modified iso to anyone booting. This attack requires a compromise of the USB flash drive controller via USB. This is realistic and has been demonstrated in the past.

A "physical write protect switch" is only going to be routed into that chip through a GPIO, so it does *not* protect against this attack. Write-protect on or off, most of the USB protocol logic inside the controller must be working in order to serve read requests.

DVDs fare better in this scenario. Even though you could also attack the reader firmware, the attacker has only one (large) static payload read by the firmware (the DVD). In case of the USB drive, the attacker has an interactive session over a complex, multi-layer protocol presenting much more attack surface.

[Ivan Mitev]

On 01/27/18 13:33, Sebastian Götte wrote:
> On 01/22/2018 08:33 AM, Peter Todd wrote:
>> Note that flash drives with physical write protect switches are available, such
>> as the Kanguru FlashBlu30 line.
> While better than a regular r/w USB drive, I would not actually trust these. There's only going to be a regular USB flash controller inside, and the firmware on that one is just as good as the firmware on other USB drives.
>
> The type of attack DVDs prevent is one where a compromised "download" or "checksum" machine compromises the USB drive firmware. The compromised USB drive then presents different data to different machines, e.g. the original iso to anyone checksumming and a modified iso to anyone booting. This attack requires a compromise of the USB flash drive controller via USB. This is realistic and has been demonstrated in the past.

I don't see the benefit of using a DVD (we're talking about USB DVD
readers here) but maybe it's only me being thick...
If the machine used to copy or checksum the payload/iso is compromised,
then IMO it's already "game over" so I don't see how using a true
read-only medium vs a regular flash drive would help.

> A "physical write protect switch" is only going to be routed into that chip through a GPIO, so it does *not* protect against this attack. Write-protect on or off, most of the USB protocol logic inside the controller must be working in order to serve read requests.
>
> DVDs fare better in this scenario. Even though you could also attack the reader firmware, the attacker has only one (large) static payload read by the firmware (the DVD). In case of the USB drive, the attacker has an interactive session over a complex, multi-layer protocol presenting much more attack surface.

Assuming the machine is not compromised and the payload/iso is legit,
the only way for the bad USB device to modify the data would be on-the-fly:

- when writing the iso to the medium (in which case using a
write-once-then-read-only doesn't help at all vs using a writable medium)

- when reading it, for instance at boot, presenting different data to
different machines like you mentioned.

But:

1- How really feasible is it to implement this attack ? It would
require tremendous processing power to properly alter the payload when
it's been copied to the medium; it would also require tailoring the
attack to qubes' isos, thus making it a targeted attack; I imagine that
if you get to that point you probably have more important problems.

2- both the DVD reader and flash drive have a USB firmware, so how
would the DVD reader's firmware be more "secure" than the USB flash
drive's one ?

But then, I'm not a security expert and I may be talking total nonsense
:) - I'd be happy to be proved wrong and learn something in the process...

Cheers,
Ivan

[Andrew Clausen]

Hi Ivan,

On 27 January 2018 at 12:57, Ivan Mitev <iv...@maa.bz> wrote:

I don't see the benefit of using a DVD (we're talking about USB DVD readers here) but maybe it's only me being thick...
If the machine used to copy or checksum the payload/iso is compromised, then IMO it's already "game over" so I don't see how using a true read-only medium vs a regular flash drive would help.

The idea is that you use many machines to checksum the payload.  Each machine would have its own DVD device.

A "physical write protect switch" is only going to be routed into that chip through a GPIO, so it does *not* protect against this attack. Write-protect on or off, most of the USB protocol logic inside the controller must be working in order to serve read requests.

DVDs fare better in this scenario. Even though you could also attack the reader firmware, the attacker has only one (large) static payload read by the firmware (the DVD). In case of the USB drive, the attacker has an interactive session over a complex, multi-layer protocol presenting much more attack surface.

Assuming the machine is not compromised and the payload/iso is legit,

But I was assuming the opposite!  The challenge is: how can you make a secure machine out of insecure machines?

 

the only way for the bad USB device to modify the data would be on-the-fly:

- when writing the iso to the medium (in which case using a write-once-then-read-only doesn't help at all vs using a writable medium)

- when reading it, for instance at boot, presenting different data to different machines like you mentioned.

But:

 1- How really feasible is it to implement this attack ? It would require tremendous processing power to properly alter the payload when it's been copied to the medium; it would also require tailoring the attack to qubes' isos, thus making it a targeted attack; I imagine that if you get to that point you probably have more important problems.

In a targeted attack by the local government, I would think it's a moderate fixed cost (e.g. one engineer spending about 3 months on it), with a low marginal cost for each victim to be attacked.  If it's a foreign government or organised crime, then interdiction becomes more expensive.  So they might need to add in a physical surveillance element as well, e.g. some kind of radio signal to tell the USB stick remotely that it should activate the attack.  Much cheaper than the 24/7 physical surveillance that many activists and some journalists are under at sensitive moments.

So overall, I think lots of attackers -- including big companies (e.g. oil, mining, pharma), organised crime, local and foreign governments -- would find this attack promising.

We know from Snowden that at least one big agency likes targeting developers and system administrators.  I would expect that everyone on this mailing list is a target, just because they are on the list.

  2- both the DVD reader and flash drive have a USB firmware, so how would the DVD reader's firmware be more "secure" than the USB flash drive's one ?

Because you never plug the DVD reader into an insecure machine, only the fresh new one.

Kind regards,

Andrew

[Ivan Mitev]

Hi Andrew,

On 01/27/18 15:31, Andrew Clausen wrote:
> Hi Ivan,
>
> On 27 January 2018 at 12:57, Ivan Mitev <iv...@maa.bz> wrote:
>
>> I don't see the benefit of using a DVD (we're talking about USB DVD
>> readers here) but maybe it's only me being thick...
>> If the machine used to copy or checksum the payload/iso is compromised,
>> then IMO it's already "game over" so I don't see how using a true read-only
>> medium vs a regular flash drive would help.
>>
>
> The idea is that you use many machines to checksum the payload. Each
> machine would have its own DVD device.

Ah, I see; in this case I agree that a DVD should give you greater
("reasonable" ?) confidence that the install iso is legit compared to
writable medias, provided you have enough machines and readers to test.

Re-reading the whole thread I'm not sure that the other parent posters
had this idea in mind though...

>> Assuming the machine is not compromised and the payload/iso is legit,
>
>
> But I was assuming the opposite! The challenge is: how can you make a
> secure machine out of insecure machines?
>
>
>> the only way for the bad USB device to modify the data would be on-the-fly:
>>
>> - when writing the iso to the medium (in which case using a
>> write-once-then-read-only doesn't help at all vs using a writable medium)
>>
>> - when reading it, for instance at boot, presenting different data to
>> different machines like you mentioned.
>>
>> But:
>>
>> 1- How really feasible is it to implement this attack ? It would require
>> tremendous processing power to properly alter the payload when it's been
>> copied to the medium; it would also require tailoring the attack to qubes'
>> isos, thus making it a targeted attack; I imagine that if you get to that
>> point you probably have more important problems.
>>
>
> In a targeted attack by the local government, I would think it's a moderate
> fixed cost (e.g. one engineer spending about 3 months on it), with a low
> marginal cost for each victim to be attacked. If it's a foreign government
> or organised crime, then interdiction becomes more expensive. So they
> might need to add in a physical surveillance element as well, e.g. some
> kind of radio signal to tell the USB stick remotely that it should activate
> the attack. Much cheaper than the 24/7 physical surveillance that many
> activists and some journalists are under at sensitive moments.

I wrote "tremendous processing", not "tremendous manpower": whatever the
manpower and time spent by clever minds, I don't see how the USB
hardware of a DVD reader or a flash drive could cope with on-the-fly
analysis and modification of the data "passing by" at full read speed.

The attack mentioned by Sebastian - presenting different data to the
host at boot time - is likely within the realm of USB hardware/firmware
resources because there is enough time to analyze only a small amount of
read data. In case you managed to get reasonable confidence that your
medium is legit with the technique you describe, you could assume that
it won't contain a "bad" alternate image so the attack above won't work.
Your host's USB hardware could still be compromised though.

I now see what your setup achieves so thanks for your reply - it's
always interesting to see what other people are doing even if I don't
need to be that paranoid - fortunately !

Best,
Ivan

[Joseph Taylor]

>1. After upgrading templates to fedora-26 and debian-9, there is no way
> the installation image will fit on DVD. Right now it takes 4908384256
> bytes. We probably could try to cut it down by eliminating even more
> packages from templates, but I think there is no much non-essential
> packages left there. For example we no longer ship vim in debian-9.
> Right now I see two options:
>
> - abandon the goal of fitting the image on DVD (I'd go for this)
>
> - exclude some template from default installation...

A lot of users today may have secure machines from which to build a trusted USB installer out of a larger image. One option could be to offer a single layer DVD image that just discards the debian-9 template, the whonix templates or both, and also offer a larger image with all the goods included. That way someone bootstrapping a trusted environment could use the single layer image to verify the burnt image and install it, then download additional templates, while someone with a trusted environment to burn the installer to a USB can just use the larger image.

Another option would be to accept a larger image size but notify users of the DVD approach and simply specify that they will need a double layer DVD. DVDs are more than 15 years old by this point, even double layer discs and burners are inexpensive for someone going to the effort to acquire hardware for verification of a qubes image as well as hardware capable of running qubes in a sufficiently secure mode to justify that effort.

>2. grub suck at booting xen.efi (or rather: xen.efi is rather picky
> about its environment). On many systems, booting xen.efi without grub
> (using rEFInd, EFI shell, or simply by renaming it over BOOTX64.efi)
> helps with boot problems. An idea: do not use grub on UEFI installation.
> Downside: you loose boot menu - no way to choose or not media
> verification, or rescue mode. And no way to adjust boot arguments,
> needed on some platforms to workaround UEFI bugs... To do that, you'd
> need to edit EFI/BOOT/xen.cfg using some other means.
> Alternative: keep grub there, but provide an instruction how to boot
> xen.efi directly, in short:
>
> mount /dev/sdb1 /mnt # assuming /dev/sdb1 is installation USB
> mv /mnt/EFI/BOOT/xen.efi /mnt/EFI/BOOT/BOOTX64.efi
> mv /mnt/EFI/BOOT/xen.cfg /mnt/EFI/BOOT/BOOTX64.cfg
> umount /mnt
>
> After such operation, media verification would fail, obviously.

You could offer this as an installation option, either by booting the installer using EFI directly (the installer itself doesn't need a boot menu, if needed you could just automatically run media verification with a skip prompt instead of making it a boot option), or by offering 2 versions of the installer image, one with GRUB and one that configures the system for direct booting.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jan 29, 2018 at 12:37:56AM -0500, Joseph Taylor wrote:
> >2. grub suck at booting xen.efi (or rather: xen.efi is rather picky
> > about its environment). On many systems, booting xen.efi without grub
> > (using rEFInd, EFI shell, or simply by renaming it over BOOTX64.efi)
> > helps with boot problems. An idea: do not use grub on UEFI installation.
> > Downside: you loose boot menu - no way to choose or not media
> > verification, or rescue mode. And no way to adjust boot arguments,
> > needed on some platforms to workaround UEFI bugs... To do that, you'd
> > need to edit EFI/BOOT/xen.cfg using some other means.
> > Alternative: keep grub there, but provide an instruction how to boot
> > xen.efi directly, in short:
> >
> > mount /dev/sdb1 /mnt # assuming /dev/sdb1 is installation USB
> > mv /mnt/EFI/BOOT/xen.efi /mnt/EFI/BOOT/BOOTX64.efi
> > mv /mnt/EFI/BOOT/xen.cfg /mnt/EFI/BOOT/BOOTX64.cfg
> > umount /mnt
> >
> > After such operation, media verification would fail, obviously.
>
> You could offer this as an installation option, either by booting the
> installer using EFI directly (the installer itself doesn't need a boot
> menu, if needed you could just automatically run media verification
> with a skip prompt instead of making it a boot option), or by offering
> 2 versions of the installer image, one with GRUB and one that
> configures the system for direct booting.

Two versions would be a mess, especially when there will be such subtle
difference. A lot of people will have hard time figuring which one is
the correct for them (in most cases: any, but still, you need to make a
choice). And at the same time, it will require more testing on our side
(two images instead of one), use more space on mirrors etc.

But there is another option: get rid of the grub, boot installer
directly, but enable known UEFI workarounds by default (dropping grub is
one of them ;) ). This should be the most convenient for most users,
even those having buggy UEFI. The missing thing will be "rescue mode", but
it is still possible to use installer for that - you just need to switch
to the second console (alt-ctrl-f2) instead following installer
instructions.

And if that still isn't enough for some machine, there are still old
workarounds available - including using rEFInd or modifying image as
described above (both kernel and xen options). Or booting in legacy
mode, where you have menu to modify boot options.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpvogwACgkQ24/THMrX
1ywHRQf+Mu7kt+7ppWV8+nQufenwp2q6sS5mipxI3hcbFc1fDGLanlX2SPgLU8zI
JLMwoUW+4M08EHnRRi8MI6stiCREFMUPbMEu9HWl8Ss0mkFmZ/1xbIJNtPd13BpS
mQjqlelAwAJfN/U9mSSrF4OcZc/vy35LXHPeO9lqz4qqT101KasjvwxhbL4lRaL/
w188zthHm3jSmC5Ltd3t3GIzdg6mlbBNp23+fL+zfis2GJGeaudRzvZ+m5iFPhsk
52JwPxkLfu2qADs4+s6fKatZUj7ShHhU2ZC5vK1+c/4UCHwFhqs6TeDDNV5ULzn5
e3R4pUzBYZrp2EllW3Sh8z4CwAJXXw==
=qObK
-----END PGP SIGNATURE-----

[Vít Šesták]

Well, will there be a way to enter the rescue mode by entering a command, or the user will have to handle all the stuff (LUKS, LVM, mount and chroot) manually?

For my purposes, I don't care much (i.e., I can handle all of those manually), but I can't imagine giving such advice to a user asking in mailing list. The user will either be able to do this manually or I will not be able to give them an advice.

Also, Memtest86+ is probably going to be missing for UEFI without Grub (as Memtest86+ is 16-bit, so UEFI cannot start it directly), but this is probably not such essential feature ☺. And even in Q3.2, one has to switch to legacy mode for Memtest86+.

On the size issues: As far as I read it well, this has been solved for Qubes 4-rc4, but this issue might arise again later. I think that within first run, user can be prompted for next steps like dom0 update, using Tor by default, templates update and installation of additional templates. This could allow to exclude debian and whonix-ws templates to be excluded from the install image without harming user experience. And it can be even useful for users, because this can encourage updates after installation is finished.

I see this approach is too late for Qubes4-rc1, but it could be useful for some future release.

Regards,
Vít Šesták 'v6ak'

[Andrew Clausen]

Hi all,

On 30 January 2018 at 08:02, Vít Šesták <groups-no-private-mail--con...@v6ak.com> wrote:

Also, Memtest86+ is probably going to be missing for UEFI without Grub (as Memtest86+ is 16-bit, so UEFI cannot start it directly), but this is probably not such essential feature ☺. And even in Q3.2, one has to switch to legacy mode for Memtest86+.

Isn't Memest86+ good for detecting Rowhammer vulnerabilities?

Use case: I walk into a shop, and ask to try before I buy.  I get out my Qubes DVD, and I check that Qubes works, and that the RAM isn't vulnerable.

I suppose it's not the end of the world -- I can bring something else with memtest86 on it.  It is nice to be efficient about these things though (to not test the patience of sales staff).

Cheers,

Andrew

[Vít Šesták]

On January 30, 2018 3:12:00 PM GMT+01:00, Andrew Clausen <andrew.p...@gmail.com> wrote:
>Isn't Memest86+ good for detecting Rowhammer vulnerabilities?

AFAIK Memtest86+ does not detect it and it is not even supposed to. My old laptop has passed Memtest86+ test, but it has failed rowhammer test. Moreover, rowhammer test might take some time...
Regards,
Vít Šesták 'v6ak'

Maybe top-posting is bad. However, quoting whole message (including quotes of quotes and quotes of quotes of quotes etc.) before your message is even worse. Please don't let others scroll extensively.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Jan 30, 2018 at 12:02:12AM -0800, Vít Šesták wrote:
> Well, will there be a way to enter the rescue mode by entering a command, or the user will have to handle all the stuff (LUKS, LVM, mount and chroot) manually?

Yes, it is possible also from installation mode:

1. Switch to tty2
2. killall -9 anaconda
3. anaconda --rescue

> For my purposes, I don't care much (i.e., I can handle all of those manually), but I can't imagine giving such advice to a user asking in mailing list. The user will either be able to do this manually or I will not be able to give them an advice.
>
> Also, Memtest86+ is probably going to be missing for UEFI without Grub (as Memtest86+ is 16-bit, so UEFI cannot start it directly), but this is probably not such essential feature ☺. And even in Q3.2, one has to switch to legacy mode for Memtest86+.
>
> On the size issues: As far as I read it well, this has been solved for Qubes 4-rc4, but this issue might arise again later. I think that within first run, user can be prompted for next steps like dom0 update, using Tor by default, templates update and installation of additional templates. This could allow to exclude debian and whonix-ws templates to be excluded from the install image without harming user experience. And it can be even useful for users, because this can encourage updates after installation is finished.

This may be problematic for multiple reasons:
- some users may not have fast internet connection available at
installation time; downloading one file (ISO) over another
connection, somewhere else, asking a friend for that etc is much
easier to organize than attaching your machine there
- downloading templates over tor takes a long time... and some may
prefer to not do it over clearnet on own connection (see point above)

But we can think about it all later...

> I see this approach is too late for Qubes4-rc1, but it could be useful for some future release.

Yes, definitely.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpxFM4ACgkQ24/THMrX
1yytyAf+PznVTJuTbCxsfHU94BsJ14OkJaajpC0Qw8a1v4YRUsVhqCpxu6c3p0O8
cZ6nkxA8TOGPqSIpXm07Qr7Uv1A9aYVuXMFr6+4lx4Dn/CnaoRQ+PsKOpBpbcswZ
DwF1NpNKB/G7OOYDDPhxstm3vpr8MBaBLQytaqzEAC9syWsDljDIGuQiMOcxRt73
LQ9oTRTo3gHYMtwwh7x7fxMXb1jTv+8mPXH8We2RRRU9/yF1O5QOAJgGDnfp7Mve
lkn5/Fs6pPZNMgmd2F2ucr7jowe2ER4DCQWS1CUwGo11yRXJM9AHeNYdJuo837HD
ux3faV/W47u+nKRPZuo0KOwoBGbLLg==
=PxIG
-----END PGP SIGNATURE-----

[Andrew Clausen]

Hi Vít,

On 30 January 2018 at 14:39, Vít Šesták <v...@v6ak.com> wrote:

On January 30, 2018 3:12:00 PM GMT+01:00, Andrew Clausen <andrew.p...@gmail.com> wrote:
>Isn't Memest86+ good for detecting Rowhammer vulnerabilities?

AFAIK Memtest86+ does not detect it and it is not even supposed to. My old laptop has passed Memtest86+ test, but it has failed rowhammer test. Moreover, rowhammer test might take some time...

Ah, I confused Memtest86 (proprietary) with Memtest86+ (GPL).  The former tests for Rowhammer.  The latter does not, although there is a patch available at https://github.com/CMU-SAFARI/rowhammer

I hope they include it some day!

Kind regards,

Andrew

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/30/2018 07:29 PM, Andrew Clausen wrote:

> Ah, I confused Memtest86 (proprietary) with Memtest86+ (GPL). The
> former tests for Rowhammer. The latter does not, although there is
> a patch available at https://github.com/CMU-SAFARI/rowhammer
>
> I hope they include it some day!

LOL

That thing is outdated badly. Nobody touched it for like 5 years now.
I would be surprised if it is even booting on recent laptops/chipsets.

Can anybody confirm this?

The "Free Edition" of the proprietary one is working better for sure,
however I don't know if it can be distributed via 3rd party OS install
discs or not. (no information found on the website about this use case)

- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlpxmboACgkQGjNaC1SP
N2RXVhAArhHV938WaGIzkNCdxklozbLaFJVdKlY37kJbr6qa1+YHetgPsT6P68Tu
T2SSBP3T/Y7P7yxnCBQKzGLjk7YfXzcFEtyHHoGjgCo6t/xZ80l68GeUXSAdRx7e
pB126XWujWtyM3NHEiUtsq/9aXeqflAP3omQlkZ2znarJn1Nbx8zfllUg3wdouQo
jjwBc8Te/DgARDyabdQMuC3jE37uaz0w1HN58OVsa1jjjY84zViuxUETpdaKT3ri
XD1NjH2qtQWn5nSLX/NMC9MTYigTpMpJhQcp/ifHrzReGYbgvXxKWEISOwLvUbEx
68GosM5CsQBOwjUkorEDufkGJ5JBRUj9/B+ymlvTGLR1VcgME8gPeqBw08vzuP2d
lR09ojFAPldlHapdUxayJ3RBXOPShQBHGk8hJ/3RcDOypX8xKt3p8XRAv4jzw7FO
K4xZi9LcuR3cQPpAwxTno6a8+1nPnAnbHm2B9KRTycpR+7k5eY9Yt/27dIDHyCCa
2dVz6VNGkQm9IbfyDcHwwi4qPsOsH53gWgLcYF1qNpGwZNGaQkwmJmonpbEt7rJ8
a99HFhwZdHhIoQOoLtn+0emPVMXdku9JKv/fIBNuhF8+bRLTodEL1IP3sAPNfblU
74PvzSPxjPtP4jeYiJBqPywWj9hyq6BwnSdMvei048vmHXaceK8=
=Hlxc
-----END PGP SIGNATURE-----

[Andrew Clausen]

Hi Zrubi,

On 31 January 2018 at 10:26, Zrubi <ma...@zrubi.hu> wrote:

> Ah, I confused Memtest86 (proprietary) with Memtest86+ (GPL).  The
> former tests for Rowhammer.  The latter does not, although there is
> a patch available at https://github.com/CMU-SAFARI/rowhammer

The "Free Edition" of the proprietary one is working better for sure,
however I don't know if it can be distributed via 3rd party OS install
discs or not. (no information found on the website about this use case)

Maybe we can just include

  https://github.com/google/rowhammer-test

in the Qubes installer?  It could be an optional thing to do right at the start (just after choosing your language).

Cheers,

Andrew

[Vít Šesták]

On Tuesday, January 30, 2018 at 5:58:54 PM UTC+1, Marek Marczykowski-Górecki wrote:
> 1. Switch to tty2
> 2. killall -9 anaconda
> 3. anaconda --rescue

Hmm, probably good enough in this situation.

> - some users may not have fast internet connection available at
> installation time; downloading one file (ISO) over another
> connection, somewhere else, asking a friend for that etc is much
> easier to organize than attaching your machine there

It depends on the options. In the current state, you are right, there is no easy process for that. But I remember some note that the current option is suboptimal anyway: Installing RPMs in dom0 from some potentially less trusted source is not what you want in general. (Sure, this depends on the scenario.) Once there is some alternative that allow convenient installation of VM templates from domUs, one could bring it on a separate flash stick. Or even on a second DVD.

> - downloading templates over tor takes a long time... and some may
> prefer to not do it over clearnet on own connection (see point above)

You are right, but OTOH, downloading some far outdated templates within the install image (like you do with Q3.2 today) and then downloading newer images over the network can take even more time.

> > I see this approach is too late for Qubes4-rc1, but it could be useful for some future release.
>
> Yes, definitely.

Oops. Of course, it was too late for RC1 at the time of writing… (Note the typo in my previous post – I wrote “rc1” instead of “rc4”.)

Regards,
Vít Šesták 'v6ak'

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/19/2018 02:37 PM, 'Tom Zander' via qubes-devel wrote:
> are thunderbird and firefox still included?
>
> Those are hardly essential...

Hi Tom,

I am struggling to see your perspective. Maybe I am an old fart, but
Thunderbird and Firefox are very much essential to me. I am not
looking for a big debate, which would be off topic here anyway ...
just wanted to give feedback that there might be more people like me
very much depending on the duo.

/Sven

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlp02XEACgkQ2m4We49U
H7bGtQ//bcBy6m6ePdJmtAFjWjzc406yoDi0yfAgZVpPxiaVgAZ9dViRS2xeCRcz
Yv+YZaGSMfbiuQ1b7u5msRe9R7a9lwRuSwXapvYnQod/TY1GDIIOw/Vj2l9QjpcN
Mv5GVr/8dU2ADRT9dns2+UHkQeJsdXpQfac7V8UostM7C/6Yb5Vuu3wsaRVpuR6L
WLImG5bpK+S5Jb4TKDymAKqFGJ63QRVrX+DH+kdwdxAX15Ot2ankxnuTIHQJv7mi
crowOFMkHkFEvXMXIgkupsmXxhGdhm2UYPh1FZneP2ATX4UfeKPnCOjcJ5a9G8N7
q5qCkarlZ4tVGxyG8TEOkdPQbcAVY1JHdBjdSzrfAxN6jO4cBBi7OJMzAjD5D11h
6JuHf8va9djEcBlITDUwZkYdGy8PvZ71mIae1KDVriVMdbJEyeDNYxES63YJgRCC
XLVOZ00Q2TqljKlKWWe6bEsSiTYqe3mu+qJzJuWNZwWg6cILp9GZgKBwKvFEB75b
3/VsL96TmOArTjQgJ9zPD429/7S4SUZHxQ3IxXnMGT9Ttt2+eBhARMSNCbmZMIhh
dbBWa3L+3PupOUD+/Njr9Uz8OPB02xnb/LuGw/6Kr8uUsbA2sTUsYYF/g5obuuQP
q9X1Mkr7xAnz9qbqN0tVhcK5fQ8Zk6hDOIXrdnJ224fGh1WGlFc=
=RSee
-----END PGP SIGNATURE-----

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/02/2018 03:34 PM, Sven Semmler wrote:
> I am struggling to see your perspective. Maybe I am an old fart,
> but Thunderbird and Firefox are very much essential to me. I am
> not looking for a big debate, which would be off topic here anyway
> ... just wanted to give feedback that there might be more people
> like me very much depending on the duo.

Ignore me. I am totally on board with bare-bones templates and then
downloading whatever you actually like to use.

/Sven


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlp02icACgkQ2m4We49U
H7Yo2A//eL8GxtOWCHiLd9DuMkqSoZMH0+wLVhf7jPs3thXxsZAUHHqDLbni14AA
mO/vmxDcq+UCK6D4ok1OGIcfrwv19YioNKPJN59mn3CKI5DOGOp5LYkB37YnNYOy
z7McnmXq1TyjIO82XG+rdjMfr8QBT+KVgQqlWJWNx0HdsSyGdk2bzOf5RfHE1/HD
trTZ3fDU+1IV9/yLzcQ0li1hVTR1lswGnxDkWoDN4csPPdufd9hFDiAnnqRXqZv2
zmqpuoeB1prRs+l44yUcgtbyt1EAVuT+RLacVIICJKR/nnXL/uuKohk4Z1JZFGWq
kXm//L75kk+4KqfuXsx4w4sYv0VzjSAKRDQbTra+5SihJiinYNnSaSIs6tXjuFFh
vKerNHzxip3kvFfp1+4BTNa3t9fU8RSIw9Aq4YJrVQ8kCAdpb3f35W4GLuwt+0GX
EVe1Qkp9rANYW5ZMEXKrVQRhDyW5ov5kLomLPbZNsmikc2a+nq8lSj/GL62NuVor
OstSFyKkMfz5RtjKxsBJT68lGUl4owf9AXRcchfM7l+UHWDRmW06TbAm3lmHMdUl
h71XZrK48Y8eeEj32hLUDzlpPa1rUrBEo4EOz1CgbkEEoN4MUkThLIe6sJ11XC8a
4aV9DI6+x83kNNR14iRkNpH46nqXQVy85BVTJupVzqBaydOE0D4=
=GDqN
-----END PGP SIGNATURE-----