Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
On Sun, Aug 20, 2017 at 12:39 AM, R0b0t1 wrote: > On Sat, Aug 19, 2017 at 6:34 AM, Francisco Blas Izquierdo Riera > (klondike) wrote: >> El 19/08/17 a las 13:18, Aaron W. Swenson escribió: >>> On 2017-08-19 13:01, Francisco Blas Izquierdo Riera (klondike) wrote: El 19/08/17 a las 12:37, Aaron W. Swenson escribió: > On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote: >> Hi! >> >> I'd like to get this one up by Saturday so that we can proceed with >> masking and removing of the hardened-sources after upstream stopped >> releasing new patches. > I hope I’m not too late. > >> We'd like to note that all the userspace hardening and MAC support >> for SELinux provided by Gentoo Hardened will still remain there and >> is unaffected by this removal. > Where is there? I think you’re talking about the packages, but the news > item is about the kernels. It would help to be more specific here. > > That’s all I had that the others hadn’t touched on. Do you think something like that is better then? We'd like to note that all the userspace hardening and MAC support for SELinux provided by Gentoo Hardened will still remain available on the portage. Keep in mind though that the security provided by these features will be weakened a bit when using sys-kernel/gentoo-sources. Also, all PaX related packages other than the hardened-sources will remain available for the time being. >>> Much better. We should mention that we’re specifically discussing >>> packages and not portage itself. At least, that’s my understanding from >>> your edit. >>> >>> Here’s my take on it: >>> >>> We'd like to note that all the userspace hardening and MAC support for >>> SELinux provided by Gentoo Hardened will still remain in the packages >>> found in portage. Keep in mind, though, that the security provided by >>> these features will be weakened a bit when using >>> sys-kernel/gentoo-sources. Also, all PaX related packages, except >>> sys-kernel/hardened-sources, will remain available for the time being. >> >> I updated the news item with your propossal. Thanks a lot :) >> > > The discussion is nice but no one has actually touched on the > technical merits of removing the packages besides "they are old." > There's plenty of old software in portage. Why not remove it first? > > I had a similar issue with the GCC developer who removed GCJ support. > I asked him for any justification at all for the removal and he had > none but some vague statements about it creating work. I would have > taken any more specific example he gave at face value, but he didn't > want to give one. I was left to conclude he didn't have one to give. > > So I ask again: On what basis are the hardened sources being removed > from the tree? > > At this point I am far less interested in making sure the sources stay > in the tree than I am in forcing you to justify your actions, because > I suspect your attempt to do so will be entertaining. > I just had a bad day so perhaps that last bit was a tad blunt. Consider replacing it with this: There is nothing that holds you accountable to me. However, I am honestly trying to understand why you are doing what you are doing and would like you to explain your decision making process to me. If you can't explain it to me, then how do you know that you have selected the best course of action? If it was a matter of opinion I can accept you will probably go "I'm a developer" and then ignore me. However I don't think it has gotten to that point yet, and you are doing the thing being discussed for what seems to be nebulous and poorly defined reasons. R0b0t1.
Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
On Sat, Aug 19, 2017 at 6:34 AM, Francisco Blas Izquierdo Riera (klondike) wrote: > El 19/08/17 a las 13:18, Aaron W. Swenson escribió: >> On 2017-08-19 13:01, Francisco Blas Izquierdo Riera (klondike) wrote: >>> El 19/08/17 a las 12:37, Aaron W. Swenson escribió: On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote: > Hi! > > I'd like to get this one up by Saturday so that we can proceed with > masking and removing of the hardened-sources after upstream stopped > releasing new patches. I hope I’m not too late. > We'd like to note that all the userspace hardening and MAC support > for SELinux provided by Gentoo Hardened will still remain there and > is unaffected by this removal. Where is there? I think you’re talking about the packages, but the news item is about the kernels. It would help to be more specific here. That’s all I had that the others hadn’t touched on. >>> Do you think something like that is better then? >>> >>> We'd like to note that all the userspace hardening and MAC support >>> for SELinux provided by Gentoo Hardened will still remain available >>> on the portage. Keep in mind though that the security provided by >>> these features will be weakened a bit when using >>> sys-kernel/gentoo-sources. Also, all PaX related packages other than >>> the hardened-sources will remain available for the time being. >>> >>> >> Much better. We should mention that we’re specifically discussing >> packages and not portage itself. At least, that’s my understanding from >> your edit. >> >> Here’s my take on it: >> >> We'd like to note that all the userspace hardening and MAC support for >> SELinux provided by Gentoo Hardened will still remain in the packages >> found in portage. Keep in mind, though, that the security provided by >> these features will be weakened a bit when using >> sys-kernel/gentoo-sources. Also, all PaX related packages, except >> sys-kernel/hardened-sources, will remain available for the time being. > > I updated the news item with your propossal. Thanks a lot :) > The discussion is nice but no one has actually touched on the technical merits of removing the packages besides "they are old." There's plenty of old software in portage. Why not remove it first? I had a similar issue with the GCC developer who removed GCJ support. I asked him for any justification at all for the removal and he had none but some vague statements about it creating work. I would have taken any more specific example he gave at face value, but he didn't want to give one. I was left to conclude he didn't have one to give. So I ask again: On what basis are the hardened sources being removed from the tree? At this point I am far less interested in making sure the sources stay in the tree than I am in forcing you to justify your actions, because I suspect your attempt to do so will be entertaining. R0b0t1.
Re: [gentoo-dev] New SYMLINK_LIB=no migration tool for review
W dniu sob, 19.08.2017 o godzinie 15∶25 -0700, użytkownik Georgy
Yakovlev napisał:
> I've found couple of issues, or maybe not.
>
> systemd installs to /usr/lib/systemd (or /lib/systemd since 234)
> unconditionally.
> I'm not sure if it's special and should be allowed to do that, but it's
> the only package on the system (except gcc/$CHOST dir) that has 64-bit
> libraries and binaries in lib.
Yes, this is valid. /usr/lib/foo is equivalent to /usr/libexec/foo
on modern systems, and some packages prefer the former over the latter.
> Here is the list of the bugs I've found and opened, maybe you can add
> them as blockers for #506276
>
> https://bugs.gentoo.org/show_bug.cgi?id=627744
> https://bugs.gentoo.org/show_bug.cgi?id=627746
Assigned and blocked, thanks.
> https://bugs.gentoo.org/show_bug.cgi?id=628338
>
>
>
> On 08/12/2017 02:33 PM, Michał Górny wrote:
> > On śro, 2017-08-02 at 17:58 +0200, Michał Górny wrote:
> > > Hi, everyone.
> > >
> > > I've finally gotten around to writing a new tool for migrating amd64
> > > systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib-
> > > migration [2] repository along with a README. Please review it and give
> > > it more testing.
> >
> > I've pushed two important fixes now:
> >
> > a. The tool now processes unowned files as well -- *.{a,la,so} are left
> > in lib64 (i.e. the symlinks created by db.eclass and alikes) while
> > everything else goes into lib.
> >
> > b. I've fixed cleanup phase to also remove top-level files
> > and directories that were moved out of lib64. Also, I've fixed it not to
> > complain about trying to remove non-empty directories.
> >
> >
> > > [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276
> > > [2]:https://github.com/mgorny/symlink-lib-migration
>
>
--
Best regards,
Michał Górny
Re: [gentoo-dev] Re: New item for sys-kernel/hardened-sources removal
W dniu sob, 19.08.2017 o godzinie 22∶15 +, użytkownik Duncan napisał: > Aaron W. Swenson posted on Sat, 19 Aug 2017 07:18:20 -0400 as excerpted: > > [Proposed news item excerpt] > > > We'd like to note that all the userspace hardening and MAC support for > > SELinux provided by Gentoo Hardened will still remain in the packages > > found in portage. > > s/portage/the main gentoo tree/ > s/tree/repository/ Though I'd say it's even better to say 'the Gentoo repository'. -- Best regards, Michał Górny
Re: [gentoo-dev] Re: [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols
W dniu sob, 19.08.2017 o godzinie 22∶01 +, użytkownik Duncan
napisał:
> Michał Górny posted on Sat, 19 Aug 2017 10:25:02 +0200 as excerpted:
>
> > Explicitly warn about any URI that uses an unsecure protocol (git, http)
> > even if it's a fallback URI. This is necessary because an attacker may
> > block HTTPS connections, effectively forcing the fallback to
> > the unsecure protocol.
>
> Thanks for this pair of patches. One minor correction, below.
>
> > eclass/git-r3.eclass | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
> > index 42b586811368..1eb0baedc67f 100644
> > --- a/eclass/git-r3.eclass
> > +++ b/eclass/git-r3.eclass
> > @@ -570,6 +570,15 @@ git-r3_fetch() {
> >
> > [[ ${repos[@]} ]] || die "No URI provided and EGIT_REPO_URI unset"
> >
> > + local r
> > + for r in "${repos[@]}"; do
> > + if [[ ${r} == git:* || ${r} == http:* ]]; then
> > + ewarn "git-r3: ${r%%:*} protocol in unsafe and may be
> > subject to MITM attacks"
>
> s/in unsafe/is unsafe/
>
Thanks, fixed locally.
--
Best regards,
Michał Górny
Re: [gentoo-dev] New SYMLINK_LIB=no migration tool for review
I've found couple of issues, or maybe not.
systemd installs to /usr/lib/systemd (or /lib/systemd since 234)
unconditionally.
I'm not sure if it's special and should be allowed to do that, but it's
the only package on the system (except gcc/$CHOST dir) that has 64-bit
libraries and binaries in lib.
Here is the list of the bugs I've found and opened, maybe you can add
them as blockers for #506276
https://bugs.gentoo.org/show_bug.cgi?id=627744
https://bugs.gentoo.org/show_bug.cgi?id=627746
https://bugs.gentoo.org/show_bug.cgi?id=628338
On 08/12/2017 02:33 PM, Michał Górny wrote:
> On śro, 2017-08-02 at 17:58 +0200, Michał Górny wrote:
>> Hi, everyone.
>>
>> I've finally gotten around to writing a new tool for migrating amd64
>> systems to SYMLINK_LIB=no layout [1]. I've put it in symlink-lib-
>> migration [2] repository along with a README. Please review it and give
>> it more testing.
>
> I've pushed two important fixes now:
>
> a. The tool now processes unowned files as well -- *.{a,la,so} are left
> in lib64 (i.e. the symlinks created by db.eclass and alikes) while
> everything else goes into lib.
>
> b. I've fixed cleanup phase to also remove top-level files
> and directories that were moved out of lib64. Also, I've fixed it not to
> complain about trying to remove non-empty directories.
>
>
>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=506276
>> [2]:https://github.com/mgorny/symlink-lib-migration
>
[gentoo-dev] Re: New item for sys-kernel/hardened-sources removal
Aaron W. Swenson posted on Sat, 19 Aug 2017 07:18:20 -0400 as excerpted: [Proposed news item excerpt] > We'd like to note that all the userspace hardening and MAC support for > SELinux provided by Gentoo Hardened will still remain in the packages > found in portage. s/portage/the main gentoo tree/ Portage is a package manager, the default certainly, but still one of three. "The portage tree" usage remains around for legacy reasons, but "the gentoo tree" or even "the main gentoo tree" (because overlays) is arguably more accurate modern usage. [Just my contribution to the shed color debate. =:^P ] -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols
Michał Górny posted on Sat, 19 Aug 2017 10:25:02 +0200 as excerpted:
> Explicitly warn about any URI that uses an unsecure protocol (git, http)
> even if it's a fallback URI. This is necessary because an attacker may
> block HTTPS connections, effectively forcing the fallback to
> the unsecure protocol.
Thanks for this pair of patches. One minor correction, below.
> eclass/git-r3.eclass | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
> index 42b586811368..1eb0baedc67f 100644
> --- a/eclass/git-r3.eclass
> +++ b/eclass/git-r3.eclass
> @@ -570,6 +570,15 @@ git-r3_fetch() {
>
> [[ ${repos[@]} ]] || die "No URI provided and EGIT_REPO_URI unset"
>
> + local r
> + for r in "${repos[@]}"; do
> + if [[ ${r} == git:* || ${r} == http:* ]]; then
> + ewarn "git-r3: ${r%%:*} protocol in unsafe and may be
> subject to MITM attacks"
s/in unsafe/is unsafe/
(Tho I can imagine a point at which "unsafe" becomes a list/array, defined
at the top of the function along with the other defines, or in a new
git-r3_check_unsafe
function, at which point "in unsafe" could make sense. But that's not the
structure here.)
> + ewarn "(even if used only as fallback). Please use
> https instead."
> + ewarn "[URI: ${r}]"
> + fi
> + done
> +
> local -x GIT_DIR
> _git-r3_set_gitdir "${repos[0]}"
>
> @@ -582,7 +591,7 @@ git-r3_fetch() {
> fi
>
> # try to fetch from the remote
> - local r success saved_umask
> + local success saved_umask
> if [[ ${EVCS_UMASK} ]]; then
> saved_umask=$(umask)
> umask "${EVCS_UMASK}" || die "Bad options to umask:
> ${EVCS_UMASK}"
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] [PATCH 2/2] vim-spell.eclass: document variables using Gentoo documentation tags.
W dniu sob, 19.08.2017 o godzinie 14∶53 +0200, użytkownik Patrice
Clement napisał:
> ---
> eclass/vim-spell.eclass | 37 +++--
> 1 file changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/eclass/vim-spell.eclass b/eclass/vim-spell.eclass
> index 1b0f93c264d..8c1b6314ed8 100644
> --- a/eclass/vim-spell.eclass
> +++ b/eclass/vim-spell.eclass
> @@ -68,23 +68,34 @@ RDEPEND="${DEPEND}"
> SRC_URI="mirror://gentoo/${P}.tar.bz2"
> SLOT="0"
>
> -if [[ -z "${VIM_SPELL_CODE}" ]] ; then
> - VIM_SPELL_CODE="${PN/vim-spell-/}"
> -fi
> +# @ECLASS-VARIABLE: DESCRIPTION
> +# @DESCRIPTION:
> +# Default DESCRIPTION for Vim spell ebuilds.
> +: ${DESCRIPTION:="vim spell files: ${VIM_SPELL_LANGUAGE}
> (${VIM_SPELL_LOCALE})"}
Wouldn't it be better to declare it after you default VIM_SPELL_*?
Also, is VIM_SPELL_LANGUAGE documented? I don't see it.
>
> -DESCRIPTION="vim spell files: ${VIM_SPELL_LANGUAGE} (${VIM_SPELL_CODE})"
> +# @ECLASS-VARIABLE: HOMEPAGE
> +# @DESCRIPTION:
> +# Default HOMEPAGE for Vim spell ebuilds.
> +: ${HOMEPAGE:="https://www.vim.org"}
>
> -if [[ -z "${HOMEPAGE}" ]] ; then
> - HOMEPAGE="http://www.vim.org/";
> -fi
> +# @ECLASS-VARIABLE: VIM_SPELL_LOCALE
> +# @INTERNAL
Is it really internal? It looks like something that the ebuild might
override in the past.
> +# @DESCRIPTION:
> +# Locale for the current ebuild.
> +: ${VIM_SPELL_LOCALE:="${PN/vim-spell-/}"}
> +
> +# @ECLASS-VARIABLE: VIM_SPELL_DIRECTORY
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Path to Vim spell directory files.
> +: ${VIM_SPELL_DIRECTORY:="/usr/share/vim/vimfiles/spell/"}
>
> # @FUNCTION: vim-spell_src_install
> # @DESCRIPTION:
> # Install Vim spell files.
> vim-spell_src_install() {
> - target="/usr/share/vim/vimfiles/spell/"
> - dodir "${target}"
> - insinto "${target}"
> + dodir "${VIM_SPELL_DIRECTORY}"
> + insinto "${VIM_SPELL_DIRECTORY}"
>
> had_spell_file=
> for f in *.spl ; do
> @@ -112,15 +123,13 @@ vim-spell_src_install() {
> # Display installed Vim spell files.
> vim-spell_pkg_postinst() {
> has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
> - target="/usr/share/vim/vimfiles/spell/"
> echo
> elog "To enable ${VIM_SPELL_LANGUAGE} spell checking, use"
> - elog ":setlocal spell spelllang=${VIM_SPELL_CODE}"
> + elog ":setlocal spell spelllang=${VIM_SPELL_LOCALE}"
> echo
> elog "The following (Vim internal, not file) encodings are supported
> for"
> elog "this language:"
> - for f in "${EROOT}/${target}/${VIM_SPELL_CODE}".*.spl ; do
> - enc="${f##*/${VIM_SPELL_CODE}.}"
> + for f in "${EROOT}/${VIM_SPELL_DIRECTORY}/${VIM_SPELL_LOCALE}".*.spl ;
> do enc="${f##*/${VIM_SPELL_LOCALE}.}"
I suppose the combining of two lines was accidental. As a side note,
EROOT ends with /.
> enc="${enc%.spl}"
> [[ -z "${enc}" ]] && continue
> elog "${enc}"
--
Best regards,
Michał Górny
[gentoo-dev] [PATCH 2/2] vim-spell.eclass: document variables using Gentoo documentation tags.
---
eclass/vim-spell.eclass | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/eclass/vim-spell.eclass b/eclass/vim-spell.eclass
index 1b0f93c264d..8c1b6314ed8 100644
--- a/eclass/vim-spell.eclass
+++ b/eclass/vim-spell.eclass
@@ -68,23 +68,34 @@ RDEPEND="${DEPEND}"
SRC_URI="mirror://gentoo/${P}.tar.bz2"
SLOT="0"
-if [[ -z "${VIM_SPELL_CODE}" ]] ; then
- VIM_SPELL_CODE="${PN/vim-spell-/}"
-fi
+# @ECLASS-VARIABLE: DESCRIPTION
+# @DESCRIPTION:
+# Default DESCRIPTION for Vim spell ebuilds.
+: ${DESCRIPTION:="vim spell files: ${VIM_SPELL_LANGUAGE}
(${VIM_SPELL_LOCALE})"}
-DESCRIPTION="vim spell files: ${VIM_SPELL_LANGUAGE} (${VIM_SPELL_CODE})"
+# @ECLASS-VARIABLE: HOMEPAGE
+# @DESCRIPTION:
+# Default HOMEPAGE for Vim spell ebuilds.
+: ${HOMEPAGE:="https://www.vim.org"}
-if [[ -z "${HOMEPAGE}" ]] ; then
- HOMEPAGE="http://www.vim.org/";
-fi
+# @ECLASS-VARIABLE: VIM_SPELL_LOCALE
+# @INTERNAL
+# @DESCRIPTION:
+# Locale for the current ebuild.
+: ${VIM_SPELL_LOCALE:="${PN/vim-spell-/}"}
+
+# @ECLASS-VARIABLE: VIM_SPELL_DIRECTORY
+# @INTERNAL
+# @DESCRIPTION:
+# Path to Vim spell directory files.
+: ${VIM_SPELL_DIRECTORY:="/usr/share/vim/vimfiles/spell/"}
# @FUNCTION: vim-spell_src_install
# @DESCRIPTION:
# Install Vim spell files.
vim-spell_src_install() {
- target="/usr/share/vim/vimfiles/spell/"
- dodir "${target}"
- insinto "${target}"
+ dodir "${VIM_SPELL_DIRECTORY}"
+ insinto "${VIM_SPELL_DIRECTORY}"
had_spell_file=
for f in *.spl ; do
@@ -112,15 +123,13 @@ vim-spell_src_install() {
# Display installed Vim spell files.
vim-spell_pkg_postinst() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
- target="/usr/share/vim/vimfiles/spell/"
echo
elog "To enable ${VIM_SPELL_LANGUAGE} spell checking, use"
- elog ":setlocal spell spelllang=${VIM_SPELL_CODE}"
+ elog ":setlocal spell spelllang=${VIM_SPELL_LOCALE}"
echo
elog "The following (Vim internal, not file) encodings are supported
for"
elog "this language:"
- for f in "${EROOT}/${target}/${VIM_SPELL_CODE}".*.spl ; do
- enc="${f##*/${VIM_SPELL_CODE}.}"
+ for f in "${EROOT}/${VIM_SPELL_DIRECTORY}/${VIM_SPELL_LOCALE}".*.spl ;
do enc="${f##*/${VIM_SPELL_LOCALE}.}"
enc="${enc%.spl}"
[[ -z "${enc}" ]] && continue
elog "${enc}"
--
2.13.0
[gentoo-dev] [PATCH 1/2] vim-spell.eclass: document functions using Gentoo documentation tags.
---
eclass/vim-spell.eclass | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/eclass/vim-spell.eclass b/eclass/vim-spell.eclass
index 0a3ef952a87..1b0f93c264d 100644
--- a/eclass/vim-spell.eclass
+++ b/eclass/vim-spell.eclass
@@ -1,12 +1,13 @@
-# Copyright 1999-2011 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-#
-# Original Author: Ciaran McCreesh
-# Maintainers: Vim Herd
-# Purpose: Simplify installing spell files for vim7
-#
-
+# @ECLASS: vim-spell.eclass
+# @MAINTAINER:
+# Vim Maintainers
+# @AUTHOR:
+# Ciaran McCreesh
+# @BLURB: Eclass for managing Vim spell files.
+# @DESCRIPTION:
# How to make a vim spell file package using prebuilt spell lists
# from upstream (${CODE} is the language's two letter code):
#
@@ -21,9 +22,9 @@
#
# * Upload the tarball to the Gentoo mirrors.
#
-# * (for now) Add your spell file to package.mask next to the other vim7
-# things. The vim herd will handle unmasking your spell packages when vim7
-# comes out of package.mask.
+# * Add your spell file to package.mask next to the other vim things. Vim
+# Project members will handle unmasking your spell packages when vim comes
out
+# of package.mask.
#
# * Create the app-vim/vim-spell-${CODE} package. You should base your ebuild
# upon app-vim/vim-spell-en. You will need to change VIM_SPELL_LANGUAGE,
@@ -52,7 +53,7 @@
# Don't forget to update your package as necessary.
#
# If there isn't an upstream-provided pregenerated spell file for your language
-# yet, read :help spell.txt from inside vim7 for instructions on how to create
+# yet, read :help spell.txt from inside vim for instructions on how to create
# spell files. It's best to let upstream know if you've generated spell files
# for another language rather than keeping them Gentoo-specific.
@@ -77,6 +78,9 @@ if [[ -z "${HOMEPAGE}" ]] ; then
HOMEPAGE="http://www.vim.org/";
fi
+# @FUNCTION: vim-spell_src_install
+# @DESCRIPTION:
+# Install Vim spell files.
vim-spell_src_install() {
target="/usr/share/vim/vimfiles/spell/"
dodir "${target}"
@@ -103,6 +107,9 @@ vim-spell_src_install() {
[[ -z "${had_spell_file}" ]] && die "Didn't install any spell files?"
}
+# @FUNCTION: vim-spell_pkg_postinst
+# @DESCRIPTION:
+# Display installed Vim spell files.
vim-spell_pkg_postinst() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
target="/usr/share/vim/vimfiles/spell/"
--
2.13.0
[gentoo-dev] [PATCH 0/2] vim-spell.eclass: improvements.
Hi everyone I'm working on solving https://bugs.gentoo.org/469414 but realised much of the eclass documentation isn't up to our standards. Here's a few commits to fix that oversight. Please review. Thanks! Patrice Clement (2): vim-spell.eclass: document functions using Gentoo documentation tags. vim-spell.eclass: document variables using Gentoo documentation tags. eclass/vim-spell.eclass | 66 ++--- 1 file changed, 41 insertions(+), 25 deletions(-) -- 2.13.0
Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
El 19/08/17 a las 13:18, Aaron W. Swenson escribió: > On 2017-08-19 13:01, Francisco Blas Izquierdo Riera (klondike) wrote: >> El 19/08/17 a las 12:37, Aaron W. Swenson escribió: >>> On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote: Hi! I'd like to get this one up by Saturday so that we can proceed with masking and removing of the hardened-sources after upstream stopped releasing new patches. >>> I hope I’m not too late. >>> We'd like to note that all the userspace hardening and MAC support for SELinux provided by Gentoo Hardened will still remain there and is unaffected by this removal. >>> Where is there? I think you’re talking about the packages, but the news >>> item is about the kernels. It would help to be more specific here. >>> >>> That’s all I had that the others hadn’t touched on. >> Do you think something like that is better then? >> >> We'd like to note that all the userspace hardening and MAC support >> for SELinux provided by Gentoo Hardened will still remain available >> on the portage. Keep in mind though that the security provided by >> these features will be weakened a bit when using >> sys-kernel/gentoo-sources. Also, all PaX related packages other than >> the hardened-sources will remain available for the time being. >> >> > Much better. We should mention that we’re specifically discussing > packages and not portage itself. At least, that’s my understanding from > your edit. > > Here’s my take on it: > > We'd like to note that all the userspace hardening and MAC support for > SELinux provided by Gentoo Hardened will still remain in the packages > found in portage. Keep in mind, though, that the security provided by > these features will be weakened a bit when using > sys-kernel/gentoo-sources. Also, all PaX related packages, except > sys-kernel/hardened-sources, will remain available for the time being. I updated the news item with your propossal. Thanks a lot :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
On 2017-08-19 13:01, Francisco Blas Izquierdo Riera (klondike) wrote: > El 19/08/17 a las 12:37, Aaron W. Swenson escribió: > > On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote: > >> Hi! > >> > >> I'd like to get this one up by Saturday so that we can proceed with > >> masking and removing of the hardened-sources after upstream stopped > >> releasing new patches. > > I hope I’m not too late. > > > >> We'd like to note that all the userspace hardening and MAC support > >> for SELinux provided by Gentoo Hardened will still remain there and > >> is unaffected by this removal. > > Where is there? I think you’re talking about the packages, but the news > > item is about the kernels. It would help to be more specific here. > > > > That’s all I had that the others hadn’t touched on. > > Do you think something like that is better then? > > We'd like to note that all the userspace hardening and MAC support > for SELinux provided by Gentoo Hardened will still remain available > on the portage. Keep in mind though that the security provided by > these features will be weakened a bit when using > sys-kernel/gentoo-sources. Also, all PaX related packages other than > the hardened-sources will remain available for the time being. > > Much better. We should mention that we’re specifically discussing packages and not portage itself. At least, that’s my understanding from your edit. Here’s my take on it: We'd like to note that all the userspace hardening and MAC support for SELinux provided by Gentoo Hardened will still remain in the packages found in portage. Keep in mind, though, that the security provided by these features will be weakened a bit when using sys-kernel/gentoo-sources. Also, all PaX related packages, except sys-kernel/hardened-sources, will remain available for the time being. signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] [PATCH] dev-util/shadowman: Unified tool to update ccache/distcc/icecc shadow dir
On 19.08.2017 12:53, Michał Górny wrote: > Dnia 19 sierpnia 2017 12:19:18 CEST, "Manuel Rüger" > napisał(a): >> On 17.08.2017 10:36, Michał Górny wrote: >>> Hi, everyone. >>> >>> I've written a new tool called shadowman [1] that aims to partially >>> replace the current *-config tools shipped with ccache, distcc, icecc >>> and potentially more. >>> >>> Why? Because the existing tools are inconsistent, inconvenient >>> and usually incomplete. The README [2] states a number of advantages: >>> >>> | 1. one usage syntax that works for all tools, >>> | >>> | 2. ability to update/clean masquerades for multiple tools in one >> call, >>> | >>> | 3. consistent (and *good*) implementation -- now all tools get the >> same >>> | executable list, >>> | >>> | 4. reduced code duplication, >>> | >>> | 5. modular layout that allows adding extra tools/compiler wildcards >>> | by third-party packages. >>> >>> This thread includes patches that: >>> >>> a. add the package for shadowman (skipping some bundled modules for >>> external inclusion) -- for testing it's just a live ebuild with full >>> keyword set; I will obviously change that before the final inclusion; >>> >>> b. adds shadowman support to ccache, distcc & icecream packages >>> (preserving the old utilities for compatibility), >>> >>> c. adds shadowman update call to toolchain.eclass & clang ebuilds >>> so that the masquerades get updated automatically on gcc/clang >> upgrade. >>> >>> Please review. Alternatively available as PR on GitHub [3]. >>> >>> [1]:https://github.com/mgorny/shadowman >>> [2]:https://github.com/mgorny/shadowman/blob/master/README >>> [3]:https://github.com/gentoo/gentoo/pull/5386 >>> >>> >> Have you considered moving it under the gentoo umbrella (e.g., mirror >> it >> on git.gentoo.org or move it to the gentoo organisation)? > > No, I'm not interested in giving away credit to my personal work which I'm > personally maintaining. > Why do you consider it to "give away credit" when it's under github.org/gentoo/ or on git.gentoo.org? You'll still be author of the commits. >> >> Thanks, >> Manuel > >
Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
El 19/08/17 a las 12:37, Aaron W. Swenson escribió: > On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote: >> Hi! >> >> I'd like to get this one up by Saturday so that we can proceed with >> masking and removing of the hardened-sources after upstream stopped >> releasing new patches. > I hope I’m not too late. > >> We'd like to note that all the userspace hardening and MAC support >> for SELinux provided by Gentoo Hardened will still remain there and >> is unaffected by this removal. > Where is there? I think you’re talking about the packages, but the news > item is about the kernels. It would help to be more specific here. > > That’s all I had that the others hadn’t touched on. Do you think something like that is better then? We'd like to note that all the userspace hardening and MAC support for SELinux provided by Gentoo Hardened will still remain available on the portage. Keep in mind though that the security provided by these features will be weakened a bit when using sys-kernel/gentoo-sources. Also, all PaX related packages other than the hardened-sources will remain available for the time being. signature.asc Description: OpenPGP digital signature
[gentoo-dev] About sys-kernel/hardened-sources removal
Hi! The gentoo-dev list is not the right place to keep up discussion on why or how the hardened-sources will be removed. Not this thread which is about the news item. Most packages just get masked and removed in 30 days for example without sending a news item just an e-mail to gentoo-dev-announce. The only reason why we are sending it is because most Gentoo Hardened users were using the hardened-sources and deserve a heads-up as to what will happen to them and what can they do after (as there will be no clear and simple upgrade path with similar features). Please do send further answers to gentoo-hardened which is the porject's mailing list. El 18/08/17 a las 02:59, R0b0t1 escribió: > On Tue, Aug 15, 2017 at 3:03 PM, Francisco Blas Izquierdo Riera > (klondike) wrote: >> El 15/08/17 a las 17:50, R0b0t1 escribió: >>> Where was this decision discussed? >> https://archives.gentoo.org/gentoo-hardened/message/62ebc2e26d91e8f079197c2c83788cff >> >> And many other threads in that list for example, those are just blueness >> (the package maintainer) conclussions. >>> The last available kernel is >>> apparently receiving long term support, there may not be any reason to >>> remove it. >> Not by the original upstream, and definitively not in the way in which >> Grsec used to (manually cherrypicking security related commits and not >> just those marked as security related). >> > All blueness says in that is that he can't personally support the > patches. That's fine, and nobody that I know of ever expected him to > do that. However, until they are unfixably broken, why remove them? > Keeping them until a suitable replacement is available seems like the > best option available. > There's no criteria in that notice for when they would be removed. > What criteria was used to decide they are generating useless work and > should be removed? They are already unfixably broken. They are affected by stack clash (when using certain obscure configs but nonetheless). They are to all effects unmaintained (as in upstream not publishing patches we can provide to you). And I'd rather not look at what other fixes came in the 4.9 tree since then that I have missed. >> Although minipli's kernel patches are good and I personally recommend >> them, this is not something the Gentoo Hardened team will do. Also they >> probably should be renamed something else. > I'm not sure anyone is asking the hardened team to do anything, except > for people on the hardened team who want to remove the patches. Then please address blueness about this (on the aforementioned thread) and not me. I'm just the messenger who was asked to deliver the news. >>> If it isn't broken and creating work yet I'm not sure why >>> anyone cares. >> Go to #gentoo-hardened and see how there is people asking about this >> again and again :P >> > I'm not sure what you mean. There are people asking about it, but that > doesn't necessarily mean they want it to happen. If something is done > people are going to discuss it regardless of what it is. I mean people is asking "what happens with the hardened-sources?" and we having to answer. Now at least we have a clear path of action announced. > Please understand, I don't want to keep an old version of the kernel > and associated patches around forever, just until a replacement is > actually found. There are a few replacements, we aren't just providing an ebuild in the portage tree for them (except for gentoo-sources, of course). If you want to keep the ebuilds and patches I recommend you set up a personal overlay instead. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] [PATCH] dev-util/shadowman: Unified tool to update ccache/distcc/icecc shadow dir
Dnia 19 sierpnia 2017 12:19:18 CEST, "Manuel Rüger" napisał(a): >On 17.08.2017 10:36, Michał Górny wrote: >> Hi, everyone. >> >> I've written a new tool called shadowman [1] that aims to partially >> replace the current *-config tools shipped with ccache, distcc, icecc >> and potentially more. >> >> Why? Because the existing tools are inconsistent, inconvenient >> and usually incomplete. The README [2] states a number of advantages: >> >> | 1. one usage syntax that works for all tools, >> | >> | 2. ability to update/clean masquerades for multiple tools in one >call, >> | >> | 3. consistent (and *good*) implementation -- now all tools get the >same >> | executable list, >> | >> | 4. reduced code duplication, >> | >> | 5. modular layout that allows adding extra tools/compiler wildcards >> | by third-party packages. >> >> This thread includes patches that: >> >> a. add the package for shadowman (skipping some bundled modules for >> external inclusion) -- for testing it's just a live ebuild with full >> keyword set; I will obviously change that before the final inclusion; >> >> b. adds shadowman support to ccache, distcc & icecream packages >> (preserving the old utilities for compatibility), >> >> c. adds shadowman update call to toolchain.eclass & clang ebuilds >> so that the masquerades get updated automatically on gcc/clang >upgrade. >> >> Please review. Alternatively available as PR on GitHub [3]. >> >> [1]:https://github.com/mgorny/shadowman >> [2]:https://github.com/mgorny/shadowman/blob/master/README >> [3]:https://github.com/gentoo/gentoo/pull/5386 >> >> >Have you considered moving it under the gentoo umbrella (e.g., mirror >it >on git.gentoo.org or move it to the gentoo organisation)? No, I'm not interested in giving away credit to my personal work which I'm personally maintaining. > >Thanks, >Manuel -- Best regards, Michał Górny (by phone)
Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal
On 2017-08-15 17:01, Francisco Blas Izquierdo Riera (klondike) wrote: > Hi! > > I'd like to get this one up by Saturday so that we can proceed with > masking and removing of the hardened-sources after upstream stopped > releasing new patches. I hope I’m not too late. > We'd like to note that all the userspace hardening and MAC support > for SELinux provided by Gentoo Hardened will still remain there and > is unaffected by this removal. Where is there? I think you’re talking about the packages, but the news item is about the kernels. It would help to be more specific here. That’s all I had that the others hadn’t touched on. signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] [PATCH] dev-util/shadowman: Unified tool to update ccache/distcc/icecc shadow dir
On 17.08.2017 10:36, Michał Górny wrote: > Hi, everyone. > > I've written a new tool called shadowman [1] that aims to partially > replace the current *-config tools shipped with ccache, distcc, icecc > and potentially more. > > Why? Because the existing tools are inconsistent, inconvenient > and usually incomplete. The README [2] states a number of advantages: > > | 1. one usage syntax that works for all tools, > | > | 2. ability to update/clean masquerades for multiple tools in one call, > | > | 3. consistent (and *good*) implementation -- now all tools get the same > | executable list, > | > | 4. reduced code duplication, > | > | 5. modular layout that allows adding extra tools/compiler wildcards > | by third-party packages. > > This thread includes patches that: > > a. add the package for shadowman (skipping some bundled modules for > external inclusion) -- for testing it's just a live ebuild with full > keyword set; I will obviously change that before the final inclusion; > > b. adds shadowman support to ccache, distcc & icecream packages > (preserving the old utilities for compatibility), > > c. adds shadowman update call to toolchain.eclass & clang ebuilds > so that the masquerades get updated automatically on gcc/clang upgrade. > > Please review. Alternatively available as PR on GitHub [3]. > > [1]:https://github.com/mgorny/shadowman > [2]:https://github.com/mgorny/shadowman/blob/master/README > [3]:https://github.com/gentoo/gentoo/pull/5386 > > Have you considered moving it under the gentoo umbrella (e.g., mirror it on git.gentoo.org or move it to the gentoo organisation)? Thanks, Manuel
[gentoo-dev] [PATCH 2/2] git-r3.eclass: Explicitly warn about unsecure protocols
Explicitly warn about any URI that uses an unsecure protocol (git, http)
even if it's a fallback URI. This is necessary because an attacker may
block HTTPS connections, effectively forcing the fallback to
the unsecure protocol.
---
eclass/git-r3.eclass | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 42b586811368..1eb0baedc67f 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -570,6 +570,15 @@ git-r3_fetch() {
[[ ${repos[@]} ]] || die "No URI provided and EGIT_REPO_URI unset"
+ local r
+ for r in "${repos[@]}"; do
+ if [[ ${r} == git:* || ${r} == http:* ]]; then
+ ewarn "git-r3: ${r%%:*} protocol in unsafe and may be
subject to MITM attacks"
+ ewarn "(even if used only as fallback). Please use
https instead."
+ ewarn "[URI: ${r}]"
+ fi
+ done
+
local -x GIT_DIR
_git-r3_set_gitdir "${repos[0]}"
@@ -582,7 +591,7 @@ git-r3_fetch() {
fi
# try to fetch from the remote
- local r success saved_umask
+ local success saved_umask
if [[ ${EVCS_UMASK} ]]; then
saved_umask=$(umask)
umask "${EVCS_UMASK}" || die "Bad options to umask:
${EVCS_UMASK}"
--
2.14.1
[gentoo-dev] [PATCH 1/2] git-r3.eclass: Update docs to discourage unsafe protocols
---
eclass/git-r3.eclass | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index bc7d4d920299..42b586811368 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -105,10 +105,14 @@ fi
# @ECLASS-VARIABLE: EGIT_REPO_URI
# @REQUIRED
# @DESCRIPTION:
-# URIs to the repository, e.g. git://foo, https://foo. If multiple URIs
-# are provided, the eclass will consider them as fallback URIs to try
-# if the first URI does not work. For supported URI syntaxes, read up
-# the manpage for git-clone(1).
+# URIs to the repository, e.g. https://foo. If multiple URIs are
+# provided, the eclass will consider the remaining URIs as fallbacks
+# to try if the first URI does not work. For supported URI syntaxes,
+# read up the manpage for git-clone(1).
+#
+# URIs should be using https:// whenever possible. http:// and git://
+# URIs are unsafe and their use (even if only as a fallback) makes
+# MITM attacks possible.
#
# It can be overriden via env using ${PN}_LIVE_REPO variable.
#
@@ -116,7 +120,7 @@ fi
#
# Example:
# @CODE
-# EGIT_REPO_URI="git://a/b.git https://c/d.git";
+# EGIT_REPO_URI="https://a/b.git https://c/d.git";
# @CODE
# @ECLASS-VARIABLE: EVCS_OFFLINE
--
2.14.1
