[gentoo-portage-dev] [PATCH 1/1] Revert "repoman: deprecate netsurf.eclass."

2020-08-14 Thread Michael Orlitzky
This reverts commit a73024729860f9224b8d1660d24c450080b67d9f. This
eclass was successfully purged from the tree, so the deprecation is no
longer needed. And eventually, to address an eblit infestation,
another eclass with the same name will return. The new one will not be
deprecated.

Signed-off-by: Michael Orlitzky 
---
 repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py 
b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
index 60410347b..5848a0c37 100644
--- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
+++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
@@ -33,7 +33,6 @@ class InheritDeprecated(LineCheck):
"gst-plugins10": "gstreamer",
"ltprune": False,
"mono": "mono-env",
-   "netsurf": False,
"python": "python-r1 / python-single-r1 / python-any-r1",
"ruby": "ruby-ng",
"user": "GLEP 81",
-- 
2.26.2




[gentoo-portage-dev] [PATCH 1/1] repoman: deprecate netsurf.eclass.

2020-06-16 Thread Michael Orlitzky
While investigating bug 489542, it became clear that the netsurf
eclass is deprecated in spirit if not in fact. All of the newer
netsurf ebuilds use a custom function loaded from a script that is
shipped in netsurf-buildsystem's $FILESDIR to do (some of) what the
eclass used to do. That function probably does belong in an eclass,
but at this point, we should throw this thing out and start from
scratch.

By deprecating the eclass, we make sure that no one else inherits it
during the time it takes to purge the two remaining consumers. Then,
once those are gone, the build system script magic can be put back
into an eclass, and its consumers updated one-at-a-time.

Bug: https://bugs.gentoo.org/489542
Bug: https://bugs.gentoo.org/637824
Signed-off-by: Michael Orlitzky 
---
 repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py 
b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
index 5848a0c37..60410347b 100644
--- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
+++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
@@ -33,6 +33,7 @@ class InheritDeprecated(LineCheck):
"gst-plugins10": "gstreamer",
"ltprune": False,
"mono": "mono-env",
+   "netsurf": False,
"python": "python-r1 / python-single-r1 / python-any-r1",
"ruby": "ruby-ng",
"user": "GLEP 81",
-- 
2.26.2




Re: [gentoo-portage-dev] [PATCH] Change BINPKG_COMPRESS default from bzip2 to xz

2020-04-26 Thread Michael Orlitzky
On 4/26/20 3:25 PM, Ulrich Mueller wrote:
>>>>>> On Sun, 26 Apr 2020, Michael Orlitzky wrote:
> 
>> Fuel for the fire:
> 
>>  * https://www.nongnu.org/lzip/lzip_benchmark.html
>>  * https://www.nongnu.org/lzip/xz_inadequate.html
> 
> Yep. That's why lzip is the dominant compression format now, and nobody
> is using xz any more.
> 

If you believed that argument, you would be using Windows =P

Dude has GRAPHS, it must be true.



Re: [gentoo-portage-dev] [PATCH] Change BINPKG_COMPRESS default from bzip2 to xz

2020-04-26 Thread Michael Orlitzky
On 4/26/20 12:55 PM, Matt Turner wrote:
> Bug: https://bugs.gentoo.org/715108
> Signed-off-by: Matt Turner 
> ---
> Strawman patch. Bikeshed away.
> 

Fuel for the fire:

 * https://www.nongnu.org/lzip/lzip_benchmark.html
 * https://www.nongnu.org/lzip/xz_inadequate.html



Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-13 Thread Michael Orlitzky
On 12/13/19 9:28 AM, Fabian Groffen wrote:
> 
> We are providing those patches, maybe.  In reality very often the
> patches originate from somewhere else though.  And you don't want to
> have to respin all of those just because.  At least that's what I feel.
> 

Just because... the context changed? A new "!" in a line of context can
be the difference between letting someone log in with the right password
and letting them log in with the wrong password. You should at least
have to stop and verify that the patch does what you think it does when
it "gains" fuzz. And at that point, git diff will give you a clean
version of it.



Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-12 Thread Michael Orlitzky
On 12/12/19 3:15 PM, Ulrich Mueller wrote:
> 
> It was also suggested that we add -F0 in EAPI 8, but that would break
> the build in those cases that are producing extra output now. I don't
> think that would be preferable.

It would only break the build for the maintainer, who would then
presumably fix the patch.



Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

2019-11-27 Thread Michael Orlitzky
On 11/27/19 2:17 PM, Michał Górny wrote:
> 
> To achieve that, attempt to apply each patch with -F0 --dry-run first.
> If this succeeds, just silently apply the patch for real.  If it
> doesn't, output an explicit eqawarn that the patch does not apply
> cleanly and retry with the default fuzz factor and verbose output.

This now disagrees with the PMS algorithm, doesn't it? Not that the
change isn't sensible otherwise.



Re: [gentoo-portage-dev] Constraint-Based Dependency Solver: initial results

2019-10-08 Thread Michael Orlitzky
On 8/30/19 10:34 AM, michael.lienha...@laposte.net wrote:
> 
> All comments/suggestions are welcomed.
> 

Since no one else has said it yet (?), I think this approach is really
cool and I'm glad someone is working on it.

Modeling difficult computations as abstract optimization problems is a
"hobby" of mine, and I think it will pay off if we can abstract away a
big ugly part of the PM and try to swap it out for something more
principled.



Re: [gentoo-portage-dev] [RFC] Adding extra vars to md5-cache, for QA purposes

2019-07-25 Thread Michael Orlitzky
On 7/25/19 4:29 PM, Michał Górny wrote:
>>
>> * In the md5-cache entry, maybe use a common prefix like EXT_ for the
>> extra keys in order to distinguish them from normal keys.
> 
> Yeah, I was thinking of something like '__ext_foo', or '__ext[foo]'.
> 

What are the pros/cons of this? The names refer to global variables, so
they should already be safely namespaced, right?.

There is a possibility that an eclass variable name (e.g. PATCHES) could
become standardized at a later date. If that happens, we could wind up
with both FOO and __ext_FOO in the cache, and tools would have to figure
out what to do with zero, one, or both present. (This has happened in
email/web protocols when an X-Foo header was standardized.) It's not the
end of the world, but someone would have to stop and think about it.

