Cidram: Updates

[delle54]

Please make it possible to update all signature-files without updating CIDRAM itself. Reason: I can and will not update the php-version (currently 5.6.31) because of several reasons. THX.

[DanielRuf]

Hi @delle54,

5.6.31

New major releases will not support insecure PHP versions anymore (officially).

Generally you should be able to update the dat files in the frontend.

[ghost]

Use the front end for updating, you can choose selectively by hand.

@DanielRuf "insecure" is a highly depending on which OS that is in use. F.ex. does PHP 7.0 still get security updates on Debian while CIDRAM declares it not to.

[DanielRuf]

@DanielRuf "insecure" is a highly depending on which OS that is in use. F.ex. does PHP 7.0 still get security updates on Debian while CIDRAM declares it not to.

We can not know or check this. Still, 7.0 and older are not recommended and not supported by newer releases.

But this is not relevant when we use PHP features which are not implemented in previous PHP versions and this can not be solved with simple security patches.

[Maikuolan]

Worth noting: Per the CIDRAM version release guidelines (and per SemVer), the need to update the PHP version used in order to continue using CIDRAM, should only ever occur when new major versions are released (e.g., v2.0.0, v3.0.0, etc). In other words: Although the minimum required PHP versions for v1.13.0 and v2.0.0 (the current latest available versions for v1 and v2) are different, the minimum required PHP version between, say, v1.11.0, v1.12.0, and v1.13.0 is exactly the same, and will be exactly the same for all future v1 releases, and likewise, the minimum required PHP version between v2.0.0 and all future v2 releases will be exactly the same.

The minimum required PHP version for CIDRAM v1 releases is PHP => 5.4.0 (so, will continue working for your PHP version). The minimum required PHP version for CIDRAM v2 releases is PHP => 7.2.0 (so, would already require that you update your PHP version in order to use). The minimum required PHP version won't be increased from PHP => 7.2.0 until CIDRAM v3 (seeing as the version release guidelines demands that when increasing the minimum required PHP version, the immediately following release must be a major version release).

Currently, the front-end updates page won't automatically update between major versions anyway, because I still need to figure out how to do that properly and safely (v2 is ready, and is safe to use, but there are some changes between v1 and v2, which the front-end updates page isn't currently capable of automatically implementing; I'll figure that out soon though, after I sort out some other things first).

In short: Just selecting "Update All" from the front-end updates page, as per normal, won't suddenly force you to update your PHP version, so you can continue to do that at the moment without any worry. I'm currently thinking, too, that when I do eventually figure out how to automate the process of updating from v1 to v2, that I'll add in a few extra steps, to make it a little more difficult to do it accidentally (i.e., warnings, confirmations, some safety checks specific to major version updates, etc). I'll keep everyone posted about this when I get further with it and when it becomes relevant.

For CIDRAM users that can't update their PHP version to 7.2 or newer, I would recommend, for now, to just stick with CIDRAM v1, and to not worry about CIDRAM v2 until a later date, in the future, when they're eventually able to update their PHP version.

For CIDRAM users that update via Composer, that can't update their PHP version to 7.2 or newer, Composer should see the different minimum PHP version requirements between different major versions and automatically update only to the newest compatible CIDRAM version, avoiding any CIDRAM versions that aren't compatible with the available PHP version (Composer is designed that way).

For CIDRAM users that update via the WordPress dashboard, that can't update their PHP version to 7.2 or newer: I haven't been able to provide v2 onto the SVN system for WordPress anyway, because their pre-commit hooks are broken and don't like the new PHP 7.2 syntax anyway, so.. WordPress users will be stuck with v1 for the moment anyway, until that gets sorted out.

As far as the warnings about PHP vulnerabilities presented at the CIDRAM front-end homepage are concerned, they're just that: Warnings. CIDRAM presents those warnings to users when they log into the front-end homepage, but will never act on those warnings (nor is capable of doing so; if a user wants to update their PHP version, they'll need to do that themselves, or take that up with their hosting provider, because CIDRAM isn't capable of doing that for them).

[Maikuolan]

I should mention, also: The currently latest available CIDRAM releases for v1 and v2, both have all the exact same features, same signature files, same protections, etc (other than v2's removal of the in-built, pre-packaged CLI-mode support that v1 provides, and I plan to create a separate, pluggable script to handle that in the near future anyway). In other words: Whether you're using v2.0.0 or v1.13.0 at the moment, either way, you're not missing out on anything at the moment. :-)

The new major release needed to happen though, so that our hands won't be tied behind our backs, if/when we decide to implement something new in the future that absolutely requires the new syntax, new features, etc introduced in newer PHP versions, that can't be polyfilled/ported to older PHP versions. There's also maintainability concerns (lack of type-hinting for primitive parameter types and return types in older PHP versions, for example; these types of type-hinting are extremely useful as a means to reduce the risk of accidentally introducing new bugs with new features and changes that might be introduced in the future).

[Maikuolan]

I could probably add some kind of mechanism to update all components of a particular type to the front-end updates page anyway though. The front-end updates page is already able to determine whether a component is intended as an IPv4 signature file, an IPv6 signature file, a module, theme, L10N data or whatever else; adding such a mechanism would just be a matter of being able to filter components based on the type of component while updating everything, and finding a way to present that to users without messing up the page aesthetics too much. I'll experiment with this a little when I've got some time.

For the moment though, just updating each component one at a time, instead of updating all at once, or manually modifying the component metadata files, would generally prevent CIDRAM itself from being updated.

[delle54]

@Maikuolan: thank you. I was just about to be complaining that nobody understood what I meant.
I will stick to V1. Only updating the signature-files is fine for me.

[Maikuolan]

You're welcome. :-)

[ghost]

@maikuolan Updating from v 1 to v 2 must be a separate manual selection due to the increased prerequisites. Don't force that upgrade on anyone. See previous comment.

[DanielRuf]

We will provide migration guides, see #121.

[Maikuolan]

Temporarily reopening as a to-do: Ability to update all by component type.

[Maikuolan]

After playing around with the UI a little, I'm thinking that including an extra option just for updating all the signature files is probably sufficient (as opposed to adding new options for every different type of component). Anyway.. I've pushed some changes just now that add this option to the front-end updates page. :-)

Marking as implemented and closing.