Re: [gentoo-dev] Re: News item: GRUB security update

[Dale]

Rich Freeman wrote:
> On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  
> wrote:
>> Hi,
>>
>> On 18.12.2015 21:06, Mike Gilbert wrote:
>>> Hi, please review the news item below.
>> thanks for drafting this news item. However, the usual way to inform
>> users about security flaws is by sending a GLSA. :)
>>
>> Based on your news item, we have drafted a GLSA now. It's currently
>> pending review by one other member of the security team and we will send
>> it in a few hours.
>>
> << SNIP >>
> 2.  Users probably don't regularly read GLSAs, since for the most part
> it just tells them to update packages they've probably already
> updated.  How do we make ones that actually have instructions beyond
> updating stand out?
>
> I know I stopped reading GLSAs ages ago, because they tended to tell
> me to update to a package I had updated to a week before, and when
> they said something else 90% of the time it was because there was an
> error in the GLSA (usually this happened with subslots and the GLSA
> just said  of ranges that were vulnerable vs fixed).  Granted, I have caught one
> or two episodes over the years where the actual package might not have
> been completely addressed and an older slot needed fixing.
>
> I guess my point isn't that GLSAs are a bad thing, but users need a
> really high S/N ratio if we want them to pay attention.  We need to
> separate the mundane from the important.
>


+1.  Given all the changes that have been done, I don't even know how to
read them any more because I stopped a long time ago. 

I might add, I also don't read blogs about this sort of thing.  About
the only time I read a blog is if it is linked to here or on -user. 
Other than that, rarely if ever. 

All things considered, if it isn't a news item or something I follow on
this list, I may never know about it.  I really depend on the news
items.  Just keep the noise down or folks will start to ignore them too,
although y'all are good at it only telling us about things that affect us.

Dale

:-)  :-) 

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Michał Górny]

On Sat, 19 Dec 2015 21:17:26 +0100
Ulrich Mueller  wrote:

> > On Sat, 19 Dec 2015, Michał Górny wrote:  
> 
> >   read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"  
> 
> > This performs word splitting into an array. Then you can do:  
> 
> >   echo -e "${DOC_CONTENTS[*]}" | ...  
> 
> The first line fails for me:
> 
> $ DOC_CONTENTS="test"
> $ read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"
> $ echo $?
> 1
> 
> (I guess it is encountering EOF on the temporary file created by the
> string redirection, but how would one distinguish this from other
> errors?)

read's return code indicates whether if found a full line (with
a newline). read can't really fail.

> Besides, it is hard to understand what this code does, as compared to
> the "set -f" solution.

Many pieces of good code are harder to understand than cheap, ugly
hacks. That's why those hacks are so common, and people meet them all
the time and never learn good code.

-- 
Best regards,
Michał Górny



pgpOxiRpJgEbu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Michał Górny]

On Sat, 19 Dec 2015 18:18:43 +0100
Ulrich Mueller  wrote:

> Here is a change to readme.gentoo-r1.eclass, as discussed with pacho.
> The eclass currently inherits eutils for shell flag saving, which
> seems like overkill (especially in EAPI 6). Replace this by a more
> lightweight approach.
> 
> Ulrich
> 
> 
> From b1f6de1e005d1cbcc9f2cfff281ad7d1d176fd31 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
> Date: Sat, 19 Dec 2015 15:15:05 +0100
> Subject: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.
> 
> This was only needed in readme.gentoo_create_doc() for a single call
> of eshopts_{push,pop}. Replace it by saving the set of options in a
> variable. Die if writing the temp file in readme.gentoo_create_doc()
> fails.
> ---
>  eclass/readme.gentoo-r1.eclass | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
> index c076650..07320c0 100644
> --- a/eclass/readme.gentoo-r1.eclass
> +++ b/eclass/readme.gentoo-r1.eclass
> @@ -21,8 +21,6 @@
>  if [[ -z ${_README_GENTOO_ECLASS} ]]; then
>  _README_GENTOO_ECLASS=1
>  
> -inherit eutils
> -
>  case "${EAPI:-0}" in
>   0|1|2|3)
>   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> @@ -61,15 +59,16 @@ readme.gentoo_create_doc() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   if [[ -n "${DOC_CONTENTS}" ]]; then
> - eshopts_push
> - set -f
>   if [[ -n "${DISABLE_AUTOFORMATTING}" ]]; then
> - echo "${DOC_CONTENTS}" > "${T}"/README.gentoo
> + echo "${DOC_CONTENTS}" > "${T}"/README.gentoo || die
>   else
> + local saved_flags=$-
> + set -f  # disable filename 
> expansion in echo arguments
>   echo -e ${DOC_CONTENTS} | fold -s -w 70 \
>   | sed 's/[[:space:]]*$//' > "${T}"/README.gentoo

