How to properly administer several templates?

[Albin Otterhäll]

I've eight different templates (copies, etc.) and administrate them
takes quite a while. How should I streamline this and make it as easily
as possible to update and install applications across several templates?

[J. Eppler]

Hello,

if some of the templates have the same functionality with a subset/superset of applications
you could combine them in a new template and reassign the VM's which are based on the other templates.

You could use the salt management stack or bash to update/upgrade vm's.

Best regards
  J. Eppler

[Albin Otterhäll]

J. Eppler:

> if some of the templates have the same functionality with a subset/superset
> of applications
> you could combine them in a new template and reassign the VM's which are
> based on the other templates.

The problem is that some software I have installed on one template
shouldn't be installed in the other. E.g. I've a template dedicated to
development with Docker's own repo added. This adds to the attack
surface (not much, but still) and I don't want to risk my general Debian
template.

> You could use the salt management stack or bash to update/upgrade
> vm's.

I guessed that. I haven't yet read up on SaltStack, but should the salt
"scrips" be in dom0, or another secure appvm? Maintaining the salt
recipes in a git repo would make it easier when reinstalling Qubes (e.g.
when upgrading).

[J. Eppler]

On Tuesday, June 14, 2016 at 6:03:46 PM UTC-5, Albin Otterhäll wrote:

J. Eppler:
> if some of the templates have the same functionality with a subset/superset
> of applications
> you could combine them in a new template and reassign the VM's which are
> based on the other templates.

The problem is that some software I have installed on one template
shouldn't be installed in the other. E.g. I've a template dedicated to
development with Docker's own repo added. This adds to the attack
surface (not much, but still) and I don't want to risk my general Debian
template.

I normally clone the templates e. g. debian-8 -> debian-8-dev install all the needed software.
If I do something more specific it would make sense to create a debian-8-docker-dev template.
You can then create multiple AppVM's based on the debian-8-docker-dev template. Than
you maybe have a general debian-8-dev, debian-8-app and a debian-8-min template etc.

If you want to update/upgrade the different templates regularly, than it would be a good idea
to write a small shell, python or ruby script to automate the update/upgrade process for all
templates.

There is no good solution for doing this. The flexibility of having many templates comes
with the cost of maintaining all of them separately.
 

> You could use the salt management stack or bash to update/upgrade
> vm's.

I guessed that. I haven't yet read up on SaltStack, but should the salt
"scrips" be in dom0, or another secure appvm? Maintaining the salt
recipes in a git repo would make it easier when reinstalling Qubes (e.g.
when upgrading).

I don't have any use case where the SaltStack would make sense for me, therefor I
do not use it.

Best regards
  J. Eppler

[Marek Marczykowski-Górecki]

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

On Tue, Jun 14, 2016 at 11:04:21PM +0000, Albin Otterhäll wrote:
> J. Eppler:
> > if some of the templates have the same functionality with a subset/superset
> > of applications
> > you could combine them in a new template and reassign the VM's which are
> > based on the other templates.
>
> The problem is that some software I have installed on one template
> shouldn't be installed in the other. E.g. I've a template dedicated to
> development with Docker's own repo added. This adds to the attack
> surface (not much, but still) and I don't want to risk my general Debian
> template.

Indeed this case looks like a valid reason for separate template. Or if
you have just one such VM (and don't expect to have other in the
future), use standalone VM. In any case, you need to apply updates
there.

> > You could use the salt management stack or bash to update/upgrade
> > vm's.
>
> I guessed that. I haven't yet read up on SaltStack, but should the salt
> "scrips" be in dom0, or another secure appvm? Maintaining the salt
> recipes in a git repo would make it easier when reinstalling Qubes (e.g.
> when upgrading).

Yes, SaltStack should be able to handle this, starting with Qubes 3.2
(where it can not only create VMs, but also configure system inside).
I haven't tried batch update yet, but have some recipe for installing
packages in all the templates.
Take a look at "Example of VM system configuration" section of:
https://www.qubes-os.org/doc/salt/

