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#1069912: argon2 tool doesn't properly link against pthread

[Christoph Anton Mitterer]

Control: reassign -1 initramfs-tools
Control: severity -1 important
Control: retitle -1 copy_exec doesn't detect libgcc dependency anymore when 
pthread is used

Hey.


I think I found the root cause (thanks to Guilhem Moulin, who
pointed[0] me to it).

Apparently (which wasn't on my radar at all ^^), glibc since 2.34
dropped libpthread. So the whole check you do in hook-functions[2] will
probably never work anymore, which hit me with my argon2 (the tool not
the lib).

Now pthread apparently dlopen()s stuff from gcc, so in my case
pthread_exit fails.

Guilhem already remembered that you've been reluctant to
unconditionally include libgcc - which I can understand (I also want to
keep my initramfs as small as possible) - but this breaks stuff and
apart from ugly manual hacks I don't see an easy way around it.

Could you please either reconsider adding it unconditionally, or is
there some other way to find out whether a binary uses pthread stuff?

If not, would it be possible to provide at least some simpler to use
interface to copy_libgcc? Where e.g. I'd just say:
copy_libgcc /usr/bin/argon2 and it would automatically find the right
libdir for the right arch?

Thanks,
Chris.


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068849#89
[1] https://lists.gnu.org/archive/html/info-gnu/2021-08/msg1.html
[2] 
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/cf964bfb4362019fd7fba1e839e403ff950dca8e/hook-functions#L248-L249

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#1069912: argon2: argon2 tool doesn't properly link against pthread

[Christoph Anton Mitterer]

Package: argon2
Version: 0~20190702+dfsg-4+b1
Severity: wishlist


Hey.

I stumbled over some odd issue, originally described here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068849#84

In short:
I use the argon2 tool inside the initramfs, into which I copy it via
initramfs-tools’ copy_exec function (defined in
/usr/share/initramfs-tools/hook-functions).

Now that function uses ldd to find out whether a binary is linked
against libpthread and if so, also includes libgcc because of #950254
(in short: pthread seems to dlopen() libgcc).

Now argon2 somehow doesn't indicate it uses libpthread:
$ ldd /usr/bin/argon2
linux-vdso.so.1 (0x7ffedb996000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f90666bb000)
/lib64/ld-linux-x86-64.so.2 (0x7f90668cb000)

which I don't quite understand why.
Actually, even when building it manually, an explicitly -lpthread it never
shows up there.

No idea why... perhaps some linker optimisation that goes wrong?
I tried with -Wl,--no-as-needed, but that doesn't help either.
I can only force it to link if using
   gcc … -Wl,--no-as-needed /usr/lib/x86_64-linux-gnu/libpthread.so.0
i.e. the real path of the .so.


So in my case, pthread_exit() fails eventually (in the initramfs), with
an error that libgcc cannot be found.


Any ideas what to do?


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#1069183: [Aptitude-devel] Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock

[Christoph Anton Mitterer]

Hey.

Just upgraded (via aptitude) to the most recent apt in sid on a number
of nodes (this time, all *without* any Icinga/Prometheus stuff)... and
on all nodes the locking issue showed up:

# aptitude
Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done

(Reading database ... 94829 files and directories currently installed.)
Preparing to unpack .../libapt-pkg6.0t64_2.9.2_amd64.deb ...
Unpacking libapt-pkg6.0t64:amd64 (2.9.2) over (2.9.1) ...
Setting up libapt-pkg6.0t64:amd64 (2.9.2) ...
(Reading database ... 94829 files and directories currently installed.)
Preparing to unpack .../archives/apt_2.9.2_amd64.deb ...
Unpacking apt (2.9.2) over (2.9.1) ...
Setting up apt (2.9.2) ...
dpkg: error: dpkg frontend lock was locked by another process with pid
59222
Note: removing the lock file is always wrong, can damage the locked
area
and the entire system. See
.
Scanning processes... 
Scanning candidates...
Scanning processor microcode...   
Scanning linux images...  

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

User sessions running outdated binaries:
 root @ session #2: aptitude[57943], bash[1142]

No VM guests are running outdated hypervisor (qemu) binaries on this
host.
E: Sub-process /usr/bin/dpkg returned an error code (2)
Processing triggers for man-db (2.12.1-1) ...
Processing triggers for libc-bin (2.37-18) ...
Press Return to continue, 'q' followed by Return to quit.

Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 94829 files and directories currently installed.)
Preparing to unpack .../apt-utils_2.9.2_amd64.deb ...
Unpacking apt-utils (2.9.2) over (2.9.1) ...
Setting up apt-utils (2.9.2) ...
Processing triggers for man-db (2.12.1-1) ...
Scanning processes... 
Scanning candidates...
Scanning processor microcode...   
Scanning linux images...  

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

User sessions running outdated binaries:
 root @ session #2: aptitude[57943], bash[1142]

No VM guests are running outdated hypervisor (qemu) binaries on this
host.
Press Return to continue, 'q' followed by Return to quit.



So as David already said, it seems to be frontend lock related... but I
guess this indicates now that the process that gets in its way may
after all *not* be check_apt or the exporter for Prometheus.


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#1068024: revert to version that does not contain changes by bad actor

[Christoph Anton Mitterer]

Hey.


On Sun, 2024-03-31 at 01:46 +, Thorsten Glaser wrote:
> Yes, a multi-team task force is working on it and will inform users
> once it is known how to proceed, inclusing how much to throw away
> and rebuild.

Kindly wanted to ask whether anything has come out meanwhile of that?


I've tried to follow quite extensively what the various reverse
engineering efforts (e.g. [0], [1], [2], [3]) found out or what's
revealed on index pages like [4] or [5].

It feels as if there are still many discussions about how to prevent
such things in the future, but less so about the concrete fallout of
the particular backdoor, where it seems most people were lead to
conclude from media reports, that an attack was only possible if sshd
was actually running an reachable.

This may of course be true, which would mean that most people are
actually safe and we had quite some luck this time:
- servers, because they run stable distros that haven't had the
  backdoor
- workstations/laptops, because they typically don't run a publicly
  listending sshd

