Bug#992172: exim4: CVE-2021-38371

[Andreas Metzler]

On 2021-08-14 Salvatore Bonaccorso  wrote:
> Source: exim4
> Version: 4.94.2-7
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 

> Hi,

> The following vulnerability was published for exim4, this is to start
> tracking the issue downstream for us. Note that at time of writing [2]
> gives still a 404.

> CVE-2021-38371[0]:
> | The STARTTLS feature in Exim through 4.94.2 allows response injection
> | (buffering) during MTA SMTP sending.
[...]

IIRC that is mitigated in experimental (4.95 rc) by ALPN and unkown
command related changes, I will not be able to check in detail for a
week or so, though.

cu Andreas

Bug#992169: installation-reports: Cinnamon does not automatically start screen reader on login

[Holger Wansing]

Control: reassign -1 cinnamon

Isabelle Simpkins  wrote (Sat, 14 Aug 2021 20:59:19 
+0100):
> Package: installation-reports
> Severity: important
> X-Debbugs-Cc: isy-deb...@koipond.org.uk
> 
> (Please provide enough information to help the Debian
> maintainers evaluate the report efficiently - e.g., by filling
> in the sections below.)
> 
> Boot method: USB
> Image version: 11.0.0 amd64 netinst
> Date: 
> 
> Machine: thinkpad x220
> 
> ...
> 
> Comments/Problems:
> 
> On cinnamon DI from the live image disk with speech synthesis, the screen 
> reader was on on the login screen, but once logged in, the screen reader was 
> not on and had to be turned on manually from the applications menu. This was 
> also the case on amd64 netinst. Looks like a bug in Cinnamon, as other DEs 
> tested did not seem to do the same thing.

So reassigning to the relevant package

Holger



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

Bug#514865: apt-listchanges: GTK+ window should not steal focus, and only appear if there is anything to show

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 11 Feb 2009 11:11:57 -0200 Gustavo Noronha Silva  wrote:
> Package: apt-listchanges
> Version: 2.83
> Severity: important
> 
> The GTK+ frontend has a very bad behavior: it will display a window
> and quickly close it if there is nothing to show. When the window is
> displayed (either because it has stuff to show or not), the window
> simply pops up in front of anything you are doing.
> 
> It should instead show in the background requesting attention (so that
> its taskbar button will pulse no matter in what virtual desktop you
> are). And should, of course, only display the window if there is
> something to show.
> 

There have been a lot of changes to apt-listchanges since 2009. Can you
confirm if this is still an issue for you?

- --
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEYUUATHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2GfTzVD/9oIRRiWVy7OtLrrj4i4GmYH/4HHf03
ncC/j1U2TxFYmWVpuP4AW1Ifv8tKsGormHOOJNVAhzkiDSvPdaWE0xZbHHNllAyx
k8XHmzF24xkyOm42k+j7v7xB6VUM8WPBDZQhfyRIPG/lBnsVLyW0+2JtlwaJuH2e
YNnEOGMVasK9LyZKQytCl2OEbFx7KJdbzShxwv6iELJ/uAxJdhpoeuRKMSBQ4aG4
u6/aRXPgSNlZ2jfwbuFVqYhakjrq0sCVPNu2joIQCwPHtY6Bw7JaHR9A15MWxKtJ
pC6T9Xrs1mLF4rSGaBpj2E1nYo1jWyUwTbm0cJv+B0YnCBs0OAwsIagjYNO87YRK
SocnBT7BrfnoO24gdFkdBkgWLGLcFMPYsjr7CUmmGWi69d+3U/8mp/KSXrh5L0u8
+RIvcqn8N6GvReJ6PudMaPCS/QavbaI/ljGOkJ66yspU7Si10UkfQCw8whir0GLm
U8bl/JI+94poMdCs4J2mMaaITpfISIr7T9WiJMbIhucEyKyS04opKjvGD6jPaKcr
MsQsHZeeUHmfViH02Ds3Aor9MLaEHEQpdppM5wfy3xw8fRq7FWEZQIYb6gaGvFLX
h315bJptP+Zc0IkKe6N2cEyMFZnDZylmcxUbW37buX0XgV/ycEWV7BzjWwNRbb4s
yOVj2Wa3SpszFQ==
=0HIg
-END PGP SIGNATURE-

Bug#951374: RFP: gh -- the GitHub CLI

[Brian Thompson]

On 0814, Paul Wise wrote:
>
>Could also add a Provides: gh so it is installable with the short name.
>
>I would definitely like to have this in Debian, but can't help with it.
>

This would be ideal. Is there any benefit of renaming the package to
something other than "gh"?  I can help with this during the next week.

-- 
Best regards,

Brian T


signature.asc
Description: PGP signature

Bug#992166: installation-reports: cannot install bootloader on JFS-on-mdraid, is this meant to work?

[Simon McVittie]

On Sat, 14 Aug 2021 at 19:37:37 +0100, Simon McVittie wrote:
> While working through the debian-cd testing checklist I tried to install
> from the copy of d-i on the XFCE live image, onto a (degraded) RAID1 array
> with a single JFS partition that is the root filesystem.

I retried installation with a less ambitious interpretation of the desired
install scenario, which is apparently what debian-cd testers have always
been doing for this scenario in practice in the past:

sdb
|-sdb1  1G ext4 on /boot
`-sdb2  ~ 148G (rest of disk) degraded RAID1
  `-md0 JFS on /

