Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

On Sat, 2024-04-27 at 03:15 +0200, Guilhem Moulin wrote:
> Yup that'd make sense to me (and I see you did that already), thanks!

:-)

Unfortunately I doubt it will be possibly to do some fully generic
solution.

So best we'll get is probably either an unconditional inclusion or some
simpler copy_* function.


Thanks for your help with the hint on the 2.34 change... I had already
been at my wits end, why pthread didn't show up at ldd ^^

Best wishes,
Chris.

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote:
> built using glibc ≥2.34.  AFAICT the “if the ldd output includes
> libpthread then run copy_libgcc()” logic from initramfs-tools is
> mostly moot
> now

Ah, I just realised glibc "merged" libpthread ^^

Therefore...

> but despite what I promised elbrus in
> https://bugs.debian.org/1032235#87 it
> looks like I didn't file a bug.

... I helped you fulfilling your promise and re-assigned my #1069912,
making it the bug that asks for some more generic solution :-)


Thanks,
Chris.

Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

Hey Guilhem

On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote:
> Even it weren't, libpthread wouldn't show up since src:argon2 from
> bookworm
> and later is built using glibc ≥2.34.

When argon2 builds, it uses -pthread ... not really sure what that does
exactly, the manpage merely says it links against pthread, but
statically? Dynamically?

Anyway, when building it manually and even with -lpthread, it doesn't
show up - just as you say.

Tried now for an hour or so to make it show up (eventually gave up and
filed #1069912).

So you say it's a glibc thingy, that this doesn't show up anymore?


>   AFAICT the “if the ldd output includes
> libpthread then run copy_libgcc()” logic from initramfs-tools is
> mostly moot
> now, see https://bugs.debian.org/1032235#97 .

Shouldn't initramfstools then not simply generally include libgcc?



> We used the following workaround to manually call copy_libgcc()
> 
>    
> https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/4cade1eae57abd93e0d6491eebce5f5f163ef186#a630d04e2df57150e6a092fc23f955c6ea0ce412
>    
> https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/369cb651abad11a3844fa38ea86ece40f4f40078

As a workaround I've used now:
copy_libgcc /lib/x86_64-linux-gnu

with the libpath hardcoded... but I have no idea how I should get that
path properly.
As far as I can see from your commit, you simply used the path that
libargon2 was using?

But I don't have that since argon2 doesn't link against it ;-)
Any idea what would be the best solution in my case?


> for Bookworm, but removed it with 2:2.7.2-1 since src:cryptsetup no
> longer uses libargon.  There is no stability guaranty for transitive
> dependencies so I'd indeed argue the regression is not
> src:cryptsetup's
> fault :-)  Adapting the above workarounds to your custom hookfile
> should
> solve the issue, though.

Hmm yes, but I'm not sure if that would be a more proper solution than
mine (with the hardcoded path), cause:

In principle, my argon2 binary tool, might be from another arch as the
installed libargon2 (if it's installed at all, which isn't necessarily
the case).
So not sure, but maybe:

$ ldd /usr/bin/argon2
linux-vdso.so.1 (0x7ffcc67d4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1a1ee48000)
/lib64/ld-linux-x86-64.so.2 (0x7f1a1f058000)

I should use libc for determination?

> 



> > Did anyone of your report this issue anywhere else?
> 
> Some years ago I asked the initramfs-tools maintainers to
> inconditionally copy
> libgcc_s to the initramfs image, but IIRC Ben argued it was too
> seldom used to
> justify the cost in size and impemented the libpthread detection
> logic +
> copy_libgcc() instead.
> 
> I don't know if the detection logic can be improved/fixed in
> initramfs-tools,
> but despite what I promised elbrus in
> https://bugs.debian.org/1032235#87 it
> looks like I didn't file a bug.

So... I assume the change in glibc is proper then... and a fix (if at
all) would rather need to go to initramfs-tools?
Would you recommend me to reassign #1069912 to initramfs-tools, asking
for a more user-friendly solution?


Thanks,
Chris.

Bug#1068849: [pkg-cryptsetup-devel] Bug#1068849: cryptsetup: Fails to unlock the filesystem with missing libgcc_s.so.1

[Christoph Anton Mitterer]

Hey guys.

I kinda ran into a similar issue.

I use my own OpenPGP keyscript which is highly improved upon that
("decrypt_gnupg") shipped by the package.

One thing that I do is offer optionally feeding the entered passphrase
trough argon2 (the standalone tool from the package of the same name)
which I copy via copy_exec.

Now the problem is that argon2 is statically linked, so there's no
libpthread showing up in its ldd, and thus copy_exec doesn't realise it
needs to invoke copy_libgcc.


Did anyone of your report this issue anywhere else? I mean it's
obviously not crypsetup.
But I cannot really blame argon2 either, nor can I really blame update-
initramfs.


Cheers,
Chris.

Bug#1064293: less: CVE-2022-48624

[Christoph Anton Mitterer]

On Sat, 2024-04-20 at 07:54 -0400, P. J. McDermott wrote:
> Then the salvage procedure can play out for the full 28+ days
> specified
> by developers-reference (21 days to allow the maintainer to object
> followed by a DELAYED/7 adoption upload).  I've already soft-proposed
> to
> salvage in bug #1069280 yesterday.  And as mentioned there I'm not
> yet a
> DD or DM, so I'd need to find a sponsor (and access to
> debian/less.git).

In the light of the recent XZ backdoor, wouldn't it generally be more
desirable to get more co-maintainers, rather than replacing an existing
one?


Cheers,
Chris.

Bug#1065017: unuser: error while loading shared libraries: libpam.so.0

[Christoph Anton Mitterer]

On Thu, 2024-02-29 at 13:31 -0700, Sam Hartman wrote:
> > > > > 
> I tried to make the revert work either if you didn't have libpam0t64
> at
> all or if you did, but we're more focused on people who never
> upgraded.
> 
> If you do run into breakage, we'll work with you to find a solution.


I guess right now going back isn't anyway possible yet, as e.g. util-
linux and some others have already depended on the t64 package, and't
I'd assume those haven't been rebuilt yet with the reversion.

Means however also, that possibly more and more people (on unstable)
get the libpam0t64 installed, unless they completely wait until the
transition is over.


Cheers,
Chris.

Bug#1065022: libglib2.0-0t64: transition from libglib2.0-0 breaks GSettings, GIO modules

[Christoph Anton Mitterer]

On Thu, 2024-02-29 at 13:30 +, Simon McVittie wrote:
> The advice for "end users" would be don't run unstable or
> experimental,
> and wait for maintainers to fix release-critical bugs like this one
> as
> they are detected.

Well "end user" is a broad range :-)
I guess quite some people do run unstable on their regular systems like
I do, which gives them kind of a rolling release, while at the same
time being 99,xx% super stable (at least in my experience)... and on
the other hand helps Debian at a whole, as much more testing is done.

Suggesting such people to use the testing suite is only a partial
replacement, as that generally lacks some packages (like firefox).


> I'm sorry if this means I am not living up to your
> expectations.

Uhm? No I'm absolutely fine... an do no in any way think that you (or
anyone else) should have "performed any better" - nor would I have any
such demands/expectations. :-)


> Installing and then reinstalling libglib2.0-0t64 should recreate this
> cache, yes.
> 
> If you have multiarch versions of libglib2.0-0t64 installed
> (typically libglib2.0-0t64:amd64 and libglib2.0-0t64:i386) then you
> will need to reinstall each of them.

I see. Well I guess that's then already enough of instructions for any
end user (in the sense of "is not a glib expert" user).


Thanks,
Chris.

Bug#1065017: unuser: error while loading shared libraries: libpam.so.0

[Christoph Anton Mitterer]

On Thu, 2024-02-29 at 08:14 +0100, Helmut Grohne wrote:
> Can you locate a more complete upgrade log?

Attached is the excerpt from APT's term.log, if that helps.

Cheers,
Chris.


term.log.xz
Description: application/xz

Bug#1065017: unuser: error while loading shared libraries: libpam.so.0

[Christoph Anton Mitterer]

On Thu, 2024-02-29 at 08:50 -0700, Sam Hartman wrote:
> > > > > 
> Steve and I agreed to revert the rename  on IRC, effectively
> accepting
> the ABI break because it doesn't matter for the archive.
> We may look at better solutions when we have a bit of time.

Do you happen to know whether there's anything needed in terms of clean
up for people who had already upgraded now? Like manually doing
whatever was done via the runuser?

>From the log it looked to me as this would have happened during removal
of libpam0g, that doesn't call it (at least no directly).

Cheers,
Chris.

Bug#1065022: libglib2.0-0t64: transition from libglib2.0-0 breaks GSettings, GIO modules

[Christoph Anton Mitterer]

Hey Simon.


On Thu, 2024-02-29 at 10:33 +, Simon McVittie wrote:
> Yes, the workaround for this is to reinstall any package that carries
> GSettings schemas. gsettings-desktop-schemas is a common one, but
> actually
> any package that has files in /usr/share/glib-2.0/schemas/ should be
> equally good here.
> 
> There is a related failure mode with a less dramatic impact that
> can be worked around by reinstalling either dconf-gsettings-backend,
> glib-networking or gvfs after the upgrade.

So the advise for "end users" is to simply re-install one package of
both groups and everything should be cleaned up again?


> Please also check the apt logs, particularly /var/log/apt/term.log,
> which will tell us what actually happened (not just what aptitude
> planned to do, which is what the aptitude logs show).

See the attached files.
term.log.{1,2} are NOT rotated files.

.1 is the first try, where I've upgraded all packages at once in the
beginning and then did lots of subsequent "downgrades", trying to find
out where the problem is.

After that I restored the whole root-fs from a btrfs snapshot that I
had made by coincidence just before.

.2 is the whole upgrades but in several steps, with an number of re-
installs (from the *t64 packages, just to be sure that all files are
there), eventually also re-installing libglib.


