How to install MuseSounds on Linux?
I have a Chromebook and have installed MuseScore 4 on it now it has been released. I used the AppImage as seen on the download page. I also downloaded the muse_hub.deb file into the same directory. I installed the AppImage and MuseScore4 works fine, but I do not know how to install the MuseHub from the ".deb" file. I used these instructions: https://musescore.org/en/handbook/3/install-linux but they are for version 3 so they do not include MuseHub installation.
Comments
I got a little farther, I ran this command:
scottlawrencelawson@penguin:~/MuseScore4$ sudo dpkg -i Muse_Hub.deb
And it responded with:
Selecting previously unselected package muse-hub.
(Reading database ... 46841 files and directories currently installed.)
Preparing to unpack Muse_Hub.deb ...
Unpacking muse-hub (1.0.0.392) ...
Setting up muse-hub (1.0.0.392) ...
Created symlink /etc/systemd/system/multi-user.target.wants/muse-hub.service → /usr/lib/systemd/system/muse-hub.service.
Processing triggers for mailcap (3.69) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
So I get an icon for MuseHub (see attachment) but when I click on it nothing happens and I cannot chose it in the mixer in MuseScore. Any idea what next?
In reply to I got a little farther, I… by scottlawrencelawson
On many Linux systems - including Chromebooks - you need to start the background service manually first. So:
sudo muse-hub-service
Btw, for future reference, you can install the hub by simply double click the “.deb” file in the Files app.
In reply to On many Linux systems -… by Marc Sabatella
Thanks, Mark I will try starting the service. I was not 100% sure how to do that, so I tried because I read that in another thread (https://musescore.org/en/node/336143#comment-1153341) but it did not work. Also, double-clicking the .deb file did not work either even though I had changed the properties of the file to make it able to be run as a program.
In reply to Thanks, Mark I will try… by scottlawrencelawson
What a difference a REBOOT makes! Over night I fully shutdown the Chromebook which stopped the Linux environment and restarted this morning. Now, doing exactly what you said: starting the MuseHub first by double-clicking on the icon brought up the app, yay! I downloaded the Choir sounds and then opened MuseScore4, loaded a motet I wrote and it had MuseSounds selected in the playback setup and it sounds great!
Thanks!
In reply to What a difference a REBOOT… by scottlawrencelawson
Awesome, glad to hear it!
In reply to On many Linux systems -… by Marc Sabatella
Why do I have to give root access to some closed source service in order to have better playback in MuseScore? That doesn't make any sense and seems incredibly fishy.
In reply to Why do I have to give root… by kresimir
I do not know how to answer that as I am not very skilled on Linux. All I know is that it works for me on my Chromebook. FWIW, last time I rebooted, I did not need to run the service via command line, I just clicked on the MuseSounds application, was able to download the sound libraries and they we correctly applied to my existing scores. It does not seem fishy to me, I think Muse is just trying to make a good product that works for everyone.
In reply to I do not know how to answer… by scottlawrencelawson
What I would do in a situation of accidentally running a proprietary program with root privileges is reinstalling the OS, in case it is compromised. After an unknown binary is executed as root, there cannot be any guarantee that the system is trustworthy anymore. Of course, every user should evaluate the security risks for themselves.
In reply to I would probably reinstall… by kresimir
That is going way too far and is irresponsible to suggest. The vast majority of software installed on the vast majority of systems in the world is not open source, and much of it uses services that require root access. Suggesting with absolutely not a shred of evidence that this is causing a computer to be infected with malware and giving people incredibly damaging advice like reinstalling their OS has no basis in fact whatsoever and in fact is simply libel.
Anyhow, anyone reading this - please don't follow this incredibly misguided advice!
In reply to That is going way too far… by Marc Sabatella
There is evidence to suggest that MuseHub is malware. Malwarebytes on Windows reports it as malware: https://musescore.org/en/comment/1154157
It's not libelous to suggest caution (otherwise, you'd have to say that Malwarebytes is a fundamentally libelous piece of software).
Now, this could very well be a false positive. It probably is. But it could just as well not be... It is safer to assume the worst and be wrong.
On Linux, we typically do not use such malware scanners, but the users are advised to be very cautious of what processes are allowed to be run with root privileges. A program that downloads a few soundfonts does not need root access. If it does, it is probably doing something else, in addition to what it purports to do. The fact is, we simply do not know what it does, so in my opinion, it is better to be safe than sorry and not let such programs have root access. Of course, that is just my opinion. Every user is responsible for their computer.
In reply to There is evidence to suggest… by kresimir
This isn't evidence of anything except a false positive. The reason for this has already been explained.
The reason for root access is, I assume, to install Muse Sampler updates, since it is a binary (shared library). Almost all installation programs for almost all binaries on almost all operating systems require root / admin access. that shouldn't be even the least bit surprising to anyhow who has installed software before - instrallers usually require system access. Whether or not this installer in particular could manage to do the job in some other way that works equally across different Linux distributions, I cannot say. Maybe you have enough experience writing Linux installers to have another idea. And maybe in the future another solution can be found with your help. But if you want to work together with the developers to propose alternative solutions, you have a much better chance of success if you refrain the the criminal accusations, and instead approach them in a spirit of cooperation.
So again, please do not continue spreading misleading information and unfounded speculation on these support forums. It does nothing to help users at all - quite the opposite.
In reply to This isn't evidence of… by Marc Sabatella
It is not my intention to mislead anyone. If I've made any factual errors, I would be very grateful for any correction.
In my 15 years of using GNU Linux, I've never downloaded a binary file from the internet and executed it with root privileges. Never. If someone asks me to do that, that is an enormous red flag and I get very suspicious. That is not how installation works on Linux (or at least not how it should work). We have package managers to do our installing for us, from the official software repositories of our Linux distributions. These package managers are run with root privileges. Third-party installers on Linux are very much frowned upon, because they are an absolute security nightmare.
How do you know it's a false positive? I'm not trying to be argumentative here, I'm genuinely interested. I've always been taught to assume that a positive is a positive, until detailed analysis is done to prove it's a false positive.
I'm not accusing anyone of anything, I am just suggesting caution and pointing out very obvious red flags. What is the reason for making this program closed source? I can only speculate, but it is obvious to me this is contrary to the spirit of MuseScore which has been Free and Open Source from the very beginning.
If I were to make a wild guess, I would say that there is 95% chance you're correct and that MuseHub is perfectly harmless. That does not change the fact it is proprietary software which requires root access. Personally, I am certainly not going to run with root privileges any proprietary program that didn't come from my distribution's official software repository -- simply because there is never any need to do that. Even if the authors of that binary file are completely trustworthy (probably are, but I don't know them), the file could be hosted on a compromised server and actual malware substituted by a malicious third party. Without a shasum check, we cannot even know if the binary file we are downloading is the same one that was created by the Muse Hub team.
If by accident I do something like that, I am going to reinstall my OS, in case it is compromised. This is standard practice. Not on Windows, but Windows is a very insecure OS.
In reply to That is not how installation… by kresimir
When you tell someone they've likely installed malware and should reinstall their OS, you've gone too far.
I'll continue this discussion when you edit your previous posts to retract that.
In reply to When you tell someone they… by Marc Sabatella
While I disagree that I've said that, in good faith, I've edited the offending post in order to soften the rhetoric. It was not my intention to say what anyone should or shouldn't do, just what I would do in such a situation. Now my post explicitly states that, as well as my reasoning for it, and I believe it is more accurate to what I wanted to say.
In reply to While I disagree that I've… by kresimir
I appreciate the gesture, but no, sorry, still completely uncalled for and harmful to the community to be spreading propaganda about systems being “compromised” and that somethjng or other is “untrustworthy”. Hundred of millions of people run installers every single day - not “accidentally” but deliberately in order to install the software. Suggesting that this is somehow different and that people have any cause for concern whatsoever without providing one single shred of evidence is out of line.
In reply to I appreciate the gesture,… by Marc Sabatella
I don't know what else do you want me to say. If you execute with root privileges a binary file you received from the internet and you don't know where that binary came from or what is in it, it is wise to consider your operating system to be compromised and untrustworthy. The binary file had the opportunity to install literally anything on that computer. This is a fact, not "propaganda". If you disagree with that, I'm sorry to tell you, but you are factually wrong.
This is especially important on Linux, where you don't habitually use malware scanning software (because most of the time, that's unnecessary). The rule is simple: do not download files and execute them as root, even if you trust the source (because their servers could be compromised without anyone knowing). Use your distribution's package manager (or "app store" or whatever you call it), preferably one that checks the shasum of any binary download. That's the most basic computer security.
If you think that is "harmful to the community" and uncalled for, then we are living on completely different planets.
In reply to I don't know what else do… by kresimir
I wonder what your stance about AppImages/Flatpack and Snaps is, given those all don't come from the default repositories. Or any ppa from launchpad.
In reply to I wonder what your stance… by jeetee
Naturally, I am very cautious about what AppImages, Flatpaks, and Snaps I run (as a matter of fact, I don't run Snaps at all, but for other reasons). If the same software is available in my distribution's official repositories, I prefer that over any Flatpak or AppImage. More importantly, however, I never run any of them with root privileges. Never. There is simply no need to ever do that.
I don't use PPAs because my distribution does not use PPAs (that's a Debian concept, I use Arch). I've never needed to add any third-party repository, and my distribution's maintainers explicitly warn against doing so.
In reply to I don't know what else do… by kresimir
I totally agree. Most companies operate a zero trust policy and any training course on basic security also encourages that. Things that can improve trust include making software with least needed rights, having some certifications like the ISO ones to show that you take security seriously etc. Your software is not safe just because you say it is.
The quality of Muse4 is poor in my opinion and not yet quite ready. Given the sheer number of bugs it is likely that there will be some within the hub and for that reason I have removed it since it is a potential backdoor exploit.
My experience on Windows with the hub was not good. A real hog and very difficult to remove and how can muse justify it connecting peer to peer by default without asking permission.
When Muse starts up why not just get it to check for updates and ask me if I want new versions rather than this service that seems to be always on.
In reply to I appreciate the gesture,… by Marc Sabatella
Let me try to defuse this discussion about the nature of MuseHub and why it wants root access. At the end I will present my take on it.
Sorry for a lenghty post, but the material is complex and needs careful treatment to be more than a yes/no discussion. I hope it makes for an easy read.
As I understand Marc Sabatella, the purpose of MuseHub is to make life as easy as possible for the user, by taking care of all the hassle in installing and maintaining software from the "Muse Family". Extremely important, and very laudable. For this, it needs root access, as is customary for an installer.
As I understand kresimir, he is worried that by allowing root access to MuseHub there is a danger that his system might become compromised. He even seems to have suggested in an earlier post that MuseHub itself is malware. If that is indeed the case, I think that was uncalled for. Yet his concerns, if they are valid, need answering.
What I hope is that by putting the discussion in a different light, Marc and kresimir will find that there is common ground to be found, to the benefit of all users of this marvelous program called MuseScore.
Please bear with me while I present a metaphor.
================
There is a factory that produces all kinds of wonderful products. It is organized in workshops. Some workshops convert raw materials to semi-finished products, that are used and combined by yet other workshops to create yet more semi-finished products, which, at the end of the chain, are delivered to final workshops that produce the finished products which go to customers and are the very reason for the factory's existence.
Basically, the factory is an infrastucture for hosting facilities that produce consumer products.
This whole factory is an incredibly complex organization, but luckily this remains hidden from the customers who without worry can obtain their favourite products from it.
This whole complex facility is run by the factory manager, who is responsible for its smooth operation and to make sure that the products satisfy standards of quality and security. On a higher level, he must guard against threats to the entire factory's proper operation, either in the form of theft of materials or in the form of sabotage, or simply caused by errors in the complex internal organization. Such disruptions could affect many or all workshops and customers.
The workshops themselves are physically located inside the factory, but they are usually developed by third parties. When being incorporated, they need to be connected to other workshops. From time to time they need to be upgraded, which may include modifying their requirements from other workshops.
For the purpose of this discussion, I assume that there is a workshop producing finished product, and that its developers have created a way to improve the product. For that, they need to replace a machine.
Now there is the problem of making that happen.
The developer says: I need the key to the factory to install my machine. Give it to me, I will install my machine, and all will be well.
The factory manager says: No way I let anybody inside my factory. The key is mine and mine alone.
How to solve this problem?
================
Back to reality: The factory is the computer. The workshops are user programs and system services. The developer is, indeed, the developer of new or improved user software, for the purpose of this tale personified by Marc. The factory manager is the OS, personified by kresimer. The key to the factory is root access.
Marc says: I have the best of intentions. I want to make life easy for everyone. Give me the key and all will be well. Besides, in no factory in the world developers can install machines without the factory key, so I need it. What's your problem with that?
kresimir says: If I give you the key, you can access everything in the factory. You may, in good faith, disturb something that is vital to the factory without you realizing it. And if I hand out the key to you, the next one asking for it may not be so well-intended. They may go into other workshops and sabotage them. They may be industrial spies. It is my responsibility to see to it that such things don't happen. I simply can't let you, if only out of principle.
The solution to both Marc's wishes and kresimir's concerns is simple: Let kresimir do the installation for Marc, on his instructions.
Back to the metaphor: The factory manager installs the machine in the workshop on behalf of the developer.
And in fact, that is what happens in practice. Many programs alert you when there is a new version, and even offer to download it for you and start the installation process. But the installation itself they do not perform. That is the OS, activated by you, when you provide your password. It may seem to the user that the program is doing its own installation, but in reality it is the OS doing it. The program does not need root access for that.
Applied to the MuseHub case: There is no need to give MuseHub root access, and indeed it is a bad idea. It is sufficient to let MuseHub, when there is an update, download the files and prepare everything, and then invite the user to enter the password to endorse installation by the OS.
This is how it usually works. A small inconvenience, to be sure, but a vital safeguard against compromising the computer, even if no ill intentions are assumed.
I hope this tale presents and motivates a solution that is acceptable to all.
In reply to Let me try to defuse this… by user2442
I think a much better analogy is of a boyfriend who demands his girlfriend give him all her passwords and access to all her social media accounts, email, phone, computer, personal diary... He promises he will not abuse this privilege, but he is asking for it. He may be the nicest guy in the world, his motives may be completely pure and innocent, but he has crossed a line that he should not have crossed. This makes him look like a very manipulative, jealous, control freak. My impression of him may be completely unfair, but his actions paint him in this light and it's hard for me to resist having this bad feeling about him. My advice to the girl would be: "tell this guy to get lost." And if she had given this guy her email password, my advice would be: "change your password." I fully concede that this may just be my prejudice -- I have no hard evidence of him being malicious, and I not given him a fair trial -- but I still think his behaviour is unacceptable, no matter what his motives are.
Same thing with MuseHub. It probably isn't malware, it probably doesn't have any ill intentions. But its actions sure aren't giving me any confidence and reasons to trust it. It does not need my root password to give me MuseSounds. It does not need root privileges to check online what the latest version of MuseScore is and tell me if MuseScore I'm running is outdated. I does not need to run a service 24/7 that won't shut down when I tell it to. It could just give me the soundfont and get lost (moreover, why can't I just download it with my browser?). But it won't. It wants full control over my entire system and my absolute and blind trust.
And when I say: "whoa, that seems a bit suspicious and out of my comfort zone!" as a reply I get: "that's libelous, uncalled for, and harmful to the community!". It is as if I am in this twilight zone illuminated by gaslight, and nobody has any notion of how absolutely outrageous it is to even suggest having such a service run with root privileges. It's exactly like that boyfriend saying: "If you loved me, you'd give me your email password! You are paranoid and crazy, and you are harming our relationship!"
In reply to I think a much better… by kresimir
This is a good representation of how I see this situation, also. If the software in question does what it says it does, then it does not need root privileges, and asking for such privileges will justifiably make people wary. Even if the root privileges are for installing stuff, it's always possible to install them in user space to avoid this security flaw.
In reply to I think a much better… by kresimir
A much nicer analogy to bring about your stance on the matter indeed.
Please note that you didn't get called out for questioning whether the Hub should actually need those rights or not. I believe there's a good case to make that it does likely not need them; although I can also imagine they'll have some reachitecturing to do as they likely now build on top of the expectancy of the background service.
You got called out/countered for seemingly telling others they should resort to a fairly drastic and impactful task of reinstalling their OS. A statement you've now kindly adjusted to clearly state would be your course of action.
Your first reply simply wasn't as nuanced as "whoa, that seems a bit suspicious and out of my comfort zone!". The resistance you met was more about the tone than about the contents; which is always a difficult thing in online written forum posts.
I think it's a good thing (tm) that people such as yourself and graffesmusic point out the risks involved with privileged software and are right to challenge the notion of necessity for the Hub to be(come) such a piece of software.
I do hope that as mentioned before you've also raised these concerns and remarks to the Hub team via their service site so that something (at the very least a founded answer, but preferably a better version of the Hub) can be done about this by them.
In reply to A much nicer analogy to… by jeetee
Yes, a better analogy to bring out kresimir's stance.
But that was not what my metaphor intended to do. It was intended to defuse the situation. Repeating your stance in different words is not helpful for that.
My metaphor was meant to, by analogy:
(a) clarify that allowing root access is really opening the door to any harmful action one can think of, intentional or not, and by implication should be an absolute no-no
(b) make clear that root access is in no way necessary for installing software.
Both things kresimir is well aware of, but others may not be, and in good faith defend root access without realizing both points above: extremely dangerous, and not needed.
In reply to A much nicer analogy to… by jeetee
Yes, my original wording was a bit harsh, I admit. I didn't mean it in that way, but now I see how it might have been understood in that light. I think my thoughts on the matter are now much more clearly expressed, after my original post has been challenged.
In reply to A much nicer analogy to… by jeetee
> there's a good case to make that it does likely not need them
Oh, it doesn't need them, for sure, with some effort you can make it function without root access. The reason it asks for it is just a combination of lazy software development practices and probably the desire to offload the ungodly traffic requirements onto the users to some extent, as the service functions kinda like a torrent client IIUC (it's not like they hide it).
The funny thing is, they could've just as easily done the autostart and torrenting thing without root access, too, and avoided this whole "annoyed LInux users" story, but for some reason they didn't ¯\_(ツ)_/¯
In reply to This isn't evidence of… by Marc Sabatella
@Marc Sabatella ("Almost all installation programs for almost all binaries on almost all operating systems require root / admin access"): That is correct, but that is not the point. The issue is not that the installer needs root access, it is that the installer installs a user program with root access. This is a serious breach of security. Normally root access is reserved for system programs. User programs with root access are very rare. This kind of access is usually reserved for programs that really need full access, such as virus checkers. Thoroughly tested and highly trusted programs. Repeat: Having root access in a user program is high risk.
There is no need for the Hub to have root access, except for installing programs without the user's knowledge. Asking the user for permission when new software is to be installed is the norm, and is done for a reason. And what is wrong with asking the user for their password when a new version is available, as has always been the case with MuseScore?
In reply to @Marc Sabatella ("Almost all… by jimfoster
MuseScore has never had an automatic update facility before, so there has never been anything in MuseScore that would suddenly prompt for a password.
As mentioned, Muse Hub - the program being installed - is an installer. It installs files into /usr/lib, etc. Thus, it currently needs to have root access. But re-designs are being considered where maybe those files could be in a user space. See the discussions on the official Muse Hub support site at musehub.zendesk.com - that's where the formal discussions of this (and any other) issues take place.
In reply to MuseScore has never had an… by Marc Sabatella
You conveniently ignore the crux of the matter, that is, why build an installer if the OS's have a perfectly capable, safe installer for you? Whereas the installer they built puts the user at serious risk for malware infiltration?
If the MuseHub developers do not know where to put content other than programs in a safe place where it can be found, which is very easy to do in a number of ways, they have no business meddling with installers. And nobody should trust them with such.
In reply to You conveniently ignore the… by jimfoster
The built in installer on most systems does not allow for auto update or for torrent support (the files download are 15 GB and greatly benefit from
This).
Anyhow, again, if you’d like to read over what the developers have actually said, and still find the need to offer additional input, the place to do so is on the official Muse Hub sup0ort site. No one here has any connection to that project whatsoever, so there is no point in continuing this discussion here.
In reply to The built in installer on… by Marc Sabatella
This again makes no sense. You don't need root access for torrent.
And if you take the trouble to read through the thread on this on the MuseHub forum, you will see that they say a lot but do evade the serious questions.
In reply to MuseScore has never had an… by Marc Sabatella
Do we scan for this general issue across the support site, or what particular thread most applies to this thread? I believe I've seen at least 3 threads over there...
In reply to Do we scan for this general… by Are Jayem
OK, I'm referring to https://musehub.zendesk.com/hc/en-gb/community/posts/8450771193629-Muse….
In reply to That is going way too far… by Marc Sabatella
The vast majority of software on Linux is open source though.
I don’t want to suggest MS is doing this, but there have been some very high-profile examples of companies installing malware on Windows, particularly gaming companies, not to mention Sony secretly (& illegally) changing system files in Windows.
-
In reply to I am glad it worked. How do… by andressegarra
Ok, i did some tests to run this as a non-root user (but without any luck)
1.Add new system user/group
sudo groupadd musegroup
sudo useradd -r -g musegroup -s /bin/false museuser
sudo chown -R museuser:musegroup /srv
sudo chown -R museuser:musegroup /opt/muse-hub/
3.modify service
sudo vi /etc/systemd/system/muse-hub.service
add under [Service]:
User=museuser
Group=musegroup
4.start service
sudo systemctl start muse-hub.service
status:
sudo systemctl status muse-hub.service
Loaded: loaded (/etc/systemd/system/muse-hub.service; disabled; vendor preset: disabled)
Active: active (running) since Mon 2022-12-19 17:18:48 CET; 271ms ago
Main PID: 5145 (muse-hub-servic)
Tasks: 11 (limit: 18854)
Memory: 9.8M
CGroup: /system.slice/muse-hub.service
├─5145 /bin/sh /usr/bin/muse-hub-service
└─5149 /opt/muse-hub/Muse.Service
Service running as user museuser:
museuser 8248 1 0 17:28 ? 00:00:00 /bin/sh /usr/bin/muse-hub-service
museuser 8249 8248 90 17:28 ? 00:00:01 /opt/muse-hub/Muse.Service
But guess what:
=> tail service_log.txt
2022-12-19 17:17:38.4838|FATAL|Program|The Muse Helper Service needs to run under sudo to function correctly.
2022-12-19 17:17:47.4353|FATAL|Program|The Muse Helper Service needs to run under sudo to function correctly.
This is very disappointing.
I am aware that the service need root privileges to install updated deb packages, but the goal is exactly to prevent automatic installations in the background without even warning about this.
Anyway.
I certainly do not think the company want to install malware on our systems. But they could if they wanted.
But did you consider that, if a vulnerability was to be found in the muse-hub.service, a attacker would gain root access to our computers?
You certainly can see how this is a potential security problem.
In reply to Ok, i did some tests (but… by graffesmusic
If you didn't already, please report this to the Hub team as well via https://musehub.zendesk.com/
In reply to If you didn't already,… by jeetee
I did exactly that on 25 December (https://musehub.zendesk.com/hc/en-gb/community/posts/8450771193629). Never got a reply. Even asked support whom to approach with this. No reply.
Another user reported, in the same topic, evidence of sloppy programming of the Hub.
So, there is a poorly programmed service with root access that runs permanently and has open ports to the Internet. And the company does not deign to react to serious warnings about the situation.
What I don't get is that MuseScore still advocates the use of this piece of software without even warning their customers.
In reply to Ok, i did some tests (but… by graffesmusic
I had a bit more luck: https://musescore.org/en/node/339560
In reply to Ok, i did some tests (but… by graffesmusic
Where is 'service_log.txt" ?? I'm on Ubuntu 20.04 & I want to examine it.
OP here. I think we "Chromebook-with-Linux" users are different than experienced Linux users and may not be so worried about "compromised" systems (at least I am). A Chromebook restore is a "powerwash" away and easy to do. I do not store any valuable data on my Chromebook anyway.
I do know that with MuseScore 4 my scores sound much better than with 3 and it was somewhat easy to set up and I do not have to run expensive Windows or MacOS. So, for almost free, I get a ton of benefit and I do not have to spend time fussing with the technicalities of my computer. For me, MuseSounds is good-ware . . . the very opposite of mal-ware! I will leave it to you professionals to file bug reports and spend some time helping this to be the best it can be for every level of user.
In reply to OP here. I think we … by scottlawrencelawson
This illustrates the point: "[i] may not so worried about compromised systems"
Most users don't care about security and are confident that the software 'vendor' is delivering secure software.
So Musescore is installed on 5 million computers?
Then it is the absolute moral obligation of the Muse Group to deliver software to those 5 million users that is as secure as possible - by design.
I am pretty sure this kind of design would not pass any security audit in a corporate environment - besides the fact that the torrent protocols would be blocked anyway in a reasonably secured network.
Contrary of what has been said, exposing bad security by design is meant to be helpful to the 'community'.
I find that stopping the background muse-hub service does not affect musescore - it works fine without it. Apparently only the muse-hub downloader "needs" it. I can't see why, but it does. So let it run, download the Muse Sounds, and shut it down again.
In reply to I find that stopping the… by [DELETED] 171629
As mentioned from the start, the use of the Hub is entirely optional and only required if you wish to download and install the optional Muse Sounds library.
In reply to I find that stopping the… by [DELETED] 171629
To be clear: Muse Hub needs the service to install updates automatically in the background. If you're content to re-run Muse Hub manually every few days to get the latest updates, then indeed, no harm in shutting down the background service.
In reply to I find that stopping the… by [DELETED] 171629
Just to be clear: once you've run any proprietary program with root privileges, there is no guarantee that your computer is not compromised. Now, I am not saying that MuseHub is malware, it probably isn't. That's completely beside the point. The point is that there is, theoretically, no way to be sure. This is a fact, with any proprietary software run as root. When you run a program with root privileges, you have given it your consent to modify your computer in whatever way it wants. Even if you shut it down, there is no guarantee that there were no permanent modifications done to your operating system. Detecting those changes, especially on Linux, is extremely difficult (since Linux does not use malware scanners, since it doesn't need it, if you don't run random programs as root).
So in the end, it comes down to blind, unconditional trust. It is up to the every user to decide whether that trust is deserved or not. It is certainly not my place (or anyone else's) to tell anyone what to do with that.
In reply to Just to be clear: once you… by kresimir
Running the program as root, with its network connections for bittorrent functionality, is always just one remote exploit away from handing root priviliges away to a random hacker even if the software would do nothing malicious by itself.
It is baffling that any software company would have such bad security practices.
In reply to I find that stopping the… by [DELETED] 171629
It is in any case used for "community distribution", where your computer helps others to download the apps and soundfiles by providing bits and pieces of the files on request. MuseHub uses the bittorrent protocol for that, and that is handled by the background service. But that can be done otherwise.
Installing updates without user intervention is indeed another function, but that could just as easily be handled by asking the user for permission once it has been downloaded. That is now not needed, since the service has write access to important system areas. That is convenient, but not safe "by design". It is a sound principle to give software not more power than is really necessary.
In reply to It is any case needed for … by user2442
Running as root is definitely not necessary for sharing files via the torrent protocol. I run qBittorrent pretty much 24/7 to share all sort of stuff, but never as root.
If you want to share stuff via the torrent protocol, the best and easiest way to do is via public trackers. Super simple, no need for proprietary software that won't run by design if it doesn't have root privileges.
In reply to It is any case needed for … by user2442
The developers chose to install muse-hub files in a protected part of the file system. (/srv on Linux). They did not need to do that. In fact there is a setting to install the MuseSounds files somewhere else, and I made use of that because my system/boot device is not that large and I do not like having such huge application files there.. But still, the muse-hub control files are written to /srv. Managing access on a multi-user system is MY problem. It should have prompted for the file location up front, not left it under a settings menu that I did not discover until I was trying to find out where all my system device space went.
Downloading updates in the background without manual intervention is a very bad idea. I have never run into another application, or even system software, that does that.
The bittorrent feature is optional, and I turned it off. It should not even be on by default. ASK FIRST: "Do you want to participate in the torrent distribution of MuseSounds files?" There are perfectly good reasons for not wanting to do this, such as being on a slow or volume-sensitive internet connection. In any case, background services do not have to run as root (at least on Linux).
In reply to The developers chose to… by [DELETED] 171629
For the record, it's not just about the sounds installed to /srv, but about Muse Sampler, which is an executable (shared library) installed globally.
In reply to The developers chose to… by [DELETED] 171629
I checked, and even after I turned bittorrent off, the service kept the port open. Only after quitting MuseHub it stops listening.
But it keeps running, even after "Automatically keep apps up-to-date" and "Automatically keep sounds up-to-date" are unchecked.
I see no need for it to keep running if both automatic updates and bittorrent are switched off.
The system log keeps repeating the following message:
2022-12-21 17:07:37.180 Df launchd[1:2f521] [com.muse.museservice:] This service is defined to be constantly running and is inherently inefficient.Wouldn't it be better to drop the service altogether and make it a user program that checks from time to time and alerts the user when an update is ready for installation? Also in light of the concerns around its root privileges, which seem overkill for what it does.
In reply to I checked, and even after I… by user2442
On Linux it is "sudo systemctl disable muse-hub" to permanently make it go away even after reboot. I don't know the equivalent on Windows or Mac but there must be one.
In reply to On Linux it is "sudo… by [DELETED] 171629
Nice. But not for the everyday user...
MacOS (12.6) does not have this command. But "Uninstall" from the MuseHub Settings interface cleans everything, including running of the system service. Removes the file even.
Of course, that means you have to reinstall MuseHub when you need an update to your MuseSounds. (MuseScore 4 can be downloaded without MuseHub.) And it does not undo the problem that a root-privileged program has run of which you know little. Probably theoretical, but still better not.
In reply to On Linux it is "sudo… by [DELETED] 171629
See my comment here:
https://musescore.org/en/node/339231
If you start muse-hub.service manually to check for an update, and a new package is (silently) installed, then it will be enabled again (on debian-like systems)
In case it’s useful to to other Arch & Arch-like users, there is a package in the AUR (muse-hub-bin) so you don’t have to muck about with the .deb
A few observations collected in one place:
1. The proper way to install product updates is to use the system package update facility. Everyone is used to that. Using AppImages is a cop-out - just do it right. Everyone else does.
2. You should never install product updates automatically. It is invasive and can be confusing to the user. I don't like that the Tor Browser does it. If the system update package has a facility to do automatic updates, then the user can make use of that. It is not as though updates are going to be coming out that often anyway.
3. On Linux, /srv is the wrong place to put application settings files - those go in /etc.
4. You should not leave ZIP files lying around after installation, like musesampler-linux-0.3.2.18.tar.zip and especially not in /srv.
5. For things as big as sample files, you should ask the user at install time where these should go. The MuseSounds library is already as big as my entire system files directory and I am sure it will grow.
6. Having a community shared download accelerator is a clever idea for things as big as sample files, but its existence should be announced up front with an OPT-IN. If not enabled, then a background service is not needed and in any case should not be running as root. (see point #1)
7. Don't announce big releases just before a major holiday. Everybody needs to be at their desks. In fact, I worked for a guy once who had a rule never to install dot zero releases of anything. This was at a commercial IBM shop.
In reply to A few observations collected… by [DELETED] 171629
I cannot speak to any current decisions or plans, only to to the past history. And I can say, AppIMages are far from a copout. They were the solution to a very real problem we experienced for many years, a problem that has not gone away and in fact has only gotten worse:- repository maintainers building MuseScore incorrectly and/or not updating it in a timely fashion. There are still repositories out there offering three-year-old versions of MuseScore, and in many cases, even when current versions are offered, they contain additional hard-to-diagnose bugs because they were built with incorrect flags or with incorrect versions of dependencies etc. Which is understandable - building MuseScore correctly is difficult, and updating repositories every time someone makes an update is a full-time job I'm sure. And who will test all those third-party builds?
So users are certainly welcome to try to install MuseScore via repositories if they care more about the "proper" way of installing than about actually having current and correctly working software. But for users who care more about results than about theories, that's why the AppImage option exists - to better serve users who want the current version and want some assurance that it is tested and working as well as possible.
Delivering ".deb" files is an alternative to be sure, but it excludes a large number of users on distributions that don't use that format.
BTW - regarding the files placed in /srv - for the most part these are not "settings" files of course. I suppose you are suggesting, the sample files could be there, but then the settings files only moved to /etc? I guess that's possible, not sure what advantage it has. But for the record, you do have the option of choosing an alternate location, via the settings button in Muse Hub.
In reply to I cannot speak to any… by Marc Sabatella
You can see the way to set the library location IF you think to look at the Settings menu before clicking the GET buttons. What I am suggesting is that it should be a forced question the first time a GET button is clicked. Or maybe just present the whole Settings page first.
In reply to You can see the way to set… by [DELETED] 171629
That's certainly a possibility that the development team could consider someday. Have you suggested this on the official Muse Hub issue tracker at musehub.zendesk.com?
In reply to I cannot speak to any… by Marc Sabatella
On my Chromebook with Linux, the AppImage made getting MuseScore easy and successful, so I would be sad if this was not available for some technically "pure" Linux reason. So, from a person who just wants to use the software as a hobby, thank you for making this method available!
In reply to On my Chromebook with Linux,… by scottlawrencelawson
Yes, and I think a lot of Linux users and developers agree with you on that. AppImages are great to solve problems with library dependencies for applications and I think Musescore is exactly the kind of project that benefits a lot from such "containerized" distribution formats. I don't think there's a generally agreed-upon "Linux reason" against that. The user may prefer to update the application from a community maintained repository, but even some of these, like the AUR in arch, allow for AppImages to be used, so your AppImage can be updated with the same tools you use to update everything else in your system.
Of course, just how easy it is to install an AppImage should be one of the many arguments on why MuseHub doesn't need root privileges to work. Installing Musescore is essentialy downloading a single file to a folder, like ~/.local/bin or whatever, and maybe also a desktop entry on ~/.local/share/applications. And the same applies to sound libraries, just files downloaded to some folder.