But there are still new findings about the backdoor every now and then,
like that it may read/write on IPC sockets (contained in [2]) and I've
read similar[6] without the restriction on IPC.
Also I've seen some vague statements[7] that it might "install" public
keys (didn't really grasp what was meant there - something like "in
authorized_keys"). And one report[8] talked about it collecting
usernames and IPs and passing the on to some function with unknown
purpose.

It also seems like these effort focus mostly on the 5.6.1 version and
while it's said that the 5.6.0 version is quite similar, who knows the
exact details!?


In any case and (too) long story short:

It would be nice to know whether there's still work done about finding
out whether people who had the malicious code on their systems (in any
version of the backdoor), but
- had sshd not running at all
and/or
- it was not reachable from the internet

can feel safe.

Or whether it may be possible that:
- the backdoor did call home (loaded commands from there, leaked
  private keys or so from the system)
- used completely different vectors not involving sshd
- or somehow else infested the system


Right now people might still have backups to torch their possibly
compromised systems and start over from a safe sate.


So Thorsten, in case you or someone else is aware of any [intermediate]
results from these task forces ([9[) it would be nice to hear about
them or better even in form of some "official" statement from Debian.


Thanks,
Chris.


[0] https://discord.gg/u6MzmQm5
[1] https://github.com/smx-smx/xzre
[2] 
https://github.com/binarly-io/binary-risk-intelligence/tree/master/xz-backdoor
[3] https://securelist.com/xz-backdoor-story-part-1/112354/
[4] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
[5] https://github.com/przemoc/xz-backdoor-links
https://przemoc.github.io/xz-backdoor-links/  (rendering of that)
[6] 
https://discord.com/channels/1223666474091020432/1223666474972090430/1230974749522530304
[7] 
https://discord.com/channels/1223666474091020432/1223666474972090430/1230173131746840606
[8] https://isc.sans.edu/diary/30802
[9] E.g. on d-d https://lists.debian.org/debian-devel/2024/03/msg00338.html
Moritz Mühlenhoff has mentioned that some company was working on it
and results were expected in some time.

Bug#1069251: ca-certificates-java: keystore is not updated

[Christoph Anton Mitterer]

Package: ca-certificates-java
Version: 20230710~deb12u1
Severity: important


Hey.

Actually I think this should have a higher severity, since the
trusted certs may very well be quit security critical.

Nevertheless:
I just traced a bug for some hours, where it eventually turned out
that dpkg-reconfigure ca-certificates doesn't cause the changes to
be picked up by ca-certificates-java.


In the following I do the opposite (where it appens, too):
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one 
certificate or CRL
0 added, 140 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
done.

As you can see, I removed (actually all certs).

But looking at the actual JKS:
# keytool -list -v -keystore /etc/ssl/certs/java/cacerts 2>/dev/null | grep -i 
^Owner:

Owner: OU=AC RAIZ FNMT-RCM, O=FNMT-RCM, C=ES
...
Owner: CN=XRamp Global Certification Authority, O=XRamp Security Services Inc, 
OU=www.xrampsecurity.com, C=US

One sees they're still all in.


When I remove it:
# rm /etc/ssl/certs/java/cacerts

# dpkg-reconfigure ca-certificates-java
done.
# ls /etc/ssl/certs/java/cacerts
ls: cannot access '/etc/ssl/certs/java/cacerts': No such file or directory
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
done.
# ls /etc/ssl/certs/java/cacerts
ls: cannot access '/etc/ssl/certs/java/cacerts': No such file or directory

It's not recreated.


Only if I configure new certs, it actually decides to recreate the JKS, too:
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one 
certificate or CRL
2 added, 0 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
Adding debian:USERTrust_ECC_Certification_Authority.pem
Adding debian:USERTrust_RSA_Certification_Authority.pem
done.
# keytool -list -v -keystore /etc/ssl/certs/java/cacerts 2>/dev/null | grep -i 
^Owner:

Owner: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, 
L=Jersey City, ST=New Jersey, C=US
Owner: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, 
L=Jersey City, ST=New Jersey, C=US

this time with the correct content.


If I now add yet another cert:
# dpkg-reconfigure ca-certificates
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one 
certificate or CRL
1 added, 0 removed; done.
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for ca-certificates-java (20230710~deb12u1) ...
done.
# keytool -list -v -keystore /etc/ssl/certs/java/cacerts 2>/dev/null | grep -i 
^Owner:

Owner: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, 
L=Jersey City, ST=New Jersey, C=US
Owner: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, 
L=Jersey City, ST=New Jersey, C=US


That is again not added to the JKS.


Cheers,
Chris.

Bug#1069183: [Aptitude-devel] Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock

[Christoph Anton Mitterer]

Hey David.

Thanks for your elaborate mail

On Wed, 2024-04-17 at 21:55 +0200, David Kalnischkies wrote:
> > Unpacking util-linux-extra (2.38.1-5+deb12u1) over (2.38.1-5+b1)
> > ...
> > Setting up util-linux-extra (2.38.1-5+deb12u1) ...
> > dpkg: error: dpkg frontend lock was locked by another process with
> > pid 1064194
> > Note: removing the lock file is always wrong, can damage the locked
> > area
> > and the entire system. See
> > .
> > E: Sub-process /usr/bin/dpkg returned an error code (2)
> 
> I am assuming here that unpacking and setting up of util-linux-extra
> worked fine and that dpkg run ended. The dpkg run after that, which
> would probably have installed other things failed due to a lock being
> held by something else…

I'd have expected the same, with perhaps the difference that my blind
assumption was that *everything* is done in one dpkg run, and thus it
would hold the lock over everything.


> 
> > Scanning processes...
> > Scanning processor microcode...
> > Scanning linux images...
> > Running kernel seems to be up-to-date.
> > The processor microcode seems to be up-to-date.
> > No services need to be restarted.
> > No containers need to be restarted.
> > No user sessions are running outdated binaries.
> > No VM guests are running outdated hypervisor (qemu) binaries on
> > this host.
> 
> This output (that I trimmed slightly) is from needrestart

Sure that output was all clear (also apt's retry),.. I merely included
it to show that when starting over, it simply moves one with the next
packages.
That is, I also don't think that this issue ever left a single package
back in half-configured state or so.
Actually I cannot even remember that I'd have ever seen broken packages
because of this (e.g. because other deps were no longer fulfilled).



> > Unfortunately it doesn't tell the name of pid 1064194 and the
> > offending process
> > is typically always already gone by then.
> 
> (Maybe report that as a feature request for dpkg to show some info
>  about the pid instead of just the number, but that might be hard to
>  implement.)
You think so? I'd have thought if it already knows the PID, it could
just print the `comm` line of that?



> 
> > But in any case, shouldn't apitude/apt/dpkg just permantenly hold
> > the lock
> > once the process has started until it finishes?
> 
> That is how it is supposed to be, but I think aptitude was never
> changed
> to make full use of the frontend lock. Probably unrelated to this
> issue,
> but a quick grep on aptitude shows me:
> > $ git grep -A 2 -- '->ReleaseLock' src/generic/apt/aptcache.cc
> > :1006:  apt_cache_file->ReleaseLock();
> > -1007-  bool dpkg_selections_saved =
> > dpkg_selections.save_selections();
> > -1008-  if (! apt_cache_file->GainLock())
> which is the old pattern of releasing the lock and calling dpkg in
> the
> hopes that nothing grabs it in the meantime, which was the practice
> before dpkg gained the frontend lock (these are aptitudes own methods
> that wrap _system->Lock() from libapt that does acquire the frontend
> and the dpkg lock – and also releases both if told so).
> 
> The solution here should be to hold onto the frontend lock for the
> entire run and do the lock dance for compatibility with the
> dpkg
> lock only. _system->LockInner() is part of that and grep has no hits
> for it in aptitude.
> 
> So, my suspicion is that aptitude doesn't use the frontend lock and
> is
> hence prune to other front ends grabbing the dpkg (and front end)
> lock
> the moment it releases the dpkg lock for dpkg. Hence the two fails
> and
> the run of needrestart takes long enough for the other front end to
> finish so that the last dpkg call aptitude makes succeeds again.

Well that sounds like a probably cause then. Though I still don't know
*what* then steals the lock. I can only think of the Icinga/Prometheus
probes.
There should be nothing else on my systems that doesn't come out-of-the
box (like apt systemd.timers or so).


Thanks,
Chris.

Bug#994220: base-files: add /etc/local and /usr/local/libexec

[Christoph Anton Mitterer]

On Thu, 2024-04-18 at 00:34 +0200, Santiago Vila wrote:
> > 
> I think you might be overestimating the importance of this.

Well I haven't said it would be super important (not at least that the
dirs are created - what might be more important is, if e.g. owners are
changed, like when stuff was owned by staff (pun intended ;-) ).


> Regarding your idea of writing a script which "updates" all those
> minor things: Feel free to do so, but I don't think it belongs
> to base-files. In fact, there are a lot of things which differ
> between
> an upgraded system and a newly installed system, and the differences
> due to more or less empty directories in /usr/local are probably
> the least important of all of them.

I don't think that a tool from some nobody:nogroup on github would help
a lit here. At least I wouldn't trust such a thing ;-)




> I often had additional recipes to achieve exactly what you
> mention: that an upgraded system is as close as possible to a newly
> installed system.

I do basically the same, and even in the more recent stable releases,
the steps needed were actually quite a lot.

In general I think that it would be best that if people do upgrade,
they should get a system which is a close to fresh one as reasonable
possible.

And such things like changed owners/permissions or not cleaned up left
over dirs/files *may* actually become important at some point.

Take for example the :staff thing. IIRC, that's no longer done. So
people may have left over dirs still owned by :staff.

Maybe in 10 years from now, staff itself has become complete obsolete,
like e.g. the gnats was stopped from being created (but not removed,
obviously).
In 10 further years, someone might think that it's time that that UID
can be reused.

Which might be an issue for people who still have it because of only
ever having upgraded, and which never even realised that they might
need to clean up.


Cheers,
Chris.

Bug#994220: base-files: add /etc/local and /usr/local/libexec

[Christoph Anton Mitterer]

On Wed, 2024-04-17 at 23:43 +0200, Santiago Vila wrote:
> Yes. An empty $2 means that the package is installed for the
> very first time, i.e. installed by debootstrap.
> 
> This is actually explained in the last question here:
> 
> /usr/share/doc/base-files/FAQ

Isn't that quite unfortunate?

It leaves out any legacy installations (and many people never re-
install Debian, but just continuously upgrade it).


I mean I can fully understand if it's to fragile to automatically
update base-files (not just creating new dirs, but e.g. also changed
directories), but:
- Wouldn't it be possible to have a small tool that is manually run and
  which e.g. compare the current situation with what a pristine
  installation would get and that spits out some commands that would
  adapt this... or per default be like --dry-run and only with some
  extra param do everything?

- Or at least *if* something changes - which is anyway quite rate - it
  should IMO into NEWS.Debian and the release notes, so that people
  that upgrade can catch up.



Cheers,
Chris.

Bug#994220: base-files: add /etc/local and /usr/local/libexec

[Christoph Anton Mitterer]

Hey.

FYI: I have upgraded to 13.1, but still didn't get a
/usr/local/libexec.

Guess that's because $2 in the script is not empty?

Cheers,
Chris.

Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock

[Christoph Anton Mitterer]

btw: There already is #586486 but to me it looked rather like a
different issue.

Bug#1069185: xserver-xorg-core: new upstream version (which has a nice fix)

[Christoph Anton Mitterer]

Package: xserver-xorg-core
Version: 2:21.1.12-1
Severity: wishlist


Hey.

Joking:
" Debin's xorg lacks critical security patches, I demand make me maintainer 
immediately "

Too soon for XZ jokes? O:-P


Seriously, there's a new upstream version out (21.1.13), which incorporates
not only the fix for a security issue (which you've already cherry picked
thanks for being so fast :-) ), but also the backported:
https://gitlab.freedesktop.org/xorg/xserver/-/commit/f54647dfa6e45481282c3650019449379059f113

That fixes a long standing and particula annoying (but in no way critical)
GTK 3 issue, where, when the mouse pointer is e.g. at the leftmost position,
it's not recognised as being there, and thus e.g. click and select
on a maximised terminal window fails.

This happens not always but often (so sometimes you select lines, it works
sometimes not).
It does not happen at all with e.g. xterm.

The above patch would fix that.


Since xorg releases happen very sporadically these days (only when there are
security holes?) I wanted to ask whether you might consider upgrading to
that version (despite no securiy issue being fixed by it, that's not already
fixed in Debian).

But... no hurry needed... that issue has been open for quite a while, so will
be able to live with it for a bit longer. :-)


Thanks,
Chris.

Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock

[Christoph Anton Mitterer]

Package: aptitude
Version: 1.21.22
Severity: important


Hey.

May very well be an issue in APT or rather dpkg, still, since I always see it
from aptitude, I report it here. Please re-assign accordingly.


I'm seeing this since quite some releases and also every now and then in 
unstable
(though probably far less there, as I only run my workstation on unstable, but
all servers on stable).

When I concurrently upgrade my servers (~60) via aptitude, out of that number
arround 10 see the already running install/upgrade process suddenly interrupted
with message like:
Unpacking util-linux-extra (2.38.1-5+deb12u1) over (2.38.1-5+b1) ...
Setting up util-linux-extra (2.38.1-5+deb12u1) ...
dpkg: error: dpkg frontend lock was locked by another process with pid 1064194
Note: removing the lock file is always wrong, can damage the locked area
and the entire system. See .
dpkg: error: dpkg frontend lock was locked by another process with pid 1064194
Note: removing the lock file is always wrong, can damage the locked area
and the entire system. See .
Scanning processes...   
   
Scanning processor microcode... 
   
Scanning linux images...
   

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.
E: Sub-process /usr/bin/dpkg returned an error code (2)
E: Sub-process dpkg --set-selections returned an error code (2)
E: Couldn't revert dpkg selection for approved remove/purge after an error was 
encountered!
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for libc-bin (2.36-9+deb12u4) ...
Press Return to continue, 'q' followed by Return to quit.

Performing actions...
Retrieving bug reports... Done

(and then I continue in a new run).


Unfortunately it doesn't tell the name of pid 1064194 and the offending process
is typically always already gone by then.

Could be check_apt from Icinga or could be 
/usr/share/prometheus-node-exporter-collectors/apt_info.py
from prometheus-node-exporter-collectors .

But in any case, shouldn't apitude/apt/dpkg just permantenly hold the lock
once the process has started until it finishes?

Or could this be a case where something ignores and subsequently breaks the 
lock?


Thanks,
Chris.

Bug#1069037: less: new upstream version

[Christoph Anton Mitterer]

Package: less
Version: 590-2
Severity: wishlist

Hey.

Less 590 is quite outdated (from somewhere mid 2021)... would be
nice to have the current version. There's been quite some changes
meanwhile including improvements to follow mode.

Cheers,
Chris.

Bug#632868: base-files: derive PATH in /etc/profile from /etc/login.defs

[Christoph Anton Mitterer]

Hey.

I mostly forgot the details of this issue ^^

On Mon, 2024-04-15 at 13:08 +0200, Santiago Vila wrote:
> I'd like to be sure that things will not break horribly
> for somebody.

What I can say at least (which is of course not a definite answer) is,
that I personally run my systems since quite some years now without
touching PATH in any of .profile, .bashrc, /etc/profile,
/etc/bash.bashrc.


Some people want to add e.g. ~/bin to their PATH, but I think the
default profile didn't do that out of the box, or did it?

I personally found that (adding ~/bin/ anyway) rather unclean, as it
will get inherited by all programs started by my session, but what most
of the time I actually want is some additional commands or overrides
for just my interactive sessions.
So instead of ever adding ~/bin to the PATH, I do set up any executable
in there as an alias (which won't get exported to other shells).


Cheers,
Chris.

Bug#1064293: less: CVE-2022-48624

[Christoph Anton Mitterer]

Hey.

There seems to be a somewhat similar issue reported by Jakub Wilk on
oss-security:
https://www.openwall.com/lists/oss-security/2024/04/12/5

where quoting causes troubles (though I couldn't replay the demo).

Any chance to get both fixed in Debian unstable?


Cheers,
Chris.

Bug#1068825: apt: possible super minor security issue in apt-get source

[Christoph Anton Mitterer]

On Thu, 2024-04-11 at 22:12 +0200, Julian Andres Klode wrote:
> >   => First, I'm not sure whether this is the right behaviour, as
> > the
> >  "original/modified" file seems to get removed, but it - being
> > a
> >  local file - may actually be something of value to the user.
> >  So maybe it should just move the file to foo.FAILED and error
> >  with non-zero exit status?

and about that?


> I think I'm fine just exiting 1 if the directory already exists,
> after doing the download dance.

At least I'd suggest to also give a human readable error message or
warning.
Just a non-zero exit status will be fine for scripts, but will look
like an erroneous non-zero for humans.


Cheers,
Chris.

Bug#1068826: vobcopy: homepage seems dead

[Christoph Anton Mitterer]

Source: vobcopy
Version: 1.2.1-4
Severity: minor

Hey.

The site listed in the homepage field:
  Homepage: http://vobcopy.org
seems dead and links eventually to some (I guess) Turikish football website.

Should perhaps be removed and replaced with the github repo:
  https://github.com/barak/vobcopy
*if* that is the actual upstream (which I haven't checked).

Cheers,
Chris.

Bug#1068825: apt: possible super minor security issue in apt-get source

[Christoph Anton Mitterer]

Package: apt
Version: 2.7.14
Severity: normal
Tags: security


Hey.

I noted the following behaviour - which may or may not be regarded as
security relevant.
So this is rather a heads up, and in case you think it's fine as it is,
just close it.

I always remembered that apt-get source was ought to verify hashes of
the downloaded files (i.e. secure APT as signed by the repo).

Likewise, I thought to remember that at least at one point in time,
downloads of binary packages (via e.g. apt-get download or aptitude
download) were NOT verified.
Because of that I never trusted these which was quite unhandy.

So I though I'd simply test that (using a local package repo and simply
changing one byte of the files to download), and turns out that apt-get
download DOES also verify the binary packages and exit with non-zero
status of the don't match.
Nice.


So just to be sure I did the same with the source package files.
And here I noted some things:
- It does check freshly downloaded files and exit with non-zero in case
  their hashes mismatch.
- But it does so as well, with *already* downloaded files, and if they
  don't match it silently downloads (also verified) fresh files.
  => First, I'm not sure whether this is the right behaviour, as the
 "original/modified" file seems to get removed, but it - being a
 local file - may actually be something of value to the user.
 So maybe it should just move the file to foo.FAILED and error
 with non-zero exit status?


Then I made some particular tries:
a) On a previously (valid) downloaded source package I modified a byte
   in the local .dsc and modified a byte in the remote .orig.tar.xz.
   apt again notcies the valid local .orig.tar.xz and does nothing and
   notices the invalid local .dsc and re-downloads it (which succeeds
   as I haven't mangled the remote .dsc).

   In principle I'd say this is fine, and there's no direct security
   issue ... and probably not even an indirect one.
   What does however happen - due to the skipped download of the already
   present+valid files - is that the remote corruption of he .orig.tar.xz
   isn't notice.

   I'd say, not an issue, but nevertheless wanted to give a heads up.


b) What may now be the “super minor security issue” is the following:
   apt *does* check already downloaded files for validity and exits
   with zero if they match, right?

   So conceptuall one could have gone two ways:
   - anything local is already trusted because it was verified before
 or the user somehow manually brought it to the system and should
 know what he's doing
   - `apt-get source` acts also like a checker and if the exit status is
 one can assume that the files present are valid

   It seems to be the 2nd, given that it verifies the local files.

   It does however NOT again verify any already unpacked tree.

   So in some super obscure scenarios, a user could come to assume that
   exit status zero means that all the stuff is verified, while in fact
   only the non unpacked files are.

   Again of course, for an attack, there would need to be some way to
   introduce a modified unpacked tree, where one could say that if an
   attacker can do that, it's anyway already too late.

   But simply from that conceptual PoV, it seems to me as if that
   behaviour is unfortunate.

   I do however have no idea for a better behaviour.
   Checking would anyway mean that we need to unpack it - therefore
   wasting further resources.
   And the tree may differ simply because of user modifications, what
   then? Move the dir to xx.NON-PRISTINE?


HTH,
Chris.

Bug#1068674: Document pam_umask change in release notes

[Christoph Anton Mitterer]

Hey.

Also with respect to having this documented in the release note, you
may want to have a look at my comment:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065806#47

I.e. I think it might be usefull to not just indicate that/how people
may use "nousergroups" again, but also to refer to alternatives (like
setting a per-user default UMASK via GECOS) by referring to the
pam_umask(8) manpage.


Cheers,
Chris.

Bug#1065806: fixed in pam 1.5.3-7

[Christoph Anton Mitterer]

My I suggest one further improvement:

I think it would be nice if there was a sentence like:

"See the pam_umask(8) manpage for alternative means to change the
UMASK, for example per-user only."


I guess there are users that would actually want to keep the new
default, but have it e.g. overridden only for their own user (like on
single user systems).

For that, setting it via the GECOS field seems a good way?

Tough unfortunately, clear documentation seems missing on how to
actually do this[0].
It seems umask= must be set in the "other" field (= the 5th) of the
GECOS field, e.g. via chfn --other .


HTH,
Chris.


[0] I've filed https://github.com/linux-pam/linux-pam/pull/786 to
improve on that.
Assuming that will be merged, it's IMO enough to just refer to the
manpage, so that people even know that there are finer grained means.

Bug#1065806: fixed in pam 1.5.3-7

[Christoph Anton Mitterer]

Hey Sam.

There's a typ in the NEWS enty:
>this user a group name that differs from the user name or add
 |
  should probably be "use"


Also, I had to think twice what's meant by "pat" ;-)
> matches their primary user name (user pat's default group is also
>called pat), then files will be group writable by default. To disable

Perhaps placing the two "pat"s in quotes?

Cheers,
Chris.

Bug#1068024: revert to version that does not contain changes by bad actor

[Christoph Anton Mitterer]

One more thing:


Is anyone on the Debian side trying to figure out how far we've been
practically affected?

I mean let's assume we're "lucky", and the backdoor is only in
5.6.0/5.6.1... and that none of the adversary's earlier commits
introduced any serious holes[0] which wouldn't be known yet.

Then many servers running Debian (which is then typically Debian
stable), would be sill safe.

However, many people (and I'd guess that includes DDs/DMs) run their
workstations/laptops with testing/unstable.
So IMO it's not enough to know that Debian stable is likely not
affected - I'd be rather relieved if I'd knew that there's a good
chance that the personal computers of most DDs/DMs (who push uploads,
etc. pp.) were (at least practically) safe.

Some guy decrypted[1] the strings from the maleware's binary payload:
https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01#file-hashes-txt-L115
where only /usr/sbin/sshd would be named.

Should(!) it turn out, that the actual binary payload actually only
affects sshd and especially does not on it's own pull in evil code, it
might at least be that all people who hadn't sshd running (or not
directly accessible because a router/firewall/etc. was in front of it),
would effectively still be safe.
No idea whether or not this is really the case - but if so, it might at
least mean that many workstations/laptops are safe, because they're not
usually directly accessible from the internet.


But even then, it would probably need to be checked whether all the
versions that Debian ever used/shipped in
testing/unstable(/experimental) were actually fully identical to the
versions that are now analysed by forensic folks.

Is the security team doing anything like that?


Cheers,
Chris.


PS: if someone from the security team reads along,
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
which is from Sam James of Gentoo, seems to collect good information on
what is known so far.
Might be worth to add to the links in the security tracker.


[0] There are reports about an added '.' in the CMakeLists.txt
disabling some sandboxing, but AFAICS at least the current version uses
autotools for building?!

[1] He also provided the code he used to do so.
https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01?permalink_comment_id=5006546#gistcomment-5006546

Bug#1068024: revert to version that does not contain changes by bad actor

[Christoph Anton Mitterer]

Hey.

Can we be confidently sure that going back to 5.4.5 is enough?

At least the git tag for that seems to be still signed by the
adversary:
https://git.tukaani.org/?p=xz.git;a=tag;h=9e4835399118b98954f110f76af2a0d504d2f531

The last one, still from Lasse Collin seems to be 5.4.1:
https://git.tukaani.org/?p=xz.git;a=tag;h=f52502e78bf84f516a739e8d8a1357f27eeea75f


Cheers,
Chris.

Bug#1065806: pam: recent upgrade changes previous default umask

[Christoph Anton Mitterer]

Source: pam
Version: 1.5.3-6
Severity: normal

Hey.

Somwhere in between 1.5.2-9.1+b1 and 1.5.3-6 the default umask for non-root
users has changed from 0022 to 0002.
Interestingly, root doesn't seem to be affected.

Intially I suspected b01196659c785b04abc387d324fae61e2ec3b1aa, but at least
when re-commenting the:
> session optional  pam_umask.so
in both files again, it still stays at 0002.

I don't so much mind the change itself, but shouldn't such a big change
go at least into NEWS.Debian and probably also he release notes?

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.7.7-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)

Bug#1065801: [pkg-cryptsetup-devel] Bug#1065801: cryptsetup: Crypttab man pages does not list option _netdev which is required for Network based unlocking via Tang

[Christoph Anton Mitterer]

On Sat, 2024-03-09 at 16:06 -0600, bigops wrote:
> The crypttab which is part of the cryptsetup package in its man page
> does not include the option _netdev.  _netdev is required for
> unlocking Luks volumes via Clevis/Tang.
> 
> Confirmed that the block device is not unlocked without this option
> in the crypttab even though it is not documented. The manpages in
> freedesktop.org has this option (_netdev)
> documented
> (https://www.freedesktop.org/software/systemd/man/latest/crypttab.htm
> l)

That's because it's from systemd's crypttab, which is a latter
development that is in incompatible but uses the same filename.

crypttab(5) manpage already contains a reference on that:
> ON DIFFERENT CRYPTTAB FORMATS
>Please note that there are several independent cryptsetup wrappers with
>their own crypttab format. This manpage covers Debian's implementation
>for initramfs scripts and SysVinit init scripts. systemd brings its own
>crypttab implementation. We try to cover the differences between the
>systemd and our implementation in this manpage, but if in doubt, better
>check the systemd crypttab(5) manpage, e.g. online at
>https://www.freedesktop.org/software/systemd/man/crypttab.html.


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#1065135: sort: error while loading shared libraries: libcrypto.so.3

[Christoph Anton Mitterer]

Hey.


On Thu, 2024-02-29 at 20:37 -0800, Steve Langasek wrote:
> Thanks for this report.

Another case:
Removing libreadline8:amd64 (8.2-3+b1) ...
awk: error while loading shared libraries: libreadline.so.8: cannot open shared 
object file: No such file or directory
awk: error while loading shared libraries: libreadline.so.8: cannot open shared 
object file: No such file or directory
Selecting previously unselected package libreadline8t64:amd64.


Not sure,... shall I report distinct bugs for each of them?


> This is definitely not the behavior we want.  However, the good thing
> is
> that the dependency from coreutils to libssl is new since bookworm. 
> As a
> result, while this can affect users on upgrades from testing, it will
> not
> affect upgrades from bookworm because libssl3t64 will be unpacked and
> configured before the coreutils that uses it.

So at least for this case, only people tracking testing/unstable may be
screwed ;-) ... that is of course only *if* any such error would ever
cause any kind of "corruptions".