The same "pkg" state should handle update too:
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.uptodate

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXYJhwAAoJENuP0xzK19csgYUIAJpA88xBM65OJ9l67ZU0b+Fj
eort3g5E+fMzTUrnICefjp3AckUNDocztaAIoKvEZvtk89BDNu8GiItDEHqqiKTh
c5pTLdK+w/BcKCL8peK3c5Sk0YYPcnkGz+VSUQKSCYxMLRlywf0JiJArzFkJy+7R
nUoHipIy89SjP5mh9ZjYVPGBjMAwNhb6ozJSYJGoFYytHAjIJxbqQLR8Kp2YUCeU
c/y/VXuQMvfk2iZT87t5l1YbOwPM1LatEPcaM1XxUWu6UkP+YDeUVPkmB7FwUiK8
BXOEHUyRQn4+xOVMSUEQZIjxy6qnAgxpcDkd13X2ktaOzC2yARx9Hi0ldQAV1rs=
=CAeM
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

Personally, I found that the vast majority of time I spent
administering templates was spent on keeping them updated, so I wrote
a bash script to update them and set it to run periodically as a cron
job in dom0.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXYLQuAAoJENtN07w5UDAwvDQP/0KA3aa/yzjAShvQRgXMQDFQ
xDxVzCyhZ40RtmPAv/Zw+hp+tq5K2optikX0dYKlHo4PPi+MV9w42K81bK7P20kY
nfFSaAX5VzZL5iXeVKFlBwKkRCj5VcAj2K+t2lE72uFu276R8/3WGCsR2uY5YAJz
CVj2Oypqdu31TR17wBUwO9rUpYKD8mUp2aAOcDG6DT/T/Vxo4N6B+EWYh0RQufxc
IHaf5jGXUh9LJxmt3GOvr7ghGrvqjHbfrz1VkbeSni7lCkuXNsjJ5Ds4YTGtZmhV
r87cS191aSLDwFHgzYsv/LM4EgDDTsvUdxzJ/IStASjCjA6FA8l3h2H78lNzJ4g8
yaAHTpPRf9S8ybH0G9+ija/9BaCxEVIBcPbKKXRAF5yAuVvXQRO08qBrf65JwE5u
MK4oASN12bcW6ZGJBErRif9RM+4+dOM0gV3Jrrxqakk6MOAz1iDSTFj0OZrdjA6v
Wbr7f+J1Ql121wrfsA7vPlPV21WKbaI5ubFU0jyHcEq/MaYpol+RRknm/syrddig
eCV0AqhZsyvMdcvNY+7jqi7cpBE9XDZexVIRVUIiygOqtohUx6nfZa8LUseUlkOd
nJ5OUL4PqcqJ5RuPTAYco2IVmAMioTVjKTdZkf9UYrvVpDcYZpZ2JbBgviqk/X+L
SxHYeHCtFhSQv4rpNuCz
=Dtov
-----END PGP SIGNATURE-----

[Albin Otterhäll]

Marek Marczykowski-Górecki:

> Yes, SaltStack should be able to handle this, starting with Qubes 3.2
> (where it can not only create VMs, but also configure system inside).
> I haven't tried batch update yet, but have some recipe for installing
> packages in all the templates.
> Take a look at "Example of VM system configuration" section of:
> https://www.qubes-os.org/doc/salt/
>
> The same "pkg" state should handle update too:
> https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkg.html#salt.states.pkg.uptodate

Nice! It will be one of the first new features that I will test out.

[Franz]

On Tue, Jun 14, 2016 at 10:49 PM, Andrew David Wong <a...@qubes-os.org> wrote:

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

On 2016-06-14 15:20, Albin Otterhäll wrote:
> I've eight different templates (copies, etc.) and administrate
> them takes quite a while. How should I streamline this and make it
> as easily as possible to update and install applications across
> several templates?
>

Personally, I found that the vast majority of time I spent
administering templates was spent on keeping them updated, so I wrote
a bash script to update them and set it to run periodically as a cron
job in dom0.

