As announced last week, today, we have renamed the "zf2" repository on GitHub to "zendframework".

Per the GitHub documentation on renames, existing links will be automatically redirected, and will persist as long as we do not create a new repository with the name "zf2". Redirects occur for:

  • issues
  • wikis
  • stars
  • followers
  • git operations

Update your remotes

While git operations pushing and pulling from the original repository URLs will continue to work, GitHub recommends you update your git remotes to point to the new location. You can do this with the following in the CLI:

$ git remote set-url origin https://github.com/zendframework/zendframework.git

Note the following:

  • Replace origin with the name of the remote you use locally; upstream is also commonly used. Run git remote -v to see what you're actually using.
  • Valid remote URLs now include:

Composer

Because Packagist points to GitHub, it will seamlessly redirect. Additionally, all sha1s for all commit remain identical. As such, there should be no impact to end-users for the change for existing installs.

We have updated Packagist to point to the new URL as well, so that as users update, their composer.lock files will start pointing to the new URL.

Source

As announced last week, today, we have renamed the "zf2" repository on GitHub to "zendframework".

Per the GitHub documentation on renames, existing links will be automatically redirected, and will persist as long as we do not create a new repository with the name "zf2". Redirects occur for:

  • issues
  • wikis
  • stars
  • followers
  • git operations

Update your remotes

While git operations pushing and pulling from the original repository URLs will continue to work, GitHub recommends you update your git remotes to point to the new location. You can do this with the following in the CLI:

$ git remote set-url origin https://github.com/zendframework/zendframework.git

Note the following:

  • Replace origin with the name of the remote you use locally; upstream is also commonly used. Run git remote -v to see what you're actually using.
  • Valid remote URLs now include:

Composer

Because Packagist points to GitHub, it will seamlessly redirect. Additionally, all sha1s for all commit remain identical. As such, there should be no impact to end-users for the change for existing installs.

We have updated Packagist to point to the new URL as well, so that as users update, their composer.lock files will start pointing to the new URL.

Source

In contrast to Zend Framework 2, which was a complete rewrite and break with the architecture of Zend Framework 1, the Zend Framework 3 initiative is more of an evolutionary change. We are laser-focused on keeping as much backwards compatibility as possible, and providing reasonable migration steps for our users. Instead of moving development to a new repository, we have split code into multiple component repositories, and made the main Zend Framework repository a "meta" repository, containing dependency information only.

Another way of putting it: changes to the main repository are happening incrementally, and version 3 will just be a new major version update within the existing repository.

However, such evolutionary change poses a slight logistical problem: the repository is currently named "zf2".

As such, we've decided to rename the repository to remove the version identifier. It will become simply "zendframework".

This naming is already reflected in our Composer package, which is named "zendframework/zendframework". Additionally, GitHub will provide long-lived redirects for all links to the repository, including those to issues, comments, pull requests, etc.; those redirects also work at the git level for each of HTTPS, SSH, and git protocol access. Because no sha1s change, this means that Composer installs will not suffer any issues, either.

We've also verified with GitHub that references of the form zendframework/zf2#... within commits, comments, etc. will continue to work, and redirect to the new location.

With all our concerns satifisied, we'll be making the change on 3 May 2016, and will post to the blog with details on how to update your git remotes to point to the renamed repository at that time.

Source

In contrast to Zend Framework 2, which was a complete rewrite and break with the architecture of Zend Framework 1, the Zend Framework 3 initiative is more of an evolutionary change. We are laser-focused on keeping as much backwards compatibility as possible, and providing reasonable migration steps for our users. Instead of moving development to a new repository, we have split code into multiple component repositories, and made the main Zend Framework repository a "meta" repository, containing dependency information only.

Another way of putting it: changes to the main repository are happening incrementally, and version 3 will just be a new major version update within the existing repository.

However, such evolutionary change poses a slight logistical problem: the repository is currently named "zf2".

As such, we've decided to rename the repository to remove the version identifier. It will become simply "zendframework".

