[gentoo-dev] uid/gid request for net-misc/openntpd
Per https://bugs.gentoo.org/show_bug.cgi?id=693050 openntpd is going to switch to a dedicated openntpd user/group rather than sharing the ntp user/group with net-misc/ntp. Could I please get a static uid/gid assigned for this? For now, I'm just going to hardcode them in the ebuild, and transition it to the new acct-user/acct-group mechanism at a later point. Thanks...
[gentoo-dev] [PATCH 2/2] acct-user/portage: new user (250)
Package-Manager: Portage-2.3.75_p2, Repoman-2.3.17_p44 Signed-off-by: Mike Gilbert --- acct-user/portage/metadata.xml | 7 +++ acct-user/portage/portage-0.ebuild | 12 2 files changed, 19 insertions(+) create mode 100644 acct-user/portage/metadata.xml create mode 100644 acct-user/portage/portage-0.ebuild diff --git a/acct-user/portage/metadata.xml b/acct-user/portage/metadata.xml new file mode 100644 index ..d4af1f25146b --- /dev/null +++ b/acct-user/portage/metadata.xml @@ -0,0 +1,7 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + dev-port...@gentoo.org + + diff --git a/acct-user/portage/portage-0.ebuild b/acct-user/portage/portage-0.ebuild new file mode 100644 index ..86506a289311 --- /dev/null +++ b/acct-user/portage/portage-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +ACCT_USER_ID=250 +ACCT_USER_GROUPS=( portage ) +ACCT_USER_HOME="/var/lib/portage/home" + +acct-user_add_deps -- 2.23.0
[gentoo-dev] [PATCH 1/2] acct-group/portage: new group (250)
Package-Manager: Portage-2.3.75_p2, Repoman-2.3.17_p44 Signed-off-by: Mike Gilbert --- acct-group/portage/metadata.xml | 7 +++ acct-group/portage/portage-0.ebuild | 8 2 files changed, 15 insertions(+) create mode 100644 acct-group/portage/metadata.xml create mode 100644 acct-group/portage/portage-0.ebuild diff --git a/acct-group/portage/metadata.xml b/acct-group/portage/metadata.xml new file mode 100644 index ..d4af1f25146b --- /dev/null +++ b/acct-group/portage/metadata.xml @@ -0,0 +1,7 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + dev-port...@gentoo.org + + diff --git a/acct-group/portage/portage-0.ebuild b/acct-group/portage/portage-0.ebuild new file mode 100644 index ..81c4c94fafce --- /dev/null +++ b/acct-group/portage/portage-0.ebuild @@ -0,0 +1,8 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +ACCT_GROUP_ID=250 -- 2.23.0
[gentoo-portage-dev] [PATCH 1/2] acct-group/portage: new group (250)
Package-Manager: Portage-2.3.75_p2, Repoman-2.3.17_p44 Signed-off-by: Mike Gilbert --- acct-group/portage/metadata.xml | 7 +++ acct-group/portage/portage-0.ebuild | 8 2 files changed, 15 insertions(+) create mode 100644 acct-group/portage/metadata.xml create mode 100644 acct-group/portage/portage-0.ebuild diff --git a/acct-group/portage/metadata.xml b/acct-group/portage/metadata.xml new file mode 100644 index ..d4af1f25146b --- /dev/null +++ b/acct-group/portage/metadata.xml @@ -0,0 +1,7 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + dev-port...@gentoo.org + + diff --git a/acct-group/portage/portage-0.ebuild b/acct-group/portage/portage-0.ebuild new file mode 100644 index ..81c4c94fafce --- /dev/null +++ b/acct-group/portage/portage-0.ebuild @@ -0,0 +1,8 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +ACCT_GROUP_ID=250 -- 2.23.0
[gentoo-portage-dev] [PATCH 2/2] acct-user/portage: new user (250)
Package-Manager: Portage-2.3.75_p2, Repoman-2.3.17_p44 Signed-off-by: Mike Gilbert --- acct-user/portage/metadata.xml | 7 +++ acct-user/portage/portage-0.ebuild | 12 2 files changed, 19 insertions(+) create mode 100644 acct-user/portage/metadata.xml create mode 100644 acct-user/portage/portage-0.ebuild diff --git a/acct-user/portage/metadata.xml b/acct-user/portage/metadata.xml new file mode 100644 index ..d4af1f25146b --- /dev/null +++ b/acct-user/portage/metadata.xml @@ -0,0 +1,7 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + dev-port...@gentoo.org + + diff --git a/acct-user/portage/portage-0.ebuild b/acct-user/portage/portage-0.ebuild new file mode 100644 index ..86506a289311 --- /dev/null +++ b/acct-user/portage/portage-0.ebuild @@ -0,0 +1,12 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +ACCT_USER_ID=250 +ACCT_USER_GROUPS=( portage ) +ACCT_USER_HOME="/var/lib/portage/home" + +acct-user_add_deps -- 2.23.0
[gentoo-dev] Packages up for grabs: net-firewall/ufw and more
Hi all, These are the packages that i proxy-maintaining for a while. Becuse of retirement i cannot maintain them any more. UFW is the important one and just stabilized & no-bugs. I hope someone else take care UFW at least. That was a great experience for me and thanks to everybody who helped me on IRC. net-firewall/ufw net-dns/dnsviz dev-db/mysqltuner net-analyzer/synscan net-analyzer/openvas net-analyzer/openvas-libraries net-analyzer/openvas-scanner net-analyzer/openvas-manager net-analyzer/greenbone-security-assistant net-analyzer/ospd net-analyzer/gvm-tools -- Best ~Hasan
[gentoo-dev] Re: Home directory for the 'portage' user
On Mon, Sep 2, 2019 at 1:04 PM Mike Gilbert wrote: > > I would like to create an acct-user package for the 'portage' user, > but I'm having trouble deciding on a home directory. > > baselayout currently sets it to /var/tmp/portage, and this just seems > like a bad idea to me. I'm pretty sure we have a QA policy against > installing files there anyway. > > If we set the home directory to /dev/null, this may cause problems for > unit tests that expect the account to have a valid home directory. For > example, see this bug report for app-shells/ksh, which is about a test > case that fails when the HOME environment variable is unset. It also > fails if the home directory is not a directory (/dev/null). > > https://github.com/att/ast/issues/1391 > > /x/portage/app-shells/ksh-2020.0.0_beta1/work/ksh-2020.0.0_beta1-build/src/cmd/ksh93/ksh[5]: > cd: /dev/null: [Not a directory] > builtins[494]: cd with no arguments fails if HOME is unset > builtins[-1]: error_count = 1 > > So, I guess we should pick somewhere to create an empty directory for > portage. Any suggestions? /var/lib/portage/home was suggested in IRC. If there are any objections to that path, please make them known.
[gentoo-portage-dev] Re: Home directory for the 'portage' user
On Mon, Sep 2, 2019 at 1:04 PM Mike Gilbert wrote: > > I would like to create an acct-user package for the 'portage' user, > but I'm having trouble deciding on a home directory. > > baselayout currently sets it to /var/tmp/portage, and this just seems > like a bad idea to me. I'm pretty sure we have a QA policy against > installing files there anyway. > > If we set the home directory to /dev/null, this may cause problems for > unit tests that expect the account to have a valid home directory. For > example, see this bug report for app-shells/ksh, which is about a test > case that fails when the HOME environment variable is unset. It also > fails if the home directory is not a directory (/dev/null). > > https://github.com/att/ast/issues/1391 > > /x/portage/app-shells/ksh-2020.0.0_beta1/work/ksh-2020.0.0_beta1-build/src/cmd/ksh93/ksh[5]: > cd: /dev/null: [Not a directory] > builtins[494]: cd with no arguments fails if HOME is unset > builtins[-1]: error_count = 1 > > So, I guess we should pick somewhere to create an empty directory for > portage. Any suggestions? /var/lib/portage/home was suggested in IRC. If there are any objections to that path, please make them known.
Re: [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: GLEP 81 user data guidelines.
On 9/2/19 12:32 PM, Mike Gilbert wrote: > > I can't really agree with the advice given in this section. > > If I'm maintaining a package and an associated acct-user package, I'm > going to keep the two in sync. I don't see why I should have to create > a directory via pkg_postinst when I could allow the acct-user package > to do it for me. > > That the data is "non-local" is irrelevant if I'm maintaining both ebuilds. > We already have similar policies for other sorts of dependencies. If your package links to libfoo, then libfoo goes in RDEPEND even if it would be pulled in by some other dependency that you maintain. Developers retire and packages change hands all the time -- having an implicit dependency is asking for trouble, especially considering that the explicit approach isn't much more onerous: it's one extra line. To the next guy, the dependency won't be implicit, it will be nonexistent. Whether you find this reasoning persuasive or not, there is at least some precedent for it. In the acct-user case, both methods will result in the directory being keepdir'd. But ultimately, the point I'm trying to make in the patch is that one method will always work while the other might not if something outside of your control changes. Neither is more difficult, so why not choose the way that always works, and set up the directory in the ebuild that uses it? User packages can be shared and home directories can change by the design of GLEP81. You can't guarantee that no one else is going to depend on your acct-user package, or that its home directory will never have to change, or that you will maintain both of them forever. In any of those situations, having the directory creation be a side effect of enewuser is a bad idea. Why should my package create your package's localstatedir just because I want to share a username? And why should I have to violate the principle of least privilege, giving my user a home directory it doesn't need? Yeah, we could address those problems when they arise; but if they can be avoided entirely by an extra call or two to fowners/fperms, I think it's worth doing so. Or at least worth *suggesting* that we do so. If any of this is more persuasive than the original, I can update the patch. If not, I can, uh, try harder.
Re: [gentoo-dev] Home directory for the 'portage' user
On Mon, Sep 2, 2019 at 10:05 AM Mike Gilbert wrote: > > I would like to create an acct-user package for the 'portage' user, > but I'm having trouble deciding on a home directory. > > baselayout currently sets it to /var/tmp/portage, and this just seems > like a bad idea to me. I'm pretty sure we have a QA policy against > installing files there anyway. Agreed. Many people would like to put /var/tmp/portage on tmpfs. If the portage user needs any persistent configuration (like an ssh key) putting its home on tmpfs would be difficult.
[gentoo-dev] Home directory for the 'portage' user
I would like to create an acct-user package for the 'portage' user, but I'm having trouble deciding on a home directory. baselayout currently sets it to /var/tmp/portage, and this just seems like a bad idea to me. I'm pretty sure we have a QA policy against installing files there anyway. If we set the home directory to /dev/null, this may cause problems for unit tests that expect the account to have a valid home directory. For example, see this bug report for app-shells/ksh, which is about a test case that fails when the HOME environment variable is unset. It also fails if the home directory is not a directory (/dev/null). https://github.com/att/ast/issues/1391 /x/portage/app-shells/ksh-2020.0.0_beta1/work/ksh-2020.0.0_beta1-build/src/cmd/ksh93/ksh[5]: cd: /dev/null: [Not a directory] builtins[494]: cd with no arguments fails if HOME is unset builtins[-1]: error_count = 1 So, I guess we should pick somewhere to create an empty directory for portage. Any suggestions?
[gentoo-portage-dev] Home directory for the 'portage' user
I would like to create an acct-user package for the 'portage' user, but I'm having trouble deciding on a home directory. baselayout currently sets it to /var/tmp/portage, and this just seems like a bad idea to me. I'm pretty sure we have a QA policy against installing files there anyway. If we set the home directory to /dev/null, this may cause problems for unit tests that expect the account to have a valid home directory. For example, see this bug report for app-shells/ksh, which is about a test case that fails when the HOME environment variable is unset. It also fails if the home directory is not a directory (/dev/null). https://github.com/att/ast/issues/1391 /x/portage/app-shells/ksh-2020.0.0_beta1/work/ksh-2020.0.0_beta1-build/src/cmd/ksh93/ksh[5]: cd: /dev/null: [Not a directory] builtins[494]: cd with no arguments fails if HOME is unset builtins[-1]: error_count = 1 So, I guess we should pick somewhere to create an empty directory for portage. Any suggestions?
Re: [gentoo-dev] [PATCH 1/1] ebuild-writing/users-and-groups: GLEP 81 user data guidelines.
On Sun, Sep 1, 2019 at 1:48 PM Michael Orlitzky wrote: > + > + Choosing a home directory > + > + > + In most cases, the default home directory (that is, no home > + directory) should be used. GLEP81 changed two aspects of user > + management with respect to home directories: > + > + > + > + > + Creating a user can now modify the permissions on an existing > + directory. Should the need arise, this is necessary for a new > + version of an acct-user package to be able to fix the > + ownership and permissions of its home directory. > + > + > + All user data aside from the username became non-local to > + ebuilds that depend on that user. This is merely a side-effect > + of moving the user creation out of the client package, and > + into a separate acct-user package. > + > + > + > + > + The first item means that you should be conservative when > + choosing a home directory. If at all possible, avoid choosing a > + home directory that is used by another package. In particular, > + no two acct-user packages should use the same home > + directory. At best, the ownership and permissions on a shared > + home directory would need to be kept synchronized between all > + packages that share it. At worst, one package goes out-of-sync > + and introduces a security hole for the others who no longer have > + the expected permissions. > + > + > + > + The second item means that if your package requires a user, you > + can no longer be sure of that user's home directory or its > + ownership and permissions. If your package requires a directory > + to be owned and writable by some user, then your package's > + ebuild should create that directory and ensure that it is > + writable by the user. In other words, you should not rely on the > + directory being created "transitively" by a dependency, even if > + that dependency is an acct-user package. > + I can't really agree with the advice given in this section. If I'm maintaining a package and an associated acct-user package, I'm going to keep the two in sync. I don't see why I should have to create a directory via pkg_postinst when I could allow the acct-user package to do it for me. That the data is "non-local" is irrelevant if I'm maintaining both ebuilds.
[gentoo-dev] Last rites: dev-cpp/gnome-vfsmm, gnome-extra/assogiate
# Michał Górny (2019-09-02) # gnome-vfs was deprecated along with GNOME 2.22 in favor of gvfs. # gnome-vfsmm provides C bindings for it, with last release in 2009 # and only one reverse dependency. # # assogiate is the last revdep of gnome-vfsmm. It was last bumped # in 2007, and the homepage is long gone (last seen ~2009). # # Removal in 30 days. Bug #649000. dev-cpp/gnome-vfsmm gnome-extra/assogiate -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] bzr.eclass: Respect the EVCS_UMASK variable.
Bug: https://bugs.gentoo.org/497798
Signed-off-by: Ulrich Müller
---
eclass/bzr.eclass | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/eclass/bzr.eclass b/eclass/bzr.eclass
index 10bd6bc7e5a..598a0f87fe6 100644
--- a/eclass/bzr.eclass
+++ b/eclass/bzr.eclass
@@ -140,6 +140,17 @@ EXPORT_FUNCTIONS src_unpack
# by users.
: ${EBZR_OFFLINE=${EVCS_OFFLINE}}
+# @ECLASS-VARIABLE: EVCS_UMASK
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Set this variable to a custom umask. This is intended to be set by
+# users. By setting this to something like 002, it can make life easier
+# for people who do development as non-root (but are in the portage
+# group), and then switch over to building with FEATURES=userpriv.
+# Or vice-versa. Shouldn't be a security issue here as anyone who has
+# portage group write access already can screw the system over in more
+# creative ways.
+
# @ECLASS-VARIABLE: EBZR_WORKDIR_CHECKOUT
# @DEFAULT_UNSET
# @DESCRIPTION:
@@ -197,7 +208,7 @@ bzr_update() {
# working copy.
bzr_fetch() {
local repo_dir branch_dir
- local save_sandbox_write=${SANDBOX_WRITE}
+ local save_sandbox_write=${SANDBOX_WRITE} save_umask
[[ -n ${EBZR_REPO_URI} ]] || die "${EBZR}: EBZR_REPO_URI is empty"
@@ -214,6 +225,10 @@ bzr_fetch() {
repo_dir=${EBZR_STORE_DIR}/${EBZR_PROJECT}
branch_dir=${repo_dir}${EBZR_BRANCH:+/${EBZR_BRANCH}}
+ if [[ -n ${EVCS_UMASK} ]]; then
+ save_umask=$(umask)
+ umask "${EVCS_UMASK}" || die
+ fi
addwrite "${EBZR_STORE_DIR}"
if [[ ! -d ${branch_dir}/.bzr ]]; then
@@ -240,8 +255,11 @@ bzr_fetch() {
bzr_update "${EBZR_REPO_URI}" "${branch_dir}"
fi
- # Restore sandbox environment
+ # Restore sandbox environment and umask
SANDBOX_WRITE=${save_sandbox_write}
+ if [[ -n ${save_umask} ]]; then
+ umask "${save_umask}" || die
+ fi
cd "${branch_dir}" || die "${EBZR}: can't chdir to ${branch_dir}"
--
2.23.0
signature.asc
Description: PGP signature
[gentoo-dev] Package up for grabs: app-admin/installer
Hi, The maintainer of the following package is retiring: app-admin/installer There are no bugs open. Chris, if you'd still like to maintain it via proxy-maint, please create a new Bugzilla account and give me its' e-mail address. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
