[LEDE-DEV] [PATCH] libusb: Update to 1.0.22

2018-04-01 Thread Rosen Penev 
Switched download from SourceForge to GitHub. It seems the author migrated to 
that.

Also fixed the website URL as the SourceForge link is dead.

Replaced the $(fPIC) macro with PKG_ASLR_PIE. They're both functionally 
identital.

Compile tested on ar71xx and mvebu. Small size decrease on ar71xx: 30444 vs. 
30099 bytes.

Signed-off-by: Rosen Penev 
---
 package/libs/libusb/Makefile | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/package/libs/libusb/Makefile b/package/libs/libusb/Makefile
index 2d1d9c2b50..e9fe3fcec3 100644
--- a/package/libs/libusb/Makefile
+++ b/package/libs/libusb/Makefile
@@ -8,15 +8,16 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=libusb
-PKG_VERSION:=1.0.21
+PKG_VERSION:=1.0.22
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=@SF/$(PKG_NAME)
-PKG_HASH:=7dce9cce9a81194b7065ee912bcd55eeffebab694ea403ffb91b67db66b1824b
+PKG_SOURCE_URL:=https://github.com/libusb/libusb/releases/download/v$(PKG_VERSION)
+PKG_HASH:=75aeb9d59a4fdb800d329a545c2e6799f732362193b465ea198f2aa275518157
 
 PKG_INSTALL:=1
 PKG_BUILD_PARALLEL:=0
+PKG_ASLR_PIE:=1
 PKG_LICENSE:=LGPL-2.1
 
 PKG_MAINTAINER := Felix Fietkau 
@@ -28,7 +29,7 @@ define Package/libusb-1.0
   CATEGORY:=Libraries
   TITLE:=A library for accessing Linux USB devices
   DEPENDS:=+libpthread +librt
-  URL:=http://libusb.wiki.sourceforge.net/
+  URL:=http://libusb.info/
 endef
 
 define Package/libusb-1.0/description
@@ -36,7 +37,6 @@ define Package/libusb-1.0/description
   many different operating systems.
 endef
 
-TARGET_CFLAGS += $(FPIC)
 CONFIGURE_ARGS += \
--disable-udev \
--disable-log
-- 
2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] ncurses: Remove obsolete compile fixes

2018-04-01 Thread Rosen Penev 
It seems both issues (GCC5 and Musl) were fixed at some point. Thus, they can 
be dropped.

Did not bump version as there is no change in functionality or size.

Compile-tested on ar71xx and mvebu, both with musl.

Signed-off-by: Rosen Penev 
---
 .../ncurses/patches/102-ncurses-5.9-gcc-5.patch| 44 --
 .../ncurses/patches/200-fix_missing_include.patch  | 14 ---
 2 files changed, 58 deletions(-)
 delete mode 100644 package/libs/ncurses/patches/102-ncurses-5.9-gcc-5.patch
 delete mode 100644 package/libs/ncurses/patches/200-fix_missing_include.patch

diff --git a/package/libs/ncurses/patches/102-ncurses-5.9-gcc-5.patch 
b/package/libs/ncurses/patches/102-ncurses-5.9-gcc-5.patch
deleted file mode 100644
index b84fcb965c..00
--- a/package/libs/ncurses/patches/102-ncurses-5.9-gcc-5.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-https://bugs.gentoo.org/545114
-
-extracted from the upstream change (which had many unrelated commits in one)
-
-From 97bb4678dc03e753290b39bbff30ba2825df9517 Mon Sep 17 00:00:00 2001
-From: "Thomas E. Dickey" 
-Date: Sun, 7 Dec 2014 03:10:09 +
-Subject: [PATCH] ncurses 5.9 - patch 20141206
-
-+ modify MKlib_gen.sh to work around change in development version of
-  gcc introduced here:
- https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02185.html
- https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00236.html
-  (reports by Marcus Shawcroft, Maohui Lei).
-
 a/ncurses/base/MKlib_gen.sh
