from:"christoph"

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

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

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

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

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

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#1069692: nfs-ganesha: FTBFS on arm{el,hf}: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

2024-04-23 Thread Christoph Martin


Hi Sebastian,

this is interesting. If you take a look into the commandline you see

-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64

there is -D_FILE_OFFSET_BITS=64 even twice. ..

But the GPFS code has:


/* _FILE_OFFSET_BITS macro causes F_GETLK/SETLK/SETLKW to be defined to
 * F_GETLK64/SETLK64/SETLKW64. Currently GPFS kernel module doesn't work
 * with these 64 bit macro values through ganesha interface. Undefine it
 * here to use plain F_GETLK/SETLK/SETLKW values.
 */
#undef _FILE_OFFSET_BITS


I'll exclude the GPFS module for armel and armhf.

Regards
Christoph



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069705: lilypond man-page has defective link on Debian

2024-04-23 Thread Christoph Brinkhaus

Source: lilypond
Version: 2.24.1-2
Severity: minor
X-Debbugs-Cc: bug-lilyp...@gnu.org

Dear Maintainer,

on https://manpages.debian.org/testing/lilypond/abc2ly.1.en.html is a
reference to the abc standard applicable for this software. The related
sentence is 

"abc2ly converts ABC music files (see
http://abcnotation.com/abc2mtex/abc.txt) to LilyPond input."

The correct link is "http://abcnotation.com/abc2mtex/abc.txt; which
leads the reader to a wiki page and a text file.

On Debian the link is "http://abcnotation.com/abc2mtex/abc.txt)". I felt
free to check the Arch man-page where the link is correct. Therefore I
guess that this little issue is related to Debian and not to LilyPond.
On Debian the link is incorrect for different languages and not just
English.

Using a browser it is almost no effort to remove the trailing ")" but a
correct link sould be better. Please fix the issue in one of the next
updates.

Thank you very much for taking care of the project,
Christoph Brinkhaus

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

2024-04-22 Thread 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

2024-04-20 Thread 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

2024-04-19 Thread 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

2024-04-18 Thread 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

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

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

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

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#1069198: RFS: chr/0.1.78-1 [RC] -- terminal-based text editor

2024-04-17 Thread Christoph Hueffelmann


Package: sponsorship-requests
Severity: important
X-Debbugs-CC:textsh...@uchuujin.de

Dear mentors,

I am looking for a sponsor for my package "chr":

 * Package name : chr
   Version  : 0.1.78-1
   Upstream contact : Christoph Hueffelmann
 * URL  :https://github.com/istoph/editor
 * License  : BSL-1.0, Expat
 * Vcs  :https://salsa.debian.org/chr/chr
   Section  : editors

The source builds the following binary packages:

  chr - terminal-based text editor
  chr-tiny - terminal-based text editor - without syntax highlighting

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/chr/

Alternatively, you can download the package with 'dget' using this command:

  dget -xhttps://mentors.debian.net/debian/pool/main/c/chr/chr_0.1.78-1.dsc

Changes since the last upload:

 chr (0.1.78-1) unstable; urgency=medium
 .
   * New upstream version 0.1.78
   * remove: Hardcode build-depends on library pkg libqt5concurrent5, blocks
 time_64 transition
 (Closes: #1069055)

Regards,
--
  Christoph Hueffelmann

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

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)

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

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#1069176: debhelper: Issues in Debhelper documentation strings

2024-04-17 Thread Christoph Brinkhaus

Package: debhelper
Version: 13.15.3
Severity: minor

Dear Maintainer,
while updating the strings in the debhelper documentation the l10
documentation team noticed a few issues in the text which I report
in the attached text file. Some issues are related to the presentation
of text in the final documents. Others are simple typos. A few
sentences are unclear.

Just for reference: The update of the german translation has been
reported in a separate report as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069112. The remarks
listed below appear in the po template as FIXME, too.

In case the documentation is updated I will be happy to update the
translation accordingly.

Thank you very much for maintaining this huge project,
Christoph Brinkhaus
1. Issue: s/source/B/
Explanation: The fix should correct the appearance to be bold.
Occurance: debhelper.pod:517
Current string:
"Note that debhelper does not provide debhelper-compat for experimental or "
"beta compatibility levels; packages experimenting with those compatibility "
"levels should put the compat level in the B field of the source "
"stanza of the F file (or, if only for selected commands, the "
"B environment variable)."

