[bug][security] Qubes repo metadata vulnerable to MITM attacks

[Joonas Lehtonen]

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

Since Qubes repos are apparently less safe against MITM attacks
against repomd.xml than Fedora's [1] I'm filing this as a bug.


Potential fixes:
(1) do the same as fedora does [2]
or
(2) serve the entire repo via HTTPS
or
(3) do it properly via repomd.xml.asc/repo_gpgcheck
or
(2) + (3)


Thanks to HW42 for bringing this up [3].

[1] https://groups.google.com/d/msg/qubes-devel/39k347Du_D4/QkIzWdV4-k8J

Background and reasoning:
https://lwn.net/Articles/327847/
[2]
https://lists.fedoraproject.org/pipermail/users/2014-August/452705.html
[3] https://groups.google.com/forum/#!topic/qubes-devel/39k347Du_D4
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT8JVpAAoJEG58zmw5nc+vXP8P/2NwjM+7UnbLxGl5mjXasqHV
tx3DxJJ/Y3ooevmGAi6su3Dz/bK64NBEjgjxUJndOuxBFRI4hx/jIl/rNRgq3PvO
/oDYWz0klPcu+RIMmTMEdb/Tjw5zMobOTk6pzJZ9PD9uD7fQDPs4pzYbjdTSWkTw
hQdFvq418yCCuv6E1Q0/HBylQCdfybSTSru76ZVGmVEeRnyP0izHMvnWU5H7+JVd
4NX97FoKaxqXzxw9D8LNxJp7emS5PhiHqiwzbJyqe5qxmN/aXQNrcTgk3QcuuotP
jgnCUH+ilycsKyUCCxH/Pb35w1h0I5Q0mzde4rX8vpeq3Aqs/ETFXqx0C5Ss5VQf
E1k6BEBJWyuPqnc5HPs2Cmpx2Ht3m6eXynDVODWpzXLuygaMi/PKzweLjSe63k+W
TlVleglbj+uxecYZC62IhDEsuWZrEpTu7r+QY91ZuJ7sz7R8iHeB2VxxVvvdRzLE
wdh6TXh8PCulyF+mCAYL3cCAGPulFG7I8n1U29DrHKPsa+LsHk3S15iMDbGIefA9
TDSigfqlvzJxwhsk1O73vDnSAS+ZlMOIXE0EJMdpTb46Tw7gLDT+DbRO/3/PCk3M
QBj8iLALp5R1En1tlZpFqE9P4U2DWhlWvAAKpnyn2safVGFZO1Z0BSTR3C3ZD+UN
UY7PvcOn4ZBxiCb4r+pf
=urE6
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

On 08/17/14 13:43, Joonas Lehtonen wrote:
> Since Qubes repos are apparently less safe against MITM attacks
> against repomd.xml than Fedora's [1] I'm filing this as a bug.
>
>
> Potential fixes:
> (1) do the same as fedora does [2]
> or
> (2) serve the entire repo via HTTPS
> or
> (3) do it properly via repomd.xml.asc/repo_gpgcheck
> or
> (2) + (3)
>
>
> Thanks to HW42 for bringing this up [3].
>
> [1] https://groups.google.com/d/msg/qubes-devel/39k347Du_D4/QkIzWdV4-k8J
>
> Background and reasoning:
> https://lwn.net/Articles/327847/
> [2]
> https://lists.fedoraproject.org/pipermail/users/2014-August/452705.html
> [3] https://groups.google.com/forum/#!topic/qubes-devel/39k347Du_D4
>

As Marek and I explained in the other thread you referenced:

1) Mere signing of the repo doesn't really solve this problem, because
the attack surface is not signification reduced (again, see the thread
on backup design, and that was just about gpg, what about the rest of
yum networking code?).

2) HTTPs is also not a good solution, because we don't want to assume
trust into our servers.

3) If you're really so worried about this potential attack vector, then
I already provided clear instructions on how to install updates much
more securely, i.e. using the same approach we use for Dom0. You can
even do that manually: 1) disable networking/repos in your
super-sensitive template, 2) run yum --downloadonly in e.g. DispVM, then
qvm-copy the rpms to the template, 3) run update repo and yum install.

