I, Thomas Ward, apply for upload rights for the package nginx.

Who I am

I am a 24 year old student in college, for IT security, in addition to being an Ubuntu enthusiast. I somewhat-actively do bug triaging for multiple packages, both as a member of Bug Squad and Bug Control. I specifically work with the NGINX packages as a bug triager, and work to get bugs fixed in nginx where possible, and try and upstream said bugs where necessary. I also helped pioneer getting NGINX into Main, via the nginx-core binary.

My Ubuntu story

Tell us how and when you got involved, what you liked working on and what you could probably do better.

Initially, I started using Ubuntu several years ago with 9.04 Jaunty and got more and more intrigued with Linux and the capabilities of it.

After that, when I ran into issues I was not skilled enough to work through, I joined ubuntuforums.org and did some support work there, both receiving and providing support, eventually settling to assisting with helping newbies get started.

After a while, I discovered the IRC support, and both received support, and provided support, there for some time, but never super-actively. I eventually learned about Ask Ubuntu, and at the time lost interest in providing IRC support, and gave a lot of support there for users. From my contributions prior to joining Ask Ubuntu, and at the time over a year ago, I applied for Ubuntu Membership for my contributions, primarily focusing on my Ask Ubuntu contributions, and what meager work I had done with packages and bug triage at the time. My membership application was approved, and I was made an Ubuntu Member.

After a while, I became interested in several programs and packages, including nginx, ZNC, and others. I became interested in packaging at roughly the same time, and learned the basics of packaging, and patch management within them.

I joined several mailing lists at the time, and continued to provide support through Ask Ubuntu, while not providing as much in terms of contributions elsewhere. Relatively recently, within the past year or so, I became interested in working with bugs, and started helping to get bugs triaged, eventually joining the Bug Squad. At this point, I became highly involved in working with the NGINX team, in order to help provide IRC support for them, and eventually helped manage all their bugs. At the request of upstream and an upstream Debian maintainer/contributor for nginx, I was given "Upstream" access to Ubuntu Bug Control, and have since been managing the nginx bugs as their primary Ubuntu contact. After working with bugs and making a few mistakes, I checked with Brian Murray, who is the "Ubuntu Bug Master" and was granted an "OK" to work with other bugs outside nginx and others, and have worked as a Bug Control member, helping to triage bugs when they end up on the #ubuntu-bugs channel or on my radar.

Now, I run Ubuntu as a primary operating system, using the LTS releases on servers, desktops, laptops, and workstations, and continue to work as a bugs triager for the nginx team. I have also become the primary NGINX PPA maintainer for the NGINX team, and am now the principal go-to for their team when it comes to working on bugs that crop up in Ubuntu for the nginx program, and have provided security debdiffs and normal update debdiffs (SRUs and non-SRUs for the development release), and on occasion sync/merge requests for nginx. More recently, I have been taking a slightly more active role in the nginx package upstream in Debian, and have been helping with some bug triage there. My biggest interaction with the nginx package was helping to get NGINX into Main, by adding a binary called nginx-core which contains only the core upstream-tarball-included modules.

My involvement

My involvement with the nginx package in Ubuntu is primarily bugfixing and bug triage, and some minor maintenance in cases where the nginx package needs some kind of package change. However, I have been designated by the nginx team (on Launchpad) as the maintainer for their PPAs, which covers the stable and mainline branches of the nginx software.

My involvement in Ubuntu is detailed above, but to summarize, I worked with giving support for Ubuntu, then moved to packaging for a bit, and ultimately ended up working with bugs and triage. I am a member of Ubuntu Bug Squad and Ubuntu Bug Control. However, I specialize working with the nginx package for bugs triage, and as a member of the Server Team, I try and help triage server bugs when they cross my path.

Examples of my work / Things I'm proud of

The biggest example of my work that I'm proud of for the NGINX Package is the work I did to help get the nginx-core binary into Main. This is reflected on the nginx Main Inclusion Request by Robie Basak in which I helped create the nginx-core binary which now is in Main. Prior to this, most of my work had been bug triage and maintaining the software in the nginx PPAs.

Additional examples of my work are mostly minor, with triage work and minor maintenance, as well as bug fixing. Do make a note that some of these bugs and their corresponding debdiffs were Security related bugs. A full list of my sponsored uploads and worh can be seen here, at the Ubuntu Sponsorship Miner on alioth.debian.org. (NOTE: Not all my work has been in the nginx package, althoug ha very large percentage of it has been).