And what happens when the update process stops for some reason, such as for being unable to verify packages or for suggesting some manual steps?
 

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXYLQuAAoJENtN07w5UDAwvDQP/0KA3aa/yzjAShvQRgXMQDFQ
xDxVzCyhZ40RtmPAv/Zw+hp+tq5K2optikX0dYKlHo4PPi+MV9w42K81bK7P20kY
nfFSaAX5VzZL5iXeVKFlBwKkRCj5VcAj2K+t2lE72uFu276R8/3WGCsR2uY5YAJz
CVj2Oypqdu31TR17wBUwO9rUpYKD8mUp2aAOcDG6DT/T/Vxo4N6B+EWYh0RQufxc
IHaf5jGXUh9LJxmt3GOvr7ghGrvqjHbfrz1VkbeSni7lCkuXNsjJ5Ds4YTGtZmhV
r87cS191aSLDwFHgzYsv/LM4EgDDTsvUdxzJ/IStASjCjA6FA8l3h2H78lNzJ4g8
yaAHTpPRf9S8ybH0G9+ija/9BaCxEVIBcPbKKXRAF5yAuVvXQRO08qBrf65JwE5u
MK4oASN12bcW6ZGJBErRif9RM+4+dOM0gV3Jrrxqakk6MOAz1iDSTFj0OZrdjA6v
Wbr7f+J1Ql121wrfsA7vPlPV21WKbaI5ubFU0jyHcEq/MaYpol+RRknm/syrddig
eCV0AqhZsyvMdcvNY+7jqi7cpBE9XDZexVIRVUIiygOqtohUx6nfZa8LUseUlkOd
nJ5OUL4PqcqJ5RuPTAYco2IVmAMioTVjKTdZkf9UYrvVpDcYZpZ2JbBgviqk/X+L
SxHYeHCtFhSQv4rpNuCz
=Dtov
-----END PGP SIGNATURE-----

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4e627f7c-872d-66dd-357e-3fbb79ac8831%40qubes-os.org.

For more options, visit https://groups.google.com/d/optout.

[Andrew David Wong]

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

On 2016-06-15 01:56, Franz wrote:
> On Tue, Jun 14, 2016 at 10:49 PM, Andrew David Wong
> <a...@qubes-os.org> wrote:
>
> On 2016-06-14 15:20, Albin Otterhäll wrote:
>>>> I've eight different templates (copies, etc.) and
>>>> administrate them takes quite a while. How should I
>>>> streamline this and make it as easily as possible to update
>>>> and install applications across several templates?
>>>>
>
> Personally, I found that the vast majority of time I spent
> administering templates was spent on keeping them updated, so I
> wrote a bash script to update them and set it to run periodically
> as a cron job in dom0.
>
>
>> And what happens when the update process stops for some reason,
>> such as for being unable to verify packages or for suggesting
>> some manual steps?
>

Then it'll just fail to update. I log all the output and check it
periodically, so if something requires manual interaction, I just do
it manually at some later time. Most of the time, no manual
interaction is required for standard updating.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXYRyDAAoJENtN07w5UDAw54IP/RVMCtWrMMBuDTHvrOtZj0UT
12ByZKJ60l3QFvdg1rzrYP2/8d8LEvnMRGASrlJorP9jdnDe34gL5AgyVo6RGOE4
jxdVIVlhGgqQA5jEgWwRUXlw78bTrz2wHRIngu7AA2hlpLYbXz34qZM/KfzfdZcR
pSR+ikUmjRubgBrLB3BbPGQGSQ+TCpJb33J/Bw9tWliaZEQQFBMvxqehlAAm7Dhf
DyfSwL9CMjWuNxUl2aZszUHtFx8d9vWpFHwDqRPWQrdMYEspeYNaSZ9n3FXetv2+
yWvqoGs8w66CfAnV8Eu1KuGfTObThc/KANKp1XtS4eF52LYBubpt1hjpHrNn2ty1
VoMdXmt0iXRElyrQSJBlqEGhDvym/ryP0T2tGQXgE68U/eIgHCQ/V4W2LCyCUSgl
IStlu5rUqL19F79LrLPwR0SIbENetGJhMEIee4mNdJb+/Q2NAD0riNXW/lzfpfac
3toX+FcHyhK96LsQzDzjrcO875ZcFyrMM2eYQRCgpIouANMieltVH/rNmrqu/AGw
f22VJsmkomomsG4bFHOhZcUefOE0Uycp5+jApmBZPcz1LFpK/QJlfWH9TRqZfO25
DoTCv1LAPULpYESkSjTWAEYIDXx30QfNFcPAI2sGvBL79dKaBv3GStG0RnLemh/i
179lolujSts2J8Z6kMQz
=GSia
-----END PGP SIGNATURE-----

[Jimmy Axenhus]

Den 2016-06-15 kl. 11:14, skrev Andrew David Wong:
> On 2016-06-15 01:56, Franz wrote:
>> On Tue, Jun 14, 2016 at 10:49 PM, Andrew David Wong
>> <a...@qubes-os.org> wrote:
>>
>> On 2016-06-14 15:20, Albin Otterhäll wrote:
>>>>> I've eight different templates (copies, etc.) and
>>>>> administrate them takes quite a while. How should I
>>>>> streamline this and make it as easily as possible to update
>>>>> and install applications across several templates?
>>>>>
>>
>> Personally, I found that the vast majority of time I spent
>> administering templates was spent on keeping them updated, so I
>> wrote a bash script to update them and set it to run periodically
>> as a cron job in dom0.
>>
>>
>>> And what happens when the update process stops for some reason,
>>> such as for being unable to verify packages or for suggesting
>>> some manual steps?
>>
>
> Then it'll just fail to update. I log all the output and check it
> periodically, so if something requires manual interaction, I just do
> it manually at some later time. Most of the time, no manual
> interaction is required for standard updating.
>