-+++ b/ncurses/base/MKlib_gen.sh
-@@ -505,11 +505,22 @@ sed -n -f $ED1 \
-   -e 's/gen_$//' \
-   -e 's/  / /g' >>$TMP
- 
-+cat >$ED1  $ED2
-+cat $ED2 >$TMP
-+
- $preprocessor $TMP 2>/dev/null \
--| sed \
--  -e 's/  / /g' \
--  -e 's/^ //' \
--  -e 's/_Bool/NCURSES_BOOL/g' \
-+| sed -f $ED1 \
- | $AWK -f $AW2 \
- | sed -f $ED3 \
- | sed \
diff --git a/package/libs/ncurses/patches/200-fix_missing_include.patch 
b/package/libs/ncurses/patches/200-fix_missing_include.patch
deleted file mode 100644
index 4616c4fb70..00
--- a/package/libs/ncurses/patches/200-fix_missing_include.patch
+++ /dev/null
@@ -1,14 +0,0 @@
 a/ncurses/curses.priv.h
-+++ b/ncurses/curses.priv.h
-@@ -55,6 +55,11 @@ extern "C" {
- 
- #include 
- 
-+#if NEED_WCHAR_H
-+#include 
-+#include 
-+#endif
-+
- #if USE_RCS_IDS
- #define MODULE_ID(id) static const char Ident[] = id;
- #else
-- 
2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] kernel version status

2018-04-01 Thread Alexandru Ardelean 
On Sun, Apr 1, 2018 at 5:48 PM, Hauke Mehrtens  wrote:
> The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
> on the target. All targets that are *not* on either kernel 4.9 or 4.14
> will not be included in the next release.
>
> I did some overview of the kernel version some months ago here:
> http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
> http://lists.infradead.org/pipermail/lede-dev/2018-February/011308.html
>
> Here is the current situation as of today:
>
>
> The following targets are on kernel 4.14 and are fine:
> * apm821xx
> * archs38
> * armvirt
> * bcm53xx
> * cns3xxx
> * imx6
> * ipq40xx
> * kirkwood
> * malta
> * mediatek
> * mvebu
> * mxs
> * octeon
> * octeontx
> * pistachio
> * sunxi
> * x86
>
>
> The following targets are on kernel 4.9 and are fine:
> * ar71xx
> * ar7
> * arc770
> * at91
> There are some patches for kernel 4.14 on the mailing list,
> but it looks like nobody with the hardware wants to take care
> of them.
> * ath25
> * brcm2708
> * brcm47xx
> There is a pull request with kernel 4.14 patches on github, we
> will probably stay with kernel 4.9 for the next release.
> * brcm63xx
> patches for 4.14 are available in master
> * ipq806x
> * ixp4xx
> * lantiq
> patches for 4.14 are available in master, we will probably stay
> with kernel 4.9 for the next release.
> * layerscape
> * mpc85xx
> * omap
> There is a pull request with kernel 4.14 patches on github.
> * orion
> * ramips
> patches for 4.14 are available in master, we will probably stay
> with kernel 4.9 for the next release.
> * rb532
> * uml
>
>
> The following targets are on kernel 4.4 and will probably not be
> included in the next release:
> * gemini
> There are patches for kernel 4.14 on the mailing list, we will
> probably get them in before the release and ship this with 4.14
> * oxnas
> * zynq

Will these targets be dropped/removed from the tree ?
I'd be interested in upgrading the zynq target.
And I also have a partial work/effort in a repo, but not enough time
to test + push it.

I don't need this to be part of the 18.xx release, just curios if it
will still be in the tree, and then I can alloc time for it at a later
time.

Thanks
Alex

>
> The following targets are on kernel 3.18 and will probably not be
> included in the next release:
> * adm5120
> * adm8668
> * au1000
> * mcs814x
> * ppc40x
> * ppc44x
> * xburst
>
>
> This target is on kernel 4.1 (WTF):
> * omap24xx
>
>
> All the targets which are not on kernel 4.9 or 4.14 will probably not be
> included in the next release, I also haven't seen any activity for any
> of them expected the gemini target to get support for more recent kernel
> versions, if you need them please take care now.
>
> I am fine with the current status and do not see this as a blocker for
> the next release, all important targets are on either 4.9 or 4.14, if
> someone wants to see his target on a more recent version we are still
> open for patches.
>
> Hauke
> ___
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] DNS split horizon *without* dnsmasq