and that installed successfully.

If I was installing a system with RAID, LVM and/or exotic filesystems
for actual productive use, then I'd always allocate a separate ext* /boot
like this to keep things on more robust and widely-tested code paths,
so I don't think it's necessarily a real bug that the version trying
to boot directly from the JFS RAID array didn't work.

smcv

Bug#992174: wolfssl: CVE-2021-38597

[Salvatore Bonaccorso]

Source: wolfssl
Version: 4.6.0-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for wolfssl.

CVE-2021-38597[0]:
| wolfSSL before 4.8.1 incorrectly skips OCSP verification in certain
| situations of irrelevant response data that contains the NoCheck
| extension.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-38597
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38597
[1] 
https://github.com/wolfSSL/wolfssl/commit/f93083be72a3b3d956b52a7ec13f307a27b6e093

Regards,
Salvatore

Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface

[Dennis Filder]

X-Debbugs-CC: Roman Fiedler 

On Sat, Aug 14, 2021 at 08:18:00PM +, Roman Fiedler wrote:

> > iface virtbr0 inet static
> >   address 192.168.1.1
> >   netmask 255.255.255.0
> >   bridge_hw 86:aa:aa:aa:aa:aa
>
> Weird, using the configuration from above will result in:
>
> $ ifup virtbr0
> Cannot find device "virtbr0"
> ifup: failed to bring up virtbr0

It is because the "bridge_ports" directive is missing.  From the
manpage bridge-utils-interfaces(5):

   bridge_ports interface specification
  this option must exist for the scripts to setup the bridge.

Either specify "bridge_ports none" or "bridge_ports enp2s0 enp2s1" (or
whatever your physical interfaces are named).

> I also reactivated "systemd-udevd":
>
> $ systemctl start systemd-udevd-kernel.socket
> $ systemctl start systemd-udevd-control.socket
> $ systemctl start systemd-udevd.service
>
> And then tried to use the link, but I am not sure, if it is active
> without rebooting as "reload" does not seem to be the right command
> for it.
>
> # systemctl reload /lib/systemd/network/80-bridgeutils.link
> Failed to reload lib-systemd-network-80\x2dbridgeutils.link.mount: Unit 
> lib-systemd-network-80\x2dbridgeutils.link.mount not found.

Running "systemctl daemon-reload" would have been the correct thing to
do here.

> Without rebooting (which at the moment would be annoying for
> the test machine), the "hw_address" does still not work:
>
> iface virtbr0 inet static
>   address 192.168.1.1
>   netmask 255.255.255.0
>   pre-up brctl addbr virtbr0
>   post-down brctl delbr virtbr0
>   bridge_hw 86:aa:aa:aa:aa:aa
>
> but now the MAC seems truely random each time the bridge is created:

This is because with systemd-udevd stopped (or told to not touch
bridge devices through 80-bridgeutils.link) the MAC address the kernel
assigns upon device creation (which is randomly generated every time)
remains untouched.  systemd-udevd would also assign a random MAC address,
but generates the same one every time (it's random only compared to
the burnt-in MAC address).

Regards.

Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface

[Roman Fiedler]

Hello,

Thanks for your swift reply and really helpful information!

Dennis Filder writes:
> X-Debbugs-CC: Roman Fiedler , Michael Tokarev 
> 
>
> As stated in the documentation, bridge-utils recently added support
> for the "bridge_hw" directive which allows you define a MAC address
> for a bridge interface.  Changing your stanza to just this should
> already work:
>
> iface virtbr0 inet static
>   address 192.168.1.1
>   netmask 255.255.255.0
>   bridge_hw 86:aa:aa:aa:aa:aa

Weird, using the configuration from above will result in:

$ ifup virtbr0
Cannot find device "virtbr0"
ifup: failed to bring up virtbr0

Modifying above stanza to this ...

iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  pre-up brctl addbr virtbr0
  post-down brctl delbr virtbr0
  bridge_hw 86:aa:aa:aa:aa:aa

... will make "ifup virtbr0" succeed, but the MAC is not set
to the expected value:

$ ifup virtbr0
$ ip link show virtbr0
9: virtbr0:  mtu 1500 qdisc noqueue state 
DOWN mode DEFAULT group default qlen 1000
link/ether 42:dc:6a:57:58:bd brd ff:ff:ff:ff:ff:ff

> If you also use systemd, then systemd-udevd may cause trouble because
> in its default configuration it will assign a randomly generated MAC
> address to the bridge device which might cause a race.

I don't know if relevant to this case but the MAC assigned
(42:dc:6a:57:58:bd) is not random, it is the same one every time
the bridge is created.

> I haven't tried this, but putting this udev rule into
> /etc/udev/rules.d/95-bridge.rules should prevent systemd-udevd from
> touching any bridge interfaces at all:
>
>ACTION=="add", SUBSYSTEM=="net", DEVTYPE=="bridge", ENV{TAGS}-="systemd"

As "systemd-udevd" is active ...

# ps aux | grep udev
root 207  0.0  0.9  21892  4808 ?Ss   08:33   0:00 
/lib/systemd/systemd-udevd

... I just stopped it completely using ...

$ systemctl stop systemd-udevd-kernel.socket
$ systemctl stop systemd-udevd-control.socket
$ systemctl stop systemd-udevd.service   

... to avoid any interference. With

iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  pre-up brctl addbr virtbr0
  post-down brctl delbr virtbr0
  bridge_hw 86:aa:aa:aa:aa:aa

