CoreDevApplication

Revision 32 as of 2025-02-24 15:26:30

Clear message

I, adrien, apply for core-dev.

Name

Adrien Nader

Launchpad Page

https://launchpad.net/~adrien

Wiki Page

<link to your Wiki page>

I am applying because:

  • I'd like to eliminate delays in getting my work sponsored.
  • I'd like to reduce the burden on my sponsors.
  • I'd like to pay back all the review time I've benefited from.
  • I'd like to help people who seek sponsorship.
  • I'd like to also help with transitions.

Who I am

Tell us a bit about yourself.

My Ubuntu story

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

My involvement

Examples of my work / Things I'm proud of

Include your existing sponsored uploads for the packages for which you are seeking upload rights. You can link directly to an upload by following this pattern.

Areas of work

I've been taking care of cryptography-related packages since I joined Canonical in late 2022.

The most notable of these package is openssl. It is a large package with many direct and recursive reverse dependencies, it has frequent updates and is also known as a package for which updates are likely to introduce regressions. Every cycle, I prepare its most recent release we can have in Ubuntu while ensuring stability and the ability to do long-term support, including for security updates. For the future, I'm also thinking about tracking the git stable branch as much as possible before the freezes in order to include as many fixes as possible (git branches because openssl patch releases have gotten pretty rare).

I have also been dealing with gnutls which shares a number of similarities with openssl but on a smaller scale on each count.

For both, there are many language bindings that need to be updated and fixed on a regular basis to match openssl and gnutls updates. This has been the case with pyopenssl and m2crypto for instance.

For cryptography in general, I have been working on crypto-config for which the specification was recently released on discourse. The main motives are to centralize and unify how cryptography is configured in Ubuntu, and make it more manageable to disable deprecated algorithms. Extra care has been taken to make it possible to integrate this gradually in the distribution in order to avoid flag days and disruptive transitions. For instance, the first package change is already in Oracular's openssl but is without effect until the opt-in 'crypto-config' package is installed (currently in a PPA, targeting universe during February).

For all these, I interact regularly with the Security and Server teams in addition to Foundations. I need to pay attention to the schedule of my changes, foresee potential regressions and either prevent or fix them in a timely manner. I take pride in the lack of complaint and issues even though most people pay more attention to shiny new things. This should resonate with people who still have in mind troubles with openssl and its packaging (in case you're wondering, the valgrind issue was 19 years ago).

I've also been deeply involved in the armhf 64-bit time_t transition, also known as t64. I worked around the clock to analyze and diff the ABI of thousands of packages. This is a work that had been started collaboratively in Foundations but I then specialized in it. Lacking upload rights, my name isn't written in the transition but I worked with uploaders and maintainers, including in Debian, to answer their questions (for instance about the sources of ABI incompatibilities).

Devel

  • gnupg2_2.4.4-2ubuntu22: I removed Debian-specific Windows code that had caused build failures

  • gnutls28_3.8.9-2ubuntu2: I'm integrating gnutls28 with the crypto-config framework (which is set to arrive in universe any day now)

OpenSSL and following up with its changes

Transitions

MIR

  • I think I worked on one some time ago but I need to find it again now.

SRU

  • anacron_2.3-33ubuntu2

    • This SRU involved detailed work as can be seen in https://launchpad.net/bugs/2006589 . There was only a single path to prevent the issue (which was that upgrading from 2.3-33 would disable the service). The SRU was therefore about using that single chance at a fix. It took a fair amount of testing and a few iterations which makes following through the comments sometimes difficult (and similarly, Steve reviewed the wrong patch in #23)

  • openssl_3.0.2-0ubuntu1.13

    • This was originally an SRU for four issues. Eventually, I figured out that fixing one of them would result in a behaviour change, just like the issue had introduced one. I followed the SRU rules and dropped it (behaviour changes in openssl, especially for fixes, are multi-faceted and therefore tricky; we can discuss that if you want). The SRU is also interesting as it includes patches to fix serious performance degradation which effectively prevented some workloads from running at all. I've also learnt that it's probably wiser to do smaller SRUs for openssl and maybe have them staged which security updates which occur regularly enough anyway.

New packages

  • python-google-api-core_2.19.0-0ubuntu1

    • pyopenssl has been deprecating functions that are implemented in pyca/cryptography and then dropping these functions. This has been putting pressure on reverse-dependencies, including python-oauth2client which had been deprecated upstream, and in turn on its reverse-dependencies. An update to python-googleapi was needed, and this package was a dependency. I'm a bit sad that I've been lacking time to do more on this package debian side unfortunately but at least it has allowed almost everything to move on.

  • crypto-config_0.7.3-0ubuntu1: https://bugs.launchpad.net/ubuntu/+bug/2098879 (to be uploaded soon)

Let us know what you worked on, with which development teams / developers with whom you cooperated and how it worked out.

Things I could do better

Plans for the future

General

What I like least in Ubuntu

I feel like the tooling situation is unsatisfactory. There are several repositories of tools with sometimes overlapping functionalities. Most often, the documentation is succinct and not discoverable. I am also confident that almost any time spent on tooling is recouped within weeks or a few months at most.

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@.

Endorsements

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

Simon Quigley

At the time of writing, I have sponsored nine uploads for Adrien:

This is not enough uploads for a fully-qualified technical endorsement of the application. That being said, he has become a familiar face around the Ubuntu Development community, and I generally find his uploads to be high-quality. Working with Adrien frequently enough, I would like to see him become an Ubuntu Core Developer.

While this is not a full and complete endorsement of Adrien Nader's application for Ubuntu Core Developer, I, Simon Quigley, believe we should unblock him in his efforts, and grant Ubuntu Core Developer permissions, immediately.

-- tsimonq2 2025-02-15 16:31:13

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.''
## Full list of sponsored packages can be generated here:
##  https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi
=== Areas of Improvement ===

CategoryCoreDevApplication