Would you mind sharing that bash script? It sounds way more convenient
than manually updating all the templates from the Qubes VM Manager.

[Unman]

Since no one else has mentioned it I'll pitch in and say that a caching
proxy is essential. I run apt-cacher as the update machine for all my
templates. Saves time and bandwidth.
I put a redirect rule in the nat table to redirect anything to
10.137.255.254 to port 3142 where apt-cacher-ng is listening. This means
it's easy to switch away from that proxy if you choose.

There's been a discussion on this here:
https://github.com/QubesOS/qubes-issues/issues/1957

unman

[Andrew David Wong]

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

I'm sure it's suboptimal in many ways, so if you (or anyone else) sees
room for improvement, feel free to let me know. :)

As a GitHub Gist (with some syntax highlighting):

https://gist.github.com/andrewdavidwong/d0b109186de65835255d467ae103c289

As plain text:

##########

#!/bin/bash
# Set the updatevm.
updatevm=sys-firewall
# Declare arrays of VMs to be updated.
Fedora=(
'fedora-23'
'fedora-23-minimal'
)
Debian=(
'whonix-gw'
'whonix-ws'
)
# Proceed only if the UpdateVM is running.
if qvm-ls $updatevm | grep -q Running; then
echo "Starting update process."
# Download dom0 updates.
echo "Downloading updates for dom0 at $(date -Is) ...";
sudo qubes-dom0-update -y;
sleep 5;
# Download Fedora VM updates.
for vm in ${Fedora[*]}; do
if qvm-ls $vm | grep -q Halted; then
echo "Updating $vm at $(date -Is) ...";
qvm-start --no-guid -q $vm;
sleep 3;
qvm-run -a --nogui -p -u root $vm \
'dnf -y --refresh upgrade';
sleep 10;
qvm-shutdown -q --wait $vm;
sleep 3;
fi
done
# Download Debian VM updates.
for vm in ${Debian[*]}; do
if qvm-ls $vm | grep -q Halted; then
echo "Updating $vm at $(date -Is) ...";
qvm-start --no-guid -q $vm;
sleep 3;
qvm-run -a --nogui -p -u root $vm \
'apt-get -y update && apt-get -y dist-upgrade';
sleep 10;
qvm-shutdown -q --wait $vm;
sleep 3;
fi
done
echo "Finished update process at $(date -Is).";
fi
exit

##########

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXYuCYAAoJENtN07w5UDAwCR8P/iTbzgmV565vwtS6b9E+pAq7
TMvK2mRECwvhbuqSOCmCQqIkxXHkgjMfWUWRZowxA+BmmeS6fhUbQFiF7k/XoS/Y
D5uxP9txtmAlyFRQGtGvlylG9+0QzSfaGHyxxabJcbEMlh/6NEs/BplpJX9CwqqQ
uf6YIXlNCkuaP4wDEMdLg0eUrKb9GwicdWTxL4SGjZ9wK1t3RzbTtMHghBAsdr6Y
opx655TpmPW/1oG+K+CgGKEu6e1QwBDhmusRl9AxKLOdDUq9cqxeLycK7CZ6fBXQ
G4Ptbl5wTfsaDKwDsmM/QAoaC0BtkTjgwZmCvVT9YFcDz4+WClMRuL6mS8Ftx/cl
nF5xXaKg2F+sM08lZSAU2SvNlmJFygMGlbNFQpPatxw1KH/w4tXGguQFrrUQFzMm
pn8P7ThZSuCrCQ5xj3t1LRJFQuK712sGiR2xzlY9VB32uCr4YC+27Cm1IftGhoLM
ogo7UseqeiybPkpjB3JFOvXqMHvf8n//aeCs/ZIIUheWD2T1LCCd2DeRZ/rBiesX
XRsuwKJA+zAFh89MN+BRwYRf8elNVkLolM83++MSqA28BzkSrGbDes/SmG8svRUN
gNxIOsnzs04tvFyuoMmIeRrOBMDwBm7gbuBUkBJWyTBfO/SBF/NdMRil2k2C9IJI
JKZfz/5hkCQIaQpqprpZ
=o+UX
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

