aom - port fails to download

[mouse07410 (Mouse)]

Looks like there's something wrong with certificates/HTTPS:

$ sudo port install aom
--->  Computing dependencies for aom
--->  Fetching archive for aom
--->  Attempting to fetch aom-3.3.0_0.darwin_21.x86_64.tbz2 from https://packages.macports.org/aom
--->  Attempting to fetch aom-3.3.0_0.darwin_21.x86_64.tbz2 from https://nue.de.packages.macports.org/aom
--->  Attempting to fetch aom-3.3.0_0.darwin_21.x86_64.tbz2 from http://atl.us.packages.macports.org/aom
--->  Fetching distfiles for aom
Error: Failed to fetch aom: Git clone failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port aom failed

and the log:

.  .  .
:msg:archivefetch --->  Fetching archive for aom
:debug:archivefetch Executing org.macports.archivefetch (aom)
:debug:archivefetch euid/egid changed to: 0/0
:debug:archivefetch chowned /opt/local/var/macports/incoming to macports
:debug:archivefetch euid/egid changed to: 501/101
:info:archivefetch --->  aom-3.3.0_0.darwin_21.x86_64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
:msg:archivefetch --->  Attempting to fetch aom-3.3.0_0.darwin_21.x86_64.tbz2 from https://packages.macports.org/aom
:debug:archivefetch Fetching archive failed: error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
:msg:archivefetch --->  Attempting to fetch aom-3.3.0_0.darwin_21.x86_64.tbz2 from https://nue.de.packages.macports.org/aom
:debug:archivefetch Fetching archive failed: error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
:msg:archivefetch --->  Attempting to fetch aom-3.3.0_0.darwin_21.x86_64.tbz2 from http://atl.us.packages.macports.org/aom
:debug:archivefetch Fetching archive failed: The requested URL returned error: 404
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:fetch fetch phase started at Thu Feb 24 14:02:20 EST 2022
:notice:fetch --->  Fetching distfiles for aom
:debug:fetch Executing org.macports.fetch (aom)
:debug:fetch Executing: /usr/bin/git clone --progress https://aomedia.googlesource.com/aom.git /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.3.0 2>&1
:debug:fetch system: /usr/bin/git clone --progress https://aomedia.googlesource.com/aom.git /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.3.0 2>&1
:info:fetch Cloning into '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.3.0'...
:info:fetch fatal: unable to access 'https://aomedia.googlesource.com/aom.git/': error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
:info:fetch Command failed: /usr/bin/git clone --progress https://aomedia.googlesource.com/aom.git /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.3.0 2>&1
:info:fetch Exit code: 128
:error:fetch Failed to fetch aom: Git clone failed
.  .  .

[jmroot (Joshua Root)]

I can't reproduce this. It's suspicious that you're getting the same SSL error from the two packages servers as well as googlesource.com.

[mouse07410 (Mouse)]

It's suspicious that you're getting the same SSL error from the two packages servers as well as googlesource.com

I hear you. But all the other packages got updated by port without a problem, and I downloaded successfully the binary aom-3.3.0_0.darwin_21.x86_64.tbz2 from ​https://packages.macports.org/aom using (Macports-installed) wget.

What would you recommend me to do?

[jmroot (Joshua Root)]

Replying to mouse07410:

I hear you. But all the other packages got updated by port without a problem, and I downloaded successfully the binary aom-3.3.0_0.darwin_21.x86_64.tbz2 from ​https://packages.macports.org/aom using (Macports-installed) wget.

Did the other ports you updated succeed in downloading from https sites, or did they fail on those and end up getting fetched from http sites? Can /usr/bin/curl download that package from the same place?

[mouse07410 (Mouse)]

Did the other ports you updated succeed in downloading from https sites . . . ?

As far as I know, yes.

Can /usr/bin/curl download that package from the same place?

$ /usr/bin/curl https://packages.macports.org/aom/aom-3.3.0_0.darwin_21.x86_64.tbz2 -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 3690k  100 3690k    0     0  9568k      0 --:--:-- --:--:-- --:--:-- 9736k
$ 

