Re: Bug#737658: some notes on util-linux takeover of eject

[Samuel Thibault]

Hello,

Chris Hofstaedtler, le dim. 03 mai 2020 23:31:23 +0200, a ecrit:
> * Cyril Brulebois :
> > While non-Linux issues aren't usually a blocker, I wouldn't welcome a
> > gratuitous breakage there. I'll let porters comment first.
> 
> We didn't hear anything from porters since 2017.

I actually hadn't noticed the mail, since both debian-boot and
debian-hurd mails fall into the same Debian mbox on my computer, and the
title wasn't enough to catch my eye.

Michael Biebl wrote:
> I noticed that eject in util-linux currently linux only.

Concerning hurd-i386 that's not a problem, we have never had an eject
package.

Samuel

Re: Bug#737658: some notes on util-linux takeover of eject

[Cyril Brulebois]

Hi,

Chris Hofstaedtler  (2020-05-03):
> * Cyril Brulebois :
> > Michael Biebl  (2017-10-24):
>  
> > > But there is one complication: I noticed that eject in util-linux
> > > currently linux only.
> > > 
> > > If we made the udeb linux-any, how would this affect the installer?
> > 
> > It might mean a regression on kfreebsd-* (I don't see an eject-udeb binary
> > on hurd). I'm adding debian-bsd@ and debian-hurd@ in copy.
> > 
> > > KiBi, is this a blocker in your opinion?
> > 
> > While non-Linux issues aren't usually a blocker, I wouldn't welcome a
> > gratuitous breakage there. I'll let porters comment first.
> 
> We didn't hear anything from porters since 2017.
> 
> Would it be a good or a bad time to do the udeb changes soon?

Feel free to go ahead.