In upcoming Qubes 3.2, it could be handled using management stack. The
configuration would be simple:

/srv/salt/update-templates.sls:

uptodate:
pkg.uptodate: []

/srv/salt/update-templates.top:

base:
qubes:type:template:
- match: pillar
- update-templates

Then enable the configuration (need to be done once):

qubesctl top.enalbe update-templates

And every time you want to update all the templates, simply call the
management stack:

qubesctl --all state.highstate

Disclaimer: I haven't tested above - there may be some typos.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXZFazAAoJENuP0xzK19csAzYH/1iGK4YjEkhKbDngvt2bQwrX
LzZbnd3gQMp/dSFsxHPb/24w1kDakgdsjISnwXSkVuS2LbfxpCvNzyQvr1Y85uE5
WvQue6Nrx5jYnZamyhe5MMPxlqargnrWE0+/djVV9A2kd6cU3bR160Xxt/jTX8ec
Z78TViHX4wDKiXAztaDQEzlc1ti56nZEk+BkhKOucfrGK+NCHuVU4WJbg9R+axU8
js9hvrofpi7QVB6XaqAA05dIfxkcIxYIjNnW3BTSL9kc2M4/CmdZBfXSwlemdIMS
MwJjE9Hq8rc/PE6SktZcLi9bYn7qwgHNKEHB97Q2jLwmLgiyxwKnZfl1v6csR2A=
=sb1D
-----END PGP SIGNATURE-----

[raah...@gmail.com]

But what if when it says it can't verify key ignatures possibly? Will it automatically hit Y to continue? I wouldn't like that. Or what about any possible error messages? I still like to see the text on the screen.

[Andrew David Wong]

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

The last time this question came up, the answer was "no, it would not
automatically say 'yes' to installing a package whose signature cannot
be verified."

If that turns out to be false, then I'll have to assume that all of my
templates are compromised.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXZMyHAAoJENtN07w5UDAwj5UQANDKFUZBm+CyfVIGXRN6MbAF
EnN+qEkkaxOyLsSlPVxswLOjdz82HcumTrY/cGUFJlnj49FJvzQLC0Tp4YJrY6eA
6U9NaApknhZzDeoxrEP1uYsgSBRBcCKcQmYISvg47iiIhRgr1771f9S5yU5Ls+E5
/+E6Pj3FMIyxkH1/jrbVb+9QbkfUBG2WVm0mggWe6FKCfUXAqP1zu2hd98lyXUGB
RdmTsXHd4sD2SVfbGjVUKpLseO7LirBZyHUb1+GG4k9Oz7cmQLNpDEClwc4BEJK3
lX7v14/uvnOoU4Eu+MXaksdsHQKW91BOuZaD8xw/RyvaYK57QWu3+dlkVdE2kQvw
KEEWnl9GpoPld8nXKafr4dW80geduKF90vUtzpoU0niqzb6PI9nsy/bCzuNh7jIt
Uhou28z5861370eV7OWOX8qzQ2anhpXIM0Gmsyu8kRL4AGxx3fk0uX+KiISVTaQr
GaYCcmHnh5N7jpmYAXrNF1PFmqCXXkoy3MgvUYQ0peUzY8H5j0YKpFLRmz1W7B6Z
hQXzbLMvBdrmCwZ+3b0ub3qsA4kUFs7vTuQ60zaGMtKdYZLKBasKtSDqDDjFcLLJ
bAaiCmBAsRze+bbeXiT1MYvUG32OVpHdfaDO61xsy9qEIcSj7HM8XJjXqVLdOuTs
Dm6OPmyDfGA3J5UUjw0b
=ICyK
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

On 2016-06-17 21:22, Andrew David Wong wrote:
> On 2016-06-17 18:02, raah...@gmail.com wrote:
>> But what if when it says it can't verify key ignatures possibly?
>> Will it automatically hit Y to continue? I wouldn't like that.
>> Or what about any possible error messages? I still like to see
>> the text on the screen.
>
>
> The last time this question came up, the answer was "no, it would
> not automatically say 'yes' to installing a package whose signature
> cannot be verified."
>
> If that turns out to be false, then I'll have to assume that all of
> my templates are compromised.
>

I decided to test this, just to make sure. Here's how I tested:

1. Installed fedora-23-minimal from the Qubes repos.

2. Inside fedora-23-minimal, renamed all the keys in /etc/pki/rpm-gpg.

