Should repo lists be https or http

Related to “slow repo” thread, I have found that making all repos to be https rather than http has sped up my updates in both yast software management and zypper.

But, I have noticed on other threads such as: YAST modules failing to load in the applications forum

that many urls submitted for diagnosis contain urls that are only http and not https as mine were before I changed them, showing that other people had their list as mine used to be.
Is the https important in accessing updates? it does seem to work faster in what I have seen.
Where do the http urls originate from? they look to be on many systems when people post their repo lists. does the install media set up http over https?

tom kosvic

I have read the other thread and I must say I am confused by your experience.

HTTPs encrypts the conversation to keep the contents secret. As it is all about Open Source, there is nothing to keep secret. Also guarding against changing the contents (man in the middle attack to implant malware in an RPM) is not needed because of the PGP check of the RPMs contents.

That is why one does not see the need to prefer HTTPS over HTTP. And it should be a little bit faster because the encryption algorithms are not needed (but I doubt that that is very noticeable).

I can only think of the HTTPS requests being redirected to different mirrors then the HTTP requests. I have no idea id this is a ridiculous way of thinking.

And let us recap that the, as far as I understand it, the long reaction times are only found during the “zypper ref” phase of a zypper/YaST >Software action. Not during downloading of packages.

I am using “http” for my repos. Yesterday, I did a “zypper refresh” on Leap 15.3. And it was slow. However, the initial call used “http”, but that redirected to a mirror using “https”. And it was that mirror that was slow responding. I’m doubting that “http” vs. “https” has much to do with the problems people have been seeing.

Yes, what I was seeing was the ref phase taking >15min for “Update Repository with updates from SUSE Linux Enterprise” repo or sometimes infinity. Not the download phase. When I changed the http to https for all repos, it ran the ref phase at normal speeds with the “Update Repository with updates from SUSE Linux Enterprise” taking only 10 sec or so. Of course, independently, at the same time, the repo could have been fixed.

I saw that tip from someone else in one of the “slow repo” threads and tried it. Improved things for me. I can understand the argument that https should take longer due to more lookup time.

I am willing to accept that my observations could have been serendipitious but I will wait and see if I get good update times when others are reporting issues.

tom kosvic

Short answer:


Change URI:

**erlangen:~ #** sed -i s,,, /etc/zypp/repos.d/*.repo 
**erlangen:~ #**

Check and test change:

**erlangen:~ #** zypper lr -E                     
#  | Alias               | Enabled | GPG Check | Priority | URI 
 5 | Packman             | Yes     | (r ) Yes  |   90     | 
14 | openSUSE-20191106-0 | Yes     | (r ) Yes  |   99     | 
19 | repo-non-oss        | Yes     | (r ) Yes  |   99     | 
21 | repo-update         | Yes     | (r ) Yes  |   99     | 
 1 | Application_Geo     | Yes     | (r ) Yes  |  100     | 
 3 | BellSoft            | Yes     | (r ) Yes  |  100     | 
 7 | chrome              | Yes     | (r ) Yes  |  100     | 
11 | jalbum              | Yes     | (  ) No   |  100     | 
**erlangen:~ #** time zypper refresh -f 
Forcing raw metadata refresh 
Retrieving repository 'Application_Geo' metadata ...
All repositories have been refreshed. 

real    0m12.413s 
user    0m5.543s 
sys     0m0.546s 
**erlangen:~ #**

To add more detail about the specific download redirectors in use:

This is managed by MirrorBrain:

This is managed by MirrorCache:

Tested three TW isos with a few days in between, the current default points to http and that breaks the update procedure. Manually add “s” and we are back and updating the system.
This referral to http is probably a leftover from the automated packaging procedure.