>  What I'm mainly
> interested in in is the order of these events relative to each other,
> during the upgrade transaction that added libglib2.0-0t64:
> 
> - De-configuring libglib2.0-0 (it's OK if this is not present)
> - Preparing to unpack libglib2.0-0t64
> - Processing triggers for libglib2.0-0t64
> - Purging configuration files for libglib2.0-0
> - Removing libglib2.0-0
> - Setting up libglib2.0-0t64
> - Unpacking libglib2.0-0t64

Guess that should all be in the APT term logs? If not, don't hesitate
to poke me with a stick.

> > [INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-2
> ...
> > [REMOVE (PURGE)] libglib2.0-0:amd64 2.78.4-1
> 
> I think what has happened here is that because you are *purging* (and
> not
> just removing) the old libglib2.0-0, this code in the postrm is
> triggered:
> 
> if [ "$1" = purge ] && [ -d /usr/share/glib-2.0/schemas ] && [
> "$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = 1 ]; then
>     # This is the last multiarch variant to be removed, so drop the
>     # architecture-independent compiled schemas
>     rm -f /usr/share/glib-2.0/schemas/gschemas.compiled
>     rmdir -p --ignore-fail-on-non-empty /usr/share/glib-2.0/schemas
> fi
> 
> ... and then you have no GSettings schemas available any more, so
> anything
> that uses GSettings will crash.
> 
> And then when you reverted the transition, you did the same thing in
> reverse:
> 
> > [INSTALL, DEPENDENCIES] libglib2.0-0:amd64 2.78.4-1
> ...
> > [REMOVE (PURGE)] libglib2.0-0t64:amd64 2.78.4-2
> 
> which would have the same problem.

I see. But isn't one more or less supposed to purge?

I mean if there would e.g. ever be a libglib3, and libglib2.0-0 had
e.g. some conffiles (or manually created) files that where still neeed
in libglib3 but some that are obsolete... one would eventually need to
purge in order to clean those up.


> Removing libglib2.0-0 will also remove the GIO modules cache, even
> though
> it is (now) still being used by libglib2.0-0t64. That has a less
> dramatic
> impact, but will break glib-networking and gvfs, which would explain
> some
> bug reports we've seen recently where certificate validation in GLib
> apps
> stops working with a message about there being no trusted CAs. Unlike
> the code path for schemas, this *does* get triggered when libglib2.0-
> 0
> is removed-but-not-purged.

Would that (cache) be re-created by reinstalling?

If not, what would be the end-user steps to clean up from all this? :)



Thanks,
Chris.


term.log.1.xz
Description: application/xz


term.log.2.xz
Description: application/xz

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

On Thu, 2024-02-29 at 06:53 +0100, Paul Gevers wrote:
> Well, officially downgrading isn't supported (although it typically 
> works) *and* losing files is one of the problems of our merged-/usr 
> solution (see [1]). I *suspect* this might be the cause. We're
> working 
> hard (well, helmut is) to protect us and our users from loosing files
> on 
> upgrades. We don't protect against downgrades.
> 
> Obviously there might be issues, but you are running unstable
> *during* a 
> transition. You have to expect some troubles. Thanks for the 
> information, let's see if this is a real issue or not.

Well I didn't mean to complain :-)

As you said, usually downgrades (well rather: purge + install the old
package, here) work,... it's just this time, that it didn't because of
what Simon explained in #1065022 and it took me quite a while to
realise that re-installing solved the issue.

That plus the vanished lib files and that probably more people might be
affected by the issue, made me think that it wouldn't harm to CC d-d :)

Cheers,
Chris.

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

On Wed, 2024-02-28 at 21:57 -0800, Steve Langasek wrote:
> Furthermore, this is a downgrade from a replacing package to a
> replaced
> package. Unless you also --reinstall the package at the end, missing
> files
> are quite to be expected.

Shouldn't that case be something that DPKG could detect and either warn
or automatically re-install... or do it in the right order (first
purge, that installed) and thus prevent the replaced files from being
deleted?

Thanks,
Chris.

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

Attached is the aptitude log.

Cheers,
Chris.
Aptitude 0.8.13: log report
Thu, Feb 29 2024 02:17:21 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 83 packages, and remove 21 packages.
471 kB of disk space will be used

[INSTALL, DEPENDENCIES] gcr4:amd64 4.2.0-3
[INSTALL, DEPENDENCIES] libapt-pkg6.0t64:amd64 2.7.12+nmu1
[INSTALL, DEPENDENCIES] libatk-bridge2.0-0t64:amd64 2.50.0-1.1
[INSTALL, DEPENDENCIES] libatk1.0-0t64:amd64 2.50.0-1.1
[INSTALL, DEPENDENCIES] libatspi2.0-0t64:amd64 2.50.0-1.1
[INSTALL, DEPENDENCIES] libcamel-1.2-64t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libcupsfilters1t64:amd64 1.28.17-3.1
[INSTALL, DEPENDENCIES] libdb5.3t64:amd64 5.3.28+dfsg2-4.1
[INSTALL, DEPENDENCIES] libdirectfb-1.7-7t64:amd64 1.7.7-11.1
[INSTALL, DEPENDENCIES] libebackend-1.2-11t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libebook-1.2-21t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libebook-contacts-1.2-4t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libecal-2.0-2t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedata-book-1.2-27t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedata-cal-2.0-2t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedataserver-1.2-27t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedataserverui-1.2-4t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libevdocument3-4t64:amd64 45.0-2
[INSTALL, DEPENDENCIES] libevview3-3t64:amd64 45.0-2
[INSTALL, DEPENDENCIES] libfontembed1t64:amd64 1.28.17-3.1
[INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-2
[INSTALL, DEPENDENCIES] libpam0t64:amd64 1.5.3-4
[HOLD] eject:amd64 2.38.1-5+b1
[REMOVE (PURGE)] libapt-pkg6.0:amd64 2.7.12
[REMOVE (PURGE)] libatk-bridge2.0-0:amd64 2.50.0-1+b1
[REMOVE (PURGE)] libatk1.0-0:amd64 2.50.0-1+b1
[REMOVE (PURGE)] libatspi2.0-0:amd64 2.50.0-1+b1
[REMOVE (PURGE)] libcamel-1.2-64:amd64 3.50.3-1
[REMOVE (PURGE)] libcupsfilters1:amd64 1.28.17-3+b1
[REMOVE (PURGE)] libdb5.3:amd64 5.3.28+dfsg2-4+b1
[REMOVE (PURGE)] libdirectfb-1.7-7:amd64 1.7.7-11+b1
[REMOVE (PURGE)] libebackend-1.2-11:amd64 3.50.3-1
[REMOVE (PURGE)] libebook-1.2-21:amd64 3.50.3-1
[REMOVE (PURGE)] libebook-contacts-1.2-4:amd64 3.50.3-1
[REMOVE (PURGE)] libecal-2.0-2:amd64 3.50.3-1
[REMOVE (PURGE)] libedata-book-1.2-27:amd64 3.50.3-1
[REMOVE (PURGE)] libedata-cal-2.0-2:amd64 3.50.3-1
[REMOVE (PURGE)] libedataserver-1.2-27:amd64 3.50.3-1
[REMOVE (PURGE)] libedataserverui-1.2-4:amd64 3.50.3-1
[REMOVE (PURGE)] libevdocument3-4:amd64 45.0-1+b1
[REMOVE (PURGE)] libevview3-3:amd64 45.0-1+b1
[REMOVE (PURGE)] libfontembed1:amd64 1.28.17-3+b1
[REMOVE (PURGE)] libglib2.0-0:amd64 2.78.4-1
[REMOVE (PURGE)] libpam0g:amd64 1.5.2-9.1+b1
[UPGRADE] apt:amd64 2.7.12 -> 2.7.12+nmu1
[UPGRADE] apt-doc:amd64 2.7.12 -> 2.7.12+nmu1
[UPGRADE] apt-utils:amd64 2.7.12 -> 2.7.12+nmu1
[UPGRADE] apt-xapian-index:amd64 0.54 -> 0.55
[UPGRADE] at-spi2-common:amd64 2.50.0-1 -> 2.50.0-1.1
[UPGRADE] at-spi2-core:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] btrfs-progs:amd64 6.6.3-1 -> 6.6.3-1.1
[UPGRADE] cups-browsed:amd64 1.28.17-3+b1 -> 1.28.17-3.1
[UPGRADE] cups-filters:amd64 1.28.17-3+b1 -> 1.28.17-3.1
[UPGRADE] cups-filters-core-drivers:amd64 1.28.17-3+b1 -> 1.28.17-3.1
[UPGRADE] evince:amd64 45.0-1+b1 -> 45.0-2
[UPGRADE] evince-common:amd64 45.0-1 -> 45.0-2
[UPGRADE] evolution-data-server:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] evolution-data-server-common:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gcr:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] gir1.2-atk-1.0:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] gir1.2-atspi-2.0:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] gir1.2-camel-1.2:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gir1.2-ecal-2.0:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gir1.2-edataserver-1.2:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gir1.2-pango-1.0:amd64 1.51.0+ds-4 -> 1.52.0+ds-1
[UPGRADE] libasound2-data:amd64 1.2.10-3 -> 1.2.10-3.1
[UPGRADE] libatk-adaptor:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] libaudit-common:amd64 1:3.1.2-2 -> 1:3.1.2-2.1
[UPGRADE] libaudit1:amd64 1:3.1.2-2 -> 1:3.1.2-2.1
[UPGRADE] libboost-filesystem1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-iostreams1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-locale1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-program-options1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-python1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-thread1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libbsd0:amd64 0.12.0-1 -> 0.12.1-1
[UPGRADE] libdirectfb-extra:amd64 1.7.7-11+b1 -> 1.7.7-11.1
[UPGRADE] libgck-1-0:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] libgck-2-2:amd64 4.2.0-2 -> 4.2.0-3
[UPGRADE] libgcr-4-4:amd64 4.2.0-2 -> 4.2.0-3
[UPGRADE] libgcr-base-3-1:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] libgcr-ui-3-1:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] libgegl-common:amd64 1:0.4.48-1 -> 1:0.4.48-2
[UPGRADE] libglib2.0-bin:amd64 2.78.4-1 -> 2.78.4-2
[UPGRADE] libglib2.0-data:amd64 2.78.4-1 -> 2.78.4-2
[UPGRADE] libnss-mymachines:amd64 

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

Package: libglib2.0-0t64
Version: 2.78.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: debian-de...@lists.debian.org

Hey.


CCing d-d since there seems some further deeper problem with the t64
transition (namely lib files getting lost, when "downgrading" i.e.
reverting).


Earlier tonight I've upgraded this day’s packages which included
numerous that made the t64 transition (see the attached aptitude log
for the whole process, first the upgrade, and then "bi-secting" to
find the culprit).

Immediately afterwards, starting GUI programs from the still running
desktop environment caused failures like:
$ evince

(evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
g_settings_schema_source_lookup: assertion 'source != NULL' failed

(evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
g_settings_schema_source_lookup: assertion 'source != NULL' failed

(evince:17537): GLib-GIO-ERROR **: 04:18:22.658: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
$ gedit

(gedit:17585): GLib-GIO-ERROR **: 04:18:35.012: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
$

I suspected a reboot might be needed but after that even the display
manager didn't start anymore.
I saw errors like:
Feb 29 02:51:14 heisenberg kernel: traps: at-spi-bus-laun[17935] trap int3 
ip:7fdceec49587 sp:7ffd0acdade0 error:0 in 
libglib-2.0.so.0.7800.4[7fdceec05000+99000]
Feb 29 02:51:52 heisenberg kernel: traps: at-spi-bus-laun[17941] trap int3 
ip:7f52e53ee587 sp:7ffcc69b0fc0 error:0 in 
libglib-2.0.so.0.7800.4[7f52e53aa000+99000]


My first guess was glib, so I downgraded that (everything from the source
package), but that didn't help.

As you can see from the aptitude log, I then moved on downgrade further
of the previously upgraded packages, several times I've rebooted in-
between (e.g. after downgrading things like *pam* and *systemd*).

Along the way I saw the most weirdest effects:
- logind was apprently in some bogus state, which I think might
  have been the reason, why X/the display manager remained black/hung for
  several minutes:
  Feb 29 03:37:21 heisenberg lightdm[139886]: Failed to get list of logind 
seats: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate 
service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

- At some point, when installing packages via aptitude
  # aptitude
  
  Performing actions...
  
  
  And it also hung at the end shortly after finishing the
  upgrade/downgrade.

- When downgrading packages that had a t64 transition, sometimes
  the lib file was gone.
  I.e. I removed the *t64 package and re-installed the old one
  and then the .so file for libapt-pkg6.0 and libpam0g was missing.
  How can that happen?


Eventually I downgraded the gcr/gck stuff, and then it worked again.

From that I went forward and upgrade all the various packages again, to
see where the problem actuall is.

Turns out, it's probably actually libglib.

When I install the first time libglib2.0-0t64 (and purge libglib2.0-0),
things start to break apart.
When I re-install libglib2.0-0t64, things work again (it seems regardless
of the gcr/gck stuff).


Long story short:
@glib maintainers:
- there's something wrong with the transition (unless even that need for
  the re-install is already a sign for some deeper issues)

@d-d:
- How can it happen that purge *t64 packages and at the same time install
  the previous package, and then the so file is missing?
  I mean it's clear that they use the same name, but shouldn't DPKG handle
  the cleanly?

Thanks,
Chris

PS: I'll attach the aptitude log only to the bug and not to d-d, in
order not to spam so many people with it.
It's probably anyway uselesss, but might help to find out why
downgrading gck/gcr stuff helped first, without re-installing the
glib package.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libglib2.0-0t64 depends on:
ii  libc6 2.37-15
ii  libffi8   3.4.6-1
ii  libmount1 2.39.3-6
ii  libpcre2-8-0  10.42-4+b1
ii  libselinux1   3.5-2
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages libglib2.0-0t64 recommends:
ii  libglib2.0-data   2.78.4-2
ii  shared-mime-info  2.4-1
ii  xdg-user-dirs 0.18-1

Versions of packages libglib2.0-0t64 suggests:
pn  low-memory-monitor  

-- no debconf information

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Christoph Anton Mitterer]

If you really insist on having that functionality, wouldn't it be
anyway better to:

- Add a systemd.timer that regularly (perhaps weekly?) calls
  update-smart-drivedb instead of doing it only once in postinst,
  where it's unlikely to be of much use, because the package was just
  upgraded, so there's a good change that it's drivedb.h is still
  current.
- But even then, please don't run that out of the box.
  Either let people manually enable it or provide a debconf question
  where one can at least choose to opt-out once and for all.
  Though even *with* debconf I'd still prefer if this was an opt-in.


Cheers,
Chris.

Bug#1056736: smartmontools: please do not force people to use update-smart-drivedb and install foreign code

[Christoph Anton Mitterer]

Package: smartmontools
Version: 7.4-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Hey.

The most recent upgrade forces people to use
update-smart-drivedb by doing it already in the postinst and not leaving it
up to the user whether he wants to use such a tool.

Security-wise this is really a bad idea.

Downloader packages (i.e. packages that install further code from
outside Debian) - and this effectively just that - are generally questionable.

Even if the downloader tool does everything right (which is actually quite
difficult if one assumes things like replay or blocking attacks), there's still
code introduced which is not in the control of Debian and especially also
outside security support.

Now you may argue that Debian doesn't audit the drivedb.h it ships either and
that thus security wouldn't be any better if Debian would just ship the
upstream file.
But there's still a difference:
If Debian ships the package, then all installations are guaranteed to get the
same file. So an attacker would need to attack all installation at the same
time and thus be far more likely to be detected.
If however the package is downloaded from some remote server, an attacker can
choose based on IP whether the "good" or the "evil" file is delivered.

And this is not to say that I'd assume smartmontools upstream would be evil.
But even their GPG keys or systemd can be compromised.


The package already has the update-smart-drivedb tool, if people are confident
with using it, they can do so.
But please don't force it on everyone by unconditionally calling it from
postinst (or from anywhere else).


Cheers,
Chris.

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Hey.

Seems a new upstream version is out:
https://github.com/strukturag/libheif/releases/tag/v1.17.0

Cheers,
Chris

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Hey Jeremy



It seems everything is now fixed upstream (see
https://github.com/strukturag/libheif/issues/974).

But upstream also said[0] a new release might follow in the next
days,... so I guess you don't really need to cherry pick the various
commits that were now necessary.


[0] https://github.com/strukturag/libheif/issues/974#issuecomment-1758675718

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Hey Jeremy


On Sat, 2023-09-30 at 05:39 -0400, Jeremy Bícha wrote:
> I pushed my change to the wip/10421242 branch of
> https://salsa.debian.org/multimedia-team/libheif if someone wants to
> do a test build.

I finally came around testing this.

1) building (with all build-deps installed) generally fails for me:
...
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/libheif.so.1.16.2
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/libheif.so.1
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/libheif.so
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/include/x86_64-linux-gnu/libheif/heif.h
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/include/x86_64-linux-gnu/libheif/heif_cxx.h
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/include/x86_64-linux-gnu/libheif/heif_plugin.h
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/include/x86_64-linux-gnu/libheif/heif_version.h
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/libheif/libheif-config.cmake
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/libheif/libheif-config-none.cmake
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/cmake/libheif/libheif-config-version.cmake
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-heif.so
-- Set runtime path of 
"/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-heif.so"
 to ""
