Is opentmpfiles dead?

[Acatorn]

Hello there,

Is opentmpfiles officialy dead and we have to use systemd-tmpfiles instead? Is there any other way to handle tmpfiles in OpenRC?

Best Regards,
Acatorn

[mid-kid]

For all intents and purposes, it seems abandoned by Gentoo. See:
https://archives.gentoo.org/gentoo-dev/message/689954cc7fd55402dc4c82aa0ac70efb
It's been replaced as the default tmpfiles provider: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab23417927d8454c8bb1c0ae52a5cac79d140b94
And the latest version (0.3.1) has been dropped due to major bugs: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c819870ebb9ff2cf25e276527fbcd6affe74c297 https://bugs.gentoo.org/751739
See also the CVE bugs in the issues tracker, as it has some security issues.

That said, I still use 0.2, as I personally believe something so simple really doesn't need a very complex implementation regardless of whatever fringe TOCTOU issues people come up with. It still works just fine. The currently reported security issues are very unlikely to be hit unless I write my own tmpfiles.d files, and the ones currently installed on my system don't hit them.
I wouldn't recommend users who can install systemd-tmpfiles to use this, but if you need a simple and portable implementation for whatever reason, it works.

And of course, anyone is free to pick it back up and resume development.

[williamh]

Here are my thoughts about opentmpfiles and systemd-tmpfiles.

• opentmpfiles does not have all of the features of systemd-tmpfiles.
• opentmpfiles is vulnerable to a cve. I think mitigating this will take a complete rewrite in C.
• If we do rewrite in C, we are echoing work that has already been done in systemd-tmpfiles.
• I've been told that systemd-tmpfiles works fine on gentoo musl as well.
• systemd-tmpfiles is a small binary and a couple of man pages, so it is a pretty small package.
• systemd-tmpfiles is part of the systemd tarball, but it runs fine standalone, like udev does.

Given this, I'm fine with systemd-tmpfiles for now since maintaining opentmpfiles feels like a lot of work without much benefit. However, if there are reasons I'm missing that we should advocate for keeping opentmpfiles and fixing it, I'm willing to listen.

[lu-zero]

In case somebody really wants yet another alternative implementation https://github.com/rust-torino/tmpfiles-rs exists, it was part of the local rust meetup activities (now sort of on-hold due covid).

as long the reference implementation does not bring additional dependencies and/or breaks our use-case (static linking, non-gnu libcs, non-gnu C compiler), I see its adoption a pragmatic choice.

[vapier]

i'm not seeing any reason for opentmpfiles to exist now that systemd-tmpfiles can be compiled independently from anything else. so unless someone has a reason for it, we can update the README to direct people to that.

[Acatorn]

Thank you all for your answers. It seems that it really makes no sense to reinvent the wheel for such small component.

[mid-kid]

I'd keep this issue open for visibility, I was confused regarding the state of the project at first as well, and I'm sure we're not the only ones. Having a statement from the primary maintainer helps a ton.

[williamh]

I'll add a note to the README for this project.

[orbea]

I just want to link these alternative implementations I have found, I am not sure how usable they are or not.

https://github.com/juur/tmpfilesd
https://github.com/eweOS/pawprint