Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
On Sun, Jul 11, 2021 at 10:54:45PM +0200, Michał Górny wrote:
> Hi, everyone.
>
> The Council has eventually decided that the proposed agenda item
> changing the EAPI workflow has not received sufficient public
> discussion, so I'd like to restart it.
>
>
> 3. When all ebuilds are removed, the EAPI is added to eapis-banned
> and the tools now explicitly forbid adding ebuilds with that EAPI.
>
>
> The change proposed in [1] eliminates step 2. The EAPI remains
> in 'deprecated' policy-state until all ebuilds using it are removed.
> There is no distinction between 'weak' deprecation ("please don't use
> it") and 'strong' ban ("you mustn't use it unless you have a very good
> reason to").
>
There seems to be a lot of time spent on whether to take 1 minute
to officialy ban an EAPI in a meeting. Plots are cool, but nothing
statistically significant is going to show given the small issues we had
in the past. The formality is simply to keep those small issues from
being a headache to other devs.
Just officially ban it, send out a message, and use the best judgement
when enforcing it (should it even need to be enforced).
-Aaron
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Changes to EAPI ban workflow
Il giorno dom 11 lug 2021 alle ore 22:55 Michał Górny ha scritto: [snip] > > This decision will also affect another posted agenda item, namely > banning EAPI 5. Switching to the new workflow will eliminate that step, > and therefore EAPI 5 won't be "banned" until all EAPI 5 ebuilds are > removed. > > If this means that stable EAPI 5 only packages will continue to work - at least until someone will replace them with a better EAPI stable version then you have my complete moral support. This obviously also affect all eclasses used by EAPI 5 only stable packages.
[gentoo-dev] [RFC] Changes to EAPI ban workflow
Hi, everyone.
The Council has eventually decided that the proposed agenda item
changing the EAPI workflow has not received sufficient public
discussion, so I'd like to restart it.
The point of contention was a proposed change to the EAPI depreciation
workflow. The current workflow consists of roughly three steps:
1. The Council decides to deprecate an EAPI. It is added to eapis-
deprecated in layout.conf and pkgcheck/repoman start emitting warnings
when they're used in ebuilds. This is a 'weak' request for developers
to stop using the old EAPI.
2. The Council decides to ban an EAPI. This is a pure policy decision
with no technical implementation. It is a 'strong' request not to use
the old EAPI, and developers have to have a very good reason (e.g.
blocked secbump, revbump due to dep changes by a third party and so on)
to touch an ebuild and leave it at old EAPI.
3. When all ebuilds are removed, the EAPI is added to eapis-banned
and the tools now explicitly forbid adding ebuilds with that EAPI.
The change proposed in [1] eliminates step 2. The EAPI remains
in 'deprecated' policy-state until all ebuilds using it are removed.
There is no distinction between 'weak' deprecation ("please don't use
it") and 'strong' ban ("you mustn't use it unless you have a very good
reason to").
My gut feeling is that having this distinction is useful. However, it
has been pointed out that we've probably never really had to use it
(i.e. use the "banned" argument to stop someone from using old EAPI)
and that the switch from "deprecated" to "banned" state did not really
affect porting away from old EAPI.
dilfridge's EAPI plots [2] can be helpful in verifying this claim,
combined with deprecation and ban dates found on the PMS project page
[3].
This decision will also affect another posted agenda item, namely
banning EAPI 5. Switching to the new workflow will eliminate that step,
and therefore EAPI 5 won't be "banned" until all EAPI 5 ebuilds are
removed.
WDYT?
[1]
https://archives.gentoo.org/gentoo-project/message/4a504a0b7aa9199bac3ebcaf54064841
[2] https://www.akhuettel.de/~huettel/plots/eapi.php
[3]
https://wiki.gentoo.org/wiki/Project:Package_Manager_Specification#Council_approval_and_use_in_Gentoo_repository
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
On Sun, Jul 11, 2021 at 03:53:31PM +0200, Thomas Deutschmann wrote: > Hi, > > TL;DR: > > Given that William said in the meanwhile, he sees no future for > opentmpfiles [1] and that nobody else, including me, is interested in > stepping up, things have changed. Add this reference as well if you want, everyone upstream seems to agree that opentmpfiles doesn't have a future. https://github.com/OpenRC/opentmpfiles/issues/19 William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
Hi, TL;DR: Given that William said in the meanwhile, he sees no future for opentmpfiles [1] and that nobody else, including me, is interested in stepping up, things have changed. Please start with the normal last-rite process and please please please, rephrase the news item and do not tell world that opentmpfiles has been masked due to the reported vulnerability because this would be wrong. 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). First, we have to take tmpfiles.d specifications into account: By default, opentmpfiles service is only reading from certain locations (for example /usr/lib/tmpfiles.d) – all of these locations are only writable for root user by default which makes it impossible for an attacker to create a controllable exploit. Furthermore, tmpfiles.d settings are only supposed for creation, deletion and cleaning of volatile and temporary files. Any package which will install tmpfiles.d settings which will create files in persistent locations should be treated like a bug in the package itself (for Gentoo packagers for example we have keepdir [3] function). Same is true for packages installing tmpfiles.d settings which will create volatile and temporary directories in user writable locations, which is usually treated like a weak file permission vulnerability in the package, similar to world-writable PID files, config files, log locations etc. Despite all the outlined pre-requirements, an attacker would still need to convince the system administrator to restart a boot service which is very uncommon and even OpenRC is warning against doing something like that. opentmpfiles specifically starts before any other services, so a compromised daemon is not capable of injecting a malicious symlink before startup: $ /lib/rc/bin/rc-depend opentmpfiles-setup sysfs devfs udev udev-trigger hwclock modules fsck root localmount opentmpfiles-setup Finally, in Gentoo Linux, like in many other distributions, from security point of view, we assume certain preconditions like running with "fs.protected_symlinks" and "fs.protected_hardlinks" enabled by default since baselayout-2.7 [4] which largely mitigates symlink attacks. (These sysctls don't affect CVE-2017-18925, but they do affect the other reported opentmpfiles CVEs, and it's worth mentioning them as examples of configuration we have to assume.) Therefore, Gentoo's security project does not believe that it is required to mask this package in Gentoo Linux for security reasons because our classification from 2017 has not changed and we usually do not mask any package with flaws which cannot be exploited in default configuration and would require discouraged settings like disabled fs.protected_symlink feature, or adjusting e.g. OpenRC's runlevels/configuration in an unsupported way. Thank you. See also: = [1] https://archives.gentoo.org/gentoo-dev/message/bce91b9d37db0b1e0980eb923a8607c9 [2] https://www.gentoo.org/support/security/vulnerability-treatment-policy.html [3] https://devmanual.gentoo.org/function-reference/install-functions/ [4] https://bugs.gentoo.org/704914 -- Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: net-print/cnrdrvcups-lb
Hey, net-print/cnrdrvcups-lb is up for grabs. It's a driver package for Canon's MFC series printers. Gotta say I've been happy how well it has worked, but since all my laser carts are empty and I can't find a retailer nearby who can supply new ones, maybe it's time to look for alternatives. Next one, something that works in Linux without external drivers... It has 2 bugs open, should be easy to fix. I might still do the next version bump for this package, but calling out any takers now. -- juippis OpenPGP_signature Description: OpenPGP digital signature
