Guys, Warren ( i guess some of you knows him ) pointed to me that the repo rpm file was downloaded from a http server, not a https one, and well he has a point. So i'm gonna make a cert on https://letsencrypt.org/ and setup the https vhost for download1.rpmfusion.org. I'll let you know when it's ok, so you can change the download link, and maybe setup a rewrite so all http links become https ones. If you have any concern or problem with this, please let me know! Pix

The way packages are verified is by gpg keys, then either we gpg-sign the repo (fedora doesn't do that) or we transfert mirrors list over https (mirrorlist doesn't need proxy cache). The later is still needed if we want to enforce strict security.

2016-09-26 16:28 GMT+02:00 Nikos Roussos <comzeradd(a)fedoraproject.org&gt;: >> The way packages are verified is by gpg keys, then either we gpg-sign >> the repo (fedora doesn't do that) or we transfert mirrors list over >> https (mirrorlist doesn't need proxy cache). >> The later is still needed if we want to enforce strict security. > > There is a nice debate going on on twitter today, about Ubuntu serving > updates over http [1]. Signing solves the verification issue, but there > still a couple of privacy/security problems. One being that anyone could > easily determine what kind of packages I use by sniffing my updates. And > secondly an ISP/Gov can easily turn the switch off to prevent me from > getting (security) updates (https would require DPI to do that). You are describing two different issues here: 1/ - The confidentiality of the connection between the dnf/yum client and the mirror repository. Right now fedora doesn't seem to address this issue. It means dnf/yum currently doesn't enforce strict https to the mirrors (if ever the mirror has support). It could probably be done as a mirror manager special option as initiated by dnf to request https capable mirror. It would also requires that most our mirrors can be https capable. And I expect we are very far from this. If you really think this should be fixed, then best is to raise the question within fedora instead. (this probably means submitting few features requests to dnf and mirror-manager) But for now the quick fix is to enable dowload1 as a baseurl and use it over https, it won't scale well if everyone is doing the same, but it will also move the confidentiality issue from client/mirror to the given mirror operator. so if you don't trust your state about such confidentiality, you will have to trust both the admin operator of the mirror and the state in which the mirror leave. So my personal advice if you really really care about such confidentiality information is to mirror the whole content. 2/ - the "integrity of the repos" (not the packages as they are gpg-signed). The way it's solved by fedora is because mirror manager periodically checks for outdated mirror content. So if one mirror is modified (security fixes are removed or else), this mirror will be removed from the "metalink" provided by dnf/yum clients. This metalink is provided over https, so both integrity and confidentiality of the content is assured. Now we can both check for fresh unmodified content and gpg-sign the whole repos. The latter was never implemented in fedora (we could eventually implement it here, but it would be better to initiate the discussion within fedora first). For providing mirrorlist over https I've opened a RFE here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4269 For the record, CentOS currently doesn't provide the mirrorlist over https and don't gpg-sign their repos either. At least their gpg keys are described over https: https://www.centos.org/keys/ (which will be done in RPM Fusion once the wiki will be migrated to the new infra). RHEL on the other side are using https for the repo (with a client certificate, but that's another story).

> Warren ( i guess some of you knows him ) pointed to me that the repo rpm > file was downloaded from a http server, not a https one, and well he has > a point. So i'm gonna make a cert on https://letsencrypt.org/ and setup > the https vhost for download1.rpmfusion.org. It would probably a good idea to include rpmfusion.org on this cert and server the whole website over https.

Nicolas Chauvet wrote: > letsencrypt doesn't provide wildcard, and that will be a different > server (so a different cert). It doesn't allow wildcards, but it allows you to give up to 100 SANs (subject alternative names) for a certificate (the canonical one and 99 more). So you can use the same cert for all *.rpmfusion.org subdomains (unless there are more than 100), but of course you don't have to.

Nicolas Chauvet wrote: > > letsencrypt doesn't provide wildcard, and that will be a different > server (so a different cert). It doesn't allow wildcards, but it allows you to give up to 100 SANs  (subject alternative names) for a certificate (the canonical one and 99  more). So you can use the same cert for all *.rpmfusion.org subdomains  (unless there are more than 100), but of course you don't have to.

On Sáb, 2016-09-24 at 22:30 +0200, Kevin Kofler wrote: > Nicolas Chauvet wrote: > > > > letsencrypt doesn't provide wildcard, and that will be a different > > server (so a different cert). > It doesn't allow wildcards, but it allows you to give up to 100 SANs > (subject alternative names) for a certificate (the canonical one and > 99 > more). So you can use the same cert for all *.rpmfusion.org > subdomains > (unless there are more than 100), but of course you don't have to. Hello , To follow up which SANs do we need , I propose one bug tracker. A few days ago expired the certificate of http://lists.rpmfusion.org w hich was from CAcert ...