-- Installing: 
/home/calestyo/ggg/libheif-1.16.2/debian/tmp/usr/share/thumbnailers/heif.thumbnailer
make[1]: Leaving directory 
'/home/calestyo/ggg/libheif-1.16.2/obj-x86_64-linux-gnu'
   dh_install
dh_install: warning: Cannot find (any matches for) 
"usr/lib/*/libheif/plugins/libheif-rav1e.so" (tried in ., debian/tmp)

dh_install: warning: libheif-plugin-rav1e missing files: 
usr/lib/*/libheif/plugins/libheif-rav1e.so
dh_install: error: missing files, aborting
make: *** [debian/rules:19: binary] Error 255


I first tried disabling the plugin in debian/rules, but that didn't
help,  had to manually remove the file from debian/libheif-plugin-
rav1e.install ... so I guess that particular plugin will be broken ^^


2) With the current version in sid (1.16.2-3), displaying heif files
worked for me with eog, but not geequie.


3) The manual bild with the patch from wip/10421242 also worked with
eog, but also failed with geeqie.

I've opened a new issue upstream:
https://github.com/strukturag/libheif/issues/974


Thanks,
Chris.

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Hey.

Any chance to cherry pick the fixing commit from upstream and upload a
new version with that to unstable?

Thanks,
Chris.

Bug#1043456: tecla: shows nothing and segfaults on keypress

[Christoph Anton Mitterer]

On Fri, 2023-08-11 at 09:36 -0400, Jeremy Bícha wrote:
> Yes, this is a known issue and it's why I am patching out the switch
> from gkbd-display to tecla in GNOME 45 apps until the tecla app
> actually works.

Ah thanks :-)


Cheers,
Chris.

Bug#1043456: tecla: shows nothing and segfaults on keypress

[Christoph Anton Mitterer]

Package: tecla
Version: 45~beta-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hey.

IIRC, this was already the case in the previous version in sid:

When starting tecla, I see only the window and they grey areas for
the keys, but there are no letters/symbols on it.

Also, as soon as I press any key (including modifiers like Alt) while
the window has focus, the program segfaults:
[Aug10 15:23] tecla[207991]: segfault at 18 ip 555840e742e0 sp 
7ffd7e3b7008 error 4 in tecla[555840e72000+4000] likely on CPU 2 (core 4, 
socket 0)
[  +0,34] Code: 18 e8 04 e1 ff ff 48 8b 44 24 28 64 48 2b 04 25 28 00 00 00 
75 0a 48 83 c4 38 48 89 e8 5b 5d c3 e8 25 df ff ff 0f 1f 44 00 00 <48> 8b 7f 18 
e9 07 e0 ff ff 0f 1f 80 00 00 00 00 48 8b 7f 18 e9 47

Any ideas?

Cheers,
Chris.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tecla depends on:
ii  libadwaita-1-0  1.3.4-1
ii  libc6   2.37-7
ii  libglib2.0-02.77.1-2
ii  libgtk-4-1  4.10.5+ds-3
ii  libpango-1.0-0  1.50.14+ds-1
ii  libwayland-client0  1.22.0-2
ii  libxkbcommon0   1.5.0-1

tecla recommends no packages.

tecla suggests no packages.

-- no debconf information

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Control: forwarded -1 https://github.com/strukturag/libheif/issues/933

Hey.

AFAICS, this had also been reported (and fixed meanwhile) upstream.

Cheers,
Chris.

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Hey Joachim.

On Mon, 2023-07-17 at 08:49 +0200, Joachim Bauch wrote:
> do you have any of the "libheif-plugin-*" packages installed with
> 1.16.2?

Quoting myself :-)

On Sun, 2023-07-16 at 14:25 +0200, Christoph Anton Mitterer wrote:
> But after upgrading to 1.16.2-1+b1 dies works no longer (I have all
> the plugins installed).

So unless having them installed *is* causing the troubles, I'd say it's
not a duplicate.


Thanks,
Chris.

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

On Sun, 2023-07-16 at 16:25 +0200, Fabian Greffrath wrote:
> Do you have the heif-gdk-pixbuf package installed? 

Yes:

On Sun, 2023-07-16 at 14:25 +0200, Christoph Anton Mitterer wrote:
> With libheif1, heif-gdk-pixbuf and heif-thumbnailer installed, I was


Cheers,
Chris.

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Weird... I did another upgrade/downgrade cycle and it now works (with
the downgraded version) for eog too.

And I'm pretty sure I checked the first time, whether eog was perhaps
still running and using the old (that is the new version) of the lib.

Bug#1041242: libheif1: 1.16.2-1+b1 breaks displaying any pictures

[Christoph Anton Mitterer]

Package: libheif1
Version: 1.16.2-1+b1
Severity: grave
Justification: renders package unusable

Hey.

With libheif1, heif-gdk-pixbuf and heif-thumbnailer installed, I was able
to display *.heic images from my smartphone in eog, geeqie and gimp.

But after upgrading to 1.16.2-1+b1 dies works no longer (I have all the
plugins installed).

Downgrading to 1.15.1-1 fixes this issue, but interestingly for
geequie and gimp only.


With 1.16.2-1+b1:

For eog there's no really usable debug output:
$ export EOG_DEBUG=1
$ export EOG_DEBUG_IMAGE_DATA=1
$ export EOG_DEBUG_IMAGE_LOAD=1
$ export EOG_DEBUG_PLUGINS=1
$ export EOG_DEBUG_VIEW=1
$ eog 20230607_075801.heic -n
[0,000126 (0,000126)] ../src/eog-plugin-engine.c:72 (eog_plugin_engine_init)
[0,000651 (0,000525)] ../src/eog-plugin-engine.c:129 (eog_plugin_engine_new) 
Adding XDG_DATA_HOME (/home/calestyo/.local/share/eog/plugins) to plugins 
search path
[0,000681 (0,30)] ../src/eog-plugin-engine.c:143 (eog_plugin_engine_new) 
Adding XDG_DATA_DIR /usr/share/gnome/eog/plugins to plugins search path
[0,000686 (0,05)] ../src/eog-plugin-engine.c:143 (eog_plugin_engine_new) 
Adding XDG_DATA_DIR /usr/local/share/eog/plugins to plugins search path
[0,000689 (0,03)] ../src/eog-plugin-engine.c:143 (eog_plugin_engine_new) 
Adding XDG_DATA_DIR /usr/share/eog/plugins to plugins search path
[0,000750 (0,61)] ../src/eog-plugin-engine.c:153 (eog_plugin_engine_new) 
Adding system plugin dir (/usr/lib/x86_64-linux-gnu/eog/plugins)to plugins 
search path
[0,025674 (0,024924)] ../src/eog-job-scheduler.c:95 
(eog_job_scheduler_dequeue_job) No jobs in queue
[0,025686 (0,12)] ../src/eog-job-scheduler.c:102 
(eog_job_scheduler_dequeue_job) Wating for jobs ...

(eog:106648): Handy-WARNING **: 14:16:35.918: Using 
GtkSettings:gtk-application-prefer-dark-theme together with HdyStyleManager is 
unsupported. Please use HdyStyleManager:color-scheme instead.
[0,081792 (0,056106)] ../src/eog-window.c:5143 (eog_window_new)
[0,082591 (0,000799)] ../src/eog-window.c:4567 (eog_window_init)
[0,082872 (0,000281)] ../src/eog-window.c:476 (eog_window_get_display_profile) 
No valid display profile set, assuming sRGB
[0,107066 (0,024194)] ../src/eog-window.c:247 (eog_window_set_gallery_mode)
[0,107520 (0,000454)] ../src/eog-window.c:247 (eog_window_set_gallery_mode)
[0,107526 (0,06)] ../src/eog-window.c:247 (eog_window_set_gallery_mode)
[0,107528 (0,02)] ../src/eog-window.c:358 (eog_window_can_save_changed_cb)
[0,107532 (0,04)] ../src/eog-window.c:700 (update_action_groups_state)
[0,107954 (0,000422)] ../src/eog-window.c:1974 (update_ui_visibility)
[0,108005 (0,51)] ../plugins/fullscreen/eog-fullscreen-plugin.c:117 
(eog_fullscreen_plugin_init) EogFullscreenPlugin initializing
[0,108025 (0,20)] ../plugins/fullscreen/eog-fullscreen-plugin.c:141 
(eog_fullscreen_plugin_activate)
[0,108041 (0,16)] ../src/eog-window.c:5293 (eog_window_open_file_list)
[0,108051 (0,10)] ../src/eog-jobs.c:861 (eog_job_model_new) EogJobModel 
(0x56410689cd40) job was CREATED
[0,108053 (0,02)] ../src/eog-job-scheduler.c:57 
(eog_job_scheduler_enqueue_job) ENQUEUED EogJobModel (0x56410689cd40) with 
priority 2
[0,108175 (0,000122)] ../src/eog-job-scheduler.c:95 
(eog_job_scheduler_dequeue_job) DEQUEUED EogJobModel (0x56410689cd40)
[0,108183 (0,08)] ../src/eog-job-scheduler.c:147 (eog_job_process) 
PROCESSING a EogJobModel (0x56410689cd40)
[0,116799 (0,008616)] ../src/eog-job-scheduler.c:95 
(eog_job_scheduler_dequeue_job) No jobs in queue
[0,116809 (0,10)] ../src/eog-job-scheduler.c:102 
(eog_job_scheduler_dequeue_job) Wating for jobs ...
[0,116939 (0,000130)] ../src/eog-jobs.c:152 (notify_finished) EogJobModel 
(0x56410689cd40) job was FINISHED
[0,116948 (0,09)] ../src/eog-window.c:5201 (eog_job_model_cb)
[0,116974 (0,26)] ../src/eog-window.c:700 (update_action_groups_state)
[1,617610 (1,500636)] ../src/eog-window.c:4660 (eog_window_dispose)
[1,617701 (0,91)] ../plugins/fullscreen/eog-fullscreen-plugin.c:125 
(eog_fullscreen_plugin_dispose) EogFullscreenPlugin disposing
[1,617721 (0,20)] ../src/eog-window.c:1792 (fullscreen_clear_timeout)
[1,617726 (0,05)] ../src/eog-window.c:1824 (slideshow_clear_timeout)


geequie just gives:

warning: heif reader error: Unsupported feature: Unsupported codec

warning: heif reader error: Unsupported feature: Unsupported codec

warning: heif reader error: Unsupported feature: Unsupported codec

warning: heif reader error: Unsupported feature: Unsupported codec


gimp gives:
Opening '20230614_134801.heic' failed: Unknown file type



Any ideas?

Thanks,
Chris.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via 

Bug#1018730: lvm2: Initramfs does not activate root LVs if VG is incomplete since 2.03.15 or 2.03.16, boot failure

[Christoph Anton Mitterer]

Hey Guilhem.

> There might be a better way to detect an initramfs-tools environment

I once faced the same question when writing a (cryptsetup) keyscript,
i.e. how to definitely find out whether one's "within" the initramfs.


With crypsetup it may seem easy - check for e.g. /scripts/local-
top/cryptroot - but that, as well as similar files (like
/conf/initramfs.conf) may in principle also exist after the system has
booted.

The best I could find was checking whether / is of type rootfs:

Something like:

# `grep`’s `-q`-option is not used as it may cause an exit status of `0` even
# when an error occurred.
grep -E '^[^ ]+ [^ ]+ [^ ]+ [^ ]+ / [^ ]+ ([^ ]+ )*- rootfs [^ ]+ [^ ]+$' 
/proc/self/mountinfo >/dev/null 2>/dev/null;  [ "$?" -ne 1 ];



But checking as you do may in practise fully suffice.


Cheers,
Chris.

Bug#1018718: marked as pending in apache2

[Christoph Anton Mitterer]

On Mon, 2023-04-03 at 10:38 +0400, Yadd wrote:

> > Causes that would also make it fix #977014.
> Sure, thanks for the link

You've marked it as fixed but haven't closed it.
Was that on purpose or should I close it?


> I saw in this issue that you were a little frustrated by the lack of 
> responsiveness in apache2 maintenance.

Uhm... don't take that too serious... it was rather just some
unfortunate wording and not really meant critical...


> But apache2 is "RFH" and I'm not 
> C expert neither apache user so I try to do my best until someone
> more 
> qualified takes over.

... in general I highly appreciate the work of any DM/DD :-)


Cheers,
Chris.

Bug#1018718: marked as pending in apache2

[Christoph Anton Mitterer]

Hey.

Thanks for the fix.

Am I right that this *generally* does not longer enable apache2-
doc.conf per default (i.e. also on fresh installs)?

Causes that would also make it fix #977014.

Cheers,
Chris.

Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Christoph Anton Mitterer]

On Wed, 2023-03-08 at 14:04 +0100, Guilhem Moulin wrote:
> No please don't, #-1 is RC so that would block transitioning into
> Bookworm which only supports merged-usr…  Will fix that later during
> the
> freeze, but ATM the priority is to get -2 into Bookworm ASAP, not
> further delay the transition.

Well but at least right now people without merged /usr will still end
up in a broken system?

And there is no guarantee that /usr has already been merged at that
point... I mean it should, when the upgrade to bookwork completes...
but can it happen that it's interrupted? Or that people do it in
several steps? Then they could upgrade argon2, reboot and have the
missing libgcc.

Anyway... thanks for taking care :-)


Cheers,
Chris.

Bug#1032221: [pkg-cryptsetup-devel] Bug#1032221: Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Christoph Anton Mitterer]

Control: reopen -1

On Wed, 2023-03-08 at 08:16 +0100, Milan Broz wrote:
> Just upstream is no longer responding here...

Seems upstream is dead... I also have some minor PRs open against
argon2, but no response. Tried to get directly in contact with some of
them, but the same.

@Guilhem, I'm reopening this for now.


Cheers,
Chris.

Bug#1032221: [pkg-cryptsetup-devel] Bug#1032221: cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work

[Christoph Anton Mitterer]

Hey Guilhem.

Is it possible that your fix doesn't work on not-yet-usr-merged
systems?

I get here:
$ env --unset=LD_PRELOAD ldd /sbin/cryptsetup | sed -nr 
'/.*=>\s*(\S+)\/libargon2\.so\..*/ {s//\1/p;q}'
/usr/lib/x86_64-linux-gnu


but:
$ dpkg -L libgcc-s1 
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libgcc_s.so.1


On non-usr-merged systems, copy_libgcc doesn't seem to include it then.

Please don't solve this by depending on usr-merge (not that I'd have
anything against it, but I'd like to migrate my systems only when this
becomes the next stable).