this will still not work even with udev disabled:

$ ifup virtbr0; ip link show virtbr0
13: virtbr0:  mtu 1500 qdisc noqueue state 
UNKNOWN mode DEFAULT group default qlen 1000
link/ether 8a:ad:e6:c7:ab:76 brd ff:ff:ff:ff:ff:ff

But without "systemd-udevd" my initial configuration will work
also in the virtual machine:

iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  pre-up brctl addbr virtbr0
  pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa
  pre-up ip link set virtbr0 up
  post-down ip link set virtbr0 down
  post-down brctl delbr virtbr0

$ ifup virtbr0; ip link show virtbr0
12: virtbr0:  mtu 1500 qdisc noqueue state 
DOWN mode DEFAULT group default qlen 1000
link/ether 86:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff

> Alternatively placing the file 80-bridge-utils.link from #991416
> (message #17)[0] into /lib/systemd/network/ should work as well.

I also reactivated "systemd-udevd":

$ systemctl start systemd-udevd-kernel.socket
$ systemctl start systemd-udevd-control.socket
$ systemctl start systemd-udevd.service

And then tried to use the link, but I am not sure, if it is active
without rebooting as "reload" does not seem to be the right command
for it.

# systemctl reload /lib/systemd/network/80-bridgeutils.link
Failed to reload lib-systemd-network-80\x2dbridgeutils.link.mount: Unit 
lib-systemd-network-80\x2dbridgeutils.link.mount not found.

Without rebooting (which at the moment would be annoying for
the test machine), the "hw_address" does still not work:

iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  pre-up brctl addbr virtbr0
  post-down brctl delbr virtbr0
  bridge_hw 86:aa:aa:aa:aa:aa

but now the MAC seems truely random each time the bridge is created:

$ ifup virtbr0; ip link show virtbr0
17: virtbr0:  mtu 1500 qdisc noqueue state 
UNKNOWN mode DEFAULT group default qlen 1000
link/ether 3e:6b:bc:8a:b0:68 brd ff:ff:ff:ff:ff:ff
...
link/ether 82:da:00:1c:98:ab brd ff:ff:ff:ff:ff:ff
...

Instead the config

iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  pre-up brctl addbr virtbr0
  pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa
  pre-up ip link set virtbr0 up
  post-down ip link set virtbr0 down
  post-down brctl delbr virtbr0

now works without any specific udev rules and systemd services running
normally.

Bug#992173: rust-tar: CVE-2021-38511

[Salvatore Bonaccorso]

Source: rust-tar
Version: 0.4.26-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/alexcrichton/tar-rs/issues/238
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rust-tar.

CVE-2021-38511[0]:
| An issue was discovered in the tar crate before 0.4.36 for Rust. When
| symlinks are present in a TAR archive, extraction can create arbitrary
| directories via .. traversal.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-38511
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38511
[1] https://github.com/alexcrichton/tar-rs/issues/238
[2] https://rustsec.org/advisories/RUSTSEC-2021-0080.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992172: exim4: CVE-2021-38371

[Salvatore Bonaccorso]

Source: exim4
Version: 4.94.2-7
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for exim4, this is to start
tracking the issue downstream for us. Note that at time of writing [2]
gives still a 404.

CVE-2021-38371[0]:
| The STARTTLS feature in Exim through 4.94.2 allows response injection
| (buffering) during MTA SMTP sending.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-38371
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38371
[1] https://nostarttls.secvuln.info
[2] https://www.exim.org/static/doc/security/CVE-2021-38371.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992171: alpine: CVE-2021-38370

[Salvatore Bonaccorso]

Source: alpine
Version: 2.24+dfsg1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.21+dfsg1-1.1

Hi,

The following vulnerability was published for alpine.

CVE-2021-38370[0]:
| In Alpine through 2.24, untagged responses from an IMAP server are
| accepted before STARTTLS.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-38370
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38370
[1] https://nostarttls.secvuln.info

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#992170: 0ad: lzma error: compressed data is corrupt

[Robbi Nespu]

Package: 0ad
Version: 0.0.23.1-5+b1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Failed to install

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 $ sudo apt-get install 0ad
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  0ad-data
The following NEW packages will be installed:
  0ad 0ad-data
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 707 MB of archives.
After this operation, 2,114 MB of additional disk space will be 
used.
Do you want to continue? [Y/n] y
Get:1 http://ftp.jp.debian.org/debian bullseye/main amd64 0ad-data 
all 0.0.23.1-1.1 [702 MB]
Get:2 http://ftp.jp.debian.org/debian bullseye/main amd64 0ad amd64 
0.0.23.1-5+b1 [5,589 kB]
Fetched 707 MB in 13min 49s (853 kB/s)
(Reading database ... 541240 files and directories currently 
installed.)
Preparing to unpack .../0ad-data_0.0.23.1-1.1_all.deb ...
Unpacking 0ad-data (0.0.23.1-1.1) ...
dpkg-deb (subprocess): decompressing archive 
'/var/cache/apt/archives/0ad-data_0.0.23.1-1.1_all.deb' (size=701833824) member 
'data.tar': lzma error: compressed data is corrupt
dpkg-deb: error:  subprocess returned error exit status 
2
dpkg: error processing archive 
/var/cache/apt/archives/0ad-data_0.0.23.1-1.1_all.deb (--unpack):
 cannot copy extracted data for 
'./usr/share/games/0ad/mods/public/public.zip' to 
'/usr/share/games/0ad/mods/public/public.zip.dpkg-new': unexpected end of file 
or stream
Selecting previously unselected package 0ad.
Preparing to unpack .../0ad_0.0.23.1-5+b1_amd64.deb ...
Unpacking 0ad (0.0.23.1-5+b1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/0ad-data_0.0.23.1-1.1_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

$ md5sum /var/cache/apt/archives/0ad-data_0.0.23.1-1.1_all.deb
2688ba115bc50916975827a9f57052bd  
/var/cache/apt/archives/0ad-data_0.0.23.1-1.1_all.deb


   * What was the outcome of this action?
Fail corupted

   * What outcome did you expect instead?
   0ad should be install without any file corruption

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages 0ad depends on:
pn  0ad-data   
ii  0ad-data-common0.0.23.1-1.1
ii  dpkg   1.20.9
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libc6  2.31-13
ii  libcurl3-gnutls7.74.0-1.3+b1
ii  libenet7   1.3.13+ds-1
ii  libgcc-s1  10.2.1-6
ii  libgl1 1.3.2-1
ii  libgloox18 1.0.24-2
ii  libicu67   67.1-7
ii  libminiupnpc17 2.2.1-1
ii  libnspr4   2:4.29-1
ii  libnvtt2   2.0.8-1+dfsg-8.2+b1
ii  libopenal1 1:1.19.1-2
ii  libpng16-161.6.37-3
ii  libsdl2-2.0-0  2.0.14+dfsg2-3
ii  libsodium231.0.18-1
ii  libstdc++6 10.2.1-6
ii  libvorbisfile3 1.3.7-1
ii  libwxbase3.0-0v5   3.0.5.1+dfsg-2
ii  libwxgtk3.0-gtk3-0v5   3.0.5.1+dfsg-2
ii  libx11-6   2:1.7.2-1
ii  libxcursor11:1.2.0-2
ii  libxml22.9.10+dfsg-6.7
ii  zlib1g 1:1.2.11.dfsg-2

0ad recommends no packages.

0ad suggests no packages.

-- debconf-show failed

Bug#992169: installation-reports: Cinnamon does not automatically start screen reader on login

[Isabelle Simpkins]

Package: installation-reports
Severity: important
X-Debbugs-Cc: isy-deb...@koipond.org.uk

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 11.0.0 amd64 netinst
Date: 

Machine: thinkpad x220

...

Comments/Problems:

On cinnamon DI from the live image disk with speech synthesis, the screen 
reader was on on the login screen, but once logged in, the screen reader was 
not on and had to be turned on manually from the applications menu. This was 
also the case on amd64 netinst. Looks like a bug in Cinnamon, as other DEs 
tested did not seem to do the same thing.

Bug#992164: calamares: Creating a new blank partition table GPT/UEFI results in failure

[liz]

Package: calamares
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: itsvaporw...@icloud.com

Dear Maintainer,

I was testing Debian 11 Bullseye on a Thinkpad T530 with UEFI/GPT and LVM. When 
the new volume group was being created, the error 'Create a new partition table 
(type gpt_ on '/dev/debian-vg') is shown. Once this is closed, calamares 
installer closes and results in failure.



-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages calamares depends on:
ii  kpackagetool5   5.78.0-3
pn  libboost-python1.74.0   
pn  libboost-python1.74.0-py39  
ii  libc6   2.31-13
ii  libcrypt1   1:4.4.18-4
ii  libgcc-s1   10.2.1-6
ii  libkf5configcore5   5.78.0-4
ii  libkf5coreaddons5   5.78.0-4
ii  libkf5package5  5.78.0-3
ii  libkf5parts55.78.0-3
ii  libkf5service-bin   5.78.0-2
ii  libkf5service5  5.78.0-2
ii  libkpmcore1020.12.3-2
ii  libparted2  3.4-1
pn  libpwquality1   
ii  libpython3.93.9.2-1
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5dbus5 5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5network5  5.15.2+dfsg-9
ii  libqt5qml5  5.15.2+dfsg-6
ii  libqt5quick55.15.2+dfsg-6
ii  libqt5quickwidgets5 5.15.2+dfsg-6
ii  libqt5svg5  5.15.2-3
ii  libqt5webkit5   5.212.0~alpha4-11
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libqt5xml5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6
pn  libyaml-cpp0.6  
ii  os-prober   1.79

Versions of packages calamares recommends:
ii  btrfs-progs 5.10.1-2
pn  squashfs-tools  

calamares suggests no packages.

Bug#992168: libtpm2-pkcs11-1: missing p11-kit configuration

[Nicolas Iooss]

Package: libtpm2-pkcs11-1
Version: 1.5.0-4
Severity: wishlist
X-Debbugs-Cc: nicolas.iooss_debb...@m4x.org

Dear Maintainer,

When trying to use p11-kit with tpm2-pkcs11, p11-kit does not find any
PKCS#11 token. This is because there is not file for tpm2-pkcs11 in
/usr/share/p11-kit/modules/.

tpm2-pkcs11's upstream provides such a configuration file in
https://salsa.debian.org/debian/tpm2-pkcs11/-/blob/01411a3855e39173c6d886455a3d5148f94188d1/misc/p11-kit/tpm2_pkcs11.module
and it gets automatically installed if ./configure detects that p11-kit
is installed. So a possible fix consists in adding p11-kit in the build
dependencies and add /usr/share/p11-kit/modules/tpm2_pkcs11.module to
one of the debian/install files of tpm2-pkcs11 package. Another way
of fixing this could consists in installing "by hand" the module without
relying on ./configure auto-detection feature.

Then, even when /usr/share/p11-kit/modules/tpm2_pkcs11.module is
present, p11-kit still does not work:

$ p11-kit list-modules -v
p11-kit: couldn't load module:
/usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so:
/usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so: cannot open shared
object file: No such file or directory

By adding a symlink like what opensc-pkcs11 does, this finally make
p11-kit find the PKCS#11 token provided by tpm2-pkcs11:

$ sudo ln -s ../libtpm2_pkcs11.so.1 
/usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so
$ p11-kit list-modules -v
tpm2_pkcs11: libtpm2_pkcs11.so
library-description: TPM2.0 Cryptoki
library-manufacturer: tpm2-software.github.io
library-version: 0.0
token:
manufacturer: Nuvoton
...

In short, in order to use p11-kit with tpm2-pkcs11, two things are
currently missing: a configuration file in /usr/share/p11-kit/modules
and a symlink in /usr/lib/x86_64-linux-gnu/pkcs11. Could you please
consider adding these files to a package?

Regards,
Nicolas Iooss

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.11.0-25-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libtpm2-pkcs11-1 depends on:
ii  libc6 2.31-12
ii  libsqlite3-0  3.34.1-3
ii  libssl1.1 1.1.1k-1
ii  libtss2-esys-3.0.2-0  3.0.3-2
ii  libtss2-mu0   3.0.3-2
ii  libtss2-rc0   3.0.3-2
ii  libtss2-tctildr0  3.0.3-2
ii  libyaml-0-2   0.2.2-1

libtpm2-pkcs11-1 recommends no packages.

libtpm2-pkcs11-1 suggests no packages.

-- no debconf information

Bug#959892: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK

[Adam Borowski]

On Fri, Aug 13, 2021 at 02:21:21PM +0200, Fabrice Creuzot wrote:
> Okay, so I tried to build all binary packages from one source package.
> Not sure if it's the good way.
> 
> It builds those binary packages:
>   awf-gtk2 - A widget factory is a theme preview application for GTK
>   awf-gtk3 - A widget factory is a theme preview application for GTK
>   awf-gtk4 - A widget factory is a theme preview application for GTK

Generally, looks good to me.

However, gtk-4 is available only in experimental.  This will almost
certainly change before your package leaves NEW (gtk4 maintainers are
probably salivating at the thought of uploading to unstable ASAP, while
NEW is very crowded), but let's have installable+buildable packages.
There's no reason for a first upload of a package to go into unstable,
too -- it needs a rebuild in any case.

Nitpick: the short desc shouldn't be capitalized.

Having no explicit debian/source/format is deprecated -- please declare
the format.

Also, while gtk2 and 3 binaries work for me, gtk4 crashes at start:
Thread 1 "awf-gtk4" received signal SIGSEGV, Segmentation fault.
create_treview (root=0x556a5780) at awf.c:1973
1973if (strcmp (config, "0") == 0)
(gdb) bt full
#0  create_treview (root=0x556a5780) at awf.c:1973
scrolled_window = 0x559704c0
store = 0x55909960
iter = 
  {stamp = -1097518473, user_data = 0x558cc150, user_data2 = 
0x556b7160, user_data3 = 0x0}
config = 0x0
view = 0x5593c3c0
renderer = 
hbox_columns = 
vbox_column1 = 
vbox_combo_entry = 
hbox_spin = 
hbox_check_radio = 
vbox_check = 
vbox_radio = 
vbox_column2 = 
vbox_buttons = 
hbox_btns1 = 
hbox_btns2 = 
hbox_btns3 = 
hbox_btns4 = 
vbox_column3 = 
vbox_progressbar1 = 
vbox_progressbar2 = 
hbox_progressbar1 = 
hbox_progressbar2 = 
vbox_column4 = 
vbox_others = 
hbox_label = 0x556a5900
hbox_spinner = 0x556a5a80
vpane = 0x555cb3b0
hpane1 = 0x555cb590
hpane2 = 0x555cb770
hbox_frame1 = 0x556a5c00
hbox_frame2 = 0x556a5d80
hbox_notebook1 = 0x556a5f00
hbox_notebook2 = 0x556d21f0
#1  create_widgets (root=0x556b7760) at awf.c:818
hbox_columns = 
vbox_column1 = 
vbox_combo_entry = 
hbox_spin = 
hbox_check_radio = 
vbox_check = 
vbox_radio = 
vbox_column2 = 
vbox_buttons = 
hbox_btns1 = 
hbox_btns2 = 
hbox_btns3 = 
hbox_btns4 = 
vbox_column3 = 
vbox_progressbar1 = 
vbox_progressbar2 = 
hbox_progressbar1 = 
hbox_progressbar2 = 
vbox_column4 = 
vbox_others = 
hbox_label = 0x556a5900
hbox_spinner = 0x556a5a80
vpane = 0x555cb3b0
hpane1 = 0x555cb590
hpane2 = 0x555cb770
hbox_frame1 = 0x556a5c00
hbox_frame2 = 0x556a5d80
hbox_notebook1 = 0x556a5f00
hbox_notebook2 = 0x556d21f0
#2  0x55562e1c in create_window (app=, theme=) at awf.c:734
vbox_window = 0x556b7160
toolbar = 0x556b72e0
widgets = 0x556b7760
gmm = 
event = 
#3  0x774450a2 in g_closure_invoke () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x77457413 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7745d6cf in g_signal_emit_valist () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7745dc3f in g_signal_emit () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7756a338 in  () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#8  0x7756a4ae in g_application_run () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#9  0x77161d0a in __libc_start_main (main=
0xb060 , argc=1, argv=0x7fffe008, init=, 
fini=, rtld_fini=, stack_end=0x7fffdff8) at 
../csu/libc-start.c:308
result = 
unwind_buf = 
  {cancel_jmp_buf = {{jmp_buf = {0, 3035993641122779325, 
93824992261632, 0, 0, 0, 9184899517099004093, 9184881029332193469}, 
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x1, 0x7fffe008}, data = 
{prev = 0x0, cleanup = 0x0, canceltype = 1}}}
not_first_call = 
#10 0xb62a in _start ()


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface

[Dennis Filder]

X-Debbugs-CC: Roman Fiedler , Michael Tokarev 


As stated in the documentation, bridge-utils recently added support
for the "bridge_hw" directive which allows you define a MAC address
for a bridge interface.  Changing your stanza to just this should
already work:

iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  bridge_hw 86:aa:aa:aa:aa:aa

If you also use systemd, then systemd-udevd may cause trouble because
in its default configuration it will assign a randomly generated MAC
address to the bridge device which might cause a race.

I haven't tried this, but putting this udev rule into
/etc/udev/rules.d/95-bridge.rules should prevent systemd-udevd from
touching any bridge interfaces at all:

   ACTION=="add", SUBSYSTEM=="net", DEVTYPE=="bridge", ENV{TAGS}-="systemd"

Alternatively placing the file 80-bridge-utils.link from #991416
(message #17)[0] into /lib/systemd/network/ should work as well.

Regards,
Dennis Filder

0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991416#17

Bug#992166: installation-reports: cannot install bootloader on JFS-on-mdraid, is this meant to work?

[Simon McVittie]

Package: installation-reports
Severity: normal

Boot method: USB
Image version: debian-live-11.0.0-amd64-xfce.iso release candidate, 2021-08-14
Date: 2021-08-14 approx 18:30 UTC

Machine: Lenovo Thinkpad X201, booted using BIOS
Partitions:

(transcribed by hand, might not be 100% accurate - I'll get logs later
but I wanted to report this while I still remember what I did)

~ # chroot /target sfdisk --dump /dev/sdb
label: dos
label-id: 0xbbfb3881
device: /dev/sdb
unit: sectors
sector-size: 512

/dev/sdb1 : start= 2048, size= 312578048, type=fd

~ # chroot /target lsblk
NAME  MAJ:MIN RM   SIZE   RO TYPE  MOUNTPOINT
sda 8:01 7.3G  0 disk
|-sda1  8:11 2.3G  0 part  /media/cdrom
`-sda2  8:21 2.6M  0 part
sdb 8:16   0   149.1G  0 disk
`-sdb1  8:17   0   149G0 part
  `-md0 9:00   148.9G  0 raid1 /

~ # chroot /target mount
/dev/md0 on / type jfs (rw,relatime)
/dev/sda1 on /media/cdrom (etc.)
devtmpfs on /dev type devtmpfs (etc.)
proc on /proc (etc.)
tmpfs on /run type tmpfs (etc.)
sysfs on /sys (etc.)

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[E]

While working through the debian-cd testing checklist I tried to install
from the copy of d-i on the XFCE live image, onto a (degraded) RAID1 array
with a single JFS partition that is the root filesystem. Transcribed by
hand, formatting might not be 100% faithful but numbers should be correct:

~ # chroot /target lsblk
NAME  MAJ:MIN RM   SIZE   RO TYPE  MOUNTPOINT
sda 8:01 7.3G  0 disk
|-sda1  8:11 2.3G  0 part  /media/cdrom
`-sda2  8:21 2.6M  0 part
sdb 8:16   0   149.1G  0 disk
`-sdb1  8:17   0   149G0 part
  `-md0 9:00   148.9G  0 raid1 / <-- a JFS filesystem

Note that I don't use JFS myself and I don't know whether this is expected
to be something that grub is able to cope with (#debian-cd regulars tell me
that they normally use a separate ext2 /boot partition outside the RAID array
when testing this use-case).

When trying to install the bootloader, I was prompted with this device list:

/dev/sda (the USB stick I am installing from)
/dev/sdb (the hard disk)

and I chose /dev/sdb. The result is:

Install the GRUB boot loader
-
Unable to install GRUB in /dev/md
Executing 'grub-install /dev/md' failed.
This is a fatal error.

I tried to work around this with:

~ # chroot /target grub-install /dev/md0

but this also failed with:

grub-install: warning: Couldn't find physical volume `(null)'. Some modules 
may be missing from core image..
grub-install: warning: Couldn't find physical volume `(null)'. Some modules 
may be missing from core image..
grub-install: warning: File system `jfs' doesn't support embedding.
grub-install: warning: Embedding is not possible.  GRUB can only be 
installed in this setup by using blocklists.  However, blocklists are 
UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

I'll send logs when I've recovered them but I can't do that right now.

Again, I don't know whether this *should* work - I'm only testing it because
it was my interpretation of what was on the checklist.

smcv

Bug#951374: RFP: gh -- the GitHub CLI

[Antoine Beaupré]

On 2021-08-08 10:17:06, Brian Thompson wrote:
>> I personally find that "gh" is quite short name for a package that
>> will go into a general purpose software catalog like Debian repository. Would
>> you mind choosing something like "github-cli" as source and binary
>> package name and mentioning the sortcut "gh" in a package description?
>> So anyone could find the program by means of `apt-cache search`.
>> Acronyms gh and gn (which stands for Google's Generate Ninja) are
>> visually similar, and I'm afraid they are easily confused.
>>
>> What do you make of this proposal?
>
> I like that proposal and think it makes a lot of sense. `gh` does seem
> too short, and while easy to identify for current gh users, maybe it
> will be more difficult to find in apt for new users. Also, as you
> mentioned, a namespace clash in the future seems like an uncommon
> occurence.

It's not on the package name, but there's already a clash on the binary
name, which we should be mindful of:

anarcat@angela:~(main)$ apt-file search bin/gh | grep 'gh$'
gitsome: /usr/bin/gh
anarcat@angela:~(main)$ apt show gitsome | sed -n '/Description/,$p'

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Description: Supercharged Git/Shell Autocompleter with GitHub Integration
 gitsome provides direct integration with GitHub and GitHub Enterprise in
 a terminal.
 It includes not only GitHub integrated commands that work with all
 shells but also provides following functions.
 .
  - Git and GitHub Autocompleter With Interactive Help
  - Fish-Style Auto-Suggestions
  - General Autocompleter
  - Python REPL
  - Command History
  - Customizable Highlighting

Since it's a git (and github, even!) related tool, we might even want to
Conflict with it directly...

a.

-- 
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld

Bug#992164: calamares: Creating a new blank partition table GPT/UEFI results in failure

[Steve McIntyre]

On Sat, Aug 14, 2021 at 05:50:47PM +0100, Steve McIntyre wrote:
>
>Starting in BIOS mode on a kde i386 live image. The existing disk on
>my test system has an LVM setup on it. I've told calamares to wipe the
>whole disk and do a fresh installation, but it looks like the code to
>work out the existing disks has got confused and it thinks that the
>whole disk is /dev/debian-vg rather than /dev/sda. Three attachments
>here:
>
> * partitions.txt is the output of "fdisk -l" at the start
> * Screenshot_20210814_174257.png shows calamares just before I hit
>   "Install"
> * Screenshot_20210814_174916.png shows the error message

FTAOD: I've just cleared the partition on the disk and restarted
calamares and now it's working fine.


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Bug#992161: /usr/bin/printf: %q outputs garbage for \1'\1

[наб]

Package: coreutils
Version: 8.32-4
Severity: normal
File: /usr/bin/printf

Dear Maintainer,

Consider the following invocation: 
/bin/printf "%q" $'\001'\'$'\001'
(i.e. 1st=dollar+letter q, 2nd=byte 1+apostrophe+byte 1)

What do you expect the output to be? I'd expect something like
$'\001'\'$'\001'
or, in the, rather verbose, printf format,
''$'\001'\'''$'\001'

Okay, now what does the invocation output?
'\001'\'''$'\001'

Uh-oh! And what fill feeding that into an Almquist shell give?
$ echo -n '\001'\'''$'\001' | hexdump -C
  5c 30 30 31 27 01 |\001'.|
0006

Sheesh!

As far as I can tell, a sequence of any string that needs escaping,
followed by an apostrophe, followed by another string that needs
escaping will trigger this, and the example above is the minimal case.

наб

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-13
ii  libgmp10 2:6.2.1+dfsg-1
ii  libselinux1  3.1-3

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#991958: /usr/bin/linux.uml: consoles do not work if they are read for reading at startup

[Simon Tatham]

Ian Jackson  wrote:
> Arrange not to write anything into linux.uml until some output has
> appeared.  That seems to work OK for me, leading me to think it's not
> a general lossage bug, but only happens if there is input to be read
> when linux.uml starts up its consoles.

FWIW, I've pushed to PuTTY main today a patch that adds a bug workaround
flag for this kind of thing. Now the PuTTY client tools can be manually
configured to delay sending their SSH (or psusan) greeting until after
they see the greeting from the other end.

So, in that particular use case of UML, this can be worked around.

Cheers,
Simon

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and m)(0xb80b5dacabab6145,0xf70027d345023,0x7643bc4018957897,0x11c2e5d9951130c9
,0xa54d9cbe4e8ab,0x746c50eaa1910,  "Simon Tatham " ))

Bug#992160: simutrans: Using "Load Scenario" fails with "Loading scenario script failed"

[Niels Thykier]

Package: simutrans
Version: 121.0-1
Severity: normal
X-Debbugs-Cc: ni...@thykier.net


Hi,

Attempting to use the `Load Scenario` feature to play any of the
built-in scenarios (such as `book-empire`) fails with a dialog box
saying "Loading scenario script failed".  On stdout from simutrans, it
emits a single line saying "script engine started." and then nothing
else.

Please let me know if you need any additional input from me to
reproduce this issue.


-- System Information:
Versions of packages simutrans depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-13
ii  libgcc-s110.2.1-6
ii  libsdl2-2.0-02.0.14+dfsg2-3
ii  libsdl2-mixer-2.0-0  2.0.4+dfsg1-3
ii  libstdc++6   10.2.1-6
ii  simutrans-data   121.0-1
ii  simutrans-pak64  121.0-1
ii  zlib1g   1:1.2.11.dfsg-2

simutrans recommends no packages.

Versions of packages simutrans suggests:
pn  freepats  

Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface

[Michael Tokarev]

On Sat, 14 Aug 2021 08:28:41 + Roman Fiedler 
 wrote:

Package: bridge-utils
Version: 1.7-1
Severity: serious

When running "brctl addbr" and "ip link set [if] address" immediately
afterwards, the second command will fail to apply the address
change. This is somehow annoying as the MAC would be used in
security related filtering and monitoring of the network traffic,
which then fails.

The configuration from "/etc/network/interfaces" reliably triggering
the bug is:

auto virtbr0
iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  pre-up brctl addbr virtbr0
  pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa
  pre-up ip link set virtbr0 up
  post-down ip link set virtbr0 down
  post-down brctl delbr virtbr0


How about switching from brctl to ip, once you already
use it anyway?  So instead of brctl addbr virtbr0,
it will read ip link add virtbr0 type bridge,
and ip link del virbr0, something like that.

I don't know about brctl, - we stopped using this
utility some 10 years ago due to numerous issues.

Also I don't know whenever it's a good idea to
mark this bug as serious.

Thanks,

/mjt

Bug#992159: security-tracker: DSA-4957-1 vs. tracker

[Francesco Poli (wintermute)]

Package: security-tracker
Severity: normal

Hi everyone!

In [DSA-4957-1], a number of CVEs are listed as fixed in trafficserver
for buster: CVE-2021-27577 CVE-2021-32566 CVE-2021-32567 CVE-2021-35474
CVE-2021-32565 .

However, the last one [CVE-2021-32565] is not present in the
corresponding [DSA tracker page], probably due to a typo in
the [changelog entry].

[DSA-4957-1]: 

[CVE-2021-32565]: 
[DSA tracker page]: 
[changelog entry]: 


If this is the case, please update the tracker data.
Thanks for your time!

Bug#984105: Reopen Bug#984105, fixed in experimental

[Rafael Laboissière]

Control: reopen -1
Control: tags -1 + fixed-in-experimental

I am hereby reopening this bug report and tagging it accordingly. The 
fixed version was uploaded to experimental and the version currently in 
sid and testing is impacted by the bug.


Rafael Laboissière

Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface

[Roman Fiedler]

Package: bridge-utils
Version: 1.7-1
Severity: serious

When running "brctl addbr" and "ip link set [if] address" immediately
afterwards, the second command will fail to apply the address
change. This is somehow annoying as the MAC would be used in
security related filtering and monitoring of the network traffic,
which then fails.

The configuration from "/etc/network/interfaces" reliably triggering
the bug is:

auto virtbr0
iface virtbr0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  pre-up brctl addbr virtbr0
  pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa
  pre-up ip link set virtbr0 up
  post-down ip link set virtbr0 down
  post-down brctl delbr virtbr0

Running "ifdown virtbr0; ifup virtbr0; ip link show" will report

link/ether 86:8a:6a:ee:5e:a2 brd ff:ff:ff:ff:ff:ff

so the setting to "86:aa:aa:aa:aa:aa" does not take effect. The
reason I expect the race to be in brctl itself or related a race
in the kernel just exposed by brctl is, that following changes
will produce correct results:

* "strace -o dump ifup virtbr0" eliminates the behavior.

* Using "  pre-up brctl addbr virtbr0 && sleep 1" will make "ifup"
wait for one second, correct MAC is set.


Instead when changing the initial interfaces configuration to
include

  pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa || touch /root/fail

"ifup" will still expose the bug but /root/fail is not created.
So if "ip link" fails to react correctly on any intermediate
state when the bridge is coming up, then at least it does not
detect it correctly and report it via an error code. As attaching
a debugger eliminates the bug I have no idea how to quickly rule
out such an effect.

Weirdly this bug does not occur on a multicore real-hardware
machine (I have no single core hardware or tried to run Linux
single core via boot options) but till now only in single core
qemu machines (I did not test multi-core qemu yet). But the core
count, kernel behaviour might be just a red herring.


Any ideas how that could happen? Maybe would "brctl add" need
to wait for a confirmation from kernel, that the bridge setup
is completed before exiting?

Bug#991960: [putty] Bug#991960: /usr/bin/psusan: psusan example ends up with . on PATH due to #991959

[Simon Tatham]

Ian Jackson  wrote:
> psusan(1) suggests this:
[...]
> I think it would be best to change the example to explicitly set PATH
> to avoid this bug.

Upstream commit 9983ff53d5a3d59d58030be0cd46a30eb5da5abc makes this
change.

Cheers,
Simon

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and m)(0xb80b5dacabab6145,0xf70027d345023,0x7643bc4018957897,0x11c2e5d9951130c9
,0xa54d9cbe4e8ab,0x746c50eaa1910,  "Simon Tatham " ))

Bug#992025: release-notes: Add section on switching init system

[Paul Gevers]

Hi Matthew,

On 09-08-2021 22:53, Matthew Vernon wrote:
> Not currently (I imagine something like it will end up there
> eventually); I think it warrants being in the release notes because it's
> quite a significant change from Buster (where non-systemd inits were
> largely unusable on desktop systems).

If that's the case, it makes more sense to mention it in the whats-new
section, keep it short and link to a wiki.

Paul



OpenPGP_signature
Description: OpenPGP digital signature