> Can you explain why 'sort' is being called at this point in your
> upgrade? 
> Is this from an apt hook or something?

Hard to say... at that point in the upgrade output, are there any APT
hooks running at all? Or is it just DPKG hooks?

In the other case with libpam where runuser failed, it was likely
/usr/share/debian-security-support/check-support-status.hook
as Sam Hartman had pointed out.

TBH, I'm not sure whether I know all places from where DPKG may load
hooks or trigger or the likes.

I looked now at:
$ ls -1 /etc/dpkg/dpkg.cfg.d/
debian-security-support
needrestart

But none of them seems to call sort or awk, at least not directly nor
the script they're executing (I haven't gone any deeper into debconf or
so).

These are the triggers, right?
$ ls -1 /var/lib/dpkg/triggers/
File
Lock
Unincorp
aspell-autobuildhash
ispell-autobuildhash
ldconfig
resolvconf-enable-updates
resolvconf-event
rkhunter-propupd
rkhunter-update-database
texmf-format
texmf-hyphen
texmf-map
twisted-plugins-cache
update-ca-certificates
update-ca-certificates-fresh
update-ca-certificates-java
update-ca-certificates-java-fresh
update-default-ispell
update-default-wordlist
update-initramfs
update-openoffice-dicts
update-sgmlcatalog