Cheers,
Chris.

Bug#1027854: kismet-plugins: uninstallable due to dependency on libssl1.1

[Christoph Anton Mitterer]

Package: kismet-plugins
Version: 2016.07.R1-1+b1
Severity: grave
Justification: renders package unusable


Hey.

libssl1.1 has been removed from unstable and thus kismet-plugins is no
longer installable.

Cheers,
Chris.

Bug#1027766: vim: backspace doesn't remove characters anymore

[Christoph Anton Mitterer]

Control: tags -1 - ftbfs
Control: severity -1 important

Still not used to reportbug's new numbering...

Bug#1027766: vim: backspace doesn't remove characters anymore

[Christoph Anton Mitterer]

Package: vim
Version: 2:9.0.1000-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)


Hey.

The following probably still worked with 2:9.0.1000-1, but definitely works 
again
when going back to the version in testing (2:9.0.0813-1+b1).

When I edit a file (pre-existing or new) I can only remove characters with
backspace when I've added them previously when in edit-mode.
As soon as I leave that, then go back into edit-mode and then backspace, it 
doesn't
work anymore.

Seemed to be "specific to "my" configuration though, as it does work with 
--clean.
However, after bisecting all my vimrc’s options, none seemed to have caused it 
and
even if I fully empty the file it still doesn't work (only when I move it away).

Find my .vim/vimrc attached.


Thanks,
Chris.

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk3
/usr/bin/vim is /usr/bin/vim.gtk3
/usr/bin/gvim is /usr/bin/vim.gtk3

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vim depends on:
ii  libacl1  2.3.1-2
ii  libc62.36-7
ii  libgpm2  1.20.7-10+b1
ii  libselinux1  3.4-1+b4
ii  libsodium23  1.0.18-1
ii  libtinfo66.4-1
ii  vim-common   2:9.0.1000-2
ii  vim-runtime  2:9.0.1000-2

vim recommends no packages.

Versions of packages vim suggests:
ii  universal-ctags [ctags]  5.9.20210829.0-1
ii  vim-doc  2:9.0.1000-2
ii  vim-scripts  20210124.2

-- no debconf information
set viminfo+=n~/.vim/viminfo
set termguicolors


filetype plugin on

highlight Normal guifg=White guibg=Black
syntax enable

autocmd ColorScheme * highlight ExtraWhitespace ctermbg=red guibg=red
highlight ExtraWhitespace ctermbg=red guibg=red
autocmd InsertEnter * match ExtraWhitespace /\s\+\%#\@  :silent :set hlsearch! hlsearch?:if 
ExtraWhitespace:match none:let ExtraWhitespace=0:else:match 
ExtraWhitespace /\s\+$\| \+\ze\t/:redraw!:let 
ExtraWhitespace=1:endif
"noremap   :silent :set hlsearch! hlsearch?

set nowrap

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

Hey Pierre.

On Tue, 2022-12-06 at 23:08 +0100, Pierre Gruet wrote:
> Thanks for the bug report (and the follow-up precisions you sent)!
> 
> Yet I fail to reproduce it on testing. I installed zookeeper and 
> zookeeperd on testing, then ran
> 
> $ /usr/share/zookeeper/bin/zkCli.sh
> specifying nothing about the classpath (it is already handled in the 
> MANIFEST.MF file of the zookeeper jar), and I could enter commands 
> (though with no prompt, as you say).

When you've started your zookeeper (I assume you also use the sysvinit
script, respectively the virtual systemd unit generated from that?),
what does your process' command line show, e.g.:
# ps ax | grep org.apache.zookeeper.server.quorum.QuorumPeerMain
   3156 ?Sl   167:08 /usr/bin/java -cp 
/etc/zookeeper/conf:/usr/share/java/zookeeper.jar:/usr/share/java/slf4j-log4j12.jar:/usr/share/java/log4j-1.2.jar
 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=true 
-Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,ROLLINGFILE 
org.apache.zookeeper.server.quorum.QuorumPeerMain /etc/zookeeper/conf/zoo.cfg

Especially, which CLASSPATH (seems to be the -cp)?

Is your test system clustered (i.e. more than one ZK node?)?


> (However, I also get the hanging issue if I do not install
> zookeeperd.)

Well I guess that's clear, cause then nothing would have started
zookeeper?!



> I guess there is some difference in the versions of the dependencies 
> between stable and testing, as you underline that the dependencies
> come 
> from stable.

That would be quite surprising, IMO,.. cause the issue seems to be
quite clearly the missing CLASSPATH stuff.

I mean if there would be some other package, that is used to start the
java process... and that other package would have a different version
and thus be incompatible, I could imagine this.

But it seems as if zookeeper's sysvinit script does all on it's own and
simply execute java in the end.

So it's hard to imagine, that something interferes, and somehow breaks
the CLASSPATH there?!



> Concerning the SLF4J warning: in the past I already stumbled upon
> this 
> and visited the URI
> https://www.slf4j.org/codes.html#StaticLoggerBinder
> which is in the warning message.

Yeah, also stumbled over that via the error message.


>  Because of the last paragraph in the
> relevant section therein, I was unsure I should choose a SLF4J
> binding 
> as this would impose my choice to the end user. What do you think?

Well since that two infamous security holes, log4j has a somewhat
damaged reputation ;-) ... but apart from that I think this would make
the most sense here.

As I've said in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025012#20 :

/usr/share/java/slf4j-log4j12.jar wasn't enough for me and I needed to
add /usr/share/java/log4j-1.2.jar to the CLASSPATH instead, in order to
get output to /var/log/zookeeper


> Finally, as:
> - I think there is a mismatch somewhere in the versions of the 
> dependencies between stable and testing;
> - I cannot reproduce on a system with dependencies fetched from
> testing 
> only,
> I would tend to discuss only the SLF4J issue and ignore the rest.
> 
> Please tell me what you think,

I think we should look into both, and at best split things apart.

I mean I can try to reproduce the whole thing on a sid or testing only
systemd an see whether it still fails to start, but right now I'd be
quite surprised why it wouldn't start because of that... and even *if*
that would be the reason, then bullseye to bookwork upgrades need to be
supported, and therefore the package (zookeeper) would need to have
correct versioned dependencies (*if* it's because of a incompatible
version of some dependency).


Thanks,
Chris.

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

And here we go:
CLASSPATH="/etc/zookeeper/conf:/usr/share/java/zookeeper.jar:/usr/share/java/slf4j-log4j12.jar:/usr/share/java/log4j-1.2.jar"

Seems to do the trick to get logging to /var/log/zookeeper/foobar .
The zkCli shows still no prompt, though.

It also needs the /usr/share/java/log4j-1.2.jar, 
/usr/share/java/slf4j-log4j12.jar alone ain't enough.


I wonder a bit whether the classpath is just completely mess up?

When installing, I needed the following dependencies:
[INSTALL, DEPENDENCIES] junit4:amd64 4.13.1-2
[INSTALL, DEPENDENCIES] libactivation-java:amd64 1.2.0-2
[INSTALL, DEPENDENCIES] libapache-pom-java:amd64 18-1
[INSTALL, DEPENDENCIES] libasm-java:amd64 9.1-1
[INSTALL, DEPENDENCIES] libatinject-jsr330-api-java:amd64 1.0+ds1-5
[INSTALL, DEPENDENCIES] libcommons-cli-java:amd64 1.4-2
[INSTALL, DEPENDENCIES] libcommons-io-java:amd64 2.8.0-1
[INSTALL, DEPENDENCIES] libcommons-logging-java:amd64 1.2-2
[INSTALL, DEPENDENCIES] libcommons-parent-java:amd64 43-1
[INSTALL, DEPENDENCIES] libdropwizard-metrics-java:amd64 3.2.6-1
[INSTALL, DEPENDENCIES] libeclipse-jdt-core-java:amd64 3.24.0+eclipse4.18-1
[INSTALL, DEPENDENCIES] libel-api-java:amd64 3.0.0-3
[INSTALL, DEPENDENCIES] libfindbugs-annotations-java:amd64 3.1.0~preview2-3
[INSTALL, DEPENDENCIES] libguava-java:amd64 29.0-6
[INSTALL, DEPENDENCIES] libhamcrest-java:amd64 1.3-9
[INSTALL, DEPENDENCIES] libjackson2-annotations-java:amd64 2.12.1-1
[INSTALL, DEPENDENCIES] libjackson2-core-java:amd64 2.12.1-1
[INSTALL, DEPENDENCIES] libjackson2-databind-java:amd64 2.12.1-1+deb11u1
[INSTALL, DEPENDENCIES] libjaxb-api-java:amd64 2.3.1-1
[INSTALL, DEPENDENCIES] libjctools-java:amd64 2.0.2-1
[INSTALL, DEPENDENCIES] libjetty9-extra-java:amd64 9.4.39-3+deb11u1
[INSTALL, DEPENDENCIES] libjetty9-java:amd64 9.4.39-3+deb11u1
[INSTALL, DEPENDENCIES] libjffi-java:amd64 1.2.7-11
[INSTALL, DEPENDENCIES] libjffi-jni:amd64 1.2.7-11+b1
[INSTALL, DEPENDENCIES] libjnr-constants-java:amd64 0.10.1-1
[INSTALL, DEPENDENCIES] libjnr-enxio-java:amd64 0.32.3-2
[INSTALL, DEPENDENCIES] libjnr-ffi-java:amd64 2.1.7-1
[INSTALL, DEPENDENCIES] libjnr-posix-java:amd64 3.0.45-2
[INSTALL, DEPENDENCIES] libjnr-unixsocket-java:amd64 0.18-4
[INSTALL, DEPENDENCIES] libjnr-x86asm-java:amd64 1.0.2-5.1
[INSTALL, DEPENDENCIES] libjsp-api-java:amd64 2.3.4-3
[INSTALL, DEPENDENCIES] libjsr305-java:amd64 0.1~+svn49-11
[INSTALL, DEPENDENCIES] liblog4j1.2-java:amd64 1.2.17-10+deb11u1
[INSTALL, DEPENDENCIES] libmail-java:amd64 1.6.5-1
[INSTALL, DEPENDENCIES] libnetty-java:amd64 1:4.1.48-4
[INSTALL, DEPENDENCIES] libnetty-tcnative-java:amd64 2.0.28-1
[INSTALL, DEPENDENCIES] libnetty-tcnative-jni:amd64 2.0.28-1
[INSTALL, DEPENDENCIES] libservlet-api-java:amd64 4.0.1-2
[INSTALL, DEPENDENCIES] libservlet3.1-java:amd64 1:4.0.1-2
[INSTALL, DEPENDENCIES] libslf4j-java:amd64 1.7.30-1
[INSTALL, DEPENDENCIES] libsnappy-java:amd64 1.1.8.3-1
[INSTALL, DEPENDENCIES] libsnappy-jni:amd64 1.1.8.3-1
[INSTALL, DEPENDENCIES] libsnappy1v5:amd64 1.1.8-1
[INSTALL, DEPENDENCIES] libspring-beans-java:amd64 4.3.30-1
[INSTALL, DEPENDENCIES] libspring-core-java:amd64 4.3.30-1
[INSTALL, DEPENDENCIES] libtaglibs-standard-impl-java:amd64 1.2.5-2.1
[INSTALL, DEPENDENCIES] libtaglibs-standard-spec-java:amd64 1.2.5-2.1
[INSTALL, DEPENDENCIES] libtomcat9-java:amd64 9.0.43-2~deb11u4
[INSTALL, DEPENDENCIES] libwebsocket-api-java:amd64 1.1-2
[INSTALL, DEPENDENCIES] libzookeeper-java:amd64 3.8.0-10
[INSTALL, DEPENDENCIES] zookeeperd:amd64 3.8.0-10
[INSTALL] zookeeper:amd64 3.8.0-10