This naming is already reflected in our Composer package, which is named "zendframework/zendframework". Additionally, GitHub will provide long-lived redirects for all links to the repository, including those to issues, comments, pull requests, etc.; those redirects also work at the git level for each of HTTPS, SSH, and git protocol access. Because no sha1s change, this means that Composer installs will not suffer any issues, either.

We've also verified with GitHub that references of the form zendframework/zf2#... within commits, comments, etc. will continue to work, and redirect to the new location.

With all our concerns satifisied, we'll be making the change on 3 May 2016, and will post to the blog with details on how to update your git remotes to point to the renamed repository at that time.

Source

This is an installment in an ongoing series of posts on ZF3 development status. In the last three weeks, we've done a lot:

  • ~160 pull requests merged, and ~110 issues closed.
  • Over 60 component releases.
  • Completion of the zend-mvc version 3 refactors.
  • All components are now forwards-compatible with existing v3 releases, including those that depend on zend-stdlib.
  • Progress on the documentation initiatives, including 11 new components documented.
  • Announcement of issue closures.

MVC Refactor

In the previous update, we provided a roadmap for the zend-mvc v3 refactor; at the time, we'd just begun the initiative, but still had the bulk of the work remaining.

As of last week, however, we have completed all tasks related to the refactor! These include:

  • a component installer Composer plugin, which will automatically inject installed components into application configuration as modules. (It is also forwards-compatible with upcoming Expressive releases!)
  • console functionality as a separate component (zend-mvc-console).
  • separation of controller plugins with additional dependencies into their own packages, including:
  • separation of i18n integration into a separate component (zend-mvc-i18n).
  • separation of the code for wiring zend-di into zend-servicemanager into a dedicated component (zend-servicemanager-di).
  • removal of all factories and integrations with components that fall outside the core dependencies.

This latter required that we move the various factories, service integrations, and event listener wiring code into the components themselves. This affected eight components, though we ended up addressing another five components that were already defining factories for zend-servicemanager as well:

  • zend-filter
  • zend-form
  • zend-hydrator
  • zend-inputfilter
  • zend-log
  • zend-navigation
  • zend-serializer
  • zend-validator
  • zend-cache
  • zend-db
  • zend-mail
  • zend-paginator
  • zend-session

For each of these, we created two new classes in their defined namespaces, ConfigProvider and Module. The first is an invokable class returning configuration, which might include service configuration, plugin configuration, etc. Module is a class specific to the Zend Framework ecosystem, and returns configuration, but, in several cases, also wired other code into the zend-mvc workflow. All of the above components received new minor releases once these were in place, and zend-mvc was updated to remove dependencies on them.

The core dependencies in zend-mvc are now:

  • zend-eventmanager
  • zend-http
  • zend-modulemanager
  • zend-router
  • zend-servicemanager
  • zend-stdlib
  • zend-view

Once we were done, the lines of code had dropped to approximately 25% of the size in the version 2 releases!

Skeleton application

With the zend-mvc refactor complete, we decided to work on the skeleton application.

Feedback we've had includes:

  • While having i18n support is interesting in terms of seeing how it's done, it's mostly worthless in the skeleton application. The provided translations are only valid for the home page shipped with the skeleton, which is replaced essentially 100% of the time with custom content. Additionally, it poses maintenance overhead with regards to reviewing and accepting new translations. Finally, with the split of zend-mvc-i18n, keeping it in meant adding additional dependencies which might never be used.
  • Related, we've had a lot of folks indicate that they'd like an option for a minimal skeleton. Many developers don't want the i18n, console, forms, cache, logging, and other facilities, or want to pick and choose which ones they configure.
  • As PSR-0 is deprecated, our skeleton should reflect PSR-4 for the default Application module.
  • Related, we want to encourage using composer for all autoloading.

To get the ball rolling, I created a pull request proposing a streamlined skeleton. This has already generated a fair bit of discussion, and we have a number of new ideas we're going to investigate, including setting up Expressive-like installation questions to allow bringing in common features during the first install.

JSON Refactor

We also did some refactoring of the zend-json component. Several users have complained that it includes too much: the JSON-RPC functionality is not generally useful for those who only want JSON de/serialization, and the XML2JSON implementation is only needed by a subset of users.

