Bug#923640: "ifupdown" 0.8.35 breaks DHCP and DNS resolving.

2019-03-26 Thread Ian Abel



Package: ifupdown
Version: 0.8.35
Followup-For: Bug #923640

Dear Maintainer,

  This bug is seemingly due to misguided single-stack DHCPv4 servers 
that are still
  found in the wild. If dhclient sents a client identifier at all, they 
will NAK
  and not respond. Hence the previous report of being able to obtain an 
IP address
  via a manual 'dhclient eth0', which will default to not using the 
'-i' option
  that is now the default in ifupdown (see #906894).

  On my installation I have confirmed the following (options setting
  pid files and leases files removed for brevity, they 
do not
  change anything):

  dhclient -4 -v -I works
  dhclient -4 -v -i -I fails with a DHCPNAK from the server
  dhclient -4 -v -I fails if 'send dhcp-client-identifier' is set in
  /etc/dhcp/dhclient.conf [a non-exhaustive search of possible
  identifiers ahs yet to find one that the server will accept].

  A possible solution is to add a configuration option for
  /etc/network/interfaces to enable/disable this on a per-interface
  basis. Or to be able to flag an interface as 'legacy v4' or similar
  and entirely disable v6 and related features.

  Severity has been flagged as important because this results in an
  unusable system silently across upgrade if you're on a network with
  such a server.

  Yours,

  Ian Abel

-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto enp0s31f6
iface enp0s31f6 inet dhcp

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 372 Jul 30  2018 openvpn

/etc/network/if-post-down.d:
total 0
lrwxrwxrwx 1 root root 23 Oct 10 04:17 avahi-daemon -> ../if-up.d/avahi-daemon

/etc/network/if-pre-up.d:
total 4
-rwxr-xr-x 1 root root 344 Jun 30  2016 ethtool

/etc/network/if-up.d:
total 12
-rwxr-xr-x 1 root root  484 Apr 27  2018 avahi-daemon
-rwxr-xr-x 1 root root 1685 Jun 30  2016 ethtool
-rwxr-xr-x 1 root root  385 Jul 30  2018 openvpn


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-8
ii  lsb-base  10.2019031300

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2

Versions of packages ifupdown suggests:
ii  ppp 2.4.7-2+4.1
pn  rdnssd  

-- no debconf information



Bug#396265: apache2: mod_proxy_ajp connection reuse bug

2006-10-30 Thread Ian Abel

Subject: apache2: mod_proxy_ajp connection reuse bug
Package: apache2
Version: 2.2.3-2
Severity: normal

*** Please type your report below this line ***

Vulnerable to bug 40310 in issues.apache.org BugZilla. Patch in apache 
bugzilla applies cleanly.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.12-xenU
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages apache2 depends on:
ii  apache2-mpm-worker2.0.55-4.1 high speed threaded model for Apac

apache2 recommends no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#336456: Bug not fixed in gnutls12

2005-11-11 Thread Ian Abel


Hi.

This bug is not fixed in gnutls12. The problem line is 
lib/gnutls_kx.c:531, the code assumes that if _gnutls_recv_handshake 
returns a negative number then the client didn't provide a certificate.
It then runs a gnutls_assert sets the errr to GNUTLS_E_NO_CERTIFICATE and 
propagates the error back to the caller of gnutls_handshake().


Despite the fact that _gnutls_recv_handshake returns GNUTLS_E_AGAIN if the 
socket is non-blocking.


Yours

Ian Abel


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]