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.)
On Mar 26, 2021, at 7:08 AM, Warren Young warren@etr-usa.com 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.
On 4/1/21 12:32 PM, Warren Young wrote:
On Mar 26, 2021, at 7:08 AM, Warren Young warren@etr-usa.com 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.
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 warren@etr-usa.com 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
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 warren@etr-usa.com 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&repo=epel-8&am..."
But to be honest the mirrorlist.centos.org element in the chain must have also a secure solution.
-- Leon
On Apr 2, 2021, at 8:46 AM, Johnny Hughes johnny@centos.org 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.
On 4/2/21 4:08 PM, Warren Young wrote:
On Apr 2, 2021, at 8:46 AM, Johnny Hughes johnny@centos.org 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. _______________________________________________
On Apr 5, 2021, at 8:32 AM, Johnny Hughes johnny@centos.org 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.
On Mon, 5 Apr 2021 at 13:05, Warren Young warren@etr-usa.com wrote:
On Apr 5, 2021, at 8:32 AM, Johnny Hughes johnny@centos.org 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&arch=x86_64&repo=BaseOS' http://mirror.us.oneandone.net/linux/distributions/centos/8.3.2011/BaseOS/x8... 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
``` <metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Mon, 05 Apr 2021 17:20:24 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager"> <files> <file name="repomd.xml"> mm0:timestamp1603150039</mm0:timestamp> <size>6282</size> <verification> <hash type="md5">7de20cbe8e7ef87b4fc1b35191277ab4</hash> <hash type="sha1">7d0c65c0daf1677eda2152e25e39a3dc4f3be027</hash> <hash type="sha256">7a75be2ebd56e44c9d33252a12158c8b7079331e9c73aa62c609414299dabf06</hash> <hash type="sha512">dfcc30a274b140d3ff65c3b3c9987a7c057a30e89880b13472f61be5fdd8829761653e11309d25680dc89d1af91d015ea0ca6992bbabec60d8b472f3e81ebba2</hash> </verification> <resources maxconnections="1"> <url protocol="http" type="http" location="US" preference="100"> http://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everythi... </url> <url protocol="rsync" type="rsync" location="US" preference="100">rsync:// download-ib01.fedoraproject.org/fedora-enchilada/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml </url> <url protocol="https" type="https" location="US" preference="100"> https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everyth... </url> </resources> </file> </files> </metalink> ```
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
On 4/5/21 12:26 PM, Stephen John Smoogen wrote:
On Mon, 5 Apr 2021 at 13:05, Warren Young warren@etr-usa.com wrote:
On Apr 5, 2021, at 8:32 AM, Johnny Hughes johnny@centos.org 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.
<snip>
On Apr 9, 2021, at 9:37 AM, Johnny Hughes johnny@centos.org 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.
-
Johnny Hughes -
Leon Fauster -
Stephen John Smoogen -
Valeri Galtsev -
Warren Young