PDA

View Full Version : piCorePlayer: how to tell if Squeezelite ought to be updated?



peterw
2019-03-30, 06:39
The web UI has prominent update buttons and tells me what version of Squeezelite I'm running, but I don't see how to determine if that version is current.

It appears that:
- the basic Update blindly updates each time, even if I'm already up-to-date
- the Full Update will tell me if I"m up-to-date, but only after I've committed to installing the update and rebooting

How can I determine if I'm up-to-date without committing to update Squeezelite?

It would be nice if PcP linked to some sort of change log telling me what a newer release offers.

Thanks.

paul-
2019-03-30, 06:51
We donít change squeezelite much.

peterw
2019-03-30, 08:03
We donít change squeezelite much.

Cool.

Feature enhancement idea: publish JSON data about stuff like this to a picoreplayer.org URL. Update the web UI to retrieve that data and compare its versions/datestamps to the installed system. Display info in web UI if updates available. Ideally each tracked feature should also track the datestamp of the most recent release with security implications (so the web UI could warn the user there was a security update even if the latest release doesn't contain any security fixes). E.G.


"packageInfo": [
{"id": "piCorePlayer", "currentVersion": "v9.2pCP", "updatePublished": "2018-09-01 12:00:00Z", "lastSecurityUpdate": "2018-08-23 12:00:00Z", "updateDescription": "Lorem ipsum..."},
{"id": "Squeezelite", "currentVersion": "v1.9.0-1121-pCP", "updatePublished": "2018-09-01 12:00:00Z", "lastSecurityUpdate": "2018-07-14 12:00:00Z", "updateDescription": "Lorem ipsum..."}
]

Ideally there'd also be some way to notify the user even if he didn't access the web UI for PcP. Too bad sending email has gotten so complicated (used to be any old system could just directly connect any email provider...). Maybe LMS should offer a way for a player to report problems to it? I don't see any current (LMS 7.9) CLI API that looks suitable. If PcP stored a similar file on the device then it'd be pretty easy to build a tool to run on a normal PC, Mac, etc. to do the comparison. Even if the web UI were disabled, a tool (or LMS extension) could use SSH to get the local file contents...

paul-
2019-03-30, 08:19
There Is no package management system, and really debatable if itís needed. The goal of pCP is to have as minimal footprint as possible, and itís all in ram or a read only filesystem.

Updates happen very infrequently.....months apart. If we do make small patch fixes, it is target at a major issue, and we talk about/announce it here.

DJanGo
2019-03-30, 11:15
Cool.

If you want a up2date System - use rasbian.

peterw
2019-03-30, 12:58
There Is no package management system, and really debatable if itís needed. The goal of pCP is to have as minimal footprint as possible, and itís all in ram or a read only filesystem.

Updates happen very infrequently.....months apart. If we do make small patch fixes, it is target at a major issue, and we talk about/announce it here.

I do appreciate that PcP can run off read-only storage, but that only really protects the PcP system itself. It still leaves PcP vulnerable to abuse as a platform for attackers (compromise the PcP host and you have a foothold on my LAN).


If you want a up2date System - use rasbian.

Is that really true? I see comments like this one from a few weeks ago (https://www.raspberrypi.org/forums/viewtopic.php?p=1437321) suggesting that Raspbian doesn't track Debian security fixes well (e.g., "The version of chromium we currently ship is relatively old, with many known CVEs fixed in later versions. I'm working on getting a newer version packaged up right now. I try to version things such that security fixes from Debian are picked up in favour of our changes, but most of archive.raspberrypi.org packages don't come from Debian and therefore don't get anywhere near the same level of scrutiny."). The fact that the Raspbian home page (http://raspbian.org/) doesn't have a security advisory link or even use https isn't encouraging.

It sounds like pure Debian is a mess (https://wiki.debian.org/RaspberryPi3) on Pi3 (e.g., "GPIO libraries work, but require some extra effort").

Ubuntu Mate looks promising, but of course not great that you can't even run its installer on a 3 A+ (https://ubuntu-mate.org/raspberry-pi/) because its 512 MB of RAM in insufficient!!! Looks like it might be time to reformat a MicroSD card and give it a shot, though.

Greg Erskine
2019-03-30, 14:40
How do you compromise any device that is on a "secure" LAN without physical access?

Anyway, getting squeezelite to work on a device is a simple task. It only gets difficult/time consuming when you try to make it suitable for everyone! :)

peterw
2019-03-30, 16:23
How do you compromise any device that is on a "secure" LAN without physical access?

Same way you sink an "unsinkable" ship like the Titanic. Find a flaw, exploit it.

The only relatively widespread attacks against Pis that I'm aware of took advantage of the devices running sshd with canned username+password pairs that had sudo rights, just like PcP. But it's my expectation that it wouldn't be hard for a "skilled adversary" to compromise even a PcP whose 'tc' password had been changed and whose web interface had been disabled.

If I were doing this, being mostly a web nerd, I'd probably start with web attacks (and give up what I expect is a small fraction of PcP users who disable the web interface). PcP's web UI totally ignores the request Host header, so it's probably easy game for DNS Rebinding attacks. Thanks to having no authentication ever and providing a web method for changing the password of the local root user**, it should be pretty easy to completely compromise a PcP box.*** Sure, if the user write-protected the SD card I'd only going to remain on the box until the power goes out, but that's something. BTW, PcP is in good company w.r.t. DNS Rebinding. (https://www.bleepingcomputer.com/news/security/google-roku-sonos-to-fix-dns-rebinding-attack-vector/)

Defense in depth is what I'm after. Same reason I pestered Slim Devices years ago to include CSRF countermeasures in the LMS web UI is why I'm a little uncomfortable running PcP on my LAN.


Anyway, getting squeezelite to work on a device is a simple task. It only gets difficult/time consuming when you try to make it suitable for everyone! :)

I guess I'll soon find out what it takes to get squeezelite and/or squeezeplay up on another Pi distro. I sure hope it's improved -- IIRC it used to be a real bear to get Squeezeplay running on PulseAudio systems, and I fear Ubuntu Mate will be all "modern" w/ PulseAudio, systemd, all that bloated new junk. :-(

** Any user with sudo is root-equivalent in my book.

*** It's a little shocking how PcP's web UI doesn't even require the current 'tc' password, as seemed to be common practice for many years with Linux-based embedded systems like WiFi routers. With the PcP web UI enabled, even if the user had edited sshd_config to disable password auth, the attacker could use the user commands or cron web config to re-enable password auth, reset the 'tc' password, and get in.