3. Erased all keys that had been imported in rpm with this command:

#rpm -e --allmatches gpg-pubkey-{hash}

(Repeated for each gpg-pubkey-{hash}.)

4. From dom0, ran this command:

$ qvm-run -a -p -u root fedora-23-minimal 'dnf -y upgrade'

5. Received this output from the template during the attempted upgrade:

warning: /var/cache/dnf/updates-e042e478e0621ea6/packages/sqlite-
libs-3.11.0-3.fc23.x86_64.rpm: Header V3 RSA/SHA256 Signature, key
ID 34ec9cba: NOKEY

Curl error (37): Couldn't read a file:// file for file:///etc
/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-x86_64 [Couldn't open file
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-x86_64]

So, it looks like using the '-y' (assumeyes) option is indeed safe as
far as PGP/GPG signature verification on packages is concerned.

If anyone has reason to suspect otherwise, or sees a flaw in this
test, please do let us know.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXZQlPAAoJENtN07w5UDAwl8wP/2hMicgBQDzzpDZtCxFy2Nkn
cdsMJZU3c8YpaqHqLyjoDrP26khdFF7Fjmpq8flLP4JqU7cRP6e8gQt9WAGIp9hM
9cEpvx93g1CDXhJgBTmP0Pc8tu/U1VzYhhcCzqsgDcAtK6K/tch4T1SKoTVkMbwr
+JbQYx826g/wUiwbGwaNBIZExfnu0cKhVK/4iwvuKUSpTNA5LUnMIZlmr3e6mpWy
gwyh0EFOMx9mwQ7gPvha60U/QN/skKDBHJeNjeuWm8IiucDIndrfS4FPhJcmFwbh
zN8aiNWQ/XFo0y9xXD5yf8nJEoI5/jidnkoyCiJA7Q5FxgDuB0jHOCJsSX1ExtOJ
w/Vo0jk9NSyUIRSVpuJpLEV/w9RkuPkUZ4Lxqp5ck8Na00FgVjc6wlYkS+imcng0
rEdutSRtDMlO8bjxCSSYdsMxWTHtd8DZjwzkAf2/c0ss8adEvM/9/GwpglJNSAoL
WDVuMEQXfkrc1xcA7kh0TOHQ7b2Av+Ya0pzb7e9uPFGU6HsO50qkkXR0XNPfGrAy
1QUSHUsODgc9dSpfX9epaml41uUu1+/z/TULBVJ5l9W0XD8hXcDuPVXHq9ySRQ/o
s7biEIG2ImTiw5icKY4gQeiHh9KqDfIIpeGDdvKYZOOp2UHlMoKIvjVdzF1wwk0s
PmobBE37547Lu3xmX5Pl
=Lq0y
-----END PGP SIGNATURE-----

[Andrew David Wong]

Just to clarify: The update simply aborted after this. DNF did not
install or upgrade any packages, and no entry was made in dnf's
history log.

So, this is something that you'd notice only if you occasionally
grepped through your automatic update log (if you do automatic
updates). But at least you'd never automatically upgrade any
unverified packages. At worst, you'd just not upgrade any (which is
why it's important to check the log once in a while -- to make sure
you're still getting updates on all templates).

> So, it looks like using the '-y' (assumeyes) option is indeed safe
> as far as PGP/GPG signature verification on packages is concerned.
>
> If anyone has reason to suspect otherwise, or sees a flaw in this
> test, please do let us know.
>
>

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXZQtaAAoJENtN07w5UDAw2XwQAJTqCov7GOd8PKcMuWxxZffN
ho7wkrFdxziaj5Gzah03C1GDq1y7arl/5BQiTwzC3pCh4RyXXPA9ieVTzqexFC1M
YW5OyLWYpgRIXBqv0KlNV3hBMAQJDD/POQkzSEsyk3OVqQr2BjY1PR5pG0EhbMPn
NBxX1aNdj3mUMzrAbwg2sSRbQrpm0ppkl2rNqKq2Gig1q+xdOzAMsUwmF2Jzn/8n
1vkMabfTZNA/W+x7R1pbA2kHu/+75dC2VhC8NDAe/SMAEL16h/ncvwRalMGfTorG
OdFXA8rwzB4pf52X0mYo5QvZM8JRAn2DNk836HZ5bROmnGQwNE3ZDk94DpvLp4zK
wgQzRV2YqbcAVW3hA6/Y6rSoo7bBX8szsVKYZctfV3nIDHgxyqMb6aUelzfbFkXm
YAknG4SeCn0henU6Tbiy7FYQkxfyi6wSG7EghIyTKdG7C6mUKcIgd2+aEnkbhc2x
tzIuSCgksHl2sMTPcr7t0YqeoP3M3msruCTdew4/y89msGjp4M2hlJPtLfIasB+W
0b+C/u3dWRXXJWNi32r7R3/DuUhsdox46ElK2fzYufl58qk3znkk+HDNpJxLescs
aUttCjIj5GjtoerhEmyWjCUbj2Teyq+E8rDqrzd8k67d1yE0Y5nnqa7lK7oX4O2Z
huvqtVEZA7ZOvl/zbTq0
=9QLp
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Yes, it's safe for yum/dnf. It will not allow unsigned/wrong signed
packages to be installed unless specifically allowed with --nogpgcheck
(which you should not use!). Even -y isn't enough to force unsigned
package installation.

