[gentoo-dev] XDG_DATA_DIRS handling under packages
Hello, Unlike most other XDG base directories[1], we do not do anything with XDG_DATA_DIRS - not in xdg_environment_reset, nor in ENV_UNSET. This is now causing some issues. Historically there was an issue[2] where a package added XDG_DATA_DIRS via env.d, which meant that if the base package (x11-misc/xdg-utils) wasn't yet installed, XDG_DATA_DIRS was set, but did not include the default paths, which broke some things as demonstrated there. Now there is an issue[3] where another package prepends other paths, which are not accessible when sandboxed and some tests are trying to access them. In my case, I'm now hitting this with flatpak, which prepends these paths via profile.d instead (and does have correct handling of the default dirs if XDG_DATA_DIRS was previously unset). This is a fundamental thing, so just unsetting it only in that package feels rather incomplete. I would think that the correct fix would be add XDG_DATA_DIRS to ENV_UNSET and also unsetting it in xdg_environment_reset (for the benefit of older EAPIs), but I fear that in some cases we specifically do need it to see what variables are in there. Perhaps prefix. If that's the case, per-ebuild unsetting could be problematic for those cases as well. Or is there some way to avoid such use cases of XDG_DATA_DIRS additions to not reach the portage environment in the first place? Thoughts? Mart 1. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html 2. https://bugs.gentoo.org/635040 3. https://bugs.gentoo.org/701978 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group
Am Donnerstag, 12. August 2021, 19:39:08 CEST schrieb Michael Orlitzky: > On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote: > > The default owner is root:root anyway. > > This is only true of you don't call insopts earlier with some other > value. I see "insopts -o root -g qmail -m 700" in there so you might > want to double check. Not my day. Ok, given that there are several places that change users and groups and the subfunctions are not always called it would be very few places where I can remove the root:root (about 3) and be sure that everything works. For that reason I would just keep them all and go back to the initial patch 2. Eike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 4/3] qmail.eclass: remove needless keepdirs
Adding an extra keep file in the intermediate /var/qmail is never necessary,
and the binary directory is filled by the installation anyway.
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index 4aeba918ed4..5fbfdd6af75 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -136,8 +136,8 @@ qmail_spp_src_compile() {
qmail_base_install() {
einfo "Setting up basic directory hierarchy"
diropts -o root -g qmail -m 755
- keepdir "${QMAIL_HOME}"/{,bin,control}
- keepdir "${QMAIL_HOME}"/users
+ dodir "${QMAIL_HOME}"/{,bin}
+ keepdir "${QMAIL_HOME}"/{control,users}
diropts -o alias -g qmail -m 755
keepdir "${QMAIL_HOME}"/alias
--
2.26.2
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group
> On Fri, 13 Aug 2021, Rolf Eike Beer wrote: > Am Donnerstag, 12. August 2021, 19:39:08 CEST schrieb Michael Orlitzky: >> On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote: >> > The default owner is root:root anyway. >> >> This is only true of you don't call insopts earlier with some other >> value. I see "insopts -o root -g qmail -m 700" in there so you might >> want to double check. > Not my day. > Ok, given that there are several places that change users and groups > and the subfunctions are not always called it would be very few places > where I can remove the root:root (about 3) and be sure that everything > works. For that reason I would just keep them all and go back to the > initial patch 2. I believe the method of choice would be to execute the offending insopts/doins pair in a subshell, i.e. put a ( ) pair around them. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
Hi Michał, On Thu, 12 Aug 2021 14:53:33 +0200 Michał Górny wrote: >Hello, everyone. > >TL;DR: I'd like to propose that stabilizations are done via blockers of >security bugs instead of security bugs themselves, i.e. as any other >stabilizations. > > >Right now we're often performing security-related stabilizations via >security bugs. This has a few problems, that are: > >1. Stabilization-related activity causes unnecessary mail to the widely >subscribed security alias. That is, subscribed people get notified of >package list changes, NATTkA results, every arch doing its work. >However, in reality the security team only cares about stabilization >being started, stalled or finished -- and for that, getting the usual >'dependent bug added/closed' mail should be sufficient. > >2. NATTkA has no good way of distinguishing irrelevant security bugs >from security bugs where something went wrong (and NATTkA doesn't use >persistent state by design). The most important problem is that -- >unlike regular stablereqs -- security bugs aren't supposed to be closed >after stabilization. It can't really distinguish a security bug 'left >open' from a security bug with incorrect package list. > >3. Proxied maintainers without editbugs can't actually CC arches on >security bugs since the bugs are assigned to security@. > > >To resolve these problems going forward and establish consistent >behavior in the future, I'd like to propose to disable 'package list' >fields on security bugs and instead expect regular stabilization bugs >to be used (and made block the security bugs) for stabilizations. >While I understand that filing additional bugs might be cumbersome for >some people, I don't think it's such a herculean effort to outweigh >the problems solved. Indeed, filing stablereq bugs is not really that big of a deal. >In the end, consistency is a good thing and we've introduced a >dedicated stabilization category to reduce the spread of stabilization >bugs all around the place. > >WDYT? > I like this proposal and fully support it. Thanks for bringing it up. Cheers -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgpd28bN2WpgH.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group
Am Freitag, 13. August 2021, 11:06:09 CEST schrieb Ulrich Mueller: > > On Fri, 13 Aug 2021, Rolf Eike Beer wrote: > > Am Donnerstag, 12. August 2021, 19:39:08 CEST schrieb Michael Orlitzky: > >> On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote: > >> > The default owner is root:root anyway. > >> > >> This is only true of you don't call insopts earlier with some other > >> value. I see "insopts -o root -g qmail -m 700" in there so you might > >> want to double check. > > > > Not my day. > > > > Ok, given that there are several places that change users and groups > > and the subfunctions are not always called it would be very few places > > where I can remove the root:root (about 3) and be sure that everything > > works. For that reason I would just keep them all and go back to the > > initial patch 2. > > I believe the method of choice would be to execute the offending > insopts/doins pair in a subshell, i.e. put a ( ) pair around them. I will just do it the other way: explicitly reset it to defaults in the 2 functions that actually set something special. signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 5/3] qmail.eclass: retire qmail_tcprules_fixup()
This has been in all ebuilds since the move of the portage tree to git, so
everyone should have already moved the files.
Signed-off-by: Rolf Eike Beer
---
eclass/qmail.eclass| 22 --
mail-mta/netqmail/netqmail-1.06-r14.ebuild | 4
mail-mta/notqmail/notqmail-1.08-r3.ebuild | 4
mail-mta/notqmail/notqmail-.ebuild | 4
4 files changed, 34 deletions(-)
diff --git a/eclass/qmail.eclass b/eclass/qmail.eclass
index c25950cc303..7f4d1f77e42 100644
--- a/eclass/qmail.eclass
+++ b/eclass/qmail.eclass
@@ -374,28 +374,6 @@ qmail_rootmail_fixup() {
chown -R alias:qmail "${ROOT}${QMAIL_HOME}"/alias/.maildir 2>/dev/null
}
-qmail_tcprules_fixup() {
- mkdir -p "${TCPRULES_DIR}"
- local POP_FILES=
- use pop3 && POP_FILES="pop3 pop3.cdb"
- for f in {smtp,qmtp,qmqp}{,.cdb} ${POP_FILES}; do
- old="/etc/tcp.${f}"
- new="${TCPRULES_DIR}/tcp.qmail-${f}"
- fail=0
- if [[ -f "${old}" && ! -f "${new}" ]]; then
- einfo "Moving ${old} to ${new}"
- cp "${old}" "${new}" || fail=1
- else
- fail=1
- fi
- if [[ "${fail}" = 1 && -f "${old}" ]]; then
- eerror "Error moving ${old} to ${new}, be sure to check
the"
- eerror "configuration! You may have already moved the
files,"
- eerror "in which case you can delete ${old}"
- fi
- done
-}
-
qmail_tcprules_build() {
for f in tcp.qmail-{smtp,qmtp,qmqp,pop3,pop3s}; do
# please note that we don't check if it exists
diff --git a/mail-mta/netqmail/netqmail-1.06-r14.ebuild
b/mail-mta/netqmail/netqmail-1.06-r14.ebuild
index aef1ed5b4dd..e1f20404872 100644
--- a/mail-mta/netqmail/netqmail-1.06-r14.ebuild
+++ b/mail-mta/netqmail/netqmail-1.06-r14.ebuild
@@ -173,10 +173,6 @@ pkg_postinst() {
elog
}
-pkg_preinst() {
- qmail_tcprules_fixup
-}
-
pkg_config() {
# avoid some weird locale problems
export LC_ALL=C
diff --git a/mail-mta/notqmail/notqmail-1.08-r3.ebuild
b/mail-mta/notqmail/notqmail-1.08-r3.ebuild
index 382f241e719..6afc55ac3bd 100644
--- a/mail-mta/notqmail/notqmail-1.08-r3.ebuild
+++ b/mail-mta/notqmail/notqmail-1.08-r3.ebuild
@@ -173,10 +173,6 @@ pkg_postinst() {
elog
}
-pkg_preinst() {
- qmail_tcprules_fixup
-}
-
pkg_config() {
# avoid some weird locale problems
export LC_ALL=C
diff --git a/mail-mta/notqmail/notqmail-.ebuild
b/mail-mta/notqmail/notqmail-.ebuild
index 8673f74908f..224aaed0628 100644
--- a/mail-mta/notqmail/notqmail-.ebuild
+++ b/mail-mta/notqmail/notqmail-.ebuild
@@ -168,10 +168,6 @@ pkg_postinst() {
elog
}
-pkg_preinst() {
- qmail_tcprules_fixup
-}
-
pkg_config() {
# avoid some weird locale problems
export LC_ALL=C
--
2.26.2
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
On Mon, 2021-08-09 at 19:50 +0200, Thomas Deutschmann wrote:
> On 2021-08-08 13:17, David Seifert wrote:
> > So you've created a big commotion... because you didn't get the
> > initial
> > point? Honestly, this seems to be a recurring theme at this point.
> > Someone suggests some improved check/some change, and nowadays you
> > can
> > bet 50 quid that Whissi will pop up and bikeshed it in some way.
>
> No?
>
> First of all, just because you disagree with something or believe a
> discussion is wrong and or not necessary and start to frame it as
> bikeshedding, it doesn't actually become bikeshedding. This is a very
> sad and transparent attempt to silence people through defamation.
>
> The draft contains an error. It's saying that "/etc/tmpfiles.d" became
> deprecated which is not true. Because this would imply that it was
> previously acceptable for packages in Gentoo repository to install to
> that location which is not correct. If a packages in ::gentoo
> installed
> to /etc/tmpfiles.d before, this was already wrong.
>
> And my point was and still is, that neither the commit message nor the
> eqawarn should use the wording "deprecated" because nothing has
> changed
> -- no location became deprecated.
>
> And this will also address parts of antarus' previous mail: Because
> this
> QA check should be only about ::gentoo repository, this shouldn't
> affect
> any other repository. I.e. in your own overlay, you are free to do
> whatever you want and can't be forced to stick to Gentoo QA rules.
>
>
> > It's become a real problem at this point. In fact, we have proxy
> > maintainers publicly refusing to work on packages somehow involving
> > you
> > (I'll mention no names, but check the #-desktop backlog), because
> > your
> > personality boils down to three attributes nowadays:
>
> I am not in that channel and never was. If you make such an
> allegation,
> include facts so that I can respond. If you look at my complete
> history
> at GitHub issues you will find that most people I worked with
> appreciated to work with me. Of course there are some bugs/PRs where I
> rejected a requested change but I am not sure what your point is. This
> is normal because not every PR is valid.
#gentoo-desktop:
[00:00:00] - {Day changed to Friday, 6 August 2021}
[...]
[13:32:33] soap: we went over this last week, 1. I'm not
making any more PRs where I do not receive the recognition I deserve and
2. working with Whissi is probably impossible ;(
[...]
[13:34:50] I'm not sure how well it got through since he
didn't seem to respond to my concerns but I could also tell that he
really has an authoritative decision making style
Timestamps so you can verify it with a third-party. This is a public
statement, I will not share statements by people who have confided in
me.
> > 1. If I say the sky is blue, you'll say it's green. If I say it's
> > green,
> > you'll say it's blue. I've had at least 5 people tell me they see
> > the
> > exact same pattern in you (and no, mgorny is not part of that set,
> > before you throw that point at me). You're the textbook contrarian
> > of
> > Gentoo ("Wutbürger") right now.
> > 2. You'll tell people they are wrong, they aren't following
> > protocols,
> > they made a mistake, but you will never follow through with actually
> > telling people what/why or how. By the time people ask you "why?",
> > you've already disappeared. Given how frequently this happens in
> > multiple channels, projects and at different time points,
> > statistically,
> > this can't be explained by coincidence any more. This happens
> > practically on a daily basis, so you're not getting the benefit of
> > the
> > doubt any more.
> > 3. You can't let go. The security elections disaster right now is
> > the
> > prime example (yes, it's public, just check the history of the
> > Security
> > Project). This captures you so well: it's all about **community**
> > and
> > stuff, until you lose, then you start invoking technicalities and
> > procedural shenanigans to justify some ludicrous kind of "co-lead"
> > crap.
> > Frankly, it's embarrassing, and you're at the centre of it. Instead
> > of
> > accepting defeat (remember, community and democracy!), you just
> > fudge
> > the results.
>
> Interesting. You don't even now my view on this but you already have
> an
> opinion and are saying that I am the culprit. I think this is called
> "prejudiced".
To this day, we're still waiting for your view/statement/rebuttal of the
points, but have yet to receive anything.
> I am pretty sure that as a ComRel member you will abstain
> from this case as you seem to be superior. I mean you are publicly
> attacking me for 10+ months, rejected any attempt from my side when I
> tried to speak with you to get things sorted and now you showed how
> biased your are...
The last message I received from you was on 10 Jul. I have sent 3
follow-up messages before Monday, 12 Jul (when the Bernd low hit
Germany). Since then, not
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60tmpfiles-path QA check
> On Fri, 13 Aug 2021, David Seifert wrote: > On Mon, 2021-08-09 at 19:50 +0200, Thomas Deutschmann wrote: >> Interesting. You don't even now my view on this but you already have >> an opinion and are saying that I am the culprit. I think this is >> called "prejudiced". > To this day, we're still waiting for your view/statement/rebuttal of the > points, but have yet to receive anything. >> I am pretty sure that as a ComRel member you will abstain >> from this case as you seem to be superior. I mean you are publicly >> attacking me for 10+ months, rejected any attempt from my side when I >> tried to speak with you to get things sorted and now you showed how >> biased your are... > The last message I received from you was on 10 Jul. I have sent 3 > follow-up messages before Monday, 12 Jul (when the Bernd low hit > Germany). Since then, nothing. And before you invoke the Bernd argument: > I'm also a first responder, and while the high Rhine wasn't nearly as > badly affected as the middle Rhine/Eifel area in terms of floodings, I > understand that you might not have had the time to respond (even though > you pushed 19 commits to ::gentoo on 13 Jul). That said, "let me check > whether soap wrote something in PM" seems to have never occurred since > 12 Jul at any point, which raises doubts as to whether this is such a > critical issue after all... Can you please take this discussion private? gentoo-dev is a technical mailing list, and while [1] still qualifies as on-topic (IMHO), the three messages following it in this sub-thread are off-topic here. Ulrich [1] https://archives.gentoo.org/gentoo-dev/message/565efeab6f253c402212fd8d8aa58945 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
Hi, >> It would be nice to be able to resolve the security@-assigned but >> before non-security-supported architectures are handled. >> >> To do that, I think we'd want to change what's required for the "clean >> up" step. Since today the "clean up" step is dropping the vulnerable >> package versions from the tree, it is dependent on >> non-security-supported architectures completing the stabilization bug. >> I think we'd like to break that dependence. >> >> I suggest that we redefine the "clean up" step to be: drop >> security-supported architectures' keywords from vulnerable versions. >> That would allow the security@-assigned bug to be resolved before >> non-security-supported architectures are finished with stabilization. >> > To be honest, this sounds like doubling the effort for little benefit. > After all, removing the old version of the package doesn't resolve any > problems on the end user systems -- upgrading does, and upgrading > usually happens entirely independently of whether we've cleaned up or > not. > > Maybe it'd easier to release GLSAs before cleanup happens? We can > always go the dekeywording way if arch teams are actually slacking. > I agree with both of you. In particular, cleaning old versions should not be a requirement for releasing the GLSA. The faster the GLSA can get out the better. Removing the keywords is a novel idea, but honestly not sure it's worth the effort. Kind Regards, Jaco
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On Thu, Aug 12, 2021 at 01:17:32PM -0700, Matt Turner wrote: > On Thu, Aug 12, 2021 at 5:53 AM Michał Górny wrote: > > > To do that, I think we'd want to change what's required for the "clean > up" step. Since today the "clean up" step is dropping the vulnerable > package versions from the tree, it is dependent on > non-security-supported architectures completing the stabilization bug. > I think we'd like to break that dependence. > Yes, please. Thank you for bringing this up. This has been a hotly debated item in the past with former security leads dictating that "clean up" is not relevant to the security process, but it remained codified in documentation that it needs to occur. It is indeed important, as leaving vulnerable versions is the tree is not good for anyone and impacts many other areas (e.g. promoting tree cleanliness). Further, as mgorny mentioned in a follow-up email to this, we need to understand what is a "security supported" architecture. This has also been an issue in the past with council intervention needed to declare dropping specific arches to exp profiles and allowing security to drop support and subsequently move bugs forward. And to continue on my soap box, we have a small blurb on the security page [1] which states what architectures are considered security supported. This is less than ideal. We also generally state that stable arches are supported and must be dealt with during the vulnerability process. So, all in all, it is highly conflated IMHO and is *not* ideal for anyone to have to determine that a particular arch is stable but not security supported. As such, I advocate for any stable arch to be security supported by default. If the arch lags or is dropped then it goes to unstable (process TBD). [1]: https://www.gentoo.org/support/security/vulnerability-treatment-policy.html -Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-benchmarks/acovea and deps
# David Seifert (2021-08-13) # Dead upstream, new "forked" upstream that just added the last version # on Github but doesn't maintain them. Unmaintained for the past 10 # years in ::gentoo, no other real distros package these anymore. # HOMEPAGE leads to some scammy site. # Bug #318143, #62, #626668, Removal in ~30 days. dev-libs/libbrahe dev-libs/libcoyotl dev-libs/libevocosm app-benchmarks/acovea app-benchmarks/acovea-gtk signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs
On Fri, 2021-08-13 at 12:50 -0400, Aaron Bauman wrote: > On Thu, Aug 12, 2021 at 01:17:32PM -0700, Matt Turner wrote: > > On Thu, Aug 12, 2021 at 5:53 AM Michał Górny wrote: > > > > > > > > To do that, I think we'd want to change what's required for the "clean > > up" step. Since today the "clean up" step is dropping the vulnerable > > package versions from the tree, it is dependent on > > non-security-supported architectures completing the stabilization bug. > > I think we'd like to break that dependence. > > > > Yes, please. Thank you for bringing this up. This has been a hotly > debated item in the past with former security leads dictating that > "clean up" is not relevant to the security process, but it remained > codified in documentation that it needs to occur. > > It is indeed important, as leaving vulnerable versions is the tree is not > good for anyone and impacts many other areas (e.g. promoting tree > cleanliness). > > Further, as mgorny mentioned in a follow-up email to this, we need to > understand what is a "security supported" architecture. This has also > been an issue in the past with council intervention needed to declare > dropping specific arches to exp profiles and allowing security to drop > support and subsequently move bugs forward. > > And to continue on my soap box, we have a small blurb on the security > page [1] which states what architectures are considered security supported. > This is less than ideal. We also generally state that stable arches are > supported and must be dealt with during the vulnerability process. > > So, all in all, it is highly conflated IMHO and is *not* ideal for > anyone to have to determine that a particular arch is stable but not > security supported. > > As such, I advocate for any stable arch to be security supported by > default. If the arch lags or is dropped then it goes to unstable > (process TBD). > Yes, this sounds like a good idea. We should avoid having multiple classifications for architectures. If something's good enough to be stable, it should be security supported. If it's not, then it shouldn't be stable. In the end, I guess the primary problem is manpower. Given that secbugs are normally given priority, I don't really see a case for an arch that would be not good enough to be security supported but at the same time good enough to cope with the wider range of bugs. -- Best regards, Michał Górny