As such, we split it into three:

  • zend-json contains the JSON de/serialization logic only, starting with its v3 release.
  • zend-json-server contains the JSON-RPC server implementation.
  • zend-xml2json contains the XML2JSON implementation.

We'd like to thank Ali Bahman for his assistance with these changes!

Forwards compatibility

This week, we discovered half-a-dozen components that declare a dependency on zend-stdlib, but which had not been updated to allow usage with zend-stdlib's v3 releases. As such, we quickly updated each to do so, releasing new maintenance releases when ready. These include:

  • zend-code
  • zend-expressive-skeleton
  • zend-ldap
  • zend-mime
  • zend-soap
  • zend-xmlrpc

Documentation

With the MVC initiatives complete, we have begun working on the documentation in earnest again.

The first thing we did was recognize that while it's nice to be publishing the documentation, we really need mechanisms for navigating to other components. As such, we created a topnav button that, when clicked, fetches a list of components with documentation, and slides the list in from the top of the page.

We've also been either documenting components as we create them (see the MVC plugins and JSON changes, above), or publishing documentation as we create new releases on components we update. Since the last update, we've published documentation for the following components:

Many thanks to Frank Brückner for the copious documentation updates he's provided!

There's plenty left to do, however (32 components left at the time of writing). We've created a list of components and tasks to perform if you are interested in helping!

Issue closures

Last week, Gary Hockin posted to the ZF blog about a plan to perform housekeeping of issues posted against the main zendframework repository. The basic summary is: issues against the main ZF repository have been tagged as "To Be Closed", and will be closed in early May unless you comment on an issue and tag user @GeeH before 3rd May 2016.

Pull request and issue activity

Since the last update, we've merged around 160 pull requests, and resolved around 110 issues. (links require a GitHub account).

Notable releases

As noted at the beginning of this post, we've done over 60 component releases since the last update (approximately four weeks ago). Notable amongst them:

  • Zend Framework 1.12.18
  • zend-json 3.0.0, which removes the JSON-RPC and XML2JSON functionality (as those are now in separate components)
  • zend-inputfilter 2.6.1, which fixes a long-standing issue with localization of NotEmpty validation messages generated for required inputs.
  • zend-math 2.7.0 provides a security hardening patch for Zend\Math\Rand, forcing usage of PHP 7's random_bytes() and random_int() when available, and requiring ircmaxell/RandomLib for earlier PHP versions.
  • zend-session 2.7.0 updates the component to use ext/mongodb + the MongoDB PHP client library instead of ext/mongo, and adds session identifier validation by default.
  • zend-db 2.7.1 updates the Pgsql adapter to accept the charset option; fixes Zend\Db\Sql\Insert to properly manage arrays of column names when generating SQL INSERT statements; fixes an issue with how row counts were reported in Oci8 result sets; and updates the IbmDb2 adapter to allow # characters in identifiers.
  • zend-cache 2.7.0 offers a ton of new features, including a new APCu adapter, upgraded support for XCache and Redis, and numerous bugfixes.
  • zend-stdlib 2.7.7 and zend-stdlib 3.0.1 fix declaration of Zend\Json\Json::GLOB_BRACE when on systems based on non-gcc versions of glob.

Until next time

If you want to help:

Many thanks to all the contributors who have provided feedback, patches, reviews, or releases since the last update!

Source

This is an installment in an ongoing series of posts on ZF3 development status. In the last three weeks, we've done a lot:

  • ~160 pull requests merged, and ~110 issues closed.
  • Over 60 component releases.
  • Completion of the zend-mvc version 3 refactors.
  • All components are now forwards-compatible with existing v3 releases, including those that depend on zend-stdlib.
  • Progress on the documentation initiatives, including 11 new components documented.
  • Announcement of issue closures.

MVC Refactor

In the previous update, we provided a roadmap for the zend-mvc v3 refactor; at the time, we'd just begun the initiative, but still had the bulk of the work remaining.

