[gentoo-dev] [PATCH v2] 2021-07-15-opentmpfiles-deprecation: add news item
Signed-off-by: Georgy Yakovlev Signed-off-by: Sam James --- ...2021-07-15-opentmpfiles-deprecation.en.txt | 69 +++ 1 file changed, 69 insertions(+) create mode 100644 2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt diff --git a/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt b/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt new file mode 100644 index 000..9f952d4 --- /dev/null +++ b/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt @@ -0,0 +1,69 @@ +Title: systemd-tmpfiles replaces deprecated opentmpfiles +Author: Georgy Yakovlev +Author: Sam James +Posted: 2021-07-15 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/opentmpfiles +Display-If-Installed: sys-apps/systemd-tmpfiles + +A tmpfiles [0] implementation provides a generic mechanism to define +the creation of regular files, directories, pipes, and device nodes, +adjustments to their access mode, ownership, attributes, quota +assignments, and contents, and finally their time-based removal. +It is commonly used for volatile and temporary files and directories +such as those located under /run/, /tmp/, /var/tmp/, the API file +systems such as /sys/ or /proc/, as well as some other directories +below /var/. [1] + +On 2021-07-06, the sys-apps/opentmpfiles package was initially masked +due to a root privilege escalation vulnerability (CVE-2017-18925 [2], +bug #751415 [3], issue 4 [4] upstream). + +The severity of this vulnerability is disputed due to the practical +obstacles to its exploitation in any default or supported configuration. + +That said, the use of opentmpfiles is discouraged by its maintainer due +to the unpatched vulnerability and other long-standing bugs [5]. It has +now been declared obsolete in favour of systemd-tmpfiles by opentmpfiles +upstream. + +Users will start seeing their package manager trying to replace +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is +another provider of virtual/tmpfiles. + +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does +not use dbus, and is just a drop-in replacement for opentmpfiles. It is +a small binary built from systemd source code, but works separately, +similarly to eudev or elogind. It is known to work on both glibc and +musl systems. + +Note that systemd-tmpfiles is specifically for non-systemd systems. It +is intended to be used on an OpenRC system. + +If you wish to selectively test systemd-tmpfiles, follow those steps: + + 1. # emerge --oneshot sys-apps/systemd-tmpfiles + 2. # reboot + 3. # rm /etc/runlevels/boot/opentmpfiles-setup + 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev + +No other steps required. + +If you still wish to use opentmpfiles for the time being, you can unmask [6] +opentmpfiles: + 1. In /etc/portage/package.unmask, add a line: + -sys-apps/opentmpfiles- + 2. # emerge --oneshot sys-apps/opentmpfiles + +Note that opentmpfiles is likely to be removed from gentoo repository +in the future. You may wish to put it in a local overlay instead [7]. + +[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html +[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html +[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925 +[3] https://bugs.gentoo.org/751415 +[4] https://github.com/OpenRC/opentmpfiles/issues/4 +[5] https://bugs.gentoo.org/741216 +[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package +[7] https://wiki.gentoo.org/wiki/Custom_ebuild_repository#Creating_a_local_repository -- 2.32.0
[gentoo-dev] [PATCH] 2021-07-15-opentmpfiles-deprecation: add news item
Signed-off-by: Georgy Yakovlev Signed-off-by: Sam James --- ...2021-07-15-opentmpfiles-deprecation.en.txt | 69 +++ 1 file changed, 69 insertions(+) create mode 100644 2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt diff --git a/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt b/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt new file mode 100644 index 000..6de2d42 --- /dev/null +++ b/2021-07-15-opentmpfiles-deprecation/2021-07-15-opentmpfiles-deprecation.en.txt @@ -0,0 +1,69 @@ +Title: systemd-tmpfiles replaces opentmpfiles due to deprecation +Author: Georgy Yakovlev +Author: Sam James +Posted: 2021-07-15 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: sys-apps/opentmpfiles +Display-If-Installed: sys-apps/systemd-tmpfiles + +A tmpfiles [0] implementation provides a generic mechanism to define +the creation of regular files, directories, pipes, and device nodes, +adjustments to their access mode, ownership, attributes, quota +assignments, and contents, and finally their time-based removal. +It is commonly used for volatile and temporary files and directories +such as those located under /run/, /tmp/, /var/tmp/, the API file +systems such as /sys/ or /proc/, as well as some other directories +below /var/. [1] + +On 2021-07-06, the sys-apps/opentmpfiles package was initially masked +due to a root privilege escalation vulnerability (CVE-2017-18925 [2], +bug #751415 [3], issue 4 [4] upstream). + +The severity of this vulnerability is disputed due to the practical +obstacles to its exploitation in any default or supported configuration. + +That said, the use of opentmpfiles is discouraged by its maintainer due +to the unpatched vulnerability and other long-standing bugs [5]. It has +now been declared obsolete in favour of systemd-tmpfiles by opentmpfiles +upstream. + +Users will start seeing their package manager trying to replace +sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is +another provider of virtual/tmpfiles. + +Despite the name, 'systemd-tmpfiles' does not depend on systemd, does +not use dbus, and is just a drop-in replacement for opentmpfiles. It is +a small binary built from systemd source code, but works separately, +similarly to eudev or elogind. It is known to work on both glibc and +musl systems. + +Note that systemd-tmpfiles is specifically for non-systemd systems. It +is intended to be used on an OpenRC system. + +If you wish to selectively test systemd-tmpfiles, follow those steps: + + 1. # emerge --oneshot sys-apps/systemd-tmpfiles + 2. # reboot + 3. # rm /etc/runlevels/boot/opentmpfiles-setup + 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev + +No other steps required. + +If you still wish to use opentmpfiles for the time being, you can unmask [6] +opentmpfiles: + 1. In /etc/portage/package.unmask, add a line: + -sys-apps/opentmpfiles- + 2. # emerge --oneshot sys-apps/opentmpfiles + +Note that opentmpfiles is likely to be removed from gentoo repository +in the future. You may wish to put it in a local overlay instead [7]. + +[0] https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html +[1] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html +[2] https://nvd.nist.gov/vuln/detail/CVE-2017-18925 +[3] https://bugs.gentoo.org/751415 +[4] https://github.com/OpenRC/opentmpfiles/issues/4 +[5] https://bugs.gentoo.org/741216 +[6] https://wiki.gentoo.org/wiki/Knowledge_Base:Unmasking_a_package +[7] https://wiki.gentoo.org/wiki/Custom_ebuild_repository#Creating_a_local_repository -- 2.32.0
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
On Wed, Jul 14, 2021 at 12:04:34AM +0200, Andreas K. Huettel wrote: > > > The package was masked due to a miscommunication with the Gentoo > > Security project. > > > > While it is true that the way opentmpfiles is currently implemented > > allows for certain races, from the security point of view, you always > > have to classify the vulnerability in context of your threat model > > because security depends on multiple layers (onion model). > > > I would like to respectfully point out that this makes > > 1) either the severity assignment of this bug by the Security project as B1 > wrong (i.e. it should have been classified "harmless") > The Gentoo model is not perfect and should be overhauled. However, it works for most things and sometimes bugs fall between the cracks. The package shouldn't have been masked either based on a bug that was purposely ignored for many years simply because they want to disband the package now and found a "security reason" to add to the mask. > 2) or the entire classification of severity levels according to the Security > project pointless (i.e. you can't base any actions on them because a mystery > onion needs to be taken into account). > I am not sure if this is sarcasm, but every bug must be considered through the correct aperture. That is, based on your environment, protections in place, defense in depth, and other buzzwords... hence the onion analogy. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> The package was masked due to a miscommunication with the Gentoo > Security project. > > While it is true that the way opentmpfiles is currently implemented > allows for certain races, from the security point of view, you always > have to classify the vulnerability in context of your threat model > because security depends on multiple layers (onion model). I would like to respectfully point out that this makes 1) either the severity assignment of this bug by the Security project as B1 wrong (i.e. it should have been classified "harmless") 2) or the entire classification of severity levels according to the Security project pointless (i.e. you can't base any actions on them because a mystery onion needs to be taken into account). https://www.gentoo.org/support/security/vulnerability-treatment-policy.html -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] News item v2: media-sound/pulseeffects "renaming"
On Tue, 2021-07-13 at 13:38 +0100, Marek Szuba wrote: > Signed-off-by: Marek Szuba > --- > ...2021-07-16-pulseeffects-easyeffects.en.txt | 33 +++ > 1 file changed, 33 insertions(+) > create mode 100644 > 2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt > > diff --git > a/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt > > b/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt > new file mode 100644 > index 000..70d1899 > --- /dev/null > +++ > b/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt > @@ -0,0 +1,33 @@ > +Title: PulseEffects-5+ are now media-sound/easyeffects > +Author: Marek Szuba > +Posted: 2021-07-16 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Installed: >=media-sound/pulseeffects-5.0.0 > + > +Since version 5.0.0, media-sound/pulseeffects have explicitly required > +media-video/pipewire rather than just a PulseAudio client (i.e. either > +PipeWire or plain media-sound/pulseaudio). Following up on this change, > +upstream has decided to rename the project to EasyEffects starting with > +version 6.0.0. > + > +Gentoo will follow the upstream renaming but in a slightly different > +fashion: > + - versions older than 5.0.0, i.e. ones not depending on > + media-video/pipewire, will continue to use the name > + media-sound/pulseeffects; > + - versions: 5.0.0 and newer, i.e. all requiring media-video/pipewire, > + will be available as media-sound/easyeffects. > + > +media-sound/easyeffects is already available in the tree, and the > +remaining PipeWire-dependent ebuilds of media-sound/pulseeffects will s/ebuilds/versions/. > +be removed in 7 days. > Probably better to use an explicit date here. '7 days' sounds relative to 'now'. > Therefore, PipeWire users of > +media-sound/pulseeffects should switch to the new package by > +deselecting the old one and installing the new one, e.g. > + > +emerge --deselect media-sound/pulseeffects > +emerge media-sound/easyeffects > + > +No action is required of media-sound/pulseeffects users who either use > +PulseAudio exclusively or wish to retain the ability to use this > +package with both PulseAudio and PipeWire. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
On Mon, Jul 12, 2021 at 11:24:42AM +0100, Marek Szuba wrote: > On 2021-07-10 22:55, William Hubbs wrote: > > > Change the _R0 suffix on these variable names to _ECLASS. > > Since my question in response to the previous round of this has yet to > be answered, I repeat: are there any non-cosmetic reasons for doing this? Consistency with the rest of the tree. If you do a "git grep _R0" on the eclass directory, the lua eclasses are the only ones that have this in the names of the guard variables, and the eclasses themselves aren't named lua-r0.eclass etc. What will break if I do this? William signature.asc Description: PGP signature
[gentoo-dev] [PATCH] News item v2: media-sound/pulseeffects "renaming"
Signed-off-by: Marek Szuba --- ...2021-07-16-pulseeffects-easyeffects.en.txt | 33 +++ 1 file changed, 33 insertions(+) create mode 100644 2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt diff --git a/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt b/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt new file mode 100644 index 000..70d1899 --- /dev/null +++ b/2021-07-16-pulseeffects-easyeffects/2021-07-16-pulseeffects-easyeffects.en.txt @@ -0,0 +1,33 @@ +Title: PulseEffects-5+ are now media-sound/easyeffects +Author: Marek Szuba +Posted: 2021-07-16 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: >=media-sound/pulseeffects-5.0.0 + +Since version 5.0.0, media-sound/pulseeffects have explicitly required +media-video/pipewire rather than just a PulseAudio client (i.e. either +PipeWire or plain media-sound/pulseaudio). Following up on this change, +upstream has decided to rename the project to EasyEffects starting with +version 6.0.0. + +Gentoo will follow the upstream renaming but in a slightly different +fashion: + - versions older than 5.0.0, i.e. ones not depending on + media-video/pipewire, will continue to use the name + media-sound/pulseeffects; + - versions: 5.0.0 and newer, i.e. all requiring media-video/pipewire, + will be available as media-sound/easyeffects. + +media-sound/easyeffects is already available in the tree, and the +remaining PipeWire-dependent ebuilds of media-sound/pulseeffects will +be removed in 7 days. Therefore, PipeWire users of +media-sound/pulseeffects should switch to the new package by +deselecting the old one and installing the new one, e.g. + +emerge --deselect media-sound/pulseeffects +emerge media-sound/easyeffects + +No action is required of media-sound/pulseeffects users who either use +PulseAudio exclusively or wish to retain the ability to use this +package with both PulseAudio and PipeWire. -- 2.31.1
[gentoo-dev] News item v2: media-sound/pulseeffects "renaming"
New version incorporating suggestions from mgorny and ulm, thank you for your feedback. -- Marecki
[gentoo-dev] Last rites: dev-python/{markuppy,tablib}
# Marco Scardovi (2021-07-13) # These packages were only ported for netbox. Not useful for anything else # No revdeps. Removal in 30 days (Bug #801991) dev-python/markuppy dev-python/tablib
Re: [gentoo-dev] News item: media-sound/pulseffects "renaming"
On 2021-07-13 07:20, Michał Górny wrote: Title: PipeWire versions of PulseEffects are now media-sound/easyeffects The title is too long (50 chars max AFAIR) Argh, and after all my attempts to keep this as short as possible while keeping this meaningful :-) Will think of something even shorter. Display-If-Installed: >=media-sound/pulseeffects-5.0.0 Why not display it to users of all versions? Only people using 5.0.0+ will have to take any action on this so it feels like displaying it for all versions would needlessly bother users who are happy with PulseAudio. I like short but here it seems that you're skipping some essential details and having users guess. > Maybe start by explaining the current state [...] Makes sense, thanks! I'll revise this along the lines of your suggestions. Finally, tell explicitly what PA and PW users should do, and provide an example emerge snippet (do they need to deselect pulseeffects?). Right, they do need to deselect pulseeffects given it will almost certainly be in the world file, won't they. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
