Re: [OE-core] [PATCH] file: explicitly disable seccomp
On Sat, Oct 19, 2019 at 2:58 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote:
> >
> >
> > On Fri, Oct 18, 2019 at 4:58 PM Ross Burton
> > wrote:
> > > file will automatically enable seccomp if the seccomp headers are
> > > available, but
> > > the build will fail on Opensuse Tumbleweed because the include
> > > paths are wrong.
> > >
> > > Enabling seccomp is a bad idea because it interacts badly with
> > > pseudo (causing
> > > build failures), so explicitly and globally disable seccomp.
> > >
> > > Signed-off-by: Ross Burton
> > > ---
> > > meta/recipes-devtools/file/file_5.37.bb | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/meta/recipes-devtools/file/file_5.37.bb
> > > b/meta/recipes-devtools/file/file_5.37.bb
> > > index a840dbc012b..c53a120b840 100644
> > > --- a/meta/recipes-devtools/file/file_5.37.bb
> > > +++ b/meta/recipes-devtools/file/file_5.37.bb
> > > @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
> > >
> > > inherit autotools update-alternatives
> > >
> > > +EXTRA_OECONF += "--disable-libseccomp"
> > > +
> >
> > On host it makes sense but how about for target recipe ? We do have
> > libseccomp support
> > Perhaps it’s best to disable it for native and native sdk alone ?
>
> Given the problem reports in the media and the decisions made by most
> other distros I think disabling this is probably safest until its been
> make more usable (no other distro is shipping this enabled now).
>
Ok makes sense
> Cheers,
>
> Richard
>
>
>
>
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libgcrypt: fix CVE-2019-13627
On 10/18/19 3:32 PM, Trevor Gamblin wrote:
Note that there are two patch files added for this fix.
Signed-off-by: Trevor Gamblin
---
...cdsa-Fix-use-of-nonce-use-larger-one.patch | 126 ++
...Add-mitigation-against-timing-attack.patch | 68 ++
.../libgcrypt/libgcrypt_1.8.4.bb | 2 +
NAK.
1.8.5 has been released and it DOES contain a fix for this CVE.
On master the commits are:
7c294330 dsa,ecdsa: Fix use of nonce, use larger one.
b9577f7c ecc: Add mitigation against timing attack.
but they are not part of a tagged release:
$ git tag --contains 7c294330 -> NULL
$ git tag --contains b9577f7c -> NULL
BUT, if you look at:
$ git log --oneline libgcrypt-1.8.4..libgcrypt-1.8.5 | \
grep -i mitigation
d5407b78 ecc: Add mitigation against timing attack.
$ git log --oneline libgcrypt-1.8.4..libgcrypt-1.8.5 | \
grep -i nonce
db4e9976 dsa,ecdsa: Fix use of nonce, use larger one.
and if you look at those logs, you'll see that these commits
were cherry-picked from master.
Also note the branch:
$ git branch -a --contains d5407b78
remotes/origin/LIBGCRYPT-1.8-BRANCH
so that makes sense. I wasn't able to the branch without the -a
so I was concerned that the repo was being handled in a way
that I didn't understand.
../Randy
3 files changed, 196 insertions(+)
create mode 100644
meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
create mode 100644
meta/recipes-support/libgcrypt/files/0001-ecc-Add-mitigation-against-timing-attack.patch
diff --git
a/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
b/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
new file mode 100644
index 00..fdc3873ba1
--- /dev/null
+++
b/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
@@ -0,0 +1,126 @@
+From 7c2943309d14407b51c8166c4dcecb56a3628567 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka
+Date: Thu, 8 Aug 2019 17:42:02 +0900
+Subject: [PATCH] dsa,ecdsa: Fix use of nonce, use larger one.
+
+* cipher/dsa-common.c (_gcry_dsa_modify_k): New.
+* cipher/pubkey-internal.h (_gcry_dsa_modify_k): New.
+* cipher/dsa.c (sign): Use _gcry_dsa_modify_k.
+* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Likewise.
+* cipher/ecc-gost.c (_gcry_ecc_gost_sign): Likewise.
+
+CVE-id: CVE-2019-13627
+GnuPG-bug-id: 4626
+Signed-off-by: NIIBE Yutaka
+---
+ cipher/dsa-common.c | 24
+ cipher/dsa.c | 2 ++
+ cipher/ecc-ecdsa.c | 10 +-
+ cipher/ecc-gost.c| 2 ++
+ cipher/pubkey-internal.h | 1 +
+ 5 files changed, 30 insertions(+), 9 deletions(-)
+
+Upstream-Status: Backport
[https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=7c2943309d1]
+This backport is one of two upstream patches addressing CVE-2019-13627.
+
+CVE: CVE-2019-13627
+
+Signed-off-by: Trevor Gamblin
+
+diff --git a/cipher/dsa-common.c b/cipher/dsa-common.c
+index 8c0a6843..fe49248d 100644
+--- a/cipher/dsa-common.c
b/cipher/dsa-common.c
+@@ -29,6 +29,30 @@
+ #include "pubkey-internal.h"
+
+
++/*
++ * Modify K, so that computation time difference can be small,
++ * by making K large enough.
++ *
++ * Originally, (EC)DSA computation requires k where 0 < k < q. Here,
++ * we add q (the order), to keep k in a range: q < k < 2*q (or,
++ * addming more q, to keep k in a range: 2*q < k < 3*q), so that
++ * timing difference of the EC multiply (or exponentiation) operation
++ * can be small. The result of (EC)DSA computation is same.
++ */
++void
++_gcry_dsa_modify_k (gcry_mpi_t k, gcry_mpi_t q, int qbits)
++{
++ gcry_mpi_t k1 = mpi_new (qbits+2);
++
++ mpi_resize (k, (qbits+2+BITS_PER_MPI_LIMB-1) / BITS_PER_MPI_LIMB);
++ k->nlimbs = k->alloced;
++ mpi_add (k, k, q);
++ mpi_add (k1, k, q);
++ mpi_set_cond (k, k1, !mpi_test_bit (k, qbits));
++
++ mpi_free (k1);
++}
++
+ /*
+ * Generate a random secret exponent K less than Q.
+ * Note that ECDSA uses this code also to generate D.
+diff --git a/cipher/dsa.c b/cipher/dsa.c
+index 22d8d782..24a53528 100644
+--- a/cipher/dsa.c
b/cipher/dsa.c
+@@ -635,6 +635,8 @@ sign (gcry_mpi_t r, gcry_mpi_t s, gcry_mpi_t input,
DSA_secret_key *skey,
+ k = _gcry_dsa_gen_k (skey->q, GCRY_STRONG_RANDOM);
+ }
+
++ _gcry_dsa_modify_k (k, skey->q, qbits);
++
+ /* r = (a^k mod p) mod q */
+ mpi_powm( r, skey->g, k, skey->p );
+ mpi_fdiv_r( r, r, skey->q );
+diff --git a/cipher/ecc-ecdsa.c b/cipher/ecc-ecdsa.c
+index 84a1cf84..97966c3a 100644
+--- a/cipher/ecc-ecdsa.c
b/cipher/ecc-ecdsa.c
+@@ -114,15 +114,7 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key
*skey,
+ else
+ k = _gcry_dsa_gen_k (skey->E.n, GCRY_STRONG_RANDOM);
+
+- /* Originally, ECDSA computation requires k where 0 < k < n.
+- * Here, we add n (the order of curve), to keep k in a
+- * range: n < k < 2*n, or,
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Sat, 2019-10-19 at 00:01 +0200, Andreas Müller wrote: > On Fri, Oct 18, 2019 at 8:50 PM Alexander Kanavin > wrote: > > I certainly don't mean to ignore those reports, it's just that due > > to my ongoing health problems, and having to dedicate most of my > > energy to the day job (https://mbition.io/en/home/), I am not > > currently able to work on the upstream issues in a timely manner > > the way I used to when maintaining core was actually my day job (at > > Intel). > > > > The question of how much effort people who update things in core > > should allocate to fixing 'other' layers has been a conflict point > > for a long time. I'd prefer to see more aggressive > > blacklisting/removal of recipes that no one has an interest in > > fixing and updating. > > > > Alex > > > First and most important: Wish you the very best to get back full > health > Second: If I read meson github issues correctly, there are chances > that meson 0.52.1 fixes (works around) static library fallout as seen > on dconf > Third: Taking this in was sub-optimal but: We are close to release > which is btw the most smooth I've ever seen since I follow this > project. > > We're back to dirty master where sh*t happens... Just to be clear for those not following close, this is only on master and not on the release branch which did not get this change. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Fri, Oct 18, 2019 at 8:50 PM Alexander Kanavin wrote: > > I certainly don't mean to ignore those reports, it's just that due to my > ongoing health problems, and having to dedicate most of my energy to the day > job (https://mbition.io/en/home/), I am not currently able to work on the > upstream issues in a timely manner the way I used to when maintaining core > was actually my day job (at Intel). > > The question of how much effort people who update things in core should > allocate to fixing 'other' layers has been a conflict point for a long time. > I'd prefer to see more aggressive blacklisting/removal of recipes that no one > has an interest in fixing and updating. > > Alex > First and most important: Wish you the very best to get back full health Second: If I read meson github issues correctly, there are chances that meson 0.52.1 fixes (works around) static library fallout as seen on dconf Third: Taking this in was sub-optimal but: We are close to release which is btw the most smooth I've ever seen since I follow this project. We're back to dirty master where sh*t happens... Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] file: explicitly disable seccomp
On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote:
>
>
> On Fri, Oct 18, 2019 at 4:58 PM Ross Burton
> wrote:
> > file will automatically enable seccomp if the seccomp headers are
> > available, but
> > the build will fail on Opensuse Tumbleweed because the include
> > paths are wrong.
> >
> > Enabling seccomp is a bad idea because it interacts badly with
> > pseudo (causing
> > build failures), so explicitly and globally disable seccomp.
> >
> > Signed-off-by: Ross Burton
> > ---
> > meta/recipes-devtools/file/file_5.37.bb | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/file/file_5.37.bb
> > b/meta/recipes-devtools/file/file_5.37.bb
> > index a840dbc012b..c53a120b840 100644
> > --- a/meta/recipes-devtools/file/file_5.37.bb
> > +++ b/meta/recipes-devtools/file/file_5.37.bb
> > @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
> >
> > inherit autotools update-alternatives
> >
> > +EXTRA_OECONF += "--disable-libseccomp"
> > +
>
> On host it makes sense but how about for target recipe ? We do have
> libseccomp support
> Perhaps it’s best to disable it for native and native sdk alone ?
Given the problem reports in the media and the decisions made by most
other distros I think disabling this is probably safest until its been
make more usable (no other distro is shipping this enabled now).
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Fri, 2019-10-18 at 20:49 +0200, Alexander Kanavin wrote: > I certainly don't mean to ignore those reports, it's just that due to > my ongoing health problems, and having to dedicate most of my energy > to the day job (https://mbition.io/en/home/), I am not currently able > to work on the upstream issues in a timely manner the way I used to > when maintaining core was actually my day job (at Intel). > > The question of how much effort people who update things in core > should allocate to fixing 'other' layers has been a conflict point > for a long time. I'd prefer to see more aggressive > blacklisting/removal of recipes that no one has an interest in fixing > and updating. If anything this would be my fault for merging things despite there being concerns raised. I have to admit I'd seen other patches and therefore erroneously thought the issues we mostly resolved. Should OE-Core block on all issues being resolved before merging? I'm torn on that, I realise there are pros and cons. It takes most of my time/energy to track the issues with core without trying to remember that patch X breaks layer Y and that I need a report back on that combination before I then find a patch and merge it. So sorry, I probably shouldn't have taken this :/. There is a fundamental issue with having enough people to help work on these things though and requiring more work for changes to be merged isn't going to help. I wish I knew what would help. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [thud][PATCH] Revert "OpkgPM: use --add-ignore-recommends to process BAD_RECOMMENDATIONS"
On 10/18/19 10:58 AM, Alejandro Del Castillo wrote: > > On 10/17/19 3:01 PM, Denys Dmytriyenko wrote: >> On Thu, Oct 17, 2019 at 12:21:11PM -0700, akuster808 wrote: >>> On 10/17/19 11:42 AM, Denys Dmytriyenko wrote: Thank you for this revert! I've been pulling my hair out past couple days figuring out why BAD_RECOMMENDATIONS stopped working for us. This fixed it. >>> What I find curious is that the offending commit has been in thud since >>> July 29th and we are just now hearing about issues. >> Yeah, in our case we only noticed the issue when we started preparing the >> latest release and found extra packages that weren't supposed to be there. > Is there a bugzilla ticket tracking the issue? I am not aware of any for thud. IIRC, this commit was a backport request from the community. It would be interesting if those who have issues with thud check against master. - armin > I added the > --add-ignore-recommends flag to opkg, mainly to get BAD_RECOMMENDATIONS > to work for OE. If that's not the case, then need to figure out what > went wrong (the OE side or the opkg side) > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] do_rootfs broken
Hi, Updated oe-core from commit 9973f89dafdf9d21f4021f59f1f4669f4ac13aff Author: Chen Qi Date: Fri Sep 27 14:42:51 2019 +0800 systemd: fix NFS regression To Author: Khem Raj Date: Sat Oct 12 17:51:17 2019 -0700 glib-2.0: Fix build with clang compiler and reverted meson 0.52.0 upgrade. All recipes build without issues but do_rootfs fails with: NOTE: > Executing update_pixbuf_cache intercept ... NOTE: Exit code 1. Output: + '[' True = False -a qemuwrapper-cross '!=' nativesdk-qemuwrapper-cross ']' + qemu-arm -r 3.2.0 -E LD_LIBRARY_PATH=/home/superandy/tmp/oe-core-glibc/work/raspberrypi3-mortsgna-linux-gnueabi/allgui-full-image/1.0-r0/rootfs/usr/lib:/home/superandy/tmp/oe-core-glibc/work/raspberrypi3-mortsgna-linux-gnueabi/allgui-full-image/1.0-r0/rootfs/lib -L /home/superandy/tmp/oe-core-glibc/work/raspberrypi3-mortsgna-linux-gnueabi/allgui-full-image/1.0-r0/rootfs /home/superandy/tmp/oe-core-glibc/work/raspberrypi3-mortsgna-linux-gnueabi/allgui-full-image/1.0-r0/rootfs/usr/lib/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders ERROR: The postinstall intercept hook 'update_pixbuf_cache' failed, details in /home/superandy/tmp/oe-core-glibc/work/raspberrypi3-mortsgna-linux-gnueabi/allgui-full-image/1.0-r0/temp/log.do_rootfs DEBUG: Python function do_rootfs finished Tried already to revert commit 3ecb6744402332f1ad143eb1eb6a94143e1700c8 Author: Joerg Vehlow Date: Fri Oct 11 08:03:57 2019 +0200 runqemu: Remove disabling of high resolution timer but that did not change anything. Any ideas / suggestions? Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libgcrypt: fix CVE-2019-13627
Note that there are two patch files added for this fix.
Signed-off-by: Trevor Gamblin
---
...cdsa-Fix-use-of-nonce-use-larger-one.patch | 126 ++
...Add-mitigation-against-timing-attack.patch | 68 ++
.../libgcrypt/libgcrypt_1.8.4.bb | 2 +
3 files changed, 196 insertions(+)
create mode 100644
meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
create mode 100644
meta/recipes-support/libgcrypt/files/0001-ecc-Add-mitigation-against-timing-attack.patch
diff --git
a/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
b/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
new file mode 100644
index 00..fdc3873ba1
--- /dev/null
+++
b/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
@@ -0,0 +1,126 @@
+From 7c2943309d14407b51c8166c4dcecb56a3628567 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka
+Date: Thu, 8 Aug 2019 17:42:02 +0900
+Subject: [PATCH] dsa,ecdsa: Fix use of nonce, use larger one.
+
+* cipher/dsa-common.c (_gcry_dsa_modify_k): New.
+* cipher/pubkey-internal.h (_gcry_dsa_modify_k): New.
+* cipher/dsa.c (sign): Use _gcry_dsa_modify_k.
+* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Likewise.
+* cipher/ecc-gost.c (_gcry_ecc_gost_sign): Likewise.
+
+CVE-id: CVE-2019-13627
+GnuPG-bug-id: 4626
+Signed-off-by: NIIBE Yutaka
+---
+ cipher/dsa-common.c | 24
+ cipher/dsa.c | 2 ++
+ cipher/ecc-ecdsa.c | 10 +-
+ cipher/ecc-gost.c| 2 ++
+ cipher/pubkey-internal.h | 1 +
+ 5 files changed, 30 insertions(+), 9 deletions(-)
+
+Upstream-Status: Backport
[https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=7c2943309d1]
+This backport is one of two upstream patches addressing CVE-2019-13627.
+
+CVE: CVE-2019-13627
+
+Signed-off-by: Trevor Gamblin
+
+diff --git a/cipher/dsa-common.c b/cipher/dsa-common.c
+index 8c0a6843..fe49248d 100644
+--- a/cipher/dsa-common.c
b/cipher/dsa-common.c
+@@ -29,6 +29,30 @@
+ #include "pubkey-internal.h"
+
+
++/*
++ * Modify K, so that computation time difference can be small,
++ * by making K large enough.
++ *
++ * Originally, (EC)DSA computation requires k where 0 < k < q. Here,
++ * we add q (the order), to keep k in a range: q < k < 2*q (or,
++ * addming more q, to keep k in a range: 2*q < k < 3*q), so that
++ * timing difference of the EC multiply (or exponentiation) operation
++ * can be small. The result of (EC)DSA computation is same.
++ */
++void
++_gcry_dsa_modify_k (gcry_mpi_t k, gcry_mpi_t q, int qbits)
++{
++ gcry_mpi_t k1 = mpi_new (qbits+2);
++
++ mpi_resize (k, (qbits+2+BITS_PER_MPI_LIMB-1) / BITS_PER_MPI_LIMB);
++ k->nlimbs = k->alloced;
++ mpi_add (k, k, q);
++ mpi_add (k1, k, q);
++ mpi_set_cond (k, k1, !mpi_test_bit (k, qbits));
++
++ mpi_free (k1);
++}
++
+ /*
+ * Generate a random secret exponent K less than Q.
+ * Note that ECDSA uses this code also to generate D.
+diff --git a/cipher/dsa.c b/cipher/dsa.c
+index 22d8d782..24a53528 100644
+--- a/cipher/dsa.c
b/cipher/dsa.c
+@@ -635,6 +635,8 @@ sign (gcry_mpi_t r, gcry_mpi_t s, gcry_mpi_t input,
DSA_secret_key *skey,
+ k = _gcry_dsa_gen_k (skey->q, GCRY_STRONG_RANDOM);
+ }
+
++ _gcry_dsa_modify_k (k, skey->q, qbits);
++
+ /* r = (a^k mod p) mod q */
+ mpi_powm( r, skey->g, k, skey->p );
+ mpi_fdiv_r( r, r, skey->q );
+diff --git a/cipher/ecc-ecdsa.c b/cipher/ecc-ecdsa.c
+index 84a1cf84..97966c3a 100644
+--- a/cipher/ecc-ecdsa.c
b/cipher/ecc-ecdsa.c
+@@ -114,15 +114,7 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key
*skey,
+ else
+ k = _gcry_dsa_gen_k (skey->E.n, GCRY_STRONG_RANDOM);
+
+- /* Originally, ECDSA computation requires k where 0 < k < n.
+- * Here, we add n (the order of curve), to keep k in a
+- * range: n < k < 2*n, or, addming more n, keep k in a range:
+- * 2*n < k < 3*n, so that timing difference of the EC
+- * multiply operation can be small. The result is same.
+- */
+- mpi_add (k, k, skey->E.n);
+- if (!mpi_test_bit (k, qbits))
+-mpi_add (k, k, skey->E.n);
++ _gcry_dsa_modify_k (k, skey->E.n, qbits);
+
+ _gcry_mpi_ec_mul_point (, k, >E.G, ctx);
+ if (_gcry_mpi_ec_get_affine (x, NULL, , ctx))
+diff --git a/cipher/ecc-gost.c b/cipher/ecc-gost.c
+index a34fa084..0362a6c7 100644
+--- a/cipher/ecc-gost.c
b/cipher/ecc-gost.c
+@@ -94,6 +94,8 @@ _gcry_ecc_gost_sign (gcry_mpi_t input, ECC_secret_key *skey,
+ mpi_free (k);
+ k = _gcry_dsa_gen_k (skey->E.n, GCRY_STRONG_RANDOM);
+
++ _gcry_dsa_modify_k (k, skey->E.n, qbits);
++
+ _gcry_mpi_ec_mul_point (, k, >E.G, ctx);
+ if (_gcry_mpi_ec_get_affine (x, NULL, , ctx))
+ {
+diff --git a/cipher/pubkey-internal.h
[OE-core] [zeus][PATCH] libgcrypt: fix CVE-2019-13627
Note that there are two patch files added for this fix.
Signed-off-by: Trevor Gamblin
---
...cdsa-Fix-use-of-nonce-use-larger-one.patch | 126 ++
...Add-mitigation-against-timing-attack.patch | 68 ++
.../libgcrypt/libgcrypt_1.8.4.bb | 2 +
3 files changed, 196 insertions(+)
create mode 100644
meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
create mode 100644
meta/recipes-support/libgcrypt/files/0001-ecc-Add-mitigation-against-timing-attack.patch
diff --git
a/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
b/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
new file mode 100644
index 00..fdc3873ba1
--- /dev/null
+++
b/meta/recipes-support/libgcrypt/files/0001-dsa-ecdsa-Fix-use-of-nonce-use-larger-one.patch
@@ -0,0 +1,126 @@
+From 7c2943309d14407b51c8166c4dcecb56a3628567 Mon Sep 17 00:00:00 2001
+From: NIIBE Yutaka
+Date: Thu, 8 Aug 2019 17:42:02 +0900
+Subject: [PATCH] dsa,ecdsa: Fix use of nonce, use larger one.
+
+* cipher/dsa-common.c (_gcry_dsa_modify_k): New.
+* cipher/pubkey-internal.h (_gcry_dsa_modify_k): New.
+* cipher/dsa.c (sign): Use _gcry_dsa_modify_k.
+* cipher/ecc-ecdsa.c (_gcry_ecc_ecdsa_sign): Likewise.
+* cipher/ecc-gost.c (_gcry_ecc_gost_sign): Likewise.
+
+CVE-id: CVE-2019-13627
+GnuPG-bug-id: 4626
+Signed-off-by: NIIBE Yutaka
+---
+ cipher/dsa-common.c | 24
+ cipher/dsa.c | 2 ++
+ cipher/ecc-ecdsa.c | 10 +-
+ cipher/ecc-gost.c| 2 ++
+ cipher/pubkey-internal.h | 1 +
+ 5 files changed, 30 insertions(+), 9 deletions(-)
+
+Upstream-Status: Backport
[https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=7c2943309d1]
+This backport is one of two upstream patches addressing CVE-2019-13627.
+
+CVE: CVE-2019-13627
+
+Signed-off-by: Trevor Gamblin
+
+diff --git a/cipher/dsa-common.c b/cipher/dsa-common.c
+index 8c0a6843..fe49248d 100644
+--- a/cipher/dsa-common.c
b/cipher/dsa-common.c
+@@ -29,6 +29,30 @@
+ #include "pubkey-internal.h"
+
+
++/*
++ * Modify K, so that computation time difference can be small,
++ * by making K large enough.
++ *
++ * Originally, (EC)DSA computation requires k where 0 < k < q. Here,
++ * we add q (the order), to keep k in a range: q < k < 2*q (or,
++ * addming more q, to keep k in a range: 2*q < k < 3*q), so that
++ * timing difference of the EC multiply (or exponentiation) operation
++ * can be small. The result of (EC)DSA computation is same.
++ */
++void
++_gcry_dsa_modify_k (gcry_mpi_t k, gcry_mpi_t q, int qbits)
++{
++ gcry_mpi_t k1 = mpi_new (qbits+2);
++
++ mpi_resize (k, (qbits+2+BITS_PER_MPI_LIMB-1) / BITS_PER_MPI_LIMB);
++ k->nlimbs = k->alloced;
++ mpi_add (k, k, q);
++ mpi_add (k1, k, q);
++ mpi_set_cond (k, k1, !mpi_test_bit (k, qbits));
++
++ mpi_free (k1);
++}
++
+ /*
+ * Generate a random secret exponent K less than Q.
+ * Note that ECDSA uses this code also to generate D.
+diff --git a/cipher/dsa.c b/cipher/dsa.c
+index 22d8d782..24a53528 100644
+--- a/cipher/dsa.c
b/cipher/dsa.c
+@@ -635,6 +635,8 @@ sign (gcry_mpi_t r, gcry_mpi_t s, gcry_mpi_t input,
DSA_secret_key *skey,
+ k = _gcry_dsa_gen_k (skey->q, GCRY_STRONG_RANDOM);
+ }
+
++ _gcry_dsa_modify_k (k, skey->q, qbits);
++
+ /* r = (a^k mod p) mod q */
+ mpi_powm( r, skey->g, k, skey->p );
+ mpi_fdiv_r( r, r, skey->q );
+diff --git a/cipher/ecc-ecdsa.c b/cipher/ecc-ecdsa.c
+index 84a1cf84..97966c3a 100644
+--- a/cipher/ecc-ecdsa.c
b/cipher/ecc-ecdsa.c
+@@ -114,15 +114,7 @@ _gcry_ecc_ecdsa_sign (gcry_mpi_t input, ECC_secret_key
*skey,
+ else
+ k = _gcry_dsa_gen_k (skey->E.n, GCRY_STRONG_RANDOM);
+
+- /* Originally, ECDSA computation requires k where 0 < k < n.
+- * Here, we add n (the order of curve), to keep k in a
+- * range: n < k < 2*n, or, addming more n, keep k in a range:
+- * 2*n < k < 3*n, so that timing difference of the EC
+- * multiply operation can be small. The result is same.
+- */
+- mpi_add (k, k, skey->E.n);
+- if (!mpi_test_bit (k, qbits))
+-mpi_add (k, k, skey->E.n);
++ _gcry_dsa_modify_k (k, skey->E.n, qbits);
+
+ _gcry_mpi_ec_mul_point (, k, >E.G, ctx);
+ if (_gcry_mpi_ec_get_affine (x, NULL, , ctx))
+diff --git a/cipher/ecc-gost.c b/cipher/ecc-gost.c
+index a34fa084..0362a6c7 100644
+--- a/cipher/ecc-gost.c
b/cipher/ecc-gost.c
+@@ -94,6 +94,8 @@ _gcry_ecc_gost_sign (gcry_mpi_t input, ECC_secret_key *skey,
+ mpi_free (k);
+ k = _gcry_dsa_gen_k (skey->E.n, GCRY_STRONG_RANDOM);
+
++ _gcry_dsa_modify_k (k, skey->E.n, qbits);
++
+ _gcry_mpi_ec_mul_point (, k, >E.G, ctx);
+ if (_gcry_mpi_ec_get_affine (x, NULL, , ctx))
+ {
+diff --git a/cipher/pubkey-internal.h
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
I certainly don't mean to ignore those reports, it's just that due to my
ongoing health problems, and having to dedicate most of my energy to the
day job (https://mbition.io/en/home/), I am not currently able to work on
the upstream issues in a timely manner the way I used to when maintaining
core was actually my day job (at Intel).
The question of how much effort people who update things in core should
allocate to fixing 'other' layers has been a conflict point for a long
time. I'd prefer to see more aggressive blacklisting/removal of recipes
that no one has an interest in fixing and updating.
Alex
On Thu, 17 Oct 2019 at 15:15, Khem Raj wrote:
> On Sat, Oct 12, 2019 at 5:20 PM Khem Raj wrote:
> >
> > On Fri, 2019-10-11 at 13:47 +0200, Alexander Kanavin wrote:
> > > Drop backported patches.
> > >
> > > Signed-off-by: Alexander Kanavin
> > > ---
> > > meta/recipes-devtools/meson/meson.inc | 7 +--
> > > ...efined-by-the-existance-of-a-cross-f.patch | 28 ---
> > > .../0001-Make-CPU-family-warnings-fatal.patch | 8 +--
> > > ...etect-windows-also-if-the-system-str.patch | 29 ---
> > > ...sues-that-arise-when-cross-compiling.patch | 8 +--
> > > ...pport-building-allarch-recipes-again.patch | 4 +-
> > > .../meson/meson/0003-native_bindir.patch | 20
> > > .../meson/meson/vala-cross-compile.patch | 50 ---
> >
> > meson 0.52.x seems to be exposing the dconf build issue.
> >
> > https://errors.yoctoproject.org/Errors/Details/273492/
> >
> > also reported here
> > https://gitlab.gnome.org/GNOME/dconf/issues/59
> >
>
>
> Regardless of this report, this is now merged and I don't see any
> resolution either of a followup
> from the submitter or any other developer. This is quite disheartening
> since it takes a lot of effort to find
> these issues and reports. we should try to be considerate of the
> layers who are trying to keep up with
> OE-Core, like this we won't be able to improve the quality of these
> layers. I understand that there are no breakages seen in OE-cor but we
> should encourage more
> of other layers to test master and especially if there are reports
> than it would be good to heed to them.
>
>
> > >
> > > .../{meson_0.51.2.bb => meson_0.52.0.bb} | 1 -
> > > ...on_0.51.2.bb => nativesdk-meson_0.52.0.bb} | 0
> > > 10 files changed, 22 insertions(+), 133 deletions(-)
> > > delete mode 100644 meta/recipes-devtools/meson/meson/0001-Cross-
> > > build-is-defined-by-the-existance-of-a-cross-f.patch
> > > delete mode 100644 meta/recipes-devtools/meson/meson/0001-
> > > environment.py-detect-windows-also-if-the-system-str.patch
> > > delete mode 100644 meta/recipes-devtools/meson/meson/vala-cross-
> > > compile.patch
> > > rename meta/recipes-devtools/meson/{meson_0.51.2.bb =>
> > > meson_0.52.0.bb} (97%)
> > > rename meta/recipes-devtools/meson/{nativesdk-meson_0.51.2.bb =>
> > > nativesdk-meson_0.52.0.bb} (100%)
> > >
> > > diff --git a/meta/recipes-devtools/meson/meson.inc b/meta/recipes-
> > > devtools/meson/meson.inc
> > > index 8219d87c741..ae0091c051c 100644
> > > --- a/meta/recipes-devtools/meson/meson.inc
> > > +++ b/meta/recipes-devtools/meson/meson.inc
> > > @@ -14,14 +14,11 @@ SRC_URI = "
> > > https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> > > file://0001-python-module-do-not-manipulate-the-
> > > environment-when.patch \
> > > file://disable-rpath-handling.patch \
> > > file://cross-prop-default.patch \
> > > - file://0001-environment.py-detect-windows-also-if-the-
> > > system-str.patch \
> > > - file://0001-Cross-build-is-defined-by-the-existance-of-a-
> > > cross-f.patch \
> > > file://0001-mesonbuild-environment.py-check-environment-
> > > for-vari.patch \
> > > file://0001-modules-python.py-do-not-substitute-python-s-
> > > install.patch \
> > > - file://vala-cross-compile.patch \
> > > "
> > > -SRC_URI[sha256sum] =
> > > "23688f0fc90be623d98e80e1defeea92bbb7103bf9336a5f5b9865d36e892d76"
> > > -SRC_URI[md5sum] = "d46c4a8e3cfd27f90e2c6fe4a69e574b"
> > > +SRC_URI[sha256sum] =
> > > "d60f75f0dedcc4fd249dbc7519d6f3ce6df490033d276ef1cf27453ef4938d32"
> > > +SRC_URI[md5sum] = "7ea7772414dda8ae11072244bf7ba991"
> > >
> > > SRC_URI_append_class-native = " \
> > > file://0001-Make-CPU-family-warnings-fatal.patch \
> > > diff --git a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-
> > > defined-by-the-existance-of-a-cross-f.patch b/meta/recipes-
> > > devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-
> > > a-cross-f.patch
> > > deleted file mode 100644
> > > index a5dbb81b088..000
> > > --- a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-
> > > by-the-existance-of-a-cross-f.patch
> > > +++ /dev/null
> > > @@ -1,28 +0,0 @@
> > > -Upstream-Status: Backport
> > > -Signed-off-by: Ross Burton
> > > -
> > > -From
Re: [OE-core] [thud][PATCH] Revert "OpkgPM: use --add-ignore-recommends to process BAD_RECOMMENDATIONS"
On 10/17/19 3:01 PM, Denys Dmytriyenko wrote: > On Thu, Oct 17, 2019 at 12:21:11PM -0700, akuster808 wrote: >> On 10/17/19 11:42 AM, Denys Dmytriyenko wrote: >>> Thank you for this revert! I've been pulling my hair out past couple days >>> figuring out why BAD_RECOMMENDATIONS stopped working for us. This fixed it. >> >> What I find curious is that the offending commit has been in thud since >> July 29th and we are just now hearing about issues. > > Yeah, in our case we only noticed the issue when we started preparing the > latest release and found extra packages that weren't supposed to be there. Is there a bugzilla ticket tracking the issue? I added the --add-ignore-recommends flag to opkg, mainly to get BAD_RECOMMENDATIONS to work for OE. If that's not the case, then need to figure out what went wrong (the OE side or the opkg side) -- Cheers, Alejandro -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ncurses: fix CVE-2019-17594, CVE-2019-17595
Backport changes to tinfo/comp_hash.c, tinfo/parse_entry.c,
and progs/dump_entry.c from upstream to fix CVEs.
Signed-off-by: Trevor Gamblin
---
...selective-backport-of-20191012-patch.patch | 169 ++
.../ncurses/ncurses_6.1+20190803.bb | 1 +
2 files changed, 170 insertions(+)
create mode 100644
meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
diff --git
a/meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
b/meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
new file mode 100644
index 00..7870c4ba32
--- /dev/null
+++
b/meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
@@ -0,0 +1,169 @@
+From 064b77f173337aa790f1cec0d741bfbc61a33d31 Mon Sep 17 00:00:00 2001
+From: Trevor Gamblin
+Date: Fri, 18 Oct 2019 09:57:43 -0400
+Subject: [PATCH] ncurses: selective backport of 20191012 patch
+
+Upstream-Status: Backport
[https://salsa.debian.org/debian/ncurses/commit/243908b1e3d81]
+
+Contents of the upstream patch that are not applied to comp_hash.c,
+parse_entry.c, or dump_entry.c have been omitted.
+
+CVE: CVE-2019-17594
+CVE: CVE-2019-17595
+
+Signed-off-by: Trevor Gamblin
+
+---
+ ncurses/tinfo/comp_hash.c | 14 ++
+ ncurses/tinfo/parse_entry.c | 32
+ progs/dump_entry.c | 7 ---
+ 3 files changed, 30 insertions(+), 23 deletions(-)
+
+diff --git a/ncurses/tinfo/comp_hash.c b/ncurses/tinfo/comp_hash.c
+index 21f165ca..a62d38f9 100644
+--- a/ncurses/tinfo/comp_hash.c
b/ncurses/tinfo/comp_hash.c
+@@ -44,7 +44,7 @@
+ #include
+ #include
+
+-MODULE_ID("$Id: comp_hash.c,v 1.49 2019/03/10 00:06:48 tom Exp $")
++MODULE_ID("$Id: comp_hash.c,v 1.51 2019/10/12 16:32:13 tom Exp $")
+
+ /*
+ * Finds the entry for the given string in the hash table if present.
+@@ -63,7 +63,9 @@ _nc_find_entry(const char *string,
+
+ hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+
+ real_table = _nc_get_table(termcap);
+ ptr = real_table + data->table_data[hashvalue];
+@@ -96,7 +98,9 @@ _nc_find_type_entry(const char *string,
+ const HashData *data = _nc_get_hash_info(termcap);
+ int hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+ const struct name_table_entry *const table = _nc_get_table(termcap);
+
+ ptr = table + data->table_data[hashvalue];
+@@ -124,7 +128,9 @@ _nc_find_user_entry(const char *string)
+
+ hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+
+ real_table = _nc_get_userdefs_table();
+ ptr = real_table + data->table_data[hashvalue];
+diff --git a/ncurses/tinfo/parse_entry.c b/ncurses/tinfo/parse_entry.c
+index f8cca8b5..064376c5 100644
+--- a/ncurses/tinfo/parse_entry.c
b/ncurses/tinfo/parse_entry.c
+@@ -47,7 +47,7 @@
+ #include
+ #include
+
+-MODULE_ID("$Id: parse_entry.c,v 1.97 2019/08/03 23:10:38 tom Exp $")
++MODULE_ID("$Id: parse_entry.c,v 1.98 2019/10/12 00:50:31 tom Exp $")
+
+ #ifdef LINT
+ static short const parametrized[] =
+@@ -654,12 +654,12 @@ _nc_capcmp(const char *s, const char *t)
+ }
+
+ static void
+-append_acs0(string_desc * dst, int code, int src)
++append_acs0(string_desc * dst, int code, char *src, size_t off)
+ {
+-if (src != 0) {
++if (src != 0 && off < strlen(src)) {
+ char temp[3];
+ temp[0] = (char) code;
+- temp[1] = (char) src;
++ temp[1] = src[off];
+ temp[2] = 0;
+ _nc_safe_strcat(dst, temp);
+ }
+@@ -669,7 +669,7 @@ static void
+ append_acs(string_desc * dst, int code, char *src)
+ {
+ if (VALID_STRING(src) && strlen(src) == 1) {
+- append_acs0(dst, code, *src);
++ append_acs0(dst, code, src, 0);
+ }
+ }
+
+@@ -1038,17 +1038,17 @@ postprocess_terminfo(TERMTYPE2 *tp)
+ _nc_str_init(, buf2, sizeof(buf2));
+ _nc_safe_strcat(, acs_chars);
+
+- append_acs0(, 'l', box_chars_1[0]); /* ACS_ULCORNER */
+- append_acs0(, 'q', box_chars_1[1]); /* ACS_HLINE */
+- append_acs0(, 'k', box_chars_1[2]); /* ACS_URCORNER */
+- append_acs0(, 'x', box_chars_1[3]); /* ACS_VLINE */
+- append_acs0(, 'j', box_chars_1[4]); /* ACS_LRCORNER */
+- append_acs0(, 'm', box_chars_1[5]); /* ACS_LLCORNER */
+- append_acs0(, 'w', box_chars_1[6]); /* ACS_TTEE */
+- append_acs0(, 'u', box_chars_1[7]); /* ACS_RTEE */
+- append_acs0(, 'v', box_chars_1[8]); /* ACS_BTEE */
[OE-core] [zeus][PATCH] ncurses: fix CVE-2019-17594, CVE-2019-17595
Backport changes to tinfo/comp_hash.c, tinfo/parse_entry.c,
and progs/dump_entry.c from upstream to fix CVEs.
Signed-off-by: Trevor Gamblin
---
...selective-backport-of-20191012-patch.patch | 169 ++
.../ncurses/ncurses_6.1+20190803.bb | 1 +
2 files changed, 170 insertions(+)
create mode 100644
meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
diff --git
a/meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
b/meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
new file mode 100644
index 00..7870c4ba32
--- /dev/null
+++
b/meta/recipes-core/ncurses/files/0001-ncurses-selective-backport-of-20191012-patch.patch
@@ -0,0 +1,169 @@
+From 064b77f173337aa790f1cec0d741bfbc61a33d31 Mon Sep 17 00:00:00 2001
+From: Trevor Gamblin
+Date: Fri, 18 Oct 2019 09:57:43 -0400
+Subject: [PATCH] ncurses: selective backport of 20191012 patch
+
+Upstream-Status: Backport
[https://salsa.debian.org/debian/ncurses/commit/243908b1e3d81]
+
+Contents of the upstream patch that are not applied to comp_hash.c,
+parse_entry.c, or dump_entry.c have been omitted.
+
+CVE: CVE-2019-17594
+CVE: CVE-2019-17595
+
+Signed-off-by: Trevor Gamblin
+
+---
+ ncurses/tinfo/comp_hash.c | 14 ++
+ ncurses/tinfo/parse_entry.c | 32
+ progs/dump_entry.c | 7 ---
+ 3 files changed, 30 insertions(+), 23 deletions(-)
+
+diff --git a/ncurses/tinfo/comp_hash.c b/ncurses/tinfo/comp_hash.c
+index 21f165ca..a62d38f9 100644
+--- a/ncurses/tinfo/comp_hash.c
b/ncurses/tinfo/comp_hash.c
+@@ -44,7 +44,7 @@
+ #include
+ #include
+
+-MODULE_ID("$Id: comp_hash.c,v 1.49 2019/03/10 00:06:48 tom Exp $")
++MODULE_ID("$Id: comp_hash.c,v 1.51 2019/10/12 16:32:13 tom Exp $")
+
+ /*
+ * Finds the entry for the given string in the hash table if present.
+@@ -63,7 +63,9 @@ _nc_find_entry(const char *string,
+
+ hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+
+ real_table = _nc_get_table(termcap);
+ ptr = real_table + data->table_data[hashvalue];
+@@ -96,7 +98,9 @@ _nc_find_type_entry(const char *string,
+ const HashData *data = _nc_get_hash_info(termcap);
+ int hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+ const struct name_table_entry *const table = _nc_get_table(termcap);
+
+ ptr = table + data->table_data[hashvalue];
+@@ -124,7 +128,9 @@ _nc_find_user_entry(const char *string)
+
+ hashvalue = data->hash_of(string);
+
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++ && (unsigned) hashvalue < data->table_size
++ && data->table_data[hashvalue] >= 0) {
+
+ real_table = _nc_get_userdefs_table();
+ ptr = real_table + data->table_data[hashvalue];
+diff --git a/ncurses/tinfo/parse_entry.c b/ncurses/tinfo/parse_entry.c
+index f8cca8b5..064376c5 100644
+--- a/ncurses/tinfo/parse_entry.c
b/ncurses/tinfo/parse_entry.c
+@@ -47,7 +47,7 @@
+ #include
+ #include
+
+-MODULE_ID("$Id: parse_entry.c,v 1.97 2019/08/03 23:10:38 tom Exp $")
++MODULE_ID("$Id: parse_entry.c,v 1.98 2019/10/12 00:50:31 tom Exp $")
+
+ #ifdef LINT
+ static short const parametrized[] =
+@@ -654,12 +654,12 @@ _nc_capcmp(const char *s, const char *t)
+ }
+
+ static void
+-append_acs0(string_desc * dst, int code, int src)
++append_acs0(string_desc * dst, int code, char *src, size_t off)
+ {
+-if (src != 0) {
++if (src != 0 && off < strlen(src)) {
+ char temp[3];
+ temp[0] = (char) code;
+- temp[1] = (char) src;
++ temp[1] = src[off];
+ temp[2] = 0;
+ _nc_safe_strcat(dst, temp);
+ }
+@@ -669,7 +669,7 @@ static void
+ append_acs(string_desc * dst, int code, char *src)
+ {
+ if (VALID_STRING(src) && strlen(src) == 1) {
+- append_acs0(dst, code, *src);
++ append_acs0(dst, code, src, 0);
+ }
+ }
+
+@@ -1038,17 +1038,17 @@ postprocess_terminfo(TERMTYPE2 *tp)
+ _nc_str_init(, buf2, sizeof(buf2));
+ _nc_safe_strcat(, acs_chars);
+
+- append_acs0(, 'l', box_chars_1[0]); /* ACS_ULCORNER */
+- append_acs0(, 'q', box_chars_1[1]); /* ACS_HLINE */
+- append_acs0(, 'k', box_chars_1[2]); /* ACS_URCORNER */
+- append_acs0(, 'x', box_chars_1[3]); /* ACS_VLINE */
+- append_acs0(, 'j', box_chars_1[4]); /* ACS_LRCORNER */
+- append_acs0(, 'm', box_chars_1[5]); /* ACS_LLCORNER */
+- append_acs0(, 'w', box_chars_1[6]); /* ACS_TTEE */
+- append_acs0(, 'u', box_chars_1[7]); /* ACS_RTEE */
+- append_acs0(, 'v', box_chars_1[8]); /* ACS_BTEE */
Re: [OE-core] [PATCH] file: explicitly disable seccomp
On Fri, Oct 18, 2019 at 4:58 PM Ross Burton wrote:
> file will automatically enable seccomp if the seccomp headers are
> available, but
> the build will fail on Opensuse Tumbleweed because the include paths are
> wrong.
>
> Enabling seccomp is a bad idea because it interacts badly with pseudo
> (causing
> build failures), so explicitly and globally disable seccomp.
>
> Signed-off-by: Ross Burton
> ---
> meta/recipes-devtools/file/file_5.37.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/file/file_5.37.bb
> b/meta/recipes-devtools/file/file_5.37.bb
> index a840dbc012b..c53a120b840 100644
> --- a/meta/recipes-devtools/file/file_5.37.bb
> +++ b/meta/recipes-devtools/file/file_5.37.bb
> @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
>
> inherit autotools update-alternatives
>
> +EXTRA_OECONF += "--disable-libseccomp"
> +
On host it makes sense but how about for target recipe ? We do have
libseccomp support
Perhaps it’s best to disable it for native and native sdk alone ?
>
> ALTERNATIVE_${PN} = "file"
> ALTERNATIVE_LINK_NAME[file] = "${bindir}/file"
>
> --
> 2.20.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] file: explicitly disable seccomp
file will automatically enable seccomp if the seccomp headers are available, but
the build will fail on Opensuse Tumbleweed because the include paths are wrong.
Enabling seccomp is a bad idea because it interacts badly with pseudo (causing
build failures), so explicitly and globally disable seccomp.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/file/file_5.37.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/file/file_5.37.bb
b/meta/recipes-devtools/file/file_5.37.bb
index a840dbc012b..c53a120b840 100644
--- a/meta/recipes-devtools/file/file_5.37.bb
+++ b/meta/recipes-devtools/file/file_5.37.bb
@@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
inherit autotools update-alternatives
+EXTRA_OECONF += "--disable-libseccomp"
+
ALTERNATIVE_${PN} = "file"
ALTERNATIVE_LINK_NAME[file] = "${bindir}/file"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] wic/rawcopy: Support files in sub-directories
If the source file is located in a subdirectory of DEPLOY_DIR rawcopy will currently fail in sparse_copy function on open(dst_fname, 'wb'), as the parent directory for destination file does not exist. This patch helps to avoid that by recursively creating parent directories. Signed-off-by: Eugene Smirnov --- scripts/lib/wic/plugins/source/rawcopy.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/scripts/lib/wic/plugins/source/rawcopy.py b/scripts/lib/wic/plugins/source/rawcopy.py index df86d6729c..82970ce51b 100644 --- a/scripts/lib/wic/plugins/source/rawcopy.py +++ b/scripts/lib/wic/plugins/source/rawcopy.py @@ -59,6 +59,9 @@ class RawCopyPlugin(SourcePlugin): src = os.path.join(kernel_dir, source_params['file']) dst = os.path.join(cr_workdir, "%s.%s" % (source_params['file'], part.lineno)) +if not os.path.exists(os.path.dirname(dst)): +os.makedirs(os.path.dirname(dst)) + if 'skip' in source_params: sparse_copy(src, dst, skip=int(source_params['skip'])) else: -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] openssh: fix CVE-2019-16905
Backport a patch from upstream to fix CVE-2019-16905
https://github.com/openssh/openssh-portable/commit/a546b17bbaeb12beac4c9aeed56f74a42b18a93a
Signed-off-by: Hongxu Jia
---
...x-integer-overflow-in-XMSS-private-key-pa.patch | 40 ++
meta/recipes-connectivity/openssh/openssh_8.0p1.bb | 1 +
2 files changed, 41 insertions(+)
create mode 100644
meta/recipes-connectivity/openssh/openssh/0001-upstream-fix-integer-overflow-in-XMSS-private-key-pa.patch
diff --git
a/meta/recipes-connectivity/openssh/openssh/0001-upstream-fix-integer-overflow-in-XMSS-private-key-pa.patch
b/meta/recipes-connectivity/openssh/openssh/0001-upstream-fix-integer-overflow-in-XMSS-private-key-pa.patch
new file mode 100644
index 000..3265be3
--- /dev/null
+++
b/meta/recipes-connectivity/openssh/openssh/0001-upstream-fix-integer-overflow-in-XMSS-private-key-pa.patch
@@ -0,0 +1,40 @@
+From 2014fad3d28090b59d2f8a0971166c06e5fa6da6 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia
+Date: Fri, 18 Oct 2019 14:56:58 +0800
+Subject: [PATCH] upstream: fix integer overflow in XMSS private key parsing.
+
+Reported by Adam Zabrocki via SecuriTeam's SSH program.
+
+Note that this code is experimental and not compiled by default.
+
+ok markus@
+
+OpenBSD-Commit-ID: cd0361896d15e8a1bac495ac583ff065ffca2be1
+
+Signed-off-by: "d...@openbsd.org"
+
+Upstream-Status: Backport
[https://github.com/openssh/openssh-portable/commit/a546b17bbaeb12beac4c9aeed56f74a42b18a93a]
+CVE: CVE-2019-16905
+
+Signed-off-by: Hongxu Jia
+---
+ sshkey-xmss.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/sshkey-xmss.c b/sshkey-xmss.c
+index aaae702..c57681a 100644
+--- a/sshkey-xmss.c
b/sshkey-xmss.c
+@@ -977,7 +977,8 @@ sshkey_xmss_decrypt_state(const struct sshkey *k, struct
sshbuf *encoded,
+ goto out;
+ }
+ /* check that an appropriate amount of auth data is present */
+- if (sshbuf_len(encoded) < encrypted_len + authlen) {
++ if (sshbuf_len(encoded) < authlen ||
++ sshbuf_len(encoded) - authlen < encrypted_len) {
+ r = SSH_ERR_INVALID_FORMAT;
+ goto out;
+ }
+--
+2.7.4
+
diff --git a/meta/recipes-connectivity/openssh/openssh_8.0p1.bb
b/meta/recipes-connectivity/openssh/openssh_8.0p1.bb
index 01eaecd..2ffbc9a 100644
--- a/meta/recipes-connectivity/openssh/openssh_8.0p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_8.0p1.bb
@@ -24,6 +24,7 @@ SRC_URI =
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
file://sshd_check_keys \
file://add-test-support-for-busybox.patch \
+
file://0001-upstream-fix-integer-overflow-in-XMSS-private-key-pa.patch \
"
SRC_URI[md5sum] = "bf050f002fe510e1daecd39044e1122d"
SRC_URI[sha256sum] =
"bd943879e69498e8031eb6b7f44d08cdc37d59a7ab689aa0b437320c3481fd68"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