2018-04-01 Thread Eric Luehrsen 

On 03/31/2018 06:03 PM, Philip Prindeville wrote:



On Mar 31, 2018, at 12:57 PM, Eric Luehrsen  wrote:

It seems I have static-stub wrong for its purpose. dhcpd and bind do work 
together. To accomplish this, the bind instance needs to be master for the 
domain zone and ptr zone where DHCP records will be entered. This master zone 
needs to permit remote updates, preferably with a secure key. dhcpd needs to be 
configure to dynamically update DNS through binds remote


Rather than using a secure key, what about listening on localhost: and 
allowing updates only from there?  Bind has reasonable ACL capabilities…

Formatting below got a little buggered up.

What are we looking at?

Thanks,

-Philip




Local host ACL would work I think. The encryption key is just part of 
the reference manual. And cleaning up the noise


dhcpd incomplete reference conf to get started

```
ddns-update-style standard;
ddns-rev-domainname "in-addr.arpa.";

zone openwrt.lan. {
   # where to send updates for hostid.openwrt.lan
   primary 127.0.0.1; };

zone 1.168.192.in-addr.arpa. {
   primary 127.0.0.1; };

```

bind incomplete reference conf to get started
https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies

```
zone "openwrt.lan" {
  type master;
  file "/var/lib/bind/db.openwrt.lan";
  update-policy {
    # you can restrict record types, rather than "any"
    grant [key-name] zonesub any;
  };
};

zone "1.168.192.in-addr.arpa" {
  type master;
  file "/var/lib/bind/db.1.168.192.in-addr.arpa";
  update-policy {
    grant [key-name] zonesub any;
  };
};
```

optional key file for both

```
key "key-name" {
  algorithm [hash];
  secret "passphrase"; };
```


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.05 status

2018-04-01 Thread Hauke Mehrtens 
On 02/16/2018 01:46 PM, John Crispin wrote:
> Hi,
> 
> whats on the critical todo list for the upcoming release ? i still have
> a few minor things that I'll be adding shortly, apart from that I am
> currently not aware of any huge problems. the release will be a mix
> between 4.9 and 4.14 afaik !?

Hi,

For me the current status of master looks good.

1. All important targets are either on kernel 4.9 or 4.14, the rest will
probably get removed.

2. We did the move to GCC 7.3 and binutils 2.29.1 and this went pretty
well, I am only aware of one problem with perl on the apm821xx (powerpc)
target https://bugs.openwrt.org/index.php?do=details_id=1464 which
is related to the GCC update and which is not fixed.

3. The update to busybox 1.28.2 is still open, but this was already
tested by many people. I am fine with merging it if it will be done soon.

There are probably a lot of small things but nothing big any more in my
opinion, I do not see any release blockers for now and would like to
start with the 18.X release soon.

Are there any problems still know which would block a release?

I would propose this timeline:
1. Branch of openwrt-18.05 at 7. April
2. Create openwrt-18.05-rc1 release on 14. April
3. Create openwrt-18.05-rc2 release on 28. April
4. Create openwrt-18.05 final release on 12. Mai
If we find more problems this will be extended.

@Jow Do you have time to prepare the build bots for this?
Do others have some time in April to manage this release and take care
about bug reports?
I haven't done a release yet and probably need some help.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] kernel version status

2018-04-01 Thread Stijn Segers 
Hauke Mehrtens  schreef op 1 april 2018 16:48:52 CEST:
>The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
>on the target. All targets that are *not* on either kernel 4.9 or 4.14
>will not be included in the next release.
>
>I did some overview of the kernel version some months ago here:
>http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
>http://lists.infradead.org/pipermail/lede-dev/2018-February/011308.html
>
>Here is the current situation as of today:
>
>
>The following targets are on kernel 4.14 and are fine:
>* apm821xx
>* archs38
>* armvirt
>* bcm53xx
>* cns3xxx
>* imx6
>* ipq40xx
>* kirkwood
>* malta
>* mediatek
>* mvebu
>* mxs
>* octeon
>* octeontx
>* pistachio
>* sunxi
>* x86
>
>
>The following targets are on kernel 4.9 and are fine:
>* ar71xx
>* ar7
>* arc770
>* at91
>   There are some patches for kernel 4.14 on the mailing list,
>   but it looks like nobody with the hardware wants to take care
>   of them.
>* ath25
>* brcm2708
>* brcm47xx
>   There is a pull request with kernel 4.14 patches on github, we
>   will probably stay with kernel 4.9 for the next release.
>* brcm63xx
>   patches for 4.14 are available in master
>* ipq806x
>* ixp4xx
>* lantiq
>   patches for 4.14 are available in master, we will probably stay
>   with kernel 4.9 for the next release.
>* layerscape
>* mpc85xx
>* omap
>   There is a pull request with kernel 4.14 patches on github.
>* orion
>* ramips
>   patches for 4.14 are available in master, we will probably stay

