March 2019 Summaries

At a recent meetup, developers discussed "dependency hell," a situation when software requires conflicting dependencies installed in the same environment. This issue can arise due to various reasons such as outdated or incompatible versions of libraries, native extensions, or system libraries. The author shares their personal experience with dependency hell and emphasizes that it's a common problem that affects everyone, regardless of technology or ecosystem. To escape dependency hell, developers can experiment with different versions of dependencies, fork open-source projects to fix issues, find or write replacement dependencies, or downgrade incompatible components. However, the author notes that shame is not an effective response to dependency hell, as it leads to dwelling on what others might think and prevents teams from working together to resolve the issue. Instead, acceptance, compassion, and teamwork are essential in overcoming dependency hell, both for individuals and teams.

The survey results highlight that professional developers spend around 30% of their average weekly work time on code maintenance, with a significant portion of this time related to the open source packages they use. The larger the development team, the more time is dedicated to code maintenance. On average, open source packages contribute around 25% of the total code maintenance workload, but there is significant variance in this figure. The most common open source maintenance tasks are improving, replacing, and keeping up with packages, often occurring together. This suggests that developers face challenges in maintaining their applications' dependencies, particularly when dealing with unmaintained or outdated libraries.

This critical WordPress vulnerability, known as CVE-2019-9787, allows an attacker to gain remote code execution on any WordPress installation prior to version 5.1.1 by tricking an administrator into visiting a malicious website. The exploit chain involves a cross-site request forgery (CSRF) vulnerability in the comment form, which is not properly sanitized, allowing attackers to inject additional HTML tags and attributes that lead to stored XSS vulnerabilities. Once the XSS payload is executed, the attacker can gain arbitrary PHP code execution on the remote server by exploiting a PHP backdoor inserted into the theme or plugin files. The vulnerability exists in WordPress versions prior to 5.1.1 and can be exploited with default settings. It's essential for WordPress administrators to update to version 5.1.1 immediately, disable comments until the security patch is installed, and logout of their administrator session before visiting other websites.