But AFAIU the actual code that is executed for the trigger, is in the
postinst of that package, right?
If so,... could be any of them, where sort/awk get called.

Cheers,
Chris.

Bug#1065135: sort: error while loading shared libraries: libcrypto.so.3

[Christoph Anton Mitterer]

Package: libssl3t64
Version: 3.1.5-1.1
Severity: normal
X-Debbugs-Cc: vor...@debian.org

Hey there.


Just a friendly meant heads up:

I saw another case similar to #1065017, i.e. where during the t64 transition.
a library is missing while sort (which I think is also considered essential?) is
executed, causing that to fail.

(Reading database ... 483226 files and directories currently installed.)
Removing libssl3:amd64 (3.1.5-1) ...
sort: error while loading shared libraries: libcrypto.so.3: cannot open shared 
object file: No such file or directory
Selecting previously unselected package libssl3t64:amd64.
(Reading database ... 483215 files and directories currently installed.)


Attaching the full APT term log and CCing, Steve Langasek who seems to have been
among those in charge of the transition.


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.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 libssl3t64 depends on:
ii  libc6  2.37-15

libssl3t64 recommends no packages.

libssl3t64 suggests no packages.

-- no debconf information


term.log.xz
Description: application/xz

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Christoph Anton Mitterer]

On Fri, 2024-02-23 at 08:09 +0100, Niels Thykier wrote:
> > Against what would one file such request? ftp.debian.org?
> That would be my best guess indeed.

Done so in #1065123.

Cheers,
Chris.

Bug#1065123: ftp.debian.org: please provide version information in the Contents files

[Christoph Anton Mitterer]

Package: ftp.debian.org
Severity: wishlist


Hey there.

Currently, AFAIU, the Contents file contains a list of all files in each package
mapped to section/packagename, with different files per arch.

This is unfortunately still not enough to provide exact package lists as e.g. 
done
by apt-file, because packages may have multiple versions available, see e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525813#34

Would be nice if there was a way, that the Contents file could provide the 
missing
piece of information.
Niels Thykier thought about an index with versions.


Thanks,
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#1065017: unuser: error while loading shared libraries: libpam.so.0

[Christoph Anton Mitterer]

Source: pam
Version: 1.5.3-4
Severity: normal

Hey.

During upgrade to 1.5.3-4 I got:
Removing libpam0g:amd64 (1.5.2-9.1+b1) ...
runuser: error while loading shared libraries: libpam.so.0: cannot open shared 
object file: No such file or directory

Guess there may be some timing issue, when libpam0g is already gone
but hasn't been replaced by libpam0t64 yet?

That happened only a bit later:
…
Unpacking libpam0t64:amd64 (1.5.3-4) ...
Setting up libpam0t64:amd64 (1.5.3-4) ...


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.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)

Bug#1064874: wrong behaviour when unsetting/setting some variables

[Christoph Anton Mitterer]

Package: dash
Version: 0.5.12-6
Severity: normal
Tags: upstream


Hey.

POSIX describes[0] unset to:
> unset values and attributes of variables and functions

While the exact detials are perhaps a bit unclear (see the discussion at [1], I
think it is rather clear that unset, on a variable that has no readonly 
attribute,
shall case the variable/value binding AND any attributes to be unset.


This works as expected in dash for most variables, but not some, e.g.:
$ env -i dash
$ export
export PWD='/home/calestyo'
$ export MAIL
$ export
export MAIL
export PWD='/home/calestyo'
$ unset -v MAIL
$ export
export MAIL
export PWD='/home/calestyo'
$ 

Same for MAILPATH and PATH, which made me believe it's perhaps an issue
in `changemail` and `changepath` as given in the struct `varinit` in src/var.c.
But it also happens with IFS, PS1, PS2 and PS4, which have no function listed 
there.
OTOH, it doesn’t happen with ATTY, TERM, LINENO and HISTSIZE.

The consequence of that is at least, that one has no chance to fully unset these
variables, and even if they loose their value, they’ll be exported to executed
commands, possibly altering their behaviour.


I think a similar problem exists when using local variables, but there it's even
worse as it seems to affect any variable names:
```
f()
{
export
echo

local FOO=v
export FOO
export
echo

unset -v FOO
export
}

f
```
gives:
```
export PWD='/home/calestyo'

export FOO='v'
export PWD='/home/calestyo'

export FOO
export PWD='/home/calestyo'

```
and presumaby that `FOO` would then be exported to executed commands.


Cheers,
Chris.


[0] 
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#unset
[1] https://austingroupbugs.net/view.php?id=1806

Bug#1064799: dvdbackup: Vcs-* fields (and perhaps Homepage) outdated

[Christoph Anton Mitterer]

Source: dvdbackup
Version: 0.4.2-4.1
Severity: minor


Hey.

The Vcs-* package fields and perhaps also Homepage (the SF site and
repo there seems even more outdated compared to launchpad) may be
outdated.

Cheers,
Chris.

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Christoph Anton Mitterer]

On Thu, 2024-02-22 at 08:59 +0100, Niels Thykier wrote:
> One challenge we have here is that a package can have multiple
> versions 
> in a given suite at the same time; notably in unstable.

And multiple arches...


> For people that want better support here, please request the archive 
> maintainers to provide an index with versioning so that apt-file can
> do 
> proper filtering.

Against what would one file such request? ftp.debian.org?


Cheers,
Chris.

Bug#525813: apt-file: Doesn't work very well when multiple package versions are available

[Christoph Anton Mitterer]

Hey.

I took the liberty to forcemerge these two bugs (578727 and 525813) as
they seem to be about the same thing.

My suggestion would be that per default, the apt-file should print the
package name with =version.
Perhaps with the exception if only one version is available (or maybe
there should be an option, that causes the =version to be omitted, if
and only if, only on version is available).

When specifying the package name I think it should also allow =version
to be appended and follow the behaviour of e.g. apt-get cache, that is:
- if no version is given, match all available versions
- if one is given, match only that.


Cheers,
Chris.

Bug#1064036: dpkg: wrong dpkg-query exit status on syntax error?

[Christoph Anton Mitterer]

Hey Guillem.

On Fri, 2024-02-16 at 05:26 +0100, Guillem Jover wrote:
> 
> Thanks!

Well rather: thank you, for your constant efforts to DPKG and the whole
ecosystem.


> > At least it seems to make it impossible to definitely find out
> > whether a package
> > is not installed (respectively not existant).
> 
> Exactly.

Maybe it would also be worth to elaborate on:
   1   The  requested  query  failed  either fully or partially, due to no
   file  or  package   being   found   (except   for   --control-path,
   --control-list and --control-show were such errors are fatal).

My understanding would have been, that e.g. when searching for a
package, 1 would in practise mean that it doesn't exist at all (when
looking from APT’s PoV) respectively is in the state 'not-installed'.

So I guess for end-users it might be helpful to be told that, i.e. that
these two things (non-existing from APT) and non-installed are the same
from DPKG’s PoV, and would trigger 1.

Also perhaps notifying somewhere that 'not-installed' will never really
show up anywhere as a printed query result.



> This is used for field names, be them real or virtual, so erroring
> out
> on fields that do not exist would seem bad. But there's the
> distinction between the real fields and virtual ones, where the
> latter
> always contain a colon. So I guess I could make the latter, at least
> warn if they do not exist. My main concern with making them errors,
> is
> that this would break backwards and/or forwards compatibility, where
> you could not use a new or renamed field with old or new releases.

Warnings are at last difficult to use when scripting.

And btw: it also succeeds if there's no colon, e.g.:
$ dpkg-query --showformat='${foobar}' --show  2>/dev/null ; echo $?
0


Thanks,
Chris.

PS: In the dpkg-query manpage, there's:
   Desired action:

   u = Unknown
   i = Install
   h = Hold
   r = Remove
   p = Purge

   Package status:

   n = Not-installed
   c = Config-files
   H = Half-installed
   U = Unpacked
   F = Half-configured
   W = Triggers-awaiting
   t = Triggers-pending
   i = Installed

   Error flags:

= (none)
   R = Reinst-required

I think, when these are actually printed, the full names are all
lowercase, i.e. installed not Installed ... might perhaps make sense to
align that?

Bug#1064036: dpkg: wrong dpkg-query exit status on syntax error?

[Christoph Anton Mitterer]

Package: dpkg
Version: 1.22.4
Severity: normal

Hey.

dpkg-query manpage says:
EXIT STATUS
   0   The requested query was successfully performed.

   1   The  requested  query  failed  either fully or partially, due to no
   file  or  package   being   found   (except   for   --control-path,
   --control-list and --control-show were such errors are fatal).

   2   Fatal  or unrecoverable error due to invalid command-line usage, or
   interactions with the system, such as  accesses  to  the  database,
   memory allocations, etc.