As of last week, however, we have completed all tasks related to the refactor! These include:

  • a component installer Composer plugin, which will automatically inject installed components into application configuration as modules. (It is also forwards-compatible with upcoming Expressive releases!)
  • console functionality as a separate component (zend-mvc-console).
  • separation of controller plugins with additional dependencies into their own packages, including:
  • separation of i18n integration into a separate component (zend-mvc-i18n).
  • separation of the code for wiring zend-di into zend-servicemanager into a dedicated component (zend-servicemanager-di).
  • removal of all factories and integrations with components that fall outside the core dependencies.

This latter required that we move the various factories, service integrations, and event listener wiring code into the components themselves. This affected eight components, though we ended up addressing another five components that were already defining factories for zend-servicemanager as well:

  • zend-filter
  • zend-form
  • zend-hydrator
  • zend-inputfilter
  • zend-log
  • zend-navigation
  • zend-serializer
  • zend-validator
  • zend-cache
  • zend-db
  • zend-mail
  • zend-paginator
  • zend-session

For each of these, we created two new classes in their defined namespaces, ConfigProvider and Module. The first is an invokable class returning configuration, which might include service configuration, plugin configuration, etc. Module is a class specific to the Zend Framework ecosystem, and returns configuration, but, in several cases, also wired other code into the zend-mvc workflow. All of the above components received new minor releases once these were in place, and zend-mvc was updated to remove dependencies on them.

The core dependencies in zend-mvc are now:

  • zend-eventmanager
  • zend-http
  • zend-modulemanager
  • zend-router
  • zend-servicemanager
  • zend-stdlib
  • zend-view

Once we were done, the lines of code had dropped to approximately 25% of the size in the version 2 releases!

Skeleton application

With the zend-mvc refactor complete, we decided to work on the skeleton application.

Feedback we've had includes:

  • While having i18n support is interesting in terms of seeing how it's done, it's mostly worthless in the skeleton application. The provided translations are only valid for the home page shipped with the skeleton, which is replaced essentially 100% of the time with custom content. Additionally, it poses maintenance overhead with regards to reviewing and accepting new translations. Finally, with the split of zend-mvc-i18n, keeping it in meant adding additional dependencies which might never be used.
  • Related, we've had a lot of folks indicate that they'd like an option for a minimal skeleton. Many developers don't want the i18n, console, forms, cache, logging, and other facilities, or want to pick and choose which ones they configure.
  • As PSR-0 is deprecated, our skeleton should reflect PSR-4 for the default Application module.
  • Related, we want to encourage using composer for all autoloading.

To get the ball rolling, I created a pull request proposing a streamlined skeleton. This has already generated a fair bit of discussion, and we have a number of new ideas we're going to investigate, including setting up Expressive-like installation questions to allow bringing in common features during the first install.

JSON Refactor

We also did some refactoring of the zend-json component. Several users have complained that it includes too much: the JSON-RPC functionality is not generally useful for those who only want JSON de/serialization, and the XML2JSON implementation is only needed by a subset of users.

As such, we split it into three:

  • zend-json contains the JSON de/serialization logic only, starting with its v3 release.
  • zend-json-server contains the JSON-RPC server implementation.
  • zend-xml2json contains the XML2JSON implementation.

We'd like to thank Ali Bahman for his assistance with these changes!

Forwards compatibility

This week, we discovered half-a-dozen components that declare a dependency on zend-stdlib, but which had not been updated to allow usage with zend-stdlib's v3 releases. As such, we quickly updated each to do so, releasing new maintenance releases when ready. These include:

  • zend-code
  • zend-expressive-skeleton
  • zend-ldap
  • zend-mime
  • zend-soap
  • zend-xmlrpc

Documentation

With the MVC initiatives complete, we have begun working on the documentation in earnest again.

The first thing we did was recognize that while it's nice to be publishing the documentation, we really need mechanisms for navigating to other components. As such, we created a topnav button that, when clicked, fetches a list of components with documentation, and slides the list in from the top of the page.

We've also been either documenting components as we create them (see the MVC plugins and JSON changes, above), or publishing documentation as we create new releases on components we update. Since the last update, we've published documentation for the following components:

Many thanks to Frank Brückner for the copious documentation updates he's provided!

