openHAB 2.5.x Patch Releases

But if @halloween want’s updates for the current 2.5 release (e.g. 2.5.1-2) then it would make sense to change the URL in the repo file, correct ?

Well, the most appropriate URL for stable releases is the repo you mention, but the version is available from the unstable repo too. New releases of openhab2-addons will appear as snapshots in unstable and as full releases in both stable and unstable.

I’m a little bit confused.
From
https://ci.openhab.org/view/Integration%20Builds%20(2.5.x)/job/openHAB-Distribution/
we already have 2.5.2-snapshot.
But I am unable to get it via openhabian or via
sudo apt-get update/upgrade.
It always tells me I am already on the newest version that is indicated as 2.5.1-2 (Release Build).
I would especially being interested in the zwave fixes.
Any ideas?

There have been usually 3 different OH versions at any one time.

Stable. The current version is 2.5.1
Testing or Milestone. There is not a current release now.
Unstable or Snapshot. There are currently 2.5.2 snapshots sometimes released daily.

Testing snapshots are not expected to be fully functional. They are designed for integrated testing for developers with issues reported to GitHub.

Milestone releases aIm to be fully functional and are designed for wider testing. As a version matures there are sometimes Release Candidates here too.

Stable releases are fully functional designed fir everyday use.

If you need just the zwave binding there is a Zigbee and zwave update script here to make installation easier.

All, we have just published the patch release 2.5.2 - see its release page for details!

In constrast to the original plan stated above, there is again a distro 2.5.2 available, although the distro itself is more or less identical to version 2.5.1 since all changes only concern the add-ons.

This also means that the 2.5.2 patches are directly available to any 2.5.1 distro installation as well without doing a distro update. If you install new add-ons - or you delete the cache and have add-ons reinstalled - the distro will pick the latest patch version of the add-on.

IMPORTANT NOTICE TO USERS OF THE EXEC BINDING:
Due to this security advisory, the exec binding requires to have a whitelist of allowed commands to execute. Note that when updating the exec binding to version 2.5.2, it will stop functioning until you provide such a whitelist. Please see the binding documentation for details and also check this post for a detailed how to.

13 Likes

9 posts were split to a new topic: Security limitations in 2.5.2 exec binding

Because I was a bit confused how to update from 2.4 stable to 2.5 stable I was waiting until 2.5 is really stable. I guess now with 2.5.2 it is.
How do I get now that 2.5.2 correctly installed, just via the GUI?

Thank you, Kai! Will there be a separate announcement for 1.x addons? (nudge)

3 posts were merged into an existing topic: Security limitations in 2.5.2 exec binding

Regarding the security vulnerability: it might be interesting to mention that following an initative by the architecture council, openHAB now has a Security Policy and participates in the Common Vulnerabilities and Exposures (CVE) program. You can report vulnerabilities to security@openhab.org and they will be discussed privately until a security advisory and CVE are eventually published.

This remote code execution vulnerability (CVE-2020-5242) involving the exec addons is actually pretty nasty so now that it’s out there, all users are strongly advised to upgrade to 2.5.2 whenever possible, even if you don’t use the exec binding or transformation.

7 Likes

Was there any reason why there was not at least an attempt to read in current exec definitions from the JSONDb to initially populate a whitelist? That could have eased many upgrades.

1 Like

The advisory board now believes openHAB should be secure. The openHAB now needs authentication doors to secure its entrances.

I guess we will see an authentication update for 2.5.x. Lack of any authentication has always been the largest and most severe OH security vulnerability. If there were authentication and authorization then this whitelist may not have been necessary.

6 Likes

This would be great.

With the REST API and WebUIs, Items and Things can be discovered, added, changed, & deleted without by any unauthenticated user. Considering they are acknowledging unauthenticated access to the REST API (and I assume, the WebUIs) I see only 2 possibilities

  1. Remove all UI & API management capabilities, reverting back to text file & CLI configuration

  2. Add authentication to OH.

1 Like

Adding authentication would enable creation of roles and users. Imagine access-restricted sitemaps!

2 Likes

That’s actually a good idea, and it’s not too late.
Install jq with apt-get or similar, create a new misc folder in your configuration if it doesn’t exist and “cd” to it, then:

  • To put all commands of existing exec things to the whitelist, this command should work:
    curl http://localhost:8080/rest/things | jq -rM '.[] | select(.UID | startswith("exec")) | .configuration.command' | sort | uniq >> exec.whitelist

  • To put all commands when the exec transform is used as a link profile in the whitelist, this command should work:
    curl http://localhost:8080/rest/links | jq -rM '.[] | select(.configuration.profile == "transform:EXEC") | .configuration.function' | sort | uniq >> exec.whitelist

Note, you might have other instances of EXEC(commands) directives in other places to perform transformations (thing configurations like MQTT, item labels…).

9 Likes

Only if they add authorization too. Really they should add accounting so you know what a user did too. Together they are normally referred to as AAA

1 Like

The user community occasionally has useful ideas… :rofl: :roll_eyes:

Indeed. There’s already an audit.log file which could support the accounting purpose.

Without authentication, you do not know WHO did something though.