Perhaps you might even consider scripting the above and nicely
integrating with qvm-prefs, to allow the user to manually opt-out select
VM(s) from networking-based updates and use Dom0-like-updates (albeit
with the limitations pointed out by Marek recently).

Something you could do between writing bug reports to the ml ;P

Cheers,
joanna.

[Joanna Rutkowska]

And, of course, you can also maintain your own repo with Qubes packages
(which you can build from the sources) and expose this repo to others.
You can even build your own template for Qubes which would already be
preconfigured to use such repos, plus other hardening, etc at your
discretion.

This is strongly encouraged.

joanna.

[Joonas Lehtonen]

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

Joanna Rutkowska:

> 1) Mere signing of the repo doesn't really solve this problem

Since you are likely talking about another problem I'll try to be a
bit more specific which attack scenario I'm talking about:

An attacker is sitting somewhere along the path between the client and
the repo server. The attacker wants to prevent his victims from
upgrading to a newer version. He can achieve that by manipulating
Qubes repo metadata in transit, since it is not signed. Signing
repomd.xml makes manipulation detectable and addresses this MITM
attack vector.

Providing repomd.xml.asc would be the better solution, but providing
repomod.xml (or its hash) via HTTPS is IMHO still better than
nothing/current.

(There are certainly other things that are not addressed by signing
repomd.xml.)

Fedora addressed the MITM attack to a certain degree via HTTPS, Qubes
does not address this at all.

> 2) HTTPs is also not a good solution, because we don't want to
> assume trust into our servers.

Are you really saying that using HTTPS would *decrease* security? ;)

> 3) If you're really so worried about this potential attack vector,
> then I already provided clear instructions on how to install
> updates much more securely, i.e. using the same approach we use for
> Dom0.

Dom0 is also indirectly affected by not getting updates.
How is UpdateVM going to provide updates to Dom0 if it doesn't even
know there are new RPMs?
So I don't follow how this is a solution to the specific MITM attack
scenario described above.

> Something you could do between writing bug reports to the ml ;P

It was my impression that this was Qubes standard procedure to report
bugs to the ML (unlike other projects which usually have public bug
trackers), if that is not wanted please let us know.
https://wiki.qubes-os.org/wiki/BugReportingGuide
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT8L16AAoJEG58zmw5nc+v1iEP/2xS3pf8uE5RU1Q8B2uGNtFE
63y+SGkkBih3aVpj5gqmZNWf9f/h71iLbtWJ57wmUcTTNT0dFurALq5GDIZRO2u4
cQ0rO5Uvt3/x56HbIpI3DGCcDYFha5wekOYkaJgcqJi5iqoTEaEufWw7IPHHtONL
AlBoQqivOrAuLjX9xiQL4ULgVrnRjcJzG3nzCFRX3oxyXjKZGG4rdc/n2nxDZpgI
TVNWnIdKj+80sH/zvI9cEbQuw4N+aACAOopRXWWRg8wX8q8fJDKSeicHd8PkqQju
/Nz3A2USLpj8ya7Z+m0a0iEHgi2keyRiu/xShg50dOhYt3ZW0ogFMngL8oFIKH91
vmVMPBOkl/QWlwnUDGOm0HxffF+UwkIVAgQygw4mnNCmG3ZdxSJwIQ9+RhDZ43zU
zOrxmRsnkjd+Iyljy7wZhRldhUM/ChUkCKsHJRKm5kLxkRiBByCwGo9s84euRbnS
wuzsYDBz6h+5JhU70EjgTfJuBNsLDiy/pSalqCWwI+TwjSSZk8ab7Cfo6XO0Q7jS
mFh8PGHwUgTxTZ9/lYb/2pgWZ9IrI+Pl2KujdJE+8jKWja8oJBZTq0654e2oHoBR
dvF3CHYZBmNHTh6gZMRb6nAfdMVCbj+PB2jXLQsNbNwZFDfDAjaXiiPg5/SrUGZr
Y9U437R7jmdkoQtkSYas
=Xniq
-----END PGP SIGNATURE-----

