Plugin interface: Add fucntion to API that uses mumbles internal SSL capability to read a webserver ressource

[hbeni]

Context

Plugin API

Description

Please add a mumble_getHTTPURL() plugin API function to query the internet.

If in my plugin mumble_hasUpdate() function I could just call some mumble_getHTTPURL("https://example.org") function to utilize the already linked ssl engine of mumble, this would be beneficial in several places:

• My mumble_hasUpdate() could be much more simple.
• The plugin itself won't have a openssl dependency, helping with
  • building for multiple targets
  • maintaining openssl compatibility
  • the byte-bloat of a statically linked openSSL for my windows build

The requested mumble_hasUpdate() Plugin-API function should just try to lookup the web ressource (using TLS when the protocol part has a https:// prefix) and return either the HTTP error code or the contents of the page.

Mumble component

Client

OS-specific?

No

Additional information

Basicly mumble_hasUpdate() probably just needs to leverage or expose the already existing mumble-code that gets called to actually fetch the updated plugin from the web, which is already part of the plugin updater process.

Probably here?

mumble/src/mumble/PluginUpdater.cpp

Lines 80 to 90 in 23f7650

	void PluginUpdater::update() {
	QMutexLocker l(&m_dataMutex);
	for (int i = 0; i < m_pluginsToUpdate.size(); i++) {
	UpdateEntry currentEntry = m_pluginsToUpdate[i];
	// The network manager will be emit a signal once the request has finished processing.
	// Thus we can ignore the returned QNetworkReply* here.
	m_networkManager.get(QNetworkRequest(currentEntry.updateURL));
	}
	}

[Krzmbrzl]

I'm wondering whether this has any security-implications. If there is some sort of bug in the webpage fetching, then a malicious website could end up causing havoc in Mumble itself. Then again, the same could already happen with the update URL 🤔

[hbeni]

Yes, it can happen with the update URL too.
And also, to consider: The update fetcher already runs inside mumble process context, as well as any plugin stuff (like my own http fetch code).

The URL should be properly sanitized by the api function, of course.
And also strict tests are prudent when fetching the content, like what to do if the requested URL is slow to respond (or hangs forever), or the webserver returns endless data. There should be limits to this, but maybe it would be good to have a possibility for the plugin code to also adjust those limits if needed.
(Said that, that is also already true for all other http stuff mumble does. But going trough a common, well tested function (which it is already probably) is better than every plugin developer reinventing the wheel here)