Even in interactive mode it isn't possible to install unsigned packages
without --nogpgcheck.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXZSrIAAoJENuP0xzK19csMwYH/iU7hU4u6bUKp+4DAnBtuca7
hXrQZOVfDOz6PetmITTewixaQLM5O0SYGc972aJdLPmnXuLLws5LFbHVCVtNEejC
FM6XNVK8+A1wCpCYFiURnrCy4eAUbgBxRp2eQ/vvLKyEuDQ+U53862QFVK0q/aC8
OFpHAXzb2Q9TRlh6VdfbnWiRKYjLhIacPIF36s1LtwtRTVyzfue8ELNlzl0QAfKp
wy0Hqdc7zmCp1qUwEw+dUUiZwsvuOmTX+S/AamFsNGy90dAjspHQb9Gh8jJKz9R2
HIPEqjANhtcEuqNn7coOuFxL0/MW9eY1qgoGAYcDEySUs95RfQLuw9Rzy76kUZw=
=WvdS
-----END PGP SIGNATURE-----

[Andrew David Wong]

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

Thank you for confirming, Marek!

Also tested on Debian. Basically the same procedure and outcome as
with Fedora:

1. Installed debian-8 from the Qubes repos.

2. Inside debian-8, moved all the keys in /etc/apt/trusted.gpg.d to a
temp directory.

3. Erased all keys that had been imported in apt-key with this command:

$ sudo apt-key del *

4. From dom0, ran this command:

$ qvm-run -a -p -u root debian-8 \

'apt-get -y update && apt-get -y dist-upgrade'

5. Received this output from the template during the attempted upgrade:

WARNING: The following packages cannot be authenticated!
[...list of packages...]
E: There are problems and -y was used without --force-yes

6. apt-get aborts. No packages are installed or updated.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXZSuYAAoJENtN07w5UDAwM5EP/RIjKzZLLHNPkyH33+yxCM2I
TNqgdLlmS7/q2X3nRQgmS6is8chjh8mfrm+a2c0mPajcZuWtK9e9NT76gE7+bBq1
Y+bQDWnd4rSLNJoQ9stiHsLQh6sr/8Lq8905CcvfORYjd2DosJB0wgVONuGPP61v
N8/HEGZCauoXzXzVmQV6UH9rqzJ2Gxsjy0G/lm8onKcXU//ZxX3fOtVmB/Q9dHge
Z9UPIIba3EmeyBmyzai9vrAMgHqe7ozKYGJ/m+B2xrG/HztsH+YwcBN0umzyESNx
MelnYM2qMBiNPp9RgaJSpf8elM0U6rgk+W7mx78CvYNutSo1CS3g1sxMOnecrq6k
h2uJCC89Fm1AvDt6lwyQvRQnL/MfElEbxHmQrSo3b0Tml8ej1CCvXshi31AOB4/k
jWvVTud7BRFvi9d4zI48IOLQHpUbDo6sqWmLzaFiThKd1KWYUhhnhc+s6b8moCiC
XAWqHY3fEplVrak+JUqggFPO8ho054lmHYPoccEEtBhkaJRt+Oh/Xs5PU5+Zaxc8
9TroEAI2blXkJpg99T8mN0qCfcFx364KFZfTYW6naD3vHYFZ8jiFOsHMUA3CXTjw
x9YwQO3UixCVviPYFLklh72MSC/E/69FN098067vTbtJlcxgtY1FNgyazmpJ3ihd
WQEmk3AlqKfR25BzW11o
=hjqV
-----END PGP SIGNATURE-----

[raah...@gmail.com]