2. Issue: s/source/B/
Explanation: The fix should correct the appearance to be bold.
Occurance: debhelper-compat-upgrade-checklist.pod:271
Current string:
"The F file is no longer accepted as a source for specifying "
"the debhelper compat level. Put the compat level in the B field "
"of the source stanza of F."

3. Issue: s/autoconf/B/
Explanation: The fix should correct the appearance to be bold.
Occurance: debhelper-compat-upgrade-checklist.pod:827
Current string:
"Multiarch support. In particular, B passes multiarch "
"directories to autoconf in --libdir and --libexecdir."

4. Issue: s/autoconf/B/
Explanation: The fix should correct the appearance to be bold.
Occurance: debhelper-compat-upgrade-checklist.pod:844
Current string:
"B does not include the source package name in --"
"libexecdir when using autoconf."

5. Issue: s/that has/that have/
Explanation: The fix should correct singular/plural
Occurance: debhelper-compat-upgrade-checklist.pod:107
Current string:
"I<< This item only applies to source packages that has exactly one "
"B stanza in F. >>"

6. Issue: s/This change changes/This change/
Explanation: There should be one word as "change" only.
Occurance: debhelper-compat-upgrade-checklist.pod:198
Current string:
"Note: This change changes will cause false-positives from an unfixed "
"B. Please check L<https://bugs.debian.org/1067653> for B "
"support for this change."

7. Issue: would no longer installs → no longer installs
Explanation: Make the description more precise.
Occurance: debhelper-compat-upgrade-checklist.pod:504
Current string:
"The B tool would no longer installs the maintainer provided "
"F file as it was deemed unnecessary. However, the B from dpkg/1.20 made the file relevant again and B "
"now installs it again in compat levels 12+."

8. Issue s/can emulate it/can get an emulation of it/ (or emulate it)
Explanation: I am not 100% sure, but it should make the description more
precise.
Occurance: debhelper-compat-upgrade-checklist.pod:637
Current string:
"The B and B build systems no longer pass B<-I.> "
"to perl. Packages that still need this behaviour can emulate it by using "
"the B environment variable. E.g. by adding B "
"in their debian/rules file (or similar)."

9. Issue: First sentence does not make sense to me.
Explanation: If possible please re-phrase to make it clear.
Occurance: dh_strip:78
Current string:
"Debug symbols will be retained, but split into an independent file in F in the package build directory. B<--dbg-package> is easier to "
"use than this option, but this option is more flexible."

Bug#1069175: Mention "megacli" in Description

2024-04-17 Thread Christoph Berg

Package: megactl
Version: 0.4.4-1
Severity: wishlist

Hi,

when looking for megacli replacements in Debian, this package doesn't
show up. I think the description could mention it.

Description-en: LSI Megaraid Control and Monitoring Tools
 Reports diagnostics on megaraid and megaraid_sas adapters and
 attached disks. The adapters are also known as Dell PERC2, PERC3,
 PERC4 and PERC5.  Permits dumping of controller log pages for
 inspection of error, temperature, and self-test conditions, initiates
 self-test diagnostics, and documents adapter and logical drive
 configuration. Target devices may be adapters, (e.g. a0), enclosures
 (e.g. a0e0), or individual disks (e.g. a0e0s0). If no target is
 specified, reports configuration and drive state on all adapters.

Perhaps like this?

 Reports diagnostics on megaraid and megaraid_sas adapters and
 attached disks, similar to the original "megacli" tool. ...

Christoph

Bug#1067831: libaio: the t64 package slipped through and is in testing

2024-04-15 Thread Christoph Berg

Re: Raphael Hertzog
> There are (proprietary) software out there that link against it and we
> happen to ship some in Kali's non-free (oracle-instantclient-*).
> 
> https://pkg.kali.org/pkg/oracle-instantclient-basic
> https://pkg.kali.org/pkg/oracle-instantclient-devel
> 
> It would be nice if we could continue to keep compabitility with binaries
> compiled against upstream's SONAME.

Fwiw I've now stumbled over this for the same reason - the
Oracle-interfacing packages on apt.postgresql.org are now
uninstallable on Ubuntu 24.04 noble which has already picked up this
rename.

I tried to paper over the problem by making them depend on
"libaio1 | libaio1t64" but since the .so file was also renamed, this
doesn't work.

The installation instructions for Oracle on Linux have been "install
libaio1 and then run this giant installer" for the past few decades,
so this rename is going to confuse quite a few people if not reverted.

Christoph