Wouldn't there need to be some CLASSPATH settings for more or less all
of them?

I guess there's at least a problem with that:
2022-11-28 21:41:34,760 - WARN  [main:AdminServerFactory@58] - Unable to load 
jetty, not starting JettyAdminServer
java.lang.NoClassDefFoundError: javax/servlet/Servlet
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at 
org.apache.zookeeper.server.admin.AdminServerFactory.createAdminServer(AdminServerFactory.java:43)
at 
org.apache.zookeeper.server.quorum.QuorumPeer.(QuorumPeer.java:1070)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.getQuorumPeer(QuorumPeerMain.java:246)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:177)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:137)
at 
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:91)
Caused by: java.lang.ClassNotFoundException: javax.servlet.Servlet
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 8 more



Thanks,
Chris.

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

I got a bit further:

Setting:
CLASSPATH="/etc/zookeeper/conf:/usr/share/java/zookeeper.jar:/usr/share/java/slf4j-simple.jar"
i.e. adding the ":/usr/share/java/slf4j-simple.jar" helps a bit...

The server seems to start now, and via zkCli, I can `ls` my paths and
`get` values.

But there's still no logging (neither to file nor to systemd)...


...and zkCli used to show a "prompt" like:
[zk: localhost:2181(CONNECTED) 3] commands go here

but now, there is nothing, though I can enter commands.

May be unrelated though

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

I should perhaps add, that I have installed the zookeeper packages
(zookeeper zookeeperd libzookeeper-java) from testing into stable
(bullseye), all other dependencies were already met with bullseye
versions.

Also, according to https://www.slf4j.org/codes.html#StaticLoggerBinder
and there the question "Failed to load class
org.slf4j.impl.StaticLoggerBinder"... the files "slf4j-nop.jar slf4j-
simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar"
are needed,... but any except for the latter is in place.

All are in /usr/share/java.

Though manually adding this to the CLASSPATH in
/etc/zookeeper/conf/environment doesn't seem to help.

Bug#1025012: zookeeper: starts but is completely unusable

[Christoph Anton Mitterer]

Package: zookeeper
Version: 3.8.0-10
Severity: grave
Justification: renders package unusable


Hey.

I've tried the new packagin, but while all my config and data files are in 
place,
and while the server "runs", there is no logging (neither to stdout/err for 
systemd
nor /var/log/zookeeper .. not even any files get created in there).

Connecting via zkCli gives:
# /usr/share/zookeeper/bin/zkCli.sh
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further 
details.
Connecting to localhost:2181
Welcome to ZooKeeper!
JLine support is disabled
SLF4J: Failed to load class "org.slf4j.impl.StaticMDCBinder".
SLF4J: Defaulting to no-operation MDCAdapter implementation.
SLF4J: See http://www.slf4j.org/codes.html#no_static_mdc_binder for further 
details.



Perhaps some missing dependency?


Thanks,
Chris.

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Christoph Anton Mitterer]

Hey.

I've just installed this again on some node, and for some reason apt-
listbugs still shows it as open:
# aptitude
Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of liblog4j1.2-java (→ 1.2.17-10+deb11u1) 
 b1 - #1004482 - liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302 
(Fixed: apache-log4j1.2/1.2.17-11)
Summary:
 liblog4j1.2-java(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] 


But that's the one now installed:
   liblog4j1.2-java 1.2.17-10+deb11u1
which, AFAIU should contain the fixes, right?

Does it need a:
  Control: fixed -1 1.2.17-10+deb11u1
?



Cheers,
Chris.

Bug#1024674: libphonenumber8: breaks Evolution

[Christoph Anton Mitterer]

On Tue, 2022-11-22 at 21:11 -0800, tony mancill wrote:
> Yes, totally.  I didn't mean to imply that the bug shouldn't be here.

Sure... just wanted to point out, that I don't consider it your fault
or so :-)



> > I had evolution running, while I've upgraded. And didn't restart it
> > afterwards (at least not immediately).
> > 
> > I then noticed some weird things... when replying to a mail, there
> > was
> > no quoting of the mail I replied to (i.e. I got a new compose
> > window,
> > but no text in it).
> > Also I couldn't save my composed mail as draft (some strange error
> > popup within evolution itself).
> 
> Interesting...

Interesting word for weird ;-)

I guess it must be doing some kind of dynamic loading stuff? OTOH, it
seems to be just linked as a plain shared lib:
$ libtree /usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4.0.0
libebook-contacts-1.2.so.4 
├── libedataserver-1.2.so.27 [ld.so.conf]
...
├── libphonenumber.so.8 [ld.so.conf]
│   ├── libprotobuf.so.23 [ld.so.conf]
│   │   └── libz.so.1 [ld.so.conf]
│   ├── libabsl_throw_delegate.so.20220623 [ld.so.conf]
│   ├── libabsl_strings.so.20220623 [ld.so.conf]
│   │   ├── libabsl_strings_internal.so.20220623 [ld.so.conf]
│   │   │   └── libabsl_raw_logging_internal.so.20220623 [ld.so.conf]
│   │   ├── libabsl_raw_logging_internal.so.20220623 [ld.so.conf]
│   │   └── libabsl_throw_delegate.so.20220623 [ld.so.conf]
│   ├── libabsl_raw_hash_set.so.20220623 [ld.so.conf]
│   ├── libabsl_hash.so.20220623 [ld.so.conf]
│   │   ├── libabsl_city.so.20220623 [ld.so.conf]
│   │   └── libabsl_low_level_hash.so.20220623 [ld.so.conf]
│   ├── libicui18n.so.72 [ld.so.conf]
│   └── libicuuc.so.72 [ld.so.conf]
...

 
> > Since I suspected some issues, I restarted evolution, and only then
> > I've noticed the libphonenumber related error I've mentioned in the
> > initial mail.
> 
> Ugh, so it's completely broken for you now.

Yes... at least evolution, but that's the only thing I have, which
depends on it.

Maybe we should increase the severity, so that people will see it at
least via apt-listbugs?


Thanks :-)
Chris.
> 

Bug#1024674: libphonenumber8: breaks Evolution

[Christoph Anton Mitterer]

Hey Tony.

On Tue, 2022-11-22 at 20:40 -0800, tony mancill wrote:
> Thank you for the bug report.  libphonenumber 8.12.57+ds-1 has been
> in
> testing for longer than a month at this point [1].  Has it been
> broken
> all of this time?  If not, I suspect this is related the protobuf
> transition [2].

No, it was fine all the time with 8.12.57+ds-1+b1 (and backporting to
it fixes the issue, too). Only 8.12.57+ds-1+b2 introduced the problem.

So yes, it may be related to the transition.

But given that the dependency for evolution (or rather libebook-
contacts-1.2-4) I thought the starting point of "responsibility" (in
terms of package dependencies) should be there.



> I'm not seeing the crash here, but I'm running vanilla unstable and
> not
> unstable-debug

I don't think this makes a difference... the unstable-debug is just
there because I have the debug repo enabled, but the packages are from
unstable:
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
^
|

> You mention that it crashes
> and that it ends up in a weird state while it's running.  Does that
> mean
> it crashes and exits sometimes?  Or that logs an error and continues
> running?

No,... sorry for not describing it clearly.

I had evolution running, while I've upgraded. And didn't restart it
afterwards (at least not immediately).

I then noticed some weird things... when replying to a mail, there was
no quoting of the mail I replied to (i.e. I got a new compose window,
but no text in it).
Also I couldn't save my composed mail as draft (some strange error
popup within evolution itself).

Since I suspected some issues, I restarted evolution, and only then
I've noticed the libphonenumber related error I've mentioned in the
initial mail.


Perhaps we should get the protobuf people on board in this issue?


Thanks,
Chris.

Bug#1024674: libphonenumber8: breaks Evolution

[Christoph Anton Mitterer]

Package: libphonenumber8
Version: 8.12.57+ds-1+b2
Severity: serious


Hey.

After the upgrade, evolution crashes when started:
$ evolution
evolution: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/libebook-contacts-1.2.so.4: undefined symbol: 
_ZN4i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE

and it even ended up in a weird state while it was still running.

Cheers,
Chris.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libphonenumber8 depends on:
ii  libabsl20220623  20220623.1-1
ii  libc62.36-5
ii  libgcc-s112.2.0-9
ii  libicu72 72.1-2
ii  libprotobuf323.21.9-4
ii  libstdc++6   12.2.0-9

libphonenumber8 recommends no packages.

libphonenumber8 suggests no packages.

-- no debconf information

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Christoph Anton Mitterer]

On Sat, 2022-10-29 at 09:23 +0200, Salvatore Bonaccorso wrote:
> 
> No unfortunately we cannot do that. The reason is similar to what
> lead
> to
> https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71
> or caused bugs like #916927.

Forgive me my ignorance, but from the package's file list I'd assume
that the signatures are included in the kernel image respectively the
module files themselves?

Is that a must, or could they be standalone signatures?

Cause if the latter, wouldn't something like the following be possible:
- have only one package that actually contains the kernel and modules
  (and that would be available earlier)
- have that depend on a separate package that ships the standalone
  signatures

That would have the benefit that there are no "duplicate" packages, and
people could create a dummy for the signature package with e.g. equivs.

> The signed packages need always longer as this needs action of
> signing
> them trough a seprate manual process of ftp-masters.

Sure, clear.


Best wishes,
Chris.

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Christoph Anton Mitterer]

Hey Salvatore.

On Fri, 2022-10-28 at 06:49 +0200, Salvatore Bonaccorso wrote:
> I did decide to still do so, so we can have the CVE fix migrate
> finally to testing (which took some time as well given there was the
> perl transition ongoing).

Fine for me... I think it would be nice if there was a better mechanism
to have bugs shown in apt-listbugs out of the box, while still not
preventing migration to testing.


Oh and another off-topic thing:

Right now the kernel image meta-packages depend on the (secure boot)
signed version of that... and it seems that these take always longer to
be available than the unsigned ones.

However, if people want the nice service to have linux-image-amd64
installed and pull in just the current package, they need to wait for
the signed one to become available - even if they don't use secure boot
at all.

So question is,.. would it make sense to request that linux-image-amd64
depends on the signed | unsigned version?



> I did import already 6.0.5 and will upload next so we get the btrfs
> fix. And I have made the bug now as well again back RC severity.

Thanks as always for your continued efforts.


Cheers,
Chris.

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Christoph Anton Mitterer]

Control: retitle -1 6.0.5 fixes critical btrfs bug in 6.0.3, affecting space 
cache v1 filesystems
Control: notfound -1 5.19.6-1
Control: found -1 6.0.3-1


No idea why reportbug picked 5.19.6, which I have not even installed
anymore... o.O

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Christoph Anton Mitterer]

Source: linux
Version: 5.19.6-1
Severity: critical
Justification: breaks the whole system


Hi.

6.0.3 introduced a commit that causes (permanent) CPU soft lockups
for some people with btrfs filesystems, effectively breaking the
system, e.g. when booting.

See e.g.
https://lore.kernel.org/linux-btrfs/2291416ef48d98059f9fdc5d865b0ff040148237.ca...@scientia.org/T/#u
https://lore.kernel.org/linux-btrfs/1c531dd5de7477c8b6ec15d4aebb8e42ae460925.ca...@scientia.org/T/#t
https://lore.kernel.org/linux-btrfs/Y1krzbq3zdYOSQYG@bulldog/T/#u
https://lore.kernel.org/all/10522366-5c17-c18f-523c-b97c14969...@net4u.de/
https://bugs.archlinux.org/task/76266



6.0.5 is ought to fix that, could you please upgrade sid ASAP? :-)

See:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.0.5=217fd7557896d990c3dd8beea83a6feeb504f235


Thanks,
Chris.

Bug#1018686: libgtkhex-4-1: cannot be upgraded

[Christoph Anton Mitterer]

Package: libgtkhex-4-1
Version: 43~alpha-1
Severity: grave
Justification: renders package unusable


Hey.

When trying to upgrade:
Unpacking libgtkhex-4-1:amd64 (43~alpha-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgtkhex-4-1_43~alpha-1_amd64.deb (--unpack):
 trying to overwrite 
'/usr/lib/x86_64-linux-gnu/gtkhex-4.0/libhex-buffer-mmap.so', which is also in 
package libgtkhex-4-0:amd64 42.3-1


Cheers,
Chris.

Bug#1017840: debian-security-support: cannot create /var/lib/debian-security-support/security-support.semaphore: Permission

[Christoph Anton Mitterer]

On Tue, 2022-08-23 at 16:23 +, Holger Levsen wrote:
> users must not be cleaned up (=removed) on package removal

Well perhaps not a must as per policy, but I think for debian-security-
support it would still make sense to clean up the user, or do you
expect anyone to create files under that user which would then have no
valid user/group? :-)


Cheers,
Chris.

Bug#1017840: debian-security-support: cannot create /var/lib/debian-security-support/security-support.semaphore: Permission

[Christoph Anton Mitterer]

Hey Holger.


It also seems as if neither that director or its files nor the created
user is ever cleaned up on purge, but left behind as cruft forever.

Or did I oversee something in the posrm?


Thanks,
Chris.

Bug#1012275: closing 1012275

[Christoph Anton Mitterer]

On Fri, 2022-06-10 at 05:09 +0900, Mike Hommey wrote:
> There's a 101.0.1 on the way.