(I'd want to see #956612 addressed before the next alpha release, and
I don't know when it's going to happen; as a consequence, I don't have
any specific schedule that could be disrupted by this change.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#737658: some notes on util-linux takeover of eject

[Chris Hofstaedtler]

Hi,

* Cyril Brulebois :
> Michael Biebl  (2017-10-24):
 
> > But there is one complication: I noticed that eject in util-linux
> > currently linux only.
> > 
> > If we made the udeb linux-any, how would this affect the installer?
> 
> It might mean a regression on kfreebsd-* (I don't see an eject-udeb binary
> on hurd). I'm adding debian-bsd@ and debian-hurd@ in copy.
> 
> > KiBi, is this a blocker in your opinion?
> 
> While non-Linux issues aren't usually a blocker, I wouldn't welcome a
> gratuitous breakage there. I'll let porters comment first.

We didn't hear anything from porters since 2017.

Would it be a good or a bad time to do the udeb changes soon?

Chris

Re: Bug#954838: buster-pu: package wpa/2:2.7+git20190128+0c1e29f-6+deb10u2

[Cyril Brulebois]

Adam D. Barratt  (2020-05-01):
> On Sat, 2020-04-25 at 20:17 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed d-i
> > 
> > On Tue, 2020-03-24 at 11:33 +0100, Andrej Shadura wrote:
> > > I’m proposing to upload a couple of upstream patches improving Wi-
> > > Fi
> > > connectivity in some cases especially on certain hardware.
> > > 
> > > For two of them, the relevant issues are #942164 and LP: #1867908.
> > > 
> > 
> > I'd be OK with that, but as wpa builds a debdiff this will need a
> > KiBi-ack. CCing and tagging accordingly.
> > 
> 
> Given that the window for getting fixes into 10.4 closes during this
> weekend, feel free to upload and we'll hold the package in stable-new
> for KiBi's review and testing.

Less thorough testing than other packages: I've limited my tests to
building a netboot-gtk image including the updated wpasupplicant udeb,
plus iwlwifi firmware (see [1]), and made sure a ThinkPad would connect
to the local WEP-based (no comments) network, download remaining udebs,
and get me to the partman screen (but I stopped there, wasn't planning
on actually reinstalling that machine).

 1. 
https://salsa.debian.org/installer-team/debian-installer/-/commit/94a2eb22b8233a01346b911ebcd2438edfc077a7

No obvious issues spotted, please go ahead.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#956216: buster-pu: package systemd/241-7~deb10u3

[Cyril Brulebois]

Adam D. Barratt  (2020-04-27):
> On Mon, 2020-04-27 at 19:17 +0200, Michael Biebl wrote:
> > Am 25.04.20 um 21:41 schrieb Adam D. Barratt:
> > > On Wed, 2020-04-08 at 16:11 +0200, Michael Biebl wrote:
> > > I'd be OK with that, but this will need a KiBi-ack, so CCing and
> > > tagging accordingly.
> > 
> > After talking to KiBi on IRC, we decided to include the fix for
> > #958397
> > as well. I kept the changes minimal and only included 60-rules in
> > udev-udeb and the initramfs.
> > 
> For the record, I'm OK with that from the SRM side.

Tests look good, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#887656: Non-obvious way to set static IPv4 address

[Holger Wansing]

Hi Peter,

Peter Roozemaal  wrote:
> I also ran into this issue with both the bullseye and buster installer.
> May I suggest an automatic fallback to manual configuration after DHCP
> failure?

Your suggestion (as I understand it) describes a different situation as the one 
in the original bugreport:

You suggested to fall back to manual configuration if DHCP fails. This is
indeed implemented like this already.

This bugreport is about using manual configuration even if DHCP succeeds!


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Bug#947442: buster-pu: package pango1.0/1.42.4-8~deb10u1

[Cyril Brulebois]

Adam D. Barratt  (2020-04-25):
> On Thu, 2019-12-26 at 21:43 +, Simon McVittie wrote:
> > We've been asked to fix a crash bug (#898960) in buster. Would you
> > be willing to consider a direct backport of 1.42.4-8 when it has had
> > some more time in unstable? In addition to a simple crash fix, it
> > has some improvements to the autopkgtest (which do not affect binary
> > packages). Diff below.
> > 
> > Or I could drop the autopkgtest changes and do a 1.42.4-7~deb10u2 or
> > something with just the crash fix, if preferred.
> 
> Sorry for the delay in replying. I'd be happy with the diff as
> presented, thanks.
> 
> > Either way this will need a d-i ack - the graphical installer uses
> > Pango, via GTK 2.
> > 
> 
> CCing for that.

Tests look good, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#958489: buster-pu: package fuse/2.9.9-1+deb10u1

[Cyril Brulebois]

Adam D. Barratt  (2020-04-26):
> Similarly to fuse3, this wants a KiBi-ack for completeness.

No objections, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#958490: buster-pu: package fuse3/3.4.1-1+deb10u1

[Cyril Brulebois]

Hi,

Adam D. Barratt  (2020-04-26):
> I missed (again) that the package generates a udeb. I don't think d-i
> actually uses it, but it should have a KiBi-ack for completeness. (A
> statement that fuse is OK to update in general would also work if
> that's easier.)

Looking at unstable, checking the only vague recollection I had
regarding FUSE: d-i uses ntfs-3g-udeb which depends on: fuse-udeb;
the latter is built by src:fuse and not src:fuse3. And I see no
reverse dependencies for libfuse3-3-udeb (built by src:fuse3).

So you seem to be absolutely correct, hence no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Completely switch graphical installer to fonts-noto?

[Cyril Brulebois]

Hi,

Finally getting back to this slightly old thread…

Holger Wansing  (2020-04-13):
> Cyril Brulebois  wrote:
> > I'm not sure there's actually “no point”. A possible fontconfig
> > issue could be hindering your tests regarding that switch…

So in the end it wasn't a fontconfig issue, but a pango one instead, see
my reply:

  https://bugs.debian.org/956612#10

> I fail to understand the correlations of all this, apparently.
> 
> In this case, we should - at a minimum - postpone the fonts-noto
> switch for a later alpha?

If we're going to ask people to compare how fonts look, we should better
make sure the rendering is correct. Otherwise we're asking them to
compare apples and oranges, and that seems to be a huge waste of time.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Bug#956612: libpango-1.0-0: broken kerning since 1.44

[Cyril Brulebois]

Hey,

Tomas Janousek  (2020-04-13):
> Package: libpango-1.0-0
> Version: 1.44.7-3
> Severity: important
> Tags: upstream
> 
> Since yesterday's apt full-upgrade of testing, font rendering in Gtk
> applications is very bad, kerning is broken, text is wider than
> necessary, it's very very unpleasant, I'd even say downright unuable
> without downgrading.
> 
> What I'm seeing is exactly this:
> https://gitlab.gnome.org/GNOME/pango/issues/404#note_712911
> https://gitlab.gnome.org/GNOME/pango/issues/404#note_676284
> https://github.com/harfbuzz/harfbuzz/issues/1892#issuecomment-552877664
> so I won't include additional screenshots.
> 
> I'm not sure what should Debian do provided upstream seems a bit
> dead... But breaking font rendering in Gtk apps across all Debian
> installations doesn't seem like a very good outcome either. :-(
> 
> Any ideas?
> 
> If anyone else is experiencing this, my workaround:
> 
> /etc/apt/sources.list:
> deb http://snapshot.debian.org/archive/debian/20200401T00Z/ testing main 
> contrib non-free
> 
> /etc/apt/preferences:
> Package: *pango*:*
> Pin: origin "snapshot.debian.org"
> Pin-Priority: 1100

I can confirm this in the Debian Installer as well (spotted early April
but only debugged right now).

Getting a little back in time and comparing what unstable used to be at
20200401T154401Z and at 20200405T084040Z, I'm seeing these changes in
the list of udebs used to build the netboot-gtk image:

-libcrypt1-udeb_1%3a4.4.15-1_amd64.udeb
+libcrypt1-udeb_1%3a4.4.16-1_amd64.udeb
-libdrm2-udeb_2.4.100-4_amd64.udeb
+libdrm2-udeb_2.4.101-1_amd64.udeb
-libpango1.0-udeb_1.42.4-8_amd64.udeb
+libpango1.0-udeb_1.44.7-3_amd64.udeb
-libudev1-udeb_245.2-1_amd64.udeb
+libudev1-udeb_245.4-2_amd64.udeb
-udev-udeb_245.2-1_amd64.udeb
+udev-udeb_245.4-2_amd64.udeb

Compare attached 1/2 screenshots to see the regression.

To make sure the pango update was responsible, I deb-reversion'ed its
udeb (taking the old udeb, faking a higher version so that it would be
preferred to the new udeb), and rebuilt the installer with unstable
from 20200405T084040Z, and I can confirm the regression disappears
(see 2+revert screenshot).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#887656: Non-obvious way to set static IPv4 address

[Peter Roozemaal]

I also ran into this issue with both the bullseye and buster installer.
May I suggest an automatic fallback to manual configuration after DHCP
failure?

Bug#959668: os-prober: translated auto-added items in other installs are not recognized as such

[Benno Schulenberg]

Package: os-prober
Version: 1.74ubuntu1
Severity: normal
Tags: patch l10n

When the hard disk contains multiple partitions, each with a Debian-based
distro (in my case: Xubuntu, Elementary, MX Linux, and Linux Mint) and each
of these distros is localized, then updating each system in turn results in
the grub.cfg file of each system getting larger and larger with each upgrade.

The cause is that the 40grub2 script does not recognize the automatically
added menu references to the other distros because the relevant grep command
checks for the word "on".  And in translations, this word will be different.

Attached patch fixes the problem.

The issue has also been reported to Ubuntu:
  https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1176652


Versions of packages os-prober depends on:
ii  dmsetup  2:1.02.145-4.1ubuntu3.18.04.2
ii  grub-common  2.02-2ubuntu8.15
ii  libc62.27-3ubuntu1
From 242992a278fc67cab3e0ce6586da75fa697780a0 Mon Sep 17 00:00:00 2001
From: Benno Schulenberg 
Date: Sun, 3 May 2020 14:11:03 +0200
Subject: [PATCH] accept also translations of "on" when detecting auto-added
 menu items

When a system is localized, then the title suffix "(on /dev/...)" will
have been translated to "(auf /dev/...)" or "(sur /dev/...)" or similar.
Make the grep command match all those strings.

Fixes https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1176652.
---
 linux-boot-probes/mounted/common/40grub2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-boot-probes/mounted/common/40grub2 b/linux-boot-probes/mounted/common/40grub2
index 885614e..a8aafd4 100755
--- a/linux-boot-probes/mounted/common/40grub2
+++ b/linux-boot-probes/mounted/common/40grub2
@@ -58,7 +58,7 @@ parse_grub_menu () {
 fi
 if [ -z "$title" ]; then
 	ignore_item=1
-elif echo "$title" | grep -q '(on /dev/[^)]*)$'; then
+elif echo "$title" | grep -q '(\w\+ /dev/[^)]\+)$'; then
 	log "Skipping entry '$title':"
 	log "appears to be an automatic reference taken from another menu.lst"
 	ignore_item=1
-- 
2.25.4



signature.asc
Description: OpenPGP digital signature

DID YOU GET IT?

[Smith and Associates]

Dear Sir,

Did you get my previous email about you deceased relatives estate?

Paul Smith
Smith and Associates
Tampa Florida U.S.A

Re: Bug#949367: stretch-pu: package wpa/2:2.4-1+deb9u5

[Andrej Shadura]

On Fri, May 01, 2020 at 05:25:19PM +0100, Adam D. Barratt wrote:
> On Sun, 2020-02-02 at 17:38 +0100, Cyril Brulebois wrote:
> > Trying to build the binaries to get that tested in a d-i environment,
> > I
> > ended up with a build failure:
> [...]
> > > 
> ../src/ap/drv_callbacks.o: In function `hostapd_notif_assoc':
> > > ./wpa_supplicant/../src/ap/drv_callbacks.c:66: undefined reference
> > > to `is_multicast_ether_addr'
> > > ../src/ap/ieee802_11.o: In function `ieee802_11_mgmt':
> > > ./wpa_supplicant/../src/ap/ieee802_11.c:2213: undefined reference
> > > to `is_multicast_ether_addr'
> > > collect2: error: ld returned 1 exit status
> > > Makefile:1621: recipe for target 'wpa_supplicant' failed

> Andrej? Is there likely to be an updated patch for this soon, or should
> we reject the current upload and close this request?

Oh, I somehow forgot about it. Please see attached debdiff; I have also
added the same minor fix I wanted to push into buster, I think it’s worth
it.

-- 
Cheers,
  Andrej
diff --git a/debian/changelog b/debian/changelog
index 689d552..23b14fc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+wpa (2:2.4-1+deb9u5) stretch; urgency=medium
+
+  * SECURITY UPDATE:
+- AP mode PMF disconnection protection bypass.
+  More details:
+   + https://w1.fi/security/2019-7/
+  Closes: #940080 (CVE-2019-16275)
+  * Add an upstream patch to fix the MAC randomisation issue with some cards
+(LP: #1867908, Closes: #954457)
+
+ -- Andrej Shadura   Sun, 03 May 2020 15:40:34 +0200
+
 wpa (2:2.4-1+deb9u4) stretch-security; urgency=high
 
   * SECURITY UPDATE (2019-5):
diff --git a/debian/patches/2019-7/0001-AP-Silently-ignore-management-frame-from-unexpected-.patch b/debian/patches/2019-7/0001-AP-Silently-ignore-management-frame-from-unexpected-.patch
new file mode 100644
index 000..935b113
--- /dev/null
+++ b/debian/patches/2019-7/0001-AP-Silently-ignore-management-frame-from-unexpected-.patch
@@ -0,0 +1,84 @@
+From 8c07fa9eda13e835f3f968b2e1c9a8be3a851ff9 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen 
+Date: Thu, 29 Aug 2019 11:52:04 +0300
+Subject: [PATCH] AP: Silently ignore management frame from unexpected source
+ address
+
+Do not process any received Management frames with unexpected/invalid SA
+so that we do not add any state for unexpected STA addresses or end up
+sending out frames to unexpected destination. This prevents unexpected
+sequences where an unprotected frame might end up causing the AP to send
+out a response to another device and that other device processing the
+unexpected response.
+
+In particular, this prevents some potential denial of service cases
+where the unexpected response frame from the AP might result in a
+connected station dropping its association.
+
+Signed-off-by: Jouni Malinen 
+---
+ src/ap/drv_callbacks.c | 13 +
+ src/ap/ieee802_11.c| 12 
+ 2 files changed, 25 insertions(+)
+
+diff --git a/src/ap/drv_callbacks.c b/src/ap/drv_callbacks.c
+index 31587685fe3b..34ca379edc3d 100644
+--- a/src/ap/drv_callbacks.c
 b/src/ap/drv_callbacks.c
+@@ -62,6 +62,19 @@ int hostapd_notif_assoc(struct hostapd_data *hapd, const u8 *addr,
+ 			   "no address");
+ 		return -1;
+ 	}
++
++	if (is_multicast_ether_addr(addr) ||
++	is_zero_ether_addr(addr) ||
++	os_memcmp(addr, hapd->own_addr, ETH_ALEN) == 0) {
++		/* Do not process any frames with unexpected/invalid SA so that
++		 * we do not add any state for unexpected STA addresses or end
++		 * up sending out frames to unexpected destination. */
++		wpa_printf(MSG_DEBUG, "%s: Invalid SA=" MACSTR
++			   " in received indication - ignore this indication silently",
++			   __func__, MAC2STR(addr));
++		return 0;
++	}
++
+ 	random_add_randomness(addr, ETH_ALEN);
+ 
+ 	hostapd_logger(hapd, addr, HOSTAPD_MODULE_IEEE80211,
+diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
+index c85a28db44b7..e7065372e158 100644
+--- a/src/ap/ieee802_11.c
 b/src/ap/ieee802_11.c
+@@ -2210,6 +2210,18 @@ int ieee802_11_mgmt(struct hostapd_data *hapd, const u8 *buf, size_t len,
+ 	fc = le_to_host16(mgmt->frame_control);
+ 	stype = WLAN_FC_GET_STYPE(fc);
+ 
++	if (is_multicast_ether_addr(mgmt->sa) ||
++	is_zero_ether_addr(mgmt->sa) ||
++	os_memcmp(mgmt->sa, hapd->own_addr, ETH_ALEN) == 0) {
++		/* Do not process any frames with unexpected/invalid SA so that
++		 * we do not add any state for unexpected STA addresses or end
++		 * up sending out frames to unexpected destination. */
++		wpa_printf(MSG_DEBUG, "MGMT: Invalid SA=" MACSTR
++			   " in received frame - ignore this frame silently",
++			   MAC2STR(mgmt->sa));
++		return 0;
++	}
++
+ 	if (stype == WLAN_FC_STYPE_BEACON) {
+ 		handle_beacon(hapd, mgmt, len, fi);
+ 		return 1;
+--- a/src/utils/common.h
 b/src/utils/common.h
+@@ -518,6 +518,11 @@
+ 	return (a[0] & a[1] & a[2] & a[3] & a[4] & a[5]) == 0xff;
+ }
+ 
++static inline int is_multicast_ether_addr(const u8 *a)
++{
++	return a[0] & 0x01;
++}
++