[Joonas Lehtonen]

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

Joanna Rutkowska:

> And, of course, you can also maintain your own repo with Qubes
> packages (which you can build from the sources) and expose this
> repo to others. You can even build your own template for Qubes
> which would already be preconfigured to use such repos, plus other
> hardening, etc at your discretion.

"You got a bug? Go fix it yourself!"


Thanks for the clear message ;)
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT8L3yAAoJEG58zmw5nc+vpk4P/Ays+l0skeHT23EL9M8fvUmZ
Bk+arfE4EreiKxmkLWdPDH9vwNoA2Co1arKKi9gltJbfM5N7S76nRO8FpgtIFHAj
h8fDAigtWf2H5URjK42nFQ0bPVIT2SMSc4sGrVgB0/9FttluVWPm8IutWjvSm9Mz
sQkNSkHIBqKKcNphArTY1TzaxwgBh6hl2uNWvdShJGhGaribrLdxff2TKWOl5fML
eZ/7uJFkbL8rAOSak9twjTEWGOP1nsVg4sOVK7z2ufLM6X4NDlurPAFCAN5ZL/WG
oisMpGr/9ASaSqlJx9IlbfHz1mbTYgaKFNTKjc9JwqiRtW51RWJ47oJvFDzWqkDj
eYpsSh7SsIJlxVnLQLDT3qm8zDUEd1ETSGxjRwZd047R+Bc0UUJCECNPDn1+Med7
wDIW8/dbsHVj/Sq8W2wx2+bSmlzOxaoEGoqhVJP+BMZ8XR3T6tOnT4c53VUEKe0f
myGO3Laum6XUj234LK5Ai7ElUDOYNHTDkrTqzXVbjGQO1j7hoMLOcq3uCSuY5PyW
9eepbDQHe7bzSKmv/sfpBPRYqAuzgZVkqfB1+kMGLBgi/acTKYXI13kmhmGCQgTF
a3ARWFYQByXv3/SGswF7jmRSCMU4mVD9SgNgTvtdRBSTjecC72gVNLlg0g7oWET9
izbocVre/tUn5icUPNSW
=HfG/
-----END PGP SIGNATURE-----

[Axon]

Joanna Rutkowska:

I'm a bit confused about why this is a security improvement over
downloading the updates directly.

If I download compromised RPMs in a DispVM and qvm-copy them to the
TemplateVM, then they can still exploit a hypothetical bug in GPG (or
whatever) compromise my TemplateVM, right?

In addition, if at some point in the act of downloading the updates my
DispVM is compromised, then I could unknowingly qvm-copy malicious RPMs
to my TemplateVM, right?

So, this appears to be a separation of tasks with no real isolation (but
perhaps it only appears that way to me because I don't understand
exactly what this procedure is designed to *prevent*).

Most importantly, my DispVM is itself based on... my TemplateVM! This
has several implications:

1. My DispVM can't be more trustworthy than my TemplateVM. (So, it
wouldn't make sense to think of my DispVM as a "cleaner" VM in which to
download updates, but I doubt anyone was thinking that.)

2. If my TemplateVM gets owned, then my DispVM also gets owned. (More
precisely, every DispVM which is started from the owned DVM template
will be owned.)

Combine these with the corollary of what came prior:

3. If my DispVM gets owned, and I qvm-copy from my DispVM to my
TemplateVM, then I should assume that my TemplateVM has also gotten owned.

And now we have a vicious circle.

In summary, we try to save the TemplateVM from a potentially malicious
update procedure by delegating that procedure to the DispVM. The
malicious update procedure compromises the DispVM, which in turn
compromises the TemplateVM (when we qvm-copy from the former to the
latter), which in turn compromises new DispVMs (which are based on the
TemplateVM).

I'm guessing there must be some flaw in my reasoning here. What am I
missing?

