I, adrien, apply for core-dev.

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.

I'm applying for Core Dev directly rather than MOTU because most of the uploads I've done contain packages that go in main. As such, MOTU would only unblock me partially and would still use sponsor time.

Who I am

My Ubuntu story

My journey with Ubuntu started with early releases, roughly at the time I was starting to use Linux (always with live systems unfortunately). I cannot directly remember the versions I used but I remember the wallpapers: warty, edgy, hardy (the wallpaper you can't forget!), intrepid. At that point I spent a year or two with opensuse and then several years with Slackware. Ultimately, my taste for tweaking everything in my system weakened and I got annoyed at the development being closed to less than a dozen people. The last straw was finding out several people reported the same issue with fix but without being aware of others as there was (and still is) no bug tracker, only private emails. I was done, I wanted something with actual community involvement.

My involvement

In late 2022, I joined Canonical in the Foundations team to take care of cryptography-related packages which I've enjoyed a lot. Since then I've been aiming at keeping them as up-to-date as possible without introducing instabilities nor hampering long-term (security) maintenance.

Examples of my work / Things I'm proud of

Areas of work

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

The most notable of these is openssl: a large package with many reverse dependencies, frequent updates which are known to be 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.

Another one is gnutls which shares a number of similarities with openssl but on a smaller scale.

For both, there are many language bindings that need to be updated and fixed on a regular basis to match their updates. This has been the case recently with pyopenssl, m2crypto, ruby3.{1,2,3} and nodejs for instance.

To improve cryptography management in Ubuntu 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 changes are already in Oracular's openssl and Plucky's gnutls but are without effect until the opt-in 'crypto-config' package is installed (currently in the NEW queue).

For all these, I interact regularly with the Security and Server teams in addition to Foundations. I also 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 that doesn't sell as well as shiny new things nowadays.

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)

• libgcrypt20/1.11.0-6ubuntu1: s390x SHA3 hardware acceleration cannot be used for cSHAKE

• gsasl/2.2.1-1willsync1ubuntu1: build timed out on s390X due to LTO

OpenSSL and following up with its changes

• openssl itself: I cleaned the packaging which contained changes outdated for more than 15 years and have been maintaining it through git-ubuntu

  • 3.0.7-1ubuntu1

  • 3.0.8-1ubuntu1

  • 3.0.10-1ubuntu3

  • 3.0.2-0ubuntu1.13

  • 3.0.13-0ubuntu1

  • 3.0.13-0ubuntu2

  • 3.2.1-3ubuntu1

  • 3.2.2-1ubuntu1

  • 3.3.1-2ubuntu2

  • 3.4.0-1ubuntu1

  • 3.4.0-1ubuntu2

  • 3.4.1-1ubuntu1

• updates needed after openssl:
  • openssl 3.4 triggered an FTBFS due to with m2crypto's use of SWIG:

    • m2crypto_0.42.0-2ubuntu1 with an initial fix that turned out to cause an issue on armhf

    • openssl/3.4.0-1ubuntu2 reverts the upstream change that triggered the FTBFS

    • m2crypto_0.42.0-2ubuntu2 drop the initial patch, fix an FTBFS introduced by SWIG which was introduced by the new SWIG version (which was noticed due to the m2crypto FTBFS); at that point the FTBFS was solved

    • https://tracker.debian.org/news/1603082/accepted-m2crypto-0420-21-source-into-unstable with a better patch I came up with, and I then asked for its sync

    • mailing-list discussion where I proposed the fix which was then integrated

  • ruby3.3/3.3.4-2ubuntu7, needed updates due to a behaviour change in openssl 3.4 (for a bug fix)

  • nodejs/20.18.1+dfsg-1ubuntu1

• strace: started the practice of ensuring strace version tracks the kernel's to match all kernel features (incidentally, strace version numbers match the kernel's)

  • 5.19-0ubuntu1

  • 6.2-0.1ubuntu1

  • 6.2-0ubuntu1

  • strace 6.14 mid-March for kernel 6.14

Transitions

• OpenMPI 5:

  • parmetis_4.0.3-7ubuntu1: adapt to new openmpi configuration env vars

  • gpaw_24.6.0-1ubuntu1: ditto

  • mpi4py_4.0.1-6ubuntu1: merge and re-enable one of the recently dropped patches

• VTK9 9.3:

  • gdcm_3.0.24-1ubuntu1: patches for VTK 9.3 compat (upstreamed) plus packaging updates

  • insighttoolkit5_5.3.0-7build5: NCR

  • therion_6.2.1-1ubuntu1: add texlive-fonts-recommended to B-D to avoid a pessimist build codepath that ultimately fails

Autopkgtest retries

I've retried thousands of tests (while being mindful of the queue sizes). These retries were far from being blind and automated. Many times it was for temporary failures but I've also changed triggers to reflect transitions and dependencies or reverse-dependencies. Due to trakcing tests, I've reported infrastructure issues sevral times (I'm not counting).

MIR

• libstring-license-perl

• libtracefs/1.8.0-1ubuntu1 for which I didn't do the MIR itself but did a large amount of work to make the inclusion in main possible wrt tests

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 a deleted 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)

+1 maintenance

• https://lists.ubuntu.com/archives/ubuntu-devel/2023-February/042475.html

• a hiatus which mostly matches work on the t64 transition

• https://lists.ubuntu.com/archives/ubuntu-devel/2024-June/043040.html

• https://lists.ubuntu.com/archives/ubuntu-devel/2024-November/043179.html

• https://lists.ubuntu.com/archives/ubuntu-devel/2025-January/043259.html

Things I could do better

I heavily dislike short-term fixes. I think I've gotten this from work when having to add work-arounds for releases and at best creating bug tracking entries for actual fixes, and never fixing the actual issues (which were still causing troubles of course). This makes me do fewer changes which require less maintenance over time. I think this is a good match for cryptography-related packages. The downside is that it takes more time upfront and it is impossible to tell in advance whether this will be recouped later on or not. This is a balance that I try to improve and I am very open to feedback about it.

I mentioned changes above but this actually also applies to e-mails for which the balance should tip more towards faster replies.

Plans for the future

General

I've been tracking openssl and gnutls versions pretty closely in the latest releases. I'd like to push that further in the future and track the stable git branches in order to reduce the likelihood of encoutering fixes that introduce behavior changes after the release.

I also want to make more packages take advantage of crypto-config and ship corresponding profiles. Being core dev will be very helpful here but I will also always discuss the changes with the usual maintainers of the packages first.

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