Finally, just having the name be predictable so that I can grep '^FOO='
without having to care where it came from is nice.

OTOH for testing, and for figuring out why these weird variables are
showing up in my cache, the prefix would help.




Re: [gentoo-portage-dev] [PATCH] f{owners,perms}: Warn when using relative path

2018-09-17 Thread Michael Orlitzky
On 09/17/2018 02:52 AM, Michał Górny wrote:
> 
> --- a/bin/ebuild-helpers/fowners
> +++ b/bin/ebuild-helpers/fowners
> ...
> + eqawarn "This is unsupported. Please use 'chmod' when you need 
> to work on files"

This one should be 'chown' instead of 'chmod'.

(Calling chown on the live filesystem is often also a dangerous mistake,
but this probably isn't the place to fuss about it.)



Re: [gentoo-portage-dev] [PATCH v2] install-qa-checks.d: Add a check for Gentoo path policies (FHS-y)

2018-09-04 Thread Michael Orlitzky
On 09/04/2018 01:53 PM, Michał Górny wrote:
> + # TODO: do we need it? gconf installs empty dir there but that's
> + # all
> + root

FWIW, we should not allow this.



Re: [gentoo-portage-dev] [PATCH v3 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

2018-08-07 Thread Michael Orlitzky
On 08/07/2018 01:34 PM, Zac Medico wrote:
> 
> Why not use ${ED%/} instead of ${D%/} here, so that the output is the
> same regardless of ${EPREFIX}?
> 

We want to show where the executable was actually installed, and
generally that includes EPREFIX. For example, I'd want to see

  /var/tmp/whatever/.../root/prefix/usr/bin/foo

reported as

  /root/prefix/usr/bin/foo

rather than

  /usr/bin/foo

Of course, these checks are now skipped on prefix systems anyway, so
it's a bit of a moot point. But I think it's more future-proof to strip
only the $D.



[gentoo-portage-dev] [PATCH v3 2/2] bin/install-qa-check.d: add new 90bad-bin-group-write QA check.

2018-08-07 Thread Michael Orlitzky
System executables that are writable by a non-root user pose a
security risk. Anyone who can write to an executable can change its
behavior. If that executable is later run with elevated privileges
(say, by root, when the machine starts), then the non-root user can
escalate his own privileges to those of the person running the
modified executable.

The 90bad-bin-owner check already addresses one cause for a non-root
user to be able to modify an executable: because he owns it. This
commit adds another check, to ensure that no non-root *groups* have
write access to any system executables. On a "normal" system, all
system executables should be writable only by the super-user's group,
if any. To avoid false-positives, non-"normal" systems (like prefix)
are skipped.

Closes: https://bugs.gentoo.org/629398
---
 bin/install-qa-check.d/90bad-bin-group-write | 55 
 1 file changed, 55 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-group-write

diff --git a/bin/install-qa-check.d/90bad-bin-group-write 
b/bin/install-qa-check.d/90bad-bin-group-write
new file mode 100644
index 0..786dde712
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-group-write
@@ -0,0 +1,55 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_group_write_check() {
+   # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+   # /usr/sbin, or /opt/bin) that are group-writable by a nonzero GID.
+
+   # This check doesn't work on non-root prefix installations at
+   # the moment, because every executable therein is owned by a
+   # nonzero GID.
+   [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+   local d f found=()
+
+   for d in "${ED%/}/opt/bin" "${ED%/}/bin"  "${ED%/}/usr/bin" \
+  "${ED%/}/sbin" 
"${ED%/}/usr/sbin"; do
+   [[ -d "${d}" ]] || continue
+
+   # Read the results of the "find" command into the "found" array.
+   #
+   # Use -L to catch symlinks whose targets are vulnerable,
+   # even though it won't catch ABSOLUTE symlinks until the package
+   # is RE-installed (the first time around, the target won't 
exist).
+   #
+   # We match the GID and not the name "root" here because (for
+   # example) on FreeBSD, the superuser group is "wheel".
+   #
+   # We don't make an exception for setguid executables here, 
because
+   # a group-writable setguid executable is likely a mistake. By
+   # altering the contents of the executable, a member of the group
+   # can allow everyone (i.e. the people running it) to obtain the
+   # full privileges available to that group. While only existing
+   # group members can make that choice, it's a decision usually
+   # limited to the system administrator.
+   while read -r -d '' f; do
+   found+=( "${f}" )
+   done < <(find -L "${d}"   \
+   -maxdepth 1   \
+   -type f   \
+   -perm /g+w\
+   ! -gid 0  \
+   -print0)
+   done
+
+   if [[ ${found[@]} ]]; then
+   eqawarn "system executables group-writable by nonzero gid:"
+   for f in "${found[@]}"; do
+   # Strip off the leading destdir before outputting the 
path.
+   eqawarn "  ${f#${D%/}}"
+   done
+   fi
+}
+
+bad_bin_group_write_check
+:
-- 
2.16.4




[gentoo-portage-dev] [PATCH v3 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

2018-08-07 Thread Michael Orlitzky
System executables that are not owned by root pose a security
risk. The owner of the executable is free to modify it at any time;
so, for example, he can change a daemon's behavior to make it
malicious before the next time the service is started (usually by
root).

On a "normal" system, the superuser should own every system executable
(even setuid ones, for security reasons). This commit adds a new
install-time check that reports any such binaries with a QA
warning. To avoid false positives, non-"normal" systems (like prefix)
are skipped at the moment.

Bug: https://bugs.gentoo.org/629398
---
 bin/install-qa-check.d/90bad-bin-owner | 48 ++
 1 file changed, 48 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-owner

diff --git a/bin/install-qa-check.d/90bad-bin-owner 
b/bin/install-qa-check.d/90bad-bin-owner
new file mode 100644
index 0..c3ee30746
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-owner
@@ -0,0 +1,48 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_owner_check() {
+   # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+   # /usr/sbin, or /opt/bin) that are owned by a nonzero UID.
+
+   # This check doesn't work on non-root prefix installations at
+   # the moment, because every executable therein is owned by a
+   # nonzero UID.
+   [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+   local d f found=()
+
+   for d in "${ED%/}/opt/bin" "${ED%/}/bin"  "${ED%/}/usr/bin" \
+  "${ED%/}/sbin" 
"${ED%/}/usr/sbin"; do
+   [[ -d "${d}" ]] || continue
+
+   # Read the results of the "find" command into the "found" bash 
array.
+   #
+   # Use -L to catch symlinks whose targets are owned by a 
non-root user,
+   # even though it won't catch ABSOLUTE symlinks until the package
+   # is RE-installed (the first time around, the target won't 
exist).
+   #
+   # We do want to list non-superuser setuid executables, because
+   # they can be exploited. The owner can simply wipe the setuid
+   # bit, and then alter the contents of the file. The superuser
+   # will then have a time bomb in his $PATH.
+   while read -r -d '' f; do
+   found+=( "${f}" )
+   done < <(find -L "${d}"   \
+   -maxdepth 1   \
+   -type f   \
+   ! -uid 0  \
+   -print0)
+   done
+
+   if [[ ${found[@]} ]]; then
+   eqawarn "system executables owned by nonzero uid:"
+   for f in "${found[@]}"; do
+   # Strip off the leading destdir before outputting the 
path.
+   eqawarn "  ${f#${D%/}}"
+   done
+   fi
+}
+
+bad_bin_owner_check
+:
-- 
2.16.4




[gentoo-portage-dev] [PATCH v3 0/2] Two insecure ownership and group-writability QA checks.​

2018-08-07 Thread Michael Orlitzky
Changes in v3:

  * Undo the setguid exception from v2, and add a comment explaining why.
  * Add line breaks for readability in two comments.
  * Try to put back the leading "/" in the output list.
  * Remove a superfluous comment mentioning the "prefix."

Michael Orlitzky (2):
  bin/install-qa-check.d: add new 90bad-bin-owner QA check.
  bin/install-qa-check.d: add new 90bad-bin-group-write QA check.

 bin/install-qa-check.d/90bad-bin-group-write | 55 
 bin/install-qa-check.d/90bad-bin-owner   | 48 
 2 files changed, 103 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-group-write
 create mode 100644 bin/install-qa-check.d/90bad-bin-owner

-- 
2.16.4




Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

2018-07-29 Thread Michael Orlitzky
On 07/29/2018 09:16 PM, Ulrich Mueller wrote:
> 
> Staying with the man:man example, how would anybody become the "man"
> user, in the first place? That user has /bin/false as a shell and no
> valid password.

One way would be to exploit a process that's running as the "man" user.
Ostensibly such a thing is possible; otherwise we wouldn't be dropping
privileges in the first place.

The shell/password settings for that user are also in no way guaranteed.

But on principle: who cares, non-root users shouldn't be able to gain
root =)


> Setgid executables shouldn't be group writable

Why not? I'm happy to pull that part back out.



[gentoo-portage-dev] [PATCH v2 0/2] Two insecure ownership and group-writability QA checks.

2018-07-29 Thread Michael Orlitzky
Changes in v2:

  * Also check executables in /opt/bin (mgorny).
  * Don't report group-writable executables that are setgid (ulm).
  * Add a comment on why we don't do the same for setuid.
  * Wrap long lines with backslashes.
  * Fix nesting of output loop; output should happen after all checks.

Michael Orlitzky (2):
  bin/install-qa-check.d: add new 90bad-bin-owner QA check.
  bin/install-qa-check.d: add new 90bad-bin-group-write QA check.

 bin/install-qa-check.d/90bad-bin-group-write | 49 
 bin/install-qa-check.d/90bad-bin-owner   | 47 ++
 2 files changed, 96 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-group-write
 create mode 100644 bin/install-qa-check.d/90bad-bin-owner

-- 
2.16.4




[gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

2018-07-29 Thread Michael Orlitzky
System executables that are not owned by root pose a security
risk. The owner of the executable is free to modify it at any time;
so, for example, he can change a daemon's behavior to make it
malicious before the next time the service is started (usually by
root).

On a "normal" system, there is no good reason why the superuser should
not own every system executable. This commit adds a new install-time
check that reports any such binaries with a QA warning. To avoid false
positives, non-"normal" systems (like prefix) are skipped at the moment.

Bug: https://bugs.gentoo.org/629398
---
 bin/install-qa-check.d/90bad-bin-owner | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-owner

diff --git a/bin/install-qa-check.d/90bad-bin-owner 
b/bin/install-qa-check.d/90bad-bin-owner
new file mode 100644
index 0..748e1dc99
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-owner
@@ -0,0 +1,47 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_owner_check() {
+   # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+   # /usr/sbin, or /opt/bin) that are owned by a nonzero UID.
+
+   # This check doesn't work on non-root prefix installations at
+   # the moment, because every executable therein is owned by a
+   # nonzero UID.
+   [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+   local d f found=()
+
+   for d in "${ED%/}/opt/bin" "${ED%/}/bin"  "${ED%/}/usr/bin" \
+  "${ED%/}/sbin" 
"${ED%/}/usr/sbin"; do
+   [[ -d "${d}" ]] || continue
+
+   # Read the results of the "find" command into the "found" bash 
array.
+   # Use -L to catch symlinks whose targets are owned by a 
non-root user,
+   # even though it won't catch ABSOLUTE symlinks until the package
+   # is RE-installed (the first time around, the target won't 
exist).
+   # We do want to list non-superuser setuid executables, because
+   # they can be exploited. The owner can simply wipe the setuid
+   # bit, and then alter the contents of the file. The superuser
+   # will then have a time bomb in his $PATH.
+   while read -r -d '' f; do
+   found+=( "${f}" )
+   done < <(find -L "${d}"   \
+   -maxdepth 1   \
+   -type f   \
+   ! -uid 0  \
+   -print0)
+   done
+
+   if [[ ${found[@]} ]]; then
+   eqawarn "system executables owned by nonzero uid:"
+   for f in "${found[@]}"; do
+   # Strip off the leading destdir before outputting the 
path,
+   # but leave the prefix if there is one.
+   eqawarn "  ${f#${D%/}/}"
+   done
+   fi
+}
+
+bad_bin_owner_check
+:
-- 
2.16.4




[gentoo-portage-dev] [PATCH 2/2] bin/install-qa-check.d: add new 90bad-bin-group-write QA check.

2018-07-29 Thread Michael Orlitzky
System executables that are writable by a non-root user pose a
security risk. Anyone who can write to an executable can change its
behavior. If that executable is later run with elevated privileges
(say, by root, when the machine starts), then the non-root user can
escalate his own privileges to those of the person running the
modified executable.

The 90bad-bin-owner check already addresses one cause for a non-root
user to be able to modify an executable: because he owns it. This
commit adds another check, to ensure that no non-root *groups* have
write access to any system executables. On a "normal" system, all
system executables should belong to the super-user's group. To avoid
false-positives, non-"normal" systems (like prefix) are skipped.

Closes: https://bugs.gentoo.org/629398
---
 bin/install-qa-check.d/90bad-bin-group-write | 49 
 1 file changed, 49 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-group-write

diff --git a/bin/install-qa-check.d/90bad-bin-group-write 
b/bin/install-qa-check.d/90bad-bin-group-write
new file mode 100644
index 0..3c5021e0d
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-group-write
@@ -0,0 +1,49 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_group_write_check() {
+   # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+   # /usr/sbin, or /opt/bin) that are group-writable by a nonzero GID.
+
+   # This check doesn't work on non-root prefix installations at
+   # the moment, because every executable therein is owned by a
+   # nonzero GID.
+   [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+   local d f found=()
+
+   for d in "${ED%/}/opt/bin" "${ED%/}/bin"  "${ED%/}/usr/bin" \
+  "${ED%/}/sbin" 
"${ED%/}/usr/sbin"; do
+   [[ -d "${d}" ]] || continue
+
+   # Read the results of the "find" command into the "found" bash
+   # array. Use -L to catch symlinks whose targets are vulnerable,
+   # even though it won't catch ABSOLUTE symlinks until the package
+   # is RE-installed (the first time around, the target won't 
exist).
+   # We match the GID and not the name "root" here because (for
+   # example) on FreeBSD, the superuser group is "wheel".
+   # We avoid listing setgid executables because -- even though 
they're
+   # super sketchy -- their non-root group is intentional.
+   while read -r -d '' f; do
+   found+=( "${f}" )
+   done < <(find -L "${d}"   \
+   -maxdepth 1   \
+   -type f   \
+   -perm /g+w\
+   ! -gid 0  \
+   ! -perm -2000 \
+   -print0)
+   done
+
+   if [[ ${found[@]} ]]; then
+   eqawarn "system executables group-writable by nonzero gid:"
+   for f in "${found[@]}"; do
+   # Strip off the leading destdir before outputting the 
path,
+   # but leave the prefix if there is one.
+   eqawarn "  ${f#${D%/}/}"
+   done
+   fi
+}
+
+bad_bin_group_write_check
+:
-- 
2.16.4




Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

2018-07-29 Thread Michael Orlitzky
On 07/29/2018 03:43 PM, Ulrich Mueller wrote:
> 
>> On a "normal" system, there is no good reason why the superuser should
>> not own every system executable. This commit adds a new install-time
>> check that reports any such binaries with a QA warning. To avoid false
>> positives, non-"normal" systems (like prefix) are skipped at the moment.
> 
> Shouldn't this check for setuid binaries like /usr/bin/mandb (which is
> owned by man:man)? I think these are legitimate usage case.
> 

After thinking about this for a while, I think we should ignore setgid
but not setuid executables. The problem with setuid and a non-root owner
is that the owner can always exploit the situation:

Suppose /bin/foo is owned by "foo" and setuid. If root (or any other
privileged user) is about to run /bin/foo, then the "foo" user can
simply strip away the setuid bit and fill /bin/foo with malicious code.

The same situation with setgid is safe because (as far as I know)
members of the group can't strip off the setgid bit.



Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

2018-07-29 Thread Michael Orlitzky
On 07/29/2018 03:43 PM, Ulrich Mueller wrote:
> 
> Shouldn't this check for setuid binaries like /usr/bin/mandb (which is
> owned by man:man)? I think these are legitimate usage case.
> 

In general, yeah. I think we should be skeptical of setuid/gid
executables, but this isn't the right place to make that stand.

In this specific case, though, I don't see why that program is setuid.
In fact, I'm pretty sure it lets the "man" user gain root privileges.



[gentoo-portage-dev] [PATCH 2/2] bin/install-qa-check.d: add new 90bad-bin-group-write QA check.

2018-07-29 Thread Michael Orlitzky
System executables that are writable by a non-root user pose a
security risk. Anyone who can write to an executable can change its
behavior. If that executable is later run with elevated privileges
(say, by root, when the machine starts), then the non-root user can
escalate his own privileges to those of the person running the
modified executable.

The 90bad-bin-owner check already addresses one cause for a non-root
user to be able to modify an executable: because he owns it. This
commit adds another check, to ensure that no non-root *groups* have
write access to any system executables. On a "normal" system, all
system executables should belong to the super-user's group. To avoid
false-positives, non-"normal" systems (like prefix) are skipped.

Closes: https://bugs.gentoo.org/629398
---
 bin/install-qa-check.d/90bad-bin-group-write | 40 
 1 file changed, 40 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-group-write

diff --git a/bin/install-qa-check.d/90bad-bin-group-write 
b/bin/install-qa-check.d/90bad-bin-group-write
new file mode 100644
index 0..f8a0259e5
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-group-write
@@ -0,0 +1,40 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_group_write_check() {
+   # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+   # or /usr/sbin) that are group-writable by a nonzero GID.
+
+   # This check doesn't work on non-root prefix installations at
+   # the moment, because every executable therein is owned by a
+   # nonzero GID.
+   [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+   local d f found=()
+
+   for d in "${ED%/}/bin" "${ED%/}/usr/bin" "${ED%/}/sbin" 
"${ED%/}/usr/sbin"; do
+   test -d "${d}" || continue
+
+   # Read the results of the "find" command into the "found" bash
+   # array. Use -L to catch symlinks whose targets are vulnerable,
+   # even though it won't catch ABSOLUTE symlinks until the package
+   # is RE-installed (the first time around, the target won't 
exist).
+   # We match the GID and not the name "root" here because (for
+   # example) on FreeBSD, the superuser group is "wheel".
+   while read -r -d '' f; do
+   found+=( "${f}" )
+   done < <(find -L "${d}" -maxdepth 1 -type f -perm /g+w ! -gid 0 
-print0)
+
+   if [[ ${found[@]} ]]; then
+   eqawarn "system executables group-writable by nonzero 
gid:"
+   for f in "${found[@]}"; do
+   # Strip off the leading destdir before 
outputting the path,
+   # but leave the prefix if there is one.
+   eqawarn "  ${f#${D%/}/}"
+   done
+   fi
+   done
+}
+
+bad_bin_group_write_check
+:
-- 
2.16.4




[gentoo-portage-dev] [PATCH 0/2] Two insecure ownership and group-writability QA checks.

2018-07-29 Thread Michael Orlitzky
Discussed and implemented in,

  https://bugs.gentoo.org/629398

Michael Orlitzky (2):
  bin/install-qa-check.d: add new 90bad-bin-owner QA check.
  bin/install-qa-check.d: add new 90bad-bin-group-write QA check.

 bin/install-qa-check.d/90bad-bin-group-write | 40 
 bin/install-qa-check.d/90bad-bin-owner   | 38 ++
 2 files changed, 78 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-group-write
 create mode 100644 bin/install-qa-check.d/90bad-bin-owner

-- 
2.16.4




[gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

2018-07-29 Thread Michael Orlitzky
System executables that are not owned by root pose a security
risk. The owner of the executable is free to modify it at any time;
so, for example, he can change a daemon's behavior to make it
malicious before the next time the service is started (usually by
root).

On a "normal" system, there is no good reason why the superuser should
not own every system executable. This commit adds a new install-time
check that reports any such binaries with a QA warning. To avoid false
positives, non-"normal" systems (like prefix) are skipped at the moment.

Bug: https://bugs.gentoo.org/629398
---
 bin/install-qa-check.d/90bad-bin-owner | 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 bin/install-qa-check.d/90bad-bin-owner

diff --git a/bin/install-qa-check.d/90bad-bin-owner 
b/bin/install-qa-check.d/90bad-bin-owner
new file mode 100644
index 0..188d67a51
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-owner
@@ -0,0 +1,38 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_owner_check() {
+   # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+   # or /usr/sbin) that are owned by a nonzero UID.
+
+   # This check doesn't work on non-root prefix installations at
+   # the moment, because every executable therein is owned by a
+   # nonzero UID.
+   [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+   local d f found=()
+
+   for d in "${ED%/}/bin" "${ED%/}/usr/bin" "${ED%/}/sbin" 
"${ED%/}/usr/sbin"; do
+   [[ -d "${d}" ]] || continue
+
+   # Read the results of the "find" command into the "found" bash 
array.
+   # Use -L to catch symlinks whose targets are owned by a 
non-root user,
+   # even though it won't catch ABSOLUTE symlinks until the package
+   # is RE-installed (the first time around, the target won't 
exist).
+   while read -r -d '' f; do
+   found+=( "${f}" )
+   done < <(find -L "${d}" -maxdepth 1 -type f ! -uid 0 -print0)
+
+   if [[ ${found[@]} ]]; then
+   eqawarn "system executables owned by nonzero uid:"
+   for f in "${found[@]}"; do
+   # Strip off the leading destdir before 
outputting the path,
+   # but leave the prefix if there is one.
+   eqawarn "  ${f#${D%/}/}"
+   done
+   fi
+   done
+}
+
+bad_bin_owner_check
+:
-- 
2.16.4




Re: [gentoo-portage-dev] [PATCH v3] install-qa-check: New QA check/cleanup for empty directories

2018-01-30 Thread Michael Orlitzky
On 01/30/2018 02:23 AM, Michał Górny wrote:
> Warn about empty directories installed to /var

Why only warn about /var, considering that FEATURES=strict-keepdir will
delete the others? People will probably assume that if their package
throws no warnings, it's strict-keepdir-safe.



Re: [gentoo-portage-dev] [PATCH] emerge: add --changed-deps-report option (bug 645780)

2018-01-28 Thread Michael Orlitzky
Since ::gentoo is the only repository governed by the PMS, can't we make
repoman do this? The problem with requiring "repoman --force" for an
in-place dependency change is that repoman generally won't have access
to the unedited ebuild; but for ::gentoo, we can probably hack something
together in git. Have it source the old and new ebuilds, and compare
their dependency lists.

It won't work outside of a git repo, but it will work in the one place
that really matters.



[gentoo-portage-dev] [PATCH v2 1/2] man/ebuild.5: document that dodir is for nonempty directories.

2018-01-12 Thread Michael Orlitzky
---
 man/ebuild.5 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 42a0599fe..28e9582d1 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -1271,7 +1271,8 @@ Creates directories inside of ${ED}.
 .br
 .BR 'dodir\ /usr/lib/apache'
 creates ${ED}/usr/lib/apache.  Note that the do* functions will run
-\fBdodir\fR for you.
+\fBdodir\fR for you. If this directory will be empty when it is merged,
+then please use \fBkeepdir\fR instead.
 .TP
 .B diropts\fR \fI[options for install(1)]
 Can be used to define options for the install function used in
-- 
2.13.6




[gentoo-portage-dev] [PATCH v2 0/2] man page updates to promote keepdir usage

2018-01-12 Thread Michael Orlitzky
The main barrier to proper keepdir usage is that nobody knows what
it's for. These two commits update the ebuild (5) man page with an
explanation, namely that empty directories are undefined by the PMS.

v2 uses different wording for dodir, and tries to be more precise
about what we mean by "is (non)empty."

Michael Orlitzky (2):
  man/ebuild.5: document that dodir is for nonempty directories.
  man/ebuild.5: document the rationale for using keepdir over dodir.

 man/ebuild.5 | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

-- 
2.13.6




[gentoo-portage-dev] [PATCH v2 2/2] man/ebuild.5: document the rationale for using keepdir over dodir.

2018-01-12 Thread Michael Orlitzky
---
 man/ebuild.5 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 28e9582d1..8784a14ee 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -1285,8 +1285,9 @@ Sets the root (\fIDESTTREE\fR) for other functions like 
\fBdobin\fR,
 The default root is /usr.
 .TP
 .B keepdir\fR \fI [more paths]
-Tells portage to leave directories behind even if they're empty.  Functions
-the same as \fBdodir\fR.
+Similar to \fBdodir\fR, but used to create directories that would otherwise
+be empty. The treatment of completely-empty directories is undefined by the
+PMS, and using \fBkeepdir\fR ensures that they are tracked.
 .TP
 .B dobin\fR \fI [list of more binaries]
 Installs a \fIbinary\fR or a list of binaries into \fIDESTTREE\fR/bin.
-- 
2.13.6




[gentoo-portage-dev] [PATCH 0/2] man page updates to promote keepdir usage

2018-01-12 Thread Michael Orlitzky
The main barrier to proper keepdir usage is that nobody knows what
it's for. These two commits update the ebuild (5) man page with an
explanation, namely that empty directories are undefined by the PMS.

Michael Orlitzky (2):
  man/ebuild.5: document that dodir is for nonempty directories.
  man/ebuild.5: document the rationale for using keepdir over dodir.

 man/ebuild.5 | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

-- 
2.13.6




[gentoo-portage-dev] [PATCH 2/2] man/ebuild.5: document the rationale for using keepdir over dodir.

2018-01-12 Thread Michael Orlitzky
---
 man/ebuild.5 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 9dd969b03..5e2fdbcf5 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -1285,8 +1285,9 @@ Sets the root (\fIDESTTREE\fR) for other functions like 
\fBdobin\fR,
 The default root is /usr.
 .TP
 .B keepdir\fR \fI [more paths]
-Tells portage to leave directories behind even if they're empty.  Functions
-the same as \fBdodir\fR.
+Similar to \fBdodir\fR, but used to create directories that would otherwise
+be empty. The treatment of completely-empty directories is undefined by the
+PMS, and using \fBkeepdir\fR ensures that they are tracked.
 .TP
 .B dobin\fR \fI [list of more binaries]
 Installs a \fIbinary\fR or a list of binaries into \fIDESTTREE\fR/bin.
-- 
2.13.6




[gentoo-portage-dev] [PATCH 1/2] man/ebuild.5: document that dodir is for nonempty directories.

2018-01-12 Thread Michael Orlitzky
---
 man/ebuild.5 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 42a0599fe..9dd969b03 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -1267,11 +1267,12 @@ that this expression does \fBNOT\fR use the offset 
prefix.
 runs sed on ${ED}/usr/bin/some\-script
 .TP
 .B dodir\fR \fI [more paths]
-Creates directories inside of ${ED}.
+Creates (nonempty) directories inside of ${ED}.
 .br
 .BR 'dodir\ /usr/lib/apache'
 creates ${ED}/usr/lib/apache.  Note that the do* functions will run
-\fBdodir\fR for you.
+\fBdodir\fR for you. Empty directories must be created with \fBkeepdir\fR
+instead.
 .TP
 .B diropts\fR \fI[options for install(1)]
 Can be used to define options for the install function used in
-- 
2.13.6




Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

2018-01-10 Thread Michael Orlitzky
On 01/10/2018 03:55 PM, Zac Medico wrote:
>>
>> This is going to break a lot of packages whose build systems create e.g.
>> /var/lib/foo and do nothing with it immediately. The ebuild should be
>> calling keepdir on those paths, but how would anyone know that?
> 
> If we consider that portage already removes these directories if they
> are still empty when the package is re-merged or upgraded, then maybe
> the risk is low enough?
> 

Does it? (Are we talking about the same thing?)

For example, the nagios-core build system creates a bunch of empty
directories under /var/nagios:

  $ find /var/nagios
  /var/nagios
  /var/nagios/rw
  /var/nagios/home
  /var/nagios/spool
  /var/nagios/spool/checkresults
  /var/nagios/archives

Re-emerging the same version of nagios-core doesn't kill them off.



Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

2018-01-10 Thread Michael Orlitzky
On 01/10/2018 03:13 PM, Michał Górny wrote:
> Remove empty directories in install-qa-check phase in order to prevent
> Portage from installing them, and therefore from developers relying
> on them being installed.

This is going to break a lot of packages whose build systems create e.g.
/var/lib/foo and do nothing with it immediately. The ebuild should be
calling keepdir on those paths, but how would anyone know that?



Re: [gentoo-portage-dev] [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)

2017-03-05 Thread Michael Orlitzky
On 03/05/2017 02:12 PM, Zac Medico wrote:
> 
> Incorrect.
> 
> ...
> 
> Incorrect.
> 

I see my mistakes, but maintain that this is confusing =)


> 
> The --with-bdeps-auto option results in desirable behavior by default,
> and it's also backward compatible with existing --with-bdeps and
> --usepkg usage. It just does the right thing, minimizing the impact to
> existing emerge usage.

I was hoping that since nothing breaks with --update-bdeps=y and
--clean-bdeps=n (the new defaults), we could just disable --with-bdeps
immediately and emit a warning when it's given.


> 
> There some problems with --update-bdeps/--clean-bdeps:
> 
> * The program logic will be more complicated, since --with-bdeps will
> have to override both options for backward-compatibility with existing
> --with-bdeps usage.

Not applicable if --with-bdeps goes away.


> * The meaning of --clean-bdeps is confusing. Does --clean-bdeps=y mean
> to clean build time deps, or does it mean to pull build time deps into
> the dependency graph for removal operations?

--clean-bdeps means clean the bdeps.


I totally agree that the worst option of all is to keep --with-bdeps AND
introduce the other two.




Re: [gentoo-portage-dev] [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)

2017-03-05 Thread Michael Orlitzky
On 03/05/2017 03:40 AM, Zac Medico wrote:
> 
> A new --with-bdeps-auto= option is provided, making it possible to
> enable or disable the program logic that causes --with-bdeps to be
> automatically enabled. Use --with-bdeps-auto=n to prevent --with-bdeps
> from being automatically enabled for installation actions. This is useful
> for some rare cases in which --with-bdeps triggers unsolvable dependency
> conflicts (and putting --with-bdeps=n in EMERGE_DEFAULT_OPTS would cause
> undesirable --depclean behavior).
> 

If I understand correctly, the end result of this is two --flags that
combine in a (rather complicated) way to let the user control the
default bdeps behavior of both "emerge --update" and "emerge --depclean"
separately. I'll try to summarize my understanding:

   I. emerge --update

 I.a. Some people want to --update the build dependencies they have
  installed for e.g. security purposes.

 I.b. Others don't want build deps pulled in by "emerge --update",
  because they're using binary packages or because it causes
  conflicts in the resolver (llvm).

  II. emerge --depclean

II.a. The default behavior is to not remove build-only dependencies
  because, generally, they will just have to rebuilt again.

II.b. However, some people want to remove the build-only deps that
  aren't strictly in use -- particularly if those build-only
  deps are not being updated by emerge --update.


To choose between those four options...

  i.   --with-bdeps=n and --with-bdeps-auto=y gives you I.a. + II.b.

  ii.  --with-bdeps=n and --with-bdeps-auto=n gives you I.b. + II.b.

  iii. --with-bdeps=y and --with-bdeps-auto=y gives you I.a. + II.a.

  iv.  --with-bdeps=y and --with-bdeps-auto=n gives you I.a. + II.a.

That only gets you three out of the four options. You have to read the
fine print to get the other:

  v.   passing no flags explicitly gives you I.b. and II.a.

If there's going to be two flags, can't we do better? Why not just name
the flags after what we want them to do:

  --update-bdeps= (default: y)

  --clean-bdeps=  (default: n)

With those two options, it's easy to tell portage exactly what you want.
If I don't like the defaults, I can turn one of them off without
affecting the other.

But what about the --usepkg magic? I think the workaround can be left
as-is. When --usepkg is enabled, switch the default for --update-bdeps
to "n" unless it is explicitly set.

Food for thought. Anyway, thanks for working on this.



Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

2017-02-01 Thread Michael Orlitzky
On 02/01/2017 04:03 PM, Michał Górny wrote:
>>  SLOT="0"
>> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr"
>> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux
>> xattr"
> 
> Wouldn't it be better to enable it by default?
> 

Please don't enshrine personal preferences into IUSE defaults unless
they're critical to the package.





Re: [gentoo-portage-dev] [PATCH] repoman: add HOMEPAGE.missingurischeme check

2017-01-07 Thread Michael Orlitzky
On 01/07/2017 06:08 AM, Wim Muskee wrote:
> 
> URISCHEME_RE = re.compile(r'^[a-z\-]+://')
> 
> ...
> 
> URISCHEME_RE.match(ebuild.metadata.get("HOMEPAGE")) is None:
> 

The PMS allows some weird stuff in HOMEPAGE:

  https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-760008

Specifically,

  In addition, SRC_URI, HOMEPAGE, RESTRICT, PROPERTIES, LICENSE and
  REQUIRED_USE use dependency-style specifications to specify their
  values.

That means that something like,

  HOMEPAGE="branding? ( https://www.mozilla.org/ )
   !branding? ( https://www.gentoo.org/ )"

would be valid. It's a little crazy, but there it is.

If you can figure out a way to parse a dependency spec (this has to
exist somewhere in repoman/portage), then you can run your check against
the URLs at the leaf nodes. At that point, it should be relatively easy
to update the regex to match the RFC =)

  https://tools.ietf.org/html/rfc3986#section-3.1




Re: [gentoo-portage-dev] [PATCH 1/1] Add a test case for PMS-compliant usage of the ROOT variable.

2016-05-11 Thread Michael Orlitzky
On 05/11/2016 12:33 PM, Brian Dolbec wrote:
> 
> I'll work on adding this check to repoman after I finish getting some
> in progress changes done so the new repoman code can be released.
> 

I took a look at the new code and it was really easy to get something
working. I added a new QA category, "variable.illegal", and left it an
error. People can --force it through if they want to, so I don't think
maintaining backwards-compatibility (against what the PMS says) is crucial.

Adding a new check in ebuild/checks.py was simple: add a PhaseCheck with
a whitelist of phases and perform the check in any other scope.

The only tricky part is the regular expression. The dumbest thing that
could possibly work is,

  rootvar_re = re.compile(r'\$(ROOT|{ROOT})')

That will throw false positives in all sorts of situations, like
app-eselect/eselect-rails-0.21:

  src_prepare() {
# Fix/Add Prefix support
sed -i -e 's/\${ROOT}/${EROOT}/' *.eselect || die
  }

The only check I saw that tried to be clever about string parsing is the
variable quoting check. Both seem to share a common need, to perform a
check only when something really is a variable and not part of a string
or otherwise cleverly-disguised.

Should we try to factor something out, or do you want me to send the
naive version (based on the repoman branch) and fix it later?




[gentoo-portage-dev] [PATCH 0/1] Test PMS-compliant usage of the ROOT variable.

2016-05-11 Thread Michael Orlitzky
Per the discussion over on -dev, this adds a test case for usage of
the ROOT variable outside of the PMS-defined pkg_* functions (which is
not allowed).

There should probably be a warning for this in repoman, since most
usages I've seen are really intended to be EPREFIX and not ROOT. Any
cases that are not so easy to fix will stand out once the trivial ones
are. Perhaps in EAPI-$next, the warning can become an error.

Michael Orlitzky (1):
  Add a test case for PMS-compliant usage of the ROOT variable.

 ebuild-test/root-var-usage/metadata.xml| 24 ++
 ebuild-test/root-var-usage/root-var-usage-0.ebuild | 90 ++
 2 files changed, 114 insertions(+)
 create mode 100644 ebuild-test/root-var-usage/metadata.xml
 create mode 100644 ebuild-test/root-var-usage/root-var-usage-0.ebuild

-- 
2.7.3




[gentoo-portage-dev] [PATCH 0/2] Document globbing for INSTALL_MASK.

2015-07-19 Thread Michael Orlitzky
This documents shell globs in INSTALL_MASK and warns about filenames
containing spaces. I also added a few more comments to the code after
I figured out what it was going.

Michael Orlitzky (2):
  bin/misc-functions.sh: Elaborate on some comments in install_mask().
  man/make.conf.5: Document globbing for INSTALL_MASK.

 bin/misc-functions.sh | 16 +---
 man/make.conf.5   | 44 
 2 files changed, 49 insertions(+), 11 deletions(-)

-- 
2.3.6




[gentoo-portage-dev] [PATCH 1/2] bin/misc-functions.sh: Elaborate on some comments in install_mask().

2015-07-19 Thread Michael Orlitzky
---
 bin/misc-functions.sh | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 9b79351..c2ff70a 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -261,20 +261,30 @@ install_mask() {
shift
local install_mask=$*
 
-   # we don't want globbing for initial expansion, but afterwards, we do
+   # We think of $install_mask as a space-separated list of
+   # globs. We don't want globbing in the for loop; that is, we
+   # want to keep the asterisks in the indivual entries.
local shopts=$-
set -o noglob
local no_inst
for no_inst in ${install_mask}; do
+   # Here, $no_inst is a single entry potentially
+   # containing a glob. From now on, we *do* want to
+   # expand it.
set +o noglob
 
-   # normal stuff
+   # The standard case where $no_inst is something that
+   # the shell could expand on its own.
if [[ -e ${root}/${no_inst} || ${root}/${no_inst} != $(echo 
${root}/${no_inst}) ]] ; then
__quiet_mode || einfo Removing ${no_inst}
rm -Rf ${root}/${no_inst} /dev/null
fi
 
-   # we also need to handle globs (*.a, *.h, etc)
+   # We also want to allow the user to specify a bare
+   # glob. For example, $no_inst=*.a should prevent
+   # ALL files ending in .a from being installed,
+   # regardless of their location/depth. We achieve this
+   # by passing the pattern to `find`.
find ${root} \( -path ${no_inst} -or -name ${no_inst} \) \
-print0 2 /dev/null \
| LC_ALL=C sort -z \
-- 
2.3.6




Re: [gentoo-portage-dev] Re: [PATCHv3 1/2] MEDIUM: misc-functions: Be more quiet when removing non existing INSTALL_MASK

2015-04-21 Thread Michael Orlitzky
On 04/21/2015 01:28 PM, Zac Medico wrote:

 The docs for INSTALL_MASK (man 5 make.conf) don't mention that globs
 will work. It's expecting a space delimited list of file names. Does
 it really take a space-delimited list of globs instead? If so, how does
 that reconcile with the fact that * could match spaces?
 
 How does it conflict?
 

I guess it's more of a filenames-with-spaces question. Would this work?

  INSTALL_MASK=Boyd\ -\ Convex Optimization.pdf

If you can escape the spaces, then the space-separated globs aren't
ambiguous. I was thinking of something like this:

  $ /bin/ls B*\ Convex*
  Boyd - Convex Optimization.pdf

Normally if you stick something like that in a quoted variable, its
spaces can be unescaped:

  INSTALL_MASK=B* Convex*

But now it's two globs instead of one. The whole thing makes sense if
you can leave the space escaped though.




Re: [gentoo-portage-dev] Re: [PATCHv3 1/2] MEDIUM: misc-functions: Be more quiet when removing non existing INSTALL_MASK

2015-04-21 Thread Michael Orlitzky
On 04/21/2015 05:48 AM, Duncan wrote:

 Well, I don't use INSTALL_MASK myself, so I don't have a real-world
 use-case for you. However, it's clear that the code will expand shell
 globs, so I preserved that behavior for compatibility.
 
 I do, with shell globs, tho I didn't bother checking the above to see if 
 they'd have been affected.
 

The docs for INSTALL_MASK (man 5 make.conf) don't mention that globs
will work. It's expecting a space delimited list of file names. Does
it really take a space-delimited list of globs instead? If so, how does
that reconcile with the fact that * could match spaces?




Re: [gentoo-portage-dev] [RFC] Add 'emerge --sync-glsa' action and 'emaint sync-glsa' command

2014-12-17 Thread Michael Orlitzky
On 12/17/2014 05:32 PM, Brian Dolbec wrote:
 
 Only code changes I see to portage, pkgcore (I know nothing about
 paludis) are to look for the glsa's in the 2 possible locations.  The
 standalone glsa repo, failing that, backup to the gentoo tree.
 

Could we ship a GLSA overlay enabled by default, regardless of what we
do with the main repo? Then for simplicity, we update the tools to check
metadata/glsa in overlays as well. No need to special-case a fallback
location.

glsa-check would of course want to sync the GLSA repo before running.




[gentoo-portage-dev] [PATCH] Add the has function to the ebuild(5) man page.

2014-01-22 Thread Michael Orlitzky
I WTF'ed on this for a long time before I noticed that the docs for
has were sort-of contained in hasv. Might as well give has its own.
From 423123cc2ea429c06914ef858a6fdb86c0c6d30b Mon Sep 17 00:00:00 2001
From: Michael Orlitzky m...@gentoo.org
Date: Wed, 22 Jan 2014 16:18:23 -0500
Subject: [PATCH] Add the has function to the ebuild(5) man page.

---
 man/ebuild.5 | 8 
 1 file changed, 8 insertions(+)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 524006a..36836b3 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -1049,6 +1049,14 @@ of \fI\-\-without\-\fR. Beginning with \fBEAPI 4\fR, an empty \fIconfigure
 opt\fR argument is recognized. In \fBEAPI 3\fR and earlier, an empty
 \fIconfigure opt\fR argument is treated as if it weren't provided.
 .TP
+.B has\fR \fIitem\fR \fIitem list
+If \fIitem\fR is in \fIitem list\fR, then \fBhas\fR returns
+0. Otherwise, 1 is returned. There is another version, \fBhasv\fR, that
+will conditionally echo \fIitem\fR.
+.br
+The \fIitem list\fR is delimited by the \fIIFS\fR variable.  This variable
+has a default value of ' ', or a space.  It is a \fBbash\fR(1) setting.
+.TP
 .B hasv\fR \fIitem\fR \fIitem list
 If \fIitem\fR is in \fIitem list\fR, then \fIitem\fR is echoed and \fBhasv\fR
 returns 0.  Otherwise, nothing is echoed and 1 is returned. As indicated with
-- 
1.8.3.2