(For similar reasons, I'm having trouble understanding the security
benefits of proxying dom0 updates via the firewallvm. What are the
security benefits there?)

[Joonas Lehtonen]

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

Axon:

> I'm a bit confused about why this is a security improvement over
> downloading the updates directly.
>
> If I download compromised RPMs

Lets not mix things up here. This bug is about unsigned *metadata* -
repomd.xml - not about the actual RPMs (which are usually signed).
So an attacker can say "no updates available" and you won't be able to
tell whether that is actually the case because that information is not
signed.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJT8QwnAAoJEG58zmw5nc+vaakP/3P5RMkwQe3CBwzr4cmBbxiX
ns2CV7XUgq7Y1K6/wEEtpz8ZfadINXmbjRFL4876TIpXjiSLOlWZKZwc7himv2uI
SySdk34qLCi/JAELUtV1mbBszYLFzS9hxL+ExHqhaQ24jgRO60Ivgbiz3ps4NxUq
DR0XZmKaJF0vElnvQxeYYJevmJWNrgKjL2HPlDPf04HPBySbhJJpuh/meIkRD7mv
B5MgHKznCZgkmcxMl8qY0+PVOERtNwADEKh3z4txR+ELqpr2iG3QGSonkwx67yKV
rNv9dBsKaf7+hjmr7GdDdOx0sNOSD3Vv4b9duoPRrTDQP+1rijJX4NZIHC7DIXga
+QEROzvc7rm8EtmR7VLsbo4hMbk+6QDV3aPCp3WplElHOpPIbWIL/4n74ju404ND
AB/r3yUSGwimFs9f9wcZ+9rxe8Z41o4b2JJOngX8GTshRQnhX01JB/deseHz1Cbx
EJ1uTyPJDuMRXZEoSzr7rG/XVk8g6ZwiClxVAYzk9K98w7/KS6ufZrTUDCh2v/uc
w1n5fly6BhBUfs282ME7RRb9OwHkh9WcPjoA8RpKo419rLNVKJ9Tfox0k8908vd6
eljE+IW85+VuNZt/4WdMVOzPtHXQeZzd/lgzQ1sZzEQAG45NvIx6TMcPTJkeKom8
MTxhMCGGNzu8vEn/GZ8p
=GqqP
-----END PGP SIGNATURE-----

[Axon]

Joonas Lehtonen:

> Axon:
>> I'm a bit confused about why this is a security improvement over
>> downloading the updates directly.
>
>> If I download compromised RPMs
>
> Lets not mix things up here. This bug is about unsigned *metadata* -
> repomd.xml - not about the actual RPMs (which are usually signed).
> So an attacker can say "no updates available" and you won't be able to
> tell whether that is actually the case because that information is not
> signed.
>

I understand that. My post was on a slightly different issue. (Sorry for
threadjacking.) I was replying to Joanna's point 3, which includes

"instructions on how to install updates much more securely, i.e. using

the same approach we use for Dom0." This is a more general issue
regarding secure updating. Compromised RPMs can still be a problem
because GPG does a lot of parsing before verifying signatures, so it
could potentially be exploited with malformed input. (This is the
historical backup-system/GPG issue Joanna referenced in her point 1.)
So, if I download a malicious RPM in my DispVM (or dom0updatevm), it
might be "signed" in a malicious way which will exploit GPG. But simply
qvm-copying this malicious RPM to the TemplateVM (or somehow piping it
to dom0) seems to *preserve* this risk and transfer it to the TemplateVM
(or dom0). (The same goes for the yum networking code.) Hence my
confusion on the security benefits in these cases.

On topic (but still related to the above): Like you, I also don't
understand how the procedure in point 3 will prevent the "no updates
available" attack you describe, since it seems that the DispVM is just
as vulnerable as the TemplateVM to this type of DoS.

[Joanna Rutkowska]