There's plenty left to do, however (32 components left at the time of writing). We've created a list of components and tasks to perform if you are interested in helping!

Issue closures

Last week, Gary Hockin posted to the ZF blog about a plan to perform housekeeping of issues posted against the main zendframework repository. The basic summary is: issues against the main ZF repository have been tagged as "To Be Closed", and will be closed in early May unless you comment on an issue and tag user @GeeH before 3rd May 2016.

Pull request and issue activity

Since the last update, we've merged around 160 pull requests, and resolved around 110 issues. (links require a GitHub account).

Notable releases

As noted at the beginning of this post, we've done over 60 component releases since the last update (approximately four weeks ago). Notable amongst them:

  • Zend Framework 1.12.18
  • zend-json 3.0.0, which removes the JSON-RPC and XML2JSON functionality (as those are now in separate components)
  • zend-inputfilter 2.6.1, which fixes a long-standing issue with localization of NotEmpty validation messages generated for required inputs.
  • zend-math 2.7.0 provides a security hardening patch for Zend\Math\Rand, forcing usage of PHP 7's random_bytes() and random_int() when available, and requiring ircmaxell/RandomLib for earlier PHP versions.
  • zend-session 2.7.0 updates the component to use ext/mongodb + the MongoDB PHP client library instead of ext/mongo, and adds session identifier validation by default.
  • zend-db 2.7.1 updates the Pgsql adapter to accept the charset option; fixes Zend\Db\Sql\Insert to properly manage arrays of column names when generating SQL INSERT statements; fixes an issue with how row counts were reported in Oci8 result sets; and updates the IbmDb2 adapter to allow # characters in identifiers.
  • zend-cache 2.7.0 offers a ton of new features, including a new APCu adapter, upgraded support for XCache and Redis, and numerous bugfixes.
  • zend-stdlib 2.7.7 and zend-stdlib 3.0.1 fix declaration of Zend\Json\Json::GLOB_BRACE when on systems based on non-gcc versions of glob.

Until next time

If you want to help:

Many thanks to all the contributors who have provided feedback, patches, reviews, or releases since the last update!

Source

The Zend Framework community is pleased to announce the immediate availability of:

  • Zend Framework 1.12.18

You can download Zend Framework at:

Security Fixes

Zend Framework 1.12.18 includes a fix for security advisory ZF2016-01, a potential insufficient entropy vulnerability in a number of methods exposed in Zend Framework 1, including:

  • Zend_Ldap_Attribute::createPassword
  • Zend_Form_Element_Hash::_generateHash
  • Zend_Gdata_HttpClient::filterHttpRequest
  • Zend_Filter_Encrypt_Mcrypt::_srand
  • Zend_OpenId::randomBytes

Moreover, the fix mitigates a flaw in openssl_random_pseudo_bytes(), ensuring sufficient entropy will be used for any random number generated.

Other changes

In addition to the security patch, the release includes fourteen other patches, primarily around documentation. You can view a full list at:

Many thanks to our contributors, and particularly the maintainers who coordinated this version: Frank Brückner, Rob Allen, and Enrico Zimuel.

Source

ZF2016-11: Potential Insufficient Entropy Vulnerability in ZF1

We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls:

  • Zend_Ldap_Attribute::createPassword
  • Zend_Form_Element_Hash::_generateHash
  • Zend_Gdata_HttpClient::filterHttpRequest
  • Zend_Filter_Encrypt_Mcrypt::_srand
  • Zend_OpenId::randomBytes

In each case, the methods were using rand() or mt_rand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

Moreover, we discovered a potential security issue in the usage of the openssl_random_pseudo_bytes() function in Zend_Crypt_Math::randBytes, reported in PHP BUG #70014, and the security implications reported in a discussion on the random_compat library.

Action Taken

We replaced the usage of rand() and mt_rand() with the random generators of ZF1 implemented in Zend_Crypt_Math().

Moreover, we removed the usage of openssl_random_pseudo_bytes() functions in Zend_Crypt_Math::randBytes(). This removal is not a BC break for Linux users thanks to the usage of /dev/urandom as an entropy source. For Windows users, this can be a BC break if the Mcrypt extension is not enabled.