[mouse07410 (Mouse)]

Interestingly, today I got a similar problem with another package:

:debug:fetch Fetching distfile failed: error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
:error:fetch Failed to fetch libxml2: error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
:debug:fetch Error code: NONE
:debug:fetch Backtrace: error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number
:debug:fetch     while executing
:debug:fetch "error $lastError"
:debug:fetch     (procedure "portfetch::fetchfiles" line 66)
:debug:fetch     invoked from within
:debug:fetch "portfetch::fetchfiles"
:debug:fetch     (procedure "portfetch::fetch_main" line 17)
:debug:fetch     invoked from within
:debug:fetch "$procedure $targetname"
:error:fetch See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_libxml2/libxml2/main.log for details

[mouse07410 (Mouse)]

Further digging by my colleague brought up this: ​https://apple.stackexchange.com/questions/432353/updated-macports-curl-implementation-behaves-differently-from-previous-version-a

The short answer is - curl port default variant should something different from +ssl. +darwinssl (using system TLS) or +gnutls (using Gnu TLS that wget default uses).

I'd appreciate if the curl port default variant was changed.

[jmroot (Joshua Root)]

Why would /usr/bin/git and MacPorts base (which uses the system libcurl) be affected by the configuration of the curl port?

[mouse07410 (Mouse)]

Why would /usr/bin/git and MacPorts base (which uses the system libcurl) be affected by the configuration of the curl port?

Who am I to know... ;-)

Seriously, I observe different results between using portfunctionality as shown above, and using /usr/bin/xxx stuff that works (again, as show above).

[ryandesign (Ryan Carsten Schmidt)]

Replying to mouse07410:

:debug:fetch Backtrace: error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number

Googling this error, it seems to say that it occurs when you try to send https traffic to a server that does not support https (such as an http server). All of our servers are surely not misconfigured in the same way at the same time, therefore I suggest there is a problem with your computer (like an antivirus program that is monitoring and interfering with your network traffic) or with a proxy server that you have configured your computer to use.

Replying to mouse07410:

Further digging by my colleague brought up this: ​https://apple.stackexchange.com/questions/432353/updated-macports-curl-implementation-behaves-differently-from-previous-version-a

That page appears to discuss this error:

curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled

which is different from the error you reported so I don't see the relevance.

The short answer is - curl port default variant should something different from +ssl. +darwinssl (using system TLS) or +gnutls (using Gnu TLS that wget default uses).

I'd appreciate if the curl port default variant was changed.

I have considered changing the curl port's default variant, however I don't see that it has anything to do with the problem you're experiencing. MacPorts does not use MacPorts curl to download anything, unless you have built MacPorts from source and told it to do so. If you have, then you could reinstall curl with a different variant, if that helps you. But I don't see how it could help solve the problem that https servers are apparently sending non-https responses only to your computer.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

a proxy server that you have configured your computer to use.

And you have mentioned in #64744 that you do use a proxy. So I suspect either the proxy's configuration or your computer settings for accessing that proxy are wrong.

[mouse07410 (Mouse)]

All of our servers are surely not misconfigured in the same way at the same time, therefore I suggest there is a problem with your computer (like an antivirus program that is monitoring and interfering with your network traffic) or with a proxy server that you have configured your computer to use

I hear you. But this is a corporate firewall - I've no control over it whatsoever, and it's not on my machine. It's a Web proxy.

Also, all of my machines go through this proxy/firewall, by the virtue of being on the same network. But only a couple of them exhibit this problem.

No, I did not build Macports itself from sources - and don't intend to do so.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mouse07410:

I hear you. But this is a corporate firewall - I've no control over it whatsoever, and it's not on my machine. It's a Web proxy.

Also, all of my machines go through this proxy/firewall, by the virtue of being on the same network. But only a couple of them exhibit this problem.

Then I would guess that those couple machines that exhibit the problem are misconfigured with regard to how they use the proxy. Ask your proxy administrator for help. I don't see anything in MacPorts or in the aom portfile that could be changed to affect this problem.