Bug#1069037: less: new upstream version

2024-04-15 Thread 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

2024-04-15 Thread 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

2024-04-12 Thread 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

2024-04-11 Thread 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

2024-04-11 Thread 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

2024-04-11 Thread 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#1002458: "version in VCS newer than in repository" might be a bit overzealous

2024-04-11 Thread Christoph Berg

Control: reassign -1 qa.debian.org
Control: retitle -1 vcswatch: ignore changelog-only commits

Re: Holger Levsen
> > For starters, an early release could classify changelog-only commits as
> > "housekeeping".
> 
> *that*!
> 
> additionally you could also only classify d/changelog changing commits
> with "Gbp-Dch: ignore" in them as such, but I'd guess Marc's suggestion
> really is good enough.

I don't understand, if debian/changelog-only commits are already
ignored, what should vcswatch do additionally?

> Please reconsider, IOW, Myon: my I reassign this back to qa.debian.org
> for vcswatch?

Done.

Christoph

Bug#1068730: Fails to build from source since removal of liblz4-tool

2024-04-09 Thread Christoph Biedl

Source: systemd
Severity: serious
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

systemd build-depends on liblz4-tool but that package is no longer build
from src:lz4 (since 1.9.4-2, uploaded about a week ago). Just replacing
the dependency with lz4 seems to fix this problem (build passes, didn't
check further).

Cheers,

Christoph

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

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



signature.asc
Description: PGP signature

Bug#1068722: aapt: symbol lookup error: libandroidfw.so.0: undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi

2024-04-09 Thread Hans-Christoph Steiner




Package: aapt
Version: 1:10.0.0+r36-10
Severity: important

Dear Maintainer,

When adb/fastboot is installed from bookworm-backports, those pull in 
android-libziparchive 1:33.0.3-2~bpo12+1, which does not have the symbols that 
bookworm's aapt needs to run:


$ aapt
aapt: symbol lookup error: /usr/lib/x86_64-linux-gnu/android/libandroidfw.so.0: 
undefined symbol: _Z18ExtractEntryToFileP10ZipArchiveP8ZipEntryi/


I guess the solution would be to also backport android-platform-frameworks-base?

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (1, 'experimental'), (1, 'unstable')

Architecture: amd64 (x86_64)

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

Versions of packages aapt depends on:
ii  android-libaapt1:10.0.0+r36-10
ii  android-libandroidfw   1:10.0.0+r36-10
ii  android-libbase1:33.0.3-2~bpo12+1
ii  android-liblog 1:33.0.3-2~bpo12+1
ii  android-libutils   1:33.0.3-2~bpo12+1
ii  android-libziparchive  1:33.0.3-2~bpo12+1
ii  libc6  2.36-9+deb12u4
ii  libexpat1  2.5.0-1
ii  libgcc-s1  13.1.0-9
ii  libpng16-161.6.39-2
ii  libprotobuf-lite32 3.21.12-3
ii  libstdc++6 13.1.0-9

aapt recommends no packages.

aapt suggests no packages.

-- no debconf information

Bug#1068674: Document pam_umask change in release notes

2024-04-09 Thread 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

2024-04-09 Thread 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

2024-04-09 Thread 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#1068569: RM: nfs-ganesha-ceph [armel armhf i386] -- NBS; ceph dropped 32 bit support

2024-04-08 Thread Christoph Martin


Hi Adam,

Am 08.04.24 um 19:15 schrieb Adam D. Barratt:

On Mon, 2024-04-08 at 11:42 +0200, Christoph Martin wrote:

Hi Sebastian,

the packages are already removed from testing and unstable.
Where do you see a problem?


I'm not Sebastian, but the archive disagrees with you about the
packages having been removed from unstable.

adsb@coccia:~$ dak ls -s unstable -a armel,armhf,i386 nfs-ganesha-ceph 
nfs-ganesha-rados-grace nfs-ganesha-rgw
nfs-ganesha-ceph| 4.3-5 | unstable   | armel, armhf, i386
nfs-ganesha-rados-grace | 4.3-5 | unstable   | armel, armhf, i386
nfs-ganesha-rgw | 4.3-5 | unstable   | armel, armhf, i386


Thanks for your reply. I only took a look at the current version in 
unstable and testing. And this is 4.3-8 with binaries for amd64 arm64 
mips64el ppc64el riscv64 s390x.


So the issue is, that the leftover binaries from version 4.3-5 are still 
in the archive.