I assume you mean "being built for Debian"?

Anyway... thanks for taking care. :-)

Cheers,
Chris.

Bug#1012275: closing 1012275

[Christoph Anton Mitterer]

Could someone then possibly rebuild this with Julian’s patch, ASAP?

Over a week with a likely remote code exploit hole in the browser of
any Debian (non-ESR) FF user, seems not so ideal,

Thanks,
Chris.

Bug#1012275: closing 1012275

[Christoph Anton Mitterer]

On Sat, 2022-06-04 at 14:42 +0200, Vincent Bernat wrote:
> Unfortunately, Firefox is not buildable due to depending on a version
> of
> Cargo not available in unstable.

Shouldn't that be reopened then?

I wouldn't be surprised if quite a number of people use the non ESR FF,
probably also DDs/DMs.

And because of rust deps, it seems to happen more often now, that
security critical upgrades cannot enter unstable. (And yes I'm well
aware, that unstable has no official security support, but still).


Cheers,
Chris.

Bug#1012275: firefox: new upstream version fixes possible RCE security holes

[Christoph Anton Mitterer]

Package: firefox
Version: 100.0.2-1
Severity: serious
Tags: security ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: Debian Security Team 


Hi.

Would be good to see 101 packaged ASAP, as it fixes numerous issues,
including some which are apparently thought to allow remote code
execution.


Cheers,
Chris.

Bug#1010192: ModuleNotFoundError: No module named 'qrtools'

[Christoph Anton Mitterer]

Package: qtqr
Version: 2.1~bzr46-2
Severity: grave
Justification: renders package unusable


Hey.

On a fresh install of the package:
$ qtqr
Traceback (most recent call last):
  File "/usr/bin/qtqr", line 15, in 
from qrtools import QR
ModuleNotFoundError: No module named 'qrtools'


Thanks,
Chris.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qtqr depends on:
ii  python3-pyqt55.15.6+dfsg-1+b2
ii  python3-qrtools  2.1~bzr46-2

qtqr recommends no packages.

qtqr suggests no packages.

-- no debconf information

Bug#1008817: libphonenumber8: breaks evolution

[Christoph Anton Mitterer]

On Sat, 2022-04-02 at 08:14 -0700, tony mancill wrote:
> Thank you for the bug report Chris, for setting the severity so
> as to block the migration, and noting the affected packages.

Actually, the latter two were done by some other helpers :-)


Thanks,
Chris.

Bug#1008817: libphonenumber8: breaks evolution

[Christoph Anton Mitterer]

Package: libphonenumber8
Version: 8.12.46-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)


Hi.

8.12.46-1 causes evolution to fail:
$ evolution
evolution: symbol lookup error: /usr/lib/x86_64-linux-gnu/libphonenumber.so.8: 
undefined symbol: _ZN4absl7debian213hash_internal9HashState5kSeedE

Downgrading to 8.12.44-1 fixes the issue.

Cheers,
Chris.



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libphonenumber8 depends on:
ii  libabsl20210324  0~20210324.2-2
ii  libc62.33-7
ii  libgcc-s112-20220319-1
ii  libicu67 67.1-7
ii  libprotobuf233.12.4-1+b3
ii  libstdc++6   12-20220319-1

libphonenumber8 recommends no packages.

libphonenumber8 suggests no packages.

-- no debconf information

Bug#1007992: libigdgmm12: new version causes segfaults

[Christoph Anton Mitterer]

On Sun, 2022-03-20 at 07:07 +0100, Paul Menzel wrote:
> Firefox with VA-API enabled crashes too,
> but not when it’s disabled.


> Do you have VA-API enabled for mpv?
I do have:
hwdec=auto

in mpv.conf, which I think would use vaapi here.

However, I have nothing specifically set for VLC.


Thanks,
Chris.

Bug#1007992: libigdgmm12: new version causes segfaults

[Christoph Anton Mitterer]

Package: libigdgmm12
Version: 22.1.1+ds1-1
Severity: critical
Justification: breaks unrelated software


Hey.


This version breaks e.g. video playback with mpv (also vlc):
$ mpv test.mp4
 (+) Video --vid=1 (h264 720x300 23.976fps)
 (+) Audio --aid=1 (aac 2ch 44100Hz)
Segmentation fault


With:
Mar 20 04:30:17 heisenberg kernel: mpv/vo[292810]: segfault at 30200 ip 
7f93a01e49ae sp 7f93ab2514b0 error 4 in 
libigdgmm.so.12.1.0[7f93a017b000+78000]
Mar 20 04:30:17 heisenberg kernel: Code: ff 4c 8b 55 c8 31 c0 b9 40 00 00 00 4c 
8b 45 b8 4c 89 fe 49 8d 92 b0 33 00 00 48 89 d7 f3 41 0f 6f 00 ba c4 06 00 00 
f3 48 ab <49> 8b 06 49 8d 7a 44 41 c7 82 b8 35 00 00 0a 00 00 00 f3 41 0f 6f
Mar 20 04:30:22 heisenberg kernel: mpv/vo[292830]: segfault at 30200 ip 
7fb5381d49ae sp 7fb53b4564b0 error 4 in 
libigdgmm.so.12.1.0[7fb53816b000+78000]
Mar 20 04:30:22 heisenberg kernel: Code: ff 4c 8b 55 c8 31 c0 b9 40 00 00 00 4c 
8b 45 b8 4c 89 fe 49 8d 92 b0 33 00 00 48 89 d7 f3 41 0f 6f 00 ba c4 06 00 00 
f3 48 ab <49> 8b 06 49 8d 7a 44 41 c7 82 b8 35 00 00 0a 00 00 00 f3 41 0f 6f
Mar 20 04:30:23 heisenberg kernel: mpv/vo[292850]: segfault at 30200 ip 
7f57901de9ae sp 7f579ea9f4b0 error 4 in 
libigdgmm.so.12.1.0[7f5790175000+78000]
Mar 20 04:30:23 heisenberg kernel: Code: ff 4c 8b 55 c8 31 c0 b9 40 00 00 00 4c 
8b 45 b8 4c 89 fe 49 8d 92 b0 33 00 00 48 89 d7 f3 41 0f 6f 00 ba c4 06 00 00 
f3 48 ab <49> 8b 06 49 8d 7a 44 41 c7 82 b8 35 00 00 0a 00 00 00 f3 41 0f 6f
Mar 20 04:30:30 heisenberg kernel: vlc[292895]: segfault at 30200 ip 
7f94f12fb9ae sp 7f94f105bb00 error 4 in 
libigdgmm.so.12.1.0[7f94f1292000+78000]
Mar 20 04:30:30 heisenberg kernel: Code: ff 4c 8b 55 c8 31 c0 b9 40 00 00 00 4c 
8b 45 b8 4c 89 fe 49 8d 92 b0 33 00 00 48 89 d7 f3 41 0f 6f 00 ba c4 06 00 00 
f3 48 ab <49> 8b 06 49 8d 7a 44 41 c7 82 b8 35 00 00 0a 00 00 00 f3 41 0f 6f
Mar 20 04:31:20 heisenberg kernel: mpv/vo[293088]: segfault at 30200 ip 
7f923547a9ae sp 7f925251a4b0 error 4 in 
libigdgmm.so.12.1.0[7f9235411000+78000]
Mar 20 04:31:20 heisenberg kernel: Code: ff 4c 8b 55 c8 31 c0 b9 40 00 00 00 4c 
8b 45 b8 4c 89 fe 49 8d 92 b0 33 00 00 48 89 d7 f3 41 0f 6f 00 ba c4 06 00 00 
f3 48 ab <49> 8b 06 49 8d 7a 44 41 c7 82 b8 35 00 00 0a 00 00 00 f3 41 0f 6f


Downgrading to 22.0.2+ds1-1 fixes the issue.


Cheers,
Chris.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libigdgmm12 depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libstdc++6  12-20220319-1

libigdgmm12 recommends no packages.

libigdgmm12 suggests no packages.

-- no debconf information

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Christoph Anton Mitterer]

Hey.

Is that going to be fixed in stable, too?

Cheers,
Chris.

Bug#990345: zookeeper: various security issues

[Christoph Anton Mitterer]

Further for the records (for a future upgrade to newer ZK versions):


There will likely need to be a NEWS.Debian entry about the following:

https://issues.apache.org/jira/browse/ZOOKEEPER-3056

In short:
- apparently they've added a check that prevents ZK from starting, when
no snapshots were found in the dataDir

- the workaround is to ONCE set
  snapshot.trust.empty=true

  (the zookeeper.snapshot.trust.empty=true mentioned in most messages
  of the bug does not work, which is mentioned in some later answers)

- start up the server

- remove the setting again
  quoting:
  "It is recommended to remove the property once you have a working
  server, because that check is important to ensure that the system is
  in good shape"


Cheers,
Chris.

Bug#1004482: liblog4j1.2-java: CVE-2022-23307 CVE-2022-23305 CVE-2022-23302

[Christoph Anton Mitterer]

Package: liblog4j1.2-java
Version: 1.2.17-10
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Hey.

A number of holes was found in the 1.2 branch of log4j.

The following is apparently critical (code injection):
https://www.cvedetails.com/cve/CVE-2022-23307/

https://www.cvedetails.com/cve/CVE-2022-23305/
https://www.cvedetails.com/cve/CVE-2022-23302/


AFAIU there is no support anymore form these from upstream, and seems:
https://lists.apache.org/thread/rg4yyc89vs3dw6kpy3r92xop9loywyhh
there are no plans to fix it.