John, are there any blockers preventing a move to 4.14? Been running it since 
Felix pushed support; haven't experienced any issues.

Stijn

>   with kernel 4.9 for the next release.
>* rb532
>* uml
>
>
>The following targets are on kernel 4.4 and will probably not be
>included in the next release:
>* gemini
>   There are patches for kernel 4.14 on the mailing list, we will
>   probably get them in before the release and ship this with 4.14
>* oxnas
>* zynq
>
>The following targets are on kernel 3.18 and will probably not be
>included in the next release:
>* adm5120
>* adm8668
>* au1000
>* mcs814x
>* ppc40x
>* ppc44x
>* xburst
>
>
>This target is on kernel 4.1 (WTF):
>* omap24xx
>
>
>All the targets which are not on kernel 4.9 or 4.14 will probably not
>be
>included in the next release, I also haven't seen any activity for any
>of them expected the gemini target to get support for more recent
>kernel
>versions, if you need them please take care now.
>
>I am fine with the current status and do not see this as a blocker for
>the next release, all important targets are on either 4.9 or 4.14, if
>someone wants to see his target on a more recent version we are still
>open for patches.
>
>Hauke
>
>___
>Lede-dev mailing list
>Lede-dev@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] kernel version status

2018-04-01 Thread Hauke Mehrtens 
The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.

I did some overview of the kernel version some months ago here:
http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html
http://lists.infradead.org/pipermail/lede-dev/2018-February/011308.html

Here is the current situation as of today:


The following targets are on kernel 4.14 and are fine:
* apm821xx
* archs38
* armvirt
* bcm53xx
* cns3xxx
* imx6
* ipq40xx
* kirkwood
* malta
* mediatek
* mvebu
* mxs
* octeon
* octeontx
* pistachio
* sunxi
* x86


The following targets are on kernel 4.9 and are fine:
* ar71xx
* ar7
* arc770
* at91
There are some patches for kernel 4.14 on the mailing list,
but it looks like nobody with the hardware wants to take care
of them.
* ath25
* brcm2708
* brcm47xx
There is a pull request with kernel 4.14 patches on github, we
will probably stay with kernel 4.9 for the next release.
* brcm63xx
patches for 4.14 are available in master
* ipq806x
* ixp4xx
* lantiq
patches for 4.14 are available in master, we will probably stay
with kernel 4.9 for the next release.
* layerscape
* mpc85xx
* omap
There is a pull request with kernel 4.14 patches on github.
* orion
* ramips
patches for 4.14 are available in master, we will probably stay
with kernel 4.9 for the next release.
* rb532
* uml


The following targets are on kernel 4.4 and will probably not be
included in the next release:
* gemini
There are patches for kernel 4.14 on the mailing list, we will
probably get them in before the release and ship this with 4.14
* oxnas
* zynq

The following targets are on kernel 3.18 and will probably not be
included in the next release:
* adm5120
* adm8668
* au1000
* mcs814x
* ppc40x
* ppc44x
* xburst


This target is on kernel 4.1 (WTF):
* omap24xx


All the targets which are not on kernel 4.9 or 4.14 will probably not be
included in the next release, I also haven't seen any activity for any
of them expected the gemini target to get support for more recent kernel
versions, if you need them please take care now.

I am fine with the current status and do not see this as a blocker for
the next release, all important targets are on either 4.9 or 4.14, if
someone wants to see his target on a more recent version we are still
open for patches.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] uqmi: Fix for big endian arch