Maybe I'm missing something but is there any reason not to quote
"${DOC_CONTENTS}" instead of working around the results of not quoting
it?

> + assert
> + set +f -${saved_flags}
>   fi
> - eshopts_pop
>   elif [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]]; then
>   cp "${FILESDIR}/README.gentoo-${SLOT%/*}" "${T}"/README.gentoo 
> || die
>   elif [[ -f "${FILESDIR}/README.gentoo${README_GENTOO_SUFFIX}" ]]; then



-- 
Best regards,
Michał Górny



pgpva2TPSPpav.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Ulrich Mueller]

Here is a change to readme.gentoo-r1.eclass, as discussed with pacho.
The eclass currently inherits eutils for shell flag saving, which
seems like overkill (especially in EAPI 6). Replace this by a more
lightweight approach.

Ulrich


From b1f6de1e005d1cbcc9f2cfff281ad7d1d176fd31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Sat, 19 Dec 2015 15:15:05 +0100
Subject: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

This was only needed in readme.gentoo_create_doc() for a single call
of eshopts_{push,pop}. Replace it by saving the set of options in a
variable. Die if writing the temp file in readme.gentoo_create_doc()
fails.
---
 eclass/readme.gentoo-r1.eclass | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/eclass/readme.gentoo-r1.eclass b/eclass/readme.gentoo-r1.eclass
index c076650..07320c0 100644
--- a/eclass/readme.gentoo-r1.eclass
+++ b/eclass/readme.gentoo-r1.eclass
@@ -21,8 +21,6 @@
 if [[ -z ${_README_GENTOO_ECLASS} ]]; then
 _README_GENTOO_ECLASS=1
 
-inherit eutils
-
 case "${EAPI:-0}" in
0|1|2|3)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
@@ -61,15 +59,16 @@ readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} "${@}"
 
if [[ -n "${DOC_CONTENTS}" ]]; then
-   eshopts_push
-   set -f
if [[ -n "${DISABLE_AUTOFORMATTING}" ]]; then
-   echo "${DOC_CONTENTS}" > "${T}"/README.gentoo
+   echo "${DOC_CONTENTS}" > "${T}"/README.gentoo || die
else
+   local saved_flags=$-
+   set -f  # disable filename 
expansion in echo arguments
echo -e ${DOC_CONTENTS} | fold -s -w 70 \
| sed 's/[[:space:]]*$//' > "${T}"/README.gentoo
+   assert
+   set +f -${saved_flags}
fi
-   eshopts_pop
elif [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]]; then
cp "${FILESDIR}/README.gentoo-${SLOT%/*}" "${T}"/README.gentoo 
|| die
elif [[ -f "${FILESDIR}/README.gentoo${README_GENTOO_SUFFIX}" ]]; then
-- 
2.6.4


pgpBaNcz68uDy.pgp
Description: PGP signature

Re: [gentoo-dev] Re: News item: GRUB security update

[Mike Gilbert]

On Sat, Dec 19, 2015 at 8:44 AM, Rich Freeman  wrote:
> On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  
> wrote:
>> Hi,
>>
>> On 18.12.2015 21:06, Mike Gilbert wrote:
>>> Hi, please review the news item below.
>>
>> thanks for drafting this news item. However, the usual way to inform
>> users about security flaws is by sending a GLSA. :)
>>
>> Based on your news item, we have drafted a GLSA now. It's currently
>> pending review by one other member of the security team and we will send
>> it in a few hours.
>>
>
> The only concerns I have with this approach are:
> 1.  In this case timing is fine, but sometimes GLSAs have a
> significant delay, especially when minor archs are involved in
> stabilization.
> 2.  Users probably don't regularly read GLSAs, since for the most part
> it just tells them to update packages they've probably already
> updated.  How do we make ones that actually have instructions beyond
> updating stand out?
>
> I know I stopped reading GLSAs ages ago, because they tended to tell
> me to update to a package I had updated to a week before, and when
> they said something else 90% of the time it was because there was an
> error in the GLSA (usually this happened with subslots and the GLSA
> just said  of ranges that were vulnerable vs fixed).  Granted, I have caught one
> or two episodes over the years where the actual package might not have
> been completely addressed and an older slot needed fixing.
>
> I guess my point isn't that GLSAs are a bad thing, but users need a
> really high S/N ratio if we want them to pay attention.  We need to
> separate the mundane from the important.

