December 2014 Summaries

A day after the release of GitLab 7.6, a patch was necessary due to an oversight in database migration affecting MySQL but not PostgreSQL. The issue arose when attempting to remove two columns, extern_uid and provider, from the users table, which had a composite index ensuring uniqueness. While PostgreSQL handled the migration smoothly, MySQL encountered a problem as it rebuilt the index using only the provider column, leading to duplicate indices. The solution involved checking for and removing the index if it existed before proceeding with the column removal. Despite having a comprehensive test suite and QA testing, this simple oversight was missed, prompting a swift patch release. This experience highlighted the need for careful consideration of database-specific behaviors in future migrations.

A critical security vulnerability has been discovered in all versions of the official Git client, affecting those using Git on case-insensitive or case-normalizing filesystems like macOS (HFS+ not formatted as case-sensitive) and Microsoft Windows (NTFS, FAT). This vulnerability allows attackers to create a malicious Git tree that can overwrite the .git/config directory during cloning or checkout, potentially leading to arbitrary command execution on the client's machine. GitLab.com and its related editions are not directly impacted due to their server-side operations, but users are strongly advised to update their Git clients to the latest maintenance releases, which address this issue. Linux clients running on case-sensitive filesystems are not affected. The Git core team has released updates across all current versions of Git, along with maintenance updates for major Git libraries, libgit2 and JGit, to rectify the problem. Users are encouraged to exercise caution when dealing with repositories from untrusted sources and can reach out to GitLab support for further assistance.

Embarking on a journey with GitLab B.V., the author shares an enlightening account of their first three months with the company, highlighting a seamless transition into a role that aligns with their professional goals and values. After completing a project for a Mexican company, they came across a remote Service Engineer position at GitLab that resonated with them, especially given GitLab's emphasis on open-source contributions, employee happiness, and flexible work schedules. An unexpectedly swift and pleasant interview process with CEO Sytse solidified the author's decision to join the company, where they found a welcoming and supportive team environment despite the physical distance. Through daily virtual meetings, the author quickly integrated into the team, enjoying the camaraderie and humor shared during calls, while also adapting to the responsibilities of handling client tickets and collaborating across different time zones. The work culture at GitLab fosters continuous learning, open communication, and personal growth, making the author grateful for their current role and eager to continue their journey with the company, which includes an upcoming team meeting in San Francisco.

A vulnerability in Gollum, the git-powered wiki used by GitLab, was recently disclosed, allowing potential code execution on servers running Gollum. However, GitLab installations are not affected by this issue due to their independent search implementation, which avoids the vulnerability by using Shellwords.shellescape(query) and switching to Rugged from Grit since version 7.4. While acknowledging that their own gem contributed to the vulnerability, GitLab has issued guidelines to prevent remote code execution vulnerabilities and is transitioning to Rugged for enhanced security. Ruby developers are encouraged to follow these best practices and contribute improvements through merge requests. Users can try GitLab by downloading the Community Edition or using the free GitLab.com instance, while the Enterprise Edition offers advanced features like LDAP integration and Jenkins support.

The blog post outlines how the GitLab community handles different types of bugs, emphasizing community involvement in identifying and fixing issues. It categorizes bugs into security bugs, regression bugs, and feature bugs, each with a distinct handling protocol. Security bugs, which are vulnerabilities allowing unauthorized access, are prioritized, with feedback given within 1-2 days and fixes applied promptly depending on severity. Regression bugs, introduced in new releases but absent in older versions, are also prioritized, with fixes often included in the next minor release. Feature bugs, which occur when GitLab features do not behave as expected, are addressed based on their impact on functionality. The post encourages responsible disclosure for security bugs, sharing regression bugs via Twitter or the issue tracker, and reporting feature bugs after checking existing community feedback. Additionally, it highlights the crucial role of over 600 external contributors in the GitLab community who participate in identifying and fixing bugs, with contributions acknowledged in the changelog.

In large GitLab instances, managing logs effectively is crucial to prevent server issues, and a practical solution is to ship logs to a separate server. GitLab Enterprise Edition (version 7.1 and up) offers UDP log shipping as an efficient method to handle this, as UDP transmits logs in a non-blocking, fire-and-forget manner, making it faster and more reliable compared to TCP, which can fail if connections drop. Setting up UDP log shipping is straightforward by configuring a few lines in the GitLab configuration file and running a simple command, allowing logs to be sent to a designated syslog server. GitLab uses svlogd for handling STDOUT logs and remote_syslog for .log files to facilitate the log shipping process. Moreover, GitLab Enterprise Edition provides additional features like support, LDAP integration, and Jenkins integration, with options to try out the Community Edition or use their free GitLab.com instance.