Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for > reading at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access in order to ensure proper accountability (c.f GLEP 48 > for QA and still non-produced GLEP for ComRel (I've started working on > this and will be presenting this one later as current ComRel Lead)) > > Comments, patches, threats, etc welcome > Most of it seems more appropriate for a project page to me and up to the sec. team, so I'll comment on the global parts only. The only global part I see is the "Security package version/revision bumps and package masks". This one would benefit from a proper definition of the rules here: If severity is X then inactive is defined to be Y days. After that, sec. team can fix themselves. It should also be the same for masking: If severity is X and no fix is known after Y days/months then sec. team should mask it (but not last rite it, this should still be maintainer/treecleaners). I think the delay should be clearly stated in the bug with something like: Please keep in mind that since this is a remote code execution vulnerability, security team will take action if nothing happens within one week. If you have tools filling the severity fields then a proper definition allows to automate this too. My point here is to avoid having all the responsibility falling under the lead but focus more on getting things done and educating fellow developers: Lower delays for more serious bugs will make people understand and prioritize better the issues at hand and their implications. Also, it'd be nice to have something more formal for sec. cleanup: "After 30 days a sec. issue has been fixed, sec. team is free to cleanup old vulnerable versions.". I've seen too much pings by sec. team members on old bugs for this and they could have spent the same amount of time simply doing it instead. Alexis.
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On Sun, 12 Mar 2017 09:14:09 +0100 Alexis Ballier wrote: > My point here is to avoid having all the responsibility falling under > the lead In other words: If you want to avoid having bugs inactive for too long, don't introduce a bus factor of 1 through the project lead :)
[gentoo-dev] Retrieve get_libdir path on EAPI 6
Hi,
in EAPI 6 get_libdir function is not more available but I currently use
it on my eclass for initialize some metadata.
How can I retrieve environment $libdir path ? With LIBDIR_${cpu}
variable?
On mgorny post I read that get_libdir function is part of EAPI, but I
don't understand how this means. I use portage-2.3.4.
Thanks in advance
G.
Re: [gentoo-dev] Retrieve get_libdir path on EAPI 6
W dniu 12.03.2017, nie o godzinie 10∶36 +0100, użytkownik Geaaru
napisał:
> Hi,
>
> in EAPI 6 get_libdir function is not more available but I currently use
> it on my eclass for initialize some metadata.
> How can I retrieve environment $libdir path ? With LIBDIR_${cpu}
> variable?
>
> On mgorny post I read that get_libdir function is part of EAPI, but I
> don't understand how this means. I use portage-2.3.4.
>
This means that you can use it without inheriting any eclass. It's
provided by portage directly.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Developers and projects, please stop holding ransom over unmaintained packages!
Hi, TL;DR: if you don't maintain a package, drop it to maintainer-needed, so others can step up. Lately I have had to deal with a fair number of packages which haven't seen any maintainer activity for a few years already. This includes packages with multiple bug reports which haven't seen any response, and is especially true of packages maintained by projects, and especially the kind of projects that loosely couple lots of barely related packages (i.e. categories) -- www-apps, forensics, benchmarks. I can think of a few reasons why this happens: a. creating meaningless projects that attempt to group things which don't have much in common, and where each project member is interested in a subset of the packages, b. developers leaving projects without ensuring that there's anyone left and either cleaning them up or announcing the need for new members, c. developers abandoning their packages and dumping them on generic projects (e.g. dumping random Python programs on python@g.o). This causes two major issues: 1. Newly reported bugs are assigned directly to the maintainer. If the maintainer ignores them, then the users end up waiting forever for a reply. In this case, it is indeed better if the user clearly sees that the package has no maintainer and if people subscribing to maintainer-needed@ mail see the new bugs. 2. Other developers hesitate to fix the package, and file bugs instead. If the maintainer doesn't reply to those bugs, that's just a wasted developer effort + unnecessary delay in getting things fixed. If they get fixed at all since the developer may forget that he filed a bug. So, developers: A. Please make sure you are only listed as a maintainer for the packages that you really want to maintain. If you are no longer interested in a package, send the usual 'up for grabs' mail to let others take care of it [and lastrite or dump it to maintainer-needed if they don't want to]. B. If your project is unable to maintain all the packages it has, then either: B1. announce the need for more project members, B2. 'up for grabs' some of the packages to let them get a dedicated maintainer, B3. disband the project altogether and take over direct maintenance of the packages you care about. C. If you no longer wish to maintain a package, then don't dump it on a generic project without asking first. Just because some project didn't mind being backup/advisory maintainer for your package doesn't mean that it wants to maintain it by itself. Any comments? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Retrieve get_libdir path on EAPI 6
Thanks for replay. But if I try to use it inside my eclass inside my
overlay isn't resolved correctly. I receive an empty string. Could be
related that in my eclass function is not already available? Or related to
a wrong version of some packages?
On Mar 12, 2017 10:55 AM, "Michał Górny" wrote:
> W dniu 12.03.2017, nie o godzinie 10∶36 +0100, użytkownik Geaaru
> napisał:
> > Hi,
> >
> > in EAPI 6 get_libdir function is not more available but I currently use
> > it on my eclass for initialize some metadata.
> > How can I retrieve environment $libdir path ? With LIBDIR_${cpu}
> > variable?
> >
> > On mgorny post I read that get_libdir function is part of EAPI, but I
> > don't understand how this means. I use portage-2.3.4.
> >
>
> This means that you can use it without inheriting any eclass. It's
> provided by portage directly.
>
> --
> Best regards,
> Michał Górny
>
Re: [gentoo-dev] Retrieve get_libdir path on EAPI 6
W dniu 12.03.2017, nie o godzinie 11∶02 +0100, użytkownik Geaaru napisał: > Thanks for replay. But if I try to use it inside my eclass inside my > overlay isn't resolved correctly. I receive an empty string. Could be > related that in my eclass function is not already available? Or related to > a wrong version of some packages? If you are attempting to use it in global scope (i.e. outside phase functions), then it won't work. Such a use is forbidden since it would mean that global variables differ depending on profile being used. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH v3] estack.eclass: Split estack* logic from eutils
Split the estack_* and related functions from eutils into a dedicated
estack.eclass. Those functions have significant complexity and are not
used frequently, therefore they benefit from having a separate file
and an explicit dedicated maintainer.
The new eclass is implicitly inherited by eutils to preserve
compatibility. However, the inherit will be removed in EAPI 7,
and the ebuilds should switch to using estack directly.
Thanks to Ulrich Müller for doing the research on this.
// v3: also rename&update tests
---
eclass/estack.eclass | 217 +
eclass/eutils.eclass | 210 +---
.../tests/{eutils_eshopts.sh => estack_eshopts.sh} | 4 +-
.../tests/{eutils_estack.sh => estack_estack.sh} | 4 +-
eclass/tests/{eutils_evar.sh => estack_evar.sh}| 4 +-
5 files changed, 230 insertions(+), 209 deletions(-)
create mode 100644 eclass/estack.eclass
rename eclass/tests/{eutils_eshopts.sh => estack_eshopts.sh} (93%)
rename eclass/tests/{eutils_estack.sh => estack_estack.sh} (93%)
rename eclass/tests/{eutils_evar.sh => estack_evar.sh} (96%)
diff --git a/eclass/estack.eclass b/eclass/estack.eclass
new file mode 100644
index ..19c388f3d8d2
--- /dev/null
+++ b/eclass/estack.eclass
@@ -0,0 +1,217 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: estack.eclass
+# @MAINTAINER:
+# base-sys...@gentoo.org
+# @BLURB: stack-like value storage support
+# @DESCRIPTION:
+# Support for storing values on stack-like variables.
+
+if [[ -z ${_ESTACK_ECLASS} ]]; then
+
+# @FUNCTION: estack_push
+# @USAGE: [items to push]
+# @DESCRIPTION:
+# Push any number of items onto the specified stack. Pick a name that
+# is a valid variable (i.e. stick to alphanumerics), and push as many
+# items as you like onto the stack at once.
+#
+# The following code snippet will echo 5, then 4, then 3, then ...
+# @CODE
+# estack_push mystack 1 2 3 4 5
+# while estack_pop mystack i ; do
+# echo "${i}"
+# done
+# @CODE
+estack_push() {
+ [[ $# -eq 0 ]] && die "estack_push: incorrect # of arguments"
+ local stack_name="_ESTACK_$1_" ; shift
+ eval ${stack_name}+=\( \"\$@\" \)
+}
+
+# @FUNCTION: estack_pop
+# @USAGE: [variable]
+# @DESCRIPTION:
+# Pop a single item off the specified stack. If a variable is specified,
+# the popped item is stored there. If no more items are available, return
+# 1, else return 0. See estack_push for more info.
+estack_pop() {
+ [[ $# -eq 0 || $# -gt 2 ]] && die "estack_pop: incorrect # of arguments"
+
+ # We use the fugly _estack_xxx var names to avoid collision with
+ # passing back the return value. If we used "local i" and the
+ # caller ran `estack_pop ... i`, we'd end up setting the local
+ # copy of "i" rather than the caller's copy. The _estack_xxx
+ # garbage is preferable to using $1/$2 everywhere as that is a
+ # bit harder to read.
+ local _estack_name="_ESTACK_$1_" ; shift
+ local _estack_retvar=$1 ; shift
+ eval local _estack_i=\${#${_estack_name}\[@\]}
+ # Don't warn -- let the caller interpret this as a failure
+ # or as normal behavior (akin to `shift`)
+ [[ $(( --_estack_i )) -eq -1 ]] && return 1
+
+ if [[ -n ${_estack_retvar} ]] ; then
+ eval ${_estack_retvar}=\"\${${_estack_name}\[${_estack_i}\]}\"
+ fi
+ eval unset \"${_estack_name}\[${_estack_i}\]\"
+}
+
+# @FUNCTION: evar_push
+# @USAGE: [more vars to save]
+# @DESCRIPTION:
+# This let's you temporarily modify a variable and then restore it (including
+# set vs unset semantics). Arrays are not supported at this time.
+#
+# This is meant for variables where using `local` does not work (such as
+# exported variables, or only temporarily changing things in a func).
+#
+# For example:
+# @CODE
+# evar_push LC_ALL
+# export LC_ALL=C
+# ... do some stuff that needs LC_ALL=C set ...
+# evar_pop
+#
+# # You can also save/restore more than one var at a time
+# evar_push BUTTERFLY IN THE SKY
+# ... do stuff with the vars ...
+# evar_pop # This restores just one var, SKY
+# ... do more stuff ...
+# evar_pop 3 # This pops the remaining 3 vars
+# @CODE
+evar_push() {
+ local var val
+ for var ; do
+ [[ ${!var+set} == "set" ]] \
+ && val=${!var} \
+ || val="unset_76fc3c462065bb4ca959f939e6793f94"
+ estack_push evar "${var}" "${val}"
+ done
+}
+
+# @FUNCTION: evar_push_set
+# @USAGE: [new value to store]
+# @DESCRIPTION:
+# This is a handy shortcut to save and temporarily set a variable. If a value
+# is not specified, the var will be unset.
+evar_push_set()
Re: [gentoo-dev] Retrieve get_libdir path on EAPI 6
On Sun, 12 Mar 2017 10:36:33 +0100 Geaaru wrote: > Hi, > > in EAPI 6 get_libdir function is not more available ??? It _is_ available. In EAPI 6 get_libdir was removed from multilib.eclass and put to EAPI 6: https://projects.gentoo.org/pms/6/pms.html#x1-143034r25 P.S. Questions about ebuild writing should go to gentoo-devhelp ML. Best regards, Andrew Savchenko pgpFzLREG0wRj.pgp Description: PGP signature
[gentoo-dev] [PATCH] ltprune.eclass: Split prune_libtool_files out of eutils
Move the prune_libtool_files into a dedicated ltprune.eclass.
The function is quite complex and depends on toolchain-funcs. It has
a separate maintainer, is not useful to non-autotools ebuilds, and even
there it is frequently replaced by the simpler 'find ... -delete' call.
Kill the unnecessary Prefix logic. There is no functional difference
between starting the find in ${D} and ${ED}, and the latter implies
unnecessary hackery for old EAPIs.
The new eclass is implicitly inherited by eutils in EAPI 6 and older
in order to preserve compatibility with existing ebuilds. However, all
ebuilds should switch to inheriting it directly.
The split has been suggested by Ulrich Müller.
---
eclass/eutils.eclass | 150 +
eclass/ltprune.eclass | 166 ++
2 files changed, 167 insertions(+), 149 deletions(-)
create mode 100644 eclass/ltprune.eclass
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index e036001dc5e1..c932d685c0e9 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -17,12 +17,10 @@
if [[ -z ${_EUTILS_ECLASS} ]]; then
_EUTILS_ECLASS=1
-inherit toolchain-funcs
-
# implicitly inherited (now split) eclasses
case ${EAPI:-0} in
0|1|2|3|4|5|6)
- inherit epatch estack multilib
+ inherit epatch estack ltprune multilib toolchain-funcs
;;
esac
@@ -869,152 +867,6 @@ use_if_iuse() {
use $1
}
-# @FUNCTION: prune_libtool_files
-# @USAGE: [--all|--modules]
-# @DESCRIPTION:
-# Locate unnecessary libtool files (.la) and libtool static archives
-# (.a) and remove them from installation image.
-#
-# By default, .la files are removed whenever the static linkage can
-# either be performed using pkg-config or doesn't introduce additional
-# flags.
-#
-# If '--modules' argument is passed, .la files for modules (plugins) are
-# removed as well. This is usually useful when the package installs
-# plugins and the plugin loader does not use .la files.
-#
-# If '--all' argument is passed, all .la files are removed without
-# performing any heuristic on them. You shouldn't ever use that,
-# and instead report a bug in the algorithm instead.
-#
-# The .a files are only removed whenever corresponding .la files state
-# that they should not be linked to, i.e. whenever these files
-# correspond to plugins.
-#
-# Note: if your package installs both static libraries and .pc files
-# which use variable substitution for -l flags, you need to add
-# pkg-config to your DEPEND.
-prune_libtool_files() {
- debug-print-function ${FUNCNAME} "$@"
-
- local removing_all removing_modules opt
- _eutils_eprefix_init
- for opt; do
- case "${opt}" in
- --all)
- removing_all=1
- removing_modules=1
- ;;
- --modules)
- removing_modules=1
- ;;
- *)
- die "Invalid argument to ${FUNCNAME}(): ${opt}"
- esac
- done
-
- local f
- local queue=()
- while IFS= read -r -d '' f; do # for all .la files
- local archivefile=${f/%.la/.a}
-
- # The following check is done by libtool itself.
- # It helps us avoid removing random files which match '*.la',
- # see bug #468380.
- if ! sed -n -e '/^# Generated by .*libtool/q0;4q1' "${f}"; then
- continue
- fi
-
- [[ ${f} != ${archivefile} ]] || die 'regex sanity check failed'
- local reason= pkgconfig_scanned=
- local snotlink=$(sed -n -e 's:^shouldnotlink=::p' "${f}")
-
- if [[ ${snotlink} == yes ]]; then
-
- # Remove static libs we're not supposed to link against.
- if [[ -f ${archivefile} ]]; then
- einfo "Removing unnecessary
${archivefile#${D%/}} (static plugin)"
- queue+=( "${archivefile}" )
- fi
-
- # The .la file may be used by a module loader, so avoid
removing it
- # unless explicitly requested.
- if [[ ${removing_modules} ]]; then
- reason='module'
- fi
-
- else
-
- # Remove .la files when:
- # - user explicitly wants us to remove all .la files,
- # - respective static archive doesn't exist,
- # - they are covered by a .pc file already,
- # - they don't provide any new information (no libs &
no flags).
-
- if [[ ${removing_all} ]]; then
- reason='requested'
-
[gentoo-dev] [PATCH v2] ltprune.eclass
Changes in v2: - now in split commits to ease review, - removed eqawarn to avoid circ dep on eutils.
[gentoo-dev] [PATCH 1/3] eutils.eclass: prune_libtool_files, punt pointless Prefix logic
Remove the unnecessary Prefix logic from prune_libtool_files(). There is
no functional difference between starting a find in ${D} and ${ED}
(since ${D} is not supposed to contain other directories on a Prefix
system), and using the latter implies unnecessary hackery for older
EAPIs.
---
eclass/eutils.eclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index e036001dc5e1..ab226b236a37 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -898,7 +898,6 @@ prune_libtool_files() {
debug-print-function ${FUNCNAME} "$@"
local removing_all removing_modules opt
- _eutils_eprefix_init
for opt; do
case "${opt}" in
--all)
@@ -1008,7 +1007,7 @@ prune_libtool_files() {
einfo "Removing unnecessary ${f#${D%/}} (${reason})"
queue+=( "${f}" )
fi
- done < <(find "${ED}" -xtype f -name '*.la' -print0)
+ done < <(find "${D}" -xtype f -name '*.la' -print0)
if [[ ${queue[@]} ]]; then
rm -f "${queue[@]}"
--
2.12.0
[gentoo-dev] [PATCH 2/3] eutils.eclass: prune_libtool_files, make .pc subst errors fatal
Make the substitution errors in prune_libtool_files logic fatal to avoid
the dependency of eqawarn. They're extremely unlikely to happen anyway.
---
eclass/eutils.eclass | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index ab226b236a37..cb472caee1d4 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -982,9 +982,10 @@ prune_libtool_files() {
for arg in ${libs}; do
if [[ ${arg} ==
-l* ]]; then
if [[
${arg} == '*$*' ]]; then
-
eqawarn "${FUNCNAME}: variable substitution likely failed in ${pc}"
-
eqawarn "(arg: ${arg})"
-
eqawarn "Most likely, you need to add virtual/pkgconfig to DEPEND."
+
eerror "${FUNCNAME}: variable substitution likely failed in ${pc}"
+
eerror "(arg: ${arg})"
+
eerror "Most likely, you need to add virtual/pkgconfig to DEPEND."
+
die "${FUNCNAME}: unsubstituted variable found in .pc"
fi
pc_libs+=( lib${arg#-l}.la )
--
2.12.0
[gentoo-dev] [PATCH 3/3] ltprune.eclass: Split prune_libtool_files out of eutils
Move the prune_libtool_files into a dedicated ltprune.eclass.
The function is quite complex and depends on toolchain-funcs. It has
a separate maintainer, is not useful to non-autotools ebuilds, and even
there it is frequently replaced by the simpler 'find ... -delete' call.
The new eclass is implicitly inherited by eutils in EAPI 6 and older
in order to preserve compatibility with existing ebuilds. However, all
ebuilds should switch to inheriting it directly.
The split has been suggested by Ulrich Müller.
---
eclass/eutils.eclass | 150 +
eclass/ltprune.eclass | 167 ++
2 files changed, 168 insertions(+), 149 deletions(-)
create mode 100644 eclass/ltprune.eclass
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index cb472caee1d4..c932d685c0e9 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -17,12 +17,10 @@
if [[ -z ${_EUTILS_ECLASS} ]]; then
_EUTILS_ECLASS=1
-inherit toolchain-funcs
-
# implicitly inherited (now split) eclasses
case ${EAPI:-0} in
0|1|2|3|4|5|6)
- inherit epatch estack multilib
+ inherit epatch estack ltprune multilib toolchain-funcs
;;
esac
@@ -869,152 +867,6 @@ use_if_iuse() {
use $1
}
-# @FUNCTION: prune_libtool_files
-# @USAGE: [--all|--modules]
-# @DESCRIPTION:
-# Locate unnecessary libtool files (.la) and libtool static archives
-# (.a) and remove them from installation image.
-#
-# By default, .la files are removed whenever the static linkage can
-# either be performed using pkg-config or doesn't introduce additional
-# flags.
-#
-# If '--modules' argument is passed, .la files for modules (plugins) are
-# removed as well. This is usually useful when the package installs
-# plugins and the plugin loader does not use .la files.
-#
-# If '--all' argument is passed, all .la files are removed without
-# performing any heuristic on them. You shouldn't ever use that,
-# and instead report a bug in the algorithm instead.
-#
-# The .a files are only removed whenever corresponding .la files state
-# that they should not be linked to, i.e. whenever these files
-# correspond to plugins.
-#
-# Note: if your package installs both static libraries and .pc files
-# which use variable substitution for -l flags, you need to add
-# pkg-config to your DEPEND.
-prune_libtool_files() {
- debug-print-function ${FUNCNAME} "$@"
-
- local removing_all removing_modules opt
- for opt; do
- case "${opt}" in
- --all)
- removing_all=1
- removing_modules=1
- ;;
- --modules)
- removing_modules=1
- ;;
- *)
- die "Invalid argument to ${FUNCNAME}(): ${opt}"
- esac
- done
-
- local f
- local queue=()
- while IFS= read -r -d '' f; do # for all .la files
- local archivefile=${f/%.la/.a}
-
- # The following check is done by libtool itself.
- # It helps us avoid removing random files which match '*.la',
- # see bug #468380.
- if ! sed -n -e '/^# Generated by .*libtool/q0;4q1' "${f}"; then
- continue
- fi
-
- [[ ${f} != ${archivefile} ]] || die 'regex sanity check failed'
- local reason= pkgconfig_scanned=
- local snotlink=$(sed -n -e 's:^shouldnotlink=::p' "${f}")
-
- if [[ ${snotlink} == yes ]]; then
-
- # Remove static libs we're not supposed to link against.
- if [[ -f ${archivefile} ]]; then
- einfo "Removing unnecessary
${archivefile#${D%/}} (static plugin)"
- queue+=( "${archivefile}" )
- fi
-
- # The .la file may be used by a module loader, so avoid
removing it
- # unless explicitly requested.
- if [[ ${removing_modules} ]]; then
- reason='module'
- fi
-
- else
-
- # Remove .la files when:
- # - user explicitly wants us to remove all .la files,
- # - respective static archive doesn't exist,
- # - they are covered by a .pc file already,
- # - they don't provide any new information (no libs &
no flags).
-
- if [[ ${removing_all} ]]; then
- reason='requested'
- elif [[ ! -f ${archivefile} ]]; then
- reason='no static archive'
- elif [[ ! $(sed -nre \
-
"s/^(dependen
Re: [gentoo-dev] [PATCH 2/3] eutils.eclass: prune_libtool_files, make .pc subst errors fatal
On Sun, 12 Mar 2017 12:00:08 +0100
Michał Górny wrote:
> Make the substitution errors in prune_libtool_files logic fatal to
> avoid the dependency of eqawarn. They're extremely unlikely to happen
> anyway. ---
> eclass/eutils.eclass | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index ab226b236a37..cb472caee1d4 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -982,9 +982,10 @@ prune_libtool_files() {
> for arg in
> ${libs}; do if [[ ${arg} == -l* ]]; then
> if
> [[ ${arg} == '*$*' ]]; then
> -
> eqawarn "${FUNCNAME}: variable substitution likely failed in ${pc}"
> -
> eqawarn "(arg: ${arg})"
> -
> eqawarn "Most likely, you need to add virtual/pkgconfig to DEPEND."
> +
> eerror "${FUNCNAME}: variable substitution likely failed in ${pc}"
> +
> eerror "(arg: ${arg})"
> +
> eerror "Most likely, you need to add virtual/pkgconfig to DEPEND."
> +
> die "${FUNCNAME}: unsubstituted variable found in .pc" fi
If you go that way then it would be best if this function had a
'has "virtual/pkgconfig" ${DEPEND} || die ...' kind of logic
the message is more intended towards package maintainer and i would
assume they have pkgconfig installed which means the failure will
be on user's throat
Re: [gentoo-dev] Retrieve get_libdir path on EAPI 6
Ok. Thank you very much for clarification. And sorry, for next questions I will use gentoo-devhelp ml. G. On Mar 12, 2017 11:08 AM, "Michał Górny" wrote: W dniu 12.03.2017, nie o godzinie 11∶02 +0100, użytkownik Geaaru napisał: > Thanks for replay. But if I try to use it inside my eclass inside my > overlay isn't resolved correctly. I receive an empty string. Could be > related that in my eclass function is not already available? Or related to > a wrong version of some packages? If you are attempting to use it in global scope (i.e. outside phase functions), then it won't work. Such a use is forbidden since it would mean that global variables differ depending on profile being used. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH 2/3] eutils.eclass: prune_libtool_files, make .pc subst errors fatal
W dniu 12.03.2017, nie o godzinie 12∶35 +0100, użytkownik Alexis Ballier
napisał:
> On Sun, 12 Mar 2017 12:00:08 +0100
> Michał Górny wrote:
>
> > Make the substitution errors in prune_libtool_files logic fatal to
> > avoid the dependency of eqawarn. They're extremely unlikely to happen
> > anyway. ---
> > eclass/eutils.eclass | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> > index ab226b236a37..cb472caee1d4 100644
> > --- a/eclass/eutils.eclass
> > +++ b/eclass/eutils.eclass
> > @@ -982,9 +982,10 @@ prune_libtool_files() {
> > for arg in
> > ${libs}; do if [[ ${arg} == -l* ]]; then
> > if
> > [[ ${arg} == '*$*' ]]; then
> > -
> > eqawarn "${FUNCNAME}: variable substitution likely failed in ${pc}"
> > -
> > eqawarn "(arg: ${arg})"
> > -
> > eqawarn "Most likely, you need to add virtual/pkgconfig to DEPEND."
> > +
> > eerror "${FUNCNAME}: variable substitution likely failed in ${pc}"
> > +
> > eerror "(arg: ${arg})"
> > +
> > eerror "Most likely, you need to add virtual/pkgconfig to DEPEND."
> > +
> > die "${FUNCNAME}: unsubstituted variable found in .pc" fi
>
> If you go that way then it would be best if this function had a
> 'has "virtual/pkgconfig" ${DEPEND} || die ...' kind of logic
You can't reliably query DEPEND in an ebuild.
> the message is more intended towards package maintainer and i would
> assume they have pkgconfig installed which means the failure will
> be on user's throat
...in the extremely unlikely case of not having pkg-config installed.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/3] eutils.eclass: prune_libtool_files, make .pc subst errors fatal
On Sun, 12 Mar 2017 13:20:18 +0100
Michał Górny wrote:
> > If you go that way then it would be best if this function had a
> > 'has "virtual/pkgconfig" ${DEPEND} || die ...' kind of logic
>
> You can't reliably query DEPEND in an ebuild.
yeah i though so
> > the message is more intended towards package maintainer and i would
> > assume they have pkgconfig installed which means the failure will
> > be on user's throat
>
> ...in the extremely unlikely case of not having pkg-config installed.
... that has far greater chances to be hit by an user than a
developer :)
[gentoo-dev] Last rites: app-i18n/x-unikey
# David Seifert (12 Mar 2017) # Awful codebase, lots of widechars stored in chars, # invokes undefined behaviour, last release in 2004. # Masked for removal in 30 days. Bug #593976. app-i18n/x-unikey
[gentoo-dev] Last rites: www-plugins/nspluginwrapper
# David Seifert (12 Mar 2017) # Bundles half of glibc, unmaintained upstream, # not really necessary anymore with 64-bit flash # Masked for removal in 30 days. Bug #609258. www-plugins/nspluginwrapper
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 2017.03.11 20:50, Kristian Fiskerstrand wrote: > A draft of a Pre-GLEP for the Security project is available for > reading > at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access in order to ensure proper accountability (c.f GLEP 48 > for QA and still non-produced GLEP for ComRel (I've started working on > this and will be presenting this one later as current ComRel Lead)) > > Comments, patches, threats, etc welcome > > -- > Kristian Fiskerstrand > OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net > fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 > > Kristian, First of all, thank you. We have needed something like this for several projects, for some time. A few odds and ends. Why do Security Project members need to be ebuild devs? Non ebuild developers can contribute by producing GLSAs, for example. Who manages the Security Project (from outside). It appears from the draft GLEP, nobody. That means that the project could become moribund and nobody would notice. Its not like Gentoo enforces or even checks for leadership elections. That's an anual event anyway, so its not a measure of a projects continued well being. Compare the Security Project to council, that have a monthly showing of project health. Projects tend to be left alone. Gentoo has several projects that appear to be unmanaged but cannot be permitted to die out. This is one. Who takes the Security Projects pulse and how? A periodic automated message to -dev that all Security Project members "reply to list" is both public and mimnimally invasive. Its no more than 'roll call'. Now the hard one, who does what when there is no pulse from the Security Project? This isn't really a Security Project issue. If its ever needed, the Security Project isn't active. It affects other projects too, like comrel, QA and others. Perhaps there is a common solution to taking a proqcts pulse and reacting when there is none. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpQAiSAKWYXf.pgp Description: PGP signature
[gentoo-dev] Last rites: app-text/uvconv
# David Seifert (12 Mar 2017) # Awful codebase, lots of widechars stored in chars, # invokes undefined behaviour, last release in 2004. # Masked for removal in 30 days. Bug #593942, #593976. app-text/uvconv
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 03/12/2017 07:11 PM, Roy Bamford wrote: > > Why do Security Project members need to be ebuild devs? > Non ebuild developers can contribute by producing GLSAs, > for example. Where is that requirement stated? > > Who manages the Security Project (from outside). It appears from > the draft GLEP, nobody. That means that the project could become > moribund and nobody would notice. Its not like Gentoo enforces > or even checks for leadership elections. That's an anual event > anyway, so its not a measure of a projects continued well being. > Imposing too much bureaucracy and reporting might not be worthwhile, the security project's work is relatively easy to monitor in bugzilla activity and GLSA publication to begin with, less so for auditing, but that has always been specific to available resources. > > This isn't really a Security Project issue. If its ever needed, the > Security Project isn't active. It affects other projects too, like > comrel, QA and others. Perhaps there is a common solution > to taking a proqcts pulse and reacting when there is none. > Talking with the lead of respective projects should be a good start without need for specific procedures. One could imagine participation from various special projects in council meetings or just email exchanges, but it'd likely just end up with a bunch of "nothing new from the western front" that can more easily just be updated informally anyways if anyone is concerned. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 03/12/2017 03:55 AM, Rich Freeman wrote: > On Sat, Mar 11, 2017 at 6:54 PM, Kristian Fiskerstrand > wrote: >> On 03/11/2017 11:23 PM, Andrew Savchenko wrote: >>> >>> My point is that users must be informed about security problem, but >>> they still should have a choice. So it should be either a rule >>> "mask without removal" or clear guidelines when to remove a >>> package and when to not. >> >> At some point, of a package does not belong in the main tree due to >> security vulnerabilities, they can still be kept in an overlay by a >> respective project without it impacting other users. I'm not convinced >> that impacts the overall user experience of other Gentoo users. >> > > Is there any reason that this can't be left to maintainer discretion? > The package is masked and clearly advertises its security issue. The > user can make an informed choice. Do we really need to force the > issue further? What is the benefit to Gentoo in doing so? > In most cases lack of maintainer participation is likely the issue to begin with. The primary issue with a package mask of this nature is that it is more permanent than temporary in nature. To what extent would other package maintainers need to take it into consideration e.g wrt depgraph breakages (say this is a lower slotted version or last version that supports a specific arch). Granted that isn't much of an issue from the security point of view, but goes more over on QA - the primary reason it isn't explicit in the draft GLEP is that specific rules are difficult to write to cover all situations and as such needs either a lot of preparation to write or will cause issues down the line. The accountability aspects of things is therefore more important than the rules themselves. Quite frankly I thought I left enough of maintainer discretion when stating: * The Security Project does not want to override the maintainer's autonomy, but if inactive might be required to fix a security vulnerability by means of version bump or application of a patch in a revision bump. * If a vulnerability is unlikely to be fixed by upstream or the package's maintainer it might require a package mask. Such mask should never break the stable dependency tree. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 03/12/2017 07:19 AM, Walter Dnes wrote: > - Typo... > Additional Security Project bugzilla notes > * The Security Project is except (should that read "exempt"?) Thanks, fixed > > > > - An intermediate level before masking might be issuing a warning if > some simple, specific remediation measure can protect against a > vulnerability. E.g. forcing cups to only listen to 127.0.0.1 or :1 Mitigations like these are mentioned in the GLSA > > - If you want to absolutely ensure that people are warned of a severe, > but remediable vulnerability, is it acceptable to "break the build" > by requiring a new local USE flag for the ebuild? I'm thinking of > something like "glep_0001234", "glep_0001235", "glep_0001236", etc, > and have the ebuild die if the flag is not set, and print out a URL > for a security problem. This could be abstracted to make.conf with > a new variable... > > GLEP="0001234 0001235 0001236 etc etc" Sounds like a lot of complexity for limited value. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On Sun, Mar 12, 2017 at 2:45 PM, Kristian Fiskerstrand wrote: > > In most cases lack of maintainer participation is likely the issue to > begin with. The primary issue with a package mask of this nature is that > it is more permanent than temporary in nature. To what extent would > other package maintainers need to take it into consideration e.g wrt > depgraph breakages (say this is a lower slotted version or last version > that supports a specific arch). > > Granted that isn't much of an issue from the security point of view, but > goes more over on QA. Sure, and if a package like this becomes a blocker then that would be a reason to remove it. The fact that it has a security issue is actually irrelevant to that decision. -- Rich
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 03/12/2017 09:14 AM, Alexis Ballier wrote: > Most of it seems more appropriate for a project page to me and up to > the sec. team, so I'll comment on the global parts only. > > The only global part I see is the "Security package version/revision > bumps and package masks". This one would benefit from a proper > definition of the rules here: If severity is X then inactive is defined > to be Y days. After that, sec. team can fix themselves. It should also > be the same for masking: If severity is X and no fix is known after Y > days/months then sec. team should mask it (but not last rite it, this > should still be maintainer/treecleaners). The severity levels and timelines are already defined in the referenced vulnerability treatment policy. We might be able to incorporate this suggestion by stronger reference to that for timeline, but in the end that should be the internal policy anyways. In general I would prefer the GLSA to be more higher level as we know things are going to need to be updated from time to time on these matters. > > I think the delay should be clearly stated in the bug with something > like: Please keep in mind that since this is a remote code execution > vulnerability, security team will take action if nothing happens within > one week. If you have tools filling the severity fields then a proper > definition allows to automate this too. > > My point here is to avoid having all the responsibility falling under > the lead but focus more on getting things done and educating fellow > developers: Lower delays for more serious bugs will make people > understand and prioritize better the issues at hand and their > implications. The lead sets policies and is responsible for keeping vulnerability treatment policy and other documentation up to date c.f Documentation of process The Project shall have procedures in place to document its process and regularly update the documentation including the Vulnerability Treatment Policies[3]. ^^ which was intended to cover some of these concerns > > > Also, it'd be nice to have something more formal for sec. cleanup: > "After 30 days a sec. issue has been fixed, sec. team is free to > cleanup old vulnerable versions.". I've seen too much pings by sec. > team members on old bugs for this and they could have spent the same > amount of time simply doing it instead. This presumes all security members are gentoo developers with tree access and can do it themselves, but I'm not convinced cleanups are vital enough for security to interact as it requires quite a bit of work for an unfamiliar package to know which files to remove in files/ for specific versions and/or other package-specific quirks. The package maintainers really should be able to handle this or hand off the package to someone else. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On Sun, 12 Mar 2017 19:59:11 +0100 Kristian Fiskerstrand wrote: > On 03/12/2017 09:14 AM, Alexis Ballier wrote: > > Most of it seems more appropriate for a project page to me and up to > > the sec. team, so I'll comment on the global parts only. > > > > The only global part I see is the "Security package version/revision > > bumps and package masks". This one would benefit from a proper > > definition of the rules here: If severity is X then inactive is > > defined to be Y days. After that, sec. team can fix themselves. It > > should also be the same for masking: If severity is X and no fix is > > known after Y days/months then sec. team should mask it (but not > > last rite it, this should still be maintainer/treecleaners). > > The severity levels and timelines are already defined in the > referenced vulnerability treatment policy. We might be able to > incorporate this suggestion by stronger reference to that for > timeline, but in the end that should be the internal policy anyways. To me, this is the only thing that is *not* internal here. You have a target delay X. What happens after X expires ? After 2X ? 10X ? When is it right for sec. team to intervene ? When is it right for sec. team to intervene after maintainer has asked for a delay ? When is it right for sec. team to intervene against maintainer wishes ? I'm pretty sure you have a good idea of when sec. team should act, and you're right in the sense that severity analysis does not belong to the GLEP, but something referencing your treatment policy and explicitly stating in the GLEP that (any member of) sec. team is allowed to take action after some multiple (possibly one) of the target delay would be more clear and avoid entirely having the lead to take a decision every time. I'm insisting here for various reasons: - It is preferable to have a clear resolution procedure, known in advance, instead of something at someone's discretion that happens to be brought up every time some other one is not happy. - Sometimes sec. masking will be controversial (nethack maybe?), having the lead take all the hate is not fair either. - I would definitely prefer saying about Gentoo: "We do not ship anything that has had a CVE reported for more than a month" than "We do our best to keep your system safe". Also, please keep in mind that for most people A4/A3/B3/B4/etc. are paper sizes :) (so that restating the delay in sec bugs is not wasted electrons) [...] > > Also, it'd be nice to have something more formal for sec. cleanup: > > "After 30 days a sec. issue has been fixed, sec. team is free to > > cleanup old vulnerable versions.". I've seen too much pings by sec. > > team members on old bugs for this and they could have spent the same > > amount of time simply doing it instead. > > This presumes all security members are gentoo developers with tree > access and can do it themselves, but I'm not convinced cleanups are > vital enough for security to interact as it requires quite a bit of > work for an unfamiliar package to know which files to remove in > files/ for specific versions and/or other package-specific quirks. > The package maintainers really should be able to handle this or hand > off the package to someone else. Well, I'm not saying the maintainer should not nor that sec. team must do it themselves, I'm just saying that sec. team can. There are complex cases but the vast majority of security cleanups are no brainers that anyone who has passed the quizzes can do. Alexis.
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 03/12/2017 11:05 PM, Alexis Ballier wrote: >> The severity levels and timelines are already defined in the >> referenced vulnerability treatment policy. We might be able to >> incorporate this suggestion by stronger reference to that for >> timeline, but in the end that should be the internal policy anyways. > > To me, this is the only thing that is *not* internal here. > > You have a target delay X. What happens after X expires ? After 2X ? > 10X ? When is it right for sec. team to intervene ? When is it right > for sec. team to intervene after maintainer has asked for a delay ? When > is it right for sec. team to intervene against maintainer wishes ? > > I'm pretty sure you have a good idea of when sec. team should act, and > you're right in the sense that severity analysis does not belong to the > GLEP, but something referencing your treatment policy and explicitly > stating in the GLEP that (any member of) sec. team is allowed to take > action after some multiple (possibly one) of the target delay would be > more clear and avoid entirely having the lead to take a decision every > time. makes sense, will try to write up some more info on this in GLEP, while still referencing the vulnerability treatment policy for the actual information as that needs to be possible to update from time to time. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On 03/11/2017 11:23 PM, Andrew Savchenko wrote: > While the Deputy may be assigned, this still gives all power to > single hands. Maybe it will be better to establish something like > the Security Project Council (SPC)? E.g. three project members may > be elected to this SPC, so that all serious decisions will require > some team agreement from at least 2 SPC members. This way the > Deputy will not be needed as well. Something like this has been discussed. I personally don't like the approach too much given that it adds a certain degree of bureaucracy and can remove responsibility. An important part of the GLEP is that the project lead is responsible to the council for the changes that is made. Having possibility to overrule that by members would mean that the lead is not able to control the action, and as such, can't be responsible for it. If the members disagree with the lead they can call for re-election as per GLEP:39 already. As discussed in another sub-thread, however, will try to incorporate more of the procedure in the vulnerability treatment policy etc into the GLEP such that procedures are more in focus. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] app-editors/ghostwriter: package up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, The following package is up for grabs: app-editors/ghostwriter - -- gokturk -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJYxdHOAAoJEIT4AuXAiM4zX7wIAKRpd6uqLQDqCX8vWoSWuto/ 8AyGdLfYDZGxNts+nPZZtuG89ykNAx7W8+c+WwoaIuHvQgD1ZOyoIIq+ghp19xng tQme9Ke6iE9DOcf6fUZSPP9GIQ6AzcdWwk9iY7MRGzyCG0oS5aZE9YZbqwD4IMHq 4gYZLVcpWXL6wJesoDFoevH+Nz47vFNMuUZL0zlaeXNVJXY3Hj9/QvhyUJfbUeN2 9uZvp5E0lfM+p25J0b7pZlyaOZwMKJcMBj7374iY2rruB6MP0RCpn2u7mEAlMm0f 8zmWYKvNFU9AJzxLrHHqNW1+uTo5I/6UrrBr7/o8mVyW6sMPN4sArxWUmjOnl+k= =3rgz -END PGP SIGNATURE-
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-03-12 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2017-03-12 23:59 UTC. Removals: app-crypt/cryptkeeper 20170312-21:22 mgorny0625e74f644 dev-libs/safestr 20170312-21:22 mgorny28119e8e8a3 dev-libs/xxl 20170312-21:22 mgornyfaef6b48cd8 dev-perl/Archive-Rar 20170311-22:00 dilfridge 0c280fcd6de dev-php/PEAR-PHP_Shell 20170308-13:12 mjo e0acd95810e dev-python/mwlib 20170312-21:21 mgornyf56a7b6e3bd dev-python/mwlib-rl20170312-21:20 mgorny5aa63a7d6e0 games-rpg/mana 20170312-21:19 mgorny6a39941a49f games-rpg/tmw 20170312-21:16 mgorny4b965518532 Additions: app-misc/freeplane 20170310-11:39 xmw 0f0c11b467b app-misc/timew 20170312-13:07 aidecoe 29f43aa2e5a app-vim/ferret 20170310-21:12 monsieurp 0f3ea282cdc app-vim/vimagit20170307-10:57 radhermit f1a7597c991 dev-lang/gnat-gpl 20170311-20:46 tupone0e7760adbc2 dev-libs/libfmt20170306-20:46 soap a7bb963c619 dev-libs/libmspack 20170306-01:10 reavertm 53e1591b307 dev-ml/ocaml-cohttp20170311-10:31 aballier 218f1f16005 dev-php/doctrine-instantiator 20170309-15:33 grknight 7ef93269fd2 dev-php/myclabs-deepcopy 20170309-15:39 grknight 467b557c602 dev-php/phpdocumentor-reflection-common20170309-15:35 grknight 1bfae2f22a0 dev-php/phpdocumentor-reflection-docblock 20170309-15:37 grknight 294a6d9202e dev-php/phpdocumentor-type-resolver20170309-15:36 grknight 72d99c23987 dev-php/phpspec-prophecy 20170309-15:41 grknight a7100386fb4 dev-php/phpunit-mock-objects 20170309-16:18 grknight 76cc2114317 dev-php/sebastian-code-unit-reverse-lookup 20170309-15:29 grknight c9cd38e7e21 dev-php/sebastian-comparator 20170309-15:27 grknight f6bc67f1625 dev-php/sebastian-diff 20170309-15:26 grknight a4344147b6d dev-php/sebastian-environment 20170309-15:24 grknight 5054d7f897b dev-php/sebastian-exporter 20170309-15:22 grknight 31967bac591 dev-php/sebastian-global-state 20170309-15:21 grknight f055eeabd8f dev-php/sebastian-object-enumerator20170309-15:19 grknight c2eb2b6bf3e dev-php/sebastian-recursion-context20170309-15:18 grknight be3acfa0bb7 dev-php/sebastian-resource-operations 20170309-15:16 grknight 3361d878f1c dev-php/sebastian-version 20170309-15:15 grknight 5a3b26f0fd6 dev-php/webmozart-assert 20170309-15:14 grknight 06c5bda11ec dev-python/HeapDict20170306-23:24 bicatali d975b18b5a8 dev-python/ipynb 20170307-15:27 soap 3ba2d44c994 dev-python/iso3166 20170208-19:39 monsieurp da0d5255d21 dev-python/iso_639 20170208-19:42 monsieurp 03814c53dbb dev-python/matplotlib2tikz 20170308-13:02 soap 9bfccc11164 dev-python/pydotplus 20170213-23:52 gokturk 101f920c2b7 dev-python/sortedcollections 20170306-23:08 bicatali f4e58189a64 dev-python/sortedcontainers20170306-22:30 bicatali a06e6a36af1 dev-python/tblib 20170306-21:28 bicatali d44f151ca14 dev-python/zstandard 20170308-15:56 mrueg 4bf9be6de7a dev-util/edb-debugger 20170307-12:22 amynkafbe36fe818b dev-util/lxqt-build-tools 20161123-15:40 monsieurp 322d8e2c43d games-board/tablebase-syzygy 20170309-10:31 ulm 3e304757f36 gnustep-apps/ftp 20170312-17:08 voyageur 11de47aea1a gnustep-apps/talksoup 20170312-16:59 voyageur 866c6241fc7 net-libs/ntirpc20170306-18:15 vapierf56569afdbb x11-misc/xowl 20170311-09:11 jer 9aa74a41070 x11-plugins/enigmail 20170309-01:03 axs 4fb9b596f42 x11-wm/xoat20170311-08:53 jer 6c34a869337 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-libs/safestr,removed,mgorny,20170312-21:22,28119e8e8a3 dev-libs/xxl,removed,mgorny,20170312-21:22,faef6b48cd8 app-crypt/cryptkeeper,removed,mgorny,20170312-21:22,0625e74f644 dev-python/mwlib,removed,mgorny,20170312-21:21,f56a7b6e3bd dev-python/mwlib-rl,removed,mgorny,20170312-21:20,5aa63a7d6e0 games-rpg/mana,removed,mgorny,20170312-21:19,6a39941a49f games-rpg
Re: [gentoo-dev] RFC: Pre-GLEP: Security Project
On Sun, Mar 12, 2017 at 02:54:22PM -0400, Rich Freeman wrote: > On Sun, Mar 12, 2017 at 2:45 PM, Kristian Fiskerstrand > wrote: > > > > In most cases lack of maintainer participation is likely the issue to > > begin with. The primary issue with a package mask of this nature is that > > it is more permanent than temporary in nature. To what extent would > > other package maintainers need to take it into consideration e.g wrt > > depgraph breakages (say this is a lower slotted version or last version > > that supports a specific arch). > > > > Granted that isn't much of an issue from the security point of view, but > > goes more over on QA. > > Sure, and if a package like this becomes a blocker then that would be > a reason to remove it. > > The fact that it has a security issue is actually irrelevant to that decision. I disagree with this argument. A security issue *is* a problem, especially if we are masking the package because of the security issue. imo to increase the quality of the tree, packages with known, unfixable security issues belong in overlays, not in the main tree. William signature.asc Description: Digital signature