EGI recommends: "For services where chainsaw is installed but not used apply 
the mitigation
zip -q -d /usr/share/cassandra/lib/log4j*.jar  org/apache/log4j/chainsaw/*"

Not sure if that could be done for the Debian package in a new version?


Is Debian going to do anything about these?


Thanks,
Chris.



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Bug#1003685: cryptsetup: CVE-2021-4122

[Christoph Anton Mitterer]

Package: cryptsetup
Version: 2:2.4.2-1
Severity: critical
Tags: security upstream
Justification: root security hole


Hey.

You've probably seen it already... Milan found CVE-2021-4122, and
the package should be upgraded to 2.4.3 ASAP.

Thanks in advance,
Chris.

Bug#998108: firefox freezes shortly after start

[Christoph Anton Mitterer]

I just had one occasion of the "freezing" problem... but it was the
first time since we got 94.0-2.

Also it didn't occur short after start, but quite some time after
browsing the very same websites.

But the symptoms were as described in message #15 (i.e. that loading
wheel).


So there may be still some issue left (or it might be something
new/unrelated).


Cheers,
Chris.

Bug#998108: reopening 998108

[Christoph Anton Mitterer]

On Sat, 2021-11-20 at 15:30 -0800, Josh Triplett wrote:
> I'm still experiencing this bug regularly, with complete browser UI
> freezes that require killing and restarting Firefox.

Hm perhaps something else? At least I haven't suffered from that
particular issue since 94.0-2.


Cheers,
Chris.

Bug#998108: firefox freezes shortly after start

[Christoph Anton Mitterer]

On Thu, 2021-11-11 at 23:06 +1100, ‍小太 wrote:
> So either the change needs to be backported to v94

It seems Mike has already been active in that bug (and even found it
himself a ~month ago ^^) and indicated he'll backport it (AFAIU).

Which I hope really happens... I know there is no official security
support for unstable, but as this bug shows: many people (including
DDs) seem to use it on their working systems and it's probably not so
good for all these to have to stick with an old version with plenty of
high-rated security issues.


Cheers,
Chris.

Bug#998108: Acknowledgement (firefox freezes shortly after start)

[Christoph Anton Mitterer]

Not sure if this is related, but since a while I've noted even bigger
than the usual performance problems of firefox...

Crackling sound is something I've heard for a month now... but since
about FF93 came out CPU utilisation seems to be much higher.
I just load simple webpages and may CPU goes up to 70-80°C.

Anyone else seen this, too?

Bug#998108: Acknowledgement (firefox freezes shortly after start)

[Christoph Anton Mitterer]

> I was also experiencing this problem and was monitoring this bug
> report for potential solutions, but the problem seems to have
> recently disappeared. 

I cannot confirm this.

I've just upgraded to 94.0-1 (with everything else on my system
upgraded to the current state of unstable, well everything except stuff
that is 100% unrelated),... and after a few minutes the previously
described problems re-appeared.


Cheers,
Chris.

Bug#998108: Acknowledgement (firefox freezes shortly after start)

[Christoph Anton Mitterer]

FF94 is still broken.

Bug#998108: Acknowledgement (firefox freezes shortly after start)

[Christoph Anton Mitterer]

Oh and as a warning for everyone who wants to try out.

Stupid *zilla seems to no prevent downgrade of the profiles... so once
upgraded you cannot downgrade without throwing away your old profile
with all data in it. Wonderful...

Bug#998108: Acknowledgement (firefox freezes shortly after start)

[Christoph Anton Mitterer]

Sometimes it seems that firefox doesn't freeze "immediatly" but some
sites continue to work (and e.g. the address bar still allows input).
But new sites (especially with JS stuff) don't load correctly or just
freeze.

Eventually whole firefox freezes and one cannot event select the
address bar anymore or switch between tabs.

Bug#998108: firefox freezes shortly after start

[Christoph Anton Mitterer]

Package: firefox
Version: 93.0-1+b1
Severity: grave
Justification: renders package unusable

Hey.

Since about yesterday (possibly since the rebuilt package came in)
firefox freezes shortly after being started.
There is no high CPU activity then, it just takes no input anymore
(no keyboard, no mouse clicks).
This also happens in --safe-mode.

Any ideas?

Chris.




-- Package-specific info:

-- Extensions information
Name: Amazon.co.uk
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Bing
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Debian queries
Location: /usr/share/webext/debian-buttons
Package: webext-debianbuttons
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: eBay
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: FoxyProxy Standard
Location: /usr/share/webext/foxyproxy
Package: webext-foxyproxy
Status: enabled

Name: Google
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled

Name: Light theme
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: user-disabled

Name: Lightbeam 3.0
Location: /usr/share/webext/lightbeam
Package: webext-lightbeam
Status: user-disabled

Name: NoScript
Location: /usr/share/webext/noscript
Package: webext-noscript
Status: enabled

Name: Picture-In-Picture
Location: /usr/lib/firefox/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: System theme theme
Location: /usr/lib/firefox/omni.ja
Package: firefox
Status: enabled

Name: uBlock Origin
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net
Package: webext-ublock-origin-firefox
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox/browser/omni.ja
Package: firefox
Status: enabled


-- Addons package information
ii  firefox  93.0-1+b1 amd64Mozilla Firefox web 
browser
ii  webext-debianbuttons 2.3-2 all  Buttons for 
querying Debian-related pages with Firefox
ii  webext-foxyproxy 7.5.1+dfsg-2  all  Advanced proxy 
management for Firefox
ii  webext-lightbeam 3.0.1-1   all  visualize sites 
that may be tracking you around the internet
ii  webext-noscript  10.1.9.6-2all  permissions manager 
for Firefox
ii  webext-ublock-origin-firefox 1.37.0+dfsg-1 all  lightweight and 
efficient ads, malware, trackers blocker (Firefox)

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages firefox depends on:
ii  debianutils  5.5-1
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-3
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-10
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-3
ii  libgtk-3-0   3.24.30-3
ii  libnspr4 2:4.32-1
ii  libnss3  2:3.70-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-10
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps 

Bug#996005: ca-certificates: fails upgrading when no new certs selected

[Christoph Anton Mitterer]

Package: ca-certificates
Version: 20211004
Severity: grave
Justification: renders package unusable


Hey.

It seems that when not selecting any of the new certs on upgrade, the package
install fails:
Setting up ca-certificates (20211004) ...
Updating certificates in /etc/ssl/certs...
chmod: cannot access '/etc/ssl/certs/ca-certificates.crt.new': No such file or 
directory
dpkg: error processing package ca-certificates (--configure):
 installed ca-certificates package post-installation script subprocess returned 
error exit status 1


It did work though on other systems, where I selected some of the new certs.


Cheers,
Chris.

Bug#993207: regression: constant ~20% CPU usage + crackling sound since 15.0+dfsg1-2

[Christoph Anton Mitterer]

Source: pulseaudio
Version: 15.0+dfsg1-2
Severity: grave
Justification: renders package unusable



Hi

Since upgrading to 15.0+dfsg1-2, the pulseaudio daemon runs constantly at 
around ~20% CPU
on my system (even when no sound is played).

If sound is played it's constantly crackling.

Downgrading to the previous 14.2-2 from testing (and restarting the daemon) 
fixes the issue.

Any ideas?

Thanks,
Chris.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; remixing-produce-lfe = no
; remixing-consume-lfe = no
; lfe-crossover-freq = 0

; flat-volumes = no

; rescue-streams = yes

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4
; default-fragment-size-msec = 25

; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0
#!/usr/bin/pulseaudio -nF
#
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR 

Bug#992307: kdenlive-data: package fails to unpack

[Christoph Anton Mitterer]

Package: kdenlive-data
Version: 21.04.3-1
Severity: grave
Justification: renders package unusable


Hey.

There is some conflict:

Preparing to unpack .../kdenlive-data_21.04.3-1_all.deb ...
Unpacking kdenlive-data (21.04.3-1) over (20.12.3-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/kdenlive-data_21.04.3-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/icons/breeze-dark/actions/16/add-subtitle.svg', which is also in 
package breeze-icon-theme 4:5.83.0-2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/kdenlive-data_21.04.3-1_all.deb


Thanks,
Chris.

Bug#990345: zookeeper: various security issues

[Christoph Anton Mitterer]

On Thu, 2021-07-15 at 21:18 -0700, tony mancill wrote:
> The Debian package disables building against Netty via this patch: 
> https://salsa.debian.org/java-team/zookeeper/-/blob/master/debian/patches/13-disable-netty-connection-factory.patch

Ah I see.


> This is certainly a valid point.  There is not time to change the
> situation for bullseye aside from filing an RM bug to prevent the
> package from shipping with the release.  That would impact transitive
> dependencies of which I believe activemq is the most significant.

Would it be possible to provide a more current version via backports...
I mean if it's not possible to get it in via some st
able-update or so?


> As an aside, I took a quick look at the latest upstream activemq
> source
> release (https://activemq.apache.org/activemq-5016002-release) and it
> specifies zookeeper 3.4.14 in its pom.xml (which makes me feel a
> little
> better).

Isn’t that just telling the minimum version that works with it - not
what they'd consider a safe use from a security PoV?


> We can work on addressing the situation in bookworm.  (One idea I
> would
> propose is paring down the package to build just libzookeeper-java,
> because I imagine that many people use the Debian package to run
> their
> ZooKeeper ensembles, although maybe that's not true.) 

Well I for example use the daemon, too, but the software from which I
use it would anyway already require some newer version and doesn't work
with 3.4 anymore.
So for me that wouldn't matter much.


Thanks,
Chris.

Bug#990345: zookeeper: various security issues

[Christoph Anton Mitterer]

Hey.

On Sun, 2021-06-27 at 14:46 +0200, Salvatore Bonaccorso wrote:
> To me this looks like CVEs in other products, but which zookeeper
> uses
> as dependency? Is this correct?

Indeed, but I couldn't find that the zookeeper package depends on these
while it does contain:
zookeeper-3.4.13/src$ find . -iname "*nett*"
./java/main/org/apache/zookeeper/server/NettyServerCnxnFactory.java
./java/main/org/apache/zookeeper/server/NettyServerCnxn.java
./java/test/org/apache/zookeeper/server/NettyServerCnxnTest.java
./java/test/org/apache/zookeeper/test/NioNettySuiteTest.java
./java/test/org/apache/zookeeper/test/NioNettySuiteHammerTest.java
./java/test/org/apache/zookeeper/test/NioNettySuiteBase.java


... so I figured these might still be affected?


And apart from that... if they apparently don't support older versions
anymore, we'd like not even notice should these contain any security
issues.


Cheers,
Chris.

Bug#990345: zookeeper: various security issues

[Christoph Anton Mitterer]

Source: zookeeper
Version: 3.4.13-6
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 


Hi.

The release notes for https://zookeeper.apache.org/doc/r3.6.3/releasenotes.html
list various security issues:
CVE-2020-25649
CVE-2021-21295
CVE-2021-28165
CVE-2021-21409

It's a bit unclear to me  whether 3.4 is affected to, but since 3.5.x versions 
seem
to be, I'd guess the issues go back longer and may affect 3.4 as well.

I would guess that 3.4.x has no upstream support anymore.


Cheers,
Chirs.

Bug#936935: [Pkg-libvirt-maintainers] Bug#936935: libvirt-sandbox: Python2 removal in sid/bullseye

[Christoph Anton Mitterer]

On Tue, 2021-05-04 at 16:51 +0200, Guido Günther wrote:
> Since upstream is pretty inactive i wonder if we should just drop it,
> it
> won't be in bullseye either and popcon is fairly low:

Hmm I always found it to be pretty nice... an are there any specific
bugs/features that would be needed to work on from upstream.

Also popcon is not representative :-)


Cheers,
Chris. 

Bug#936935: libvirt-sandbox: Python2 removal in sid/bullseye

[Christoph Anton Mitterer]

Hey.

AFAICS, all python script have been adapted to Python3 upstream (or
dropped)... so I guess this could be solved by upgrading to the current
version.


Cheers,
Chris.

Bug#982023: gimp-gmic: prevents gimp from loading

[Christoph Anton Mitterer]

Package: gimp-gmic
Version: 2.9.4-1
Severity: grave
Justification: renders package unusable


Hi.

Since one of the more recent upgrades, gimp doesn't start up anymore, when
gimp-gmic is present (purging it solves the issue), but instead hangs
forever at th slapsh screen.


Cheers,
Chris.



$ gimp --verbose
Parsing '/etc/gimp/2.0/gimprc' for configured language.
Parsing '/home/calestyo/.config/GIMP/2.10/gimprc' for configured language.
No language property found.
INIT: gimp_load_config
Parsing '/home/calestyo/.config/GIMP/2.10/unitrc'
Parsing '/etc/gimp/2.0/gimprc'
Parsing '/home/calestyo/.config/GIMP/2.10/gimprc'
Adding icon theme 'Color' (/usr/share/gimp/2.0/icons/Color)
Adding icon theme 'Legacy' (/usr/share/gimp/2.0/icons/Legacy)
Adding icon theme 'Symbolic' (/usr/share/gimp/2.0/icons/Symbolic)
Adding icon theme 'Symbolic-Inverted' 
(/usr/share/gimp/2.0/icons/Symbolic-Inverted)
Adding icon theme 'Symbolic-High-Contrast' 
(/usr/share/gimp/2.0/icons/Symbolic-High-Contrast)
Adding icon theme 'Symbolic-Inverted-High-Contrast' 
(/usr/share/gimp/2.0/icons/Symbolic-Inverted-High-Contrast)
Loading icon theme 'Color'
Adding theme 'Dark' (/usr/share/gimp/2.0/themes/Dark)
Adding theme 'Gray' (/usr/share/gimp/2.0/themes/Gray)
Adding theme 'Light' (/usr/share/gimp/2.0/themes/Light)
Adding theme 'System' (/usr/share/gimp/2.0/themes/System)
Writing '/home/calestyo/.config/GIMP/2.10/themerc'
Trying splash '/home/calestyo/.config/GIMP/2.10/gimp-splash.png' ... failed
Trying splash '/usr/share/gimp/2.0/images/gimp-splash.png' ... OK
INIT: gimp_initialize
INIT: gimp_real_initialize
Parsing '/usr/lib/gimp/2.0/interpreters/default.interp'
Parsing '/usr/lib/gimp/2.0/environ/default.env'
INIT: gui_initialize_after_callback
INIT: gimp_restore
Parsing '/home/calestyo/.config/GIMP/2.10/parasiterc'
Loading 'brush factory' data
  Loading /usr/share/gimp/2.0/brushes/Texture/Cell-01.gbr
  Loading /usr/share/gimp/2.0/brushes/Texture/Cell-02.gbr
  Loading /usr/share/gimp/2.0/brushes/Texture/Grass.gih
  Loading /usr/share/gimp/2.0/brushes/Texture/Hatch-Pen-01.gbr
  Loading /usr/share/gimp/2.0/brushes/Texture/Smoke.gbr
  Loading /usr/share/gimp/2.0/brushes/Texture/Stone-Work-01.gih
  Loading /usr/share/gimp/2.0/brushes/Texture/Texture-01.gbr
  Loading /usr/share/gimp/2.0/brushes/Texture/Texture-02.gbr
  Loading /usr/share/gimp/2.0/brushes/Texture/Texture-Hose-01.gih
  Loading /usr/share/gimp/2.0/brushes/Texture/Texture-Hose-02.gih
  Loading /usr/share/gimp/2.0/brushes/Texture/Texture-Hose-03.gih
  Loading /usr/share/gimp/2.0/brushes/Texture/Vegetation-01.gbr
  Loading /usr/share/gimp/2.0/brushes/Texture/Vegetation-02.gih
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/10x10square.gbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/10x10squareBlur.gbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/20x20square.gbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/20x20squareBlur.gbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/5x5square.gbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/5x5squareBlur.gbr
  Loading 
/usr/share/gimp/2.0/brushes/gimp-obsolete-files/Calligraphic-Brush-0.vbr
  Loading 
/usr/share/gimp/2.0/brushes/gimp-obsolete-files/Calligraphic-Brush-1.vbr
  Loading 
/usr/share/gimp/2.0/brushes/gimp-obsolete-files/Calligraphic-Brush-2.vbr
  Loading 
/usr/share/gimp/2.0/brushes/gimp-obsolete-files/Calligraphic-Brush-3.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-1.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-11.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-13.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-15.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-17.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-19.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-3.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-5.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-7.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-9.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-11.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-13.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-15.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-17.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-19.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-3.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-5.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-7.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Circle-Fuzzy-9.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Diagonal-Star-11.vbr
  Loading /usr/share/gimp/2.0/brushes/gimp-obsolete-files/Diagonal-Star-17.vbr

Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM

[Christoph Anton Mitterer]

On Fri, 2021-01-01 at 12:10 +0100, Michel Le Bihan wrote:
> 
> 
> That's actually intended. It would be easier to set the build flag
> that
> disables it, but some users are still interested in using it. The way
> it's done currently still allows them to use it.

Yeah, but the point is, AFAIU, for those people who already have it now
(possibly unknowingly) it will be kept (and updated).

So unless such users accidentally stumble of this, they'll never be
able to decide whether they really want to keep it or not.



Cheers,
Chris.

Bug#960454: chromium: Make Chromium ask before downloading and enabling DRM

[Christoph Anton Mitterer]

Hey.


Just wondered:


1) Since this is a binary blob who, by it's nature, is made for
surveillance, it's IMO more a rather serious security issue than just a
DFSG-policy problem.
No one really knows what exactly Google ships there.

So maybe people should be told about this more actively in a DSA or
NEWS.Debian entry?



2) To my great surprise (and shock - due to the compromise) I found the
binaries downloaded last July, even though I never used chromium on any
site that uses EME or things like that.
Which makes this behaviour even more suspicious.



3) AFAIU, now the Debian package no longer downloads it automatically
(with widevine-cdm-cu.patch), but many people will still have it
silently in place (and presumably executed). Which is again kinda a
point for (1).



4) This problem of browsers downloading their own closed-source and
possibly compromised stuff has already surfaced in the past.
Wouldn't it be safer to completely remove the code doing at all?
Right now we have widevine-cdm-cu.patch which is fine for just this,
and as soon as Google would add something new it would probably get
downloaded again until someone notices by chance.


In general, I think it's pretty bad if software circumvents secure APT
do download further software:

- there is no central security support (just imagine an attacked simply
blocks any time chromium tries to upgrade the binary blobs) and
people will not even notice if upgrades from within the software fail.

- it's not taken into account by tools like check_apt either

- unless someone knows that Chromium puts software in .config it will
stay there forever and not begin removed or so when the chromium
package would be removed

- an evil Google could just selectively distribute hacked versions of
their binaries - something which is more or less impossible when all
software comes via secure APT

- doing package upgrade really in a secure way (i.e. preventing
blocking attacks, downgrade attacks, or just not using
outdated/insecure algorithms) is actually not that easy and I've seen
many downloader packages doing it wrong - with secure APT there's one
central place where all this is handled (securely)



Cheers,
Chris.

Bug#912880: gprename ported to GTK3

[Christoph Anton Mitterer]

Hey.

Seems gprename has been ported to GTK3... would be awesome if this
could find it's way back into Debian :-)

https://sourceforge.net/p/gprename/bugs/18/

Cheers,
Chris.

Bug#969123: webext-ublock-origin: FF80 broke ublock again

[Christoph Anton Mitterer]

On Mon, 2020-08-31 at 10:12 +0200, Markus Koschany wrote:
> remove
> ~/.mozilla/firefox to create a new profile to get it working again.

Doesn't really sound like a "solution" to me (well except than taking
it as a trigger to finally move away from crappy FF).

It seems to have become fashion nowadays for *zilla to completely break
user setups every few versions... first breakage of thousands of
"legacy" add-ons... and now they even break their webext addon and the
only solution is re-creating a profile directory for which these is no
proper migration procedure and where most data is stored in some binary
format?!


Cheers,
Chris.

Bug#969123: webext-ublock-origin: FF80 broke ublock again

[Christoph Anton Mitterer]

On Sat, 2020-08-29 at 01:32 +0200, Markus Koschany wrote:
> Thanks for reporting. I believe this is fixed in 1.29.0+dfsg.
> Unfortunately the package has to go through NEW again which is
> unfortunate. I hope I can convince the ftp-team to fast-track
> reviewing
> uBo (again).

Interestingly it seems other (all) add-ons are broken too, at least for
me... but not when I create fresh profiles.


Thanks,
Chris.

Bug#969123: webext-ublock-origin: FF80 broke ublock again

[Christoph Anton Mitterer]

Package: webext-ublock-origin
Version: 1.28.0+dfsg-1
Severity: grave
Justification: renders package unusable



Hey.

It seems stupid *zilla broke ublock origina again with the new Firefox.

All adds are shown.

Cheers,
Chris.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

webext-ublock-origin depends on no packages.

Versions of packages webext-ublock-origin recommends:
ii  firefox  80.0-1

Versions of packages webext-ublock-origin suggests:
pn  ublock-origin-doc  

-- no debconf information

Bug#945055: linux: CPU runs at considerably higher temperatures

[Christoph Anton Mitterer]

Hey.

According to https://gitlab.freedesktop.org/drm/intel/issues/953 the
bug was introduced by:
drm/i915/gen8+: Add RC6 CTX corruption WA 
(d4360736a7c0a6326e3bbdf7d41181f6ed03d9a6)

which, AFAIU, is actually a security fix.


There seem to be some patches, but not sure when they'll be "final" (if
ever)... without opening the security issue again.


Also this would just fix my imminent showstopper of Cinnamon running at
extreme temperatures when being effectively idle.

As my test series shows the following issues likely remain:
- Cinnamon performs noticeably worse with video playback than GNOME
  even under 5.2 (where the offending commit isn't there)
- vaapi performs than xv (which I guess it shouldn't)
- intel_pstate makes the system hotter to.


Thanks,
Chris.

Bug#945055: Acknowledgement (intel-microcode: CPU runs at considerably higher temperatures)

[Christoph Anton Mitterer]

Control: forwarded -1 
https://lore.kernel.org/lkml/d05aba2742ae42783788c954e2a380e7fcb10830.ca...@scientia.net/

Hey.

I've forwarded this to lkml.

My most recent post in that thread[0] contains an pretty elaborate test
series comparing kernel 5.2 vs. 5.4 (each with intel_pstate=disable and
without), each on Cinnamon and GNOME Classic... under different
scenarios (idle system and several videos played back).

My personal conclusion would be that something changed between 5.2 and
5.3, which made temperatures and CPU utilisation considerably worse for
Cinnamon,... and not such much, but still noticeably for GNOME.


Apart from that however, there seems to be additionally something wrong
with Cinnamon, as it performs much worse with video playback than GNOME
does - even under 5.2.

So I've additionally created a ticket there at Cinnamon[1].


[0] 
https://lore.kernel.org/lkml/c7b7e81b14380709c3d63033b0e67ee12b737b55.ca...@scientia.net/
[1] https://github.com/linuxmint/cinnamon/issues/9085#issuecomment-570654676

Bug#947340: linux-base: can't be upgraded

[Christoph Anton Mitterer]

Package: linux-base
Version: 4.6
Severity: grave
Justification: renders package unusable


Hi.

Since last April, the package can't be upgraded as it conflicts with
the current version of kernel-common.

Would be nice if this could be resolved.

Probably it's this change:
  * Take over kernel-img.conf(5) manual page from kernel-common 

 ▒
(Closes: #925415)   

 ▒
but then this should be reflected in kernel-common, or it should have
been coordinated with its maintainer in the first place.

Cheers,
Chris.

Bug#945864: unhide[208429]: segfault at 7ffd06cfec58 ip 000055c15aa077d3 sp 00007ffd06cfec60 error 6 in unhide-linux[55c15aa07000+6000]

[Christoph Anton Mitterer]

Package: unhide
Version: 20130526-3
Severity: grave
Justification: renders package unusable



Since 1-3 weeks unhide segfaults every time:

Nov 30 01:39:48 heisenberg kernel: unhide[208429]: segfault at 7ffd06cfec58 ip 
55c15aa077d3 sp 7ffd06cfec60 error 6 in unhide-linux[55c15aa07000+6000]
Nov 30 01:39:48 heisenberg kernel: Code: 00 48 89 45 c8 31 c0 48 63 05 5d 98 00 
00 48 8d 04 85 0f 00 00 00 48 83 e0 f0 48 29 c4 48 89 65 98 48 29 c4 31 c0 48 
89 65 90  d8 3e 00 00 31 c0 66 0f 1f 44 00 00 48 8b 4d 98 48 8b 55 90 c7


Cheers,
Chris.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unhide depends on:
ii  libc6  2.29-3

unhide recommends no packages.

Versions of packages unhide suggests:
ii  rkhunter  1.4.6-7

-- no debconf information

Bug#940105: linux: serious corruption issue with btrfs

[Christoph Anton Mitterer]

Hey.

Is there anything one can help to speed this up?

A patch is available for two weeks now, while Debian users of testing
and unstable are left with the danger of catastrophic btrfs corruption
without even any warning to them (so that they could at least downgrade
to <5.2).

Cheers,
Chris.

Bug#940105: linux: serious corruption issue with btrfs

[Christoph Anton Mitterer]

Hey.

Just to put some emphasise on this, the fix has now been merged late to
5.3 as urgent.

Also note Filipe's post[0] that the issue can more or less hit anyone.

Cheers,
Chris.


[0] 
https://lore.kernel.org/linux-btrfs/9731b0e7-81f3-4ee5-6f89-b4fd8d981...@petaramesh.org/T/#m7b3863ef7ec5f62a2f7d1b6e99cad2d6dae43b37

Bug#940105: linux: serious corruption issue with btrfs

[Christoph Anton Mitterer]

Source: linux
Version: 5.2.9-2
Severity: critical
Tags: upstream patch
Justification: causes serious data loss


Hi.

There were some reports over the last weeks from users on linux-btrfs which
suffered from catastrophic btrfs corruption.
The bug which is apparently a regression introduced in 5.2 has now been found[0]
an a patch is available[1].

Since it's unclear how long it will take to be part of a stable release and when
Debian will pick this up in unstable, please consider to cherry-pick the patch.

Thanks,
Chris.

[0] 
https://lore.kernel.org/linux-btrfs/9731b0e7-81f3-4ee5-6f89-b4fd8d981...@petaramesh.org/T/#m38d726b09e784f1ffbd26edf13f723f71045723e
[1] https://patchwork.kernel.org/patch/11141559/


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

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

Bug#927450: fixed in debian-security-support 2019.04.25

[Christoph Anton Mitterer]

Control: reopen -1

As if I wouldn't have written it before... o.O

Now all that was done is changing the value from 9 to 10 and it will
break again in xx months when the next-stable arrives an no one will
remember by then that this must be adapted...

Can't you just set a Conflicts/Breaks against base-files >10 ... and
people won't again fall into that trap in the future?


Cheers,,
Chris.

Bug#927841: plowshare: plowmod is inherently insecure

[Christoph Anton Mitterer]

Package: plowshare
Version: 2.1.7-2
Severity: grave
Tags: security
Justification: user security hole


Hi.

The removal of plowshare-modules, which was IMO quite !smart, forces
users to use plowmod which is IMO, like basically every code-downloader
inherently insecure.

1) There seems to be no verification, whatsoever of the downloaded code
   apart from using TLS
   Thus any, out of about 150 of the default CAs (from which many are
   already known to be rogue CAs that have in the past often forged
   certs for the totalitarian states where they're based in) plus
   thousands of intermediate CAs can basically easily create a forged
   cert for github and then inject code into an attacked system.

   Such an attack can be targeted upon specific users only (which is
   not possibly if some code - even if not audited - is taken by Debian
   and distributed from there... in such a case *all* users would be
   attacked and an attack is likely to be noticed more easily).

   Of course the same is possible to github and even the upstream authors.
   Attacking a single person without ever being noticed because the
   vast majority gets "good" code.

2) It circumvents the package management system which is generally wrong
   for many reasons, including e.g.
   - users won't be notified about security update by regular means
 (actually by no means at all)
   - things like debsums break
   - tools like check_apt for Icinga/etc. will either break or simply not
 work as intended.


code-downloader+installer-tools are typically inherently insecure... even
with "proper" OpenPGP signatures and verification it's hard to get it done
right and often things like downgrade-attacks are forgotten... and it still
leaves the attack window open that an evil (or stolen) upstream key can
be used to only selectively attack users which will never be noticed.
The only why to get it down right is, if Debian (respecitvely the downloader
package) itself contains the signatures/sum (*not* a generally trusted key)
and verifies against those... which however defeats the "benefits" of such
code downloader programs.

Since code-downloader+installer-tools are from a security PoV generall evil
they should actually rather be removed from packages, so that users don't
actually use them.

Cheers,
Chris.

Bug#927450: base-files: breaks debian-security-support, which then breaks package installations

[Christoph Anton Mitterer]

On Sat, 2019-04-20 at 09:22 +0200, Santiago Vila wrote:
> I'm adding "affect base-files" so that people see this bug in the BTS
> page for base-files and nobody thinks the problem is in base-files,
> but just for that.

Well at least with this it does *not* show up in apt-listbugs and
prevent people from upgrading it until the bug in d-s-s is fixed...

Bug#927450: base-files: breaks debian-security-support, which then breaks package installations

[Christoph Anton Mitterer]

Yeah it's definitely that strange hardcoded part in:
/usr/bin/check-support-status:

> DEB_LOWEST_VER_ID=7
> # Version ID for next Debian stable
> DEB_NEXT_VER_ID=9
> …
> if [ "$DEBIAN_VERSION" -lt "$DEB_LOWEST_VER_ID" ] || [ "$DEBIAN_VERSION" -gt 
> "$DEB_NEXT_VER_ID" ] ; then
> eval_gettext "Unknown DEBIAN_VERSION \$DEBIAN_VERSION. Valid values from 
> \$DEB_LOWEST_VER_ID and \$DEB_NEXT_VER_ID"; echo
> exit 1
> fi

if one makes something like this one should have probably declared a
Conflicts against any base-files package >9.


Not sure what the correct is to handle this in the BTS... of course it
should be assigned to debian-security-support, but then people who
upgrade won't notice the problem... "affects base-files" isn't the case
and wouldn't probably make it show up either.

Guess the only thing the BTS allows is to have a 2nd bug at debian-
security-support and make this one a dummy-bug (which also block
transition to testing) blocked by the other.

Cheers,
Chris.