Overdue GPG signing

In the last few years I wasn’t really maintaining my GPG keys. I’ve created a new one (B4E14499) in 2011 during DebConf11, after the older primary one (99E81DA0) became too weak (1024D). I thought that I didn’t have enough signatures on the new key and almost lost my place on the debian keyring due to removal on the old one (without adding the new key).

Due to my confusion with the key signature, I didn’t really take the time to sign other people keys. But that doesn’t mean I ignored them completely, as I kept all the information from Debconf11 (yes, 4 years ago) and also the slips I was handed since.

Today, I finally took the time to finish the backlog and sign all the keys which are strong enough and still valid (haven’t expired / revoked). One less item on the todo list.

For those who got my signatures – I’m sorry for the delay, but better later than never, right ?

Leave a comment

Filed under Debian GNU/Linux

CVE assignment without upstream knowledge

In the past few months I’ve been dealing with aligning PHP CVE information to enable easier tracking of security fixes. The two main locations are the NEWS file which is part of each release and the changelog available on the website which is more popular (and easier to update).

Usually the CVE are assigned per PHP.net security team request or with cooperation with one of the Linux distribution’s teams (either PHP or security), as should be in a good ecosystem.

Recently I got a few notifications issued by Debian about its PHP package, which I wasn’t familiar with these CVE IDS. When checking this, I found out a few CVE assigned per 3rd party (Linux distribution, bug reporter, etc…) request without upstream knowledge. Digging deeper I found out that some CVE were assigned a month after the fixes were released, while others were only a week or two after. While this makes sure the security information is documented, it’s harder to add the information after tagging and releasing.

In another case, while discussing about a CVE for a specific bug, we found out one was already assigned per the reporter’s request but without the our or the upstream library knowledge. Even if the issue isn’t severe, upstream should get a fair chance to fix issue before making them public. Which also leads to a problem with requesting CVE IDs on a public mailing list which in some cases leads to security information leakage. We should balance transparency with some grace period for upstreams (as projects share code).

Leave a comment

Filed under Debian GNU/Linux, PHP

PHP7 replaces non-free JSON extension

For many the PHP JSON extension license might look like a storm in a teacup, but for many Linux distributions the bits of the free software licenses are very important. That was the case when Debian decided (#692613) to remove the non-free JSON extension as part of the transition to PHP 5.5 in May 2013 (after the Debian 7 release).

This change was done with the help of Remi Collet (from Fedora / Red Hat) who wrote an alternative extension based on JSON-C implementation. A similar change was done by other Linux distributions, and this became the defacto standard for most Linux users.

The situation has recently changed with the acceptance of the Jakub Zelenka’s jsond RFC to replace the current non-free implementation with a free one. The change was committed to the code base on early February (Closing #63520) and expected to be released later this year as part of PHP7.

2 Comments

Filed under Free software licenses, PHP

The importance of close integration between distribution and upstream

Many package maintainers need to decide when to upload a new version to Debian. Should the upload be done only after the official release, or is there a place for uploads during the development process. In the latter case there’s a need to balance between the benefit of early testing and feedback with the stability and not completely breaking user’s environment (and package relationships) too often.

With the coming PHP 5.6.0 release, Debian kept being on the cutting edge. Thanks to Ondřej, the new version was available in experimental since alpha1 and in unstable/testing since beta3. Considering the timing of the PHP release related to the Debian freeze, I’m happy we started early, and did the transition to PHP 5.6 a few months ago.

But just following the development releases (betas ,RCs) isn’t enough. Both Ondřej and myself are part of the PHP community, and know the planned timelines, current status and what are the critical points. Such knowledge was very useful this week, when we new 5.6.0 was pending finale tagging before release (after RC4). This made take the report of Debian bug #759381: “php5: TLS connections broken in 5.6.0 RC4” seriously and contact the release managers.

First it was a “heads up” and then a real problem. After a quick discussion (both private mails by me and on github by Ondřej), the relevant commit was reverted by the release managers (Julien Pauli & Ferenc Kovacs), and 5.6.0 was retagged. The issue will get more checks towards 5.6.1 without any time pressure.

Although 5.6.0 isn’t in production for anyone (yet), and like any major release can have issues, the close connectivity between everyone saved complaints from the PHP users and ecosystem. I don’t imagine the issue been sorted so quickly 16 hours later. This is also due to the bug been reported on difference between two close release (regression in RC4 comparing to RC3).

To close the loop, if we’ve uploaded 5.6.0 only after the release, the report would be regression between 5.5.x and 5.6.0, which is obviously much harder to pinpoint. So, I’m not sure I have a good answer for the question in the beginning of the post, but for this case our policy proved itself.

1 Comment

Filed under Debian GNU/Linux, PHP

Testing PHPNG on Debian/Ubuntu

We (at Zend) want to help people get more involved in testing PHPNG (PHP next generation), so we’re started to provide binaries for it, although it’s still a branch on top of PHP’s master branch. See more details about PHPNG on Zeev Suraski’s blog post.

The binaries (64bit) are compatible with Debian testing/unstable and Ubuntu Trusty (14.04) and up. The mod_php is built for Apache 2.4 which all three flavors have.

The repository is at http://repos.zend.com/zend-server/early-access/phpng/

Installation instructions:

# wget http://repos.zend.com/zend.key -O- 2> /dev/null | apt-key add –
# echo “deb [arch=amd64] http://repos.zend.com/zend-server/early-access/phpng/ trusty zend” > /etc/apt/sources.list.d/phpng.list
# apt-get update
# apt-get install php5

For the task of providing these binaries, I had a pleasure of combining my experience as a member of the Debian PHP team and a Debian Developer with stuff more internal to the PHP development process. Using the already existing Debian packaging enabled me to test more builds scenarios easily (and report problems accoredingly). Hopefully this could also be translated back into providing more experimental packages for Debian and making sure Debian packages are ready for the PHP released after PHP 5.6.

1 Comment

Filed under Debian GNU/Linux, PHP

Removal of (some) PHP related software from Debian

The Debian FTP masters have for quite a while a line in their reject FAQ about the PHP license. Despite that, quite a lot of PHP extensions were uploaded to the archive and accepted. Some are being managed/developed in PHP.net’s PECL website, and are done under the umbrella of the PHP Group, which is the group the PHP license is refers to. Over time, we started to see many more extension being developed outside of the PHP group (both technically with sites like github and copyright wise).  This is true to certain degree with the PHP.net’s PEAR  website which has software written in PHP.

The issue has been raised again in October 2013 with php-gearman using the PHP license while having different copyright holders (bug #728196). After discussions (ftp masters, release team & Ondřej), it was agreed that the current interpretation is still relevant, and almost all extensions and applications should be either removed or re-licensed by its upstream. This makes the todo list 41 packages long (full list based on Ondřej Surý’s bug reports). Any help with contacting upstream projects, explaining the situation and requesting a license change would be welcomed. We also need to monitor new release based on fulfilling these requests.

Until such a change happen, with automatic removal of packages from testing, we’re going to see packages disappear after mid July. This has a little wider affect due to package dependencies, but for the moment only on testing (Jessie).

5 Comments

Filed under Debian GNU/Linux, PHP

freedom 0

The license says you can use free and open source software for any reason, but the FBI wouldn’t agree with your questions… Silk Road operator identified by asking a PHP related question on stackoverflow.

See “The Bonehead Mistake That Brought Down an Online Drug-Dealing Empire” on Slate.com

3 Comments

Filed under Uncategorized