I had that same thought when keytoaster first replied to this.

Realistically, I suspect very few Gentoo users are using
authentication in GRUB. Those who do are certainly more security
conscious than the average user, and more likely to read GLSAs and
other security announcements.

I think the pkg_postinst message and the GLSA are sufficient coverage
for this issue.

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Ulrich Mueller]

> On Sat, 19 Dec 2015, Michał Górny wrote:

>   read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"

> This performs word splitting into an array. Then you can do:

>   echo -e "${DOC_CONTENTS[*]}" | ...

The first line fails for me:

$ DOC_CONTENTS="test"
$ read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"
$ echo $?
1

(I guess it is encountering EOF on the temporary file created by the
string redirection, but how would one distinguish this from other
errors?)

Besides, it is hard to understand what this code does, as compared to
the "set -f" solution.

Ulrich


pgpwkQkTra60u.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Ulrich Mueller]

> On Sat, 19 Dec 2015, Michał Górny wrote:

>> (I guess it is encountering EOF on the temporary file created by
>> the string redirection, but how would one distinguish this from
>> other errors?)

> read's return code indicates whether if found a full line (with a
> newline). read can't really fail.

Certainly writing or reading the temp file can fail?

>> Besides, it is hard to understand what this code does, as compared
>> to the "set -f" solution.

> Many pieces of good code are harder to understand than cheap, ugly
> hacks. That's why those hacks are so common, and people meet them
> all the time and never learn good code.

Well, compare:

set -f
echo -e ${DOC_CONTENTS} | ...

versus:

read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"
echo -e "${DOC_CONTENTS[*]}" | ...

The second one is (IMHO) harder to understand, less efficient, and
relies on undocumented behaviour.

Ulrich


pgpKGa5qZlTyR.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Michał Górny]

On Sat, 19 Dec 2015 19:24:17 +0100
Ulrich Mueller  wrote:

> > On Sat, 19 Dec 2015, Michał Górny wrote:  
> 
> >> +  set -f  # disable filename 
> >> expansion in echo arguments
> >>echo -e ${DOC_CONTENTS} | fold -s -w 70 \
> >>| sed 's/[[:space:]]*$//' > 
> >> "${T}"/README.gentoo  
> 
> > Maybe I'm missing something but is there any reason not to quote
> > "${DOC_CONTENTS}" instead of working around the results of not
> > quoting it?  
> 
> IIUC the intention of not quoting it is to normalise whitespace,
> especially embedded newlines. Unfortunately, I don't see a good way to
> do this differently. Adding another processing step after echo -e is
> too late, because newlines expanded from \n must be kept.

  read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"

This performs word splitting into an array. Then you can do:

  echo -e "${DOC_CONTENTS[*]}" | ...

-- 
Best regards,
Michał Górny



pgpLXLRlgsTvE.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Martin Vaeth]

Michał Górny  wrote:
>>  if [[ -n "${DISABLE_AUTOFORMATTING}" ]]; then
>>  echo "${DOC_CONTENTS}" > "${T}"/README.gentoo || die
>>  else
>>  echo -e ${DOC_CONTENTS} | fold -s -w 70 \
>>  | sed 's/[[:space:]]*$//' > "${T}"/README.gentoo

(omitted some lines/space for better context):

> Maybe I'm missing something but is there any reason not to quote
> "${DOC_CONTENTS}" instead of working around the results of not quoting
> it?

With DISABLE_AUTOFORMATTING=true, it is correctly quoted,
and there is no "workaround".
Without DISABLE_AUTOFORMATTING, the autowrapping (and ignoring
of "manual" format information by not quoting) is obviously
intentional.
Maybe, it would be more natural to have the opposite as the default,
but this is how the eclass works from its very beginning.

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Ulrich Mueller]

> On Sat, 19 Dec 2015, Michał Górny wrote:

>> +set -f  # disable filename 
>> expansion in echo arguments
>>  echo -e ${DOC_CONTENTS} | fold -s -w 70 \
>>  | sed 's/[[:space:]]*$//' > "${T}"/README.gentoo

> Maybe I'm missing something but is there any reason not to quote
> "${DOC_CONTENTS}" instead of working around the results of not
> quoting it?

IIUC the intention of not quoting it is to normalise whitespace,
especially embedded newlines. Unfortunately, I don't see a good way to
do this differently. Adding another processing step after echo -e is
too late, because newlines expanded from \n must be kept.

