All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH 1/2] nss: Move to meta-oe
@ 2020-02-23 19:34 Adrian Bunk
  2020-02-23 19:34 ` [RFC][PATCH 2/2] nspr: " Adrian Bunk
  2020-02-24  0:25 ` [RFC][PATCH 1/2] nss: " Khem Raj
  0 siblings, 2 replies; 27+ messages in thread
From: Adrian Bunk @ 2020-02-23 19:34 UTC (permalink / raw)
  To: openembedded-core

rpm was the last user in OE-core.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
 meta/conf/distro/include/maintainers.inc      |   1 -
 ...figure-option-to-disable-ARM-HW-cryp.patch |  52 ----
 ...0001-nss-fix-support-cross-compiling.patch |  48 ---
 meta/recipes-support/nss/nss/blank-cert9.db   | Bin 28672 -> 0 bytes
 meta/recipes-support/nss/nss/blank-key4.db    | Bin 36864 -> 0 bytes
 .../nss/nss/disable-Wvarargs-with-clang.patch |  33 ---
 .../nss-fix-incorrect-shebang-of-perl.patch   | 110 -------
 .../nss/nss/nss-fix-nsinstall-build.patch     |  36 ---
 .../nss-no-rpath-for-cross-compiling.patch    |  26 --
 meta/recipes-support/nss/nss/nss.pc.in        |  11 -
 .../nss/nss/pqg.c-ULL_addend.patch            |  23 --
 meta/recipes-support/nss/nss/signlibs.sh      |  20 --
 .../recipes-support/nss/nss/system-pkcs11.txt |   5 -
 meta/recipes-support/nss/nss_3.50.bb          | 273 ------------------
 14 files changed, 638 deletions(-)
 delete mode 100644 meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
 delete mode 100644 meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch
 delete mode 100644 meta/recipes-support/nss/nss/blank-cert9.db
 delete mode 100644 meta/recipes-support/nss/nss/blank-key4.db
 delete mode 100644 meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch
 delete mode 100644 meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch
 delete mode 100644 meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch
 delete mode 100644 meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch
 delete mode 100644 meta/recipes-support/nss/nss/nss.pc.in
 delete mode 100644 meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch
 delete mode 100644 meta/recipes-support/nss/nss/signlibs.sh
 delete mode 100644 meta/recipes-support/nss/nss/system-pkcs11.txt
 delete mode 100644 meta/recipes-support/nss/nss_3.50.bb

diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
index 8f612ace39..e4b710d640 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -526,7 +526,6 @@ RECIPE_MAINTAINER_pn-nfs-utils = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-ninja = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-npth = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-nspr = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-nss = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-nss-myhostname = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-ofono = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-opensbi = "Alistair Francis <alistair.francis@wdc.com>"
diff --git a/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch b/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
deleted file mode 100644
index c380c14491..0000000000
--- a/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
+++ /dev/null
@@ -1,52 +0,0 @@
-From 5595e9651aca39af945931c73eb524a0f8bd130d Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin <alex.kanavin@gmail.com>
-Date: Wed, 18 Dec 2019 12:29:50 +0100
-Subject: [PATCH] freebl: add a configure option to disable ARM HW crypto
-
-Not all current hardware supports it, particularly anything
-prior to armv8 does not.
-
-Upstream-Status: Pending
-Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
----
- nss/lib/freebl/Makefile | 3 +++
- 1 file changed, 3 insertions(+)
-
---- a/nss/lib/freebl/Makefile
-+++ b/nss/lib/freebl/Makefile
-@@ -125,6 +125,9 @@ else
-         DEFINES += -DNSS_X86
- endif
- endif
-+
-+ifdef NSS_USE_ARM_HW_CRYPTO
-+    DEFINES += -DNSS_USE_ARM_HW_CRYPTO
- ifeq ($(CPU_ARCH),aarch64)
-     DEFINES += -DUSE_HW_AES
-     EXTRA_SRCS += aes-armv8.c gcm-aarch64.c
-@@ -146,6 +149,7 @@ ifeq ($(CPU_ARCH),arm)
-         endif
-     endif
- endif
-+endif
- 
- ifeq ($(OS_TARGET),OSF1)
-     DEFINES += -DMP_ASSEMBLY_MULTIPLY -DMP_NO_MP_WORD
---- a/nss/lib/freebl/gcm.c
-+++ b/nss/lib/freebl/gcm.c
-@@ -17,6 +17,7 @@
- 
- #include <limits.h>
- 
-+#ifdef NSS_USE_ARM_HW_CRYPTO
- /* old gcc doesn't support some poly64x2_t intrinsic */
- #if defined(__aarch64__) && defined(IS_LITTLE_ENDIAN) && \
-     (defined(__clang__) || defined(__GNUC__) && __GNUC__ > 6)
-@@ -25,6 +26,7 @@
- /* We don't test on big endian platform, so disable this on big endian. */
- #define USE_ARM_GCM
- #endif
-+#endif
- 
- /* Forward declarations */
- SECStatus gcm_HashInit_hw(gcmHashContext *ghash);
diff --git a/meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch b/meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch
deleted file mode 100644
index d5403397e7..0000000000
--- a/meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-From 0cf47ee432cc26a706864fcc09b2c3adc342a679 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin <alex.kanavin@gmail.com>
-Date: Wed, 22 Feb 2017 11:36:11 +0200
-Subject: [PATCH] nss: fix support cross compiling
-
-Let some make variables be assigned from outside makefile.
-
-Upstream-Status: Inappropriate [configuration]
-Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
-Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
----
- nss/coreconf/arch.mk    | 2 +-
- nss/lib/freebl/Makefile | 6 ++++++
- 2 files changed, 7 insertions(+), 1 deletion(-)
-
-diff --git a/nss/coreconf/arch.mk b/nss/coreconf/arch.mk
-index 06c276f..9c1eb51 100644
---- a/nss/coreconf/arch.mk
-+++ b/nss/coreconf/arch.mk
-@@ -30,7 +30,7 @@ OS_TEST := $(shell uname -m)
- ifeq ($(OS_TEST),i86pc)
-     OS_RELEASE := $(shell uname -r)_$(OS_TEST)
- else
--    OS_RELEASE := $(shell uname -r)
-+    OS_RELEASE ?= $(shell uname -r)
- endif
- 
- #
-diff --git a/nss/lib/freebl/Makefile b/nss/lib/freebl/Makefile
-index 0ce1425..ebeb411 100644
---- a/nss/lib/freebl/Makefile
-+++ b/nss/lib/freebl/Makefile
-@@ -36,6 +36,12 @@ ifdef USE_64
- 	DEFINES += -DNSS_USE_64
- endif
- 
-+ifeq ($(OS_TEST),mips)
-+ifndef USE_64
-+       DEFINES += -DNS_PTR_LE_32
-+endif
-+endif
-+
- ifdef USE_ABI32_FPU
- 	DEFINES += -DNSS_USE_ABI32_FPU
- endif
--- 
-2.11.0
-
diff --git a/meta/recipes-support/nss/nss/blank-cert9.db b/meta/recipes-support/nss/nss/blank-cert9.db
deleted file mode 100644
index 7d4bcf2582d510f7b51d4306706746178c41fbbc..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 28672
zcmeH~OK;Oa6ou_RTxhB2E<!9aOCljO58HJ%sA+4Yh?2G;mFNOhcH&Bb(26FJSh8cs
zo*x9ii4|h*_1I~<VaFmmmVA3=?%XpopQn-L?dj2YR*1{%n@`zH7;ne(eQ!?)&+~ly
zZrHba)~#5p8ul;c|MmFZ3-M$7@oz8K{Np`(`1t46udT0Jd$xfG1V8`;KmY_l00ck)
z1pYgLy&z~bn*RCtYE*m~e$2+BtLgM)o=?WZje~yL8Kk1yJ51jR&WYomsPp1krlfAY
zTxW+fc9>*&F{wuccN{o(-@&vF*Mi2=rvIMnr}O+nF`U&7>vtSn_P&Rbs?}Ky8c(Wy
zjHlCiaZ{VD-7zVX_dOET`quV08qKEvy)(=5Nl};AV#WCkI{QcIZ4Tp+IO%uabo%Gw
zb$Tw&dfn5rlx8?M?!7wd9t=ch|F}PRE;4CfWnXPyLz+9NM^RTo&4ii>H)%)`Qiv$T
z6m}^j6xtLr3b_q!wvuIJM@b$^mh+H{l4PSK`6x+7N|KY3WThl|DM@BZ4k^0jmFr_?
zU21mL?5x>Yv$JMr&CZ&g4ObbiGF)Z2%5YW8*_g92XJgLBWtKf-_T1%>%ttXG%{$eS
zYBldv^J+tBAFZg{N%A#3+VE(@qivFhlmlr@$fQC^bB9bSWKto|8uF|mf0u}BBX*0}
zE#lf?5t-0LWa%XNI!POIl4fv{w&*17(@6s8BvC9SLveCZ#&}%sqAae;;>B{Ttd?VC
zwHzy}<ycwyT3Ic}%F5TuTfTH=Xkyz-2ggY|Jx<aQa&okg#X?@zk`F>THeW0!r{#>I
zOpbCUp3t|IjGe}YCgyXi+by*cG}5N;l|Le%C-z2vk<Dk<+`g#)gD+GqSM5*j1Nyn$
zrm#Z+4+ww&2!H?xfB*=900@8p2!H?xfWWd6*rbi&{=clB7yAMM5C8!X009sH0T2KI
z5C8!X00Aa|`#%l>2!H?xfB*=900@8p2!H?xfB*<AKLOnTm;W1Mhadm~AOHd&00JNY
z0w4eaAOHd&fcrnr00@8p2!H?xfB*=900@8p2!H?xEI$F<|Cj$8V}~FB0w4eaAOHd&
O00JNY0w4eaAn+IM<WtiC

diff --git a/meta/recipes-support/nss/nss/blank-key4.db b/meta/recipes-support/nss/nss/blank-key4.db
deleted file mode 100644
index d47f08d04fe82197bc6a39ef9bf216b61c3dc77a..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 36864
zcmeI)Pj3@P7zXfN$JsbGQBr~AB4lZNXcZIG&g?%N!~w@RZQ3*mZcvLjSnGHJQ-_q;
zfnEyAB}g2&RFzt!s;9Q+svn?82vt4w)Lub+1tcV(r_THCZkH&E#0_CRt9bl+XXe@2
z-!3E@BtAW}*d2u8!p7!$Fc6M0WtgUMN(jR+GWs>HU&&_aBAa~B@8(POer3jZPkcWy
z`P|6mo5q3c<o&|$h3f?`|0Lhc-`j5z_Co*y5P$##AOHafyh#GRv9V&QWNyz4f_5)l
z4+p{NU=Sqlxq7ovTWyHd+T3D8Bzwhlw<A`X3!l`Q=fua2bK>mM!kM!TvAiVe%S-c%
z3-wjeY^*HS>WyPU|Gc`cqBpzpe$Fb^OQzAi(h0xnU+wA6R<JeL;Loijzon9De9p3p
z#j<&x2dsS&bURo2{gut`wO|mA#fw{5I^FnOa3?Jx9U!IyCGE<oQO@{`GkQTg?4?7j
zT^ZcDC&Q`CXRYFqve}B3z16-Pt_{+R(Ont+sC!R}lB!Z4v5JS2v+4HxTj6FJlid{)
z_3lZjs>-dC=2)>@Ht*E=lBEG@m5HOG%a-ncl?zv!TW+o%6M@t(ecb|EzZ|N02klX`
zt4bfM^s&kxX-L(j#-qlk<~TJ~YG$bksA=nFmZN0Ua-yURC8Og|ijowgB;_bcK}u4R
zk`$#RWhqHvO0H2GFE3gjC)-iY$u=k3oNRNl&B-<=+nnt1EQe<~Jj>x(4$tzr*XLfJ
zdwuTpqh8MRIrBJ=WFN&qHlL|2X|By@YV&GcsW)5E?zp5}heta++Tqc<lZQkDX^hKK
zuB2nTEakG4%SUzjs4ia@kLP-v=5d<GbJs%8aUG8$<C1dYl1?lx=?HO2rx=%Xo^eTl
zaY>3%$tZD|PGg>UZ#vCSrupe|beSwim&tN;nJh<_Nv<xF<>)fW)#XdMbkER%^<KJh
z;*##3xTISsE<0%%rsakIOTH1JvF&s@ZCXyp3uLFw;#In~lG$mj>-c=%+OriWV--Ir
z@Ap?=`e(JJ(t1RHN6FE5l?iI5sKEvS2tWV=5P$##AOHafKmY;|fWWW{<mtrl{6DOh
z7v}{52tWV=5P$##AOHafKmY;|U;#Y;<3@l01Rwwb2tWV=5P$##AOHaf48H)L|A+q?
z;|w7H0SG_<0uX=z1Rwwb2tWV=c>c#d009U<00Izz00bZa0SG_<0uUH}0X+W?|24)L
zLI45~fB*y_009U<00Izz00ij&|2HRpH1roX2tWV=5P$##AOHafKmY;|fB*zuk3h>D
zExFsdFN1#n`o?DG@A=!mz4-R0mFHhS{`aGMCw_gf{mystq@1=2M|VElc{X7l7&S-a
z;q0N#(b>ECcfWb-&&$6&y8G8Z_h0;R>*tJVW~XMJ>|DC|(5t=u;D?(BCuVNYzyF()
mPYwNr4FV8=00bZa0SG_<0uX=z1Rwx`ArdHzl*W_aDEtSkqPYeD

diff --git a/meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch b/meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch
deleted file mode 100644
index de812d27ba..0000000000
--- a/meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-clang 3.9 add this warning to rightly flag undefined
-behavior, we relegate this to be just a warning instead
-of error and keep the behavior as it was. Right fix would
-be to not pass enum to the function with variadic arguments
-as last named argument
-
-Fixes errors like
-ocsp.c:2220:22: error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Werror,-Wvarargs]
-        va_start(ap, responseType0);
-                     ^
-ocsp.c:2200:43: note: parameter of type 'SECOidTag' is declared here
-                                SECOidTag responseType0, ...)
-
-see
-https://www.securecoding.cert.org/confluence/display/cplusplus/EXP58-CPP.+Pass+an+object+of+the+correct+type+to+va_start
-for more details
-
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-Upstream-Status: Pending
-
-Index: nss-3.37.1/nss/coreconf/Werror.mk
-===================================================================
---- nss-3.37.1.orig/nss/coreconf/Werror.mk
-+++ nss-3.37.1/nss/coreconf/Werror.mk
-@@ -56,7 +56,7 @@ ifndef WARNING_CFLAGS
-     ifdef CC_IS_CLANG
-       # -Qunused-arguments : clang objects to arguments that it doesn't understand
-       #    and fixing this would require rearchitecture
--      WARNING_CFLAGS += -Qunused-arguments
-+      WARNING_CFLAGS += -Qunused-arguments -Wno-error=varargs
-       # -Wno-parentheses-equality : because clang warns about macro expansions
-       WARNING_CFLAGS += $(call disable_warning,parentheses-equality)
-       ifdef BUILD_OPT
diff --git a/meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch b/meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch
deleted file mode 100644
index 547594d5b6..0000000000
--- a/meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch
+++ /dev/null
@@ -1,110 +0,0 @@
-nss: fix incorrect shebang of perl
-
-Replace incorrect shebang of perl with `#!/usr/bin/env perl'.
-
-Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
-Upstream-Status: Pending
----
- nss/cmd/smimetools/smime  | 2 +-
- nss/coreconf/cpdist.pl    | 2 +-
- nss/coreconf/import.pl    | 2 +-
- nss/coreconf/jniregen.pl  | 2 +-
- nss/coreconf/outofdate.pl | 2 +-
- nss/coreconf/release.pl   | 2 +-
- nss/coreconf/version.pl   | 2 +-
- nss/tests/clean_tbx       | 2 +-
- nss/tests/path_uniq       | 2 +-
- 9 files changed, 9 insertions(+), 9 deletions(-)
-
-diff --git a/nss/cmd/smimetools/smime b/nss/cmd/smimetools/smime
---- a/nss/cmd/smimetools/smime
-+++ b/nss/cmd/smimetools/smime
-@@ -1,4 +1,4 @@
--#!/usr/local/bin/perl
-+#!/usr/bin/env perl
- 
- # This Source Code Form is subject to the terms of the Mozilla Public
- # License, v. 2.0. If a copy of the MPL was not distributed with this
-diff --git a/nss/coreconf/cpdist.pl b/nss/coreconf/cpdist.pl
-index 800edfb..652187f 100755
---- a/nss/coreconf/cpdist.pl
-+++ b/nss/coreconf/cpdist.pl
-@@ -1,4 +1,4 @@
--#! /usr/local/bin/perl
-+#!/usr/bin/env perl
- #
- # This Source Code Form is subject to the terms of the Mozilla Public
- # License, v. 2.0. If a copy of the MPL was not distributed with this
-diff --git a/nss/coreconf/import.pl b/nss/coreconf/import.pl
-index dd2d177..428eaa5 100755
---- a/nss/coreconf/import.pl
-+++ b/nss/coreconf/import.pl
-@@ -1,4 +1,4 @@
--#! /usr/local/bin/perl
-+#!/usr/bin/env perl
- #
- # This Source Code Form is subject to the terms of the Mozilla Public
- # License, v. 2.0. If a copy of the MPL was not distributed with this
-diff --git a/nss/coreconf/jniregen.pl b/nss/coreconf/jniregen.pl
-index 2039180..5f4f69c 100755
---- a/nss/coreconf/jniregen.pl
-+++ b/nss/coreconf/jniregen.pl
-@@ -1,4 +1,4 @@
--#!/usr/local/bin/perl
-+#!/usr/bin/env perl
- #
- # This Source Code Form is subject to the terms of the Mozilla Public
- # License, v. 2.0. If a copy of the MPL was not distributed with this
-diff --git a/nss/coreconf/outofdate.pl b/nss/coreconf/outofdate.pl
-index 33d80bb..01fc097 100755
---- a/nss/coreconf/outofdate.pl
-+++ b/nss/coreconf/outofdate.pl
-@@ -1,4 +1,4 @@
--#!/usr/local/bin/perl
-+#!/usr/bin/env perl
- #
- # This Source Code Form is subject to the terms of the Mozilla Public
- # License, v. 2.0. If a copy of the MPL was not distributed with this
-diff --git a/nss/coreconf/release.pl b/nss/coreconf/release.pl
-index 7cde19d..b5df2f6 100755
---- a/nss/coreconf/release.pl
-+++ b/nss/coreconf/release.pl
-@@ -1,4 +1,4 @@
--#! /usr/local/bin/perl
-+#!/usr/bin/env perl
- #
- # This Source Code Form is subject to the terms of the Mozilla Public
- # License, v. 2.0. If a copy of the MPL was not distributed with this
-diff --git a/nss/coreconf/version.pl b/nss/coreconf/version.pl
-index d2a4942..79359fe 100644
---- a/nss/coreconf/version.pl
-+++ b/nss/coreconf/version.pl
-@@ -1,4 +1,4 @@
--#!/usr/sbin/perl
-+#!/usr/bin/env perl
- #
- # This Source Code Form is subject to the terms of the Mozilla Public
- # License, v. 2.0. If a copy of the MPL was not distributed with this
-diff --git a/nss/tests/clean_tbx b/nss/tests/clean_tbx
-index 4de9555..a7def9f 100755
---- a/nss/tests/clean_tbx
-+++ b/nss/tests/clean_tbx
-@@ -1,4 +1,4 @@
--#! /bin/perl
-+#!/usr/bin/env perl
- 
- #######################################################################
- #
-diff --git a/nss/tests/path_uniq b/nss/tests/path_uniq
-index f29f60a..08fbffa 100755
---- a/nss/tests/path_uniq
-+++ b/nss/tests/path_uniq
-@@ -1,4 +1,4 @@
--#! /bin/perl
-+#!/usr/bin/env perl
- 
- ########################################################################
- #
--- 
-1.8.1.2
-
diff --git a/meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch b/meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch
deleted file mode 100644
index 43c09d13ea..0000000000
--- a/meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-Fix nss multilib build on openSUSE 11.x 32bit
-
-While building lib64-nss on openSUSE 11.x 32bit, the nsinstall will
-fail with error:
-
-* nsinstall.c:1:0: sorry, unimplemented: 64-bit mode not compiled
-
-It caused by the '-m64' option which passed to host gcc.
-
-The nsinstall was built first while nss starting to build, it only runs
-on host to install built files, it doesn't need any cross-compling or
-multilib build options. Just clean the ARCHFLAG and LDFLAGS to fix this
-error.
-
-Upstream-Status: Pending
-
-Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
-===================================================
-Index: nss-3.24/nss/coreconf/nsinstall/Makefile
-===================================================================
---- nss-3.24.orig/nss/coreconf/nsinstall/Makefile
-+++ nss-3.24/nss/coreconf/nsinstall/Makefile
-@@ -18,6 +18,13 @@ INTERNAL_TOOLS  = 1
- 
- include $(DEPTH)/coreconf/config.mk
- 
-+# nsinstall is unfit for cross-compiling/multilib-build since it was
-+# always run on local host to install built files. This change intends
-+# to clean the '-m64' from ARCHFLAG and LDFLAGS.
-+ARCHFLAG =
-+LDFLAGS =
-+# CFLAGS =
-+
- ifeq (,$(filter-out OS2 WIN%,$(OS_TARGET)))
- PROGRAM		=
- else
diff --git a/meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch b/meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch
deleted file mode 100644
index 7661dc93a0..0000000000
--- a/meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-nss:no rpath for cross compiling
-
-Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
-Upstream-Status: Inappropriate [configuration]
----
- nss/cmd/platlibs.mk | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/nss/cmd/platlibs.mk b/nss/cmd/platlibs.mk
---- a/nss/cmd/platlibs.mk
-+++ b/nss/cmd/platlibs.mk
-@@ -18,9 +18,9 @@ endif
- 
- ifeq ($(OS_ARCH), Linux)
- ifeq ($(USE_64), 1)
--EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib64:/opt/sun/private/lib64:$$ORIGIN/../lib'
-+#EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib64:/opt/sun/private/lib64:$$ORIGIN/../lib'
- else
--EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib:/opt/sun/private/lib'
-+#EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib:/opt/sun/private/lib'
- endif
- endif
- 
--- 
-1.8.1.2
-
diff --git a/meta/recipes-support/nss/nss/nss.pc.in b/meta/recipes-support/nss/nss/nss.pc.in
deleted file mode 100644
index 402b4ecb33..0000000000
--- a/meta/recipes-support/nss/nss/nss.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-prefix=OEPREFIX
-exec_prefix=OEEXECPREFIX
-libdir=OELIBDIR
-includedir=OEINCDIR
-
-Name: NSS
-Description: Network Security Services
-Version: %NSS_VERSION%
-Requires: nspr >= %NSPR_VERSION%
-Libs: -L${libdir} -lssl3 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3
-Cflags: -IOEINCDIR
diff --git a/meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch b/meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch
deleted file mode 100644
index 3a817faaa6..0000000000
--- a/meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-nss does not build on mips with clang because wrong types are used?
-
-pqg.c:339:16: error: comparison of constant 18446744073709551615 with expression of type 'unsigned long' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
-     if (addend < MP_DIGIT_MAX) {
-       ~~~~~~ ^ ~~~~~~~~~~~~
-
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-Upstream-Status: Pending
-Index: nss-3.37.1/nss/lib/freebl/pqg.c
-===================================================================
---- nss-3.37.1.orig/nss/lib/freebl/pqg.c
-+++ nss-3.37.1/nss/lib/freebl/pqg.c
-@@ -326,8 +326,8 @@ generate_h_candidate(SECItem *hit, mp_in
- 
- static SECStatus
- addToSeed(const SECItem *seed,
--          unsigned long addend,
--          int seedlen, /* g in 186-1 */
-+          unsigned long long  addend,
-+          int                 seedlen, /* g in 186-1 */
-           SECItem *seedout)
- {
-     mp_int s, sum, modulus, tmp;
diff --git a/meta/recipes-support/nss/nss/signlibs.sh b/meta/recipes-support/nss/nss/signlibs.sh
deleted file mode 100644
index a74e499f8c..0000000000
--- a/meta/recipes-support/nss/nss/signlibs.sh
+++ /dev/null
@@ -1,20 +0,0 @@
-#!/bin/sh
-
-# signlibs.sh
-#
-# (c)2010 Wind River Systems, Inc.
-#
-# regenerates the .chk files for the NSS libraries that require it
-# since the ones that are built have incorrect checksums that were
-# calculated on the host where they really need to be done on the
-# target
-
-CHK_FILES=`ls /lib*/*.chk /usr/lib*/*.chk 2>/dev/null`
-SIGN_BINARY=`which shlibsign`
-for I in $CHK_FILES
-do
-       DN=`dirname $I`
-       BN=`basename $I .chk`
-       FN=$DN/$BN.so
-       $SIGN_BINARY -i $FN
-done
diff --git a/meta/recipes-support/nss/nss/system-pkcs11.txt b/meta/recipes-support/nss/nss/system-pkcs11.txt
deleted file mode 100644
index 1a264e9cc4..0000000000
--- a/meta/recipes-support/nss/nss/system-pkcs11.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-library=
-name=NSS Internal PKCS #11 Module
-parameters=configdir='sql:/etc/pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags= updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription='' 
-NSS=Flags=internal,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[ECC,RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512] askpw=any timeout=30})
-
diff --git a/meta/recipes-support/nss/nss_3.50.bb b/meta/recipes-support/nss/nss_3.50.bb
deleted file mode 100644
index e9855d7a7e..0000000000
--- a/meta/recipes-support/nss/nss_3.50.bb
+++ /dev/null
@@ -1,273 +0,0 @@
-SUMMARY = "Mozilla's SSL and TLS implementation"
-DESCRIPTION = "Network Security Services (NSS) is a set of libraries \
-designed to support cross-platform development of \
-security-enabled client and server applications. \
-Applications built with NSS can support SSL v2 and v3, \
-TLS, PKCS 5, PKCS 7, PKCS 11, PKCS 12, S/MIME, X.509 \
-v3 certificates, and other security standards."
-HOMEPAGE = "http://www.mozilla.org/projects/security/pki/nss/"
-SECTION = "libs"
-
-DEPENDS = "sqlite3 nspr zlib nss-native"
-DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
-
-LICENSE = "MPL-2.0 | (MPL-2.0 & GPL-2.0+) | (MPL-2.0 & LGPL-2.1+)"
-
-LIC_FILES_CHKSUM = "file://nss/COPYING;md5=3b1e88e1b9c0b5a4b2881d46cce06a18 \
-                    file://nss/lib/freebl/mpi/doc/LICENSE;md5=491f158d09d948466afce85d6f1fe18f \
-                    file://nss/lib/freebl/mpi/doc/LICENSE-MPL;md5=5d425c8f3157dbf212db2ec53d9e5132"
-
-VERSION_DIR = "${@d.getVar('BP').upper().replace('-', '_').replace('.', '_') + '_RTM'}"
-
-SRC_URI = "http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/${VERSION_DIR}/src/${BP}.tar.gz \
-           file://nss.pc.in \
-           file://signlibs.sh \
-           file://0001-nss-fix-support-cross-compiling.patch \
-           file://nss-no-rpath-for-cross-compiling.patch \
-           file://nss-fix-incorrect-shebang-of-perl.patch \
-           file://disable-Wvarargs-with-clang.patch \
-           file://pqg.c-ULL_addend.patch \
-           file://blank-cert9.db \
-           file://blank-key4.db \
-           file://system-pkcs11.txt \
-           file://nss-fix-nsinstall-build.patch \
-           file://0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch \
-           "
-
-SRC_URI[md5sum] = "e0366615e12b147cebc136c915baea37"
-SRC_URI[sha256sum] = "185df319775243f5f5daa9d49b7f9cc5f2b389435be3247c3376579bee063ba7"
-
-UPSTREAM_CHECK_URI = "https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases"
-UPSTREAM_CHECK_REGEX = "NSS_(?P<pver>.+)_release_notes"
-
-inherit siteinfo
-
-TD = "${S}/tentative-dist"
-TDS = "${S}/tentative-dist-staging"
-
-TARGET_CC_ARCH += "${LDFLAGS}"
-
-do_configure_prepend_libc-musl () {
-    sed -i -e '/-DHAVE_SYS_CDEFS_H/d' ${S}/nss/lib/dbm/config/config.mk
-}
-
-do_compile_prepend_class-native() {
-    export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}/nspr
-    export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
-    export NSS_ENABLE_WERROR=0
-}
-
-do_compile_prepend_class-nativesdk() {
-    export LDFLAGS=""
-}
-
-do_compile_prepend_class-native() {
-    # Need to set RPATH so that chrpath will do its job correctly
-    RPATH="-Wl,-rpath-link,${STAGING_LIBDIR_NATIVE} -Wl,-rpath-link,${STAGING_BASE_LIBDIR_NATIVE} -Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}"
-}
-
-do_compile() {
-    export NSPR_INCLUDE_DIR=${STAGING_INCDIR}/nspr
-
-    export CROSS_COMPILE=1
-    export NATIVE_CC="${BUILD_CC}"
-    # Additional defines needed on Centos 7
-    export NATIVE_FLAGS="${BUILD_CFLAGS} -DLINUX -Dlinux"
-    export BUILD_OPT=1
-
-    export FREEBL_NO_DEPEND=1
-    export FREEBL_LOWHASH=1
-
-    export LIBDIR=${libdir}
-    export MOZILLA_CLIENT=1
-    export NS_USE_GCC=1
-    export NSS_USE_SYSTEM_SQLITE=1
-    export NSS_ENABLE_ECC=1
-
-    ${@bb.utils.contains("TUNE_FEATURES", "crypto", "export NSS_USE_ARM_HW_CRYPTO=1", "", d)}
-
-    export OS_RELEASE=3.4
-    export OS_TARGET=Linux
-    export OS_ARCH=Linux
-
-    if [ "${TARGET_ARCH}" = "powerpc" ]; then
-        OS_TEST=ppc
-    elif [ "${TARGET_ARCH}" = "powerpc64" ]; then
-        OS_TEST=ppc64
-    elif [ "${TARGET_ARCH}" = "mips" -o "${TARGET_ARCH}" = "mipsel" -o "${TARGET_ARCH}" = "mips64" -o "${TARGET_ARCH}" = "mips64el" ]; then
-        OS_TEST=mips
-    elif [ "${TARGET_ARCH}" = "aarch64_be" ]; then
-        OS_TEST="aarch64"
-    else
-        OS_TEST="${TARGET_ARCH}"
-    fi
-
-    if [ "${SITEINFO_BITS}" = "64" ]; then
-        export USE_64=1
-    elif [ "${TARGET_ARCH}" = "x86_64" -a "${SITEINFO_BITS}" = "32" ]; then
-        export USE_X32=1
-    fi
-
-    export NSS_DISABLE_GTESTS=1
-
-    # We can modify CC in the environment, but if we set it via an
-    # argument to make, nsinstall, a host program, will also build with it!
-    #
-    # nss pretty much does its own thing with CFLAGS, so we put them into CC.
-    # Optimization will get clobbered, but most of the stuff will survive.
-    # The motivation for this is to point to the correct place for debug
-    # source files and CFLAGS does that.  Nothing uses CCC.
-    #
-    export CC="${CC} ${CFLAGS}"
-    make -C ./nss CCC="${CXX} -g" \
-        OS_TEST=${OS_TEST} \
-        RPATH="${RPATH}"
-}
-
-do_compile[vardepsexclude] += "SITEINFO_BITS"
-
-do_install_prepend_class-nativesdk() {
-    export LDFLAGS=""
-}
-
-do_install() {
-    export CROSS_COMPILE=1
-    export NATIVE_CC="${BUILD_CC}"
-    export BUILD_OPT=1
-
-    export FREEBL_NO_DEPEND=1
-
-    export LIBDIR=${libdir}
-    export MOZILLA_CLIENT=1
-    export NS_USE_GCC=1
-    export NSS_USE_SYSTEM_SQLITE=1
-    export NSS_ENABLE_ECC=1
-
-    export OS_RELEASE=3.4
-    export OS_TARGET=Linux
-    export OS_ARCH=Linux
-
-    if [ "${TARGET_ARCH}" = "powerpc" ]; then
-        OS_TEST=ppc
-    elif [ "${TARGET_ARCH}" = "powerpc64" ]; then
-        OS_TEST=ppc64
-    elif [ "${TARGET_ARCH}" = "mips" -o "${TARGET_ARCH}" = "mipsel" -o "${TARGET_ARCH}" = "mips64" -o "${TARGET_ARCH}" = "mips64el" ]; then
-        OS_TEST=mips
-    elif [ "${TARGET_ARCH}" = "aarch64_be" ]; then
-        CPU_ARCH=aarch64
-        OS_TEST="aarch64"
-    else
-        OS_TEST="${TARGET_ARCH}"
-    fi
-    if [ "${SITEINFO_BITS}" = "64" ]; then
-        export USE_64=1
-    elif [ "${TARGET_ARCH}" = "x86_64" -a "${SITEINFO_BITS}" = "32" ]; then
-        export USE_X32=1
-    fi
-
-    export NSS_DISABLE_GTESTS=1
-
-    make -C ./nss \
-        CCC="${CXX}" \
-        OS_TEST=${OS_TEST} \
-        SOURCE_LIB_DIR="${TD}/${libdir}" \
-        SOURCE_BIN_DIR="${TD}/${bindir}" \
-        install
-
-    install -d ${D}/${libdir}/
-    for file in ${S}/dist/*.OBJ/lib/*.so; do
-        echo "Installing `basename $file`..."
-        cp $file  ${D}/${libdir}/
-    done
-
-    for shared_lib in ${TD}/${libdir}/*.so.*; do
-        if [ -f $shared_lib ]; then
-            cp $shared_lib ${D}/${libdir}
-            ln -sf $(basename $shared_lib) ${D}/${libdir}/$(basename $shared_lib .1oe)
-        fi
-    done
-    for shared_lib in ${TD}/${libdir}/*.so; do
-        if [ -f $shared_lib -a ! -e ${D}/${libdir}/$shared_lib ]; then
-            cp $shared_lib ${D}/${libdir}
-        fi
-    done
-
-    install -d ${D}/${includedir}/nss3
-    install -m 644 -t ${D}/${includedir}/nss3 dist/public/nss/*
-
-    install -d ${D}/${bindir}
-    for binary in ${TD}/${bindir}/*; do
-        install -m 755 -t ${D}/${bindir} $binary
-    done
-}
-
-do_install[vardepsexclude] += "SITEINFO_BITS"
-
-do_install_append() {
-    # Create empty .chk files for the NSS libraries at build time. They could
-    # be regenerated at target's boot time.
-    for file in libsoftokn3.chk libfreebl3.chk libnssdbm3.chk; do
-        touch ${D}/${libdir}/$file
-        chmod 755 ${D}/${libdir}/$file
-    done
-    install -D -m 755 ${WORKDIR}/signlibs.sh ${D}/${bindir}/signlibs.sh
-
-    install -d ${D}${libdir}/pkgconfig/
-    sed 's/%NSS_VERSION%/${PV}/' ${WORKDIR}/nss.pc.in | sed 's/%NSPR_VERSION%/4.9.2/' > ${D}${libdir}/pkgconfig/nss.pc
-    sed -i s:OEPREFIX:${prefix}:g ${D}${libdir}/pkgconfig/nss.pc
-    sed -i s:OEEXECPREFIX:${exec_prefix}:g ${D}${libdir}/pkgconfig/nss.pc
-    sed -i s:OELIBDIR:${libdir}:g ${D}${libdir}/pkgconfig/nss.pc
-    sed -i s:OEINCDIR:${includedir}/nss3:g ${D}${libdir}/pkgconfig/nss.pc
-}
-
-do_install_append_class-target() {
-    # It used to call certutil to create a blank certificate with empty password at
-    # build time, but the checksum of key4.db changes every time when certutil is called.
-    # It causes non-determinism issue, so provide databases with a blank certificate
-    # which are originally from output of nss in qemux86-64 build. You can get these
-    # databases by:
-    # certutil -N -d sql:/database/path/ --empty-password
-    install -d ${D}${sysconfdir}/pki/nssdb/
-    install -m 0644 ${WORKDIR}/blank-cert9.db ${D}${sysconfdir}/pki/nssdb/cert9.db
-    install -m 0644 ${WORKDIR}/blank-key4.db ${D}${sysconfdir}/pki/nssdb/key4.db
-    install -m 0644 ${WORKDIR}/system-pkcs11.txt ${D}${sysconfdir}/pki/nssdb/pkcs11.txt
-}
-
-PACKAGE_WRITE_DEPS += "nss-native"
-pkg_postinst_${PN} () {
-    if [ -n "$D" ]; then
-        for I in $D${libdir}/lib*.chk; do
-            DN=`dirname $I`
-            BN=`basename $I .chk`
-            FN=$DN/$BN.so
-            shlibsign -i $FN
-            if [ $? -ne 0 ]; then
-                exit 1
-            fi
-        done
-    else
-        signlibs.sh
-    fi
-}
-
-PACKAGES =+ "${PN}-smime"
-FILES_${PN}-smime = "\
-    ${bindir}/smime \
-"
-
-FILES_${PN} = "\
-    ${sysconfdir} \
-    ${bindir} \
-    ${libdir}/lib*.chk \
-    ${libdir}/lib*.so \
-    "
-
-FILES_${PN}-dev = "\
-    ${libdir}/nss \
-    ${libdir}/pkgconfig/* \
-    ${includedir}/* \
-    "
-
-RDEPENDS_${PN}-smime = "perl"
-
-BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1



^ permalink raw reply related	[flat|nested] 27+ messages in thread

* [RFC][PATCH 2/2] nspr: Move to meta-oe
  2020-02-23 19:34 [RFC][PATCH 1/2] nss: Move to meta-oe Adrian Bunk
@ 2020-02-23 19:34 ` Adrian Bunk
  2020-02-24  0:25 ` [RFC][PATCH 1/2] nss: " Khem Raj
  1 sibling, 0 replies; 27+ messages in thread
From: Adrian Bunk @ 2020-02-23 19:34 UTC (permalink / raw)
  To: openembedded-core

It was used only by nss.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
 meta/conf/distro/include/maintainers.inc      |   1 -
 .../nspr/0001-md-Fix-build-with-musl.patch    |  31 ---
 .../nspr/nspr/0002-Add-nios2-support.patch    | 102 ---------
 ...remove-_BUILD_STRING-and-_BUILD_TIME.patch | 103 ---------
 .../nspr/nspr/fix-build-on-x86_64.patch       |  52 -----
 meta/recipes-support/nspr/nspr/nspr.pc.in     |  11 -
 .../nspr/nspr/remove-rpath-from-tests.patch   |  26 ---
 .../remove-srcdir-from-configure-in.patch     |  19 --
 meta/recipes-support/nspr/nspr_4.25.bb        | 197 ------------------
 9 files changed, 542 deletions(-)
 delete mode 100644 meta/recipes-support/nspr/nspr/0001-md-Fix-build-with-musl.patch
 delete mode 100644 meta/recipes-support/nspr/nspr/0002-Add-nios2-support.patch
 delete mode 100644 meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch
 delete mode 100644 meta/recipes-support/nspr/nspr/fix-build-on-x86_64.patch
 delete mode 100644 meta/recipes-support/nspr/nspr/nspr.pc.in
 delete mode 100644 meta/recipes-support/nspr/nspr/remove-rpath-from-tests.patch
 delete mode 100644 meta/recipes-support/nspr/nspr/remove-srcdir-from-configure-in.patch
 delete mode 100644 meta/recipes-support/nspr/nspr_4.25.bb

diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
index e4b710d640..874c595f0d 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -525,7 +525,6 @@ RECIPE_MAINTAINER_pn-nfs-export-root = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-nfs-utils = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-ninja = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-npth = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-nspr = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-nss-myhostname = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-ofono = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-opensbi = "Alistair Francis <alistair.francis@wdc.com>"
diff --git a/meta/recipes-support/nspr/nspr/0001-md-Fix-build-with-musl.patch b/meta/recipes-support/nspr/nspr/0001-md-Fix-build-with-musl.patch
deleted file mode 100644
index f3cd670026..0000000000
--- a/meta/recipes-support/nspr/nspr/0001-md-Fix-build-with-musl.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 147f3c2acbd96d44025cec11800ded0282327764 Mon Sep 17 00:00:00 2001
-From: Khem Raj <raj.khem@gmail.com>
-Date: Mon, 18 Sep 2017 17:22:43 -0700
-Subject: [PATCH] md: Fix build with musl
-
-The MIPS specific header <sgidefs.h> is not provided by musl
-linux kernel headers provide <asm/sgidefs.h> which has same definitions
-
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
----
-Upstream-Status: Pending
-
- pr/include/md/_linux.cfg | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/pr/include/md/_linux.cfg b/pr/include/md/_linux.cfg
-index 640b19c..31296a8 100644
---- a/pr/include/md/_linux.cfg
-+++ b/pr/include/md/_linux.cfg
-@@ -499,7 +499,7 @@
- #elif defined(__mips__)
- 
- /* For _ABI64 */
--#include <sgidefs.h>
-+#include <asm/sgidefs.h>
- 
- #ifdef __MIPSEB__
- #define IS_BIG_ENDIAN 1
--- 
-2.14.1
-
diff --git a/meta/recipes-support/nspr/nspr/0002-Add-nios2-support.patch b/meta/recipes-support/nspr/nspr/0002-Add-nios2-support.patch
deleted file mode 100644
index 3a04d426a8..0000000000
--- a/meta/recipes-support/nspr/nspr/0002-Add-nios2-support.patch
+++ /dev/null
@@ -1,102 +0,0 @@
-From 95bda64fb4cf1825fea745e918cfe8202843f0ba Mon Sep 17 00:00:00 2001
-From: Marek Vasut <marex@denx.de>
-Date: Sat, 30 Jan 2016 07:18:02 +0100
-Subject: [PATCH] Add nios2 support
-
-Add support for the nios2 CPU.
-
-Signed-off-by: Marek Vasut <marex@denx.de>
-Upstream-Status: Submitted [ https://bugzilla.mozilla.org/show_bug.cgi?id=1244421 ]
----
- nspr/pr/include/md/_linux.cfg | 45 +++++++++++++++++++++++++++++++++++++++++++
- nspr/pr/include/md/_linux.h   | 14 ++++++++++++++
- 2 files changed, 59 insertions(+)
-
-Index: nspr/pr/include/md/_linux.cfg
-===================================================================
---- nspr.orig/pr/include/md/_linux.cfg
-+++ nspr/pr/include/md/_linux.cfg
-@@ -975,6 +975,51 @@
- #define PR_BYTES_PER_WORD_LOG2   2
- #define PR_BYTES_PER_DWORD_LOG2  3
- 
-+#elif defined(__nios2__)
-+
-+#define IS_LITTLE_ENDIAN    1
-+#undef  IS_BIG_ENDIAN
-+
-+#define PR_BYTES_PER_BYTE   1
-+#define PR_BYTES_PER_SHORT  2
-+#define PR_BYTES_PER_INT    4
-+#define PR_BYTES_PER_INT64  8
-+#define PR_BYTES_PER_LONG   4
-+#define PR_BYTES_PER_FLOAT  4
-+#define PR_BYTES_PER_DOUBLE 8
-+#define PR_BYTES_PER_WORD   4
-+#define PR_BYTES_PER_DWORD  8
-+
-+#define PR_BITS_PER_BYTE    8
-+#define PR_BITS_PER_SHORT   16
-+#define PR_BITS_PER_INT     32
-+#define PR_BITS_PER_INT64   64
-+#define PR_BITS_PER_LONG    32
-+#define PR_BITS_PER_FLOAT   32
-+#define PR_BITS_PER_DOUBLE  64
-+#define PR_BITS_PER_WORD    32
-+
-+#define PR_BITS_PER_BYTE_LOG2   3
-+#define PR_BITS_PER_SHORT_LOG2  4
-+#define PR_BITS_PER_INT_LOG2    5
-+#define PR_BITS_PER_INT64_LOG2  6
-+#define PR_BITS_PER_LONG_LOG2   5
-+#define PR_BITS_PER_FLOAT_LOG2  5
-+#define PR_BITS_PER_DOUBLE_LOG2 6
-+#define PR_BITS_PER_WORD_LOG2   5
-+
-+#define PR_ALIGN_OF_SHORT   2
-+#define PR_ALIGN_OF_INT     4
-+#define PR_ALIGN_OF_LONG    4
-+#define PR_ALIGN_OF_INT64   4
-+#define PR_ALIGN_OF_FLOAT   4
-+#define PR_ALIGN_OF_DOUBLE  4
-+#define PR_ALIGN_OF_POINTER 4
-+#define PR_ALIGN_OF_WORD    4
-+
-+#define PR_BYTES_PER_WORD_LOG2   2
-+#define PR_BYTES_PER_DWORD_LOG2  3
-+
- #elif defined(__or1k__)
- 
- #undef  IS_LITTLE_ENDIAN
-Index: nspr/pr/include/md/_linux.h
-===================================================================
---- nspr.orig/pr/include/md/_linux.h
-+++ nspr/pr/include/md/_linux.h
-@@ -55,6 +55,8 @@
- #define _PR_SI_ARCHITECTURE "avr32"
- #elif defined(__m32r__)
- #define _PR_SI_ARCHITECTURE "m32r"
-+#elif defined(__nios2__)
-+#define _PR_SI_ARCHITECTURE "nios2"
- #elif defined(__or1k__)
- #define _PR_SI_ARCHITECTURE "or1k"
- #elif defined(__riscv) && (__riscv_xlen == 32)
-@@ -129,6 +131,18 @@ extern PRInt32 _PR_x86_64_AtomicSet(PRIn
- #define _MD_ATOMIC_SET                _PR_x86_64_AtomicSet
- #endif
- 
-+#if defined(__nios2__)
-+#if defined(__GNUC__)
-+/* Use GCC built-in functions */
-+#define _PR_HAVE_ATOMIC_OPS
-+#define _MD_INIT_ATOMIC()
-+#define _MD_ATOMIC_INCREMENT(ptr) __sync_add_and_fetch(ptr, 1)
-+#define _MD_ATOMIC_DECREMENT(ptr) __sync_sub_and_fetch(ptr, 1)
-+#define _MD_ATOMIC_ADD(ptr, i) __sync_add_and_fetch(ptr, i)
-+#define _MD_ATOMIC_SET(ptr, nv) __sync_lock_test_and_set(ptr, nv)
-+#endif
-+#endif
-+
- #if defined(__or1k__)
- #if defined(__GNUC__)
- /* Use GCC built-in functions */
diff --git a/meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch b/meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch
deleted file mode 100644
index 90fe45f34d..0000000000
--- a/meta/recipes-support/nspr/nspr/Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch
+++ /dev/null
@@ -1,103 +0,0 @@
-From 8a592e4ead4ed6befe6044da3dd2dc7523c33905 Mon Sep 17 00:00:00 2001
-From: Mingli Yu <Mingli.Yu@windriver.com>
-Date: Fri, 16 Nov 2018 13:52:49 +0800
-Subject: [PATCH] Makefile.in: remove _BUILD_STRING and _BUILD_TIME
-
-Remove _BUILD_STRING and _BUILD_TIME to avoid
-adding timestamp to _pl_bld.h which can result
-in adding timestamp in library file such as
-libnspr4.so.
- $ readelf --wide --decompress --hex-dump=.rodata libnspr4.so
- [snip]
-  0x00004000 32303138 2d31312d 31352030 353a3439 2018-11-15 05:49
- [snip]
-
-Upstream-Status: Pending
-
-Signed-off-by: Mingli Yu <Mingli.Yu@windriver.com>
----
- lib/ds/Makefile.in        | 8 +-------
- lib/libc/src/Makefile.in  | 8 +-------
- lib/prstreams/Makefile.in | 8 +-------
- pr/src/Makefile.in        | 8 +-------
- 4 files changed, 4 insertions(+), 28 deletions(-)
-
-diff --git a/lib/ds/Makefile.in b/lib/ds/Makefile.in
-index e737791..b578476 100644
---- a/lib/ds/Makefile.in
-+++ b/lib/ds/Makefile.in
-@@ -114,13 +114,7 @@ GARBAGE += $(TINC)
- 
- $(TINC):
- 	@$(MAKE_OBJDIR)
--	@$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
--	@if test ! -z "$(SH_NOW)"; then \
--	    $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
--	else \
--	    true; \
--	fi
--	@$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
-+	@$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
- 
- 
- $(OBJDIR)/plvrsion.$(OBJ_SUFFIX): plvrsion.c $(TINC)
-diff --git a/lib/libc/src/Makefile.in b/lib/libc/src/Makefile.in
-index e8a6d9f..978ed28 100644
---- a/lib/libc/src/Makefile.in
-+++ b/lib/libc/src/Makefile.in
-@@ -116,13 +116,7 @@ GARBAGE += $(TINC)
- 
- $(TINC):
- 	@$(MAKE_OBJDIR)
--	@$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
--	@if test ! -z "$(SH_NOW)"; then \
--	    $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
--	else \
--	    true; \
--	fi
--	@$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
-+	@$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
- 
- 
- $(OBJDIR)/plvrsion.$(OBJ_SUFFIX): plvrsion.c $(TINC)
-diff --git a/lib/prstreams/Makefile.in b/lib/prstreams/Makefile.in
-index aeb2944..f318097 100644
---- a/lib/prstreams/Makefile.in
-+++ b/lib/prstreams/Makefile.in
-@@ -116,13 +116,7 @@ endif
- 
- $(TINC):
- 	@$(MAKE_OBJDIR)
--	@$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
--	@if test ! -z "$(SH_NOW)"; then \
--	    $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
--	else \
--	    true; \
--	fi
--	@$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
-+	@$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
- 
- 
- $(OBJDIR)/plvrsion.$(OBJ_SUFFIX): plvrsion.c $(TINC)
-diff --git a/pr/src/Makefile.in b/pr/src/Makefile.in
-index 19c5a69..b4ac31c 100644
---- a/pr/src/Makefile.in
-+++ b/pr/src/Makefile.in
-@@ -326,13 +326,7 @@ GARBAGE += $(TINC)
- 
- $(TINC):
- 	@$(MAKE_OBJDIR)
--	@$(ECHO) '#define _BUILD_STRING "$(SH_DATE)"' > $(TINC)
--	@if test ! -z "$(SH_NOW)"; then \
--	    $(ECHO) '#define _BUILD_TIME $(SH_NOW)$(SUF)' >> $(TINC); \
--	else \
--	    true; \
--	fi
--	@$(ECHO) '#define _PRODUCTION "$(PROD)"' >> $(TINC)
-+	@$(ECHO) '#define _PRODUCTION "$(PROD)"' > $(TINC)
- 
- 
- $(OBJDIR)/prvrsion.$(OBJ_SUFFIX): prvrsion.c $(TINC)
--- 
-2.7.4
-
diff --git a/meta/recipes-support/nspr/nspr/fix-build-on-x86_64.patch b/meta/recipes-support/nspr/nspr/fix-build-on-x86_64.patch
deleted file mode 100644
index f12acc8548..0000000000
--- a/meta/recipes-support/nspr/nspr/fix-build-on-x86_64.patch
+++ /dev/null
@@ -1,52 +0,0 @@
-Fix build failure on x86_64
-
-When the target_cpu is x86_64, we should assume that the pkg uses 64bit,
-only if USE_N32 is set, we can assume that the pkg uses 32bit. It used a
-opposite logic before.
-
-Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
-
-Upstream-Status: Pending
----
- configure.in |   12 ++++++------
- 1 files changed, 6 insertions(+), 6 deletions(-)
-
-Index: nspr/configure.in
-===================================================================
---- nspr.orig/configure.in
-+++ nspr/configure.in
-@@ -1875,28 +1875,24 @@ tools are selected during the Xcode/Deve
-         PR_MD_ASFILES=os_Linux_ia64.s
-         ;;
-     x86_64)
--        if test -n "$USE_64"; then
--            PR_MD_ASFILES=os_Linux_x86_64.s
--        elif test -n "$USE_X32"; then
-+        if test -n "$USE_X32"; then
-+            AC_DEFINE(i386)
-             PR_MD_ASFILES=os_Linux_x86_64.s
-             CC="$CC -mx32"
-             CXX="$CXX -mx32"
-         else
--            AC_DEFINE(i386)
--            PR_MD_ASFILES=os_Linux_x86.s
--            CC="$CC -m32"
--            CXX="$CXX -m32"
-+            PR_MD_ASFILES=os_Linux_x86_64.s
-         fi
-         ;;
-     ppc|powerpc)
-         PR_MD_ASFILES=os_Linux_ppc.s
-         ;;
-     powerpc64)
--        if test -n "$USE_64"; then
-+        if test -n "$USE_N32"; then
-+            PR_MD_ASFILES=os_Linux_ppc.s
-+        else
-             CC="$CC -m64"
-             CXX="$CXX -m64"
--        else
--            PR_MD_ASFILES=os_Linux_ppc.s
-         fi
-         ;;
-     esac    
diff --git a/meta/recipes-support/nspr/nspr/nspr.pc.in b/meta/recipes-support/nspr/nspr/nspr.pc.in
deleted file mode 100644
index 1f15d19cfa..0000000000
--- a/meta/recipes-support/nspr/nspr/nspr.pc.in
+++ /dev/null
@@ -1,11 +0,0 @@
-os_libs=-lpthread -ldl
-prefix=OEPREFIX
-exec_prefix=OEEXECPREFIX
-libdir=OELIBDIR
-includedir=OEINCDIR
-
-Name: NSPR
-Description: The Netscape Portable Runtime
-Version: NSPRVERSION
-Libs: -L${libdir} -lplds4 -lplc4 -lnspr4 -lpthread -ldl
-Cflags: -I${includedir}/nspr
diff --git a/meta/recipes-support/nspr/nspr/remove-rpath-from-tests.patch b/meta/recipes-support/nspr/nspr/remove-rpath-from-tests.patch
deleted file mode 100644
index 7ba59ed644..0000000000
--- a/meta/recipes-support/nspr/nspr/remove-rpath-from-tests.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-Author: Andrei Gherzan <andrei@gherzan.ro>
-Date:   Thu Feb 9 00:03:38 2012 +0200
-
-Avoid QA warnings by removing hardcoded rpath from binaries.
-
-[...]
-WARNING: QA Issue: package nspr contains bad RPATH {builddir}/tmp/work/armv5te-poky-linux-gnueabi/nspr-4.8.9-r1/nspr-4.8.9/mozilla/nsprpub/pr/tests/../../dist/lib
-in file {builddir}/tmp/work/armv5te-poky-linux-gnueabi/nspr-4.8.9-r1/packages-split/nspr/usr/lib/nspr/tests/multiwait
-[...]
-
-Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
-Upstream-Status: Pending
-
-Index: nspr/pr/tests/Makefile.in
-===================================================================
---- nspr.orig/pr/tests/Makefile.in
-+++ nspr/pr/tests/Makefile.in
-@@ -316,7 +316,7 @@ ifeq ($(OS_ARCH), SunOS)
- endif # SunOS
- 
- ifeq (,$(filter-out Linux GNU GNU_%,$(OS_ARCH)))
--    LDOPTS += -Xlinker -rpath $(ABSOLUTE_LIB_DIR)
-+    LDOPTS += -Xlinker
-     ifeq ($(USE_PTHREADS),1)
-         EXTRA_LIBS = -lpthread
-     endif
diff --git a/meta/recipes-support/nspr/nspr/remove-srcdir-from-configure-in.patch b/meta/recipes-support/nspr/nspr/remove-srcdir-from-configure-in.patch
deleted file mode 100644
index bde715c5dc..0000000000
--- a/meta/recipes-support/nspr/nspr/remove-srcdir-from-configure-in.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-the $srcdir is not defined at the time of gnu-configurize.
-
-Upstream-Status: Inappropriate [OE-Core specific]
-
-Signed-off-by: Saul Wold <sgw@linux.intel.com>
-
-Index: nspr/configure.in
-===================================================================
---- nspr.orig/configure.in
-+++ nspr/configure.in
-@@ -8,7 +8,7 @@ AC_PREREQ(2.61)
- AC_INIT
- AC_CONFIG_SRCDIR([pr/include/nspr.h])
- 
--AC_CONFIG_AUX_DIR(${srcdir}/build/autoconf)
-+AC_CONFIG_AUX_DIR(build/autoconf)
- AC_CANONICAL_TARGET
- 
- dnl ========================================================
diff --git a/meta/recipes-support/nspr/nspr_4.25.bb b/meta/recipes-support/nspr/nspr_4.25.bb
deleted file mode 100644
index 1de26e1eed..0000000000
--- a/meta/recipes-support/nspr/nspr_4.25.bb
+++ /dev/null
@@ -1,197 +0,0 @@
-SUMMARY = "Netscape Portable Runtime Library"
-HOMEPAGE =  "http://www.mozilla.org/projects/nspr/"
-LICENSE = "GPL-2.0 | MPL-2.0 | LGPL-2.1"
-LIC_FILES_CHKSUM = "file://configure.in;beginline=3;endline=6;md5=90c2fdee38e45d6302abcfe475c8b5c5 \
-                    file://Makefile.in;beginline=4;endline=38;md5=beda1dbb98a515f557d3e58ef06bca99"
-SECTION = "libs/network"
-
-SRC_URI = "http://ftp.mozilla.org/pub/nspr/releases/v${PV}/src/nspr-${PV}.tar.gz \
-           file://remove-rpath-from-tests.patch \
-           file://fix-build-on-x86_64.patch \
-           file://remove-srcdir-from-configure-in.patch \
-           file://0002-Add-nios2-support.patch \
-           file://0001-md-Fix-build-with-musl.patch \
-           file://Makefile.in-remove-_BUILD_STRING-and-_BUILD_TIME.patch \
-           file://nspr.pc.in \
-"
-
-CACHED_CONFIGUREVARS_append_libc-musl = " CFLAGS='${CFLAGS} -D_PR_POLL_AVAILABLE \
-                                          -D_PR_HAVE_OFF64_T -D_PR_INET6 -D_PR_HAVE_INET_NTOP \
-                                          -D_PR_HAVE_GETHOSTBYNAME2 -D_PR_HAVE_GETADDRINFO \
-                                          -D_PR_INET6_PROBE -DNO_DLOPEN_NULL'"
-
-UPSTREAM_CHECK_URI = "http://ftp.mozilla.org/pub/nspr/releases/"
-UPSTREAM_CHECK_REGEX = "v(?P<pver>\d+(\.\d+)+)/"
-
-SRC_URI[md5sum] = "4ca4d75a424f30fcdc766296bb103d17"
-SRC_URI[sha256sum] = "0bc309be21f91da4474c56df90415101c7f0c7c7cab2943cd943cd7896985256"
-
-CVE_PRODUCT = "netscape_portable_runtime"
-
-S = "${WORKDIR}/nspr-${PV}/nspr"
-
-RDEPENDS_${PN}-dev += "perl"
-TARGET_CC_ARCH += "${LDFLAGS}"
-
-TESTS = " \
-    accept \
-    acceptread \
-    acceptreademu \
-    affinity \
-    alarm \
-    anonfm \
-    atomic \
-    attach \
-    bigfile \
-    cleanup \
-    cltsrv  \
-    concur \
-    cvar \
-    cvar2 \
-    dlltest \
-    dtoa \
-    errcodes \
-    exit \
-    fdcach \
-    fileio \
-    foreign \
-    formattm \
-    fsync \
-    gethost \
-    getproto \
-    i2l \
-    initclk \
-    inrval \
-    instrumt \
-    intrio \
-    intrupt \
-    io_timeout \
-    ioconthr \
-    join \
-    joinkk \
-    joinku \
-    joinuk \
-    joinuu \
-    layer \
-    lazyinit \
-    libfilename \
-    lltest \
-    lock \
-    lockfile \
-    logfile \
-    logger \
-    many_cv \
-    multiwait \
-    nameshm1 \
-    nblayer \
-    nonblock \
-    ntioto \
-    ntoh \
-    op_2long \
-    op_excl \
-    op_filnf \
-    op_filok \
-    op_nofil \
-    parent \
-    parsetm \
-    peek \
-    perf \
-    pipeping \
-    pipeping2 \
-    pipeself \
-    poll_nm \
-    poll_to \
-    pollable \
-    prftest \
-    primblok \
-    provider \
-    prpollml \
-    ranfile \
-    randseed \
-    reinit \
-    rwlocktest \
-    sel_spd \
-    selct_er \
-    selct_nm \
-    selct_to \
-    selintr \
-    sema \
-    semaerr \
-    semaping \
-    sendzlf \
-    server_test \
-    servr_kk \
-    servr_uk \
-    servr_ku \
-    servr_uu \
-    short_thread \
-    sigpipe \
-    socket \
-    sockopt \
-    sockping \
-    sprintf \
-    stack \
-    stdio \
-    str2addr \
-    strod \
-    switch \
-    system \
-    testbit \
-    testfile \
-    threads \
-    timemac \
-    timetest \
-    tpd \
-    udpsrv \
-    vercheck \
-    version \
-    writev \
-    xnotify \
-    zerolen"
-
-inherit autotools multilib_script
-
-MULTILIB_SCRIPTS = "${PN}-dev:${bindir}/nspr-config"
-
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
-PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
-
-# Do not install nspr in usr/include, but in usr/include/nspr, the
-# preferred path upstream.
-EXTRA_OECONF += "--includedir=${includedir}/nspr"
-
-do_compile_prepend() {
-	oe_runmake CROSS_COMPILE=1 CFLAGS="-DXP_UNIX ${BUILD_CFLAGS}" LDFLAGS="" CC="${BUILD_CC}" -C config export
-}
-
-do_compile_append() {
-	oe_runmake -C pr/tests
-}
-
-do_install_append() {
-    install -D ${WORKDIR}/nspr.pc.in ${D}${libdir}/pkgconfig/nspr.pc
-    sed -i  \
-    -e 's:NSPRVERSION:${PV}:g' \
-    -e 's:OEPREFIX:${prefix}:g' \
-    -e 's:OELIBDIR:${libdir}:g' \
-    -e 's:OEINCDIR:${includedir}:g' \
-    -e 's:OEEXECPREFIX:${exec_prefix}:g' \
-    ${D}${libdir}/pkgconfig/nspr.pc
-
-    mkdir -p ${D}${libdir}/nspr/tests
-    install -m 0755 ${S}/pr/tests/runtests.pl ${D}${libdir}/nspr/tests
-    install -m 0755 ${S}/pr/tests/runtests.sh ${D}${libdir}/nspr/tests
-    cd ${B}/pr/tests
-    install -m 0755 ${TESTS} ${D}${libdir}/nspr/tests
-
-    # delete compile-et.pl and perr.properties from ${bindir} because these are
-    # only used to generate prerr.c and prerr.h files from prerr.et at compile
-    # time
-    rm ${D}${bindir}/compile-et.pl ${D}${bindir}/prerr.properties
-}
-
-FILES_${PN} = "${libdir}/lib*.so"
-FILES_${PN}-dev = "${bindir}/* ${libdir}/nspr/tests/* ${libdir}/pkgconfig \
-                ${includedir}/* ${datadir}/aclocal/* "
-
-BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1



^ permalink raw reply related	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-02-23 19:34 [RFC][PATCH 1/2] nss: Move to meta-oe Adrian Bunk
  2020-02-23 19:34 ` [RFC][PATCH 2/2] nspr: " Adrian Bunk
@ 2020-02-24  0:25 ` Khem Raj
  2020-02-24  5:17   ` Adrian Bunk
  1 sibling, 1 reply; 27+ messages in thread
From: Khem Raj @ 2020-02-24  0:25 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Patches and discussions about the oe-core layer

On Sun, Feb 23, 2020 at 11:34 AM Adrian Bunk <bunk@stusta.de> wrote:
>
> rpm was the last user in OE-core.
>

we should also assess external dependencies especially on libraries,
there might be layers which do not depend on meta-oe but use nss
or enable nss packageconfigs in core components like curl.

> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> ---
>  meta/conf/distro/include/maintainers.inc      |   1 -
>  ...figure-option-to-disable-ARM-HW-cryp.patch |  52 ----
>  ...0001-nss-fix-support-cross-compiling.patch |  48 ---
>  meta/recipes-support/nss/nss/blank-cert9.db   | Bin 28672 -> 0 bytes
>  meta/recipes-support/nss/nss/blank-key4.db    | Bin 36864 -> 0 bytes
>  .../nss/nss/disable-Wvarargs-with-clang.patch |  33 ---
>  .../nss-fix-incorrect-shebang-of-perl.patch   | 110 -------
>  .../nss/nss/nss-fix-nsinstall-build.patch     |  36 ---
>  .../nss-no-rpath-for-cross-compiling.patch    |  26 --
>  meta/recipes-support/nss/nss/nss.pc.in        |  11 -
>  .../nss/nss/pqg.c-ULL_addend.patch            |  23 --
>  meta/recipes-support/nss/nss/signlibs.sh      |  20 --
>  .../recipes-support/nss/nss/system-pkcs11.txt |   5 -
>  meta/recipes-support/nss/nss_3.50.bb          | 273 ------------------
>  14 files changed, 638 deletions(-)
>  delete mode 100644 meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
>  delete mode 100644 meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch
>  delete mode 100644 meta/recipes-support/nss/nss/blank-cert9.db
>  delete mode 100644 meta/recipes-support/nss/nss/blank-key4.db
>  delete mode 100644 meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch
>  delete mode 100644 meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch
>  delete mode 100644 meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch
>  delete mode 100644 meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch
>  delete mode 100644 meta/recipes-support/nss/nss/nss.pc.in
>  delete mode 100644 meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch
>  delete mode 100644 meta/recipes-support/nss/nss/signlibs.sh
>  delete mode 100644 meta/recipes-support/nss/nss/system-pkcs11.txt
>  delete mode 100644 meta/recipes-support/nss/nss_3.50.bb
>
> diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
> index 8f612ace39..e4b710d640 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -526,7 +526,6 @@ RECIPE_MAINTAINER_pn-nfs-utils = "Robert Yang <liezhi.yang@windriver.com>"
>  RECIPE_MAINTAINER_pn-ninja = "Khem Raj <raj.khem@gmail.com>"
>  RECIPE_MAINTAINER_pn-npth = "Alexander Kanavin <alex.kanavin@gmail.com>"
>  RECIPE_MAINTAINER_pn-nspr = "Armin Kuster <akuster808@gmail.com>"
> -RECIPE_MAINTAINER_pn-nss = "Armin Kuster <akuster808@gmail.com>"
>  RECIPE_MAINTAINER_pn-nss-myhostname = "Anuj Mittal <anuj.mittal@intel.com>"
>  RECIPE_MAINTAINER_pn-ofono = "Ross Burton <ross.burton@intel.com>"
>  RECIPE_MAINTAINER_pn-opensbi = "Alistair Francis <alistair.francis@wdc.com>"
> diff --git a/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch b/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
> deleted file mode 100644
> index c380c14491..0000000000
> --- a/meta/recipes-support/nss/nss/0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch
> +++ /dev/null
> @@ -1,52 +0,0 @@
> -From 5595e9651aca39af945931c73eb524a0f8bd130d Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin <alex.kanavin@gmail.com>
> -Date: Wed, 18 Dec 2019 12:29:50 +0100
> -Subject: [PATCH] freebl: add a configure option to disable ARM HW crypto
> -
> -Not all current hardware supports it, particularly anything
> -prior to armv8 does not.
> -
> -Upstream-Status: Pending
> -Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ----
> - nss/lib/freebl/Makefile | 3 +++
> - 1 file changed, 3 insertions(+)
> -
> ---- a/nss/lib/freebl/Makefile
> -+++ b/nss/lib/freebl/Makefile
> -@@ -125,6 +125,9 @@ else
> -         DEFINES += -DNSS_X86
> - endif
> - endif
> -+
> -+ifdef NSS_USE_ARM_HW_CRYPTO
> -+    DEFINES += -DNSS_USE_ARM_HW_CRYPTO
> - ifeq ($(CPU_ARCH),aarch64)
> -     DEFINES += -DUSE_HW_AES
> -     EXTRA_SRCS += aes-armv8.c gcm-aarch64.c
> -@@ -146,6 +149,7 @@ ifeq ($(CPU_ARCH),arm)
> -         endif
> -     endif
> - endif
> -+endif
> -
> - ifeq ($(OS_TARGET),OSF1)
> -     DEFINES += -DMP_ASSEMBLY_MULTIPLY -DMP_NO_MP_WORD
> ---- a/nss/lib/freebl/gcm.c
> -+++ b/nss/lib/freebl/gcm.c
> -@@ -17,6 +17,7 @@
> -
> - #include <limits.h>
> -
> -+#ifdef NSS_USE_ARM_HW_CRYPTO
> - /* old gcc doesn't support some poly64x2_t intrinsic */
> - #if defined(__aarch64__) && defined(IS_LITTLE_ENDIAN) && \
> -     (defined(__clang__) || defined(__GNUC__) && __GNUC__ > 6)
> -@@ -25,6 +26,7 @@
> - /* We don't test on big endian platform, so disable this on big endian. */
> - #define USE_ARM_GCM
> - #endif
> -+#endif
> -
> - /* Forward declarations */
> - SECStatus gcm_HashInit_hw(gcmHashContext *ghash);
> diff --git a/meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch b/meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch
> deleted file mode 100644
> index d5403397e7..0000000000
> --- a/meta/recipes-support/nss/nss/0001-nss-fix-support-cross-compiling.patch
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -From 0cf47ee432cc26a706864fcc09b2c3adc342a679 Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin <alex.kanavin@gmail.com>
> -Date: Wed, 22 Feb 2017 11:36:11 +0200
> -Subject: [PATCH] nss: fix support cross compiling
> -
> -Let some make variables be assigned from outside makefile.
> -
> -Upstream-Status: Inappropriate [configuration]
> -Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> -Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ----
> - nss/coreconf/arch.mk    | 2 +-
> - nss/lib/freebl/Makefile | 6 ++++++
> - 2 files changed, 7 insertions(+), 1 deletion(-)
> -
> -diff --git a/nss/coreconf/arch.mk b/nss/coreconf/arch.mk
> -index 06c276f..9c1eb51 100644
> ---- a/nss/coreconf/arch.mk
> -+++ b/nss/coreconf/arch.mk
> -@@ -30,7 +30,7 @@ OS_TEST := $(shell uname -m)
> - ifeq ($(OS_TEST),i86pc)
> -     OS_RELEASE := $(shell uname -r)_$(OS_TEST)
> - else
> --    OS_RELEASE := $(shell uname -r)
> -+    OS_RELEASE ?= $(shell uname -r)
> - endif
> -
> - #
> -diff --git a/nss/lib/freebl/Makefile b/nss/lib/freebl/Makefile
> -index 0ce1425..ebeb411 100644
> ---- a/nss/lib/freebl/Makefile
> -+++ b/nss/lib/freebl/Makefile
> -@@ -36,6 +36,12 @@ ifdef USE_64
> -       DEFINES += -DNSS_USE_64
> - endif
> -
> -+ifeq ($(OS_TEST),mips)
> -+ifndef USE_64
> -+       DEFINES += -DNS_PTR_LE_32
> -+endif
> -+endif
> -+
> - ifdef USE_ABI32_FPU
> -       DEFINES += -DNSS_USE_ABI32_FPU
> - endif
> ---
> -2.11.0
> -
> diff --git a/meta/recipes-support/nss/nss/blank-cert9.db b/meta/recipes-support/nss/nss/blank-cert9.db
> deleted file mode 100644
> index 7d4bcf2582d510f7b51d4306706746178c41fbbc..0000000000000000000000000000000000000000
> GIT binary patch
> literal 0
> HcmV?d00001
>
> literal 28672
> zcmeH~OK;Oa6ou_RTxhB2E<!9aOCljO58HJ%sA+4Yh?2G;mFNOhcH&Bb(26FJSh8cs
> zo*x9ii4|h*_1I~<VaFmmmVA3=?%XpopQn-L?dj2YR*1{%n@`zH7;ne(eQ!?)&+~ly
> zZrHba)~#5p8ul;c|MmFZ3-M$7@oz8K{Np`(`1t46udT0Jd$xfG1V8`;KmY_l00ck)
> z1pYgLy&z~bn*RCtYE*m~e$2+BtLgM)o=?WZje~yL8Kk1yJ51jR&WYomsPp1krlfAY
> zTxW+fc9>*&F{wuccN{o(-@&vF*Mi2=rvIMnr}O+nF`U&7>vtSn_P&Rbs?}Ky8c(Wy
> zjHlCiaZ{VD-7zVX_dOET`quV08qKEvy)(=5Nl};AV#WCkI{QcIZ4Tp+IO%uabo%Gw
> zb$Tw&dfn5rlx8?M?!7wd9t=ch|F}PRE;4CfWnXPyLz+9NM^RTo&4ii>H)%)`Qiv$T
> z6m}^j6xtLr3b_q!wvuIJM@b$^mh+H{l4PSK`6x+7N|KY3WThl|DM@BZ4k^0jmFr_?
> zU21mL?5x>Yv$JMr&CZ&g4ObbiGF)Z2%5YW8*_g92XJgLBWtKf-_T1%>%ttXG%{$eS
> zYBldv^J+tBAFZg{N%A#3+VE(@qivFhlmlr@$fQC^bB9bSWKto|8uF|mf0u}BBX*0}
> zE#lf?5t-0LWa%XNI!POIl4fv{w&*17(@6s8BvC9SLveCZ#&}%sqAae;;>B{Ttd?VC
> zwHzy}<ycwyT3Ic}%F5TuTfTH=Xkyz-2ggY|Jx<aQa&okg#X?@zk`F>THeW0!r{#>I
> zOpbCUp3t|IjGe}YCgyXi+by*cG}5N;l|Le%C-z2vk<Dk<+`g#)gD+GqSM5*j1Nyn$
> zrm#Z+4+ww&2!H?xfB*=900@8p2!H?xfWWd6*rbi&{=clB7yAMM5C8!X009sH0T2KI
> z5C8!X00Aa|`#%l>2!H?xfB*=900@8p2!H?xfB*<AKLOnTm;W1Mhadm~AOHd&00JNY
> z0w4eaAOHd&fcrnr00@8p2!H?xfB*=900@8p2!H?xEI$F<|Cj$8V}~FB0w4eaAOHd&
> O00JNY0w4eaAn+IM<WtiC
>
> diff --git a/meta/recipes-support/nss/nss/blank-key4.db b/meta/recipes-support/nss/nss/blank-key4.db
> deleted file mode 100644
> index d47f08d04fe82197bc6a39ef9bf216b61c3dc77a..0000000000000000000000000000000000000000
> GIT binary patch
> literal 0
> HcmV?d00001
>
> literal 36864
> zcmeI)Pj3@P7zXfN$JsbGQBr~AB4lZNXcZIG&g?%N!~w@RZQ3*mZcvLjSnGHJQ-_q;
> zfnEyAB}g2&RFzt!s;9Q+svn?82vt4w)Lub+1tcV(r_THCZkH&E#0_CRt9bl+XXe@2
> z-!3E@BtAW}*d2u8!p7!$Fc6M0WtgUMN(jR+GWs>HU&&_aBAa~B@8(POer3jZPkcWy
> z`P|6mo5q3c<o&|$h3f?`|0Lhc-`j5z_Co*y5P$##AOHafyh#GRv9V&QWNyz4f_5)l
> z4+p{NU=Sqlxq7ovTWyHd+T3D8Bzwhlw<A`X3!l`Q=fua2bK>mM!kM!TvAiVe%S-c%
> z3-wjeY^*HS>WyPU|Gc`cqBpzpe$Fb^OQzAi(h0xnU+wA6R<JeL;Loijzon9De9p3p
> z#j<&x2dsS&bURo2{gut`wO|mA#fw{5I^FnOa3?Jx9U!IyCGE<oQO@{`GkQTg?4?7j
> zT^ZcDC&Q`CXRYFqve}B3z16-Pt_{+R(Ont+sC!R}lB!Z4v5JS2v+4HxTj6FJlid{)
> z_3lZjs>-dC=2)>@Ht*E=lBEG@m5HOG%a-ncl?zv!TW+o%6M@t(ecb|EzZ|N02klX`
> zt4bfM^s&kxX-L(j#-qlk<~TJ~YG$bksA=nFmZN0Ua-yURC8Og|ijowgB;_bcK}u4R
> zk`$#RWhqHvO0H2GFE3gjC)-iY$u=k3oNRNl&B-<=+nnt1EQe<~Jj>x(4$tzr*XLfJ
> zdwuTpqh8MRIrBJ=WFN&qHlL|2X|By@YV&GcsW)5E?zp5}heta++Tqc<lZQkDX^hKK
> zuB2nTEakG4%SUzjs4ia@kLP-v=5d<GbJs%8aUG8$<C1dYl1?lx=?HO2rx=%Xo^eTl
> zaY>3%$tZD|PGg>UZ#vCSrupe|beSwim&tN;nJh<_Nv<xF<>)fW)#XdMbkER%^<KJh
> z;*##3xTISsE<0%%rsakIOTH1JvF&s@ZCXyp3uLFw;#In~lG$mj>-c=%+OriWV--Ir
> z@Ap?=`e(JJ(t1RHN6FE5l?iI5sKEvS2tWV=5P$##AOHafKmY;|fWWW{<mtrl{6DOh
> z7v}{52tWV=5P$##AOHafKmY;|U;#Y;<3@l01Rwwb2tWV=5P$##AOHaf48H)L|A+q?
> z;|w7H0SG_<0uX=z1Rwwb2tWV=c>c#d009U<00Izz00bZa0SG_<0uUH}0X+W?|24)L
> zLI45~fB*y_009U<00Izz00ij&|2HRpH1roX2tWV=5P$##AOHafKmY;|fB*zuk3h>D
> zExFsdFN1#n`o?DG@A=!mz4-R0mFHhS{`aGMCw_gf{mystq@1=2M|VElc{X7l7&S-a
> z;q0N#(b>ECcfWb-&&$6&y8G8Z_h0;R>*tJVW~XMJ>|DC|(5t=u;D?(BCuVNYzyF()
> mPYwNr4FV8=00bZa0SG_<0uX=z1Rwx`ArdHzl*W_aDEtSkqPYeD
>
> diff --git a/meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch b/meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch
> deleted file mode 100644
> index de812d27ba..0000000000
> --- a/meta/recipes-support/nss/nss/disable-Wvarargs-with-clang.patch
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -clang 3.9 add this warning to rightly flag undefined
> -behavior, we relegate this to be just a warning instead
> -of error and keep the behavior as it was. Right fix would
> -be to not pass enum to the function with variadic arguments
> -as last named argument
> -
> -Fixes errors like
> -ocsp.c:2220:22: error: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior [-Werror,-Wvarargs]
> -        va_start(ap, responseType0);
> -                     ^
> -ocsp.c:2200:43: note: parameter of type 'SECOidTag' is declared here
> -                                SECOidTag responseType0, ...)
> -
> -see
> -https://www.securecoding.cert.org/confluence/display/cplusplus/EXP58-CPP.+Pass+an+object+of+the+correct+type+to+va_start
> -for more details
> -
> -Signed-off-by: Khem Raj <raj.khem@gmail.com>
> -Upstream-Status: Pending
> -
> -Index: nss-3.37.1/nss/coreconf/Werror.mk
> -===================================================================
> ---- nss-3.37.1.orig/nss/coreconf/Werror.mk
> -+++ nss-3.37.1/nss/coreconf/Werror.mk
> -@@ -56,7 +56,7 @@ ifndef WARNING_CFLAGS
> -     ifdef CC_IS_CLANG
> -       # -Qunused-arguments : clang objects to arguments that it doesn't understand
> -       #    and fixing this would require rearchitecture
> --      WARNING_CFLAGS += -Qunused-arguments
> -+      WARNING_CFLAGS += -Qunused-arguments -Wno-error=varargs
> -       # -Wno-parentheses-equality : because clang warns about macro expansions
> -       WARNING_CFLAGS += $(call disable_warning,parentheses-equality)
> -       ifdef BUILD_OPT
> diff --git a/meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch b/meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch
> deleted file mode 100644
> index 547594d5b6..0000000000
> --- a/meta/recipes-support/nss/nss/nss-fix-incorrect-shebang-of-perl.patch
> +++ /dev/null
> @@ -1,110 +0,0 @@
> -nss: fix incorrect shebang of perl
> -
> -Replace incorrect shebang of perl with `#!/usr/bin/env perl'.
> -
> -Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> -Upstream-Status: Pending
> ----
> - nss/cmd/smimetools/smime  | 2 +-
> - nss/coreconf/cpdist.pl    | 2 +-
> - nss/coreconf/import.pl    | 2 +-
> - nss/coreconf/jniregen.pl  | 2 +-
> - nss/coreconf/outofdate.pl | 2 +-
> - nss/coreconf/release.pl   | 2 +-
> - nss/coreconf/version.pl   | 2 +-
> - nss/tests/clean_tbx       | 2 +-
> - nss/tests/path_uniq       | 2 +-
> - 9 files changed, 9 insertions(+), 9 deletions(-)
> -
> -diff --git a/nss/cmd/smimetools/smime b/nss/cmd/smimetools/smime
> ---- a/nss/cmd/smimetools/smime
> -+++ b/nss/cmd/smimetools/smime
> -@@ -1,4 +1,4 @@
> --#!/usr/local/bin/perl
> -+#!/usr/bin/env perl
> -
> - # This Source Code Form is subject to the terms of the Mozilla Public
> - # License, v. 2.0. If a copy of the MPL was not distributed with this
> -diff --git a/nss/coreconf/cpdist.pl b/nss/coreconf/cpdist.pl
> -index 800edfb..652187f 100755
> ---- a/nss/coreconf/cpdist.pl
> -+++ b/nss/coreconf/cpdist.pl
> -@@ -1,4 +1,4 @@
> --#! /usr/local/bin/perl
> -+#!/usr/bin/env perl
> - #
> - # This Source Code Form is subject to the terms of the Mozilla Public
> - # License, v. 2.0. If a copy of the MPL was not distributed with this
> -diff --git a/nss/coreconf/import.pl b/nss/coreconf/import.pl
> -index dd2d177..428eaa5 100755
> ---- a/nss/coreconf/import.pl
> -+++ b/nss/coreconf/import.pl
> -@@ -1,4 +1,4 @@
> --#! /usr/local/bin/perl
> -+#!/usr/bin/env perl
> - #
> - # This Source Code Form is subject to the terms of the Mozilla Public
> - # License, v. 2.0. If a copy of the MPL was not distributed with this
> -diff --git a/nss/coreconf/jniregen.pl b/nss/coreconf/jniregen.pl
> -index 2039180..5f4f69c 100755
> ---- a/nss/coreconf/jniregen.pl
> -+++ b/nss/coreconf/jniregen.pl
> -@@ -1,4 +1,4 @@
> --#!/usr/local/bin/perl
> -+#!/usr/bin/env perl
> - #
> - # This Source Code Form is subject to the terms of the Mozilla Public
> - # License, v. 2.0. If a copy of the MPL was not distributed with this
> -diff --git a/nss/coreconf/outofdate.pl b/nss/coreconf/outofdate.pl
> -index 33d80bb..01fc097 100755
> ---- a/nss/coreconf/outofdate.pl
> -+++ b/nss/coreconf/outofdate.pl
> -@@ -1,4 +1,4 @@
> --#!/usr/local/bin/perl
> -+#!/usr/bin/env perl
> - #
> - # This Source Code Form is subject to the terms of the Mozilla Public
> - # License, v. 2.0. If a copy of the MPL was not distributed with this
> -diff --git a/nss/coreconf/release.pl b/nss/coreconf/release.pl
> -index 7cde19d..b5df2f6 100755
> ---- a/nss/coreconf/release.pl
> -+++ b/nss/coreconf/release.pl
> -@@ -1,4 +1,4 @@
> --#! /usr/local/bin/perl
> -+#!/usr/bin/env perl
> - #
> - # This Source Code Form is subject to the terms of the Mozilla Public
> - # License, v. 2.0. If a copy of the MPL was not distributed with this
> -diff --git a/nss/coreconf/version.pl b/nss/coreconf/version.pl
> -index d2a4942..79359fe 100644
> ---- a/nss/coreconf/version.pl
> -+++ b/nss/coreconf/version.pl
> -@@ -1,4 +1,4 @@
> --#!/usr/sbin/perl
> -+#!/usr/bin/env perl
> - #
> - # This Source Code Form is subject to the terms of the Mozilla Public
> - # License, v. 2.0. If a copy of the MPL was not distributed with this
> -diff --git a/nss/tests/clean_tbx b/nss/tests/clean_tbx
> -index 4de9555..a7def9f 100755
> ---- a/nss/tests/clean_tbx
> -+++ b/nss/tests/clean_tbx
> -@@ -1,4 +1,4 @@
> --#! /bin/perl
> -+#!/usr/bin/env perl
> -
> - #######################################################################
> - #
> -diff --git a/nss/tests/path_uniq b/nss/tests/path_uniq
> -index f29f60a..08fbffa 100755
> ---- a/nss/tests/path_uniq
> -+++ b/nss/tests/path_uniq
> -@@ -1,4 +1,4 @@
> --#! /bin/perl
> -+#!/usr/bin/env perl
> -
> - ########################################################################
> - #
> ---
> -1.8.1.2
> -
> diff --git a/meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch b/meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch
> deleted file mode 100644
> index 43c09d13ea..0000000000
> --- a/meta/recipes-support/nss/nss/nss-fix-nsinstall-build.patch
> +++ /dev/null
> @@ -1,36 +0,0 @@
> -Fix nss multilib build on openSUSE 11.x 32bit
> -
> -While building lib64-nss on openSUSE 11.x 32bit, the nsinstall will
> -fail with error:
> -
> -* nsinstall.c:1:0: sorry, unimplemented: 64-bit mode not compiled
> -
> -It caused by the '-m64' option which passed to host gcc.
> -
> -The nsinstall was built first while nss starting to build, it only runs
> -on host to install built files, it doesn't need any cross-compling or
> -multilib build options. Just clean the ARCHFLAG and LDFLAGS to fix this
> -error.
> -
> -Upstream-Status: Pending
> -
> -Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
> -===================================================
> -Index: nss-3.24/nss/coreconf/nsinstall/Makefile
> -===================================================================
> ---- nss-3.24.orig/nss/coreconf/nsinstall/Makefile
> -+++ nss-3.24/nss/coreconf/nsinstall/Makefile
> -@@ -18,6 +18,13 @@ INTERNAL_TOOLS  = 1
> -
> - include $(DEPTH)/coreconf/config.mk
> -
> -+# nsinstall is unfit for cross-compiling/multilib-build since it was
> -+# always run on local host to install built files. This change intends
> -+# to clean the '-m64' from ARCHFLAG and LDFLAGS.
> -+ARCHFLAG =
> -+LDFLAGS =
> -+# CFLAGS =
> -+
> - ifeq (,$(filter-out OS2 WIN%,$(OS_TARGET)))
> - PROGRAM               =
> - else
> diff --git a/meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch b/meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch
> deleted file mode 100644
> index 7661dc93a0..0000000000
> --- a/meta/recipes-support/nss/nss/nss-no-rpath-for-cross-compiling.patch
> +++ /dev/null
> @@ -1,26 +0,0 @@
> -nss:no rpath for cross compiling
> -
> -Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> -Upstream-Status: Inappropriate [configuration]
> ----
> - nss/cmd/platlibs.mk | 4 ++--
> - 1 file changed, 2 insertions(+), 2 deletions(-)
> -
> -diff --git a/nss/cmd/platlibs.mk b/nss/cmd/platlibs.mk
> ---- a/nss/cmd/platlibs.mk
> -+++ b/nss/cmd/platlibs.mk
> -@@ -18,9 +18,9 @@ endif
> -
> - ifeq ($(OS_ARCH), Linux)
> - ifeq ($(USE_64), 1)
> --EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib64:/opt/sun/private/lib64:$$ORIGIN/../lib'
> -+#EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib64:/opt/sun/private/lib64:$$ORIGIN/../lib'
> - else
> --EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib:/opt/sun/private/lib'
> -+#EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib:/opt/sun/private/lib'
> - endif
> - endif
> -
> ---
> -1.8.1.2
> -
> diff --git a/meta/recipes-support/nss/nss/nss.pc.in b/meta/recipes-support/nss/nss/nss.pc.in
> deleted file mode 100644
> index 402b4ecb33..0000000000
> --- a/meta/recipes-support/nss/nss/nss.pc.in
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -prefix=OEPREFIX
> -exec_prefix=OEEXECPREFIX
> -libdir=OELIBDIR
> -includedir=OEINCDIR
> -
> -Name: NSS
> -Description: Network Security Services
> -Version: %NSS_VERSION%
> -Requires: nspr >= %NSPR_VERSION%
> -Libs: -L${libdir} -lssl3 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3
> -Cflags: -IOEINCDIR
> diff --git a/meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch b/meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch
> deleted file mode 100644
> index 3a817faaa6..0000000000
> --- a/meta/recipes-support/nss/nss/pqg.c-ULL_addend.patch
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -nss does not build on mips with clang because wrong types are used?
> -
> -pqg.c:339:16: error: comparison of constant 18446744073709551615 with expression of type 'unsigned long' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
> -     if (addend < MP_DIGIT_MAX) {
> -       ~~~~~~ ^ ~~~~~~~~~~~~
> -
> -Signed-off-by: Khem Raj <raj.khem@gmail.com>
> -Upstream-Status: Pending
> -Index: nss-3.37.1/nss/lib/freebl/pqg.c
> -===================================================================
> ---- nss-3.37.1.orig/nss/lib/freebl/pqg.c
> -+++ nss-3.37.1/nss/lib/freebl/pqg.c
> -@@ -326,8 +326,8 @@ generate_h_candidate(SECItem *hit, mp_in
> -
> - static SECStatus
> - addToSeed(const SECItem *seed,
> --          unsigned long addend,
> --          int seedlen, /* g in 186-1 */
> -+          unsigned long long  addend,
> -+          int                 seedlen, /* g in 186-1 */
> -           SECItem *seedout)
> - {
> -     mp_int s, sum, modulus, tmp;
> diff --git a/meta/recipes-support/nss/nss/signlibs.sh b/meta/recipes-support/nss/nss/signlibs.sh
> deleted file mode 100644
> index a74e499f8c..0000000000
> --- a/meta/recipes-support/nss/nss/signlibs.sh
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -#!/bin/sh
> -
> -# signlibs.sh
> -#
> -# (c)2010 Wind River Systems, Inc.
> -#
> -# regenerates the .chk files for the NSS libraries that require it
> -# since the ones that are built have incorrect checksums that were
> -# calculated on the host where they really need to be done on the
> -# target
> -
> -CHK_FILES=`ls /lib*/*.chk /usr/lib*/*.chk 2>/dev/null`
> -SIGN_BINARY=`which shlibsign`
> -for I in $CHK_FILES
> -do
> -       DN=`dirname $I`
> -       BN=`basename $I .chk`
> -       FN=$DN/$BN.so
> -       $SIGN_BINARY -i $FN
> -done
> diff --git a/meta/recipes-support/nss/nss/system-pkcs11.txt b/meta/recipes-support/nss/nss/system-pkcs11.txt
> deleted file mode 100644
> index 1a264e9cc4..0000000000
> --- a/meta/recipes-support/nss/nss/system-pkcs11.txt
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -library=
> -name=NSS Internal PKCS #11 Module
> -parameters=configdir='sql:/etc/pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags= updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription=''
> -NSS=Flags=internal,critical trustOrder=75 cipherOrder=100 slotParams=(1={slotFlags=[ECC,RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512] askpw=any timeout=30})
> -
> diff --git a/meta/recipes-support/nss/nss_3.50.bb b/meta/recipes-support/nss/nss_3.50.bb
> deleted file mode 100644
> index e9855d7a7e..0000000000
> --- a/meta/recipes-support/nss/nss_3.50.bb
> +++ /dev/null
> @@ -1,273 +0,0 @@
> -SUMMARY = "Mozilla's SSL and TLS implementation"
> -DESCRIPTION = "Network Security Services (NSS) is a set of libraries \
> -designed to support cross-platform development of \
> -security-enabled client and server applications. \
> -Applications built with NSS can support SSL v2 and v3, \
> -TLS, PKCS 5, PKCS 7, PKCS 11, PKCS 12, S/MIME, X.509 \
> -v3 certificates, and other security standards."
> -HOMEPAGE = "http://www.mozilla.org/projects/security/pki/nss/"
> -SECTION = "libs"
> -
> -DEPENDS = "sqlite3 nspr zlib nss-native"
> -DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
> -
> -LICENSE = "MPL-2.0 | (MPL-2.0 & GPL-2.0+) | (MPL-2.0 & LGPL-2.1+)"
> -
> -LIC_FILES_CHKSUM = "file://nss/COPYING;md5=3b1e88e1b9c0b5a4b2881d46cce06a18 \
> -                    file://nss/lib/freebl/mpi/doc/LICENSE;md5=491f158d09d948466afce85d6f1fe18f \
> -                    file://nss/lib/freebl/mpi/doc/LICENSE-MPL;md5=5d425c8f3157dbf212db2ec53d9e5132"
> -
> -VERSION_DIR = "${@d.getVar('BP').upper().replace('-', '_').replace('.', '_') + '_RTM'}"
> -
> -SRC_URI = "http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/${VERSION_DIR}/src/${BP}.tar.gz \
> -           file://nss.pc.in \
> -           file://signlibs.sh \
> -           file://0001-nss-fix-support-cross-compiling.patch \
> -           file://nss-no-rpath-for-cross-compiling.patch \
> -           file://nss-fix-incorrect-shebang-of-perl.patch \
> -           file://disable-Wvarargs-with-clang.patch \
> -           file://pqg.c-ULL_addend.patch \
> -           file://blank-cert9.db \
> -           file://blank-key4.db \
> -           file://system-pkcs11.txt \
> -           file://nss-fix-nsinstall-build.patch \
> -           file://0001-freebl-add-a-configure-option-to-disable-ARM-HW-cryp.patch \
> -           "
> -
> -SRC_URI[md5sum] = "e0366615e12b147cebc136c915baea37"
> -SRC_URI[sha256sum] = "185df319775243f5f5daa9d49b7f9cc5f2b389435be3247c3376579bee063ba7"
> -
> -UPSTREAM_CHECK_URI = "https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases"
> -UPSTREAM_CHECK_REGEX = "NSS_(?P<pver>.+)_release_notes"
> -
> -inherit siteinfo
> -
> -TD = "${S}/tentative-dist"
> -TDS = "${S}/tentative-dist-staging"
> -
> -TARGET_CC_ARCH += "${LDFLAGS}"
> -
> -do_configure_prepend_libc-musl () {
> -    sed -i -e '/-DHAVE_SYS_CDEFS_H/d' ${S}/nss/lib/dbm/config/config.mk
> -}
> -
> -do_compile_prepend_class-native() {
> -    export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}/nspr
> -    export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
> -    export NSS_ENABLE_WERROR=0
> -}
> -
> -do_compile_prepend_class-nativesdk() {
> -    export LDFLAGS=""
> -}
> -
> -do_compile_prepend_class-native() {
> -    # Need to set RPATH so that chrpath will do its job correctly
> -    RPATH="-Wl,-rpath-link,${STAGING_LIBDIR_NATIVE} -Wl,-rpath-link,${STAGING_BASE_LIBDIR_NATIVE} -Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}"
> -}
> -
> -do_compile() {
> -    export NSPR_INCLUDE_DIR=${STAGING_INCDIR}/nspr
> -
> -    export CROSS_COMPILE=1
> -    export NATIVE_CC="${BUILD_CC}"
> -    # Additional defines needed on Centos 7
> -    export NATIVE_FLAGS="${BUILD_CFLAGS} -DLINUX -Dlinux"
> -    export BUILD_OPT=1
> -
> -    export FREEBL_NO_DEPEND=1
> -    export FREEBL_LOWHASH=1
> -
> -    export LIBDIR=${libdir}
> -    export MOZILLA_CLIENT=1
> -    export NS_USE_GCC=1
> -    export NSS_USE_SYSTEM_SQLITE=1
> -    export NSS_ENABLE_ECC=1
> -
> -    ${@bb.utils.contains("TUNE_FEATURES", "crypto", "export NSS_USE_ARM_HW_CRYPTO=1", "", d)}
> -
> -    export OS_RELEASE=3.4
> -    export OS_TARGET=Linux
> -    export OS_ARCH=Linux
> -
> -    if [ "${TARGET_ARCH}" = "powerpc" ]; then
> -        OS_TEST=ppc
> -    elif [ "${TARGET_ARCH}" = "powerpc64" ]; then
> -        OS_TEST=ppc64
> -    elif [ "${TARGET_ARCH}" = "mips" -o "${TARGET_ARCH}" = "mipsel" -o "${TARGET_ARCH}" = "mips64" -o "${TARGET_ARCH}" = "mips64el" ]; then
> -        OS_TEST=mips
> -    elif [ "${TARGET_ARCH}" = "aarch64_be" ]; then
> -        OS_TEST="aarch64"
> -    else
> -        OS_TEST="${TARGET_ARCH}"
> -    fi
> -
> -    if [ "${SITEINFO_BITS}" = "64" ]; then
> -        export USE_64=1
> -    elif [ "${TARGET_ARCH}" = "x86_64" -a "${SITEINFO_BITS}" = "32" ]; then
> -        export USE_X32=1
> -    fi
> -
> -    export NSS_DISABLE_GTESTS=1
> -
> -    # We can modify CC in the environment, but if we set it via an
> -    # argument to make, nsinstall, a host program, will also build with it!
> -    #
> -    # nss pretty much does its own thing with CFLAGS, so we put them into CC.
> -    # Optimization will get clobbered, but most of the stuff will survive.
> -    # The motivation for this is to point to the correct place for debug
> -    # source files and CFLAGS does that.  Nothing uses CCC.
> -    #
> -    export CC="${CC} ${CFLAGS}"
> -    make -C ./nss CCC="${CXX} -g" \
> -        OS_TEST=${OS_TEST} \
> -        RPATH="${RPATH}"
> -}
> -
> -do_compile[vardepsexclude] += "SITEINFO_BITS"
> -
> -do_install_prepend_class-nativesdk() {
> -    export LDFLAGS=""
> -}
> -
> -do_install() {
> -    export CROSS_COMPILE=1
> -    export NATIVE_CC="${BUILD_CC}"
> -    export BUILD_OPT=1
> -
> -    export FREEBL_NO_DEPEND=1
> -
> -    export LIBDIR=${libdir}
> -    export MOZILLA_CLIENT=1
> -    export NS_USE_GCC=1
> -    export NSS_USE_SYSTEM_SQLITE=1
> -    export NSS_ENABLE_ECC=1
> -
> -    export OS_RELEASE=3.4
> -    export OS_TARGET=Linux
> -    export OS_ARCH=Linux
> -
> -    if [ "${TARGET_ARCH}" = "powerpc" ]; then
> -        OS_TEST=ppc
> -    elif [ "${TARGET_ARCH}" = "powerpc64" ]; then
> -        OS_TEST=ppc64
> -    elif [ "${TARGET_ARCH}" = "mips" -o "${TARGET_ARCH}" = "mipsel" -o "${TARGET_ARCH}" = "mips64" -o "${TARGET_ARCH}" = "mips64el" ]; then
> -        OS_TEST=mips
> -    elif [ "${TARGET_ARCH}" = "aarch64_be" ]; then
> -        CPU_ARCH=aarch64
> -        OS_TEST="aarch64"
> -    else
> -        OS_TEST="${TARGET_ARCH}"
> -    fi
> -    if [ "${SITEINFO_BITS}" = "64" ]; then
> -        export USE_64=1
> -    elif [ "${TARGET_ARCH}" = "x86_64" -a "${SITEINFO_BITS}" = "32" ]; then
> -        export USE_X32=1
> -    fi
> -
> -    export NSS_DISABLE_GTESTS=1
> -
> -    make -C ./nss \
> -        CCC="${CXX}" \
> -        OS_TEST=${OS_TEST} \
> -        SOURCE_LIB_DIR="${TD}/${libdir}" \
> -        SOURCE_BIN_DIR="${TD}/${bindir}" \
> -        install
> -
> -    install -d ${D}/${libdir}/
> -    for file in ${S}/dist/*.OBJ/lib/*.so; do
> -        echo "Installing `basename $file`..."
> -        cp $file  ${D}/${libdir}/
> -    done
> -
> -    for shared_lib in ${TD}/${libdir}/*.so.*; do
> -        if [ -f $shared_lib ]; then
> -            cp $shared_lib ${D}/${libdir}
> -            ln -sf $(basename $shared_lib) ${D}/${libdir}/$(basename $shared_lib .1oe)
> -        fi
> -    done
> -    for shared_lib in ${TD}/${libdir}/*.so; do
> -        if [ -f $shared_lib -a ! -e ${D}/${libdir}/$shared_lib ]; then
> -            cp $shared_lib ${D}/${libdir}
> -        fi
> -    done
> -
> -    install -d ${D}/${includedir}/nss3
> -    install -m 644 -t ${D}/${includedir}/nss3 dist/public/nss/*
> -
> -    install -d ${D}/${bindir}
> -    for binary in ${TD}/${bindir}/*; do
> -        install -m 755 -t ${D}/${bindir} $binary
> -    done
> -}
> -
> -do_install[vardepsexclude] += "SITEINFO_BITS"
> -
> -do_install_append() {
> -    # Create empty .chk files for the NSS libraries at build time. They could
> -    # be regenerated at target's boot time.
> -    for file in libsoftokn3.chk libfreebl3.chk libnssdbm3.chk; do
> -        touch ${D}/${libdir}/$file
> -        chmod 755 ${D}/${libdir}/$file
> -    done
> -    install -D -m 755 ${WORKDIR}/signlibs.sh ${D}/${bindir}/signlibs.sh
> -
> -    install -d ${D}${libdir}/pkgconfig/
> -    sed 's/%NSS_VERSION%/${PV}/' ${WORKDIR}/nss.pc.in | sed 's/%NSPR_VERSION%/4.9.2/' > ${D}${libdir}/pkgconfig/nss.pc
> -    sed -i s:OEPREFIX:${prefix}:g ${D}${libdir}/pkgconfig/nss.pc
> -    sed -i s:OEEXECPREFIX:${exec_prefix}:g ${D}${libdir}/pkgconfig/nss.pc
> -    sed -i s:OELIBDIR:${libdir}:g ${D}${libdir}/pkgconfig/nss.pc
> -    sed -i s:OEINCDIR:${includedir}/nss3:g ${D}${libdir}/pkgconfig/nss.pc
> -}
> -
> -do_install_append_class-target() {
> -    # It used to call certutil to create a blank certificate with empty password at
> -    # build time, but the checksum of key4.db changes every time when certutil is called.
> -    # It causes non-determinism issue, so provide databases with a blank certificate
> -    # which are originally from output of nss in qemux86-64 build. You can get these
> -    # databases by:
> -    # certutil -N -d sql:/database/path/ --empty-password
> -    install -d ${D}${sysconfdir}/pki/nssdb/
> -    install -m 0644 ${WORKDIR}/blank-cert9.db ${D}${sysconfdir}/pki/nssdb/cert9.db
> -    install -m 0644 ${WORKDIR}/blank-key4.db ${D}${sysconfdir}/pki/nssdb/key4.db
> -    install -m 0644 ${WORKDIR}/system-pkcs11.txt ${D}${sysconfdir}/pki/nssdb/pkcs11.txt
> -}
> -
> -PACKAGE_WRITE_DEPS += "nss-native"
> -pkg_postinst_${PN} () {
> -    if [ -n "$D" ]; then
> -        for I in $D${libdir}/lib*.chk; do
> -            DN=`dirname $I`
> -            BN=`basename $I .chk`
> -            FN=$DN/$BN.so
> -            shlibsign -i $FN
> -            if [ $? -ne 0 ]; then
> -                exit 1
> -            fi
> -        done
> -    else
> -        signlibs.sh
> -    fi
> -}
> -
> -PACKAGES =+ "${PN}-smime"
> -FILES_${PN}-smime = "\
> -    ${bindir}/smime \
> -"
> -
> -FILES_${PN} = "\
> -    ${sysconfdir} \
> -    ${bindir} \
> -    ${libdir}/lib*.chk \
> -    ${libdir}/lib*.so \
> -    "
> -
> -FILES_${PN}-dev = "\
> -    ${libdir}/nss \
> -    ${libdir}/pkgconfig/* \
> -    ${includedir}/* \
> -    "
> -
> -RDEPENDS_${PN}-smime = "perl"
> -
> -BBCLASSEXTEND = "native nativesdk"
> --
> 2.17.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-02-24  0:25 ` [RFC][PATCH 1/2] nss: " Khem Raj
@ 2020-02-24  5:17   ` Adrian Bunk
  2020-02-24 16:32     ` akuster808
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-02-24  5:17 UTC (permalink / raw)
  To: Khem Raj; +Cc: Patches and discussions about the oe-core layer

On Sun, Feb 23, 2020 at 04:25:18PM -0800, Khem Raj wrote:
> On Sun, Feb 23, 2020 at 11:34 AM Adrian Bunk <bunk@stusta.de> wrote:
> >
> > rpm was the last user in OE-core.
> 
> we should also assess external dependencies especially on libraries,
> there might be layers which do not depend on meta-oe but use nss
> or enable nss packageconfigs in core components like curl.
>...

Is providing a crypto library in OE-core without providing security 
support better than not shipping it?

nss in warrior seems to lack fixes for at least 5 CVEs.

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-02-24  5:17   ` Adrian Bunk
@ 2020-02-24 16:32     ` akuster808
  2020-02-27 13:27       ` Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: akuster808 @ 2020-02-24 16:32 UTC (permalink / raw)
  To: Adrian Bunk, Khem Raj; +Cc: Patches and discussions about the oe-core layer

Adrian,

On 2/23/20 9:17 PM, Adrian Bunk wrote:
> On Sun, Feb 23, 2020 at 04:25:18PM -0800, Khem Raj wrote:
>> On Sun, Feb 23, 2020 at 11:34 AM Adrian Bunk <bunk@stusta.de> wrote:
>>> rpm was the last user in OE-core.
>> we should also assess external dependencies especially on libraries,
>> there might be layers which do not depend on meta-oe but use nss
>> or enable nss packageconfigs in core components like curl.
>> ...
> Is providing a crypto library in OE-core without providing security 
> support better than not shipping it?
>
> nss in warrior seems to lack fixes for at least 5 CVEs.

I don't see how that is relevant to the RFC?

nss package is not moving out for warrior nor zeus.


- armin
>
> cu
> Adrian



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-02-24 16:32     ` akuster808
@ 2020-02-27 13:27       ` Adrian Bunk
  2020-02-27 14:03         ` Alexander Kanavin
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-02-27 13:27 UTC (permalink / raw)
  To: akuster808; +Cc: Patches and discussions about the oe-core layer

On Mon, Feb 24, 2020 at 08:32:24AM -0800, akuster808 wrote:
>...
> On 2/23/20 9:17 PM, Adrian Bunk wrote:
> > On Sun, Feb 23, 2020 at 04:25:18PM -0800, Khem Raj wrote:
> >> On Sun, Feb 23, 2020 at 11:34 AM Adrian Bunk <bunk@stusta.de> wrote:
> >>> rpm was the last user in OE-core.
> >> we should also assess external dependencies especially on libraries,
> >> there might be layers which do not depend on meta-oe but use nss
> >> or enable nss packageconfigs in core components like curl.
> >> ...
> > Is providing a crypto library in OE-core without providing security 
> > support better than not shipping it?
> >
> > nss in warrior seems to lack fixes for at least 5 CVEs.
> 
> I don't see how that is relevant to the RFC?
>...

It is a crypto library with a history of unfixed CVEs in supported 
stable Yocto releases.

> - armin

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-02-27 13:27       ` Adrian Bunk
@ 2020-02-27 14:03         ` Alexander Kanavin
  2020-03-04  9:05           ` Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: Alexander Kanavin @ 2020-02-27 14:03 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Thu, 27 Feb 2020 at 14:28, Adrian Bunk <bunk@stusta.de> wrote:

> >...
>
> It is a crypto library with a history of unfixed CVEs in supported
> stable Yocto releases.
>

If the issue is unfixed CVEs, then I do not think it's particularly
relevant which layer the recipe is in. Stable release maintainers are not
expected to 'track and fix CVEs', that one is on users.

Alex

[-- Attachment #2: Type: text/html, Size: 707 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-02-27 14:03         ` Alexander Kanavin
@ 2020-03-04  9:05           ` Adrian Bunk
  2020-03-04  9:36             ` Alexander Kanavin
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-03-04  9:05 UTC (permalink / raw)
  To: Alexander Kanavin; +Cc: Patches and discussions about the oe-core layer

On Thu, Feb 27, 2020 at 03:03:18PM +0100, Alexander Kanavin wrote:
> On Thu, 27 Feb 2020 at 14:28, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > >...
> >
> > It is a crypto library with a history of unfixed CVEs in supported
> > stable Yocto releases.
> >
> 
> If the issue is unfixed CVEs, then I do not think it's particularly
> relevant which layer the recipe is in. Stable release maintainers are not
> expected to 'track and fix CVEs', that one is on users.

Yesterdays LTS announcement makes it clear that the Yocto project does 
provide regular security updates for supported stable branches:

<--  snip  -->

Yocto Project releases are usually maintained for one year.
Beyond this period, releases move to community support, which means
they only receive occasional patches for critical defects and updates,
and no regular defect fixes and security updates.

<--  snip  -->


> Alex

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-03-04  9:05           ` Adrian Bunk
@ 2020-03-04  9:36             ` Alexander Kanavin
  2020-03-04 11:32               ` Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: Alexander Kanavin @ 2020-03-04  9:36 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

You are misinterpreting the announcement. The security updates are provided
by users as patches to the mailing list, maintainers merely collect and
integrate them. There is no promise from the project to do anything else,
and LTS doesn’t change that, it only extends the maintainer duty from one
year to two. Moving a recipe in or out of core does not fundamentally
change how much attention it gets w.r.t. security fixes.

Alex

On Wed 4. Mar 2020 at 10.05, Adrian Bunk <bunk@stusta.de> wrote:

> On Thu, Feb 27, 2020 at 03:03:18PM +0100, Alexander Kanavin wrote:
> > On Thu, 27 Feb 2020 at 14:28, Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > >...
> > >
> > > It is a crypto library with a history of unfixed CVEs in supported
> > > stable Yocto releases.
> > >
> >
> > If the issue is unfixed CVEs, then I do not think it's particularly
> > relevant which layer the recipe is in. Stable release maintainers are not
> > expected to 'track and fix CVEs', that one is on users.
>
> Yesterdays LTS announcement makes it clear that the Yocto project does
> provide regular security updates for supported stable branches:
>
> <--  snip  -->
>
> Yocto Project releases are usually maintained for one year.
> Beyond this period, releases move to community support, which means
> they only receive occasional patches for critical defects and updates,
> and no regular defect fixes and security updates.
>
> <--  snip  -->
>
>
> > Alex
>
> cu
> Adrian
>

[-- Attachment #2: Type: text/html, Size: 2013 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-03-04  9:36             ` Alexander Kanavin
@ 2020-03-04 11:32               ` Adrian Bunk
  2020-03-04 12:13                 ` Alexander Kanavin
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-03-04 11:32 UTC (permalink / raw)
  To: Alexander Kanavin; +Cc: Patches and discussions about the oe-core layer

On Wed, Mar 04, 2020 at 10:36:52AM +0100, Alexander Kanavin wrote:
> You are misinterpreting the announcement. The security updates are provided
> by users as patches to the mailing list, maintainers merely collect and
> integrate them. There is no promise from the project to do anything else,
> and LTS doesn’t change that, it only extends the maintainer duty from one
> year to two. Moving a recipe in or out of core does not fundamentally
> change how much attention it gets w.r.t. security fixes.

The part in question does not even talk about LTS, it describes the 
status quo for the current stable releases with one year support.

>...
> > <--  snip  -->
> >
> > Yocto Project releases are usually maintained for one year.
> > Beyond this period, releases move to community support, which means
> > they only receive occasional patches for critical defects and updates,
> > and no regular defect fixes and security updates.
> >
> > <--  snip  -->
>...

This announcement states pretty clearly that security updates are
provided for stable branches, but not for community supported branches.

I am sure there will be an update to the announcement if this doesn't
reflect current reality.

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC][PATCH 1/2] nss: Move to meta-oe
  2020-03-04 11:32               ` Adrian Bunk
@ 2020-03-04 12:13                 ` Alexander Kanavin
  2020-03-04 14:01                   ` Does YP provide security support for stable and LTS branches? Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: Alexander Kanavin @ 2020-03-04 12:13 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Wed, 4 Mar 2020 at 12:32, Adrian Bunk <bunk@stusta.de> wrote:

> I am sure there will be an update to the announcement if this doesn't
> reflect current reality.
>

Who is expected to do the actual work of tracking CVEs, making action
points and performing the actions? The current reality is this: the
security update work is done ad hoc by community, even for stable branches.
There is no rigorous security process like in Debian, and no roles to
follow in that process. This means that if no one bothers to make a patch,
the security issue will remain unfixed, and this does happen often. If you
are expecting anything else (e.g. that listed recipe maintainers should do
something), you're setting yourself up to be disappointed.

Alex

[-- Attachment #2: Type: text/html, Size: 1149 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Does YP provide security support for stable and LTS branches?
  2020-03-04 12:13                 ` Alexander Kanavin
@ 2020-03-04 14:01                   ` Adrian Bunk
  2020-03-04 16:00                     ` Alexander Kanavin
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-03-04 14:01 UTC (permalink / raw)
  To: Alexander Kanavin
  Cc: openembedded-architecture,
	Patches and discussions about the oe-core layer

On Wed, Mar 04, 2020 at 01:13:19PM +0100, Alexander Kanavin wrote:
> On Wed, 4 Mar 2020 at 12:32, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > I am sure there will be an update to the announcement if this doesn't
> > reflect current reality.
> 
> Who is expected to do the actual work of tracking CVEs, making action
> points and performing the actions? The current reality is this: the
> security update work is done ad hoc by community, even for stable branches.
> There is no rigorous security process like in Debian, and no roles to
> follow in that process. This means that if no one bothers to make a patch,
> the security issue will remain unfixed, and this does happen often. If you
> are expecting anything else (e.g. that listed recipe maintainers should do
> something), you're setting yourself up to be disappointed.

All I am expecting is honesty.

If YP does not provide security support for supported stable branches, 
then public statements that community support would be worse than stable 
branches due to lack of security support are dishonest and offensive.

It also puts all users of Yocto stable and LTS releases and billions of 
devices at danger if the Yocto project announces security support but 
does not deliver.

The normal user expects that that the announced "usual defect fixes and 
updates for the extended period of two years" in LTS include the regular 
security updates that were claimed for stable branches earlier in the 
same announcement.

For cases where I am the user the only benefit of going through the pain 
of upgrading existing products from older releases to Yocto 3.1 would be 
2 years of security support from upstream. Doing the upgrade and only 
discovering afterwards that it doesn't bring the benefit that was 
promised would make me <unprintable>.

Let me repeat that the only thing I am expecting is honesty,
and all I am asking for is that if YP does not provide security
support for stable and LTS branches this should be communicated
clearly so that all users are aware.

> Alex

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Does YP provide security support for stable and LTS branches?
  2020-03-04 14:01                   ` Does YP provide security support for stable and LTS branches? Adrian Bunk
@ 2020-03-04 16:00                     ` Alexander Kanavin
  2020-03-04 17:24                       ` Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: Alexander Kanavin @ 2020-03-04 16:00 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: openembedded-architecture,
	Patches and discussions about the oe-core layer

[-- Attachment #1: Type: text/plain, Size: 2908 bytes --]

Taking offense or getting angry at the yocto project is entirely
misdirected. The liability for insecure millions of devices does not lie
with the yocto project, it lies with the OEMs. If the OEMs are unwilling to
allocate manpower to work on security, there’s very little the yocto
project can do. We are already struggling to find people to work on actual
bugs, and there’s simply no manpower to do security properly. Still, stable
releases *are* much better than community supported ones, they do get a lot
of CVEs and bugs fixed, all I wanted to say is that the exhaustive process
to fix everything that could be insecure is not there.

Alex

On Wed 4. Mar 2020 at 15.01, Adrian Bunk <bunk@stusta.de> wrote:

> On Wed, Mar 04, 2020 at 01:13:19PM +0100, Alexander Kanavin wrote:
> > On Wed, 4 Mar 2020 at 12:32, Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > I am sure there will be an update to the announcement if this doesn't
> > > reflect current reality.
> >
> > Who is expected to do the actual work of tracking CVEs, making action
> > points and performing the actions? The current reality is this: the
> > security update work is done ad hoc by community, even for stable
> branches.
> > There is no rigorous security process like in Debian, and no roles to
> > follow in that process. This means that if no one bothers to make a
> patch,
> > the security issue will remain unfixed, and this does happen often. If
> you
> > are expecting anything else (e.g. that listed recipe maintainers should
> do
> > something), you're setting yourself up to be disappointed.
>
> All I am expecting is honesty.
>
> If YP does not provide security support for supported stable branches,
> then public statements that community support would be worse than stable
> branches due to lack of security support are dishonest and offensive.
>
> It also puts all users of Yocto stable and LTS releases and billions of
> devices at danger if the Yocto project announces security support but
> does not deliver.
>
> The normal user expects that that the announced "usual defect fixes and
> updates for the extended period of two years" in LTS include the regular
> security updates that were claimed for stable branches earlier in the
> same announcement.
>
> For cases where I am the user the only benefit of going through the pain
> of upgrading existing products from older releases to Yocto 3.1 would be
> 2 years of security support from upstream. Doing the upgrade and only
> discovering afterwards that it doesn't bring the benefit that was
> promised would make me <unprintable>.
>
> Let me repeat that the only thing I am expecting is honesty,
> and all I am asking for is that if YP does not provide security
> support for stable and LTS branches this should be communicated
> clearly so that all users are aware.
>
> > Alex
>
> cu
> Adrian
>

[-- Attachment #2: Type: text/html, Size: 3477 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Does YP provide security support for stable and LTS branches?
  2020-03-04 16:00                     ` Alexander Kanavin
@ 2020-03-04 17:24                       ` Adrian Bunk
  2020-03-04 20:26                         ` [Openembedded-architecture] " akuster808
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-03-04 17:24 UTC (permalink / raw)
  To: Alexander Kanavin
  Cc: openembedded-architecture,
	Patches and discussions about the oe-core layer

On Wed, Mar 04, 2020 at 05:00:44PM +0100, Alexander Kanavin wrote:
> Taking offense or getting angry at the yocto project is entirely
> misdirected.

I am not angry if YP does not provide security support.

I am angry when YP is telling lies that it would provide security 
support, but does not actually provide it.

> The liability for insecure millions of devices does not lie
> with the yocto project, it lies with the OEMs.
>...

The liability for insecure millions of devices lies 100% with the Yocto 
Project if it claims to provide security support but does not actually 
provide it.

If a user has to decide today whether an upcoming product will run
Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the
user whether or not choosing Yocto will provide upstream security 
support the same way as Ubuntu.

A user reading the YP LTS announcement expects security support similar 
to what Ubuntu is offering, and might only notice that this isn't true 
after a known vulnerability gets exploited on millions of devices.

If security support for YP stable and LTS releases is only on a
community support basis and usually incomplete, then it is on YP
to make that clear to all users instead of claiming the opposite - in 
other projects LTS does include security support, sometimes only 
security fixes are permitted.

This could be combined with a call for help for security support,
an advantage of being honest would be that it becomes visible for
users that there is a resource shortage.

> Alex

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-04 17:24                       ` Adrian Bunk
@ 2020-03-04 20:26                         ` akuster808
  2020-03-06 10:04                           ` Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: akuster808 @ 2020-03-04 20:26 UTC (permalink / raw)
  To: Adrian Bunk, Alexander Kanavin
  Cc: openembedded-architecture,
	Patches and discussions about the oe-core layer

Adrian,


On 3/4/20 9:24 AM, Adrian Bunk wrote:
> On Wed, Mar 04, 2020 at 05:00:44PM +0100, Alexander Kanavin wrote:
>> Taking offense or getting angry at the yocto project is entirely
>> misdirected.
> I am not angry if YP does not provide security support.
>
> I am angry when YP is telling lies that it would provide security 
> support, but does not actually provide it.

 I am sure its not the intent of the Yocto Project to miss lead folks.

>
>> The liability for insecure millions of devices does not lie
>> with the yocto project, it lies with the OEMs.
>> ...
> The liability for insecure millions of devices lies 100% with the Yocto 
> Project if it claims to provide security support but does not actually 
> provide it.
>
> If a user has to decide today whether an upcoming product will run
> Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the
> user whether or not choosing Yocto will provide upstream security 
> support the same way as Ubuntu.
>
> A user reading the YP LTS announcement expects security support similar 
> to what Ubuntu is offering, and might only notice that this isn't true 
> after a known vulnerability gets exploited on millions of devices.
I didn't get that out of the announcement. It only reference in the LTS
announcement  regarding Security was in context to Community support.

The new new LTS / Stable process wiki does not claim such claims either.

https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS

>
> If security support for YP stable and LTS releases is only on a
> community support basis and usually incomplete, then it is on YP
> to make that clear to all users instead of claiming the opposite - in 
> other projects LTS does include security support, sometimes only 
> security fixes are permitted.

Can point out where those statements are made? Again, I am sure the
Yocto Project would like to know.

>
> This could be combined with a call for help for security support,
> an advantage of being honest would be that it becomes visible for
> users that there is a resource shortage.
There are weekly status reports  and minutes from various meeting that
include the attendees list.  The attendees list has not grown. The build
swat team was shut down as no one stepped up to help. That was an
opportunity for the community to step up.

There is request for help regarding defects sent out every week and if
it wasn't for WindRiver, Intel, Joshua Watt and Richard the open defects
would go uncheck.

So the resource issue has been floating around on the various mailing
lists for some time. What do you think needs to be done to make it even
more visible?

regards,
armin
>
>> Alex
> cu
> Adrian
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture




^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-04 20:26                         ` [Openembedded-architecture] " akuster808
@ 2020-03-06 10:04                           ` Adrian Bunk
  2020-03-06 10:36                             ` Richard Purdie
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-03-06 10:04 UTC (permalink / raw)
  To: akuster808
  Cc: openembedded-architecture,
	Patches and discussions about the oe-core layer

On Wed, Mar 04, 2020 at 12:26:29PM -0800, akuster808 wrote:
...
> On 3/4/20 9:24 AM, Adrian Bunk wrote:
...
> > This could be combined with a call for help for security support,
> > an advantage of being honest would be that it becomes visible for
> > users that there is a resource shortage.
> There are weekly status reports  and minutes from various meeting that
> include the attendees list.  The attendees list has not grown. The build
> swat team was shut down as no one stepped up to help. That was an
> opportunity for the community to step up.

Yocto is setup as a B2B project providing a basis for embedded products,
your "community" are mainly companies.

The "build everything yourself" niche for non-embedded is already
occupied by Gentoo.

For most community companies there is no clear Return on Investment
if they would use the opportunity to invest in upstream involvement.

> There is request for help regarding defects sent out every week and if
> it wasn't for WindRiver, Intel, Joshua Watt and Richard the open defects
> would go uncheck.
>
> So the resource issue has been floating around on the various mailing
> lists for some time. What do you think needs to be done to make it even
> more visible?
>...

You are confusing developers with users.

Developers are following development discussions.

Users who are being paid for building a product based on Yocto
read the user information at https://www.yoctoproject.org/
especially the great manuals written by Scott.

Development discussions are mostly irrelevant for users.

To make a non-Yocto example:
I am using Ubuntu LTS on my laptop.
The security support provided by Canonical is essential for me,
and as part of the community I am using their bugtracker in rare
cases where I have problems.
I have neither time nor interest in following upstream discussions
regarding development of future Ubuntu releases.

>...
> >> The liability for insecure millions of devices does not lie
> >> with the yocto project, it lies with the OEMs.
> >> ...
> > The liability for insecure millions of devices lies 100% with the Yocto 
> > Project if it claims to provide security support but does not actually 
> > provide it.
> >
> > If a user has to decide today whether an upcoming product will run
> > Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the
> > user whether or not choosing Yocto will provide upstream security 
> > support the same way as Ubuntu.
> >
> > A user reading the YP LTS announcement expects security support similar 
> > to what Ubuntu is offering, and might only notice that this isn't true 
> > after a known vulnerability gets exploited on millions of devices.
> I didn't get that out of the announcement. It only reference in the LTS
> announcement  regarding Security was in context to Community support.
>...

The wording is "releases move to community support, which means they 
only receive occasional patches for critical defects and updates,
and no regular defect fixes and security updates".

When the move to community support means no regular security updates,
this is a clear claim from YP that before the move there are regular
security updates.

YP then claims for LTS that "These components will now receive the usual 
defect fixes and updates for the extended period of two years."

When YP states "A very important criterion for evaluating and adopting
a software platform is support." the one kind of support that really 
matters for users of long term support releases is security support.
This is the baseline users expect from anything called LTS,
and the main reason why users want to use LTS releases.

If YP does not want to be responsible for insecure millions of devices,
it is up to YP to not make incorrect claims and make it clear in
announcements and user documentation if security support is not
provided by YP.

This allows users to mitigate by allocating resources for security
support of their products, instead of unknowingly shipping millions
of insecure devices.

It would also allow YP to develop offers for community companies to pool 
smaller contributions together - 50 companies each paying 2k per year 
for pooled security support is cheaper for them than each of them 
locally providing the same security support.

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-06 10:04                           ` Adrian Bunk
@ 2020-03-06 10:36                             ` Richard Purdie
  2020-03-08 21:46                               ` Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: Richard Purdie @ 2020-03-06 10:36 UTC (permalink / raw)
  To: Adrian Bunk, akuster808
  Cc: openembedded-architecture,
	Patches and discussions about the oe-core layer

On Fri, 2020-03-06 at 12:04 +0200, Adrian Bunk wrote:
> For most community companies there is no clear Return on Investment
> if they would use the opportunity to invest in upstream involvement.

That isn't true. If you fix something yourself and hold the change you
get to maintain it. If you work with upstream you can share the
maintenance burden with the community going forward. That is a direct
ROI, there are also more indirect benefits.

> > > > The liability for insecure millions of devices does not lie
> > > > with the yocto project, it lies with the OEMs.
> > > > ...
> > > The liability for insecure millions of devices lies 100% with the
> > > Yocto 
> > > Project if it claims to provide security support but does not
> > > actually 
> > > provide it.
> > > 
> > > If a user has to decide today whether an upcoming product will
> > > run
> > > Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the
> > > user whether or not choosing Yocto will provide upstream
> > > security 
> > > support the same way as Ubuntu.
> > > 
> > > A user reading the YP LTS announcement expects security support
> > > similar 
> > > to what Ubuntu is offering, and might only notice that this isn't
> > > true 
> > > after a known vulnerability gets exploited on millions of
> > > devices.
> > I didn't get that out of the announcement. It only reference in the
> > LTS
> > announcement  regarding Security was in context to Community
> > support.
> > ...
> 
> The wording is "releases move to community support, which means they 
> only receive occasional patches for critical defects and updates,
> and no regular defect fixes and security updates".
> 
> When the move to community support means no regular security updates,
> this is a clear claim from YP that before the move there are regular
> security updates.

I think you're being rather pedantic here and I'd suggest we go back to
what the essence of this announcement is.

Today, our stable branch maintenance is done "ad-hoc" by volunteers.
I/we can't ask them to do anything in any given time frame, its a best
effort. I *hugely* appreciate what those people do but it has its
limitations.

Even with the non-stable side of the project, the patch
review/testing/merging and debugging which patch causes which
regression basically falls onto one person, me. Yes, people help, its
hugely appreciated when they do but I'm the only person paid to do it
(amongst many other things) and I therefore know first hand how much
work this is.

We want to extend the lifespan of some releases. We can't ask/force our
volunteers to do that, its not reasonable. The project is therefore
looking to try something different where we have someone with time
dedicated to this.

There are certainly limitations to what will likely be one part time
person can do, however we are hoping it improves on what we have today
and may even set a mechanism by which the project can better operate
for key functionality in future.

We're putting this into the context of the maintainer who coordinates
things, not someone to write the individual security fixes as that is
the only realistic way we can make this work. If people share their
security patches they'll have a lot of work, if nobody shares such
fixes, it will be minimal. Time will tell if people can/will share. I
do think it makes sense to try.

> YP then claims for LTS that "These components will now receive the
> usual defect fixes and updates for the extended period of two years."

So the current process is extended for a longer period. That seems
quite clear.

> When YP states "A very important criterion for evaluating and
> adopting a software platform is support." the one kind of support
> that really  matters for users of long term support releases is
> security support. This is the baseline users expect from anything
> called LTS, and the main reason why users want to use LTS releases.

And we are trying to put something in place which better supports
review and merging of patches into that LTS. That is a form of security
support. We can't afford a team of 20 to work on it but it is an
improvement from our current volunteer best efforts?

We're also not competing with member company offerings. If you want a
full set of security guarantees, please use a company which offers that
service, several project members will be happy to help (and charge
accordingly).

> If YP does not want to be responsible for insecure millions of
> devices, it is up to YP to not make incorrect claims and make it
> clear in announcements and user documentation if security support is
> not provided by YP.

I think the definition of "security support" is arguable to be
different things but the intent of what we're trying to do here is
clear. No, the person will not write the patches, the intent is to
coordinate the maintenance of the branch. If there are huge security
holes I would at least expect they can highlight the issues and then
coordinate any help in fixing them. That in itself is a level of
security support btw.

> This allows users to mitigate by allocating resources for security
> support of their products, instead of unknowingly shipping millions
> of insecure devices.
> 
> It would also allow YP to develop offers for community companies to
> pool smaller contributions together - 50 companies each paying 2k per
> year for pooled security support is cheaper for them than each of
> them locally providing the same security support.

This is what we're effectively trying to do. The level of "security
support" you can do with $100k/year is a maintainer/coordinator of the
stable branch. Even writing a spec for that is hard, if you have one
we'd love a copy btw.

Taking a step back, please realise that we are trying to improve what
we can offer within the realms of what is practical. We can improve the
maintenance function, we're not going to be able to write every
security fix or provide guarantees.

Its incredibly hard to find funding to try and then organise what we're
trying to do, it would be nice if you could try and help us support in
doing so.

If we need to clarify how this is documented/presented, we should do
so. Accusing people of misleading/lying/false information isn't
helpful, or in fact accurate.

Cheers,

Richard



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-06 10:36                             ` Richard Purdie
@ 2020-03-08 21:46                               ` Adrian Bunk
  2020-03-08 22:08                                 ` Alexander Kanavin
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-03-08 21:46 UTC (permalink / raw)
  To: Richard Purdie
  Cc: openembedded-architecture,
	Patches and discussions about the oe-core layer

On Fri, Mar 06, 2020 at 10:36:59AM +0000, Richard Purdie wrote:
> On Fri, 2020-03-06 at 12:04 +0200, Adrian Bunk wrote:
> > For most community companies there is no clear Return on Investment
> > if they would use the opportunity to invest in upstream involvement.
> 
> That isn't true. If you fix something yourself and hold the change you
> get to maintain it. If you work with upstream you can share the
> maintenance burden with the community going forward. That is a direct
> ROI, there are also more indirect benefits.

I was responding to Armin talking about the build swat team.
It is hard to see the ROI for a community company when participating
in something like that.

Upstreaming of own local changes is a different story.

>...
> Today, our stable branch maintenance is done "ad-hoc" by volunteers.
> I/we can't ask them to do anything in any given time frame, its a best
> effort. I *hugely* appreciate what those people do but it has its
> limitations.

On developer lists the message is always "we are short on resources,
please help". Which reaches the few people already involved in 
development.

The message to users is that everything is fine and what new things
Yocto is additionally offering.

No regular user of Wikipedia would miss the regular fundraising where 
the project needs/wants money.

>...
> > The wording is "releases move to community support, which means they 
> > only receive occasional patches for critical defects and updates,
> > and no regular defect fixes and security updates".
> > 
> > When the move to community support means no regular security updates,
> > this is a clear claim from YP that before the move there are regular
> > security updates.
> 
> I think you're being rather pedantic here and I'd suggest we go back to
> what the essence of this announcement is.

The essence for me is that a few days after I am told on the developer 
list that 'track and fix CVEs' for stable releases is on users, YP makes 
an announcement that is worded to make users believe the opposite.

I am getting attacks like being accused of making "toxic accusations" 
for stating the fact that millions of devices being put at risk by
YP misrepresenting the status of security support to users who are
building products based on Yocto.

It is on YP to make it clear to users whether or not Yocto comes with
the same set of security guarantees as distributions like Ubuntu or Debian. 
If it is the duty of every user of Yocto to track and fix CVEs,
then this has to be stated clearly instead of implying the opposite.
This gives users the opportunity to mitigate, instead of unknowingly
shipping insecure products.

E.g. embedded products based on Ubuntu with its security support from 
Linux Foundation member Canonical are clearly better than embedded 
products based on any distribution without similar security support.

And while you are downloading an Ubuntu image from their website you are 
on a "Contribute with PayPal" page.

>...
> > If YP does not want to be responsible for insecure millions of
> > devices, it is up to YP to not make incorrect claims and make it
> > clear in announcements and user documentation if security support is
> > not provided by YP.
> 
> I think the definition of "security support" is arguable to be
> different things but the intent of what we're trying to do here is
> clear. No, the person will not write the patches, the intent is to
> coordinate the maintenance of the branch. If there are huge security
> holes I would at least expect they can highlight the issues and then
> coordinate any help in fixing them. That in itself is a level of
> security support btw.

This is a bit of a strawman, the problem is elsewhere.

Vulnerabilities are rarely OE/Yocto-specific, in practice security
support means applying the same patches that other distributions
are also applying.

When a security advisory will be published for Ubuntu 20.04 LTS
there will be a patch available for usually approximately the
same version of this software as is in Yocto 3.1 LTS.

Going back to where this discussion started:

If YP gives the impression that stable and LTS series are security
supported by YP, then it is a problem when a crypto library like
nss is not getting any security fixes in Yocto 2.7.

Debian stable ships the same upstream version and applied fixes for 5 
CVEs last year. In practice security support means integrating these 
existing patches. And providing security support means that there is
a person resposible for integrating such existing patches from elsewhere.

>...
> Its incredibly hard to find funding to try and then organise what we're
> trying to do, it would be nice if you could try and help us support in
> doing so.
>...

Do you have constructive suggestions how people can help with funding 
who do not have access to money sources that could contribute 6 digit 
amounts to upstream Yocto?

Any support I could provide or might be able to organize would be
4 digits per year, and I am not aware of any existing way to pool
such contributions easily for paying people for upstream YP work.

The best I could offer would be that I open a company that sends 
invoices for small contributions and pays people from that money.
Which sounds like a clear non-starter for financing YP stable/LTS branch 
maintainance - this would likely have to be organized through the LF.

I might have use for continued warrior maintainance and might volunteer
as community maintainer for that after the 12 months, but this doesn't 
generate funding for YP.

It is really hard to help you find funding when you are offering 
opportunities to fund YP only for big companies with huge budgets,
but aren't offering any opportunity to give a 1k contribution to YP.

I fully understand that improving on that would be difficult,
but this is a reason why most businesses are not able to help
you even if they want to.

> Cheers,
> 
> Richard

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-08 21:46                               ` Adrian Bunk
@ 2020-03-08 22:08                                 ` Alexander Kanavin
  2020-03-09  0:23                                   ` Adrian Bunk
  0 siblings, 1 reply; 27+ messages in thread
From: Alexander Kanavin @ 2020-03-08 22:08 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Patches and discussions about the oe-core layer,
	openembedded-architecture

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On Sun, 8 Mar 2020 at 22:46, Adrian Bunk <bunk@stusta.de> wrote:

> It is on YP to make it clear to users whether or not Yocto comes with
> the same set of security guarantees as distributions like Ubuntu or
> Debian.
> If it is the duty of every user of Yocto to track and fix CVEs,
> then this has to be stated clearly instead of implying the opposite.
> This gives users the opportunity to mitigate, instead of unknowingly
> shipping insecure products.
>

Do you have any actual evidence for actual users shipping insecure products
because they mistakenly believe Yocto takes care of security for them? This
has been the situation from the start of the project, certainly this was
the case 5 years ago when I joined it, and the only person ever to make an
issue out of it is you. Everyone else seems to understand the deal they're
getting by using Yocto without a commercial support contract.

Yes, there are millions of insecure yocto-based devices out there, but
there reasons they are insecure have nothing to do with what you say.

Alex

[-- Attachment #2: Type: text/html, Size: 1430 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-08 22:08                                 ` Alexander Kanavin
@ 2020-03-09  0:23                                   ` Adrian Bunk
  2020-03-09  7:29                                     ` Ayoub Zaki
  0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2020-03-09  0:23 UTC (permalink / raw)
  To: Alexander Kanavin
  Cc: Patches and discussions about the oe-core layer,
	openembedded-architecture

On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote:
> On Sun, 8 Mar 2020 at 22:46, Adrian Bunk <bunk@stusta.de> wrote:
> 
> > It is on YP to make it clear to users whether or not Yocto comes with
> > the same set of security guarantees as distributions like Ubuntu or
> > Debian.
> > If it is the duty of every user of Yocto to track and fix CVEs,
> > then this has to be stated clearly instead of implying the opposite.
> > This gives users the opportunity to mitigate, instead of unknowingly
> > shipping insecure products.
> >
> 
> Do you have any actual evidence for actual users shipping insecure products
> because they mistakenly believe Yocto takes care of security for them?

Nothing to discuss in public.

> This
> has been the situation from the start of the project, certainly this was
> the case 5 years ago when I joined it, and the only person ever to make an
> issue out of it is you. Everyone else seems to understand the deal they're
> getting by using Yocto without a commercial support contract.
>...

You are saying that 'track and fix CVEs' is on users.
Let's check what YP is telling users.

Click on the "Is Yocto Project for you?" link on the YP frontpage:

https://www.yoctoproject.org/is-yocto-project-for-you/
13. Yocto Project follows a strict release schedule incorporating 
security patches in all supported releases. This predictability is 
crucial for projects that are based on Yocto Project and allows the 
development teams to plan their activities. Developers can choose which 
Yocto Project branch on which to base their activities as a function of 
their needs. The development branch will ensure access to the latest 
features while the stable branches will reduce the pace of changes. CVEs 
(common vulnerabilities and exposures) issues are supported for the 
latest 2 releases.


> Alex

cu
Adrian


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-09  0:23                                   ` Adrian Bunk
@ 2020-03-09  7:29                                     ` Ayoub Zaki
  2020-03-09  9:53                                       ` Alexander Kanavin
                                                         ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Ayoub Zaki @ 2020-03-09  7:29 UTC (permalink / raw)
  To: openembedded-core

Hello,

On 09.03.20 01:23, Adrian Bunk wrote:
> On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote:
>> On Sun, 8 Mar 2020 at 22:46, Adrian Bunk <bunk@stusta.de> wrote:
>>
>>> It is on YP to make it clear to users whether or not Yocto comes with
>>> the same set of security guarantees as distributions like Ubuntu or
>>> Debian.
>>> If it is the duty of every user of Yocto to track and fix CVEs,
>>> then this has to be stated clearly instead of implying the opposite.
>>> This gives users the opportunity to mitigate, instead of unknowingly
>>> shipping insecure products.
>>>
>> Do you have any actual evidence for actual users shipping insecure products
>> because they mistakenly believe Yocto takes care of security for them?
> Nothing to discuss in public.
>
>> This
>> has been the situation from the start of the project, certainly this was
>> the case 5 years ago when I joined it, and the only person ever to make an
>> issue out of it is you. Everyone else seems to understand the deal they're
>> getting by using Yocto without a commercial support contract.
>> ...
> You are saying that 'track and fix CVEs' is on users.
> Let's check what YP is telling users.
>
> Click on the "Is Yocto Project for you?" link on the YP frontpage:
>
> https://www.yoctoproject.org/is-yocto-project-for-you/
> 13. Yocto Project follows a strict release schedule incorporating
> security patches in all supported releases. This predictability is
> crucial for projects that are based on Yocto Project and allows the
> development teams to plan their activities. Developers can choose which
> Yocto Project branch on which to base their activities as a function of
> their needs. The development branch will ensure access to the latest
> features while the stable branches will reduce the pace of changes. CVEs
> (common vulnerabilities and exposures) issues are supported for the
> latest 2 releases.


Adrian is making a point here, The Yocto Project by claiming that it 
supports security patches for Stable releases is misleading the Users!

I work with different customers and some of them think that by using and 
pulling the latest releases they will get the CVEs automatically fixed!

YP should state that CLEARLY! Of course it will impact the choice of 
going with Yocto or Not ( probably NOT in this case).

>
>
>> Alex
> cu
> Adrian

Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg


Mobile   : +4917662901545
Email    : ayoub.zaki@embexus.com
Homepage : https://embexus.com
VAT No.  : DE313902634



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-09  7:29                                     ` Ayoub Zaki
@ 2020-03-09  9:53                                       ` Alexander Kanavin
  2020-03-09 12:45                                       ` Richard Purdie
  2020-03-10 16:11                                       ` Ross Burton
  2 siblings, 0 replies; 27+ messages in thread
From: Alexander Kanavin @ 2020-03-09  9:53 UTC (permalink / raw)
  To: Ayoub Zaki; +Cc: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 3620 bytes --]

The intent is to say that security patches are eligible for inclusion into
stable release updates (while e.g. version updates are not). If the wording
is vague, it can be improved. I tend to agree that there has to be a more
clear message that users must set up their own security process or pay
someone to do it (especially considering that most products involve a lot
more 3rd party layers and not just oe-core). Some of the fixing work can be
reused from upstream but there is no promise that it covers everything.

Alex

On Mon 9. Mar 2020 at 8.45, Ayoub Zaki <ayoub.zaki@embexus.com> wrote:

> Hello,
>
> On 09.03.20 01:23, Adrian Bunk wrote:
> > On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote:
> >> On Sun, 8 Mar 2020 at 22:46, Adrian Bunk <bunk@stusta.de> wrote:
> >>
> >>> It is on YP to make it clear to users whether or not Yocto comes with
> >>> the same set of security guarantees as distributions like Ubuntu or
> >>> Debian.
> >>> If it is the duty of every user of Yocto to track and fix CVEs,
> >>> then this has to be stated clearly instead of implying the opposite.
> >>> This gives users the opportunity to mitigate, instead of unknowingly
> >>> shipping insecure products.
> >>>
> >> Do you have any actual evidence for actual users shipping insecure
> products
> >> because they mistakenly believe Yocto takes care of security for them?
> > Nothing to discuss in public.
> >
> >> This
> >> has been the situation from the start of the project, certainly this was
> >> the case 5 years ago when I joined it, and the only person ever to make
> an
> >> issue out of it is you. Everyone else seems to understand the deal
> they're
> >> getting by using Yocto without a commercial support contract.
> >> ...
> > You are saying that 'track and fix CVEs' is on users.
> > Let's check what YP is telling users.
> >
> > Click on the "Is Yocto Project for you?" link on the YP frontpage:
> >
> > https://www.yoctoproject.org/is-yocto-project-for-you/
> > 13. Yocto Project follows a strict release schedule incorporating
> > security patches in all supported releases. This predictability is
> > crucial for projects that are based on Yocto Project and allows the
> > development teams to plan their activities. Developers can choose which
> > Yocto Project branch on which to base their activities as a function of
> > their needs. The development branch will ensure access to the latest
> > features while the stable branches will reduce the pace of changes. CVEs
> > (common vulnerabilities and exposures) issues are supported for the
> > latest 2 releases.
>
>
> Adrian is making a point here, The Yocto Project by claiming that it
> supports security patches for Stable releases is misleading the Users!
>
> I work with different customers and some of them think that by using and
> pulling the latest releases they will get the CVEs automatically fixed!
>
> YP should state that CLEARLY! Of course it will impact the choice of
> going with Yocto or Not ( probably NOT in this case).
>
> >
> >
> >> Alex
> > cu
> > Adrian
>
> Mit freundlichen Grüßen / Kind regards
>
> --
> Ayoub Zaki
> Embedded Systems Consultant
>
> Vaihinger Straße 2/1
> D-71634 Ludwigsburg
>
>
> Mobile   : +4917662901545
> Email    : ayoub.zaki@embexus.com
> Homepage : https://embexus.com
> VAT No.  : DE313902634
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 4809 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-09  7:29                                     ` Ayoub Zaki
  2020-03-09  9:53                                       ` Alexander Kanavin
@ 2020-03-09 12:45                                       ` Richard Purdie
  2020-03-10 16:11                                       ` Ross Burton
  2 siblings, 0 replies; 27+ messages in thread
From: Richard Purdie @ 2020-03-09 12:45 UTC (permalink / raw)
  To: Ayoub Zaki, openembedded-core

On Mon, 2020-03-09 at 08:29 +0100, Ayoub Zaki wrote:
> On 09.03.20 01:23, Adrian Bunk wrote:
> > On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote:
> > > On Sun, 8 Mar 2020 at 22:46, Adrian Bunk <bunk@stusta.de> wrote:
> > https://www.yoctoproject.org/is-yocto-project-for-you/
> > 13. Yocto Project follows a strict release schedule incorporating
> > security patches in all supported releases. This predictability is
> > crucial for projects that are based on Yocto Project and allows the
> > development teams to plan their activities. Developers can choose
> > which
> > Yocto Project branch on which to base their activities as a
> > function of
> > their needs. The development branch will ensure access to the
> > latest
> > features while the stable branches will reduce the pace of changes.
> > CVEs
> > (common vulnerabilities and exposures) issues are supported for the
> > latest 2 releases.
> 
> Adrian is making a point here, The Yocto Project by claiming that it 
> supports security patches for Stable releases is misleading the
> Users!
> 
> I work with different customers and some of them think that by using
> and pulling the latest releases they will get the CVEs automatically
> fixed!

If you use our latest codebase then you get the latest usptream
versions and hence, yes, you get the fixes. It does depend what
"latest" means in the contents of your comments above.

For the stable series we're putting in a commitment to review and
include CVE fixes which are submitted to us. We have a pretty good
track record of having them submitted and included.

That said, we cannot write a guarantee than all CVE fixes will be
included, we're an open source project, not a company with an
engineering team or a project with the scale of say Debian.

> YP should state that CLEARLY! Of course it will impact the choice of 
> going with Yocto or Not ( probably NOT in this case).

I agree we have to set realistic expectations, not entirely sure how to
do that but hope the above clarifies whilst we try and update the
docs/web pages and so on.

Cheers,

Richard





^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-09  7:29                                     ` Ayoub Zaki
  2020-03-09  9:53                                       ` Alexander Kanavin
  2020-03-09 12:45                                       ` Richard Purdie
@ 2020-03-10 16:11                                       ` Ross Burton
  2020-03-10 19:45                                         ` Ayoub Zaki
  2 siblings, 1 reply; 27+ messages in thread
From: Ross Burton @ 2020-03-10 16:11 UTC (permalink / raw)
  To: Ayoub Zaki; +Cc: OE-core

On Mon, 9 Mar 2020 at 07:45, Ayoub Zaki <ayoub.zaki@embexus.com> wrote:
> Adrian is making a point here, The Yocto Project by claiming that it
> supports security patches for Stable releases is misleading the Users!
>
> I work with different customers and some of them think that by using and
> pulling the latest releases they will get the CVEs automatically fixed!
>
> YP should state that CLEARLY! Of course it will impact the choice of
> going with Yocto or Not ( probably NOT in this case).

What would the alternative to Yocto be, and what is their security
policy?  Does e.g. buildroot commit to fixing every known security
issue (which is more than just known CVEs) in their releases?

Ross


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-10 16:11                                       ` Ross Burton
@ 2020-03-10 19:45                                         ` Ayoub Zaki
  2020-03-11 14:53                                           ` Ross Burton
  0 siblings, 1 reply; 27+ messages in thread
From: Ayoub Zaki @ 2020-03-10 19:45 UTC (permalink / raw)
  To: Ross Burton; +Cc: OE-core

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

Hi,


On 10.03.20 17:11, Ross Burton wrote:
> On Mon, 9 Mar 2020 at 07:45, Ayoub Zaki <ayoub.zaki@embexus.com> wrote:
>> Adrian is making a point here, The Yocto Project by claiming that it
>> supports security patches for Stable releases is misleading the Users!
>>
>> I work with different customers and some of them think that by using and
>> pulling the latest releases they will get the CVEs automatically fixed!
>>
>> YP should state that CLEARLY! Of course it will impact the choice of
>> going with Yocto or Not ( probably NOT in this case).
> What would the alternative to Yocto be, and what is their security
> policy?  Does e.g. buildroot commit to fixing every known security
> issue (which is more than just known CVEs) in their releases?


Security patches support is definitely for many companies a knock-out 
criterion.
Probably in this case Debian or a commercial OSes like Qnx would be a 
choice for who can afford it.


Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg


Mobile   : +4917662901545
Email    : ayoub.zaki@embexus.com
Homepage : https://embexus.com
VAT No.  : DE313902634


[-- Attachment #2: Type: text/html, Size: 3614 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
  2020-03-10 19:45                                         ` Ayoub Zaki
@ 2020-03-11 14:53                                           ` Ross Burton
  0 siblings, 0 replies; 27+ messages in thread
From: Ross Burton @ 2020-03-11 14:53 UTC (permalink / raw)
  To: Ayoub Zaki; +Cc: OE-core

On Tue, 10 Mar 2020 at 19:45, Ayoub Zaki <ayoub.zaki@embexus.com> wrote:
> Security patches support is definitely for many companies a knock-out criterion.
> Probably in this case Debian or a commercial OSes like Qnx would be a choice for who can afford it.

If someone is using Yocto commercially and willing to pay money, then
they are entirely welcome to use a OSV such as Mentor/Wind
River/Montavista/etc who *will* make firm commitments on security
issues.

Ross


^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [Openembedded-architecture] Does YP provide security support for stable and LTS branches?
@ 2020-03-09 10:01 Rich Persaud
  0 siblings, 0 replies; 27+ messages in thread
From: Rich Persaud @ 2020-03-09 10:01 UTC (permalink / raw)
  To: Ayoub Zaki; +Cc: openembedded-core

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]


On Mar 9, 2020, at 03:45, Ayoub Zaki <ayoub.zaki@embexus.com> wrote:
>> Nothing to discuss in public.
>> 
>>> This
>>> has been the situation from the start of the project, certainly this was
>>> the case 5 years ago when I joined it, and the only person ever to make an
>>> issue out of it is you. Everyone else seems to understand the deal they're
>>> getting by using Yocto without a commercial support contract.
>>> ...
>> You are saying that 'track and fix CVEs' is on users.
>> Let's check what YP is telling users.
>> 
>> Click on the "Is Yocto Project for you?" link on the YP frontpage:
>> 
>> https://www.yoctoproject.org/is-yocto-project-for-you/
>> 13. Yocto Project follows a strict release schedule incorporating
>> security patches in all supported releases. This predictability is
>> crucial for projects that are based on Yocto Project and allows the
>> development teams to plan their activities. Developers can choose which
>> Yocto Project branch on which to base their activities as a function of
>> their needs. The development branch will ensure access to the latest
>> features while the stable branches will reduce the pace of changes. CVEs
>> (common vulnerabilities and exposures) issues are supported for the
>> latest 2 releases.
> 
> 
> Adrian is making a point here, The Yocto Project by claiming that it supports security patches for Stable releases is misleading the Users!
> 
> I work with different customers and some of them think that by using and pulling the latest releases they will get the CVEs automatically fixed!
> 
> YP should state that CLEARLY! Of course it will impact the choice of going with Yocto or Not ( probably NOT in this case).

Would the Yocto mailing list [1] be a good venue to reach the maintainers of the Yocto website? There are now a handful of OE-arch / OE-core threads on this topic, which could be consolidated into a single thread on the Yocto list, where participants can act on recommendations.

Rich

[1] https://lists.yoctoproject.org/g/yocto


[-- Attachment #2: Type: text/html, Size: 3900 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2020-03-11 14:53 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-23 19:34 [RFC][PATCH 1/2] nss: Move to meta-oe Adrian Bunk
2020-02-23 19:34 ` [RFC][PATCH 2/2] nspr: " Adrian Bunk
2020-02-24  0:25 ` [RFC][PATCH 1/2] nss: " Khem Raj
2020-02-24  5:17   ` Adrian Bunk
2020-02-24 16:32     ` akuster808
2020-02-27 13:27       ` Adrian Bunk
2020-02-27 14:03         ` Alexander Kanavin
2020-03-04  9:05           ` Adrian Bunk
2020-03-04  9:36             ` Alexander Kanavin
2020-03-04 11:32               ` Adrian Bunk
2020-03-04 12:13                 ` Alexander Kanavin
2020-03-04 14:01                   ` Does YP provide security support for stable and LTS branches? Adrian Bunk
2020-03-04 16:00                     ` Alexander Kanavin
2020-03-04 17:24                       ` Adrian Bunk
2020-03-04 20:26                         ` [Openembedded-architecture] " akuster808
2020-03-06 10:04                           ` Adrian Bunk
2020-03-06 10:36                             ` Richard Purdie
2020-03-08 21:46                               ` Adrian Bunk
2020-03-08 22:08                                 ` Alexander Kanavin
2020-03-09  0:23                                   ` Adrian Bunk
2020-03-09  7:29                                     ` Ayoub Zaki
2020-03-09  9:53                                       ` Alexander Kanavin
2020-03-09 12:45                                       ` Richard Purdie
2020-03-10 16:11                                       ` Ross Burton
2020-03-10 19:45                                         ` Ayoub Zaki
2020-03-11 14:53                                           ` Ross Burton
2020-03-09 10:01 Rich Persaud

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.