apereo / phpCAS

Apereo PHP CAS Client

Home Page:https://apereo.github.io/phpCAS/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Version 1.6.0 is a breaking upgrade and is not compatible with older versions

jichangfeng opened this issue · comments

Insert new $service_base_url parameter in the middle of the parameters of the client function

tag/1.5.0: public static function client($server_version, $server_hostname, $server_port, $server_uri, $changeSessionID = true, \SessionHandlerInterface $sessionHandler = null) {}
tag/1.6.0: public static function client($server_version, $server_hostname, $server_port, $server_uri, $service_base_url, $changeSessionID = true, \SessionHandlerInterface $sessionHandler = null) {}

commit: b759361?diff=unified#diff-2dcd9774659f79c5f378e2663f575ba23a5a080b3608720a6516ab54a0da051f

If the calling code passes the changeSessionID parameter, the following error will be reported

phpCAS error: phpCAS::client(): CAS_TypeMismatchException: type mismatched for parameter $name (should be 'array, string, or CAS_ServiceBaseUrl_Interface object '), boolean given
commented

Yes, it is supposed to be a breaking change because we do require you to set sensible default config. We are not publishing minor version update for the same reason. For more information, please see the security advisory: GHSA-8q72-6qq8-xv64

Does that answer your question?

Understood. However, several projects have had problems because of this, and we can only temporarily fix the version to 1.5.0.

Anyhow, thank you for your reply.

commented

Well, you will need to make your own decision on whether you can take the risk to continue using the old version. It sounds absurd that you would just auto upgrade without any pinning in place.

Closing this.

Temporarily fix the version to 1.5.0 in the deployment phase, restoring normal access as soon as possible without changing the code. Modifying the code is a matter behind.

I agree with both sides of this conversation but would like to provide more context.

Yes, the CVE needs to be addressed and the change in behavior is a breaking change. That seems necessary and appropriate. As users of the package, we have responsibility to understand the change and adapt accordingly.

My first concern is the statement in the security advisory that:

phpCAS 1.6.0 is a major version upgrade

Yes, it is a major version upgrade, the version increment does not reflect that per semver expectations. This appears as minor release per semver. I'm sure many users would greatly appreciate following semver versioning for the package. Releasing this as 2.0.0 would make it much more clear that there are likely breaking changes to address.

My other immediate concern is that release includes other breaking changes that do not appear directly related to the CVE. After addressing the service discovery change, I encountered the error:

this version of CAS (`SAML_VERSION_1_1') is not supported by phpCAS 1.6.0

Yes, we still had SAML enabled. It was working fine in 1.5.0 and there is no indication in the release notes that support for it was being removed in 1.6.0.

After disabling SAML, I have run into additional issues, but have not pursued them in detail yet.

I do appreciate the time and effort required to maintain a package like this, especially when responding to security issues. I'm only expressing my opinion as a user of the package to plead for releases that make it easier for me understand and respond to the changes.

commented

@dstepe Thanks for the comment about the semver. Unfortunately I believe we have misinterpreted this twice in this project :(

For your other comment about SAML_VERSION_1_1, I am not sure what's going on here and you might want to open a separate issue. I don't think anything has changed in terms of that and it's still listed as supported

$supportedProtocols[SAML_VERSION_1_1] = 'SAML 1.1';

@phy25 thanks for the followup. I think you can disregard the SAML issue. I believe I introduced that problem while playing around with the update. The SAML_VERSION_1_1 is a constant and I inadvertently treated it as a string. Based on the code you shared, the value of the constant should appear in the error rather than the constant itself. The error stating is not supported by phpCAS 1.6.0 caused me to conclude it was another change in this release. Apologies.