The following releases contain the fixes:

  • Zend Framework 1.12.18

Recommendations

If you are using an affected version of PHP, we highly recommend upgrading immediately to Zend Framework 1.12.18.

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and working with us to help protect its users:

  • Brian Engert of Soliant Consulting, who discovered, reported, and proposed a patch for the issue;
  • Enrico Zimuel, who tested the patch and added the patch for the OpenSSL usage removal.

Source

ZF2016-01: Potential Insufficient Entropy Vulnerability in ZF1

We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls:

  • Zend_Ldap_Attribute::createPassword
  • Zend_Form_Element_Hash::_generateHash
  • Zend_Gdata_HttpClient::filterHttpRequest
  • Zend_Filter_Encrypt_Mcrypt::_srand
  • Zend_OpenId::randomBytes

In each case, the methods were using rand() or mt_rand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

Moreover, we discovered a potential security issue in the usage of the openssl_random_pseudo_bytes() function in Zend_Crypt_Math::randBytes, reported in PHP BUG #70014, and the security implications reported in a discussion on the random_compat library.

Action Taken

We replaced the usage of rand() and mt_rand() with the random generators of ZF1 implemented in Zend_Crypt_Math().

Moreover, we removed the usage of openssl_random_pseudo_bytes() functions in Zend_Crypt_Math::randBytes(). This removal is not a BC break for Linux users thanks to the usage of /dev/urandom as an entropy source. For Windows users, this can be a BC break if the Mcrypt extension is not enabled.

The following releases contain the fixes:

  • Zend Framework 1.12.18

Recommendations

If you are using an affected version of PHP, we highly recommend upgrading immediately to Zend Framework 1.12.18.

Other Information

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and working with us to help protect its users:

  • Brian Engert of Soliant Consulting, who discovered, reported, and proposed a patch for the issue;
  • Enrico Zimuel, who tested the patch and added the patch for the OpenSSL usage removal.

Source

Hello Zend Frameworkians.

I want to make you aware of some upcoming changes to the issues that are currently logged in GitHub. We currently have 426 open issues that are logged against the (now) meta zf2 repository. The vast majority of these are now in the wrong place, as we've split our once monolithic single repository into the many single component repositories. These issues should be moved from the zf2 repository to the correct component that the issue relates to.

In preparation for this, we've been doing a little housekeeping and have already closed a few minor issues that have been open since before we even used GitHub for issue tracking. Matthew, Enrico and I also had a long discussion at Midwest PHP on the best way to handle these issues, and we came up with a plan of attack that hopefully will allow us to close off a bunch of historical issues that are no longer relevant, and then move issues that need to be moved to the correct place.

You may have noticed that over the last few weeks, a number of issues have been tagged with the new label of "To Be Closed". These are issues that have been open for a number of years and still haven't been fixed. Its probable that a number of these issues should not be closed as they are still relevant all this time later (after all, just because an issue has been open for many years does not mean that it will never be addressed). However, at some point these issues need to be triaged so that issues that are old and not relevant can be closed, and this is the convenient time.

So, in early may, all the issues that are tagged with "To Be Closed" will be closed. If you feel an issue needs to remain open for any reason, then please comment on the issue with a mention of my username (GeeH). I will then remove the "To Be Closed" tag. Next, no sooner than the 3rd May 2016, we will run a script that will automatically close every tagged issue, commenting on it to advise the original author to re-open an issue on the correct repository if they feel that issue is still valid.

Once this has been done, we will be left with around 100-150 issues by my estimation. Most of these have already been labelled with the correct repository to move them to (thanks to the sterling work of the community). The next step will be to run a script that opens a new issue with the same body text on the correct repository, adding a link to the original issue on the central zf2 repo. A comment will be added referencing the new issue on the original, and the original will be closed.

Hopefully, once this process is complete, we will be left with a few issues that are either in the right place (after all, some issues will relate to the meta package on the zf2 repository), or can be moved by hand.

TLDR

You need to comment on an issue mentioning GeeH BEFORE the 3rd May 2016 to ensure it remains open after that date (if it's currently tagged "To Be Closed").

Source