1) Regarding prevention of "no updates available" attack -- I neither
see how signing of repomd.xml could solve it, nor I see how this is a
practical problem for current Qubes users (who should be reading Qubes
Security bulletins anyway, and verify the proper packages got installed
anyway). HTTPS which might make it a bit harder for the MITM "no updates
attacks" is not a good solution because it would bump CPU requirements
for our hosted updates server, which would translate to higher costs.
Again, because I consider this problem not very practical one, I don't
think we will switch to HTTPS for our yum server anytime soon.

In the future, when we will be offering remote system management
infrastructure for Qubes OS, such attacks would be become practically
important.

2) Today, a more important problem is a possibility for the attacker who
either compromised the updates server or is doing MITM on the
connection, to attack the network-facing and metdata-processing code of
the package manager (yum, apt, you name it). The only viable solution to
that problem has been discussed earlier in this thread: Dom0-like update
scheme. By splitting the updates mechanism into "resolve & download" and
"verify and install", like we do for Dom0, we minimize the attack
surface significantly, because we get rid of all the network and
metadata processing code from the TCB. Note: it's totally unimportant
which VM (DispVM or whatever) you use for downloading of the rpms.

Sadly we cannot do anything (affordable) about potential malicious RPMs
that could be exploiting hypothetical bugs in GPG --verify. We can only
switch between distros and package managers, but any could be viable to
same hypothetical bugs. ITL could write one, but the overhead to
maintain our own repos with "normal" updates for Fedora or whatever
distro in the template, is just unacceptable.

Let me repeat it again: if somebody feels like the updates
infrastructure we offer/use is inadequate, there is really nothing
stopping you from offering your own.

Unfortunately we don't have resources to address every single wish and
request of our users. We're not aiming to create a perfect security
platform -- we try to make a Reasonably Secure platform. We use our
experience and intuition to judge which features should get priority and
which we can afford not to work on. We might make mistakes, of course.
And that's why we made Qubes GPL to allow others to help implement
features others want and which we cannot afford to work on (or decide
were not-so-important).

joanna.

[Joanna Rutkowska]

On 08/17/14 16:36, Joonas Lehtonen wrote:
> Joanna Rutkowska:
>> And, of course, you can also maintain your own repo with Qubes
>> packages (which you can build from the sources) and expose this
>> repo to others. You can even build your own template for Qubes
>> which would already be preconfigured to use such repos, plus other
>> hardening, etc at your discretion.
>
> "You got a bug? Go fix it yourself!"
>
>

A more polite way of saying this, popular among many GPL projects is:
"patches welcome" :)

j.

[Axon]

Joanna Rutkowska:

That's a good point.

> and verify the proper packages got installed anyway).

Should we just use "yum info" to check the installed package version
numbers against those mentioned in the Qubes Security Bulletins, or is
there some further verification step that should be done?

> HTTPS which might make it a bit harder for the MITM "no updates
> attacks" is not a good solution because it would bump CPU requirements
> for our hosted updates server, which would translate to higher costs.

True. Easy to overlook, but always important. Making sure ITL remains
solvent in the long-term is probably the best thing that can be done for
personal computer security. :)

> Again, because I consider this problem not very practical one, I don't
> think we will switch to HTTPS for our yum server anytime soon.
>
> In the future, when we will be offering remote system management
> infrastructure for Qubes OS, such attacks would be become practically
> important.
>
> 2) Today, a more important problem is a possibility for the attacker who
> either compromised the updates server or is doing MITM on the
> connection, to attack the network-facing and metdata-processing code of
> the package manager (yum, apt, you name it). The only viable solution to
> that problem has been discussed earlier in this thread: Dom0-like update
> scheme. By splitting the updates mechanism into "resolve & download" and
> "verify and install", like we do for Dom0, we minimize the attack
> surface significantly, because we get rid of all the network and
> metadata processing code from the TCB. Note: it's totally unimportant
> which VM (DispVM or whatever) you use for downloading of the rpms.
>
> Sadly we cannot do anything (affordable) about potential malicious RPMs
> that could be exploiting hypothetical bugs in GPG --verify. We can only
> switch between distros and package managers, but any could be viable to
> same hypothetical bugs. ITL could write one, but the overhead to
> maintain our own repos with "normal" updates for Fedora or whatever
> distro in the template, is just unacceptable.
>

Ah, I understand the logic of the update scheme now. Thank you for
explaining it! (I'll update the wiki with this info for future curious
users.)

> Let me repeat it again: if somebody feels like the updates
> infrastructure we offer/use is inadequate, there is really nothing
> stopping you from offering your own.
>
> Unfortunately we don't have resources to address every single wish and
> request of our users. We're not aiming to create a perfect security
> platform -- we try to make a Reasonably Secure platform. We use our
> experience and intuition to judge which features should get priority and
> which we can afford not to work on. We might make mistakes, of course.
> And that's why we made Qubes GPL to allow others to help implement
> features others want and which we cannot afford to work on (or decide
> were not-so-important).
>
> joanna.

You're right, of course. This is a very reasonable (and understanding)
attitude. I apologize if I ever gave the impression of being too
demanding or critical; my enthusiasm for Qubes is sometimes too great to
contain! ;)

[HW42]

Am Mon, 18 Aug 2014 10:26:36 +0200
schrieb Joanna Rutkowska <joa...@invisiblethingslab.com>:

Exactly due to the motivation to make it reasonably secure I think
repo_gpgcheck should be used. As you and Axon pointed out we rely on
gpg --verify anyway (signed rpms in templates and dom0). So using
repo_gpgcheck reduce the attack surface significantly (since we then
rely only on gpg --verify and the proper usage through yum/rpm).
(especially once we moved the network-part out of the template VM).

I think a separation of the download process for templates would be
really a good improvement (I would implement it as a generic
"networkless" download which could be also used for things other than
yum. But this is of course the decision of the person who find the time
to do it).

Could you please ether provide a repomd.xml.asc or point out why this
would be a lot of work for you.

With regard to self operated repos: I this case you also still rely on
gpg since the git commits are signed via gpg.

So a hardned gpg/gpgv would be are great thing (i recognize that you
obviously don't have the resources to provide this). A small first step
would be --compress-algo None.

HW42

[Axon]

Joanna Rutkowska:

> Sadly we cannot do anything (affordable) about potential malicious RPMs
> that could be exploiting hypothetical bugs in GPG --verify. We can only
> switch between distros and package managers, but any could be viable to
> same hypothetical bugs. ITL could write one, but the overhead to
> maintain our own repos with "normal" updates for Fedora or whatever
> distro in the template, is just unacceptable.

So, I was just thinking:

Given that we're forced to trust GPG --verify in this case, isn't it odd
that we go out of our way to avoid trusting GPG --verify in the case of
our backup system? (Or was it not actually "GPG --verify" that we would
have had to trust in the backup system, but a different operation?)

After all, an attacker who serves us a malicious RPM which exploits GPG
--verify achieves the exact same goal as an attacker who serves a us
malicious Qubes backup file which exploits GPG --verify. (In both cases
the goal and the effect is compromising dom0.) Moreover, serving us a
malicious RPM is in most cases far easier than serving us a malicious
Qubes backup file (many mirrors, hence more opportunities; too many
packages to monitor, hence less scrutiny).

This matters to the extent that we sacrificed desired functionality by
choosing OpenSSL over GPG (working backup compression, among other things).

[cprise]

I think ITL will eventually be forced to deal with this issue one way or
another. The in-between case of using-but-avoiding-gpg-as-insecure that
you are now in (and trying to defend) is a legacy of Fedora's lax
policies (which RedHat has an interest in keeping lax). Note that RHEL
itself along with SLES, Debian, Ubuntu and I'm sure a host of others
have signed metadata, so this is another peculiar consequence of
choosing Fedora for Qubes.

And its not a matter of all-or-nothing DOS, either. Its mainly about
metadata being falsified such that only one or two critical packages
bearing zero-day vulnerabilities are prevented from updating while the
rest of the system appears to update fine. "No updates available" would
be an improvement as its more likely to raise a red flag.

The best way forward may be for ITL to publish signatures for
repomod.xml for dom0 repo as well as for the Qubes-for-VM at regular
intervals and, in the short term, let those of us who are more concerned
with update security to implement our own handling of verification. As
for templates themselves, there may be an eventual solution in using the
Debian template as a replacement for Fedora.

[cprise]

On 08/18/14 07:23, HW42 wrote:
>
> Exactly due to the motivation to make it reasonably secure I think
> repo_gpgcheck should be used. As you and Axon pointed out we rely on
> gpg --verify anyway (signed rpms in templates and dom0). So using
> repo_gpgcheck reduce the attack surface significantly (since we then
> rely only on gpg --verify and the proper usage through yum/rpm).
> (especially once we moved the network-part out of the template VM).
>
> I think a separation of the download process for templates would be
> really a good improvement (I would implement it as a generic
> "networkless" download which could be also used for things other than
> yum. But this is of course the decision of the person who find the time
> to do it).
>
> Could you please ether provide a repomd.xml.asc or point out why this
> would be a lot of work for you.
>
> With regard to self operated repos: I this case you also still rely on
> gpg since the git commits are signed via gpg.
>
> So a hardned gpg/gpgv would be are great thing (i recognize that you
> obviously don't have the resources to provide this). A small first step
> would be --compress-algo None.
>
> HW42

You make a good point about gpg itself... It is heavily relied upon for
security across many Linux servers and desktops. Like it or not, it
occupies a niche in the 'attack surface' of an OS that may be
irreducible. IMHO, it is better for the community to focus on improving
its security instead of running away from it.

[Joanna Rutkowska]

Because metadata are generated on the (untrusted) server, not on my
(trusted) build VM, see:

http://git.qubes-os.org/?p=joanna/linux-yum.git;a=blob;f=sync_qubes-os.org_repo.sh;h=b4a70aa309372d12056d3487cd5da3d06ec8c6bb;hb=HEAD

And some reasons for that are: 1) avoiding putting metadata into
incoherent state during upload of new packages (running createrepo on
the local server takes care about this), 2) not needing to keep all the
binary RPMs in local VMs, especially important in the future when we
will want to support ability for N people to be able to upload packages
(provided they are signed by M out of N signatures).

