[gentoo-portage-dev] [PATCH] LocationsManager: map empty root var to / (bug 663904)
When ROOT or PORTAGE_CONFIGROOT is entirely empty, map
the value to / since otherwise is becomes the current
working directory which gives undesirable results.
Bug: https://bugs.gentoo.org/663904
---
lib/portage/package/ebuild/_config/LocationsManager.py | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/portage/package/ebuild/_config/LocationsManager.py
b/lib/portage/package/ebuild/_config/LocationsManager.py
index f7d7209ff..b8a4ccdd0 100644
--- a/lib/portage/package/ebuild/_config/LocationsManager.py
+++ b/lib/portage/package/ebuild/_config/LocationsManager.py
@@ -60,7 +60,7 @@ class LocationsManager(object):
self.config_root = portage.const.EPREFIX + os.sep
self.config_root = normalize_path(os.path.abspath(
- self.config_root)).rstrip(os.path.sep) + os.path.sep
+ self.config_root or os.sep)).rstrip(os.path.sep) +
os.path.sep
self._check_var_directory("PORTAGE_CONFIGROOT",
self.config_root)
self.abs_user_config = os.path.join(self.config_root,
USER_CONFIG_PATH)
@@ -304,8 +304,7 @@ class LocationsManager(object):
self.target_root = root_overwrite
if not self.target_root.strip():
self.target_root = None
- if self.target_root is None:
- self.target_root = "/"
+ self.target_root = self.target_root or os.sep
self.target_root = normalize_path(os.path.abspath(
self.target_root)).rstrip(os.path.sep) + os.path.sep
--
2.16.4
[gentoo-portage-dev] [PATCH] config: default features USE for conditional RESTRICT (bug 663848)
Initialize default features USE state, and reset when appropriate,
so that the "test" flag state is correct for evaluation of !test?
conditionals in RESTRICT.
Fixes: 45986341a80c ("Support !test? conditionals in RESTRICT (bug 663278)")
---
lib/portage/package/ebuild/config.py | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/lib/portage/package/ebuild/config.py
b/lib/portage/package/ebuild/config.py
index 3b01095d0..9fbf7e8fc 100644
--- a/lib/portage/package/ebuild/config.py
+++ b/lib/portage/package/ebuild/config.py
@@ -259,6 +259,7 @@ class config(object):
self.packages = clone.packages
self.repositories = clone.repositories
self.unpack_dependencies = clone.unpack_dependencies
+ self._default_features_use = clone._default_features_use
self._iuse_effective = clone._iuse_effective
self._iuse_implicit_match = clone._iuse_implicit_match
self._non_user_variables = clone._non_user_variables
@@ -961,6 +962,14 @@ class config(object):
# initialize self.features
self.regenerate()
+ feature_use = []
+ if "test" in self.features:
+ feature_use.append("test")
+ self.configdict["features"]["USE"] =
self._default_features_use = " ".join(feature_use)
+ if feature_use:
+ # Regenerate USE so that the initial "test"
flag state is
+ # correct for evaluation of !test? conditionals
in RESTRICT.
+ self.regenerate()
if unprivileged:
self.features.add('unprivileged')
@@ -1296,7 +1305,7 @@ class config(object):
del self._penv[:]
self.configdict["pkg"].clear()
self.configdict["pkginternal"].clear()
- self.configdict["features"].clear()
+ self.configdict["features"]["USE"] =
self._default_features_use
self.configdict["repo"].clear()
self.configdict["defaults"]["USE"] = \
" ".join(self.make_defaults_use)
@@ -1598,7 +1607,7 @@ class config(object):
has_changed = True
# Prevent stale features USE from corrupting the
evaluation
# of USE conditional RESTRICT.
- self.configdict["features"]["USE"] = ""
+ self.configdict["features"]["USE"] =
self._default_features_use
self._penv = []
cpdict = self._penvdict.get(cp)
--
2.16.4
Re: [gentoo-dev] autotools.eclass and EAPI 7
Ühel kenal päeval, R, 17.08.2018 kell 15:15, kirjutas Alexis Ballier: > On Thu, 16 Aug 2018 21:36:56 +0300 > Mart Raudsepp wrote: > > > Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans: > > > There are currently a handful of ebuilds using EAPI 7 and the > > > autotools > > > eclass. > > > > > > I believe that this eclass should be reviewed for adding BDEPEND > > > or > > > having BDEPEND replace the DEPEND statement as the default action > > > of > > > the > > > eclass. > > > > > > Other items might be needed, but that's doubtful. > > > > > > Someone please advise the best course of action and either do it > > > or > > > I will propose a patch based on the discussion. > > > > > > > Could or did someone also check through all the other eclasses that > > don't have any global EAPI compatibility checks? > > For the future, maybe it's better to add such a check - just > > accepting > > 0-7 or so, but unsure about all these custom EAPIs out there, might > > force more eclass copying to some overlays. > > I don't really like that kind of checks: untested after usually small > changes != broken. > > IMHO a better solution could be to have council members review all > eclasses prior to approving an eapi and either adding a comment why + > a > die when used with the not-yet-approved-eapi if the eclass requires > changes or do nothing about it if it's fine. This has the double > advantage to give council members first hands experience with an eapi > before approving/voting it and ensures better migration when eapi is > approved. I think that's a good idea, in some form, but that ship has sailed with EAPI-7 now and the request remains. I'll try to remember this for a future EAPI-8 in the future. I'd be glad to review things now, if I had time, but frankly I have much more important things on my plate right now (like getting other things to the point I can review and merge EAPI-7 support to some of the eclasses I maintain and unblock progress for more usage of it). Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] autotools.eclass and EAPI 7
On Thu, 16 Aug 2018 21:36:56 +0300 Mart Raudsepp wrote: > Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans: > > There are currently a handful of ebuilds using EAPI 7 and the > > autotools > > eclass. > > > > I believe that this eclass should be reviewed for adding BDEPEND or > > having BDEPEND replace the DEPEND statement as the default action of > > the > > eclass. > > > > Other items might be needed, but that's doubtful. > > > > Someone please advise the best course of action and either do it or > > I will propose a patch based on the discussion. > > > > Could or did someone also check through all the other eclasses that > don't have any global EAPI compatibility checks? > For the future, maybe it's better to add such a check - just accepting > 0-7 or so, but unsure about all these custom EAPIs out there, might > force more eclass copying to some overlays. I don't really like that kind of checks: untested after usually small changes != broken. IMHO a better solution could be to have council members review all eclasses prior to approving an eapi and either adding a comment why + a die when used with the not-yet-approved-eapi if the eclass requires changes or do nothing about it if it's fine. This has the double advantage to give council members first hands experience with an eapi before approving/voting it and ensures better migration when eapi is approved.
Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part
On Sat, 2018-08-04 at 16:57 +0200, Thomas Deutschmann wrote: > On 2018-08-04 14:34, Ulrich Mueller wrote: > > So this should either have been submitted as part of that update, or > > you should at least have given notice to the council that further > > changes are pending (as you were present during the meeting). In the > > latter case, we may likely have postponed the decision about the GLEP > > update, which wasn't entirely uncontroversial. > > I agree but nevertheless I appreciate that someone (Michał in this case) > doesn't rest and continue to improve things. > > > Michał Górny wrote: > > +Furthermore, the specification requires separate subkeys for different > > +purposes. This is a generally agreed on practice (e.g. GnuPG defaults to > > +using a separate encryption key) aiming to further reduce the attack > > surface. > > +Kristian Fiskerstrand points out e.g. it is technically possible to obtain > > +a valid signature over crafted data while using the subkey for purposes > > +of authorization [#COUNCIL-MEETING-20180729]_. > > I challenge this one: > > If an attacker is already able to trick a developer into signing > something the developer didn't want to sign, the same attacker will also > be able to trick the same developer into using the right sub key the > attacker is actually interested in. > > My point is: While I don't disagree that best practice should be an own > sub key for every purpose, arguing that this has an impact on security > is wrong. And that was and still is my reason why I don't want that this > is getting enforced. I defer this to Kristian. He knows the GnuPG internals much better than I do. > Michał Górny wrote: > > +This policy serves two purposes. Firstly, it provides a last fallback > > option > > +in the event of access to the secret keys being lost and there being > > +no possibility of revoking them. In this case, the keys eventually expire > > +and users can clearly see that they are no longer being used. Secondly, it > > +ensures that the developers periodically confirm their access to the > > primary > > +key. > > And I am also challenging this one: > > Given that this a policy for Gentoo, we have to take Gentoo specifics > into account: > > In Gentoo the primary purpose of OpenGPG is to sign commits and push > operations. A git hook ensures that each commit and push is well signed > by a known key. However, this key is coming from Gentoo's LDAP. LDAP is > accessed via SSH key. So anyone with access to a developer's SSH key is > able to add an additional (malicious) key which would be picked up by > other automated processes with the result that whoever is in control of > that additional key could now use it to commit and push to any Gentoo > repositories. > > In this process, an expiration date isn't really used. Again, it is best > practice but when we don't use it, why do we care and enforce such a value? > > Well, if you take the *now* proposed "Foreword" into account I *could* > arrange with such a statement because expiration date plays a role in > the web of trust and GLEP 63 seems to be more than just a OpenGPG policy > for commit/push. Most of the developers are always signing their mails using their OpenPGP keys. In fact, mail signing preceded Manifest signing, not to mention the migration to git. Why would suddenly its purpose be reduced to just commits? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
