[Home]

Summary:ASTERISK-30170: thirdparty: Certificate for svn.digium.com HTTPS is untrusted on Debian
Reporter:N A (InterLinked)Labels:
Date Opened:2022-08-08 18:18:37Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Contrib/General
Versions:18.13.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:
Description:This seems to have started some time recently - installs are getting blocked due to a warning about svn.digium.com using an untrusted certificate.

Perhaps the certificate could be updated, or the endpoint changed?

{noformat}
#############################################
## install completed successfully
#############################################
Error validating server certificate for 'https://svn.digium.com:443':
- The certificate is not issued by a trusted authority. Use the
  fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *.digium.com
- Valid: from Apr 21 00:00:00 2022 GMT until May  1 23:59:59 2023 GMT
- Issuer: GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1, DigiCert Inc, US
- Fingerprint: D2:49:EC:5A:DE:E2:E5:1B:74:22:FD:39:22:FA:B1:78:B9:34:87:FA
(R)eject, accept (t)emporarily or accept (p)ermanently?
{noformat}

Furthermore, upon accepting, it fails anyways:
{noformat}
svn: E170013: Unable to connect to a repository at URL 'https://svn.digium.com/svn/thirdparty/mp3/trunk'
svn: E120108: Error running context: The server unexpectedly closed the connection.
{noformat}

I can access it in my browser, but https gets redirected to http so not sure if something changed here recently.

I believe this stems from a problem with:

./contrib/scripts/get_mp3_source.sh

<s>I'm not entirely clear on what the impact of this is, since app_mp3 seems to compile as normal, but it does seem to block the install process.</s>

Okay, I take that back, I do get this after all at the end, which has not happened before:

{noformat}
**************************************************************
***                                                        ***
***    ---> IMPORTANT INFORMATION ABOUT format_mp3 <---    ***
***                                                        ***
*** format_mp3 has been selected to be installed, but the  ***
*** MP3 decoder library has not yet been downloaded into   ***
*** the source tree.  To do so, please run the following   ***
*** command:                                               ***
***                                                        ***
***          $ contrib/scripts/get_mp3_source.sh           ***
***                                                        ***
**************************************************************

Installing modules from addons...
/usr/bin/install: cannot stat 'format_mp3.so': No such file or directory
make[1]: *** [/usr/src/asterisk-18.13.0/Makefile.moddir_rules:109: install] Error 1
make: *** [Makefile:584: addons-install] Error 2
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2022-08-08 18:18:42.183-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].
By: Joshua C. Colp (jcolp) 2022-08-09 03:46:12.547-0500

There have been no changes to this, aside from renewing and updating the TLS certificate in April. I'm also not able to reproduce it on any of my systems, and haven't seen any reports from those who still use format_mp3.

What distribution and version is this occurring on? Did packages change there for the trusted root certificates?

What does manually doing: svn ls https://svn.digium.com/svn/thirdparty/mp3/trunk

Result in?
By: N A (InterLinked) 2022-08-09 05:08:12.825-0500

Running that manually works, though post-install things seem to work more.

This has happened now on both Debian 10 and Debian 11, when I reinstalled Asterisk on such machines recently. I don't recall anything else changing w/r/t certificates recently.

I can't reproduce it anymore on such systems because the certificate was already accepted, I think this only happens once per machine, which can still be problematic when managing a fleet of servers.
By: N A (InterLinked) 2022-08-31 16:42:23.806-0500

Here is an encounter with this again on another machine I must not have reinstalled Asterisk on super recently:

asterisk-18.14.0/utils/muted.c
asterisk-18.14.0/utils/smsq.c
asterisk-18.14.0/utils/stereorize.c
asterisk-18.14.0/utils/streamplayer.c
asterisk-18.14.0/utils/utils.xml
info: Trying to set 'libvpb1/countrycode' [string] to '1'
info: Loading answer for 'libvpb1/countrycode'
Reading package lists... Done
Building dependency tree
Reading state information... Done
libvpb1 is already the newest version (4.2.61-1).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Hit http://security.debian.org/debian-security buster/updates InRelease
Hit http://deb.debian.org/debian buster InRelease
Hit http://deb.debian.org/debian buster-updates InRelease

#############################################
## install completed successfully
#############################################
Error validating server certificate for 'https://svn.digium.com:443':
- The certificate is not issued by a trusted authority. Use the
  fingerprint to validate the certificate manually!
Certificate information:
- Hostname: *.digium.com
- Valid: from Apr 21 00:00:00 2022 GMT until May  1 23:59:59 2023 GMT
- Issuer: GeoTrust TLS DV RSA Mixed SHA256 2020 CA-1, DigiCert Inc, US
- Fingerprint: D2:49:EC:5A:DE:E2:E5:1B:74:22:FD:39:22:FA:B1:78:B9:34:87:FA
(R)eject, accept (t)emporarily or accept (p)ermanently?

Upon accepting, it actually fails:

svn: E170013: Unable to connect to a repository at URL 'https://svn.digium.com/svn/thirdparty/mp3/trunk'
svn: E120108: Error running context: The server unexpectedly closed the connection.

I can confirm this corresponds to running the following, probably just the latter:

./contrib/scripts/install_prereq install
./contrib/scripts/get_mp3_source.sh
By: N A (InterLinked) 2023-01-12 07:26:31.520-0600

As of sometime in the last few days, this seems to be a major issue again.

Asterisk installs with MP3 are all failing because the certificate is not trusted:

svn export https://svn.digium.com/svn/thirdparty/mp3/trunk addons/mp3
This fails on every Debian machine I have tried.
By: N A (InterLinked) 2023-01-12 07:28:24.828-0600

Changing the command to svn --non-interactive --trust-server-cert export https://svn.digium.com/svn/thirdparty/mp3/trunk addons/mp3 in the script makes it work it seems.

I'm not sure if this would be considered "acceptable", but I think this change needs to be made if the SVN server keeps having this issue.
By: Joshua C. Colp (jcolp) 2023-01-12 07:42:02.309-0600

I'm investigating.
By: Joshua C. Colp (jcolp) 2023-01-12 07:45:14.255-0600

This should now be resolved.
By: Joshua C. Colp (jcolp) 2023-01-12 07:46:28.545-0600

Additionally, things will change. The entire HTTPS proxy this runs through serves downloads, issues, svn, wiki, etc. It will be replaced in the future.
By: N A (InterLinked) 2023-01-12 08:06:08.763-0600

Thanks for looking into it, I updated my build script to blindly trust the cert for now, and then run the MP3 script, just in case, but I'll revisit once the migration happens.
As part of the Git migration, is migrating the SVN stuff to GitHub on the radar? Seems kind of clunky to keep relying on that long term.
By: Joshua C. Colp (jcolp) 2023-01-12 08:09:47.316-0600

Yes, the repos already exist on Gerrit. They'll be copied to Github and the process updated (which I have an abandoned review for). SVN will likely still need to exist in read-only form for a period of time regardless, since all previous versions still rely on it and people still build old versions.