deaddabe - debian

Status update, May 2022

2022-05-20T00:00:00+02:00

Boing, time for another status update.

Debian work

I have finally found how to make my fonts-creep2 package work on my Debian machines. The solution was to not use the TTF file that contains the Bitmap glyphs, but instead generate an OTB file, which is an OpenType format for Bitmap fonts.

This means that I can close the fonts-creep ITP bug altogether and rely on this fonts-creep2 package instead. Hopefully it will be reviewed and uploaded soon by a certified™ Debian Developer.

This font is too small for daily usage, but imagine the quantity of data you could display on an auxiliary screen with poor resolution (and poor pixel density eventually).

Here is a meme I created for the occasion:

Checks out.

Rust work

I have obsoleted my most popular Rust crate, gladis.

Indeed, the GTK folks have managed to develop a similar solution named CompositeTemplate, that is available in both gtk3-macros and gtk4-macros crates. I did not investigate from how long this has been available before I created this crate. Hopefully it did not exist before I developed it.

I have learnt a lot about Rust crates development with this crate, and managed to put in place a semi-automated release flow that I will surely use in other future crates.

See ya.

Status update, April 2022

2022-04-13T00:00:00+02:00

After missing the previous March update, here we go again!

New avatar

I created myself a new avatar! Of course, I designed it as a pixel-art picture — as you should know if you have been following the previous status update.

Since I am still trying to learn to draw stuff, I used my previous avatar that I created with a Picrew generator as a base.

Creation process of the avatar

Nothing fancy here. I imported the avatar in Aseprite and then draw over it. Well, it took me some time nonetheless. I estimate it to be around 2 or 3 hours. Note that I am still a beginner, so this (may) explain that.

If you ask me, I am very happy with the result.

Lospec palette scrapper

I have cleaned up my little scrapper script for the Lospec palettes, and have uploaded the project on Github. Lospec is a website that I have been using for retrieving cool color palettes for doing pixel art.

I quickly drafter a logo, ironically in vectorial format using Inkscape.

I also took the opportunity to upload the scrapped data directly into the repository, because who knows how may the Lospec website author may react to this. Whatever happens, the data will stay available in the repository.

The initial goal of this side project was to create an offline-first palette browser in GTK4, but I first needed the data. To be continued (?).

Debian work

The Debian work still continues, although it has calmed down. I am still trying to figure out how to make font-creep2 recognised in various software — if not giving up by proposing to package its original variant.

I also made a lot of progress on my personal (semi-private) dashboard to track my progression of packaging work. This is something that I should be able to present soon to the other Debianites, if the proposed presentation is accepted by the reviewers. I will be sure to make a case in point here if in any case.

Until then, happy coding!

Status update, February 2022

2022-03-01T00:00:00+01:00

Published one day late because of reasons, here is another status update.

Arts

This comes first, because it is what I dedicated most of my time recently. Well, I still have a problem regarding the “art” word as I am really not that great but more of a beginner.

Mostly, I am currently trying to learn and practising:

Pixel-art; and
Hand-drawing.

I started with pixel-art first — but as someone who does not know how to draw things properly, I realised that pixel art is not a magical shortcut. One still needs to know how to draw, even if twiddling with pixels.

Here is one realization of mine, using cubes because I can’t draw much more:

For hand drawing I am using Drawabox, and I have nothing special to show here. I am doing the exercises as well as practising on white paper and notebooks, nothing fancy (mostly boxes and triangles, if you really want to be disappointed).

Rust work

Gladis

I have released a new major version of gladis, named 2.0. This is a breaking change, because it is now requiring the latest 0.15 gtk-rs crate, instead of the previous 0.14 version in the 1.x versions series.

There are no major changes regarding the code itself, but there have been many changes in “chore” tasks like described in the CHANGELOG. Mainly, these have been:

Making the project REUSE-compliant; and
Making publishing new versions a lot easier, using automated tools.

Making projects REUSE-compliant

For the first point, I am now on making my new and maintained projects adhere to the software REUSE specification. I think that this is a great initiative.

Indeed, as a Debian individual contributor, figuring out the Copyright holders of big projects is always a mess. And if someone else from Redhat or another distribution wants to package the software, but does not know that this copyright checking has already been done in Debian, this madness has to be done again!

Detailing copyright holders directly in upstream using an automated format, instead of distributions, is the sanest solution in my opinion to transfer this burden to upstream (sometimes we are even “gessing” copyright holders by deep inspection of the commit history…).