E.g.:
 $ dpkg-query --showformat='${db:Status-Status}' --show --list 2>/dev/null ; 
echo $?
 2
looks good, as does
 $ dpkg-query --showformat='${db:Status-Status}' --show not-existing-package 
2>/dev/null ; echo $?
 1

But e.g.
 $ dpkg-query --showformat='${db:Status-Statu' --show  2>/dev/null ; echo $?
 1
causes also 1, though it fails because of the syntax error in the format string.

Shouldn't that be a 2?


At least it seems to make it impossible to definitely find out whether a package
is not installed (respectively not existant).


btw. it will also not fail at all in cases like:
 $ dpkg-query --showformat='${db:Status-Statu}' --show  2>/dev/null ; echo $?
 0
where the field doesn't exist. Not sure whether that’s desired or not


Cheers,
Chris.


-- Package-specific info:

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
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 dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b2
ii  libc62.37-15
ii  liblzma5 5.4.5-0.3
ii  libmd0   1.1.0-2
ii  libselinux1  3.5-2
ii  libzstd1 1.5.5+dfsg2-2
ii  tar  1.35+dfsg-3
ii  zlib1g   1:1.3.dfsg-3+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.7.11
ii  debsig-verify  0.29

-- no debconf information

Bug#1061347: cryptsetup-nuke-password: improving package description

[Christoph Anton Mitterer]

Source: cryptsetup-nuke-password
Version: 4+nmu1
Severity: wishlist


Hey.

I think the description should add some important details:

*If* a sufficently advanced 3-letter-government organisation would seize 
someone’s computer,
it's rather unlikely that the idea of wiping the master keys with a special 
passphrase would
work out, since copies of the medium containing the plain dm-crypt / LUKS would 
likely have
been made (quite likely, even unknown to the user... maybe while he wasn’t at 
home).

Instead, unlocking would then not only give proof, that the user actually has 
access to the
encrypted volume (which may already be enouhg to disappear at some black site 
;-) )...
but also give "them" a key (keylogger), which "they" could then use to open the 
device,
simply from some other system, not booting into the one that contains the 
"nuke" code, and just
have access to the data.


I think right now, people may quite easily get a sense of wrong security, while 
they'd
acutally make things worse (by giving out a key).


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.6.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE
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)

Bug#1057963: annotate-output: big overhaul - updated and looking for some reviewers

[Christoph Anton Mitterer]

Hey.

I've just force pushed the PR[0] over at salsa, which:
- Rebased the patchset on current master.
- Also fixed a bug in the previous a36873c2, where the IFS= was not
  just wrong (it would have needed to be IFS=' ' but also ineffective,
  as it wouldn’t be used for the expansion of $*.
  The new solution works without messing around with IFS at all
- Added the new 212e0955 which is IMO particularly nice, as it properly
  escapes the command name and arguments in the annotated output (the
  Started … line), thereby allowing to properly reconstruct what has
  actually been done.

Would be nice if some devscripts developers could review & merge these.

I know it's a lot of commits, but in principle the tools should be in a
working state after each single commit,... so the reviewing could be
done one by one.
Also each commit is quite small and well documented (IMO ^^).

Thanks.
Chris


[0]https://salsa.debian.org/debian/devscripts/-/merge_requests/377#note_456804

Bug#1056989: libaacs: build aacs_info

[Christoph Anton Mitterer]

Control: tags -1 + patch

Hey Dylan and people from the multimedia team.

I'd have made a PR at:
https://salsa.debian.org/multimedia-team/libaacs/-/merge_requests/2

which packages the already built aacs_info in a new libaacs-bin
package.

Would be nice if this could be reviewed, merged and a new version
uploaded anytime soon :-)


Thanks,
Chris.

Bug#237925: ITP: cdemu -- CD drive emulator for Linux

[Christoph Anton Mitterer]

On Tue, 2024-01-16 at 09:47 +0100, Matteo Bini wrote:
> for
> instance if it's fine to make as many DEB packages as the source
> tarballs CDEmu is divided in.

Probably best if you ask at the mentors mailing list. But I'd guess
it's totally fine.
Though I'd personally probably keep everything in one source package
(and just build multiple binary packages from that), simply because the
parts are all in one git repo.

Cheers,
Chris.

Bug#237925: ITP: cdemu -- CD drive emulator for Linux

[Christoph Anton Mitterer]

Hey Matteo.

Are you still working on packaging CDemu for Debian?

If not, Robert Ayrapetyan indicated interest in taking the ITP over:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237925#84


Cheers,
Chris

Bug#1060237: openjdk-17-jre-zero cannot be installed anymore

[Christoph Anton Mitterer]

Package: openjdk-17-jre-zero
Version: 17.0.9+9-2
Severity: normal


Hey.

Since upgrading the other OpenJDK packages to 17.0.10~6ea-1,
openjdk-17-jre-zero is uninstallable.

Cheers,
Chris.

Bug#1059826: git-delta: fails to run without git

[Christoph Anton Mitterer]

Package: git-delta
Version: 0.16.5-5
Severity: normal
Control: forwarded -1 https://github.com/dandavison/delta/issues/1593

Hey.

It seems delta alone fails to run when git is not installed.


$ touch 1 2
$ delta 1 2
Failed to execute the command 'git': No such file or directory (os error 2)
$ delta --no-gitconfig 1 2
Failed to execute the command 'git': No such file or directory (os error 2)
$

Interestingly it does work with:
$ delta <(echo a)  <(echo b)

Depending on the outcome of the upstream bug, the package may need to depend
on the `git` package.

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.6.8-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 git-delta depends on:
ii  libc62.37-13
ii  libgcc-s113.2.0-9
ii  libgit2-1.7  1.7.1+ds-2

git-delta recommends no packages.

Versions of packages git-delta suggests:
ii  bash-completion  1:2.11-8

-- no debconf information

Bug#1058960: dpkg: warning: unable to delete old directory '/usr/share/debian-reference': Directory not empty

[Christoph Anton Mitterer]

Package: debian-reference
Version: 2.109
Severity: normal


Hey.

Something looks odd with the package’s files registration in Debian.
On upgrade from 2.108 to 2.109 I got:
Unpacking debian-reference-common (2.109) over (2.108) ...
dpkg: warning: unable to delete old directory 
'/usr/share/debian-reference/images': Directory not empty
Preparing to unpack .../01-debian-reference-en_2.109_all.deb ...
Unpacking debian-reference-en (2.109) over (2.108) ...
dpkg: warning: unable to delete old directory '/usr/share/debian-reference': 
Directory not empty