Ulrich


pgpl1aJOf8zre.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Michał Górny]

On Sat, 19 Dec 2015 23:51:47 +0100
Ulrich Mueller  wrote:

> > On Sat, 19 Dec 2015, Michał Górny wrote:  
> 
> >> (I guess it is encountering EOF on the temporary file created by
> >> the string redirection, but how would one distinguish this from
> >> other errors?)  
> 
> > read's return code indicates whether if found a full line (with a
> > newline). read can't really fail.  
> 
> Certainly writing or reading the temp file can fail?
> 
> >> Besides, it is hard to understand what this code does, as compared
> >> to the "set -f" solution.  
> 
> > Many pieces of good code are harder to understand than cheap, ugly
> > hacks. That's why those hacks are so common, and people meet them
> > all the time and never learn good code.  
> 
> Well, compare:
> 
> set -f
> echo -e ${DOC_CONTENTS} | ...
> 
> versus:
> 
> read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"
> echo -e "${DOC_CONTENTS[*]}" | ...
> 
> The second one is (IMHO) harder to understand, less efficient, and
> relies on undocumented behaviour.

On WHAT?!

-- 
Best regards,
Michał Górny



pgpYCZakBWldT.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Ulrich Mueller]

> On Sat, 19 Dec 2015, Michał Górny wrote:

>> set -f
>> echo -e ${DOC_CONTENTS} | ...
>> 
>> versus:
>> 
>> read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}"
>> echo -e "${DOC_CONTENTS[*]}" | ...
>> 
>> The second one is (IMHO) harder to understand, less efficient, and
>> relies on undocumented behaviour.

> On WHAT?!

Documentation of the read command doesn't specify behaviour for an
empty argument of the -d option:

`-d DELIM'
  The first character of DELIM is used to terminate the input
  line, rather than newline.

Ulrich


pgpDiajpZBeSN.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] egencache: add --stable-mtime option

[Brian Dolbec]

On Sat, 19 Dec 2015 15:51:29 -0800
Zac Medico  wrote:

> On 12/16/2015 09:49 AM, Michał Górny wrote:
> > On Wed, 16 Dec 2015 14:38:03 +0100
> > Alexander Berntsen  wrote:
> >   
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> On 16/12/15 06:33, Zac Medico wrote:  
> >>> Disable Manifest "stable mtime" behavior by default, and add a
> >>> corresponding egencache option.
> >> This message tells me nothing about why we need to do this.  
> > 
> > We need do this because we changed the behavior and the new
> > behavior is counter-intuitive. We already had a number of bugs
> > caused by it, and while it's used by Infra, it's at least
> > unexpected when someone manually runs 'repoman manifest'.  
> 
> Just because it was historically buggy does not mean that it will
> always be that way. I believe that it will be very safe once we've
> fixed it to include the mtimes of all relevant directories in the max
> mtime calculation.
> 
> > I mean, before this all started 'repoman manifest' just updated
> > the Manifest which meant it's mtime changed. Nowadays, it also sets
> > mtime to some value in the past, which means running 'repoman
> > manifest' may result in updated Manifest having mtime older than
> > the old Manifest. As a result, people using rsync are in trouble.
> > And this has been reported too by overlay owners.  
> 
> We should get our facts straight. It's not possible for the updated
> Manifest to have an older mtime than the old manifest, because the
> mtime of the old Manfiest is included in the max mtime calculation.


I'm generally in favour of this one, infra is changing how they
generate the Changelogs, etc.  So, making this an option makes sense
to me.  
-- 
Brian Dolbec 

Re: [gentoo-portage-dev] [PATCH] egencache: add --stable-mtime option

[Zac Medico]

On 12/16/2015 09:49 AM, Michał Górny wrote:
> On Wed, 16 Dec 2015 14:38:03 +0100
> Alexander Berntsen  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 16/12/15 06:33, Zac Medico wrote:
>>> Disable Manifest "stable mtime" behavior by default, and add a
>>> corresponding egencache option.  
>> This message tells me nothing about why we need to do this.
> 
> We need do this because we changed the behavior and the new behavior is
> counter-intuitive. We already had a number of bugs caused by it,
> and while it's used by Infra, it's at least unexpected when someone
> manually runs 'repoman manifest'.

Just because it was historically buggy does not mean that it will always
be that way. I believe that it will be very safe once we've fixed it to
include the mtimes of all relevant directories in the max mtime calculation.

> I mean, before this all started 'repoman manifest' just updated
> the Manifest which meant it's mtime changed. Nowadays, it also sets
> mtime to some value in the past, which means running 'repoman manifest'
> may result in updated Manifest having mtime older than the old
> Manifest. As a result, people using rsync are in trouble. And this has
> been reported too by overlay owners.

We should get our facts straight. It's not possible for the updated
Manifest to have an older mtime than the old manifest, because the mtime
of the old Manfiest is included in the max mtime calculation.
-- 
Thanks,
Zac

[gentoo-dev] [PATCH] elisp.eclass: Support EAPI 6.

[Ulrich Mueller]

Nothing exciting there, basically s/epatch/eapply/ and don't inherit
eutils in EAPI 6.

I'll commit this tomorrow unless someone will point out a bug.

Ulrich


From 37929a17e2e3977b6f811915e6ef23f557c0f241 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Sat, 19 Dec 2015 13:08:36 +0100
Subject: [PATCH] elisp.eclass: Support EAPI 6.

---
 eclass/elisp.eclass | 35 +--
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index 1178880..93a7d4b 100644
--- a/eclass/elisp.eclass
+++ b/eclass/elisp.eclass
@@ -65,13 +65,21 @@
 # DOCS="blah.txt ChangeLog" is automatically used to install the given
 # files by dodoc in src_install().
 
-inherit elisp-common eutils
+inherit elisp-common
 
 case ${EAPI:-0} in
-   0|1) EXPORT_FUNCTIONS src_{unpack,compile,install} \
-   pkg_{setup,postinst,postrm} ;;
-   *) EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} \
-   pkg_{setup,postinst,postrm} ;;
+   0|1)
+   inherit eutils
+   EXPORT_FUNCTIONS src_{unpack,compile,install} \
+   pkg_{setup,postinst,postrm} ;;
+   2|3|4|5)
+   inherit eutils
+   EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} 
\
+   pkg_{setup,postinst,postrm} ;;
+   6)
+   EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} 
\
+   pkg_{setup,postinst,postrm} ;;
+   *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
 esac
 
 DEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
@@ -117,21 +125,28 @@ elisp_src_unpack() {
 # for in the current working dir, WORKDIR, and FILESDIR.
 
 elisp_src_prepare() {
-   local patch
+   local patch file
for patch in ${ELISP_PATCHES}; do
if [[ -f ${patch} ]]; then
-   epatch "${patch}"
+   file="${patch}"
elif [[ -f ${WORKDIR}/${patch} ]]; then
-   epatch "${WORKDIR}/${patch}"
+   file="${WORKDIR}/${patch}"
elif [[ -f ${FILESDIR}/${patch} ]]; then
-   epatch "${FILESDIR}/${patch}"
+   file="${FILESDIR}/${patch}"
else
die "Cannot find ${patch}"
fi
+   case ${EAPI:-0} in
+   0|1|2|3|4|5) epatch "${file}" ;;
+   6) eapply "${file}" ;;
+   esac
done
 
# apply any user patches
-   epatch_user
+   case ${EAPI:-0} in
+   0|1|2|3|4|5) epatch_user ;;
+   6) eapply_user ;;
+   esac
 
if [[ -n ${ELISP_REMOVE} ]]; then
rm ${ELISP_REMOVE} || die
-- 
2.6.4


pgpIH3NldUEXn.pgp
Description: PGP signature

[gentoo-dev] Re: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.

[Jonathan Callen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/19/2015 05:56 PM, Michał Górny wrote:
> On Sat, 19 Dec 2015 23:51:47 +0100 Ulrich Mueller 
> wrote:
> 
>>> On Sat, 19 Dec 2015, Michał Górny wrote:
>> 
 (I guess it is encountering EOF on the temporary file created
 by the string redirection, but how would one distinguish this
 from other errors?)
>> 
>>> read's return code indicates whether if found a full line (with
>>> a newline). read can't really fail.
>> 
>> Certainly writing or reading the temp file can fail?
>> 
 Besides, it is hard to understand what this code does, as
 compared to the "set -f" solution.
>> 
>>> Many pieces of good code are harder to understand than cheap,
>>> ugly hacks. That's why those hacks are so common, and people
>>> meet them all the time and never learn good code.
>> 
>> Well, compare:
>> 
>> set -f echo -e ${DOC_CONTENTS} | ...
>> 
>> versus:
>> 
>> read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}" echo -e
>> "${DOC_CONTENTS[*]}" | ...
>> 
>> The second one is (IMHO) harder to understand, less efficient,
>> and relies on undocumented behaviour.
> 
> On WHAT?!
> 

Apparently, bash(1) and bash.info don't document what it means to pass
an empty string as the argument to the -d option of the read builtin
(what actually happens is that in all cases, bash uses the first
character of the C string that the option gets translated to, which is
'\0' for the empty string; the documentation just refers to "the first
character of the string passed").

- -- 
Jonathan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWdeydAAoJEEIQbvYRB3mgnQ4P+gP6WHxcyb6PZaBo8EG3nj/i
I5mbIs4XSsp4G13SVm54nTQelPzDlDLtMsRqdAj5Oh+oXrCyLLFcUKSpUf/1laNG
z7pzY6FStgFm1MZWAajtw16xr1+tAbkmGbGy/6pYvSVu7yNiI1n/P+2tBij6e6rN
cOeLtqRGfb1M0Ew3Py2qKVmWYf+/YxH6AkwFZGBZRcb+q3lCSZ9Ycbk3GRBStZwG
wi3PAf6nnuEaouuk7GA33Fi35cmHs8MISVIC70ULakOTu51xHm7aVJCzZQQIFl9N
WvH04+IMCcX+BleU6mP4LK0NB647WwKR8JWgcl8qj2415RvvImCtE35bhnpJbf92
PcVP1l4NJzbUUyfXMDZBpvxzXMHTz2DA4b9PS5Mq8jhiA1jKqAWFD5BBG05SHyrA
IpD0CKipLUFsXyJ5z/MS0gmUFFwymhB+dBVtKOqa4a4s40H2qahY3ffyn/MzIx52
imAYb7IK4MqCPQrzr9nM7qf7UApyLEaQDjN5n+bJ4ZEEd+p3kdf2sVrAFdTom0SU
hXmF1+7TCW4pVB6kL35YbtJkKQbHPfXTHVAJ/ctsLMMNNzXSiKUdnlCV+CwWfrgC
ptMy/Rk7WoHssyQZgl83JsQBdz396j0M6M3+kUNSGFThCz3OF9YBAccrKy7gqeHr
cyg+QQQN4yNyFaWl7S9a
=5O6Z
-END PGP SIGNATURE-

[gentoo-dev] Re: News item: GRUB security update

[Tobias Heinlein]

Hi,

On 18.12.2015 21:06, Mike Gilbert wrote:
> Hi, please review the news item below.

thanks for drafting this news item. However, the usual way to inform
users about security flaws is by sending a GLSA. :)

Based on your news item, we have drafted a GLSA now. It's currently
pending review by one other member of the security team and we will send
it in a few hours.

Thanks!

Cheers,
Tobias



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item: GRUB security update

[Rich Freeman]

On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  wrote:
> Hi,
>
> On 18.12.2015 21:06, Mike Gilbert wrote:
>> Hi, please review the news item below.
>
> thanks for drafting this news item. However, the usual way to inform
> users about security flaws is by sending a GLSA. :)
>
> Based on your news item, we have drafted a GLSA now. It's currently
> pending review by one other member of the security team and we will send
> it in a few hours.
>

The only concerns I have with this approach are:
1.  In this case timing is fine, but sometimes GLSAs have a
significant delay, especially when minor archs are involved in
stabilization.
2.  Users probably don't regularly read GLSAs, since for the most part
it just tells them to update packages they've probably already
updated.  How do we make ones that actually have instructions beyond
updating stand out?

I know I stopped reading GLSAs ages ago, because they tended to tell
me to update to a package I had updated to a week before, and when
they said something else 90% of the time it was because there was an
error in the GLSA (usually this happened with subslots and the GLSA
just said 

[gentoo-dev] Re: News item: GRUB security update

[Kristian Fiskerstrand]

On 12/19/2015 02:44 PM, Rich Freeman wrote:
> On Sat, Dec 19, 2015 at 8:24 AM, Tobias Heinlein  
> wrote:
>> Hi,
>>
>> On 18.12.2015 21:06, Mike Gilbert wrote:
>>> Hi, please review the news item below.
>>


..

> 
> I guess my point isn't that GLSAs are a bad thing, but users need a
> really high S/N ratio if we want them to pay attention.  We need to
> separate the mundane from the important.
> 

This sounds like something that might be appropriate for gentoo blog  of
some sort (GWN on a more ad-hoc basis?) linking to the GLSA. Even a blog
in private blog as part of Planet Gentoo would likely work (but official
blog would work nicer).

-- 
Kristian Fiskerstrand
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature