Re: deltarpm usefulness?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 11, 2021 at 02:02:39PM -0700, Kevin Fenzi wrote:
> drpms work by downloading the delta, then using it + the version you
> have installed to recreate the signed rpm (just like you downloaded the
> full signed update) 

I'm worried about this process specifically. It does rather heavy
parsing on a drpm file, before having a chance to verify the signature.

> and then the gpg signature is checked of that full rpm,
> just like one you downloaded. If the drpm is tampered with it won't
> reassemble and it will fall back to the full signed rpm.
> 
> Additionally, fedoraproject.org has dnssec enabled, so if you are
> worried, do enable that to avoid hyjacking.

Ok, so there are several things here:
1. DNSSEC protects against only some of the threats. It won't (on its
   own) help if someone intercepts my TCP connection when I download
   updates via wifi in a coffee shop.

2. HTTPS provides _much_ better protection against various kind of MitM
   attacks, but in some threat models is still not enough:
   - It protects only the connection to the server, not integrity of the
     mirrors.fedoraproject.org machine itself (if someone manages to
     exploit a hypothetical bug in the web server there, it's game
     over). 
   - Furthermore, there is a wildcard cert for *.fedoraproject.org, so
     in practice it's enough to break into any of the servers (having
     key for that cert), to make MitM attack feasible.
   - There are over hundred trusted CAs in the default setup. It takes
     just one compromised/malicious to issue a duplicate cert. Both
     scenarios has happened to some CAs in the past.

3. Finally, this is about just Fedora repositories. It doesn't help for
much for dozen other repositories that user is free to add. Some may
even use plain HTTP (and rely just on package signatures)!

While I still think disabling deltarpm by default is a good idea, in
absence of signed metadata there are a few things that could improve the
situation:
 - Pin specific CA in the repo config (sslcacert option)
 - Add CAA record for the same purpose
 - Avoid wildcard cert for such critical purpose, but to make it really
   worth it, the wildcard cert for the domain would need to not exists -
   rather impractical thing. Maybe use separate domain then
   (getfedora.org?)?
 - Some would propose to use own CA to avoid trusting the whole
   DigiCert (or other single CA), but personally I think the downsides
   overweights the benefits

And this is just about the connection part, not about integrity of the
server itself... BTW, I do hope that signing keys are stored somewhere
else.


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux