Re: [gentoo-dev] License of news items

[Francisco Blas Izquierdo Riera (klondike)]

El 26/12/20 a las 10:20, Ulrich Mueller escribió:

This would apply retroactively since 2018-10-21 (when GLEP 76 was marked
as Active). I am going to file a bug for authors to acknowledge that
their news items can be distributed under CC-BY-SA-4.0.


For all matters the news item I wrote in 2017 can be distributed under that 
license (and also under the GFDL if you prefer).

Francisco



OpenPGP_0x5608AEA28AAFC0EC_and_old_rev.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] CPU_FLAGS_X86: Introduce 'rdrand' flag

[Francisco Blas Izquierdo Riera (klondike)]

El 13/7/20 a las 22:07, Francisco Blas Izquierdo Riera (klondike) escribió:
> El 13/7/20 a las 21:27, Michał Górny escribió:
>> On Mon, 2020-07-13 at 19:33 +0200, Francisco Blas Izquierdo Riera
>> (klondike) wrote:
>>> El 13/7/20 a las 19:23, Michał Górny escribió:
>>>> On Mon, 2020-07-13 at 19:07 +0200, Francisco Blas Izquierdo Riera
>>>> (klondike) wrote:
>>>>> Hi!
>>>>>
>>>>> We have currently two packages that have USE cpu-flags-x86-rdrand as 
>>>>> there is no USE_EXPAND version available. This pattern is likely to 
>>>>> confuse users as they may not be aware of the difference between dashes 
>>>>> and underscores.
>>>>>
>>>>> Affected packages:
>>>>> dev-haskell/cryptonite
>>>>> dev-libs/json-c
>>>>>
>>>> I'm sorry but I haven't been following the big rdrand-AMD drama closely.
>>>>  Does the kernel mitigate broken RDRAND after resume these days?
>>>>
>>> AGESA patches do exist to address this issue: 
>>> https://www.reddit.com/r/Amd/comments/cmza34/agesa_1003_abb_fixes_rdrandrdseed/
>>>  I suspect AMD microcode does too.
>>>
>> Lemme rephrase: is this something we should be warning our users before
>> they enable the flag?  I think we should aim to avoid the situation that
>> cpuid2cpuflags enables this behind user's backs and their programs
>> suddenly break as a result.
> You then mean the other rdrand bug.
>
> Yes, current stable linux kernel (5.4.48) in amd64 does include the patch, 
> I'm uncertain about prior kernel branches though but I don't expect many 
> users on that confluence.
>
> The patch: 
> https://lore.kernel.org/linux-doc/776cb5c2d33e7fd0d2893904724c0e52b394f24a.1565817448.git.thomas.lenda...@amd.com/
> The bug: https://bugzilla.kernel.org/show_bug.cgi?id=85911
>
>
I have checked also stable versions for other kernel branches and all seem to 
have the patch icluded.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] CPU_FLAGS_X86: Introduce 'rdrand' flag

[Francisco Blas Izquierdo Riera (klondike)]

El 13/7/20 a las 21:27, Michał Górny escribió:
> On Mon, 2020-07-13 at 19:33 +0200, Francisco Blas Izquierdo Riera
> (klondike) wrote:
>> El 13/7/20 a las 19:23, Michał Górny escribió:
>>> On Mon, 2020-07-13 at 19:07 +0200, Francisco Blas Izquierdo Riera
>>> (klondike) wrote:
>>>> Hi!
>>>>
>>>> We have currently two packages that have USE cpu-flags-x86-rdrand as there 
>>>> is no USE_EXPAND version available. This pattern is likely to confuse 
>>>> users as they may not be aware of the difference between dashes and 
>>>> underscores.
>>>>
>>>> Affected packages:
>>>> dev-haskell/cryptonite
>>>> dev-libs/json-c
>>>>
>>> I'm sorry but I haven't been following the big rdrand-AMD drama closely.
>>>  Does the kernel mitigate broken RDRAND after resume these days?
>>>
>> AGESA patches do exist to address this issue: 
>> https://www.reddit.com/r/Amd/comments/cmza34/agesa_1003_abb_fixes_rdrandrdseed/
>>  I suspect AMD microcode does too.
>>
> Lemme rephrase: is this something we should be warning our users before
> they enable the flag?  I think we should aim to avoid the situation that
> cpuid2cpuflags enables this behind user's backs and their programs
> suddenly break as a result.

You then mean the other rdrand bug.

Yes, current stable linux kernel (5.4.48) in amd64 does include the patch, I'm 
uncertain about prior kernel branches though but I don't expect many users on 
that confluence.

The patch: 
https://lore.kernel.org/linux-doc/776cb5c2d33e7fd0d2893904724c0e52b394f24a.1565817448.git.thomas.lenda...@amd.com/
The bug: https://bugzilla.kernel.org/show_bug.cgi?id=85911




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/4] CPU_FLAGS_X86: Introduce 'rdrand' flag

[Francisco Blas Izquierdo Riera (klondike)]

El 13/7/20 a las 19:23, Michał Górny escribió:
> On Mon, 2020-07-13 at 19:07 +0200, Francisco Blas Izquierdo Riera
> (klondike) wrote:
>> Hi!
>>
>> We have currently two packages that have USE cpu-flags-x86-rdrand as there 
>> is no USE_EXPAND version available. This pattern is likely to confuse users 
>> as they may not be aware of the difference between dashes and underscores.
>>
>> Affected packages:
>> dev-haskell/cryptonite
>> dev-libs/json-c
>>
> I'm sorry but I haven't been following the big rdrand-AMD drama closely.
>  Does the kernel mitigate broken RDRAND after resume these days?
>
AGESA patches do exist to address this issue: 
https://www.reddit.com/r/Amd/comments/cmza34/agesa_1003_abb_fixes_rdrandrdseed/ 
I suspect AMD microcode does too.




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH 0/4] CPU_FLAGS_X86: Introduce 'rdrand' flag

[Francisco Blas Izquierdo Riera (klondike)]

Please ignore patches 2 and 3, I missed some USE flag replacements. I'll 
resubmit in a second.

El 13/7/20 a las 19:07, Francisco Blas Izquierdo Riera (klondike) escribió:
> Hi!
>
> We have currently two packages that have USE cpu-flags-x86-rdrand as there is 
> no USE_EXPAND version available. This pattern is likely to confuse users as 
> they may not be aware of the difference between dashes and underscores.
>
> Affected packages:
> dev-haskell/cryptonite
> dev-libs/json-c
>
> The following set of patches:
>
> 1 Add the cpu_flags_x86_rdrand use flag to the USE_EXPAND variable.
> 2 and 3 Make affected packages use the new USE flag
> 4 Provides detection on cpuid2cpuflags
>
> Patches 1 to 3 are available as a pull request at: 
> https://github.com/gentoo/gentoo/pull/16686
>
> Patch 4 is available as a pull request at: 
> https://github.com/mgorny/cpuid2cpuflags/pull/16
>
> (Using GitHub mostly to make following the patches easier, keep the 
> discussion here)
>
>




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCHv2 3/4] dev-libs/json-c: Change USE to cpu_flags_x86_rdrand

[Francisco Blas Izquierdo Riera (klondike)]

Package-Manager: Portage-2.3.99, Repoman-2.3.23
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) 
---
 dev-libs/json-c/json-c-0.14-r3.ebuild | 4 ++--
 dev-libs/json-c/json-c-.ebuild    | 4 ++--
 dev-libs/json-c/metadata.xml  | 3 ---
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/dev-libs/json-c/json-c-0.14-r3.ebuild 
b/dev-libs/json-c/json-c-0.14-r3.ebuild
index 0d4ff648a36..0eae6655775 100644
--- a/dev-libs/json-c/json-c-0.14-r3.ebuild
+++ b/dev-libs/json-c/json-c-0.14-r3.ebuild
@@ -13,7 +13,7 @@ 
SRC_URI="https://s3.amazonaws.com/json-c_releases/releases/${P}.tar.gz;
 LICENSE="MIT"
 SLOT="0/5"
 KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~mips ppc ppc64 s390 sparc x86 
~amd64-linux ~x86-linux ~ppc-macos"
-IUSE="cpu-flags-x86-rdrand doc static-libs threads"
+IUSE="cpu_flags_x86_rdrand doc static-libs threads"
 
 PATCHES=(
     "${FILESDIR}/${PN}-0.14-cmake-static-libs.patch"
@@ -34,7 +34,7 @@ multilib_src_configure() {
         -DBUILD_DOCUMENTATION=$(multilib_native_usex doc)
         -DBUILD_STATIC_LIBS=$(usex static-libs)
         -DDISABLE_WERROR=ON
-        -DENABLE_RDRAND=$(usex cpu-flags-x86-rdrand)
+        -DENABLE_RDRAND=$(usex cpu_flags_x86_rdrand)
         -DENABLE_THREADING=$(usex threads)
     )
 
diff --git a/dev-libs/json-c/json-c-.ebuild 
b/dev-libs/json-c/json-c-.ebuild
index 51583e0b0ad..b39b8ba779c 100644
--- a/dev-libs/json-c/json-c-.ebuild
+++ b/dev-libs/json-c/json-c-.ebuild
@@ -12,7 +12,7 @@ EGIT_REPO_URI="https://github.com/json-c/json-c.git;
 
 LICENSE="MIT"
 SLOT="0/5"
-IUSE="cpu-flags-x86-rdrand doc static-libs threads"
+IUSE="cpu_flags_x86_rdrand doc static-libs threads"
 
 MULTILIB_WRAPPED_HEADERS=(
     /usr/include/json-c/config.h
@@ -27,7 +27,7 @@ multilib_src_configure() {
         -DBUILD_DOCUMENTATION=$(multilib_native_usex doc)
         -DDISABLE_WERROR=ON
         -DENABLE_THREADING=$(usex threads)
-        -DENABLE_RDRAND=$(usex cpu-flags-x86-rdrand)
+        -DENABLE_RDRAND=$(usex cpu_flags_x86_rdrand)
         -DBUILD_STATIC_LIBS=$(usex static-libs)
     )
 
diff --git a/dev-libs/json-c/metadata.xml b/dev-libs/json-c/metadata.xml
index 4165aa7d278..ca10c6aa7ae 100644
--- a/dev-libs/json-c/metadata.xml
+++ b/dev-libs/json-c/metadata.xml
@@ -13,9 +13,6 @@
 proxy-ma...@gentoo.org
 Proxy Maintainers
   
-  
-    Enable RDRAND Hardware RNG Hash 
Seed
-  
   
 "A JSON implementation in C" is probably the better description, and then
 "JSON-C implements a reference counting object model that allows you to
-- 
2.26.2



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCHv2 2/4] dev-haskell/cryptonite: Change USE to cpu_flags_x86_rdrand

[Francisco Blas Izquierdo Riera (klondike)]

Package-Manager: Portage-2.3.99, Repoman-2.3.23
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) 
---
 dev-haskell/cryptonite/cryptonite-0.21.ebuild    | 8 
 dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild | 6 +++---
 dev-haskell/cryptonite/metadata.xml  | 1 -
 3 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/dev-haskell/cryptonite/cryptonite-0.21.ebuild 
b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
index 531dfe8cfb7..3198705f21b 100644
--- a/dev-haskell/cryptonite/cryptonite-0.21.ebuild
+++ b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
@@ -1,10 +1,10 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
 
 # ebuild generated by hackport 0.6.
-#hackport: flags: 
-check_alignment,-old_toolchain_inliner,+support_deepseq,support_aesni:cpu_flags_x86_aes,support_pclmuldq:cpu_flags_x86_sse4_1,support_rdrand:cpu-flags-x86-rdrand,support_blake2_sse:cpu_flags_x86_sse2
+#hackport: flags: 
-check_alignment,-old_toolchain_inliner,+support_deepseq,support_aesni:cpu_flags_x86_aes,support_pclmuldq:cpu_flags_x86_sse4_1,support_rdrand:cpu_flags_x86_rdrand,support_blake2_sse:cpu_flags_x86_sse2
 
 CABAL_FEATURES="lib profile haddock hoogle hscolour test-suite"
 inherit haskell-cabal
@@ -16,7 +16,7 @@ SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
 LICENSE="BSD"
 SLOT="0/${PV}"
 KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux"
-IUSE="cpu-flags-x86-rdrand cpu_flags_x86_aes cpu_flags_x86_sse2 
cpu_flags_x86_sse4_1 +integer-gmp"
+IUSE="cpu_flags_x86_rdrand cpu_flags_x86_aes cpu_flags_x86_sse2 
cpu_flags_x86_sse4_1 +integer-gmp"
 
 RDEPEND=">=dev-haskell/memory-0.8:=[profile?]
 >=dev-lang/ghc-7.4.1:=
@@ -43,5 +43,5 @@ src_configure() {
     $(cabal_flag cpu_flags_x86_sse2 support_blake2_sse) \
     --flag=support_deepseq \
     $(cabal_flag cpu_flags_x86_sse4_1 support_pclmuldq) \
-        $(cabal_flag cpu-flags-x86-rdrand support_rdrand)
+        $(cabal_flag cpu_flags_x86_rdrand support_rdrand)
 }
diff --git a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild 
b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
index 8d097bb5cfa..da6a90056ed 100644
--- a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
+++ b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
@@ -4,7 +4,7 @@
 EAPI=7
 
 # ebuild generated by hackport 0.6.1.
-#hackport: flags: 
-check_alignment,-old_toolchain_inliner,+support_deepseq,support_aesni:cpu_flags_x86_aes,support_pclmuldq:cpu_flags_x86_sse4_1,support_sse:cpu_flags_x86_sse,support_rdrand:cpu-flags-x86-rdrand
+#hackport: flags: 
-check_alignment,-old_toolchain_inliner,+support_deepseq,support_aesni:cpu_flags_x86_aes,support_pclmuldq:cpu_flags_x86_sse4_1,support_sse:cpu_flags_x86_sse,support_rdrand:cpu_flags_x86_rdrand
 
 CABAL_FEATURES="lib profile haddock hoogle hscolour test-suite"
 inherit haskell-cabal
@@ -16,7 +16,7 @@ SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
 LICENSE="BSD"
 SLOT="0/${PV}"
 KEYWORDS="~amd64 ~x86"
-IUSE="+cpu-flags-x86-rdrand +cpu_flags_x86_aes cpu_flags_x86_sse 
cpu_flags_x86_sse4_1 +integer-gmp"
+IUSE="+cpu_flags_x86_rdrand +cpu_flags_x86_aes cpu_flags_x86_sse 
cpu_flags_x86_sse4_1 +integer-gmp"
 
 RDEPEND=">=dev-haskell/basement-0.0.6:=[profile?]
 >=dev-haskell/memory-0.14.18:=[profile?]
@@ -40,6 +40,6 @@ src_configure() {
     $(cabal_flag cpu_flags_x86_aes support_aesni) \
     --flag=support_deepseq \
     $(cabal_flag cpu_flags_x86_sse4_1 support_pclmuldq) \
-        $(cabal_flag cpu-flags-x86-rdrand support_rdrand) \
+        $(cabal_flag cpu_flags_x86_rdrand support_rdrand) \
     $(cabal_flag cpu_flags_x86_sse support_sse)
 }
diff --git a/dev-haskell/cryptonite/metadata.xml 
b/dev-haskell/cryptonite/metadata.xml
index c845b334ecd..8e02ebe625c 100644
--- a/dev-haskell/cryptonite/metadata.xml
+++ b/dev-haskell/cryptonite/metadata.xml
@@ -29,7 +29,6 @@
     Evaluate the security related to your requirements before using.
 
 
-        allow compilation with RDRAND on 
system and architecture that supports it
     Whether or not to use GMP for some 
functions
 
 
-- 
2.26.2





signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [PATCH 4/4] x86: Add support for 'rdrand'

[Francisco Blas Izquierdo Riera (klondike)]

Notice that this is for cpuflags2cpuid
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) 
---
 src/x86.c  | 1 +
 tests/x86/amd-colfax.txt   | 2 +-
 tests/x86/xeon-e-2176g.txt | 2 +-
 tests/x86/xeon-silver-4410.txt | 2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/x86.c b/src/x86.c
index 72f67d1..ac8db9f 100644
--- a/src/x86.c
+++ b/src/x86.c
@@ -73,6 +73,7 @@ struct flag_info flags[] = {
 { "pclmul", INTEL_ECX, (1 << 1) },
 { "popcnt", INTEL_ECX, (1 << 23) }, /* Intel */
 { "popcnt", AMD_ECX, (1 << 5) }, /* ABM on AMD; XXX: manuals say it's 
LZCNT */
+    { "rdrand", INTEL_ECX, (1 << 30) },
 { "sha", INTEL_SUB0_EBX, (1 << 29) },
 { "sse", INTEL_EDX, (1 << 25) },
 { "sse2", INTEL_EDX, (1 << 26) },
diff --git a/tests/x86/amd-colfax.txt b/tests/x86/amd-colfax.txt
index 94194c0..ffdbd52 100644
--- a/tests/x86/amd-colfax.txt
+++ b/tests/x86/amd-colfax.txt
@@ -1,4 +1,4 @@
-expected:aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sha sse sse2 sse3 
sse4_1 sse4_2 sse4a ssse3
+expected:aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 
sse3 sse4_1 sse4_2 sse4a ssse3
 top:0001:00800f82:0b400800:7ed8320b:178bfbff
 sub:0007:::209c01a9::
 top:8001:00800f82:7000:35c233ff:2fd3fbff
diff --git a/tests/x86/xeon-e-2176g.txt b/tests/x86/xeon-e-2176g.txt
index f15f4b8..5157e1c 100644
--- a/tests/x86/xeon-e-2176g.txt
+++ b/tests/x86/xeon-e-2176g.txt
@@ -1,4 +1,4 @@
-expected:aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 
sse4_2 ssse3
+expected:aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 
sse4_1 sse4_2 ssse3
 top:0001:000906ea:07100800:7ffafbff:bfebfbff
 sub:0007:::029c6fbf:4000:9c00
 top:8001:::0121:2c100800
diff --git a/tests/x86/xeon-silver-4410.txt b/tests/x86/xeon-silver-4410.txt
index 2018ae4..189ff3e 100644
--- a/tests/x86/xeon-silver-4410.txt
+++ b/tests/x86/xeon-silver-4410.txt
@@ -1,4 +1,4 @@
-expected:aes avx avx2 avx512f avx512dq avx512cd avx512bw avx512vl f16c fma3 
mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3
+expected:aes avx avx2 avx512f avx512dq avx512cd avx512bw avx512vl f16c fma3 
mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3
 top:0001:00050654:11100800:7ffefbff:bfebfbff
 sub:0007:::d39b:0018:9c002400
 top:8001:::0121:2c100800
-- 
2.26.2





signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 3/4] dev-libs/json-c: Change USE to cpu_flags_x86_rdrand

[Francisco Blas Izquierdo Riera (klondike)]

Package-Manager: Portage-2.3.99, Repoman-2.3.23
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) 
---
 dev-libs/json-c/json-c-0.14-r3.ebuild | 2 +-
 dev-libs/json-c/json-c-.ebuild    | 2 +-
 dev-libs/json-c/metadata.xml  | 3 ---
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/dev-libs/json-c/json-c-0.14-r3.ebuild 
b/dev-libs/json-c/json-c-0.14-r3.ebuild
index 0d4ff648a36..2c666f39db9 100644
--- a/dev-libs/json-c/json-c-0.14-r3.ebuild
+++ b/dev-libs/json-c/json-c-0.14-r3.ebuild
@@ -13,7 +13,7 @@ 
SRC_URI="https://s3.amazonaws.com/json-c_releases/releases/${P}.tar.gz;
 LICENSE="MIT"
 SLOT="0/5"
 KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~mips ppc ppc64 s390 sparc x86 
~amd64-linux ~x86-linux ~ppc-macos"
-IUSE="cpu-flags-x86-rdrand doc static-libs threads"
+IUSE="cpu_flags_x86_rdrand doc static-libs threads"
 
 PATCHES=(
 "${FILESDIR}/${PN}-0.14-cmake-static-libs.patch"
diff --git a/dev-libs/json-c/json-c-.ebuild 
b/dev-libs/json-c/json-c-.ebuild
index 51583e0b0ad..317e7f77329 100644
--- a/dev-libs/json-c/json-c-.ebuild
+++ b/dev-libs/json-c/json-c-.ebuild
@@ -12,7 +12,7 @@ EGIT_REPO_URI="https://github.com/json-c/json-c.git;
 
 LICENSE="MIT"
 SLOT="0/5"
-IUSE="cpu-flags-x86-rdrand doc static-libs threads"
+IUSE="cpu_flags_x86_rdrand doc static-libs threads"
 
 MULTILIB_WRAPPED_HEADERS=(
 /usr/include/json-c/config.h
diff --git a/dev-libs/json-c/metadata.xml b/dev-libs/json-c/metadata.xml
index 4165aa7d278..ca10c6aa7ae 100644
--- a/dev-libs/json-c/metadata.xml
+++ b/dev-libs/json-c/metadata.xml
@@ -13,9 +13,6 @@
 proxy-ma...@gentoo.org
 Proxy Maintainers
   
-  
-    Enable RDRAND Hardware RNG Hash 
Seed
-  
   
 "A JSON implementation in C" is probably the better description, and then
 "JSON-C implements a reference counting object model that allows you to
-- 
2.26.2





signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 2/4] dev-haskell/cryptonite: Change USE to cpu_flags_x86_rdrand

[Francisco Blas Izquierdo Riera (klondike)]

Package-Manager: Portage-2.3.99, Repoman-2.3.23
Signed-off-by: Francisco Blas Izquierdo Riera (klondike) 
---
 dev-haskell/cryptonite/cryptonite-0.21.ebuild    | 4 ++--
 dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild | 2 +-
 dev-haskell/cryptonite/metadata.xml  | 1 -
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/dev-haskell/cryptonite/cryptonite-0.21.ebuild 
b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
index 531dfe8cfb7..c3497dae415 100644
--- a/dev-haskell/cryptonite/cryptonite-0.21.ebuild
+++ b/dev-haskell/cryptonite/cryptonite-0.21.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=7
@@ -16,7 +16,7 @@ SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
 LICENSE="BSD"
 SLOT="0/${PV}"
 KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux"
-IUSE="cpu-flags-x86-rdrand cpu_flags_x86_aes cpu_flags_x86_sse2 
cpu_flags_x86_sse4_1 +integer-gmp"
+IUSE="cpu_flags_x86_rdrand cpu_flags_x86_aes cpu_flags_x86_sse2 
cpu_flags_x86_sse4_1 +integer-gmp"
 
 RDEPEND=">=dev-haskell/memory-0.8:=[profile?]
 >=dev-lang/ghc-7.4.1:=
diff --git a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild 
b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
index 8d097bb5cfa..3cdbcf44b91 100644
--- a/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
+++ b/dev-haskell/cryptonite/cryptonite-0.26-r1.ebuild
@@ -16,7 +16,7 @@ SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz;
 LICENSE="BSD"
 SLOT="0/${PV}"
 KEYWORDS="~amd64 ~x86"
-IUSE="+cpu-flags-x86-rdrand +cpu_flags_x86_aes cpu_flags_x86_sse 
cpu_flags_x86_sse4_1 +integer-gmp"
+IUSE="+cpu_flags_x86_rdrand +cpu_flags_x86_aes cpu_flags_x86_sse 
cpu_flags_x86_sse4_1 +integer-gmp"
 
 RDEPEND=">=dev-haskell/basement-0.0.6:=[profile?]
 >=dev-haskell/memory-0.14.18:=[profile?]
diff --git a/dev-haskell/cryptonite/metadata.xml 
b/dev-haskell/cryptonite/metadata.xml
index c845b334ecd..8e02ebe625c 100644
--- a/dev-haskell/cryptonite/metadata.xml
+++ b/dev-haskell/cryptonite/metadata.xml
@@ -29,7 +29,6 @@
     Evaluate the security related to your requirements before using.
 
 
-        allow compilation with RDRAND on 
system and architecture that supports it
     Whether or not to use GMP for some 
functions
 
 
-- 
2.26.2



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 1/4] CPU_FLAGS_X86: add 'rdrand' flag

[Francisco Blas Izquierdo Riera (klondike)]

Introduce 'rdrand' flag that corresponds to RDRAND instruction.
This currently has two users.

Signed-off-by: Francisco Blas Izquierdo Riera (klondike) 
---
 profiles/desc/cpu_flags_x86.desc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/profiles/desc/cpu_flags_x86.desc b/profiles/desc/cpu_flags_x86.desc
index 156b677e5a4..5c8a9bceaee 100644
--- a/profiles/desc/cpu_flags_x86.desc
+++ b/profiles/desc/cpu_flags_x86.desc
@@ -21,6 +21,7 @@ mmxext - Use the Extended MMX instruction set (a subset of 
SSE) ([mmxext] or [ss
 padlock - Use VIA padlock instructions ([phe] in cpuinfo)
 pclmul - Use Carry-less Multiplication instructions ([pclmulqdq] in cpuinfo)
 popcnt - Enable popcnt instruction support ([abm] or [popcnt] in cpuinfo)
+rdrand - Use the RDRAND instruction for generating random numbers
 sha - Use the SHA-NI instruction set
 sse - Use the SSE instruction set
 sse2 - Use the SSE2 instruction set
-- 
2.26.2




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 0/4] CPU_FLAGS_X86: Introduce 'rdrand' flag

[Francisco Blas Izquierdo Riera (klondike)]

Hi!

We have currently two packages that have USE cpu-flags-x86-rdrand as there is 
no USE_EXPAND version available. This pattern is likely to confuse users as 
they may not be aware of the difference between dashes and underscores.

Affected packages:
dev-haskell/cryptonite
dev-libs/json-c

The following set of patches:

1 Add the cpu_flags_x86_rdrand use flag to the USE_EXPAND variable.
2 and 3 Make affected packages use the new USE flag
4 Provides detection on cpuid2cpuflags

Patches 1 to 3 are available as a pull request at: 
https://github.com/gentoo/gentoo/pull/16686

Patch 4 is available as a pull request at: 
https://github.com/mgorny/cpuid2cpuflags/pull/16

(Using GitHub mostly to make following the patches easier, keep the discussion 
here)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: obsolete news items

[Francisco Blas Izquierdo Riera (klondike)]

El 31/5/19 a las 11:47, Ulrich Mueller escribió:
> Would it be reasonable to use the same schedule as for profiles/updates
> in future, namely to remove everything older than 5 years? Of course,
> that shouldn't stop anyone from removing a news item earlier if it has
> become irrelevant.


Hi Ulrich!

Unless blueness has something to say I think we can drop
"2017-08-19-hardened-sources-removal" too. Hardened sources has been
gone since December 2018 and the package has been masked since August 2017.

Klondike




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-dev-announce] (Lots of) Packages up for grabs due to net-mail@ project disbanding

[Francisco Blas Izquierdo Riera (klondike)]

El 26/3/19 a las 22:15, Ralph Seichter escribió:
> * Francisco Blas Izquierdo Riera:
>
> All of my systems, and a big part of my business, depend on Postfix. I
> don't want to start a tug-of-war, but I have been building and using
> Postfix for roughly ten years now. I'm *certain* I'll do a good job.
Good for me xD I think I have been building and using postfix for more
than 10 years but I just don't find it so critical given my usage
(mostly receiving and sending my personal mail). I just stood up to make
sure somebody would maintain it (hence why I suuggested Eras as most of
the work on the package in the last years has been his).



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-dev-announce] (Lots of) Packages up for grabs due to net-mail@ project disbanding

[Francisco Blas Izquierdo Riera (klondike)]

El 26/3/19 a las 21:02, Michał Górny escribió:
> mail-filter/opendkim

I'm unsure if anybody feels responsible for this one. Upstream is pretty
silent and made no releases since 2015.

In a modern mail system it is important to be able to sign outgoing
e-mail with DKIM as things like mailing lists may fail otherwise. So I
can take maintainership if somebody is willing to proxy for me.


> mail-mta/postfix

Some of my systems depend on this one so unless eras wants to take care
of it, I can try to do that. I doubt I'll do as good of a job as he has
done so far.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-analyzer/{libnasl/nessus*,prelude-nessus}, sec-policy/selinux-nessus

[Francisco Blas Izquierdo Riera (klondike)]

El 16/3/19 a las 20:51, Hasan Ç. escribió:
> Hi,
>
> net-analyzer/openvas is perfectly suitable for nessus users to migrate.
> I updated all openvas components to latest stables.
>
> Regards,
> 
> Hasan ÇALIŞIR
> Proxy Maintainer | OpenVAS
>
> 16 Mar 2019 Cts 10:10 PM tarihinde Francisco Blas Izquierdo Riera
> (klondike) mailto:klond...@gentoo.org>> şunu yazdı:
>
> Hi Michał
>
> El 16/3/19 a las 20:06, Michał Górny escribió:
> > # The current Gentoo version of Nessus is from 2006 (!).  It does
> > # not build for quite some time (#590226), also -client fails
> with new
> > # openssl (#674424).  Upstream has stopped releasing non-proprietary
> > # versions.  While at it, remove prelude-nessus that practically
> > # has not been touched since 2003.
> > # Removal in 30 days.  Bug #680636.
> > net-analyzer/libnasl
> > net-analyzer/nessus-client
> > net-analyzer/nessus-core
> > net-analyzer/nessus-libraries
> > net-analyzer/nessus-plugins
> > net-analyzer/prelude-nessus
> > sec-policy/selinux-nessus
>
> You should comment that users can migrate to
> net-analyzer/nessus-bin or
> net-analyzer/openvas.
>
>
To be sincere that is much better than nessus-bin, whose only available
versions are 8.0.1 and 6.10.5 none of which can be downloaded anymore:
https://www.tenable.com/downloads/nessus



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: net-analyzer/{libnasl/nessus*,prelude-nessus}, sec-policy/selinux-nessus

[Francisco Blas Izquierdo Riera (klondike)]

Hi Michał

El 16/3/19 a las 20:06, Michał Górny escribió:
> # The current Gentoo version of Nessus is from 2006 (!).  It does
> # not build for quite some time (#590226), also -client fails with new
> # openssl (#674424).  Upstream has stopped releasing non-proprietary
> # versions.  While at it, remove prelude-nessus that practically
> # has not been touched since 2003.
> # Removal in 30 days.  Bug #680636.
> net-analyzer/libnasl
> net-analyzer/nessus-client
> net-analyzer/nessus-core
> net-analyzer/nessus-libraries
> net-analyzer/nessus-plugins
> net-analyzer/prelude-nessus
> sec-policy/selinux-nessus

You should comment that users can migrate to net-analyzer/nessus-bin or
net-analyzer/openvas.




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Hostile takeover of our github mirror. Don't use ebuild from there until new warning!

[Francisco Blas Izquierdo Riera (klondike)]

El 28/06/18 a las 23:15, Francisco Blas Izquierdo Riera (klondike) escribió:
> Hi!
>
> I just want to notify that an attacker has taken control of the Gentoo
> organization in Github and has among other things replaced the portage
> and musl-dev trees with malicious versions of the ebuilds intended to
> try removing all of your files.
>
> Whilst the malicious code shouldn't work as is and GitHub has now
> removed the organization, please don't use any ebuild from the GitHub
> mirror ontained before 28/06/2018, 18:00 GMT  until new warning.
>
> Sincerely,
> Francisco Blas Izquierdo Riera (klondike)
> Gentoo developer.
>
>
Just to keep up with it. There is a more complete article published at
https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hacked.html





signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Hostile takeover of our github mirror. Don't use ebuild from there until new warning!

[Francisco Blas Izquierdo Riera (klondike)]

Hi!

I just want to notify that an attacker has taken control of the Gentoo
organization in Github and has among other things replaced the portage
and musl-dev trees with malicious versions of the ebuilds intended to
try removing all of your files.

Whilst the malicious code shouldn't work as is and GitHub has now
removed the organization, please don't use any ebuild from the GitHub
mirror ontained before 28/06/2018, 18:00 GMT  until new warning.

Sincerely,
Francisco Blas Izquierdo Riera (klondike)
Gentoo developer.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item review: Python 3.6 to become the default target

[Francisco Blas Izquierdo Riera (klondike)]

Hi Michał,

El 15/05/18 a las 08:20, Michał Górny escribió:
> If you are still using Python 3.4, please consider switching to a newer
> version as it is reaching its end-of-life.  The end-of-life dates
> for the currently used versions are:
>
>   Python 3.42019-03-16
>   Python 2.72020-01-01
>   Python 3.52020-09-13 [1]


Keep in mind that this bit is quite useless unless you also display the
news item if dev-lang/python:3.4 is installed.

Also you may want to break the paragraph before "The end-of-lie dates..."




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Gentoo Social Contract, Council: please fix the mess you cause

[Francisco Blas Izquierdo Riera (klondike)]

Dear Gentoo Council,

During the meeting you held on December (see the logs here:
https://projects.gentoo.org/council/meeting-logs/20171210.txt ), you
voted for restricting the gentoo-dev mailing list. Although in said
meeting somebody raised that such a change affected the Gentoo Social
Contract as it referred users to provide comments on the gentoo-dev
mailing list (see
https://www.gentoo.org/get-started/philosophy/social-contract.html )
this was dismissed by one of your members (which has, in the past,
called the Gentoo Social Contract "dead law") by saying that the right
place to send such comments is gentoo-project (but willingly ignoring
that such a reference has been part of it since the first archived draft
version
https://web.archive.org/web/20021112053724/http://www.gentoo.org:80/main/en/contract.xml
and the first non draft version
https://web.archive.org/web/20031203222653/http://www.gentoo.org:80/main/en/contract.xml
which predate the gentoo-project mailing list) and apparently ignored by
the rest.

This was noted after the vote had happened and to the best of my
knowledge hadn't been raised before. Despite that, on the next meeting
where the topic was discussed a different council member stated that
said person did not "any pertinent new information since last vote".

Now, three months after, no action has been carried by the council on
this very specific regard despite being made aware of it. This clearly
shows that the current council members not only take hastened decissions
without even doing propper research, they don't try to clean up the mess
they cause after their own decissions.

Given the inaction by the council, I'm propossing to apply either of
these two changes to the Gentoo Social contract.

First propossal:
Replace "Comments are welcome. Please send them to our
gentoo-dev@lists.gentoo.org  mailing
list." by "Comments by selected people are welcome. Please send them to
our gentoo-dev@lists.gentoo.org 
mailing list.". Which clearly reflects the new ivory tower philosophy
the Council is making the Gentoo Project take.

Second propossal:
Replace "Comments are welcome. Please send them to our
gentoo-dev@lists.gentoo.org  mailing
list." by "Comments by selected people are welcome. Please send them to
our gentoo-proj...@lists.gentoo.org
 mailing list CCing the Gentoo
Foundation trustees on trust...@lists.gentoo.org
.". Which ensures trustees get a
notification of such propossals and still keeps the social contract open
to comments for anybody.

Please note, in the spirit of the second propossal I'm CCing gentoo-project.

Klondike



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Francisco Blas Izquierdo Riera (klondike)]

El 24/03/18 a las 04:34, Aaron Bauman escribió:
>
> On March 23, 2018 11:11:16 PM EDT, "Francisco Blas Izquierdo Riera 
> (klondike)" <klond...@gentoo.org> wrote:
>> El 20/03/18 a las 09:52, Kristian Fiskerstrand escribió:
>>> This was not put in effect on 23 January 2018, however I have now
>>> requested infra to put it in place in [bug 650964]. Users wishing
>>> posting permissions are encouraged to find a mentor and register in
>> [bug
>>> 644070]
>>>
>>> References:
>>> [bug 650964] https://bugs.gentoo.org/650964
>>> [bug 644070] https://bugs.gentoo.org/644070
>> I can't wait for it to finally happen. I have been wishing to be able
>> to
>> genuinely ignore this list for so long.
>>
>> Finally, the Council will give me a propper reason to be able to do so!
> How does the councils decision give you a reason to do so?
Because if I want to see wizards on top of their unreachable ivory
towers I prefer to go play heroes 2 of might and magic than reading a
mailing list.

(And because a project that gives their back to their community is
condemned to die as no new developers will cover for the retiring ones).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Francisco Blas Izquierdo Riera (klondike)]

El 20/03/18 a las 09:52, Kristian Fiskerstrand escribió:
> This was not put in effect on 23 January 2018, however I have now
> requested infra to put it in place in [bug 650964]. Users wishing
> posting permissions are encouraged to find a mentor and register in [bug
> 644070]
>
> References:
> [bug 650964] https://bugs.gentoo.org/650964
> [bug 644070] https://bugs.gentoo.org/644070

I can't wait for it to finally happen. I have been wishing to be able to
genuinely ignore this list for so long.

Finally, the Council will give me a propper reason to be able to do so!




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 20/08/17 a las 00:44, Michał Górny escribió:
> 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'.
>
I have addressed this. Thanks for the input :)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

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

[Francisco Blas Izquierdo Riera (klondike)]

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

[Francisco Blas Izquierdo Riera (klondike)]

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) <klond...@gentoo.org> 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] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 16/08/17 a las 18:01, Duncan escribió:
> Francisco Blas Izquierdo Riera (klondike) posted on Wed, 16 Aug 2017
> 12:09:57 +0200 as excerpted:
>
>> s you may know the core of sys-kernel/hardened-sources have been the
>> grsecuirty patches.
> New typo: s/grsecuirty/grsecurity/
>
Thanks, I fixed it :)

@all I'll get this pushed up before going to bed tomorrow so I guess
this is the last chance for any comments left :)

Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera <klond...@gentoo.org>
Posted: 2017-08-19
Revision: 4
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources
Display-If-Profile: hardened/linux/*

As you may know the core of sys-kernel/hardened-sources have been the
grsecurity patches.

Sadly, their developers have stopped making these patches freely
available [1]. This is a full stop of any public updates and not only
stable ones as was announced two years ago[2].

As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove them from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the stable
4.9 branch of the kernel; minipli, another grsecurity user, is forward
porting the patches on [3].

Strcat from Copperhead OS is making his own version of the patches
forward ported to the latest version of the Linux tree at [4].

The Gentoo Hardened team can't make any statement regarding the
security, reliability or update availability of either those patches
as we aren't providing them and can't therefore make any
recommendation regarding their use.

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. Also, all PaX related packages other
than the hardened-sources will remain for the time being.

[1] https://grsecurity.net/passing_the_baton.php
[2] https://www.gentoo.org/support/news-items/2015-10-21-future-support-of-
hardened-sources-kernel.html
[3] https://github.com/minipli/linux-unofficial_grsec
[4] https://github.com/copperhead/linux-hardened

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 16/08/17 a las 09:40, Marek Szuba escribió:
> Two tiny bits of formal nitpicking from my side:
>  - it's "grsecurity" (not a typo, they do use a lowercase g except when
> the name appears at the beginning of a sentence), not "grsec";
>  - the patches were not *distributed by* grsecurity, they *are*
> grsecurity. The vendor's name is Open Source Security, Inc.

Nowadays it is, but this hasn't always been the case. You'll notice the
presence of a /dev/grsec and you'll also find grsec referenced accross
some old patches. Anyways I changed it.

The same applies to Open Source Security, Inc. the company was founded
on 2008 but grsecurity has been around for much longer. That's why I
prefer to refer to Brad Spengler and The PaX team here as they are still
the real upstream behind Open Source Security, Inc.


Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera 
Posted: 2017-08-19
Revision: 4
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources
Display-If-Profile: hardened/linux/*

As you may know the core of sys-kernel/hardened-sources have been the
grsecuirty patches.

Sadly, their developers have stopped making these patches freely
available [1]. This is a full stop of any public updates and not only
stable ones as was announced two years ago[2].

As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove them from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the stable
4.9 branch of the kernel; minipli, another grsecurity user, is forward
porting the patches on [3].

Strcat from Copperhead OS is making his own version of the patches
forward ported to the latest version of the Linux tree at [4].

The Gentoo Hardened team can't make any statement regarding the
security, reliability or update availability of either those patches
as we aren't providing them and can't therefore make any
recommendation regarding their use.

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. Also, all PaX related packages other
than the hardened-sources will remain for the time being.

[1] https://grsecurity.net/passing_the_baton.php
[2] https://www.gentoo.org/support/news-items/2015-10-21-future-support-of-
hardened-sources-kernel.html
[3] https://github.com/minipli/linux-unofficial_grsec
[4] https://github.com/copperhead/linux-hardened

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 15/08/17 a las 18:08, Ulrich Mueller escribió:
>>>>>> On Tue, 15 Aug 2017, Francisco Blas Izquierdo Riera (klondike) wrote:
>> Updated the news item following comments from dilfridge, mrueg and
>> floppym. Also made it display to users of hardened profiles.
> Some very minor comments:
>
>> Author: Francisco Blas Izquierdo Riera (klondike) <klond...@gentoo.org>
> Format of the line is "Real Name <email@address>", so I'd suggest to
> drop the nick in parentheses, especially since it is there in the
> e-mail address anyway.
>
>> Because of that we will be masking the hardened-sources on the 27th of
>> August and will proceed to remove then from the tree by the end of
>> September. [...]
> s/then/them/
>
>> As an alternative, for users happy keeping themselves on the  stable
>> 4.9 branch of the kernel minipli, another Grsec user, is forward
>> porting the patches on [3].
> I had difficulties parsing this sentence. Insert a comma after
> "kernel"? Also there is spurious whitespace before "stable".
>
> Ulrich

Thanks for your input, I have addressed your comments on the attached
news item.

I have also added a note regarding the other PaX related packages as
these won't stil be removed.


Klondike

Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera <klond...@gentoo.org>
Posted: 2017-08-19
Revision: 3
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources
Display-If-Profile: hardened/linux/*

As you may know the core of sys-kernel/hardened-sources have been the
patches published by Grsec.

Sadly, their developers have stopped making these patches freely
available [1]. This is a full stop of any public updates and not only
stable ones as was announced two years ago[2].

As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove them from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the stable
4.9 branch of the kernel; minipli, another Grsec user, is forward
porting the patches on [3].

Strcat from Copperhead OS is making his own version of the patches
forward ported to the latest version of the Linux tree at [4].

The Gentoo Hardened team can't make any statement regarding the
security, reliability or update availability of either those patches
as we aren't providing them and can't therefore make any
recommendation regarding their use.

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. Also, all PaX related packages other
than the hardened-sources will remain for the time being.

[1] https://grsecurity.net/passing_the_baton.php
[2] https://www.gentoo.org/support/news-items/2015-10-21-future-support-of-
hardened-sources-kernel.html
[3] https://github.com/minipli/linux-unofficial_grsec
[4] https://github.com/copperhead/linux-hardened

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

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).

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.
> 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




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

El 15/08/17 a las 17:01, Francisco Blas Izquierdo Riera (klondike) escribió:
> 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.
>
> This is my first time writting a news item so all input will be appreciated.
>
> As for the rationale behind this, we need to clearly inform users as to
> the options available for hardening their system kernels after the
> removal of the hardened-sources.
>
> Sincerely,
> Klondike
>
Updated the news item following comments from dilfridge, mrueg and
floppym. Also made it display to users of hardened profiles.

Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera (klondike) <klond...@gentoo.org>
Posted: 2017-08-19
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources
Display-If-Profile: hardened/linux/*

As you may know the core of sys-kernel/hardened-sources have been the
patches published by Grsec.

Sadly, their developers have stopped making these patches freely
available [1]. This is a full stop of any public updates and not only
stable ones as was announced two years ago[2].

As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove then from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the  stable
4.9 branch of the kernel minipli, another Grsec user, is forward
porting the patches on [3].

Strcat from Copperhead OS is making his own version of the patches
forward ported to the latest version of the Linux tree at [4].

The Gentoo Hardened team can't make any statement regarding the
security, reliability or update availability of either those patches
as we aren't providing them and can't therefore make any
recommendation regarding their use.

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.

[1] https://grsecurity.net/passing_the_baton.php
[2] https://www.gentoo.org/support/news-items/2015-10-21-future-support-of-
hardened-sources-kernel.html
[3] https://github.com/minipli/linux-unofficial_grsec
[4] https://github.com/copperhead/linux-hardened

signature.asc
Description: OpenPGP digital signature

[gentoo-dev] New item for sys-kernel/hardened-sources removal

[Francisco Blas Izquierdo Riera (klondike)]

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.

This is my first time writting a news item so all input will be appreciated.

As for the rationale behind this, we need to clearly inform users as to
the options available for hardening their system kernels after the
removal of the hardened-sources.

Sincerely,
Klondike

Title: sys-kernel/hardened-sources removal
Author: Francisco Blas Izquierdo Riera (klondike) <klond...@gentoo.org>
Posted: 2017-08-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-kernel/hardened-sources

As you may know the core of sys-kernel/hardened-sources have been the
patches published by Grsec.

Sadly, their developers have stopped making these freely available [1].
As a result, the Gentoo Hardened team is unable to keep providing
further updates of the patches, and although the hardened-sources have
proved (when using a hardened toolchain) being resistant against
certain attacks like the stack guard page jump techniques proposed by
Stack Clash, we can't ensure a regular patching schedule and therefore,
the security of the users of these kernel sources.

Because of that we will be masking the hardened-sources on the 27th of
August and will proceed to remove then from the tree by the end of
September. Obviously, we will reinstate the package again if the
developers decide to make their patches publicly available again.

Our recommendation is that users should consider using instead
sys-kernel/gentoo-sources.

As an alternative, for users happy keeping themselves on the  stable
4.9 branch of the kernel minipli, another Grsec user, is forward
porting the patches on [2]. The Gentoo Hardened team can't make any
statement regarding the security, reliability or update availability
of those patches as we aren't providing them and can't therefore
make any recommendation regarding their use.

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.

Finally we'd like to send a sincere thank you to Brad Spengler and
the PaX Team for making their hardening patches freely available all
this time.



[1] https://grsecurity.net/passing_the_baton.php
[2] https://github.com/minipli/linux-unofficial_grsec

signature.asc
Description: OpenPGP digital signature

Re: [gentoo-core] [gentoo-dev] Git Migration: go-live!

[Francisco Blas Izquierdo Riera (klondike)]

El 09/08/15 a las 12:02, Mike Frysinger escribió:
 On 09 Aug 2015 11:31, Marc Schiffbauer wrote:
 * Michael Weber schrieb am 09.08.15 um 11:00 Uhr:
 On 08/09/2015 07:36 AM, Robin H. Johnson wrote:
 I'm only 90% sure that everything works, but I've spent almost the 
 entire day on it, and there's more to go tomorrow.
 Thanks a lot!

 use case: my cvs tree had uncommitted ebuild work (yes, you caught me
 actually doing something).
 now `cvs diff` no longer works, how can i track down my local changes?
 besides diffing against git tree, brain memory aka shell history and
 find -newer?
 I'd say: 

 - tar your *.ebuild and files/* stuff away
 - then git clone the new git repo.
 - untar your files in the new git repo
 - use git diff
 there will be a ton of cvs keyword noise in there though.  need to run
 a sed on the files to clear it out.

 it also will include noise where your local checkout was behind the latest
 tree, so it'll only really work if you ran `cvs up` in the whole tree just
 before it was shutdown.
 -mike
Out of curiosity, is it impossible to have a read only CVS server with
the state at the time of the freeze?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Francisco Blas Izquierdo Riera (klondike)]

Hi!

El 29/03/14 05:13, Samuli Suominen escribió:
 I took the liberty to unbreak the tree for you. Don't ever touch my
 packages again unless
 they are broken.
Udev is broken:
* They have known off by one string handling errors on their libraries,
the developers were warned of that but have chosen to ignore the issue.
The issue is still on
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/strxcpyx.c
on the function size_t strpcpyf(char **dest, size_t size, const char
*src, ...) which can overflow the string boundaries in some case. This
issue keeps coming up from time to time thanks to their nice efforts
for cahnging the whole thing instead of fixing bugs. Also after a year
nothing has been done.
* They keep losing cohesion
(http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) by
inserting more and more unrelated software into Udev/systemd. This helps
things like the above happen again.
* They have the bad habit of recoding functions that are already
provided by their only supported c library. This helps things like the
above happen.ç
* They keep reengineering everything reintroducing bugs that were fixed
on previous iterations.

Thus given the potential security issues udev (and systemd) have, the
poor design decissions, and the lack of interest in their maintainers of
fixing these, I'd strongly recommend masking it as was done with packets
like wordpress or at least putting a big warning to the users.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Gentoo Hangouts

[Francisco Blas Izquierdo Riera (klondike)]

El 24/06/13 19:10, Sven Vermeulen escribió:
 On Mon, Jun 24, 2013 at 12:04:04PM +0100, Markos Chandras wrote:
 I like the idea. It might help bring developers and users closer.
 Me too, if I can ever contribute to it, or help users with their Gentoo
 (Hardened/SELinux/IMA/EVM/...) through it, I'll be happy to work with it.
I also find this a good idea, in the hardened team we have managed to
keep a familiar feeling amongst us thanks to conferences and I know some
devs don't have the chance to assist to these so having some small talk
amongst us over videoconference may help strengthen that feeling.

That said, I refuse to keep the hardened team meeting on VC. I have
enough tweeting main point in unreal time to do the same with VC xD



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Francisco Blas Izquierdo Riera (klondike)]

El 18/11/12 04:39, Greg KH escribió:
 Anyway, I now see a _very_ dangerous commit in the Copyright branch
 that better not get merged into the tree, as it's wrong, and illegal
 under all countries that follow the normal body of Copyright Law.  It
 should be removed right now before someone gets into trouble, not the
 least of which would be the orginization that the copyright is now being
 attributed to.
So I made a mistake coming out from a missunderstanding on a commit on a
branch that didn't even get merged since I was expecting approval from
somebody else before that. Cool. The amount of damage caused by this
action is around the same as publishing a patch and not applying it.
 Come on people, this is basic copyright law, it's not something
 radically new.  It's something that _all_ software developers should
 know, either from school, or any company they have ever worked at.
Check european copyright laws please, they are quite different from
yours. I at least have had to read and understand the spanish copyright
laws a few times and its not funny. So please don't speak of a normal
body of copyright law there is not such thing and some of us have enough
with the normalizations USA based lobbies are trying  to impose on ours.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-dev-announce] New subproject: Hardened uClibc

[Francisco Blas Izquierdo Riera (klondike)]

El 03/11/12 14:35, Anthony G. Basile escribió:
 Hi everyone,

 I'd like to announce a new subproject of Hardened Gentoo: Hardened
 uClibc.  It is an effort to port both tool chain and kernel hardening
 to uClibc based systems for a variety of architectures, treating
 uClibc more as a drop in alternative to glibc, and not necessarily as
 embedded. Embedded systems aim to produce kernels and user lands
 with tiny footprints, and so tend to use busybox as their Swiss Army
 Knife of common UNIX utilities. While not excluding this possibility,
 we aim at making most (all?) of Gentoo's packages both hardened and
 uClibc compatible.

 The subproject crosses three areas: hardened, embedded and releng. 
 For a while I was just manually building and tarballing chroots, but
 I'm migrating to proper stage3's built using catalyst.  The following
 table gives a brief summary of the current state of affairs:

 Arch  ABI(s) Medium
 amd64  Generic   stage3 desktop
 arm   armv7a   stage4
 mips  mips32r2 mipsel32r2  stage4
 x86   i686stage3
 ppc in progress

 These are available on the mirrors under
 ${MIRROR}/expiermental/${ARCH}/uclibc.

 uClibc has made it quite a ways in the last few years. For amd64, I
 built an entire desktop system based on XFCE4 which is also on the
 mirrors.  However, this is still work in progress and should be
 considered experimental. Eg. upgrading the desktop from glib-2.30.3 to
 glib-2.32.4-r1 breaks.  The stage3's are the closest to being stable.

 The project homepage is at http://www.gentoo.org/proj/en/hardened/uclibc/
Back then I already discussed how this project description leads to
confusion on users, and as such I opened bug 441014
https://bugs.gentoo.org/show_bug.cgi?id=441014 I'm still waiting for
blueness answers on this since he was the one who asked me to open said
bug. Meanwhile missinformation keeps being spread out.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Package ranking by number of ebuilds on the portage tree

[Francisco Blas Izquierdo Riera (klondike)]

So I have been doing some bash scripting out of some comment in a
conversation to count (and rank) the packages by the number of ebuilds
they have (and thus of versions of said package). The results can be
seen at http://dev.gentoo.org/~klondike/ebuildrank.txt and if there is
interest I can try to automate the generation of the ranking daily
(though I'd like infra's comments on that).

As some extra candy I have calculated which is the percentage of
packages holding the same number of packages, it is impressive seeing
how more than 50% of the ebuilds have only 1 and more than 75% have two
or less! If I recall my stats classes the number of versions in a
package seems to follow some kind of poison distribution.
175 .00635687496026953100
68 .00635687496026953100
31 .00635687496026953100
28 .00635687496026953100
25 .00635687496026953100
23 .01271374992053906200
22 .01271374992053906200
21 .01271374992053906200
20 .01271374992053906200
19 .01271374992053906200
16 .05721187464242578300
15 .04449812472188672000
14 .04449812472188672000
13 .07628249952323437700
12 .08263937448350390900
11 .12078062424512109800
10 .15892187400673828700
9 .22884749856970313300
8 .31784374801347657400
7 .76282499523234377900
6 2.20583561121352742900
5 2.47282435954484775200
4 4.54516559659271502100
3 11.39151992880300044400
2 25.75170046405187209900
1 51.64325217722967389200

Hope you enjoy the numbers as much as I enjoyed calculating them!
klondike





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies

[Francisco Blas Izquierdo Riera (klondike)]

El 12/03/12 17:29, Samuli Suominen escribió:
 # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012)
 # media-sound/lilypond required for this is masked in ../package.mask
 # for removal
 app-text/asciidoc test

asciidoc only depends with the test use flag set so why don't just
remove the test USE and the test function from the ebuilds instead?
If somebody is willing to proxy the changes for me I can patch the tree
with this fix.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Free Gentoo

[Francisco Blas Izquierdo Riera (klondike)]

El 21/01/12 19:01, . escribió:
 Hello there!

 Is there a chance that Gentoo may become a free distro?

 I'm so unhappy with the fact that there are some non-free packages in
 the main tree.
 The main goal of the GNU project was to replace the proprietary Unix system.
 You are actually ruining this goal.

 I'm also dissatisfied with the name of the distro. Linux is the kernel
 not the whole system.
If it weren't because I know rms won't ever use gmail I'd thought it
could have him under another name since I had this same discussion with
him at FSCONS.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] woodpecker.gentoo.org maintenance / outage

[Francisco Blas Izquierdo Riera (klondike)]

El 18/11/11 17:11, Christian Ruppert escribió:
 What is left is:
 Kernel
Any problem regarding hardened? Need a hand from somebody in the team?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Shutdown of berlios

[Francisco Blas Izquierdo Riera (klondike)]

El 31/10/11 17:43, Alec Warner escribió:
 We can't force people who write Gentoo specific software to host w/us
 (that would be silly.) If upstream is dead then take a tarball and
 clone it into a git repo; nothing is stopping you.
We can, all you need is enough field agents to convince people to do so ;)

And before anybody asks: yes, this comment is a joke.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Moving more hardening features to default?

[Francisco Blas Izquierdo Riera (klondike)]

El 23/10/11 05:56, Steven J Long escribió:
 Will we be able to switch off SSP via config, or will we have to setup our 
 own profile?
This should do the trick:
CFLAGS=$CFLAGS -fno-stack-protector



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Build dependencies and upgrades.

[Francisco Blas Izquierdo Riera (klondike)]

Hi,

Today I have found that build dependencies are left in the system but
won't be upgraded when running emerge -vauD1 world.
This can be inconvenient since security issues fixed in those left over
packages won't be applied properly.
So, is there any reason for this behaviour? Shouldn't build dependencies
either be cleaned with --depclean after building or be upgraded to avoid
possible issues?

Sorry if this gets in here twice, I used an incorrect account.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Build dependencies and upgrades.

[Francisco Blas Izquierdo Riera (klondike)]

El 11/10/11 20:55, Markos Chandras escribió:
 On 10/11/11 19:50, Francisco Blas Izquierdo Riera (klondike) wrote:
  Hi,

  Today I have found that build dependencies are left in the system
  but won't be upgraded when running emerge -vauD1 world. This can be
  inconvenient since security issues fixed in those left over
  packages won't be applied properly. So, is there any reason for
  this behaviour? Shouldn't build dependencies either be cleaned with
  --depclean after building or be upgraded to avoid possible issues?

  Sorry if this gets in here twice, I used an incorrect account.


 Maybe you want the --with-bdeps parameter along with the -D one?. man
 emerge - section Options - parameter -D
That makes sense but then the problem is on the poor documentation we
have in the Internet.
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=1
Here no mention to that option is made
Nor is in:
http://www.gentoo.org/doc/en/gentoo-upgrading.xml

And in fact no mention to the option is made in the doc space at all. I
may also be wrong here but I don't recall finding it when I started with
portage and no notice was issued since then so either I misunderstood
it, kinda likely by then, or it was added later. And the fact it wasn't
commented at all in the documentation didn't help.

The question now is anybody thinks this shouldn't appear in the
handbook? If nobody has a problem I'll prepare a patch.

PS: howarang thanks for the point I found it really odd this was missing.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Build dependencies and upgrades.

[Francisco Blas Izquierdo Riera (klondike)]

El 11/10/11 21:36, Alec Warner escribió:
 On Tue, Oct 11, 2011 at 12:23 PM, Francisco Blas Izquierdo Riera
 (klondike) klond...@gentoo.org wrote:
 El 11/10/11 20:55, Markos Chandras escribió:
 On 10/11/11 19:50, Francisco Blas Izquierdo Riera (klondike) wrote:
 Hi,
 Today I have found that build dependencies are left in the system
 but won't be upgraded when running emerge -vauD1 world. This can be
 inconvenient since security issues fixed in those left over
 packages won't be applied properly. So, is there any reason for
 this behaviour? Shouldn't build dependencies either be cleaned with
 --depclean after building or be upgraded to avoid possible issues?
 Sorry if this gets in here twice, I used an incorrect account.

 Maybe you want the --with-bdeps parameter along with the -D one?. man
 emerge - section Options - parameter -D
 That makes sense but then the problem is on the poor documentation we
 have in the Internet.
 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=1
 Here no mention to that option is made
 Nor is in:
 http://www.gentoo.org/doc/en/gentoo-upgrading.xml

 And in fact no mention to the option is made in the doc space at all. I
 may also be wrong here but I don't recall finding it when I started with
 portage and no notice was issued since then so either I misunderstood
 it, kinda likely by then, or it was added later. And the fact it wasn't
 commented at all in the documentation didn't help.

 The question now is anybody thinks this shouldn't appear in the
 handbook? If nobody has a problem I'll prepare a patch.

 PS: howarang thanks for the point I found it really odd this was missing.


 FYI: there are a truckload of options that are available in portage
 but are not documented in the handbook. I'm not really sure
 replicating the portage manpages in the handbook is necessarily a good
 way to move forward. Ideally we would direct users to just read the
 manpages.
Antarus, an user who has read the whole installation handbook and is new
to the distro should by then have a lot of new ideas in mind to direct
them to man pages written in a more technical way creating even more
confusion. Add to to that any search on how to update / upgrade Gentoo
and you will find the same set of commands almost always:
$ emerge -u world
$ emerge -uD world
With no references to other parameters at all. Which can make users
assume that it is a safe default. If you look in the docs I provided
you'll see it is the case.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] mesa r600 gallium news item

[Francisco Blas Izquierdo Riera (klondike)]

El 25/08/11 23:25, Matt Turner escribió:
 2011/8/25 Chí-Thanh Christopher Nguyễn chith...@gentoo.org:
 Hello,

 Please see the attached news item for review. The news item should be
 published before mesa-7.11 goes stable.
 Corresponding bug report: https://bugs.gentoo.org/show_bug.cgi?id=377349


 Best regards,
 Chí-Thanh Christopher Nguyễn
 Looks good to me.

 Matt
You can point the reader to
http://www.x.org/wiki/RadeonFeature#Decoderringforengineeringvsmarketingnames
in order to know wether his ATI card is or not an r600 ATI card.
Specially since the reference to HD2000 includes some r500 cards.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] contribution to colorgcc

[Francisco Blas Izquierdo Riera (klondike)]

El 07/08/11 02:48, Dmitry Goncharov escribió:
 Is anybody maintaining dev-util/colorgcc?
Yes the shell-tools herd. You can email them at shell-tools (at) g.o



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Delivery reports about your e-mail

[Francisco Blas Izquierdo Riera (klondike)]

El 03/08/11 03:31, c1p...@gentoo.org escribió:
 wi¹~BBº“‚ã°êØvܬ»\‡Š
 ôß(ÇW¨Ý‚é{Ò…Ä�
 ô2‡°¼ÛûÜîÙ‹–õ–~HwX~/؉ý†íE[¬£ÜœŸdd‰¶§ã±8ÒŠ6gîvs
 ã�X„òYFý5ù1çFØŸô
 L`Ce¤ÎA‘]²´e¼s§eµ©ùÍáÍmÉãZÄþ²cxZ:Õ•ƒÙFyÚ‘wû–a—š|×:¤b~ØüœÔ§X‰AQ¬­bR\ž‡|ĉ3u±«Ÿ4æØ7‡˜øU\ö/°tÛnæKß¡^¸Åڌ٤ÚbT;3ºI7%$œÎÆc™Öšoåi
 ´òÆÞ²�{jdÆŠÍ9]‰¼)ŒÒµ†%ùÐJžQÜU™‰PÖÈÛ93°ö´‚*{vnEÝÝtý‚ª
 ‹º9¾tÎÂ3O)ØãÇÐ GTÆP?7YF³ËŠÞÛ†W.Kë{9uè·a#¨óëð[ä:Q5cõ
 $ñï†'I(œ~B÷0fô{­íô¡iòâöÉiKYyرuÀ£:žO�«Ñ)ÒÃ5/ðJKDÒ™þ‚|ì�öóÝÀ0œQ–yPüdÏï‰ìºRg4X¨wVú«9,ëܲX‡¨�ëy(Ê«
  ÷ÀÝȪµ”OIH¨6? ’•‹)ú˜TCEò•mvƒôQ§Õ'ö)Äëpa^3ÓB,]iòZÑøq‘ý;�agvõn0GÍž{HUÍÁk˜^ˆ
 _·k©ÅdÒ´fÙÏM¯Y·9õŠÝßa[ ü×›¿ÁpØml
 –†Ž†F“Æ‚*ùêÔ_ǃEù¡Mt|·PdéfŸž^#£Ðצ‘ NÁ
 Ã8¿º4Ë4þÍÐ]ê6ð0ůÀÙÇ%é2òÔRrgg†6Û¤ 
 :åf˱6RÂRgýwèÉ3÷_Gbp?¾ª™vŸO÷«áþ‘-‡8YW%…çΨ(™Ó¯��²ÖÁ¡B'�#µ$)ÕÚ4Tõ¤Æƒf20We­ÇP*׎ï�µëc?/J»§•©ô™ÙºÁ�kñŒ_Ä•Ñ`Ⱦ:�ÊãíÚK¬b4ýK®fŽ��
 A²Ï{ç£,¼�8W$øª…?à6îØÒª^/U
 ^~SöEʸÅô‡µ×$;ß4›RI_Uã·1¡åb{æ_†…:–{Gþ}û*8Á]¼c†œ™ôãvoGµËËb�ˆ¼d�²äå 
 ñÍpÅ)ÍCF—×år,G²”Ò­ÜbSœÁÔü9NöÒ³!^.ÎÙ8~è�c)N«`CN­“ýΑ%\ Œƒ£®
 Û3¨a$Ú9è•Í T±¬�vàÝfíH}ýˆY˜[Å°a›ö‘8f
 oÇÈf©ïBeÏ—vgPþùøתd�2„}U?׊)°Š“ÏÐœR·†±¥Å 
 ®µÍ©#{Ç¥¨!-,Ö•�WkL7-¬/Ä5˜Dw75´Å^�úšÀ�D æbyÅs/«†SÃF£SŸØÂ`kãB{Û
 ÷í—oO\øC¼µÅUö/ÙKÙ�²Ž%hðÏý%Úó‚°�à,ÓúNnŒ;‚«hAtžé¡PÒYRó¨œ{

Come on they can't be serious... this won't work against Gentoo devs,
will it?


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Delivery reports about your e-mail

[Francisco Blas Izquierdo Riera (klondike)]

El 03/08/11 06:57, Robin H. Johnson escribió:
 On Wed, Aug 03, 2011 at 04:13:19AM +0200, Francisco Blas Izquierdo Riera 
 (klondike) wrote:
 Come on they can't be serious... this won't work against Gentoo devs,
 will it?
 It is concerning that the spammer used a valid list subscriber.

 Crunching all attachments for validation or moderating everything to
 catch this is a lot of work.
What about using an antispam filter reference for moderation. A properly
configured antispam system should have detected a mail like that one as,
at least, a possible virus.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

[Francisco Blas Izquierdo Riera (klondike)]

El 17/06/11 16:25, Rich Freeman escribió:
 If we
 think that tweaking the changelog policy causes pain, just wait to see
 how the git migration goes.
Just a few words regarding this, in my company we moved to git (from
darcs) recently. I have ended up taking some non working days because
the pressure made by the devs was very high. So Council guys expect the
same from Gentoo devs when you move (and I'm in no way not supporting
the move, in fact I'd like to see it done).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

[Francisco Blas Izquierdo Riera (klondike)]

El 17/06/11 18:46, Mike Frysinger escribió:
 On Friday, June 17, 2011 12:08:43 Francisco Blas Izquierdo Riera wrote:
 El 17/06/11 16:25, Rich Freeman escribió:
 If we
 think that tweaking the changelog policy causes pain, just wait to see
 how the git migration goes.
 Just a few words regarding this, in my company we moved to git (from
 darcs) recently. I have ended up taking some non working days because
 the pressure made by the devs was very high. So Council guys expect the
 same from Gentoo devs when you move (and I'm in no way not supporting
 the move, in fact I'd like to see it done).
 when i made the conversion at my job, i made myself available for 
 random/trivial questions and explaining of concepts.  it seemed to make 
 things 
 much smoother for them.
Neither am I in fact I'm working in this ATM:
http://dev.gentoo.org/~klondike/git.xml Yet when people doesn't want to
change your availability serves little.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: net-wireless/kbluetooth

[Francisco Blas Izquierdo Riera (klondike)]

El 03/06/11 23:48, Andreas K. Huettel escribió:
 # Andreas K. Huettel dilfri...@gentoo.org (3 Jun 2011)
 # Requires KDE 4.4, which is not in the portage tree anymore.
 # Please unmerge before upgrading KDE, and emerge afterwards
 # net-wireless/bluedevil for bluetooth support in KDE 4.6.
 # Masked for removal in 15 days
 net-wireless/kbluetoot
Andreas, maybe increase the removal to 30 days? Desktop users tend to be
less aware of these things and take longer to upgrade.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

[Francisco Blas Izquierdo Riera (klondike)]

I was thinking of writting this in private, but I bet it will do more
good if I do it public.

I'm 22 (most of you could call me a kid) and a reasonably recent new
developer and I'm sad having to ask you, am I the only one seeing
childishness on your actions, and this yours implies at least Samuli,
Mike and Diego and probably many others.

You are discussing and reveling for a stupid file, even worse, its not
even code and solutions to automate the process have been proposed so
you are discussing over nothing.

If you guys want to rebel I can give you many good reasons which are
meaningful that a few lines of something that's not even code:
* Mike your country considers freedom of speech a restrictable right,
maybe you should fight and rebel against that instead of a stupid file.
* Samuli, extremist right wing parties are gaining power in your
country, I think this is a way better reason to rebel than a stupid file.
* Diego, Berlusconi a way better reason to be outraged I think.

I know this will serve for nothing you are going to keep discussing over
pride? 10 minutes of your live? instead of fighting what really should
matter you. It is up to you, meanwhile I'll keep fighting for the camped
people in Spain instead of some random piece of documentation.

Have a nice day.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml

[Francisco Blas Izquierdo Riera (klondike)]

El 10/06/11 17:33, Francisco Blas Izquierdo Riera (klondike) escribió:
 * Diego, Berlusconi a way better reason to be outraged I think.
Small clarification here: I'm not comparing Diego with Berlusconi AFAIK
he isn't a corrupt underage fucking politician, I'm pointing him
Berlusconi ruling Italy is a quite good reason to fight against compared
to adding some lines in a file.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo package statistics -- GSoC 2011

[Francisco Blas Izquierdo Riera (klondike)]

El 08/06/11 20:07, Vikraman escribió:
 On Wed, Jun 08, 2011 at 09:35:26PM +0400, Николай Антонов wrote:
 On 08.06.2011 18:36, Vikraman wrote:
 Hi everyone,

 I'm working on the `Package statistics` project this year. Till now, I
 have managed to write a client and server[0] to collect the following
 information from hosts:

 * Uname, portage profile, timestamp of portage tree
 * ARCH, CHOST, CFLAGS, CXXFLAGS, FFLAGS, LDFLAGS, MAKEOPTS
 * ACCEPT_KEYWORDS, FEATURES, USE, LANG, SYNC, GENTOO_MIRRORS
 * Repository, Keyword, Useflags (plus,minus,unset), Counter, Size,
   and Build time for each installed package

 May be collect hardware info  kernel configs too?
 For example cpuinfo, lspci and lsusb(?).
 That's not part of package statistics. There's the smolt project for
 hardware statistics.
Well there is another reason about why you don't want' to log that:
Hardened users. Not having access to the kernel .config helps in making
the system more resilient to some attacks, as a result many hardened
users are very stubborn in not having the .config files published.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

[Francisco Blas Izquierdo Riera (klondike)]

El 16/05/11 19:54, Kacper Kowalik escribió:
 Neither of those points include sending mail to gentoo-dev, which tend
 to quickly convert into the witch hunt and seldom lead to anything
 conclusive.
To some of us (i.e. me as a staffer and probably any wanna be developer
following the list) it is a good way to learn from others' mistake
before applying for full developership.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] More bugzilla restrictions should be applied to normal users

[Francisco Blas Izquierdo Riera (klondike)]

El 13/05/11 01:57, Jorge Manuel B. S. Vicetto escribió:
 Hi Markos.

 On 12-05-2011 20:19, Markos Chandras wrote:
  Hi,

  Quite a lot of users tend to change bugzilla fields without even
  understand why they are doing it. Would it be possible to restrict users
  from touching the following fields?

  - Importance
  - Severity
Never knew if these fields are really used. Anyway I have seen them been
resetted a few times and users usually don't touch them then.
  - CCing arches on their own (!)
They can still manually add them I think ;)
  - Blocks
I at least use that to let users easily report bugs on Hardened docs,
and maybe others do too
  - Keywords
Yeah this one maybe needs being blocked.
  How do you feel about that? Does bugzilla allow such restrictions?

 I think we should trust our users. Some might feel tempted to test all
 the buttons, but I'm sure the majority will just try to fill a bug
 report the best way they know how.
 This topic has been raised a few times in the past and as far as I can
 recall there never was a consensus about it. In any case, as pointed out
 before, some developers want users to be able to CC them on bugs, at
 least on some bugs, informed users can have a good idea about the
 importance and or severity of a bug and in general being more open can
 provide a more inviting environment for users to look at and or
 contribute to Gentoo.
 Finally, whenever a user abuses bugzilla, you can poke bugzilla admins,
 userrel and a few others to look at and take care of it. Some of us can
 go as far as locking users accounts - feel free to poke me if that need
 ever arises.
I'd just like to add that usually a simple warning when users don't do
things properly suffices, I recall receiving one from Tommy[D] regarding
the use of CCing and after that I didn't do evil deeds with it again.

klondike



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: About the Qt 4.7.3 bump

[Francisco Blas Izquierdo Riera (klondike)]

El 11/05/11 17:43, Duncan escribió:
 Markos Chandras posted on Wed, 11 May 2011 15:27:48 +0100 as excerpted:

 To my perspective, split ebuilds ease the integration of patches. You
 can patch a single ebuild and not have to rebuild everything else. But,
 when it comes to version bumps, I think it is more safe to bump
 everything. Do note that we apply patches more frequently than we do
 version bumps, so it is definitely worth the pain of having split
 ebuilds.
 That was another reason given, and it still makes sense, as does the 
 safety of bumping everything together (no revdep-rebuild issues that way).

 Thanks for the reminder. =:^)
Me be user. Me see that latest version of QT not in portage. Me open bug
to ask for a bump.

Not that all our users are stupid, but most of them don't know wether
things changed or not between versions.



signature.asc
Description: OpenPGP digital signature