#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