Fwd: [MacPorts] #49721: (potentially) dangerous bug in Qt5

[René J.V. Bertin]

Hi,

A small FYI-style note of warning for people who use Qt5 for their own development (or to install applications) other than through existing MacPorts ports. 

The issue I ran into was possible only because of a specific set of conditions that may have existed only on my own computer, but I am not yet convinced there are no other faces to this bug in Qt.

R.

----------  Forwarded Message  ----------

Subject: [MacPorts] #49721: dangerous bug in Qt5
Date: Tuesday November 17 2015, 09:32:27
From: MacPorts <noreply at macports.org>
To: rjvbertin at gmail.com, macports-tickets at lists.macosforge.org

#49721: dangerous bug in Qt5
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:
 Keywords:               |       Port:  qt5
-------------------------+--------------------------------
 Last week I ran into a dangerous bug in Qt5, as a result of which I had to
 restore a large part of /Applications from backup.

 The bug is in QtCore::QStandardPaths (QSP) which provides applications
 with a way to obtain the paths to a range of standard locations, in
 readable ("system") and writable ("user") form. The class also has a
 switch to put it into testing mode that changes the returned locations,
 intended for use in unittests/autotests so that they don't overwrite or
 delete anything in the actual locations.

 On OS X, QSP returns locations that are compliant with the OS X way of
 doing things (app. data into ~/Library/Application Support, for instance)
 and App Store rules.

 For the `ApplicationsLocation` it returns `/Applications`, which seems
 reasonable (but in fact has nothing to do with the role of the
 ApplicationsLocation on Linux). This location makes no difference between
 readable and writable, and more importantly, not either between regular
 and testing mode.

 As a result, software tests that verify functionality involving reading
 and writing from ApplicationsLocation will
 - attempt to get the testing ApplicationsLocation
 - store files there, do stuff with them
 - cleanup afterwards

 The code that wreaked havoc on my machine did the cleanup with a
 `removeDir(ApplicationsLocation)`, in other words, `rm -rf /Applications`.
 Evidently it didn't print exactly what it was doing, it just seemed to
 hang (fortunately I have an HDD, not an SDD). (And of course I have since
 reverified all permissions in /Applications.)

 I reported the bug upstreams, but at the moment any fixing appears to be
 blocked by a single Qt dev, and a fix isn't likely to be included anytime
 soon anyway (5.7, maybe).

 I did include a fix in the QSP patch of my own [ticket:48967
 port:qt5-kde], of course.

 I did run into this problem while developing a port, but I don't think
 there is much risk with published ports. `port test` probably doesn't run
 with elevated privileges, and port maintainers should just check any
 (auto)tests or keep/set `test.run no`.

 However, anyone using the installed Qt5 SDK should be aware of the risk.

-- 
Ticket URL: <https://trac.macports.org/ticket/49721>
MacPorts <https://www.macports.org/>
Ports system for OS X
-----------------------------------------