> With regard to self operated repos: I this case you also still rely on
> gpg since the git commits are signed via gpg.
>
> So a hardned gpg/gpgv would be are great thing (i recognize that you
> obviously don't have the resources to provide this). A small first step
> would be --compress-algo None.

Oh, it's not only about trusting gpg -v, it's also trusting e.g. yum
networking code. In other words, if you worry about yum attacks, then
gpg/https is not the answer (this will only give you illusory
improvement). The proper answer is: split architecture as we use for
Dom0 updates, plus hardened gpgv.

joanna.

[Joanna Rutkowska]

And just out of curiosity -- a question to people who suggested
switching over to https for updates: how do we set a list of
white-listed CAs for yum?

j.

[HW42]

Am Mon, 18 Aug 2014 19:29:09 +0200

ok. (so a separate meta data key would be nice ;P but very likely not
supported by yum)

> > With regard to self operated repos: I this case you also still rely
> > on gpg since the git commits are signed via gpg.
> >
> > So a hardned gpg/gpgv would be are great thing (i recognize that you
> > obviously don't have the resources to provide this). A small first
> > step would be --compress-algo None.
>
> Oh, it's not only about trusting gpg -v, it's also trusting e.g. yum
> networking code. In other words, if you worry about yum attacks, then
> gpg/https is not the answer (this will only give you illusory
> improvement). The proper answer is: split architecture as we use for
> Dom0 updates, plus hardened gpgv.

Oh maybe I was a bit unclear on this point. Yes I really want
"networkless" templates but this obviously involve some work.

I think it would be a good idea to have a generic download solution
instead of a yum-specific code (curl extension, http-proxy or similar).

But at least the next day I haven't the time to work on it so I don't
focused in the mail on this part

HW42

[HW42]

Am Mon, 18 Aug 2014 21:02:36 +0200
schrieb HW42 <hw...@ipsumj.de>:

The M out of N would be great but need even more yum extension.