2018-04-01 Thread Oskari Lemmela 
leXX_to_cpu function messes up get_next value in big endian arch.

Signed-off-by: Oskari Lemmelä 
---
 data/gen-code.pl | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/data/gen-code.pl b/data/gen-code.pl
index f45d28a..cf46b67 100755
--- a/data/gen-code.pl
+++ b/data/gen-code.pl
@@ -13,12 +13,12 @@ my $varsize_field;
 my %tlv_get = (
gint8 => "*(int8_t *) get_next(1)",
guint8 => "*(uint8_t *) get_next(1)",
-   gint16 => "le16_to_cpu(*(uint16_t *) get_next(2))",
-   guint16 => "le16_to_cpu(*(uint16_t *) get_next(2))",
-   gint32 => "le32_to_cpu(*(uint32_t *) get_next(4))",
-   guint32 => "le32_to_cpu(*(uint32_t *) get_next(4))",
-   gint64 => "le64_to_cpu(*(uint64_t *) get_next(8))",
-   guint64 => "le64_to_cpu(*(uint64_t *) get_next(8))",
+   gint16 => "({ int16_t value = *(int16_t *) get_next(2); int16_t _val = 
le16_to_cpu(value); _val;})",
+   guint16 => "({ uint16_t value = *(uint16_t *) get_next(2); uint16_t 
_val = le16_to_cpu(value); _val;})",
+   gint32 => "({ int32_t value = *(int32_t *) get_next(4); int32_t _val = 
le32_to_cpu(value); _val;})",
+   guint32 => "({ uint32_t value = *(uint32_t *) get_next(4); uint32_t 
_val = le32_to_cpu(value); _val;})",
+   gint64 => "({ int64_t value = *(int64_t *) get_next(8); int64_t _val = 
le64_to_cpu(value); _val;})",
+   guint64 => "({ uint64_t value = *(uint64_t *) get_next(8); uint64_t 
_val = le64_to_cpu(value); _val;})",
gfloat => "({ uint32_t data = le32_to_cpu(*(uint32_t *) get_next(4)); 
float _val; memcpy(&_val, , sizeof(_val)); _val; })"
 );
 
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] samba36: fix some security problems

2018-04-01 Thread Hauke Mehrtens 
This Adds fixes for the following security problems based on debians patches:
CVE-2016-2125: Unconditional privilege delegation to Kerberos servers in 
trusted realms
CVE-2017-12163: Server memory information leak over SMB1
CVE-2017-12150: SMB1/2/3 connections may not require signing where they should
CVE-2018-1050: Denial of Service Attack on external print server.

Signed-off-by: Hauke Mehrtens 
---
 package/network/services/samba36/Makefile  |   2 +-
 .../samba36/patches/028-CVE-2016-2125-v3.6.patch   |  59 +
 ...494-v3-6.patch => 029-CVE-2017-7494-v3-6.patch} |   0
 ...7-15275.patch => 030-CVE-2017-15275-v3.6.patch} |   0
 .../samba36/patches/031-CVE-2017-12163-v3.6.patch  | 136 +
 .../samba36/patches/032-CVE-2017-12150-v3.6.patch  |  75 
 .../samba36/patches/032-CVE-2018-1050-v3-6.patch   |  49 
 .../patches/200-remove_printer_support.patch   |   4 +-
 8 files changed, 322 insertions(+), 3 deletions(-)
 create mode 100644 
package/network/services/samba36/patches/028-CVE-2016-2125-v3.6.patch
 rename package/network/services/samba36/patches/{028-CVE-2017-7494-v3-6.patch 
=> 029-CVE-2017-7494-v3-6.patch} (100%)
 rename package/network/services/samba36/patches/{029-CVE-2017-15275.patch => 
030-CVE-2017-15275-v3.6.patch} (100%)
 create mode 100644 
package/network/services/samba36/patches/031-CVE-2017-12163-v3.6.patch
 create mode 100644 
package/network/services/samba36/patches/032-CVE-2017-12150-v3.6.patch
 create mode 100644 
package/network/services/samba36/patches/032-CVE-2018-1050-v3-6.patch