This bug which I made a fix for in Utopic just prior to its release addresses the SSLv3 being used in the default config issue, which opens users to the POODLE vulnerability.

This bug which I had a fix sponsored for in Precise a while ago enabled a module to be built that wasn't being built. It was accepted because the Package Description explicitly stated that the module was enabled, when it was, in fact, not built.

Prior to Saucy being End of Life, I helped to get a segfault fix into the nginx package. This was a problem with a third party module included in the packaging, but it still helped fix a segfault issue which could result in crashes. This was a fix so that when any of the flavors of Ubuntu are installed, the configuration files do not get removed. This was initially fixed in Debian, but it became necessary to take the changes and put them into Ubuntu, removing the config-removal steps from the individual flavors and only put that step in nginx-common.

I helped with debdiffs for a security fix for CVE-2013-4547 which could result in a security restrictions bypass with a specially crafted URI.

I helped with the debdiffs for CVE-2014-0133, which addressed a SPDY Heap Buffer Overflow vulnerability.

I helped prepare the debdiffs to patch a buffer overflow vulnerability in NGINX.

I helped identify and fix an issue in the default-shipped configs which would result in a failure-to-start issue due to conflicting port 80 binds. The introduced regression caused by a mistype by me was also fixed by me, with some help from Debian upstream.

I helped cherry-pick upstream changes to fix a segmentation fault when try_files uses a URI that is shorter than the request URI.

I also helped get the debdiffs created for CVE-2009-4487, CVE-2011-4315, and CVE-2012-1180, which were listed in the March 15th 2012 Security Advisory posted by Luis Arias against the nginx package. Although it took several months to get done, this was one of my first actual involvements on a larger scale with the nginx package.

One of my most recent efforts was to merge NGINX 1.6.2-4 from Debian Unstable into Vivid. This merge was accepted with two minor changes, in which I accidentally let two remaining changes off of the changelog entry. There is another merge pending, which merges 1.6.2-5 from Unstable into Vivid.

Areas of work

Let us know what you worked on, with which development teams / developers with whom you cooperated and how it worked out. I've cooperated with the Security Team for nginx security fixes, as well as the Ubuntu Server team and multiple other sponsors to get fixes put in for the nginx package in Ubuntu. In almost every case, it has worked out effectively, with each bug and change getting included if its critical, and being rejected if it's too minor.

I worked with Robie Basak and Seth Arnold and the Security Team on the Main Inclusion for nginx-core.

I have worked with Seth Arnold, Jamie Strandboge, and Marc Deslauriers on security fixes in nginx, and they have been the primary ones sponsoring those debdiffs.

As far as individuals who have sponsored my uploads in the past, that list can be expanded to include Iain Lane, Adam Conrad, and Micah Gersten. Most recently, it has been primarily working with Seth, Marc, and Robie

As a per-package uploader, please give us some insight into the package maintenance and bug situation since you're working on it.

nginx package maintenance is generally handled upstream in Debian, as the packages in Ubuntu are derived from Debian's packages. Bugs in nginx in Ubuntu are being filed, but as I am one of the few people actually working on the nginx bugs in Ubuntu, I am usually resorting to contacting upstream to get more specifics on whether the bug is in the program or an issue of user error, at least when I am not familiar with the issue. In most cases, the packages are maintained upstream and in Debian, and I help get the bug fixes into Ubuntu's versions when a related bug has been filed against the Ubuntu package.

Maintenance of the nginx package, in terms of security updates, is dependent entirely on upstream releasing fixes, except in cases of issues with the default-shipped configurations, or additional third-party modules in the Universe packages (in which case, the upstream trackers and maintainers of those third-party modules end up being contacted). I do, however, check the Security Team's CVE trackers for nginx once a month or so and check to see whether any new CVEs have been filed against nginx. When one has been filed that does not have a corresponding bug for those CVEs, I file a bug in Launchpad, and with guidance of the Security Team, work on getting patches for CVEs once upstream has fixed those security risks. However, there are multiple CVEs of which Upstream is seemingly ignoring and have had zero progress on fixing, so there are some low priority CVEs that remain unfixed.

Bug fixes (except merges) tend to have SRUs with my own signature on the debdiffs, uploaded by sponsors. Some security bugs have debdiffs with my signature on them as well (except merges up to this point).