tks for confirming.

[Jimmy Axenhus]

Now it's my turn!
Inspired by your script and the fact that it will probably be a few
months until Qubes 3.2 is released I decided to go ahead and try a
cleaner version of it. After looking at how the VM Manager does it I
ended up with a completely rewritten script in Python. The difference is
that this one is interactive (I prefer that) and it's starting them all
right after each other. In other words you might get a bunch of windows
popping up.

I have no idea how stable it is or if it's going to work in Qubes 3.2,
but it works fine in 3.1.

License is CC-0 or GPLv2+. Pick the one you like.

https://gist.github.com/JimmyAx/818bcf11a14e85531516ef999c8c5765

###

#!/usr/bin/python2

import subprocess

from qubes.qubes import QubesVmCollection


if __name__ == "__main__":
qvm_collection = QubesVmCollection()
qvm_collection.lock_db_for_reading()
try:
qvm_collection.load()
finally:
qvm_collection.unlock_db()

vms = qvm_collection.values()

exclude_vms = ("archlinux-aur", "archlinux")

processes = []
for vm in vms:
dom0 = vm.qid == 0
if not dom0 and vm.updateable and vm.name not in exclude_vms:
print "Updating VM template %s..." % vm.name
if not vm.is_running():
vm.start()
p = vm.run_service("qubes.InstallUpdatesGUI", gui=True,
wait=False, passio_popen=True)
processes.append((vm, p))

print "Waiting for VMs to complete updating..."
for vm, p in processes:
p.wait()
vm.shutdown()

subprocess.check_call(["/usr/bin/qubes-dom0-update", "--clean",
"--gui"])

[Andrew David Wong]

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

On 2016-06-23 13:02, Jimmy Axenhus wrote:
> Den 2016-06-16 kl. 19:23, skrev Andrew David Wong: On 2016-06-15

> [...]

>
> Now it's my turn! Inspired by your script and the fact that it
> will probably be a few months until Qubes 3.2 is released I decided
> to go ahead and try a cleaner version of it. After looking at how
> the VM Manager does it I ended up with a completely rewritten
> script in Python. The difference is that this one is interactive (I
> prefer that) and it's starting them all right after each other. In
> other words you might get a bunch of windows popping up.
>
> I have no idea how stable it is or if it's going to work in Qubes
> 3.2, but it works fine in 3.1.
>
> License is CC-0 or GPLv2+. Pick the one you like.
>
> https://gist.github.com/JimmyAx/818bcf11a14e85531516ef999c8c5765
>

> [...]
>

Thanks for sharing!

(I also have another one that updates all the TemplateVMs
simultaneously, but I prefer updating them serially when running the
script as a cron job to minimize resource usage.)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXbMQzAAoJENtN07w5UDAwurcP/igS2uVDTd+wdQCMmYvXUlIR
QvUqzs3GBrEUwz7At05kEUHYW7q/IkxMddGIzJcAub65EnAYZl3L+vDEB5lVpDCW
1G6w7BWgX3TDIxfCSh8wVF1/Pg3uo8Wc0JFlR1XAEqlSIYWZNQs62fdfvju7Y3Ix
iYYnGJS3d54hcIrwjxVKNu+yGx8wLXefYDweU6+/hgC3mGbE2bhzbQUAqERNER2h
ls5vAsPzBktSlX4jjQUNaxWgt9UmAuCYF06MyT38IYV+2oEdDP95dRbdKFxw8ALw
S4KrTe0gp1KpiYmEZAmCCzbP0vHaGQu4VMpHlwu0q1tI1Ljc79gBW1cqkSTAkrYh
Ud5AOshLiMzwbArV2NOV6xE3nuJ3MFkdm+ydyOb2+NuTOPrYwQoSTfDtenUGnzD5
RcSbQX1RdOuMTuL6gVyKPJFpvbsF4eTzvLd3uYZWlcqtUMk4UdaoLZlMP5gQypuv
wX9OWXgf0TocMY8BLu4QpOAp+CdCASKwCQbX26CdjM27vnyzeBkc2OMr8FZ3XtNj
VgUhCEYRV4g3JBcEIJsppNz36YSqYo/ELJI3CT3mxfvzveRNS0B3e00hs8xDE0ct
pptN80JFiCY9C2zKzbDRXk5g1zagj4sJIP1YJu8k66Qyaj1S7AUEbO6TVMn4Xlgq
P2uF7vJnRwW73x8BzMHT
=14zX
-----END PGP SIGNATURE-----