Making releasing easy

Maintaining a package with two crates and keeping their versions synchronised is an “interesting” problem. I have been doing this manually for most of the history of this crate, but I am done with it. I am now using a set of related tools in order to release new versions (be it patch, minor or major) a breeze.

The tools that I have selected for this purpose are:

git-cliff for automatic CHANGELOG generation; and
cargo-release for automating the release process in general (calls git-cliff).

This process probably be more detailed in a dedicated article in the future. It can be (and will eventually be) reused in other crates in order to facilitate releasing.

I am also looking into creating a template for starting out new projects with everything configured, but it seems that Cargo templates are not available yet, so I will probably create a dedicated git repository for that.

Debian work

I have packaged two new fonts:

fonts-national-park (available in unstable)
fonts-routed-gothic (still in NEW, see ITP #1004995)

I also updated the popular fonts-ebgaramond to its latest git version in order to get some fixes that have not been published into a new, dedicated version by upstream.

Finally I have started packaging python-dt-schema (ITP #1005301) for my kernel tweaking needs, but after some yak shaking I am now blocked by dependencies planned to be packaged by other individuals, but actually not packaged yet.

Aaaand… that’s all! See you next time.

Status update, January 2022

2022-01-20T00:00:00+01:00

Let’s hope for the best for this new year. I think that compaired to the last two, it will be refreshening and full of possibilities — with the perspective of the global pandemic finally coming to an end.

Resolutions

I take the “adopt new resolutions on a new year” thing quite seriously — even if it seems unpopular these days for some reason that I ignore. Changing habits is a hard thing, and January the 1st of every year, one gets the occasion to kickstart new things.

I will not detail every change that I will start to make this year in this small update. Still, some of them are described in this article and some others will come in later publications. This looks like a teasing indeed, so stay tuned!

Debian work

Here is one resolution for this new year: reduce my Debian involvement to the parts that I enjoy the most.

Last year, on multiple times, I have found myself creating or maintaining packages that did not bring me direct usefulness in my day to day developer life. When something becomes a burden — and you do it on your free time — you should seek to stop the burden and do something that brings you satisfaction instead.

From now, this is the philosophy that I will try to stick to concerning my Debian involvment on my free time.

This means that I will stop working on the following packages:

python-ppft (RFA #1003846 created)
python-pox (ITP #992509 closed)
python-pathos (ITP #992511 closed)

They were packaged by mistake: I misread a dependency name in a package, and yak-shaving led me to package these as sub-dependencies.

I wanted to “archive” the Git repositories on Salsa, but I could not find the corresponding option in the “Settings/Advanced” section of the Gitlab interface ; the repositories will probably stay as-is for now.

Esperanto

I am still actively learning Esperanto, but failing to use it in real-life situations (online or offline). Still, this little mental challenge is nice to have. I think that when the COVID-19 pandemic situation will have chilled — hopefully soon with this Ο-variant [1] — I will look forward to meet IRL people in order to speak the “lingvo” out loud.

Final thoughs

One of the other resolutions is to — as every year — write a little bit more on this very blog. It is first and foremost a tool that I use to empty my mind and clarify subjects that I find interresting. And, as a byproduct, a publication platform that can be read by others.

I have so many ideas of things to try this year, so, as always, see you soon!

[1]	Yes, this is a real “omicron” greek leter. Thanks BÉPO for letting me access so many fancy symbols.

Status update, November 2021

2021-11-20T00:00:00+01:00

Winter is coming. Let’s see what has been achieved during the last ~30 days. As before, this status update is written from a local coffee. Let’s try to keep this monthly habbit!

Vimium-FF

I discovered and installed Vimium-FF, after reading about it on a thread on an alternative hacker news browser. It is awesome.

The default key mapping is for the QWERTY layout. I had to reconfigure it for the BÉPO keyboard layout that I am using.

Caveats: shortcuts do not work in reader mode. It is a shame because this makes me switch back to arrow keys to scroll through reading material instead of using the ergonomic HJKL keys (well, CTSR in bépo).

Project Euler

In quest of intellectual stimulation, I have started to participate in the Project Euler online challenges. I already participated when I was a student, but only made it through the 10 first because of time scarity. I participated in Python at the time, which caused some performance challenges as I was bruteforcing some solutions.

This time I am participating in my favorite programming language for non-scripting usage: Rust. The great performance and functional constructions available (generators, filters, …) make it an ideal choice for implementing the algorithms. Pencil and paper are valuable as well for constructing the final solution.

Debian work

New gftools release

I am trying to bring the new gftools release to Debian, but the new required dependencies cannot be ported because PEP-517/518 are not supported yet.

As more and more Python packages that I need to package are blocked because of this issue, it may be the time to take a break from packaging Python packages in Debian for me. Especially since the NEW queue is full again, so packages uploaded today may arrive in unstable in months anyways.

I have trouble of keeping track of bug dependencies between my different ITPs. I managed to create graphviz diagrams of the dependencies by querying the Ultimate Debian Database with some Python scripts. However this is still very manual. I hope this idea can gain some traction in the community, but I need to find energy to promote it.

Notion dashboard

I created myself a dashboard on Notion, a SaaS product that I wanted to try given the hype it recently received in the tech scene. The idea is to track the progress of (most of) my ongoing Debian packages that are not available in unstable yet.

For this, I have created a set of columns that directly represents the states of the packages in my own interpretation of the Debian delivery process:

This is not optimal and manually updated. But I think there is an idea behind this that could be explored. Maybe oneday I will pursue down this rabbit hole and create myself an automatic dashboard.

Esperanto

Ekde kvar semanaj mi lernas la esperanton. Mi estas komencanto. La lingvo estas facile. Mi usas DuoLingon kaj esperantan vortaron. Fojfoje mi usas "Google Translate" pro konfirmiĝi mian vortumijn. Mi ŝatas la esperanton pli ol la hispanon, kiu mi lernis al liceo.

Eble mi skribos esperantajn artiklojn se mi ŝatas la lingvo ankoraŭ. Sed sur otro blogo, ĉar ĝi blogo estas nur pro la teknikajn artiklojn en angla.

Ĝis la revido!

Status update, October 2021

2021-10-23T00:00:00+02:00

Leaves are falling, and so have been articles! Let’s see what other things have been achieved this month.

On writing

I am quite proud of myself. While between July and September 2021, no articles have been published. During this month, 3 of them went out! One can deduce that I have found some motivation for writing about my small experiments.

I still do not check how many readers I have. Maybe I should spend some time in setting back a GoAccess cron task to analyze the web server's logs.

I have a lot of other ideas, of course. But writing takes time. However it helps me to keep track of what I have learned over the months — as well as empty my mind to let room for other things to learn.

I am currently writing this status update in a sofa inside of a nice coffee shop. It helps to get out in order to change atmosphere and find motivation do finish something before going home. Maybe this is an habit to put in place: go to the coffee shop at least once every month in order to write other status updates!

Debian work

bcnc

I have spent a substantial amount of time in improving the Debian packaging of bCNC. Indeed, this work has been started March 2021 but has not been validated since. Thanks to the many reviews of Stefano, I have been able to push the following commits in the Salsa repository:

* b1d93bb introduce autopkgtests
* acc95ce d/control: manually add missing depends
* cd8c101 d/rules: keep .egg-info until dh_python3 for Depends
* d596c51 d/copyright: explain license inference
* e655334 d/upstream/metadata: add Registry for pypi
* 2abdd7b d/bCNC: use exec and consider spaces in args
* acf138a d/rules: do not install tests
* fa1c7e8 d/README.debian: explain missing testing dep
* 4b4cd93 new repack for embedding tests/ dir
*   e47fcd6 Update upstream source from tag 'upstream/0.9.14.317+ds2'
|\
| * c5b0368 New upstream version 0.9.14.317+ds2
* | dc8dabd d/copyright: do not exclude unexisting svgelements
* | 04354b3 d/README.debian: explain strange upstream release policy
* | d7a90f5 d/copyright: do not exclude tests anymore
* | 05fe01d d/copyright: mark code owned by Vasilis Vlachoudis
* | 35f1a7a d/control: add missing pil.imagetk dep
* | 7ce30ee move startup script outside of d/rules
* | aa0a0ec introduce README.debian
* | 2ac9741 install upstream README in docs

A lot of cleanup indeed. I think that the package is now in good shape for being sponsored into the NEW queue, where copyrights will be validated.

Bug reporting

While working on my Debian packages, I also found issues in other Debian packages. While I do not have the complete list in mind for this month's worth of bugs, it shows that reporting bugs is also an important way of contributing to the Debian ecosystem.

By using the bts block XXXXXX by YYYYYY, I was able to register the dependencies between my ITP (Intent To Package) bugs and the bugs I reported and that are currently blocking me from making progress. Some of them have been closed pretty fast, some others are still open.

Since the dependencies are stored in the bugs database, I can put these packages on hold and move on to do other things. I will get notified by email when the bugs are closed, and can check back on where I stopped.

See ya!

Status update, September 2021

2021-09-20T00:00:00+02:00

Now that we finally had some (late) sun, let’s see how things have been.

Rust work

crates.io

I spend too much time trying to figure out how to center images in README.md files. Not only on github.com, but also on crates.io. To this purpose, I dug into the source code of the latter to see how I could make image centering work.

At first, I though the correct syntax was:

I proposed a PR (pull request) to the upstream project, introducing a new unit test to make sure that this usecase will be documented are guaranteed to keep working in the future. After getting this merged, I actually tested to center an image in a crate and push it to crates.io. And the image was not centered. Dumb me. I should have tried this first.

Digging a little bit more, the correct syntax to center images both on github.com and crates.io was:

After republishing to crates.io, this now seems to work. The image is centered. Now push to check for github.com. Centered too! Time to send a fix to upstream in order to really test that image centering will be supported in the future.

What a journey. Next time I will remember to test my changes before annoying upstream with a double PR instead of one.

cargo-release

I have started to play with cargo-release in order to try to automate my crate deployements. Indeed, most of my crates are making use of proc macros. They are architectured like this:

one main crate, eg. gladis; and
one macro crate, eg. gladis_proc_macro.

Both crates live in the same repository, using a cargo workspace to group them. The crates use the same version release number. However, I manually need to bump the versions in different files on each release. This is where cargo-release helps.

I am however still having trouble in trying to adapt this tool to my workflow. However I hope that I will be able to make it work, as I have currently 3 crates that are using this dual main/macro crates mechanism.

Debian work

DM application

My Debian Maintainer application, which I was happy to brag about in the previous status update, has stalled.

I managed to get my OpenPGP key signed in-person by sharing beers with a DD (Debian Developer) in Paris. However this was not enough to conclude the application. I still needed to find an advocate, that is a person that thinks my technical contributions are strong enough to be let done without further babysitting.

I now need to provide with more signed, irreprochable work before gathering enough street cred to propose my application again.

Stay tuned!

Status update, August 2021

2021-08-18T00:00:00+02:00

Let's see what has been accomplished during these (rather cold) summer months.

Rust work

glade-bindgen

I have proposed serveral pull-requests for the glade-bindgen Rust crate:

They all got merged. I am interested into this crate because it is pushing a step further what I managed to do with my gladis crate: automatically integrate GTK *.ui XML interface files with Rust code seamlessly.

gladis

Regarding gladis itself, I have:

Added an example in Gladis using the Relm crate; and
Added an example in Relm using the Gladis crate (not merged yet).

By this reciprocal example introduction, I hope that gladis will be more visible and help developers simplify their Relm use with UI files. When comparing the previous glade.rs example with the new glade_gladis.rs one, the gains are clear.

Next step would be to do the same for the relm4 crate for GTK4 (and it has a nice logo now).

debcontrol_struct

Finally, I have created a new crate: debcontrol_struct.

This crate uses a proc macro to derive named structs and automatically allow them to be read from a Debian control file. Not only debian/control, but any file that uses this mail-inspired key: value syntax.

The provided example is used to parse the beginning of the debian/copyright file that also uses the control syntax.

Debian work

opentracker

I have packaged the opentracker package for Debian. I had to write few patches in order to make it work as intented. I proposed the patches back to upstream as usual — via direct email for this one — and they got merged pretty quickly into the main branch!

Here are two patches for the curious:

I also wrote a man page for the software, by looking at how other man pages were redacted, as well as opentracker's --help output. I have sent the man page to upstream, but got no answer (yet).

Misc

Regarding my other packages, I updated python-strictyaml from 1.3.2 to 1.4.4 on Salsa, leaving it for the Python Team to review while I do not have push rights, but…

DM application

…Last, but not least, I have started to apply as a Debian Maintainer to be a part of the team, after something like a year of contributing to the project. I hope that this will succeed, in order to be able to update my packages without requiring the review of another Debian Developer each time.

Wish me success!

Status update, July 2021

2021-07-25T00:00:00+02:00

No status update since a long time (almost a year), mainly because of a lot of personal challenges. But now is the time to go back on the status update habit!

This kind of article is used to keep track of what I have achieved over the course of the last month-or-so. Why keeping track? Because it is a nice way to remind me that I have not been that lazy during the month. And also because it may make you reader find interesting software or problems from my contribution list.

Rust work

Maintainance tasks:

Introduce Github Actions for my gladis and gtk_liststore_item Rust crates;
Adapt the last two crates to work with the gtk 0.14.0 crate release; and
Release them on crates.io.

After fixing these GTK Rust crates, I stumbled upon the new glade-bindgen crate. This crate pushes the concept of gladis further: it automatically generate structs containing all of the Gtk widgets, from the source *.ui files.

This approach is even more attractive than the gladis approach I took some time ago. It would be nice for this crate to reach a certain level of maturity. To this intent, I have proposed two (now merged) pull-requests to this crate:

Next contributions I would like to make is to make the README a little bit sexier, as well as applying the rustfmt automatic formating tool on the autogenerated *.ui.rs files.

Debian work

Debian has been in the freeze state for quite some time now. No new packages allowed. The NEW queue is filling up. This is the reason why I did not spend time creating or improving new packages for now.

Now that the Full Freeze has been announced, I may start to look back at contributing. At least push all of my waiting packages into testing.

I am also somewhat interested in finishing the packaging of the opentracker software (discussion started in 2012!). I use it extensively, but was surprised that it was not available in the Debian archive.

msmtp and AppArmor: investigating a curious access issue

2020-12-22T00:00:00+01:00

Here is a writeup about how I investigated an issue with msmtp configuration files on my Debian laptop, how I deduced it was caused by AppArmor and finally how I proposed to fix the issue in the package itself.

Background

I am currently refactoring all of my email configuration for command line usage. My current stack currently uses the following software:

mutt to read emails;
neovim to write them (called by mutt);
isync (mbsync) to synchronize them; and
msmtp to send them.

While moving reading man pages, I have noticed that msmtp(1) specifies that msmtp supports the $XDG_CONFIG_HOME/msmtp/config configuration file path, in addition to ~/.msmtprc that I have been using.

The $XDG_CONFIG_HOME usually expands to ~/.config/ directory. It is a standard used by a lot of programs to store their configuration files instead of putting them in arbitrary files directly in the $HOME directory.

I always used ~/.msmtprc before, but regrouping files into $XDG_CONFIG_HOME is appealing. It permits to have a cleaner $HOME directory structure. This is nice to have when you accidentally list all files in there.

One important fact to note is that I use GNU Stow in order to create symlinks for managing my dotfiles. All of them are regrouped per-software in my ~/dotfiles git repository.

Here is a non-exhaustive tree of this directory:

$ tree -a ~/dotfiles
/home/user/dotfiles
├── mutt
│   ├── .muttrc
│   ├── .msmtprc
│   ├── .mutt
│   │   ├── common.rc
│   │   ├── ...

When I am on a system that I want to configure to use mutt (and all the related software like msmtp), I just run the following commands to symlink all the configuration files into my home directory:

$ cd dotfiles/
$ stow mutt
$ ls -l ~/.muttrc
... /home/user/.muttrc -> dotfiles/mutt/.muttrc
$ ls -l ~/.msmtprc
... /home/user/.msmtprc -> dotfiles/mutt/.msmtprc

Moving the msmtp configuration

This configuration file is moved so that it uses the $XDG_CONFIG_HOME path:

$ cd ~/dotfiles
$ mkdir -p mutt/.config/msmtp/
$ git mv mutt/.msmtprc mutt/.config/msmtp/config
$ rm ~/.msmtprc
$ stow mutt
$ ls -ld ~/.config/msmtp
... /home/user/.config/msmtp -> ../dotfiles/mutt/.config/msmtp

After moving this file, msmtp is not able to read its configuration file anymore. This is the message displayed when running the following example command to send a test email:

$ echo "hello, world" | msmtp -t example@example.org
msmtp: account default not found: no configuration file available

In order to verify that msmtp is trying to open the ~/.config/msmtp/config file like the manual page states, let’s use strace to see which files are accessed:

$ echo -e "foo" | strace msmtp -t example@example.org
...

openat(AT_FDCWD, "/etc/msmtprc", O_RDONLY)
= -1 (No such file or directory)

stat("/home/user/.msmtprc", 0x...)
= -1 ENOENT (No such file or directory)

stat("/home/user/.config/msmtp/config",
     {st_mode=S_IFREG|0644, st_size=551, ...})
= 0

geteuid()
= 1000

openat(AT_FDCWD, "/home/user/.config/msmtp/config", O_RDONLY)
= -1 EACCES (Permission denied)

We can see that msmtp is trying different configuration files. It can see our configuration file (stat), but it fails when trying to open it. Then it finally prints the error message and exits with non-zero error.

The mode of the file detected by stat is 644 so there is no reason msmtp should not be able to open the file… except if something else is preventing it to open it!

Investigating AppArmor rules

And this is when you have to consider the rest of my system. I am using Debian testing, which is preparing for the bullseye release. But since buster release, AppArmor is activated by default.

AppArmor is a software that confines programs according to a set of rules. So this would certainly explain why msmtp cannot access the configuration file, while I can access it with any other text editor.

By looking into the rules directory, we can indeed see that there is a set of rules activated:

$ ls -lh /etc/apparmor.d/usr.bin.msmtp
-rw-r--r-- 1 root root 1,5K 16 Dec  14:37 /etc/apparmor.d/usr.bin.msmtp

Here is its (edited) content:

$ cat /etc/apparmor.d/usr.bin.msmtp
...

profile msmtp /usr/bin/msmtp flags=(attach_disconnected) {
  ...

  /usr/bin/msmtp          mr,
  /etc/aliases            r,
  /etc/msmtprc            r,
  /etc/mailname           r,
  /etc/netrc              r,
  owner @{HOME}/.msmtp*   r,
  owner @{HOME}/.netrc    r,
  owner @{HOME}/.tls-crls r,

  owner @{HOME}/.msmtp*.log wk,
  /var/log/msmtp            wk,

  owner @{HOME}/**/*msmtprc        r,
  owner @{HOME}/.config/msmtp/*    r,
  owner @{HOME}/.cache/msmtp/*     r,
  owner @{HOME}/.cache/msmtp/*.log wk,

  ...

  #include 
}

We can see here the list of files that /usr/bin/msmtp program is allowed to access on the system. The files we are interested in are the configuration files in the home directory of the user, represented by @{HOME}.

We can see that the @{HOME}/**/*msmtprc rule matches the previous path that we were using (via the symlink): ~/dotfiles/mutt/.msmtprc.

However, the rule using the XDG_CONFIG_HOME is not using a ** directory wildcard. This means that the program can read the file in ~/.config, but only if it is a plain file. If it is a symlink redirecting to somewhere else in the home directory, this rule prevents msmtp from reading the link.

The solution seems simple: introduce a directory wildcard for the ~/.config path as well. Here is the modification that I applied onto this file as root:

$ diff -u /etc/apparmor.d/usr.bin.msmtp.orig /etc/apparmor.d/usr.bin.msmtp
--- /etc/apparmor.d/usr.bin.msmtp.orig      2020-12-16 13:25:37.618559611 +0100
+++ /etc/apparmor.d/usr.bin.msmtp   2020-12-22 16:14:55.067110824 +0100
@@ -23,7 +23,7 @@
   /var/log/msmtp            wk,

   owner @{HOME}/**/*msmtprc        r,
-  owner @{HOME}/.config/msmtp/*    r,
+  owner @{HOME}/**/.config/msmtp/* r,
   owner @{HOME}/.cache/msmtp/*     r,
   owner @{HOME}/.cache/msmtp/*.log wk,

We need to restart AppArmor in order for the changes to be applied:

$ sudo apparmor_parser -R /etc/apparmor.d/usr.bin.msmtp

And now, if we try to call msmtp again with our symlinked configuration file, everything works as expected:

$ echo -e "foo" | msmtp -t example@example.org

(msmtp will fail because of the example address, but works with a real one)

Fixing the bug in Debian

So, now that we have identified the problem, it would be nice to fix it so that other people do not have to conduct the same kind of investigation (although it was fun to do!).

First, we need to find out which package is installing these rules for msmtp:

$ apt-file search /etc/apparmor.d/usr.bin.msmtp
msmtp: /etc/apparmor.d/usr.bin.msmtp

We can see that the rules are provided by the msmtp package itself. We could directly file a bug using the reportbug tool, but let’s be nice and first prepare a patch for the source package so that the maintainer can merge the fix directly.

Let's download the source package of msmtp:

$ mkdir -p ~/tmp/msmtp
$ cd ~/tmp/msmtp
$ apt source msmtp
Reading package lists... Done
NOTICE: 'msmtp' packaging is maintained in the 'Git' version
control system at:
https://salsa.debian.org/kolter/msmtp.git
Please use:
git clone https://salsa.debian.org/kolter/msmtp.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 377 kB of source archives.
...

We see an interesting notice that tells us that this package is maintained via Git. We should probably clone the repository instead of using the source package, since the issue may have already been fixed:

$ git clone https://salsa.debian.org/kolter/msmtp.git
...
$ cd msmtp
$ find . -name 'usr.bin.msmtp'
./debian/apparmor/usr.bin.msmtp
$ diff -u /etc/apparmor.d/usr.bin.msmtp.orig ./debian/apparmor/usr.bin.msmtp

Using diff, we can see that there is no difference between the file installed on our system and the latest rules. So we can just replace this file with the one that we have patched, and create a commit out of it:

$ cp /etc/apparmor.d/usr.bin.msmtp ./debian/apparmor/usr.bin.msmtp
$ git commit ./debian/apparmor/usr.bin.msmtp
...
$ git format-patch -1

From here we can create a bug for the package with reportbug and attach this patch as a proposed solution:

$ reportbug --mutt msmtp
...
12 bug reports found:

Bugs with severity important
   1) #917260  msmtp: hangs after message termination [.]

Bugs with severity normal
   2) #683892  msmtp attempts to connect to gnome-keyring
   3) #933551  msmtp can't write logs to an encfs file
   4) #942457  msmtp: Running msmtp as a user and Apparmor
   5) #944188  /etc/msmtprc password disclosure
   6) #945024  msmtp: Doesn't generate a Message-Id
   7) #969198  msmtp-mta package should use update-alternatives for symlinking to msmtp
   8) #975333  msmtp: AppArmor profile breaks --file, logfile, and passwordeval

Bugs with severity minor
   9) #487555  Shouldn't complain about permissions unless .msmtprc contains passwords

Bugs with severity wishlist
  10) #569122  $HOME/.msmtprc is incompatible with vixie cron.
  11) #810727  msmtp: should be able to pull hostname from server greeting (for gssapi)
  12) #834167  Should allow pinning server key
(1-12/12) Is the bug you found listed above [y|N|b|m|r|q|s|f|e|?]?

We can see that there are already two bugs regarding msmtp and apparmor.

In #975333, it seems to be agreed that the AppArmor rules are breaking many workflows, and that users should be able to easily disable them for msmtp. This is currently being worked on by the maintainer, if I understood the discussion correctly.

In #942457, there are some complaints about how using symlinks and dotfiles does not always work. Some people resort to copy the file instead of linking to it. This looks like a bug to attach our patch to.

I have sent a new answer to this bug report, confirming that this bug is still occurring. The patch has also been proposed for the current package maintainer to fix the issue described in this article.

Conclusion

msmtp is a nice piece of software. It allows me to send mails via mutt or the command line easily. However the AppArmor rules proposed in the Debian package are a little bit restrictive. They should be improved (the intent of this article), or easily disabled while we are still figuring this out.

Happy mailing!

deaddabe - debian

Status update, May 2022

Debian work

Rust work

Status update, April 2022

New avatar

Lospec palette scrapper

Debian work

Status update, February 2022

Arts

Rust work

Gladis

Making projects REUSE-compliant

Making releasing easy

Debian work

Status update, January 2022

Resolutions

Debian work

Meta

Esperanto

Final thoughs

Status update, November 2021

Vimium-FF

Project Euler

Debian work

New gftools release

Notion dashboard

Esperanto

Status update, October 2021

On writing

Debian work

bcnc

Bug reporting

Status update, September 2021

Rust work

crates.io

cargo-release

Debian work

DM application

Status update, August 2021

Rust work

glade-bindgen

gladis

debcontrol_struct

Debian work

opentracker

Misc

DM application

Status update, July 2021

Rust work

Debian work

Meta

msmtp and AppArmor: investigating a curious access issue

Background

Moving the msmtp configuration

Investigating AppArmor rules

Fixing the bug in Debian

Conclusion