Things I could do better

I rely heavily on upstream for bugfixes, as I am not a developer of their software. I am a maintainer for their PPAs, and I work primarily as a bug triager / bug fixer for the nginx package. I could probably better familiarize myself with all the code of nginx, to be better equipped to fix bugs without resorting to upstream fixes.

I definitely need to familiarize myself more with the merge procedures. As it currently stands, I used the UDD procedure of merging to work on the upstream merge of nginx which resulted in the debdiff(s) posted here. Unfortunately, I am not as familiar with merges as I am standard bug triage and debdiffs.

Plans for the future

My plans for the future for this package are to continue to provide bugfixes and maintenance for the package in Ubuntu, as well as to continue helping to handle bug triage, while working with the Security and Server teams on the nginx maintenance going forward. I plan to continue maintaining the nginx PPAs, as well.

What I like least in Ubuntu

Please describe what you like least in Ubuntu and what thoughts do you have about fixing it.

I find that there are very few things I dislike about Ubuntu, and what I do dislike is mainly aesthetics-related. I generally tolerate those aesthetic issues (such as, a dislike for Unity's arrangement of things on screen, but that is generally just a minor issue, not a major one). Unfortunately, I do not have any suggestions towards fixing this, as it is a general design dislike rather than a specific issue.

Comments

If you'd like to comment, but are not the applicant or a sponsor, do it here. Don't forget to sign with @SIG@.

Seth Arnold

I've worked with Thomas on the nginx package, both for "community" sponsored security updates and for the main inclusion request to add nginx to Ubuntu main. Thomas is enthusiastic, keeps good watch on the nginx bugs, provides good help to users on IRC, and doesn't hesitate to ask questions when something is outside his familiarity. It's been unfortunate that nginx was moved to main as a result of his packaging work in the past but is now harder for him to maintain as a result.

I support Thomas's application for PPU rights for nginx. Thanks.

-- seth-arnold 2014-11-03 18:44:11

Endorsements

As a sponsor, just copy the template below, fill it out and add it to this section.

Robie Basak

General feedback

Thomas has been looking after nginx in Ubuntu for longer than I can remember now. This includes triaging bugs, SRUs and maintaining a PPA for users who want things that we can't provide in the Ubuntu archive for policy reasons.

It is great that Thomas has become an "Ubuntu domain expert" in nginx like this. He is valuable to the rest of the server team; the rest of us don't need to worry about the state of nginx in the archive so much because Thomas is generally on top of it.

When other commitments make Thomas unavailable to work on something in nginx that we need for a release, he is communicative about it so that the rest of the Ubuntu Server Team can plan to take on this work early.

Thomas is very careful to ask when he's not sure about something.

Specific Experiences of working together

It looks like I've sponsored only three nginx SRUs for Thomas, but my work with Thomas on the nginx package in general has been much wider than this.

The SRUs themselves have been fine. Minimal, as required, most of the work is in the bug paperwork, which I've been happy to leave to Thomas and which he does correctly.

The wider picture is that Thomas regularly discusses with me what is going on in the nginx packaging world when this impacts Ubuntu. In addition to the nginx MIR, this has included for example Debian dropping support for naxsi and most recently the POODLE vulnerability.

Areas of Improvement

I don't see any merges in Thomas' sponsorship history, and it would be nice to see him doing some of these. I note that he's already got one in the sponsorship queue though!

However, I don't feel that it's necessary to hold back PPU rights because of this. Thomas' care of stable releases through SRUs is valuable to the project, and I don't think he needs sponsorship of these any longer. I think Thomas has demonstrated that he takes enough care over his work. I'm confident that he will seek review for anything for which he doesn't have prior experience already.

Marc Deslauriers

General feedback

I have been sponsoring nginx package changes for Thomas for a long time now. He is attentive, and cares greatly about the quality of the nginx package. He is not afraid to ask questions when he isn't entirely sure about something, and he values input. I fully support Thomas's application for PPU rights for nginx.

ENDORSEMENTS TEMPLATE

== <SPONSORS NAME> ==
=== General feedback ===
## Please fill us in on your shared experience. (How many packages did you sponsor? How would you judge the quality? How would you describe the improvements? Do you trust the applicant?)

=== Specific Experiences of working together ===
''Please add good examples of your work together, but also cases that could have handled better.''
=== Areas of Improvement ===

CategoryPerPackageUploaderApplication