Re: [CentOS] Can't upgrade sssd-*
On Apr 9, 2021, at 9:37 AM, Johnny Hughes wrote: > > donated machines that are part of the > mirror.centos.org dns name. My key incorrect assumption was that this is just a front end, and all of the actual file pulls came from other second-level domains. I didn’t realize you were allowing other organizations to masquerade as centos.org. The usual solution to this sort of problem is to set up another domain; centosmirrors.org or similar. Then you can separately manage the key spaces of the two domains. This sort of design also solves certain types of CORS and XSS problems, such as third-parties getting sent cookies for the main site they haven’t actually got any business seeing, because the HTTP client can’t tell the difference. This is why you’ll find your uploads to social media sites being served back from domains other than the main user-facing one: it’s user-provided content, so they refuse to ship it from the domain that handles authentication. > we do sign the metadata .. so you can make sure the rpms, no matter > their origin, are real if you enable signed repodata I wasn’t worried about that. I just wanted to use HTTPS to hide the RPM data from the site’s overly paranoid “translucent” HTTP gateway proxy, so it wouldn’t block the download. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On 4/5/21 12:26 PM, Stephen John Smoogen wrote: > On Mon, 5 Apr 2021 at 13:05, Warren Young wrote: > >> On Apr 5, 2021, at 8:32 AM, Johnny Hughes wrote: >>> >>> wrt private keys .. we don't want any to live on machines we >>> don't physically own. >> >> Yeah, I get that. >> >> What I don’t get is why, if DNF goes to http://foo.centos.org to pull >> metadata, and it tells DNF to go to https://bar.qux.example.edu to >> download the packages specified by that metadata, why must there be any >> private keys for *.centos.org involved on example.edu’s servers? >> >> > I don't think they do require it unless that node is supposed to look like > a part of mirror.centos.org. The issue is that various tools fail when a > mirrorlist sends them data which is not the same as 'requested'. So if you > send over a http link and get an https, the tool may crash or try to talk > HTTP to the TLS port etc. > Correct .. I am talking only about donated machines that are part of the mirror.centos.org dns name. Other mirrors that have their own hostnames that are non centos.org can use https and it works fine. We just don't use it w/ mirror.centos.org machines. but we do sign the metadata .. so you can make sure the rpms, no matter their origin, are real if you enable signed repodata in yum/dnf regardless of where they are downloaded and if http or https. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On Mon, 5 Apr 2021 at 13:05, Warren Young wrote: > On Apr 5, 2021, at 8:32 AM, Johnny Hughes wrote: > > > > wrt private keys .. we don't want any to live on machines we > > don't physically own. > > Yeah, I get that. > > What I don’t get is why, if DNF goes to http://foo.centos.org to pull > metadata, and it tells DNF to go to https://bar.qux.example.edu to > download the packages specified by that metadata, why must there be any > private keys for *.centos.org involved on example.edu’s servers? > > I don't think they do require it unless that node is supposed to look like a part of mirror.centos.org. The issue is that various tools fail when a mirrorlist sends them data which is not the same as 'requested'. So if you send over a http link and get an https, the tool may crash or try to talk HTTP to the TLS port etc. ``` $ curl 'http://mirrorlist.centos.org/?release=8=x86_64=BaseOS' http://mirror.us.oneandone.net/linux/distributions/centos/8.3.2011/BaseOS/x86_64/os/ http://mirror.cs.vt.edu/pub/CentOS/8.3.2011/BaseOS/x86_64/os/ http://distro.ibiblio.org/centos/8.3.2011/BaseOS/x86_64/os/ http://ftpmirror.your.org/pub/centos/8.3.2011/BaseOS/x86_64/os/ http://mirrors.rit.edu/centos/8.3.2011/BaseOS/x86_64/os/ http://mirror.atl.genesisadaptive.com/centos/8.3.2011/BaseOS/x86_64/os/ http://atl.mirrors.clouvider.net/CentOS/8.3.2011/BaseOS/x86_64/os/ http://repos-va.psychz.net/centos/8.3.2011/BaseOS/x86_64/os/ http://centos-distro.cavecreek.net/centos/8.3.2011/BaseOS/x86_64/os/ http://mirror.vtti.vt.edu/centos/8.3.2011/BaseOS/x86_64/os/ ``` A metalink system provides different data which would allow for these 'transfers' but it has other problems which are mitigated with TLS connections ``` http://www.metalinker.org/; type="dynamic" pubdate="Mon, 05 Apr 2021 17:20:24 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager;> 1603150039 6282 7de20cbe8e7ef87b4fc1b35191277ab4 7d0c65c0daf1677eda2152e25e39a3dc4f3be027 7a75be2ebd56e44c9d33252a12158c8b7079331e9c73aa62c609414299dabf06 dfcc30a274b140d3ff65c3b3c9987a7c057a30e89880b13472f61be5fdd8829761653e11309d25680dc89d1af91d015ea0ca6992bbabec60d8b472f3e81ebba2 http://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml rsync:// download-ib01.fedoraproject.org/fedora-enchilada/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml ``` In this way the tool can know and choose the version of TLS or download protocol (rsync) which it can deal with. I don't present this as a better way, just a different way. Both systems make different security and availability choices to meet different requirements. [The Fedora system is known to be fragile in TLS bringup during the thundering bison rush of several million EPEL systems updating caches at 04:00 while the CentOS system doesn't have this issue.] > Surely the sysadmin of bar.qux.example.edu obtains a TLS key pair from > some trusted CA that certifies that bar.qux.example.edu is valid > according to the worldwide TLS public PKI. > > If we’re talking about package signing keys, surely that all happens on > centos.org servers, and the resulting RPM packages are distributed as-is, > not re-signed on each mirror server. > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- Stephen J Smoogen. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On Apr 5, 2021, at 8:32 AM, Johnny Hughes wrote: > > wrt private keys .. we don't want any to live on machines we > don't physically own. Yeah, I get that. What I don’t get is why, if DNF goes to http://foo.centos.org to pull metadata, and it tells DNF to go to https://bar.qux.example.edu to download the packages specified by that metadata, why must there be any private keys for *.centos.org involved on example.edu’s servers? Surely the sysadmin of bar.qux.example.edu obtains a TLS key pair from some trusted CA that certifies that bar.qux.example.edu is valid according to the worldwide TLS public PKI. If we’re talking about package signing keys, surely that all happens on centos.org servers, and the resulting RPM packages are distributed as-is, not re-signed on each mirror server. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On 4/2/21 4:08 PM, Warren Young wrote: > On Apr 2, 2021, at 8:46 AM, Johnny Hughes wrote: >> >> We just can't risk putting private keys for centos.org on >> machines that are donated. > > I guess I don’t understand how the mirror system works, then, because I > thought DNF/YUM contacted a central server (presumably under centos.org) > which then selected one or more mirrors with an entirely different Internet > domain, with none of the actual package traffic being on the centos.org > servers, only metadata. Yes .. BUT wrt private keys .. we don't want any to live on machines we don't physically own. (A requirement to stand up the web sever for https). > > While I might be nice to have the metadata secured as well — more than nice, > since an attacker could do bad stuff by MITM’ing it — my immediate problem > would be solved if it contacted the mirror over HTTPS, since I haven’t > configured this box to accept keys minted by any sort of snoopware box on the > site LAN. > > I suppose the site might just block HTTPS entirely if it doesn’t pass through > their snoopware, but one problem at a time, yes? > > Meanwhile, I suppose I’ll just download the packages on another box and > manually rpm -U them. > ___ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On Apr 2, 2021, at 8:46 AM, Johnny Hughes wrote: > > We just can't risk putting private keys for centos.org on > machines that are donated. I guess I don’t understand how the mirror system works, then, because I thought DNF/YUM contacted a central server (presumably under centos.org) which then selected one or more mirrors with an entirely different Internet domain, with none of the actual package traffic being on the centos.org servers, only metadata. While I might be nice to have the metadata secured as well — more than nice, since an attacker could do bad stuff by MITM’ing it — my immediate problem would be solved if it contacted the mirror over HTTPS, since I haven’t configured this box to accept keys minted by any sort of snoopware box on the site LAN. I suppose the site might just block HTTPS entirely if it doesn’t pass through their snoopware, but one problem at a time, yes? Meanwhile, I suppose I’ll just download the packages on another box and manually rpm -U them. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On 02.04.21 16:46, Johnny Hughes wrote: On 4/1/21 12:32 PM, Warren Young wrote: On Mar 26, 2021, at 7:08 AM, Warren Young wrote: Is anyone else getting this on dnf upgrade? [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: Server reports Content-Length: 9937 but expected size is: 143980 The short reply size made me think to try a packet capture, and it turned out to be a message from the site’s “transparent” HTTP proxy, telling me that content’s blocked. Rather than fight with site IT over the block list, I have a new question: is there any plan for getting HTTPS-only updates in CentOS? Changing all “http” to “https” in my repo conf files just made the update stall, so I assume there are mirrors that are still HTTP-only. No .. we host things on donated servers, we therefore are not putting private keys on there. That (and external mirrors) is why we SIGN repodata.xml. We just can't risk putting private keys for centos.org on machines that are donated. We had such a discussion in the past on the list. I assume there are no plans for improvements? Would a change from dnf's "mirrorlist" to "metalink" be a starting point? Albeit mirrorlist.centos.org would be still on http only. metalink would allow to configure https-only mirrors. Like: $ curl "https://mirrors.fedoraproject.org/metalink?protocol=https=epel-8=x86_64; But to be honest the mirrorlist.centos.org element in the chain must have also a secure solution. -- Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On 4/2/21 9:46 AM, Johnny Hughes wrote: On 4/1/21 12:32 PM, Warren Young wrote: On Mar 26, 2021, at 7:08 AM, Warren Young wrote: Is anyone else getting this on dnf upgrade? [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: Server reports Content-Length: 9937 but expected size is: 143980 The short reply size made me think to try a packet capture, and it turned out to be a message from the site’s “transparent” HTTP proxy, telling me that content’s blocked. Rather than fight with site IT over the block list, I have a new question: is there any plan for getting HTTPS-only updates in CentOS? Changing all “http” to “https” in my repo conf files just made the update stall, so I assume there are mirrors that are still HTTP-only. The mirror I still maintain IS http only: http://bay.uchicago.edu/centos/ as of this moment I have no plans to change anything (like remove CentOS from mirror machine, or force/redirect http to https on the server side). I hope, this helps. Valeri No .. we host things on donated servers, we therefore are not putting private keys on there. That (and external mirrors) is why we SIGN repodata.xml. We just can't risk putting private keys for centos.org on machines that are donated. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos -- Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On 4/1/21 12:32 PM, Warren Young wrote: > On Mar 26, 2021, at 7:08 AM, Warren Young wrote: >> >> Is anyone else getting this on dnf upgrade? >> >> [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: >> Server reports Content-Length: 9937 but expected size is: 143980 > > The short reply size made me think to try a packet capture, and it turned out > to be a message from the site’s “transparent” HTTP proxy, telling me that > content’s blocked. > > Rather than fight with site IT over the block list, I have a new question: is > there any plan for getting HTTPS-only updates in CentOS? Changing all “http” > to “https” in my repo conf files just made the update stall, so I assume > there are mirrors that are still HTTP-only. No .. we host things on donated servers, we therefore are not putting private keys on there. That (and external mirrors) is why we SIGN repodata.xml. We just can't risk putting private keys for centos.org on machines that are donated. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Can't upgrade sssd-*
On Mar 26, 2021, at 7:08 AM, Warren Young wrote: > > Is anyone else getting this on dnf upgrade? > > [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: > Server reports Content-Length: 9937 but expected size is: 143980 The short reply size made me think to try a packet capture, and it turned out to be a message from the site’s “transparent” HTTP proxy, telling me that content’s blocked. Rather than fight with site IT over the block list, I have a new question: is there any plan for getting HTTPS-only updates in CentOS? Changing all “http” to “https” in my repo conf files just made the update stall, so I assume there are mirrors that are still HTTP-only. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Can't upgrade sssd-*
Is anyone else getting this on dnf upgrade? [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: Server reports Content-Length: 9937 but expected size is: 143980 [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: Server reports Content-Length: 9937 but expected size is: 143980 [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: Server reports Content-Length: 9937 but expected size is: 143980 [MIRROR] sssd-proxy-2.3.0-9.el8.x86_64.rpm: Interrupted by header callback: Server reports Content-Length: 9937 but expected size is: 143980 I can install almost everything else in the latest batch of updates but not any of sssd-* or anything directly dependent upon it. (Basically, gvfs, samba, and assorted libraries built atop sssd.) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