diff --git a/package/network/services/samba36/Makefile 
b/package/network/services/samba36/Makefile
index 55e1428d49..30e26195ff 100644
--- a/package/network/services/samba36/Makefile
+++ b/package/network/services/samba36/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=samba
 PKG_VERSION:=3.6.25
-PKG_RELEASE:=9
+PKG_RELEASE:=10
 
 PKG_SOURCE_URL:=https://download.samba.org/pub/samba \
https://download.samba.org/pub/samba/stable
diff --git 
a/package/network/services/samba36/patches/028-CVE-2016-2125-v3.6.patch 
b/package/network/services/samba36/patches/028-CVE-2016-2125-v3.6.patch
new file mode 100644
index 00..8e174f0e7b
--- /dev/null
+++ b/package/network/services/samba36/patches/028-CVE-2016-2125-v3.6.patch
@@ -0,0 +1,59 @@
+From: =?utf-8?q?Guido_G=C3=BCnther?= 
+Date: Wed, 28 Dec 2016 19:21:49 +0100
+Subject: security-CVE-2016-2125: Don't pass GSS_C_DELEG_FLAG by default
+
+This is a backport of upstream commits
+
+   b1a056f77e793efc45df34ab7bf78fbec1bf8a59
+   b83897ae49fdee1fda73c10c7fe73362bfaba690 (code not used in wheezy)
+   3106964a640ddf6a3c08c634ff586a814f94dff8 (code not used in wheezy)
+---
+ source3/librpc/crypto/gse.c | 1 -
+ source3/libsmb/clifsinfo.c  | 2 +-
+ source4/auth/gensec/gensec_gssapi.c | 2 +-
+ source4/scripting/bin/nsupdate-gss  | 2 +-
+ 4 files changed, 3 insertions(+), 4 deletions(-)
+
+--- a/source3/librpc/crypto/gse.c
 b/source3/librpc/crypto/gse.c
+@@ -162,7 +162,6 @@ static NTSTATUS gse_context_init(TALLOC_
+   memcpy(_ctx->gss_mech, gss_mech_krb5, sizeof(gss_OID_desc));
+ 
+   gse_ctx->gss_c_flags = GSS_C_MUTUAL_FLAG |
+-  GSS_C_DELEG_FLAG |
+   GSS_C_DELEG_POLICY_FLAG |
+   GSS_C_REPLAY_FLAG |
+   GSS_C_SEQUENCE_FLAG;
+--- a/source3/libsmb/clifsinfo.c
 b/source3/libsmb/clifsinfo.c
+@@ -726,7 +726,7 @@ static NTSTATUS make_cli_gss_blob(TALLOC
+   >s.gss_state->gss_ctx,
+   srv_name,
+   GSS_C_NO_OID, /* default OID. */
+-  GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | 
GSS_C_SEQUENCE_FLAG | GSS_C_DELEG_FLAG,
++  GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | 
GSS_C_SEQUENCE_FLAG | GSS_C_DELEG_POLICY_FLAG,
+   GSS_C_INDEFINITE,   /* requested ticket 
lifetime. */
+   NULL,   /* no channel bindings */
+   p_tok_in,
+--- a/source4/auth/gensec/gensec_gssapi.c
 b/source4/auth/gensec/gensec_gssapi.c
+@@ -172,7 +172,7 @@ static NTSTATUS gensec_gssapi_start(stru
+   if (gensec_setting_bool(gensec_security->settings, "gensec_gssapi", 
"mutual", true)) {
+   gensec_gssapi_state->want_flags |= GSS_C_MUTUAL_FLAG;
+   }
+-  if (gensec_setting_bool(gensec_security->settings, "gensec_gssapi", 
"delegation", true)) {
++  if (gensec_setting_bool(gensec_security->settings, "gensec_gssapi", 
"delegation", false)) {
+   gensec_gssapi_state->want_flags |= GSS_C_DELEG_FLAG;
+   }
+   if (gensec_setting_bool(gensec_security->settings, "gensec_gssapi", 
"replay", true)) {
+--- a/source4/scripting/bin/nsupdate-gss
 b/source4/scripting/bin/nsupdate-gss