Regards
Christoph


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068640: clevis-initramfs: clevis early boot DNS fail, no resolv.conf created by ipconfig

2024-04-08 Thread Christoph Biedl

anon2529 wrote...

> The early boot fails to unlock a volume automatically. We get a
> prompt to unlock a volume (it's a swap volume) but clevis is
> unable to unlock it automatically because it cannot resolve
> the Tang server's hostname.

That ought to be fixed in clevis 20 (not uploaded yet, will do in the
next days). If you have the skills and the time, you could try to
backport

https://github.com/latchset/clevis/commit/bebb037d664185769c12cd061c2221c2d2bdb432

    Christoph


signature.asc
Description: PGP signature

Bug#1068569: RM: nfs-ganesha-ceph [armel armhf i386] -- NBS; ceph dropped 32 bit support

2024-04-08 Thread Christoph Martin


Hi Sebastian,

the packages are already removed from testing and unstable.
Where do you see a problem?

Regards
Christoph

Am 07.04.24 um 13:21 schrieb Sebastian Ramacher:

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: nfs-gane...@packages.debian.org, sramac...@debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:nfs-ganesha
Control: block 1065470 by -1
Control: clone -1 -2
Control: clone -1 -3
Control: retitle -2 RM: nfs-ganesha-grace [armel armhf i386] -- NBS; ceph 
dropped 32 bit support
Control: retitle -3 RM: nfs-ganesha-rgw [armel armhf i386] -- NBS; ceph dropped 
32 bit support

  nfs-ganesha (4.3-6) unstable; urgency=medium
  .
* only configure with ceph for some 64bit archs

So please remove the old nfs-ganesha-ceoph, nfs-ganesha-rados-grace, and
nfs-genesha-rgw binaries from armel, armhf and i386.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068373: RM: libzia/experimental -- ROM; Merged into tucnak

2024-04-04 Thread Christoph Berg

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:libzia
User: ftp.debian@packages.debian.org
Usertags: remove

Hi,

I had somehow assumed that #1064844 would result in the removal of
libzia from both unstable and experimental, but of course it only got
removed from unstable. So, here I am again:

Please remove libzia from experimental.

The library is now part of the tucnak source since it doesn't get
released (and used) independently.

Thanks,
Christoph

Bug#1064708: pygame: FTBFS: AssertionError: "No video mode" does not match "Parameter 'surface' is invalid"

2024-04-02 Thread Christoph Berg

Control: severity -1 serious

Re: Peter Michael Green
> > severity 1064708 important
> Can you explain why you downgraded this bug? it looks rc to me
> and is blocking the time_t transition.

I think I mistakenly downgraded it along with some other "t64 nmu diff" bugs.

Christoph

Bug#1067237: ngircd: missing ssl security patch in debian's ngircd package

2024-03-31 Thread Christoph Biedl

Control: tags 1067237 pending

jose wrote...

> The master branch of the upstream ngircd changelog informs about an 
> SSL security related patch [1] that is missing in the -26-1 ngircd debian
> package patches.

Thanks, this is on radar and I'm in contact with upstream on how to deal
with this.

Christoph


signature.asc
Description: PGP signature

Bug#1068139: miniflux: [L10N,DE] miniflux_2.1.1-1: german translation

2024-03-31 Thread Christoph Brinkhaus

Package: miniflux
Version: miniflux 2.1.2-1
Severity: wishlist
X-Debbugs-Cc: maytha8the...@gmail.com

Dear Maintainer,

please find attached the german translation of the miniflux_2.1.1-1 template.
Thank you for taking care of the package!

Kind regards,
Christoph Brinkhaus
# German translation of manpages
# This file is distributed under the same license as the miniflux package.
# Copyright © of this file:
# Christoph Brinkhaus , 2024.
#
msgid ""
msgstr ""
"Project-Id-Version: miniflux\n"
"Report-Msgid-Bugs-To: minif...@packages.debian.org\n"
"POT-Creation-Date: 2024-03-23 15:28+0800\n"
"PO-Revision-Date: 2024-03-29 16:30+0200\n"
"Last-Translator: Christoph Brinkhaus \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Would you like to create an admin account?"
msgstr "Möchten Sie ein Administratorkonto einrichten?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"By default, miniflux comes with no user accounts. You can choose to create "
"an administrator account for miniflux here, or do it manually afterwards "
"(see /usr/share/doc/miniflux/README.Debian)."
msgstr ""
"In der Voreinstellung hat miniflux keine Benutzerkonten. Sie können jetzt "
"ein Administratorkonto einrichten, oder Sie machen das später manuell "
"(siehe /usr/share/doc/miniflux/README.Debian)."

#. Type: string
#. Description
#: ../templates:2001
msgid "Username:"
msgstr "Benutzername:"

#. Type: string
#. Description
#: ../templates:2001
msgid "Username for the new admin account on miniflux."
msgstr "Benutzername für das neue Administratorkonto von miniflux."

#. Type: password
#. Description
#: ../templates:3001
msgid "Password:"
msgstr "Passwort:"

#. Type: password
#. Description
#: ../templates:3001
msgid "Password for the new admin account on miniflux."
msgstr "Passwort für das neue Administratorkonto von miniflux."

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

2024-03-30 Thread 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

2024-03-30 Thread 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#1067838: Please provide a trivial working example

2024-03-27 Thread Christoph Biedl

Package: libresolv-wrapper
Version: 1.1.8-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de

Greetings,

while looking for a way to overload hostname resolution as non-root
(part of a test suite and/or autopkgtest), I came across your package.
However, *nothing* works, not even in the stable releases.

Assuming this is rather a "you're holding it wrong" than a grave bug in
libresolv-wrapper, I guess usage is not as easy as it seems. So can
you please provide an as-simple-as-possible example, in the tradition
of "Hello, world"?

It could be like

echo "A server1.example.com 192.0.2.1" >/tmp/hosts
LD_PRELOAD=libresolv_wrapper.so \
RESOLV_WRAPPER_HOSTS=/tmp/hosts \
$MAGIC

where the output signalizes the hostname server1.example.com was indeed
resolved into the given IP address.

These are the things I've tried without success:

* getent hosts server1.example.com
* host server1.example.com
* wget -O /dev/null http://server1.example.com/
* the actual application, using a gnutls linkage

According to strace, libresolv_wrapper.so is loaded but there is no
access to the mocked hosts file.

According to ltrace, none of the RESOLV_WRAPPER_* variables are checked
via getenv.

Not a big surpise then: Setting RESOLV_WRAPPER_DEBUGLEVEL had no effect
either.

Using <https://github.com/figiel/hosts>, the above checks work except
for the second one. However, this project is not in Debian.

Christoph

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

Kernel: Linux 6.6.22 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 libresolv-wrapper depends on:
ii  libc6  2.37-15.1

libresolv-wrapper recommends no packages.

libresolv-wrapper suggests no packages.

-- no debconf information



signature.asc
Description: PGP signature

Bug#1067457: jose: CVE-2023-50967

2024-03-21 Thread Christoph Biedl

Control: forwarded 1067457 https://github.com/latchset/jose/issues/151


signature.asc
Description: PGP signature

Bug#1066067: cl-plus-ssl: hardcoded libssl3 dependency

Re: Sebastian Ramacher
> Source: cl-plus-ssl
> Version: 20220328.git8b91648-4
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
> 
> cl-plus-ssl hardcodeds a dependency on libssl3. Due to the time_t
> transition, the package name changed and the dependency needs to be
> updated.

It actually doesn't hard-code the dependency but correctly extracts it
from libssl-dev. But since we don't have arch:all binnmus, a new
upload was needed anyway. Just did that.

Once cl-plus-ssl is installed, please binnmu pgloader to have it pick
up the changed dependency.

Christoph

Bug#980150: RFA: cyrus-imspd -- Internet Message Support Protocol daemon

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: cyrus-imspd -- RoM; FTBFS and probably full of CVEs

> I request an adopter for the cyrus-imspd package as I am not using it
> myself.
> 
> The package description is:
>  This package contains the cyrus-imspd daemon for the Internet Message Support
>  Protocol (imsp), providing central storage for addressbooks and application
>  config.

This didn't have any takers in 3 years, and the package is now
FTBFSing (#1066480) with C code so ancient it's a PITA to fix, so
let's get it removed.

Christoph

Bug#1067144: [3dprinter-general] Bug#1067144: uranium: missing depend on python3-all for autopkgtest

Re: Gregor Riepl
> I pushed a simple patch to add the dependency, would be nice if you could
> release it, @myon? Thanks in advance.

On its way, thanks for the update!

Christoph

Bug#1064697: flask-babelex: FTBFS: ImportError: cannot import name '_request_ctx_stack' from 'flask' (/usr/lib/python3/dist-packages/flask/init.py)