And indeed, none of these files seem to belong to a Debian package:
$ dpkg -S /usr/share/debian-reference/images/*
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/caution.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/home.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/important.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/next.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/note.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/prev.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/tip.png
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/up.gif
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/images/warning.png
$ dpkg -S /usr/share/debian-reference/*
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/apa.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch01.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch02.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch03.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch04.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch05.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch06.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch07.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch08.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch09.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch10.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch11.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/ch12.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/debian-reference.css
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/debian-reference.en.pdf
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/debian-reference.en.txt.gz
dpkg-query: no path found matching pattern /usr/share/debian-reference/images
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/index.en.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/index.html
dpkg-query: no path found matching pattern 
/usr/share/debian-reference/pr01.en.html

These files do however seem to exist in the package, though registered as:
$ grep /usr/share/doc/debian-reference-common/docs 
/var/lib/dpkg/info/debian-reference-common.list
/usr/share/doc/debian-reference-common/docs
/usr/share/doc/debian-reference-common/docs/.htaccess
/usr/share/doc/debian-reference-common/docs/debian-reference.css
/usr/share/doc/debian-reference-common/docs/images
/usr/share/doc/debian-reference-common/docs/images/caution.png
/usr/share/doc/debian-reference-common/docs/images/home.png
/usr/share/doc/debian-reference-common/docs/images/important.png
/usr/share/doc/debian-reference-common/docs/images/next.png
/usr/share/doc/debian-reference-common/docs/images/note.png
/usr/share/doc/debian-reference-common/docs/images/prev.png
/usr/share/doc/debian-reference-common/docs/images/tip.png
/usr/share/doc/debian-reference-common/docs/images/up.gif
/usr/share/doc/debian-reference-common/docs/images/warning.png
/var/lib/dpkg/info$ grep /usr/share/doc/debian-reference-common/docs 
/var/lib/dpkg/info/debian-reference-en.list
/usr/share/doc/debian-reference-common/docs
/usr/share/doc/debian-reference-common/docs/apa.en.html
/usr/share/doc/debian-reference-common/docs/ch01.en.html
/usr/share/doc/debian-reference-common/docs/ch02.en.html
/usr/share/doc/debian-reference-common/docs/ch03.en.html
/usr/share/doc/debian-reference-common/docs/ch04.en.html
/usr/share/doc/debian-reference-common/docs/ch05.en.html
/usr/share/doc/debian-reference-common/docs/ch06.en.html
/usr/share/doc/debian-reference-common/docs/ch07.en.html
/usr/share/doc/debian-reference-common/docs/ch08.en.html
/usr/share/doc/debian-reference-common/docs/ch09.en.html
/usr/share/doc/debian-reference-common/docs/ch10.en.html

Bug#860933: git-crecord: stage command just commits

[Christoph Anton Mitterer]

Hey Paul.

AFAICS, this works now in at least the version as of sid.

Can we close this issue?

Thanks,
Chris.

Bug#990913: ausweisapp2: creates config in '~/.config/Unknown Organization'

[Christoph Anton Mitterer]

Hey.

Few weeks ago I've again stumbled over this, and tried to fix it, but
my Qt coding skills are worse than absolutely zero ^^

I did however found e.g. this:
https://gitlab.cs.fau.de/rudis/passt-mac/-/commit/00d4f8fc2c729b1baf723cacd2b5942b032b6784
which seems a commit that fixes a similar problem.

Maybe this helps someone who knows Qt to craft a fix.


I further tried to contact upstream (Ticket: INC-2023-124927) but was
told, that they provide no Linux support:

On Thu, 2023-11-16 at 10:58 +, support.ausweisa...@governikus.de wrote:
> Der Bund stellt aktuell leider keine offiziell unterstützte Version
> der AusweisApp für Linux bereit.
> Diese Entscheidung wurde auf Grundlage der geringen Marktverbreitung
> von Linux und der zusätzlich starken Fragmentierung der Linux-
> Distributionen getroffen.
> 
> ...
> 
> Bitte haben Sie jedoch Verständnis dafür, dass wir (die Governikus
> KG) als mit der Entwicklung der AusweisApp2 beauftragte Firma für den
> Einsatz unter Linux keinen Support leisten können.

and they've close-ignored the ticket right away ^^


Cheers,
Chris.

Bug#1057624: ausweisapp2: new upstream version (and name)

[Christoph Anton Mitterer]

Hey John.


On Wed, 2023-12-06 at 09:17 +0100, John Paul Adrian Glaubitz wrote:
> I am naturally aware of the new release because I am in direct
> contact with
> one of the upstream maintainers. The withheld update to 2.x is
> intentional
> for two reasons.

Ah I see. :-)

Then I wrongly thought you might have missed the new major version,
when I saw that new package versions got released from the old major
branch :-D


> The user interface
> basically now looks like a scaled up phone app on the desktop which I
> consider
> a huge step back.

Yeah,... I don't know why so many people think that smartphone UIs are
the way to go I mean smartphones and their UI style do have their
fixed place in the world, but one cannot really professionally work
with them.


> Overall, there is no urgent need to update to version 2.x right now,
> so I rather
> want to take my time to come up with a proper transition plan with
> the potential
> prospect of a better user interface.

Absolutely fine :-)


How's your contact with upstream? Few week ago I wrote upstream about
that still annoying #
.
But I was told quite quickly in an automated-reply fashion, that there
is no Linux support.


Cheers,
Chris.

Bug#1058060: python3-ntp: invalid escapes warnings during package install

[Christoph Anton Mitterer]

Package: python3-ntp
Version: 1.2.2+dfsg1-3
Severity: normal


Hey.

When upgrading to the current version, I got.
Setting up python3-ntp (1.2.2+dfsg1-3) ...
/usr/lib/python3/dist-packages/ntp/util.py:641: SyntaxWarning: invalid escape 
sequence '\]'
  m = re.match("([:.[\]]|\w)*", inhost)
/usr/lib/python3/dist-packages/ntp/util.py:1398: SyntaxWarning: invalid escape 
sequence '\%'
  if not c.isalnum() and c not in "/.:[] \%\n":


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.5.0-5-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 python3-ntp depends on:
ii  libbsd0  0.11.7-4
ii  libc62.37-13
ii  libssl3  3.1.4-2
ii  python3  3.11.6-1

python3-ntp recommends no packages.

python3-ntp suggests no packages.

-- no debconf information

Bug#1057963: annotate-output: big overhaul

[Christoph Anton Mitterer]

Package: devscripts
Version: 2.23.6
Severity: wishlist
Tags: patch


Hey.

Shamlessly copy my text from:
https://salsa.debian.org/debian/devscripts/-/merge_requests/377

This is some major overhaul of annotate-output.

The core parts are IMO:
- getting rid of any shell variables set by the script itself, which
  may override variables that the caller wants to export to the
  invoked program (a355a37f1e285673d0fcb54fdff87893646848b9,
  383a82917fe180cc3a45dec520afa139b552e093 and
  ecea512825e964d073c74f6c9961ced44d5d3809)
- greatly improving performance when no date conversion specifiers are
  used (c236a7ecb4c178d72a4f477be451948831684063)

Per default the behaviour (in terms of output format) should not be
changed, at least the stuff that might get parsed by someone.

Please notice that I did some ugly reference of another commit ID (that
of a355a37f1e285673d0fcb54fdff87893646848b9) in some commits. So if you
don’t apply that on top of the current master or change commits, please
adapt the commit messages, or let me do it.

Other than that, please review and merge[0] :-)

Thanks, Chris.


[0] Or even better, let someone skilled in C and especially IO streams
(the latter being a weakness of mine), re-implemented it properly.

PS: I'm attaching the patch series here, too, though I guess I'd prefer
to discuss things on salsa/Gitlab.
>From 4091b4a3c12d8ef98fd949d09ab53d9dfaaf6efa Mon Sep 17 00:00:00 2001
From: Christoph Anton Mitterer 
Date: Sun, 10 Dec 2023 05:23:36 +0100
Subject: [PATCH 01/23] annotate-output: fixed typo

Signed-off-by: Christoph Anton Mitterer 
---
 scripts/annotate-output.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/annotate-output.sh b/scripts/annotate-output.sh
index 84025f58..da308252 100755
--- a/scripts/annotate-output.sh
+++ b/scripts/annotate-output.sh
@@ -70,7 +70,7 @@ echo Started "$@" | handler $formatter I
 
 # The following block redirects FD 2 (stderr) to FD 1 (stdout) which is then
 # processed by the stderr handler. It redirects FD 1 (stdout) to FD 4 such
-# that it can later be move to FD 1 (stdout) and handled by the stdout handler.
+# that it can later be moved to FD 1 (stdout) and handled by the stdout 
handler.
 # The exit status of the program gets written to FD 2 (stderr) which is then
 # captured to produce the correct exit status as the last step of the pipe.
 # Both the stdout and stderr handler output to FD 3 such that after exiting
-- 
2.43.0

From a355a37f1e285673d0fcb54fdff87893646848b9 Mon Sep 17 00:00:00 2001
From: Christoph Anton Mitterer 
Date: Sun, 10 Dec 2023 05:42:22 +0100
Subject: [PATCH 02/23] annotate-output: prevent `PROGNAME`-variable from
 leaking to command
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

annotate-output is a wrapper program that runs other programs. Such programs may
in turn make use of arbitrary environment variables.

Every variable that is set within the script, may have been already in the
environment of the shell (because it was already exported when `annotate-output`
itself was called).
The script would then overwrite the variable and export it further to the actual
program, which would not get the value as expected by the user.

A simple example (before this commit) would have been:
```
$ export PROGNAME=foo; annotate-output env | grep -E ^.{12}PROGNAME=
15:50:19 O: PROGNAME=annotate-output
```

Unfortunately, the problem cannot be fully solved in the Shell Command Language,
amongst others because:
- Shell always unconditionally set some own variables - which again my have
  already been marked as exported.
- Environment variables need to to be valid shell variables (e.g. `*=value`) is
  in principle a valid environment variable, but not a shell variable) and it’s
  unspecified whether such are still passed on to commands (called from the
  shell) or not.

A re-implementation in e.g. C would be needed to overcome this limitation (side
note: even Python cannot be made 100% transparent of the environment, see
https://github.com/python/cpython/issues/93446).

Signed-off-by: Christoph Anton Mitterer 
---
 scripts/annotate-output.sh | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/annotate-output.sh b/scripts/annotate-output.sh
index da308252..25307a17 100755
--- a/scripts/annotate-output.sh
+++ b/scripts/annotate-output.sh
@@ -14,8 +14,6 @@
 
 set -eu
 
-PROGNAME=${0##*/}
-
 handler() {
while IFS= read -r line; do
printf "%s %s: %s\n" "$($1)" "$2" "$line"
@@ -27,7 +25,7 @@ handler() {
 
 usage() {
echo \
-"Usage: $PROGNAME [options] program [args ...]
+"Usage: ${0##*/} [options] program [args ...]
   Run program and annotate STDOUT/STDERR with a timestamp.
 
   Options:
-- 
2.43.0

>From 554612e126d5fa6bafb3af2fad50d8e442dde777 Mon Sep 17 00:00:00 2001
From: Christoph Anton Mitterer 
Date: Sun, 10 Dec 2023 06:2

Bug#775962: udftools: No means of repairing a UDF filesystem i.e. no fsck.udf

[Christoph Anton Mitterer]

On Sun, 2023-12-10 at 01:23 +0100, Pali Rohár wrote:
> There is also beta version of udffsck for udftools:
> https://github.com/pali/udftools/pull/7

Ah nice. Is that going to be released/packaged?

Thanks,
Chris

Bug#775962: udftools: No means of repairing a UDF filesystem i.e. no fsck.udf

[Christoph Anton Mitterer]

Hey.

FIY: It seems netbsd developed a fsck for UDF[0], but it would require
porting to LInux.

Cheers,
Chris.


[0] https://wiki.netbsd.org/projects/project/fsck_udf/

Bug#1023429: pgrep/pkill: remove trailing 0x00 from matching?

[Christoph Anton Mitterer]

Hey.

Just for the records:
At least as of now, ssh no longer seems to add the multiple 0x0 to it's
cmdline.

But I guess the "problem" (should it ever come back or exist for other
programs) in pgrep/pkill still remains.


Cheers,
Chris.

Bug#1057624: ausweisapp2: new upstream version (and name)

[Christoph Anton Mitterer]

Package: ausweisapp2
Version: 1.26.7-2
Severity: wishlist


Hey.

A new upstream major version (2.x) is out, and they've apparently also
rebranded it back to just "AusweisApp" (i.e. no longer a 2 in the name).


Cheers,
Chris.

Bug#1056989: libaacs: build aacs_info

[Christoph Anton Mitterer]

Source: libaacs
Version: 0.11.1-2
Severity: wishlist


Hey.

Upstream contains the aacs_info program at:
src/examples/aacs_info.c

would it be possible to build and package that (e.g. as libaacs-tools or so), 
too?

Thanks,
Chris.

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

[Christoph Anton Mitterer]

On Sun, 2023-11-26 at 15:52 +1100, Dmitry Smirnov wrote:
>   https://salsa.debian.org/debian/smartmontools/-/commit/625f38bc
Thanks :-)

And sorry again for the noise and not having checked --install in
detail before reporting.

Cheers,
Chris

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

[Christoph Anton Mitterer]

Hey Paul.

On Sun, 2023-11-26 at 11:01 +0800, Paul Wise wrote:
> BTW Chris, I imagine you might have some issues for this page:
> 
> https://wiki.debian.org/PrivacyIssues

In which respect?

AFAICS that page is mainly about privacy (in the sense of calling
home).

My main concern is rather security, in terms of packages which download
code or similar from remote (e.g. like Firefox used to download the
binary-only OpenH264 stuff).

And we do unfortunately have quite some "downloader" packages in Debian
and no general handling of how this is done.
Some packages do it in a secure manner (IMO the best way is still to
have a fresh version of the downloader package for every new upstream
version, and the downloader package contains a hash sum of the
downloaded content - that should prevent all things like
downgrade/blocking attacks... but of course requires the package to be
kept up2date).


Now if you meant that I would want to add something to the above wiki,
because of update-smart-drivedb "calling home", then from my PoV this
isn't really necessary:

I think the purpose of update-smart-drivedb is pretty clear from its
documentation: fetching current data from upstream
(Actually I'd rather think that the --install functionality should be
outside of the tool.)

It should be obvious to anyone, that upstream will at least know your
IP from that.

IMO, that's not really a privacy issue, as its obvious.

What are rather issues is, if e.g. Firefox silently sends all kinds of
data to Mozilla (the whole "healthreport" and telemetry stuff) and too
Google ("Safe Browsing") and possibly even more.
Or when a tool like gitg contacts gravatar[0] with all emails it
encounters in a git repo, from which others could rather easily deduce
*which* repo one is working on.


Cheers,
Chris.


[0] There's an option now in it to disable it (after I've lobbied for
quite a while for it ^^), not sure whether it's on/off per default,
though.

Bug#1056946: duperemove: new upstream version

[Christoph Anton Mitterer]

Package: duperemove
Version: 0.11.2-3
Severity: wishlist

Hey

Debian’s 0.11.2 is older than 2 years. 0.14.1 is out with many changes.

Thanks,
Chris.

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

[Christoph Anton Mitterer]

Control: severity -1 normal
Control: tags - security


Hey.

On Sun, 2023-11-26 at 12:23 +1100, Dmitry Smirnov wrote:
> I think you misunderstood that invocation of `update-smart-drivedb`
> in postinst is an equivalent of 
> 
> ```
> cp -f /usr/share/smartmontools/drivedb.h 
> /var/lib/smartmontools/drivedb/
> ```

Indeed. At least from the documentation (only had a short glance now
what it actually does if file= is set... but seems you're right).

Sorry for that, I had wrongly in mind that --install would also
download.


Nevertheless, do you think it would possible to adapt it to check
whether update-smart-drivedb is executable and if not fall back to the
old code?

Background is that at the university cluster I administrate we have set
dpkg-statoverrides for various "code downloader" commands like update-
smart-drivedb, update-ieee-data or update-pciids, which removes their
executeable bit, so that they're at least not accidentally run.

Would be nice if it could be kept that way.


Thanks,
Chris.

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#1056378: sshfs: cannot use setuid= and drop_privileges from mount as sshfs mount helper seem to not use FUSE3

[Christoph Anton Mitterer]

Package: sshfs
Version: 3.7.3-1.1
Severity: normal

Hey.

The following problem persits also in unstable.

Doing the following fails:
# mount foo.example.org:/ /mnt -t fuse.sshfs -o setuid=someUser,furtherOptions
fuse: unknown option(s): `-o setuid=someUser'

Whereas it does work if one calls e.g.:
/usr/sbin/mount.fuse3 foo.example.org:/ /mnt -t fuse.sshfs -o 
setuid=someUser,furtherOptions

The problem seems to be that the setuid= and drop_privileges work only when 
called via FUSE3
(see mount.fuse(8)) but sshfs’ mount helpers (which mount(1) calls):
   /usr/sbin/mount.fuse.sshfs
   /usr/sbin/mount.sshfs
which are symlinks to:
   /usr/bin/sshfs
seem to not use FUSE3 (despite the binary being linked against libfuse3).

Just using /usr/sbin/mount.fuse3 is no real alternative either, as e.g. systemd
uses simply `mount` for .mount units.


Would be nice if this could be fixed (and backported to bookworm).

Thanks,
Chris.


-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/2 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 sshfs depends on:
ii  fuse3   3.14.0-4
ii  libc6   2.36-9+deb12u3
ii  libfuse3-3  3.14.0-4
ii  libglib2.0-02.74.6-2
ii  openssh-client  1:9.2p1-2+deb12u1

sshfs recommends no packages.

sshfs suggests no packages.

-- no debconf information

Bug#1056135: regression: hibernation issues with 255~rc2-1

[Christoph Anton Mitterer]

Just for the records:

There's now a fix for this at:
  https://github.com/systemd/systemd/pull/30074
(which I confirmed working)

>From my side it's not super important to have that cherry picked.
I'd hope it might still make it into 255, so for that I can easily wait
and it saves you guys some work!

Thanks,
Chris.

Bug#1056135: regression: hibernation issues with 255~rc2-1

[Christoph Anton Mitterer]

Control: forwarded -1 https://github.com/systemd/systemd/issues/30083

On Fri, 2023-11-17 at 13:48 +, Luca Boccassi wrote:
> Please open an issue on github and attach debug level logs showing
> the
> error


Done.

Cheers,
Chris.

Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Christoph Anton Mitterer]

On Fri, 2023-11-17 at 15:37 +0100, Michael Biebl wrote:
> downgrades are not officially supported by Debian.

Sure... and if it's not fixable... well then it's not. But at least it
would be better then to abort the downgrade if it's detected that e.g.
a DE is running.
In my case it didn't matter but people may have important/unsaved data
open.

And maybe there is just some accidental restart of dbus or so involved
(that usually kills of the DE, too).


Cheers,
Chris.

Bug#1013356: fzf: Bash completions not active by default

[Christoph Anton Mitterer]

On Fri, 2023-11-17 at 08:40 +0100, Bastian Venthur wrote:
> If bash completion is not enabled on purpose, I would
> consider this behaviou a bug. But I believe just enabling the bash
> completion
> by default would be the better solution.

In any case, please do not enable the fzf-completion (i.e. **) by
default, unless there's an easy way to manually disable that (which is
not easy if the file is installed to /usr/share/bash-
completion/completions/fzf )

The problem with fzf’s completion file is, that it contains both:
1. the completion for the fzf program itself
2. the "generic" (well only to some very limited amount) **
   completion

The latter is unfortunately rather limited and even buggy in many
cases.
I tried to get that improved, but upstream eventually decided that he
doesn't want the functionality to be expanded/fixed.

Alternative integrations exist, but these do not work properly when
fzf’s own is also enabled.


Therefore, please stop installing the completion file to:
   /usr/share/bash-completion/completions/fzf

This is anyway not an appropriate location, as neither of the two
completions mentioned above actually use bash-completion.

IMO the proper way would be:
- users need to manually source (2) (or manually install it in
  /etc/profile.d or the likes)
- the parts for (1) should be split of into a separate file and that
  could actually be installed into
  /usr/share/bash-completion/completions/
  (not because it would really use anything of bash-completion, but
  only to get the opportunistic loading of that)

I've had talked to upstream about splitting the two
(https://github.com/junegunn/fzf/issues/3457), but again... he does not
seem to have much interest in improving things.

If you really need to have fzf's completion file automatically loaded,
please add some easy way to disable that. Otherwise you break the setup
of people who want to use better alternative integrations.

Cheers,
Chris.

Bug#1056135: regression: hibernation issues with 255~rc2-1

[Christoph Anton Mitterer]

Package: systemd
Version: 255~rc2-1
Severity: normal

Hey.

The following two issues are both solved when downgrading to 254.5-1 (and 
completely
rebooting the system, before trying again - they also shop up again, only after
completely rebooting the upgraded systemd again):

1) I have a somewhat special hibernation setup.
   Hibernation goes to a btrfs swap file on top of dm-crypt.
   The following unit files are used for that:
   /etc/systemd/system/data-swap-hibernation.swap:
[Unit]
Before=systemd-hibernate.service
StopWhenUnneeded=true

[Swap]
What=/data/swap/hibernation
Options=noauto

[Install]
RequiredBy=systemd-hibernate.service
   
   I also have a /etc/systemd/system/hibernation-cleanup.service:
[Unit]
Description=synchronise cached writes to persistent storage and free 
page cache before hibernation in order to minimise the image
Before=hibernate.target

[Service]
Type=oneshot
ExecStart=sync
ExecStart=@sh %n:sh -c 'printf 1 >/proc/sys/vm/drop_caches'

[Install]
WantedBy=hibernate.target
   but I don't think this has anything to do with the issue here.

   There are symlinks:

/etc/systemd/system/systemd-hibernate.service.requires/data-swap-hibernation.swap
 -> /etc/systemd/system/data-swap-hibernation.swap
/etc/systemd/system/hibernate.target.wants/hibernation-cleanup.service 
-> /etc/systemd/system/hibernation-cleanup.service


   Especially, the hibernation file may not be availabe (or activated as swap),
   yet, when I go into hibernation.
   This caused desktop environments (I use Cinnamon) not to show the "Hiberate"
   button, which I've been able to solve via a:
   
/etc/systemd/system/systemd-logind.service.d/disable-hibernation-swap-check.conf:
[Service]
Environment="SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1"

   However, starting with 255~rc2-1 (but solved when going back to 254.5-1)
   this no longer seems to have an effect. At least Cinnamon then doesn't show
   the Hibernate button anymore.


2) When, because of (1), manually calling:
   # systemctl hibernate
   Call to Hibernate failed: No such file or directory

   The above error occurs (which itdoes not with 254.5-1), but the system then
   still seems to hibernate normally (and can also resume from that).


Notice also that I've changed logind.conf and sleep.conf.


Any ideas? I can forward the issue upstream if you think it's happening there.

Thanks,
Chris.



-- Package-specific info:

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

Kernel: Linux 6.5.0-4-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 systemd depends on:
ii  libacl12.3.1-3
ii  libapparmor1   3.0.12-1
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-6
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.4-0.1
ii  libmount1  2.39.2-6
ii  libpam0g   1.5.2-9.1
ii  libseccomp22.5.4-2
ii  libselinux13.5-1
ii  libssl33.0.12-2
ii  libsystemd-shared  255~rc2-1
ii  libsystemd0255~rc2-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.39.2-6
ii  systemd-dev255~rc2-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]  1.14.10-3
ii  ntpsec [time-daemon]1.2.2+dfsg1-2

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1+b1
ii  libip4tc2 1.8.9-2
ii  libp11-kit0   0.25.0-5
ii  libqrencode4  4.1.1-1
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
ii  polkitd   123-3
ii  python3   3.11.4-5+b1
pn  python3-pefile
pn  systemd-boot  
ii  systemd-container 255~rc2-1
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-3
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 255~rc2-1
ii  libpam-systemd 255~rc2-1
ii  udev   255~rc2-1

-- Configuration Files:
/etc/systemd/logind.conf changed:
[Login]
HandleSuspendKey=ignore
HandleSuspendKeyLongPress=ignore
HandleLidSwitch=lock
HandleLidSwitchExternalPower=lock
HandleLidSwitchDocked=lock

/etc/systemd/sleep.conf changed:
[Sleep]
HibernateMode=shutdown platform


-- no debconf information

Bug#1055822: debhelper: support systemd generators

[Christoph Anton Mitterer]

Package: debhelper
Version: 13.11.7
Severity: wishlist
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org


Hey there.

Would it make sense and be possible for the systemd debhelper programs to
support systemd generators?

I think of something like just copying the file to the right location and
execute a systemd daemon-reload (which debhelper seems to already do on remove
when there are systemd units, but not on configure, so the genertor won't have
excuted).
It could perhaps auto-detect generator files as:
  .systemd.generator
or so.


Cheers,
Chris.

Bug#1055372: btrfs-progs: new upstream version

[Christoph Anton Mitterer]

Hey.

Upstream has released 6.6.1, which contains an important fix.

6.6 should not be used, see:
https://lore.kernel.org/linux-btrfs/20231105222046.19483-1-dste...@suse.com/T/#u

Cheers,
Chris.

Bug#1055372: btrfs-progs: new upstream version

[Christoph Anton Mitterer]

Package: btrfs-progs
Version: 6.3.2-1
Severity: wishlist


Hey.

6.6 is out ad 6.3 is rather outdated now :-)

Cheers,
Chris.

Bug#1055315: webext-ublock-origin-firefox: new upstream version

[Christoph Anton Mitterer]

Package: webext-ublock-origin-firefox
Version: 1.52.0+dfsg-1
Severity: wishlist

Hey.

1.53.0 is out since a few days :-)

Thanks,
Chris.

Bug#1053822: Acknowledgement (openssh-client: consider patch for allow GSSAPI to use default ccache or unique)

[Christoph Anton Mitterer]

FYI: Ubuntu is apparently also consider to add this:
https://github.com/openssh-gsskex/openssh-gsskex/issues/24#issuecomment-1768955946


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#1053822: openssh-client: consider patch for allow GSSAPI to use default ccache or unique

[Christoph Anton Mitterer]

Package: openssh-client
Version: 1:9.4p1-1
Severity: wishlist


Hey there.

I've recently filed:
https://github.com/openssh-gsskex/openssh-gsskex/issues/24
(not sure whether this is actually the current upstream, if there's
any at all, of Debian's GSSAPI patch).

In short, the problem is, that the current patch doesn't work well
when one uses kerberos with multiple realms (or perhaps even multiple
principals withon one real).
More details at the link above.


I've now seen that there may even already be a solution for that.

https://github.com/openssh-gsskex/openssh-gsskex/commit/d26622b7e0f2a9752cb8acb595d0265bd03aee0d
mentions various other patches:
> [2] 
> https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-6.6p1-kuserok.patch
> [3] 
> https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-6.6p1-GSSAPIEnablek5users.patch
> [4] https://bugzilla.mindrot.org/show_bug.cgi?id=2775

[4] reads as if it would be what I'm looking for. Not sure whether
Debian would benefit from [2] and [3].

Fedora seem to have a different patch for this:
https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.7p1-gssapi-new-unique.patch


I have no idea about the security of these patches ;-)

Do you think it would be possible to merge one of them?


Thanks,
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#987753: closed by Debian FTP Masters (reply to Unit 193 ) (Bug#987753: fixed in yt-dlp 2023.09.24-1)

[Christoph Anton Mitterer]

Hey Unit 193.


Just a heads up:

I recently filed https://github.com/yt-dlp/yt-dlp/issues/8193 and it
was implemented via:
https://github.com/yt-dlp/yt-dlp/pull/8205

So in future versions you can drop the Recommends on:
  python3-xattr | python3-pyxattr | attr
probably altogether.


Thanks,
Chris.

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#748631: closed by Debian FTP Masters (reply to Jonathan Kamens ) (Bug#748631: fixed in apt-listchanges 4.0)

[Christoph Anton Mitterer]

Thanks for fixing this, Jonathan. :-)


Cheers,
Chris.

Bug#1053248: pipewire: no sound (and hanging processes) without wireplumber

[Christoph Anton Mitterer]

Hey.

On Fri, 2023-09-29 at 20:13 -0400, Jeremy Bícha wrote:
> Please install pipewire-audio instead of pipewire directly.

a) That still leaves the problem of other processes freezing?

b) Shouldn't other packages, which now depend on
   pipewire-pulse|pulseaudio, then rather depend on pipewire-audio?
   Only GNOME packages do so as of now.

c) Would it perhaps be possible to have pipewire-audio only Recommend
   libspa-0.2-bluetooth ?

   I mean bluetooth audio devices is probably not the standard means of
   output for most typical computers, yet one gets quite a number of
   additional libraries just for it.
   Plus, over time there were quite a few attacks on BT.

Cheers,
Chris.

Bug#1053248: pipewire: no sound (and hanging processes) without wireplumber

[Christoph Anton Mitterer]

Package: pipewire
Version: 0.3.80-2
Severity: normal

Hey there.

Recently, cinnamon-settings-daemon in version 5.8.1-2 started to prefer
pipewire(-pulse) over pulseaudio, so I thought cinnamon would be ready
for it and gave it a try.

That is, I've installed pipewire (and pipewire-pulse) but no recommended
packages, especially not wireplumber.

I further purged pulseaudio, but not pulseaudio-utils which pipewire-pulse
Suggests, and of course non of the dependencies from other packages,
like libpulse-mainloop-glib0, libpulse0 and libpulsedsp.

Restarted to get all potentially remaining processes removed.


After that no soundcards were found (just a Dummy device entry).

Worse, processes started to use sound (e.g. firefox, but also the "test
sound" thingy from Cinnamon's Audio Mixer), they seemed to freeze.
Firefox seems to have come back to live for short times (where I saw tabs
were continuing to load), but I couldn't do anything with it (no reaction).


Turned out that wireplumber was needed, with that I got my output device
back and sound works nicely.


Not sure whether any of the pipewire packages should depend on wireplumber...
or which part here requires it exactly... but people may run into trouble
without it.

And at least the part of freezing other processes seems like something that
shouldn't happen at all.


HTH,
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.5.0-1-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 pipewire depends on:
ii  adduser  3.137
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.80-2
ii  pipewire-bin 0.3.80-2

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1053247: firefox: suggest pipewire-pulse as alternative

[Christoph Anton Mitterer]

Package: firefox
Version: 118.0-1
Severity: wishlist


Hey.

Numerous packages have started to suggest:
pipewire-pulse | pulseaudio
(or vice versa).


It seems firefox also works with pipewire-pulse, so maybe firefox should adopt
the same alternative?

Thanks,
Chris.

Bug#1013356: fzf: Bash completions not active by default

[Christoph Anton Mitterer]

Hey folks.

I filed an issue upstream at:
https://github.com/junegunn/fzf/issues/3457

which describes the situation leading to this bug and discusses
possible solutions.

The main problem is IMO, that right now, fzf's completion.bash file
contains both, code for:
a. completing options for fzf itself (e.g. fzf --height)
b. completing other stuff (e.g. hostnames in ssh **, etc.)


While the code from (a) doen't strictly depend on bash-completion (but
only the completion functionality of bash), I'd still say there is some
benefit for that to go into:
  /usr/share/bash-completion/completions/fzf
namely, the on-demand loading, that means that the completion functions
for fzf *itself* are only loaded if necessary.


Howver, (b) MUST NOT go into /usr/share/bash-completion/completions/fzf
for at least two reasons:
- It doesn't work (as reported in this Debian bug), because the
  functions are there only loaded by bash-completion, if fzf *itself*
  is completed.
- There is not easy/good way for (non-root) users to disable the
  (b)-part, from there.
  This (being able to disable it) is however likely necessary, if a
  user wants to 1) simply not use the functionality at all or 2) use
  an alternative implementation for it, like e.g.:
  https://github.com/lincheney/fzf-tab-completion
  or
  https://github.com/rockandska/fzf-obc



How to move forward?

First we should wait what upstream thinks about
https://github.com/junegunn/fzf/issues/3457 .
There I propose the current completion.bash file to be split up in the
two functionalities described above, (a) and (b).

If upstream would agree, we should ship the file for the (a) part as:
/usr/share/bash-completion/completions/fzf
in order to utilise bash-completions on-demand loading

For the (b) part I'd say we should do the following:
- ship the file itself as some /usr/share/fzf
then either:
- leave it at the users to source that file in their .bashrc or so
or:
- somehow source it out-of-the-box in either /etc/profile.d/[0] or
  /etc/bash_completion.d/
  Either as symlink, or via some wrapper script.
  The latter could provide some easy way for the user to disable
  loading of the script (on a per-user basis)


If upstream would *not* want to split up the file, I'd say we do the
same than above, except that we cannot ship *anything* in
/usr/share/bash-completion/completions/ .
Thus, even the completion for fzf *itself* would need to be loaded via
the ways described above for the (b) part.

Of course Debian could on its own split up the file... but I guess that
would add quite some ugly maintenance burden no one wants.


Thanks,
Chris.


[0] Would require an additional test, whether the shell is really bash.

Bug#1013356: fzf: Bash completions not active by default

[Christoph Anton Mitterer]

Just for the records:

The workaround I've proposed before (using something like
/etc/bash_completion.d/fzf) may not be the best way either.

I'm looking into what should be done (see also discussion
at https://github.com/scop/bash-completion/issues/1055), but perhaps
the ideal solution would first require some fzf upstream changes.


Cheers,
Chris.

Bug#1013356: fzf: Bash completions not active by default

[Christoph Anton Mitterer]

Hey.

A workaround would be what the git package does with:
  /etc/bash_completion.d/git-prompt
which sources:
  /usr/lib/git-core/git-sh-prompt
which in turn provides:
  __git_ps1()
and some others that are thereby unconditionally loaded by every bash
instance.

I've asked upstream whether there are means to have files in /usr/
sourced unconditionally, perhaps that would be a better approach - at
least if there'd be also a way to mask that again:
  https://github.com/scop/bash-completion/issues/1055


Cheers,
Chris.

Bug#1052198: libvte-2.91-0: swallowed characters on libreadline editing

[Christoph Anton Mitterer]

On Thu, 2023-09-21 at 23:31 +0200, Egmont Koblinger wrote:
> VTE's emulation behavior didn't change recently. Bash/Readline could
> have changed, I don't know (might be interesting to check their
> Ubuntu
> packages' changelogs).

What I did notice that libvte and gnome-terminal packages were both
updated recently, and I think I gnome-terminal packages were only
updated a few days after.
But that still doesn't explain, why it suddenly happened with the old
libvte packages.


> Or you're executing somewhat different steps.
> 
> If the printed prompt is exactly the same (including all the bells
> and
> whistles that it prints, like the username, hostname, working
> directory, previous command's exit value, background job stuff), and
> the terminal width is exactly the same (is it?), and you're pressing
> the same keys to invoke the same previous commands or editing the
> current command in the exact same way, then you should see the exact
> same behavior. Any difference in any of these could make the bug
> appear or vanish.

At least I wouldn't be aware of doing anything differently.


> Also make sure that the previous command's output ended with a
> newline, that is, the prompt begins in the first column. Otherwise
> it's common to see misbehavior while editing.

That's clear, and that was definitely not the case.


> By now we are sure that we're talking about two separate issues. The
> line editing misbehavior is surely independent from Samuel's patch.

I guess so, too.



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#1052198: libvte-2.91-0: swallowed characters on libreadline editing

[Christoph Anton Mitterer]

Hey there.

It's a bit weird, I can *no* longer reproduce it.

I have now (and everything else except libheif* at the current versions
of unstable):
libvte-2.91-0:amd64 0.74.0-2
gnome-terminal 3.50.0-1

If I use my original PS1 and the command I've mentioned before, go back
with the Up key and then remove the "2"... everything seems fine.


@Samuel, could you please also try whether you can still reproduce it?
If not, I'd say we might close the issue.



@Egmont, sorry, I hadn't seen you reply to the bug (Deb BTS is...
well...).

I now tried with xterm (where the issue doesn't appear, but as I've
said, I cannot even reproduce it with gnome-terminal anymore.

> In fact, I _think_ the culprit is that inside command substitution
> stuff, a.k.a.. $(...), nonprintable characters need to be enclosed
> within the raw bytes 0x01 and 0x02, rather than the two-character
> sequences \[ and \]. Not entirely sure, though.

That's interesting... why do you think so? The command substitution
should also be bash, and I'd have thus expected \[ and \] inside it
have therefore the same representation as outside and should thus be
identical?


Cheers,
Chris.