Bug#1064797: Mediawiki ships with .htaccess files containing outdated access control configuration

[Alain Knaff]

Package: mediawiki
Version: 1:1.39.5-1~deb12u1

Hi,

Mediawiki ships with .htaccess files which contain outdated access
control directives.

for instance, /usr/share/mediawiki/vendor/.htaccess contains:

  Deny from all

rather than the more current

  Require all denied


The new syntax was introduced in Apache 2.4, shipping since at least
Jessie, April 2015.

Wouldn't it be time to go with the new syntax, as less and less people
now continue to use the access_compat module?

Thanks,

Alain

Bug#1059323: mount.cifs fails to mount a share which smbclient can access all right

[Alain Knaff]

t 6 characters and nothing
special), could this be a factor?

Thanks,

-- 
Alain Knaff
Service Informatique

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat
et de la Biodiversité
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1058067: Mimedefang's relay_is_blacklisted_multi removes the wrong filedescriptor from its IO::Select set resulting in SERVFAIL

[Alain Knaff]

Package: mimedefang
Version: 3.3-1

Hi,

relay_is_blacklisted_multi sends out its multiple DNS requests at once,
and then uses IO::Select to wait for the various answers as they come in.

It has a loop in which it intends to remove each socket from the
IO::Select set as soon as it is done with it (i.e. received and
processed the answer).

However, it accidentally removes the wrong socket: $sock instead of $rsock.

$sock is a now useless variable from a previous loop (should have been
"my" to that loop), which just happens to be the highest socket of the set.

The result of this issue is that that last socket is dropped from the
set, even if it hasn't received an answer, meaning that if this socket
isn't the first one to receive an answer, its answer will never be
processed, resulting in a SERVFAIL on that query.

Here is a patch:

--- ./usr/share/perl5/Mail/MIMEDefang/Net.pm2023-01-30
18:00:55.0 +0100
+++ /usr/share/perl5/Mail/MIMEDefang/Net.pm 2023-11-20
11:54:23.448414007 +0100
@@ -386,7 +386,7 @@
 @ready = $sel->can_read($expire);
 foreach my $rsock (@ready) {
   my $pack = $res->bgread($rsock);
-  $sel->remove($sock);
+  $sel->remove($rsock);
   my $sdomain = $sock_to_domain{$rsock};
   undef($rsock);
   my($rr, $rcode);


Btw, this issue no longer exists in the most recent upstream version

Thanks,

Alain

Bug#1055450: Plocate's database easily becomes corrupted, resulting in locate finding nothing

[Alain Knaff]

Den 06/11/2023 19:07 huet de(n) Steinar H. Gunderson geschriwwen:

On Mon, Nov 06, 2023 at 06:43:33PM +0100, Alain Knaff wrote:

Nov 06 18:33:15 hitchhiker updatedb.plocate[98659]:  => adding `/home' 
(duplicate of mount point 
`/run/schroot/mount/buster-53c7e4fc-0416-4408-8421-959dc1fdaa1d/home')


So your /home is mounted in two places, and updatedb picks one of them.
There's no way of knowing which one you want, I guess?

/* Steinar */



But then, shouldn't it keep the shorter path (if both are the root of 
their filesystem)?


And even if it used the longer path, shouldn't it find files which I 
locate under that longer path?


And during investigation, I added /run/schroot to PRUNEPATHS so updatedb 
shouldn't have "seen" the longer path at all. The failure to locate 
files in my home directory happened both before and after this addition.


Thanks,

Alain

Bug#1055450: Plocate's database easily becomes corrupted, resulting in locate finding nothing

[Alain Knaff]

Den 06/11/2023 15:57 huet de(n) Steinar H. Gunderson geschriwwen:

On Mon, Nov 06, 2023 at 03:41:50PM +0100, Alain Knaff wrote:

On the box where plocate.db is currently corrupted, /home is a btrfs.


It it by any chance a subvolume? (If so, known btrfs bug/design issue;
see the updatedb.conf man page.)

/* Steinar */



I thinks it's the root volume on its FS (name = )

root@hitchhiker:/home/alain# btrfs subvolume show /home
/
Name:   
UUID:   bda85cb7-3079-4487-9382-773767db26e1
Parent UUID:-
Received UUID:  -
Creation time:  2022-04-23 17:44:45 +0200
Subvolume ID:   5
Generation: 1051661
Gen at creation:0
Parent ID:  0
Top level ID:   0
Flags:  -
Send transid:   0
Send time:  2022-04-23 17:44:45 +0200
Receive transid:0
Receive time:   -
Snapshot(s):

But in any case, I've now set PRUNE_BIND_MOUNTS to "no", lets see in a 
couple of days whether that helps.



Thanks,

Alain

Bug#1055450: Plocate's database easily becomes corrupted, resulting in locate finding nothing

[Alain Knaff]

Den 06/11/2023 15:31 huet de(n) Steinar H. Gunderson geschriwwen:

On Mon, Nov 06, 2023 at 03:09:48PM +0100, Alain Knaff wrote:

On 2 separate Debian 12 machines, I'm observing the following issue:

Search for a file that obviously exists returns nothing.

Running updatedb and then locate doesn't fix this.

Removing /var/lib/plocate/plocate.db, and then re-running updatedb does fix
it... until the issue reappears again several days later.


I haven't had reports that this is a common occurrence, no. There were some
issues with upgrades from mlocate, but nothing obvious.


That's what I suspected at first as well. But then I uninstalled mlocate 
complete (dpkg --purge mlocate , and removed files containing mlocating 
that were still left after the purge), but the problem kept re-occuring.



You could in theory
dump out what's in plocate.db and see what it looks like? (E.g. through
plocate '' as root.)


On one of the 2 boxes (where I didn't recently perform above-mentioned 
workaround), I see that plocate.db is not empty, but everything under 
/home seems to be missing (i.e. /home itself is present, but everything 
contained in it is missing)




What filesystem is this?


On the box where plocate.db is currently corrupted, /home is a btrfs.

On the other box, where I just applied the workaround, /home is an ext FS



Could there be something very wrong with timestamps?


What exactly would that be, and how to check for it?



/* Steinar */



Thanks for your quick answer,

Alain

Bug#1055450: Plocate's database easily becomes corrupted, resulting in locate finding nothing

[Alain Knaff]

Package: plocate
Version: 1.1.18-1

Hi,

On 2 separate Debian 12 machines, I'm observing the following issue:

Search for a file that obviously exists returns nothing.

Running updatedb and then locate doesn't fix this.

Removing /var/lib/plocate/plocate.db, and then re-running updatedb does 
fix it... until the issue reappears again several days later.


Any ideas?

Thanks,

Alain

Bug#1040996: Davical defines a Content-Security-Policy without scoping it to its own resources

[Alain Knaff]

Package: davical
Version: 1.1.12-2

Hi,

At the end of its example / reference configuration file 
/etc/apache2/sites-available/davical.conf,
davical defines a Content-Security-Policy, but forgets to bracket it with 
 instructions
to scope it to its own resources.

Should be:



  Header set Content-Security-Policy "default-src 'none'; img-src 'self' data:; 
media-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' data:; 
font-src 'self' data:; object-src 'self'; base-uri 'self'; connect-src 'self'; 
form-action 'self' sis.redsys.es; frame-ancestors 'self'"



... or even better, move it up to the existing  scope on
top of the file, along with all the other items.

Without such scoping, the Content-Security-Policy applies to *all* resources on 
the server,
including those of other, unrelated web applications. In our case, this broke 
nextcloud by
interfering with nextcloud's own Content-Security-Policy.

Similar issue may exist with the RewriteRules, we noticed that nextcloud failed 
to correctly locate
its .well-known resources. Davical should only rewrite those .well-known 
resources that it specifically
supplies, rather than (.*)

Thanks for fixing this,

Alain

Bug#1040525: Lighttpd disregards ssl.dh-file setting

[Alain Knaff]

Hi,

On 08/07/2023 00:51, gs-bugs.debian@gluelogic.com wrote:
> ⚠ Expéditeur externe au réseau de l'Etat. Voir les consignes de sécurité sur 
> ctie.etat.lu.
> 
>   
> 
> On Fri, Jul 07, 2023 at 09:28:24AM +, Alain Knaff wrote:
>> Package: lighttpd
>> Version: 1.4.69-1
>>
>> Since our upgrade to Debian 12, lighttpd now uses insecure
>> Diffie-Hellman parameters
>> c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63
>> b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5
>> 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f
>> a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39
>> a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6
>> 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b
>> 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2
>> 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8
>> 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94
>> e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18
>> 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce
>> 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186
>> af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb
>> ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2
>> d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0
>> 8f4df435c934063199
> 
> What are you sharing?  What command did you use to obtain this info?

Thanks for your reply.

The full Diffie-Hellman parameter was listed in our monthly "Nexpose" 
Report. Then I confirmed using openssl  s_client -connect 
mcp.aev.etat.lu:443 -tls1_2 -cipher DHE-RSA-AES256-GCM-SHA384 -msg | 
grep -A2 "  0c 00" that this was indeed the parameters used.

(responds with a handshake failure now, as I disabled the 2 ciphers that 
use Diffie-Hellman)


> 
> Please clarify why you think this is insecure.

I trust Nexpose on this one. The theory goes that any "standard" 
parameter is insecure, as a would be attacker would only need to "crack" 
it once, and then be able to use it against a huge number of sites.

> 
> This does not look like lighttpd mod_openssl default DH parameters
> used since lighttpd 1.4.56.

Not sure where this is coming from, but for sure not from our local 
configuration (which is basically being ignored...)

> 
> Since lighttpd 1.4.56, lighttpd mod_openssl configures default
> DH parameters to use RFC 7919 FFDHE2048 2048-bit group
> https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83
> RFC 7919:
> https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1
> 
> Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may
> change lighttpd mod_openssl to use FFDHE3072 by default in the future.
> 
> Please note: if using GnuTLS (with lighttpd mod_gnutls) or using
> mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is
> chosen to be secure according to RFC7919 DH parameter negotiation,
> and there is no default set by lighttpd.
> 
>> And this despite having pointed ssl.dh-file to a self generated dh param
>> file, as described in https://weakdh.org/sysadmin.html
> 
> That page is out-dated, at least for lighttpd.
> 
> Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in
> https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list
> now used by default since lighttpd 1.4.68.
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68

We did use a "locally" constructed cipher list, to which we kept 
blacklisting ciphers as soon as Nexpose considered them insecure.

I now removed that cipher list (falling back to the default), and this 
disabled the 2 remaining ciphers (DHE-RSA-AES256-GCM-SHA384 and 
DHE-RSA-AES128-GCM-SHA256) that used Diffie Hellman :-)

> 
>> In Debian 11, an identical configuration was using our locally generated
>> secure dh parameters.
> 
> Since lighttpd 1.4.65 (released Jun 2022), lighttpd has been announcing
> the future scheduled removal of ssl.dh-file.
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67

It would have been good if this change, potentially endangering 
security, would have been listed in apt_listchanges.


> 
> The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023)
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68
> 
> As linked in the lighttpd release notes:
>See https://wiki.lighttpd.ne

Bug#1040525: Lighttpd disregards ssl.dh-file setting

[Alain Knaff]

Package: lighttpd
Version: 1.4.69-1

Since our upgrade to Debian 12, lighttpd now uses insecure 
Diffie-Hellman parameters 
c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63
b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5
1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f
a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39
a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6
70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b
2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2
261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8
50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94
e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18
177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce
0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186
af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb
ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2
d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0
8f4df435c934063199


And this despite having pointed ssl.dh-file to a self generated dh param 
file, as described in https://weakdh.org/sysadmin.html

In Debian 11, an identical configuration was using our locally generated 
secure dh parameters.

Thanks,

-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1040325: Network drives other than NFS are no longer automatically mounted after boot

[Alain Knaff]

Package: systemd
Version: 252.6-1

Package: initscripts
Version: 3.06-4

Hi,

We have several CIFS drives specified in our /etc/fstab

Until Debian 11 (with isc-dhcp-client), they got automatically mounted 
all right after boot.

No longer in Debian 12 (with dhcpcd-base)

Even adding _netdev to the drives' options in /etc/fstab didn't help.

Some investigation showed that /etc/network/if-up.d/mountnfs (part of 
initscripts: this is the script responsible for mounting network drives 
when new connections are brought up) sources /lib/lsb/init-functions, 
which itself sources parts in /lib/lsb/init-functions.d

/lib/lsb/init-functions.d/40-systemd (part of systemd package) checks 
whether mountnfs.service is "masked", and if so, exits before mounting 
any drives.

=> which means that networked drives other than NFS are not mounted!

Manually "unmasking" mountnfs.service fixes the issue, however I have a 
feeling that on a future Debian upgrade, mountnfs.service might get 
masked again.

Thanks for looking into this,
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1039703: With dhcpcd version 9.4.1 interfaces cannot be brought down and up again, please ship at least 9.5.0

[Alain Knaff]

Hi,

On 03/07/2023 13:13, Martin-Éric Racine wrote:
> On Thu, 29 Jun 2023 14:50:16 +0000 Alain Knaff  
> wrote:
[...]
>> What fixes it, is disabling the dhcpcd service in systemd. This works
>> even with 9.4.1: interfaces are brought up all right after boot even
>> without this service, and can be brought down and up again later!
> 
> The long description of the 'dhcpcd' package is very clear that it
> should NOT be installed if interfaces are configured using ifupdown.
> Purge 'dhcpcd' and only keep 'dhcpcd-base'.
> 
> Martin-Éric
> 

Thanks for the information. Although the description does mention 
potential problems with /etc/network/interfaces, it doesn't mention the 
solution, and this naming is confusing. Usually *-base packages are not 
packages meant to be installed alone. It would be clearer if the current 
dhcpcd package was named dhcpcd-systemd-integration (or something 
similar), and the current dhcpcd-base package was just dhcpcd.

Thanks,
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1039703: With dhcpcd version 9.4.1 interfaces cannot be brought down and up again, please ship at least 9.5.0

[Alain Knaff]

Hi,

On 28/06/2023 14:01, Alain Knaff wrote:
> Package: dhcpcd
> Version: 9.4.1-22
> 
> Hi,
> 
> With the dhcpcd shipped with Debian 12, it is no longer possible to 
> bring an interface down and up again:
> 
> ifdown eth0 ; sleep 1 ; ifup eth0
> 
[...]
> According to https://github.com/NetworkConfiguration/dhcpcd/issues/159, 
> a bug with a similar error message is fixed in dhcpcd-9.5.0
> 

Actually, further test show that dhcpcd-9.5.1, nor dhcpcd-10.0.1 don't 
fix this issue.

What fixes it, is disabling the dhcpcd service in systemd. This works 
even with 9.4.1: interfaces are brought up all right after boot even 
without this service, and can be brought down and up again later!

Regards,

-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1039704: Sendmail does not notice when /etc/resolv.conf changes

[Alain Knaff]

Package: sendmail-base
Version: 8.17.1.9-2

Hi,

As far as I understood, since Debian 12, isc-dhcp-client is considered 
obsolete, and dhcpcd is recommended instead.

However, dhcpcd appears to be slightly slower, with the result that on 
startup sendmail sees an empty /etc/resolv.conf file.

Apparently, sendmail only reads this file once at startup (and on 
reload), meaning that it won't be able to process outbound mails, as it 
can't look any domain names up.

There actually *is* a /usr/share/sendmail/dynamic script meant to reload 
sendmail when the network changes (i.e. nameservers become available), 
but unfortunately it only leaves 2 choices:
  1. DAEMON_NETMODE="Static"  => do not reload sendmail on network change

  2. DAEMON_NETMODE="Dynamic" => recompile the entire configuration, and 
reload sendmail on network change

Not only is Static the default (which means that people having newly 
upgraded to Debian 12 might miss it), but Dynamic is over the top (we 
don't need a complete recompilation of the configuration: it never 
mentions the server's anywhere)

So could we have a "Semi-Dynamic" setting instead, which would be the 
default after upgrade, and which would only do the reload, without 
preceding config recompilation?

Thanks,

Alain

-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1039703: With dhcpcd version 9.4.1 interfaces cannot be brought down and up again, please ship at least 9.5.0

[Alain Knaff]

Package: dhcpcd
Version: 9.4.1-22

Hi,

With the dhcpcd shipped with Debian 12, it is no longer possible to 
bring an interface down and up again:

ifdown eth0 ; sleep 1 ; ifup eth0

Indeed, the ifup can no longer connect to the master dhcpcd process:

2023-06-28T13:53:51.134196+02:00 build dhcpcd[572]: ps_ctl_dispatch: 
cannot handle another client
2023-06-28T13:53:56.138312+02:00 build dhcpcd[572]: control_free: No 
such file or directory


According to https://github.com/NetworkConfiguration/dhcpcd/issues/159, 
a bug with a similar error message is fixed in dhcpcd-9.5.0

Thanks,
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1039696: Confusing header message in /etc/resolvconf/resolv.conf.d/head

[Alain Knaff]

Hi,

On 28/06/2023 13:09, Andrej Shadura wrote:
> ⚠ Expéditeur externe au réseau de l'Etat. Voir les consignes de sécurité sur 
> ctie.etat.lu.
> 
>   
> 
> Hi,
> 
> On Wed, 28 Jun 2023, at 12:35, Alain Knaff wrote:
>> The current resolvconf leaves a confusing header message in
>> /etc/resolv.conf:
>>
>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
>> resolvconf(8)
>> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
>> # 127.0.0.53 is the systemd-resolved stub resolver.
>> # run "resolvectl status" to see details about the actual nameservers.
>>
>> trying to run resolvectl suggests to apt install systemd-resolved
>>
>> Actually doing so, however, removes resolvconf, and breaks
>> /etc/resolv.conf more than it already was. It looks as if
>> systemd-resolved is a different (incompatible) approach from resolvconf,
>> and installing it actually removes resolvconf.
>>
>> The message should be fixed to avoid confusing people. Ok if people
>> actually want systemd to handle DNS, but they should not be sent there
>> if they currently have chosen a different approach.
> 
> When this message was written, it was possible to install resolved and 
> resolvconf at the same time.

"Possible" but not "compulsory". It was also still possible to have just 
resolvconf on its own, and in this case a message which make extensive 
reference to features of resolved (127.0.0.53, resolvectl status) makes 
no sense in resolveconf.

> Meanwhile though, resolved started shipping /sbin/resolvconf thus preventing 
> resolvconf from being used with resolved. I voiced my opposition, but it 
> wasn’t acted upon: https://bugs.debian.org/939904
> 
> I’m not sure what’s the best thing to do now.
> 

Apart from fixing the message (i.e. somehow moving it to 
systemd-resolved package), what might make sense would be to split 
/sbin/resolvconf binary from the rest of its if-up environment (i.e. the 
/etc/network/if-up.d/000resolvconf script). That way, both packages can 
rely on this common binary without stepping on each other.

Thanks,
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1039696: Confusing header message in /etc/resolvconf/resolv.conf.d/head

[Alain Knaff]

Package: resolvconf
Version: 1.91+nmu1

Hi,

The current resolvconf leaves a confusing header message in 
/etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by 
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

trying to run resolvectl suggests to apt install systemd-resolved

Actually doing so, however, removes resolvconf, and breaks 
/etc/resolv.conf more than it already was. It looks as if 
systemd-resolved is a different (incompatible) approach from resolvconf, 
and installing it actually removes resolvconf.

The message should be fixed to avoid confusing people. Ok if people 
actually want systemd to handle DNS, but they should not be sent there 
if they currently have chosen a different approach.

Thanks,

Alain
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1038441: Horde uses obsolete each() function throughout its code.

[Alain Knaff]

Package: php-horde-imp
Version: 6.2.27-3

Hi,

Horde still uses the obsolete each() function.
https://www.php.net/manual/en/function.each.php

Example from /usr/share/horde/imp/lib/Ajax/Application/ListMessages.php,
line 438:

while (list(,$ob) = each($overview['overview'])) {
 ...
}

This function has been deprecated since 7.2, and has now been removed
completely in php-8.2 (as shipped by Debian 12).

Which means that horde is basically unusable right now.

What makes this hard to debug is that most instances of it only leave a
mysterious "Error when communication with the server" error. Some
occurrences fortunately then leave additional details in
/var/log/horde.log . Others however have *only* the "Error when
communication with the server" without any further details elsewhere.

N.B. The problem occurs right after log in, when Horde / IMP attempts to
display mailbox, so is really not hard to reproduce!

Thanks for addressing this,

Alain

Bug#1034500: Nheko crashes after a few seconds after launch, bug fixed upstream

[Alain Knaff]

Package: nheko
Version: 0.8.0+really0.7.2-4

Hi,

After a couple of seconds, and after displaying its UI correctly, nheko
crashes with the following messages:

terminate called after throwing an instance of 'std::invalid_argument'
  what():  v1.1: invalid version
Aborted


Apparently, this bug is known upstream since 2022:

https://github.com/Nheko-Reborn/nheko/issues/957

Thanks,

Alain

Bug#1033320: HTML5 "autofocus" tag for input element in dillo

[Alain Knaff]

Package: dillo
Version: 3.0.5-7

Hi,

[Sorry for not submitting this upstream, but apparently dillo.org's mail 
server is no longer accepting mails for the dillo.org domain.]

The attached patch adds support for HTML5's autofocus tag to Dillo: this 
allows to automatically focus certain input fields as soon as the page 
with the form loads. We're using this to implement a barcode scanner on 
a raspberry pi 3, so that the browser is immediately ready to scan, 
without a need to touch into the input field first.

Thanks,

-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu
diff -ur dillo-3.0.5.orig/dw/fltkplatform.cc dillo-3.0.5/dw/fltkplatform.cc
--- dillo-3.0.5.orig/dw/fltkplatform.cc	2015-06-10 23:48:53.0 +0200
+++ dillo-3.0.5/dw/fltkplatform.cc	2023-03-18 12:41:21.910464773 +0100
@@ -370,6 +370,10 @@
 {
 }
 
+void FltkView::focusFltkWidget (Fl_Widget *widget)
+{
+}
+
 void FltkView::allocateFltkWidget (Fl_Widget *widget,
core::Allocation *allocation)
 {
diff -ur dillo-3.0.5.orig/dw/fltkplatform.hh dillo-3.0.5/dw/fltkplatform.hh
--- dillo-3.0.5.orig/dw/fltkplatform.hh	2015-06-30 16:06:08.0 +0200
+++ dillo-3.0.5/dw/fltkplatform.hh	2023-03-18 12:46:12.542094720 +0100
@@ -86,6 +86,7 @@
virtual void allocateFltkWidget (Fl_Widget *widget,
 core::Allocation *allocation);
virtual void drawFltkWidget (Fl_Widget *widget, core::Rectangle *area);
+   virtual void focusFltkWidget (Fl_Widget *widget);
 };
 
 
diff -ur dillo-3.0.5.orig/dw/fltkui.cc dillo-3.0.5/dw/fltkui.cc
--- dillo-3.0.5.orig/dw/fltkui.cc	2015-06-30 16:06:08.0 +0200
+++ dillo-3.0.5/dw/fltkui.cc	2023-03-18 12:33:36.914259944 +0100
@@ -460,6 +460,11 @@
this->view = NULL;
 }
 
+void FltkResource::focus ()
+{
+view->focusFltkWidget (widget);
+}
+	
 void FltkResource::sizeAllocate (core::Allocation *allocation)
 {
this->allocation = *allocation;
@@ -574,6 +579,11 @@
FltkResource::setEnabled (enabled);
 }
 
+template  void FltkSpecificResource::focus ()
+{
+   FltkResource::focus ();
+}
+	
 // --
 
 class EnterButton : public Fl_Button {
diff -ur dillo-3.0.5.orig/dw/fltkui.hh dillo-3.0.5/dw/fltkui.hh
--- dillo-3.0.5.orig/dw/fltkui.hh	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/fltkui.hh	2023-03-18 12:38:41.898264236 +0100
@@ -217,6 +217,8 @@
 
bool isEnabled ();
void setEnabled (bool enabled);
+
+   void focus ();
 };
 
 
@@ -232,6 +234,8 @@
 
bool isEnabled ();
void setEnabled (bool enabled);
+
+   void focus ();
 };
 
 
diff -ur dillo-3.0.5.orig/dw/fltkviewbase.cc dillo-3.0.5/dw/fltkviewbase.cc
--- dillo-3.0.5.orig/dw/fltkviewbase.cc	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/fltkviewbase.cc	2023-03-18 12:18:12.234001790 +0100
@@ -711,6 +711,12 @@
add (widget);
 }
 
+void FltkWidgetView::focusFltkWidget (Fl_Widget *widget)
+{
+	focused_child=widget;
+	widget->take_focus();
+}
+
 void FltkWidgetView::removeFltkWidget (Fl_Widget *widget)
 {
remove (widget);
diff -ur dillo-3.0.5.orig/dw/fltkviewbase.hh dillo-3.0.5/dw/fltkviewbase.hh
--- dillo-3.0.5.orig/dw/fltkviewbase.hh	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/fltkviewbase.hh	2023-03-18 12:39:07.514936690 +0100
@@ -132,6 +132,7 @@
void allocateFltkWidget (Fl_Widget *widget,
 core::Allocation *allocation);
void drawFltkWidget (Fl_Widget *widget, core::Rectangle *area);
+   void focusFltkWidget (Fl_Widget *widget);
 };
 
 } // namespace fltk
diff -ur dillo-3.0.5.orig/dw/ui.cc dillo-3.0.5/dw/ui.cc
--- dillo-3.0.5.orig/dw/ui.cc	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/ui.cc	2023-03-18 12:41:55.403344022 +0100
@@ -223,6 +223,10 @@
 {
 }
 
+void Resource::focus ()
+{
+}
+	
 void Resource::emitEnter ()
 {
activateEmitter.emitEnter(this);
diff -ur dillo-3.0.5.orig/dw/ui.hh dillo-3.0.5/dw/ui.hh
--- dillo-3.0.5.orig/dw/ui.hh	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/ui.hh	2023-03-18 12:33:20.465828321 +0100
@@ -347,6 +347,8 @@
virtual bool isEnabled () = 0;
virtual void setEnabled (bool enabled) = 0;
 
+   virtual void focus () = 0;
+
inline void connectActivate (ActivateReceiver *receiver) {
   activateEmitter.connectActivate (receiver); }
inline void connectClicked (ClickedReceiver *receiver) {
diff -ur dillo-3.0.5.orig/src/form.cc dillo-3.0.5/src/form.cc
--- dillo-3.0.5.orig/src/form.cc	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/src/form.cc	2023-03-18 12:40:04.192424547 +0100
@@ -431,7 +431,7 @@
DilloHtmlInputType inp_type;
Resource *resource = NUL

Bug#1030688: Davmail's caldav port lists DELETE in http OPTIONS command, even when user is not yet authenticated

[Alain Knaff]

Package: davmail
Version: 5.5.1.3299-5

Hi,

Our automated security scanner happened accross our davmail's calendar
TCP port, and complains that it lists the DELETE method when asked for
OPTIONS, thinking that this is a security hole "The Web server contains
a flaw that may allow a remote attacker to delete arbitrary files by
using the HTTP method 'DELETE', resulting in a loss of integrity".

Well obviously, for a calendar, this is not a problem (it should be
possible to cancel events, after all), but the scanner does have a
point: normally this should only be available for users that are
*authenticated*. However, this is not the case:

$ alain@ceres:~$ openssl s_client -connect localhost:2443
OPTIONS / HTTP/1.0

HTTP/1.1 200 OK
Server: DavMail Gateway 5.5.1-trunk
DAV: 1, calendar-access, calendar-auto-schedule,
calendarserver-private-events, addressbook
Date: Mon, 06 Feb 2023 13:47:07 +
Expires: Mon, 06 Feb 2023 13:47:07 +
Cache-Control: private, max-age=0
Allow: OPTIONS, PROPFIND, HEAD, GET, REPORT, PROPPATCH, PUT, DELETE, POST
Connection: keep-alive
Content-Length: 0

IMHO, methods that imply write operations should only be listed if a
valid Authorization header has been sent by client.

Thanks,
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1029421: Websocketd strips adds extraneous newlines in other direction from client to server, and strips out newlines in the other direction

[Alain Knaff]

Package: websocketd
Version: 0.4.1-1+b5

In order to do some tests with web services, and eventually set up a
tunnel for ssh, I used websocketd with a simple script.

Here I noticed that the script's input and output are not faithfully
received from/sent to the socket.

Indeed, from client to server, extraneous newlines are added.
Conversely, on data from server to client, newlines are stripped out.

N.B., I *did* set both STDERR and STDOUT to autoflush.

Hence, this cannot be used to tunnel arbitrary data via a web server.

Thanks,

Alain

Bug#1028100: Anbox's README.Debian points to a defunct website for downloading images

[Alain Knaff]

Package: anbox
Version: 0.0~git20210106-1

Hi,

In order to use the anbox android emulator, you first need to download
an android image, and put it into /var/lib/anbox/android.img.

/usr/share/doc/anbox/README.Debian gives a source URL for these images:
https://build.anbox.io/android-images
but unfortunately the site seems to be defunct. Name is still defined,
but connection attempts time out.

Please update with an URL that is still valid today

Thanks,

Alain

Bug#1023491: ovmf-ia32 lacks non-secboot firmware images, but qemu does not (yet) support secboot

[Alain Knaff]

Package: ovmf-ia32
Version: 2020.11-2+deb11u1

Hi,

Recently I wanted to analyze behavior of a 32-bit EFI OS bootfile, and
wanted to setup a KVM with 32 bit UEFI to do this.

However, qemu/kvm apparently does not (yet) support .secboot.fd UEFI
images, but these are the only ones available in ovmf-ia32.

Qemu just hangs on "Gues has not initialized the display (yet)" when
given a secboot image (when specified with -drive if=pflash...), or
fails immediately with "could not load PC BIOS ..." when specified with
-bios (but the latter happens with any 4M firmware image)

Eventually, I got ahead by getting an old RPM from Fedora 30, which does
also contain a non-secboot firmware image. This booted just fine on my
Debian Qemu.

Please bring back non-secboot images, until qemu can support secboot (or
until they supply readily discoverable documentation how to use secboot).

N.B. Non-secboot images are available alright in the 64bit version of
ovmf, but unfortunately I needed an 32bit UEFI for my tests.

Regards,

Alain

Bug#1001684: Davmail should use log4j 2.16 rather than 1.2

[Alain Knaff]

Hi Alexandre,

On 14/12/2021 11:51, Alexandre Rossi wrote:
> tag 1001684 moreinfo
> thanks
> 
> Hi,
> 
>> According to https://github.com/jagornet/dhcp/issues/20 , log4j 1.2 is
>> vulnerable to CVE-2019-17571, so davmail should use log4j 2.15 or 2.16
>> instead.
> 
> According to the debian security tracker[1], this has been fixed in
> log4j so davmail uses a fixed version.
> https://security-tracker.debian.org/tracker/source-package/apache-log4j1.2

ok that's good news :-)

> 
> Do you have exploit code that works against davmail or any other clue
> that davmail needs fixing?

Unfortunately not.

I only stumbled upon this when examining our servers for instances
vulnerable to CVE-2021-44228. Forums seem to claim that versions log4j
versions 1 are not safe either (different vulnerabilities), but without
giving any specifics. However, log4j team itself says versions 1.x are
"end of life" and should be avoided. So, it's more a case of "better be
safe than sorry" than any concrete exploit.

Also, since a while already, Java now has its own internal logging
framework (java.util.logging.Logger), so there should be less and less
reason to use potentially unsafe third-party logging libraries (but
switching to java's internal logging might be more difficult to do in
the short run than just upgrading to a newer version).


> 
> Thanks,
> 
> Alex
> 

Regards,
-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1001684: Davmail should use log4j 2.16 rather than 1.2

[Alain Knaff]

Package: davmail
Version: 5.1.0.2891-2

Hi,

According to https://github.com/jagornet/dhcp/issues/20 , log4j 1.2 is
vulnerable to CVE-2019-17571, so davmail should use log4j 2.15 or 2.16
instead.

Thanks,

-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu

Bug#1000985: Mailman web interface shows Fedora icon on login page, which errors when clicked on

[Alain Knaff]

Package: mailman3-web
Version: 0+20200530-2

Hi,

Mailman3-web ships with a
/usr/share/mailman3-web/settings_local.py.sample file that has
django_mailman3.lib.auth.fedora included in INSTALLED_APPS

This causes appearance of a fedora logo on the mailing lists' login
page. However, clicking on that logo results in an error message mailed
to admin (see attach)

Removing django_mailman3.lib.auth.fedora from
/etc/mailman3/mailman-web.py locally fixes the issue, but obviously
packages should not ship with defaults that cause errors.

Thanks,

Alain
--- Begin Message ---
Internal Server Error: /mailman3/accounts/fedora/login/

TypeError at /accounts/fedora/login/
_openid_consumer() missing 2 required positional arguments: 'provider' and 
'endpoint'

Request Method: GET
Request URL: 
https://udpcast.linux.lu/mailman3/accounts/fedora/login/?process=login=%2Fmailman3%2Fhyperkitty%2Flist%2Fudpcast%40udpcast.linux.lu%2F2014%2F5%2F
Django Version: 2.2.24
Python Executable: /usr/bin/uwsgi-core
Python Version: 3.9.2
Python Path: ['.', '', '/usr/lib/python39.zip', '/usr/lib/python3.9', 
'/usr/lib/python3.9/lib-dynload', '/usr/local/lib/python3.9/dist-packages', 
'/usr/lib/python3/dist-packages', '/usr/lib/python3.9/dist-packages']
Server time: Mon, 1 Nov 2021 07:20:20 +
Installed Applications:
('hyperkitty',
 'postorius',
 'django_mailman3',
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'rest_framework',
 'django_gravatar',
 'compressor',
 'haystack',
 'django_extensions',
 'django_q',
 'allauth',
 'allauth.account',
 'allauth.socialaccount',
 'django_mailman3.lib.auth.fedora')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.middleware.locale.LocaleMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'django.middleware.security.SecurityMiddleware',
 'django_mailman3.middleware.TimezoneMiddleware',
 'postorius.middleware.PostoriusMiddleware')


Traceback:

File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner
  34. response = get_response(request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  115. response = self.process_exception_by_middleware(e, 
request)

File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in 
_get_response
  113. response = wrapped_callback(request, *callback_args, 
**callback_kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in view
  71. return self.dispatch(request, *args, **kwargs)

File "/usr/lib/python3/dist-packages/django/views/generic/base.py" in dispatch
  97. return handler(request, *args, **kwargs)

File "/usr/lib/python3/dist-packages/django_mailman3/lib/auth/fedora/views.py" 
in get
  56. return self.post(request, *args, **kwargs)

File "/usr/lib/python3/dist-packages/django_mailman3/lib/auth/fedora/views.py" 
in post
  67. client = _openid_consumer(request)

Exception Type: TypeError at /accounts/fedora/login/
Exception Value: _openid_consumer() missing 2 required positional arguments: 
'provider' and 'endpoint'
Request information:
USER: AnonymousUser

GET:
process = 'login'
next = '/mailman3/hyperkitty/list/udpc...@udpcast.linux.lu/2014/5/'

POST: No POST data

FILES: No FILES data

COOKIES: No cookie data

META:
CONTEXT_DOCUMENT_ROOT = '/var/www/html'
CONTEXT_PREFIX = ''
DOCUMENT_ROOT = '/var/www/html'
GATEWAY_INTERFACE = 'CGI/1.1'
HTTPS = 'on'
HTTP_ACCEPT = 
'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,text/html,application/xhtml+xml,application/signed-exchange;v=b3,application/xml;q=0.9,*/*;q=0.8'
HTTP_ACCEPT_ENCODING = 'gzip, deflate, br'
HTTP_AMP_CACHE_TRANSFORM = 'google;v="1..8"'
HTTP_CONNECTION = 'keep-alive'
HTTP_FROM = 'googlebot(at)googlebot.com'
HTTP_HOST = 'udpcast.linux.lu'
HTTP_USER_AGENT = 'Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Mobile Safari/537.36 
(compatible; Googlebot/2.1; +http://www.google.com/bot.html)'
PATH = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
PATH_INFO = '/accounts/fedora/login/'
QUERY_STRING = 
'process=login=%2Fmailman3%2Fhyperkitty%2Flist%2Fudpcast%40udpcast.linux.lu%2F2014%2F5%2F'
REMOTE_ADDR = '66.249.64.45'
REMOTE_PORT = '37475'
REQUEST_METHOD = 'GET'
REQUEST_SCHEME = 'https'
REQUEST_URI = 
'/mailman3/accounts/fedora/login/?process=login=%2Fmailman3%2Fhyperkitty%2Flist%2Fudpcast%40udpcast.linux.lu%2F2014%2F5%2F'
SCRIPT_FILENAME = 'proxy:uwsgi://localhost/accounts/fedora/login/'
SCRIPT_NAME = '/mailman3'
SERVER_ADDR = 

Bug#1000908: procps ships with a file in /usr/lib/sysctl.d/ that does not start with a pair of digits

[Alain Knaff]

Package: procps
Version: 2:3.3.17-5

Hi,

Procps includes a sysctl configuration file in /usr/lib/sysctl.d/ that
disallows root from overwriting group-writable files in setgid directories.

As this interferes with our backup script, we initially tried to
override it with a local file in /etc/sysctl.d, but this at first failed
due to the "interesting" way how systemd manages priorities among those
configuration files.

Apparently, systemd recommends to call those files NN-xyz.conf, with NN
being a pair of decimals to be used for ordering, as detailed in Lennart
Poettering's answer to this bug-report:

https://github.com/systemd/systemd/issues/20919


Procps' protect-links.conf file does unfortunately not follow this
convention. If for example the file was called 10-protect-links.conf,
sysadmins could easily override it by calling their file 99-allow-links.conf

We solved the issue locally by calling our file zz-allow-links.conf, but
I thought I'd mention this here in order to spare a lengthy search to
fellow sysadmins who might have the same need.

Thanks,

Alain

Bug#997060: [Pkg-mailman-hackers] Bug#997060: Bring back mailing list support to Debian

[Alain Knaff]

Hi,

On 10/24/21 12:27 AM, Pierre-Elliott Bécue wrote:
[...]
> mailman removal is the decision of the mailman maintainer, Thijs, due to
> the fact it relies on python2 which got removed from Debian.
> 
> Regarding mailman3, I did the nginx integration, Jonas the Apache2 one,
> from upstream recommendations. Looking from the config, I'd try the URL
> without the trailing slash: https://myserver/mailman3

Thanks for your reply.

Indeed, in the meantime I found the following bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996105

... and followed their advice to remove that trailing slash from
/etc/mailman3/apache2.conf, and that made it work.

> 
> I don't know if the proxy permissions are really required.

Without it, I get a permission error (even with slash removed from
apache2.conf)

> 
> Apart from that, mailman3 is in Debian since Buster, so more than three
> years, and while it indeed carried out its lot of bugs, it's quite
> usable.

There are indeed still a number of issues present which make integration
cumbersome:

- obscure "lmtp" interface to submit mails, makes it difficult to have
domains that contain both mailing lists and direct mail users. The old
way of calling /usr/lib/mailman/mail/mailman to submit was easier to
integrate. Why not ship an lmtp client that can be called the same way
as the old /usr/lib/mailman/mail/mailman ?

- the non-standard uwsgi proxy for the web interface, rather than plain
CGI which just works, and is easy to debug.

> 
> Regards,
> --
> Pierre-Elliott Bécue
> 

Regards,

Alain

Bug#997060: Bring back mailing list support to Debian

[Alain Knaff]

Package: mailman3-web
Version: 0+20200530-2

Hi,

After I recently upgraded my server to Debian 11, I was rather appalled
that mailman was dropped without a clear migration path.

I figured out that this is now replaced by mailman3-full, but apparently
that package is still pretty much work in progress.

/usr/share/doc/mailman3-web/README.Debian.gz says to run
dpkg-reconfigure mailman3-web after installing it, and this does indeed
prompt me to set up a superuser account, and installs its configuration
in the webserver

However, when navigating to https://myserver/mailman3/ , I encounter
several issues:

1. Proxy permissions are not set up.

So I added the following:


Require all granted



2. After the above, I see a message "Page not found This page either
doesn't exist, or it moved somewhere else."

Links in the top menu bar are broken, they snip off the last letter of
"mailman3", so it becomes "mailman". After setting up a ProxyPass for
the path "mailman" as well, I see that another letter is snipped in the
top links, so it becomes "mailma", then "mailm", ...

What is going on here?


3. So, I tried clicking on login, and manually added back the missing 3
to the URL and went to
https://myserver/mailman3/accounts/login/?next=/mailman3/accounts/login/

=> Still the same page with "Page not found. This page either doesn't
exist, or it moved somewhere else."


So, what gives?

I can understand that it takes some time for a full rewrite of a major
software to become production-ready. However, in that case, please don't
drop the working previous version (mailman 2.1) until the new one is
actually usable.

Thanks,

Alain

Bug#994696: Bind9's systemd .service says named available before it actually is, which makes services which depend on it fail

[Alain Knaff]

Package: bind9
Version: 1:9.16.15-1

Hi,

Bind9's systemd service file /lib/systemd/system/named.service marks
bind service as available before it actually is.
This allows systemd to proceed with starting other services which depend
on bind's availability (i.e. with After=nss-lookup.target). These
services then fail, because bind is not yet actually available at that
point.

Thanks,

Alain

Bug#994158: bt-adapter (and other bluetooth tools) throws assertions failed rather than user-understandable errors if bluetoothd not running or no host adapter present

[Alain Knaff]

Package: bluez-tools
Version: 2.0~20170911.0.7cb788c-4

Hi,

bt-adapter -i fails assertions when attempting to start it without 
bluetoothd running, or no host adapter present.


If bluetoothd is not running, it waits a long while (why? It's a TCP 
connection, which should fail immediately), and finally throws following 
assertion failed:

**
ERROR:lib/helpers.c:319:intf_supported: assertion failed: (introspection_proxy 
!= NULL)
Bail out! ERROR:lib/helpers.c:319:intf_supported: assertion failed: 
(introspection_proxy != NULL)
Aborted


If bluetoothd *is* running, but no hostadapter (HCI) present, it throws 
the following assertion:

**
ERROR:lib/bluez/adapter.c:165:adapter_get_dbus_object_path: assertion failed: 
(ADAPTER_IS(self))
Bail out! ERROR:lib/bluez/adapter.c:165:adapter_get_dbus_object_path: assertion 
failed: (ADAPTER_IS(self))
Aborted

Normally, assertions should only be thrown for *internal* bugs in the 
application, but not for external conditions (such as services or 
hardware not present). For the user it would be much more obvious if it 
plainly said something to the effect of "Bluetoothd service not running" 
or "No Bluetooth Host Adapter (HCI) found"

Thanks,

Alain

Bug#982670: wetransfer is incompletely disabled in thunderbird

[Alain Knaff]

Package: thunderbird
Version: 1:78.7.0-1~deb10u1

Hi,

In its attempt to stay afloat, thunderbird bundles a number of unwanted
extensions with its standard build.

Debian has disabled these, which is a good thing.

However, unfortunately the wetransfer extension has been disabled in an
incomplete way, by just removing the xpi. Thunderbird still attempts to
call it though, as witnessed by the following entry in the error console
(accessible via Tools->DeveloperTools->ErrorConsole):

1613201754313	addons.xpi	WARN	Can't get modified time of 
/usr/lib/thunderbird/features/wetrans...@extensions.thunderbird.net.xpi


Regards,

Alain

Bug#974026: On upgrade, sddm clobbers /usr/share/sddm/scripts/Xsetup

[Alain Knaff]

Package: sddm
Version: 0.18.0-1+deb10u1

Hi,

sddm contains a file /usr/share/sddm/scripts/Xsetup intended to be
customized... such as for setting up a displayLink hub.

Indeed, as shipped the file is empty, except for the hashbang line and a
single line comment ("Xsetup - run as root before the login dialog
appears"). Obviously intended to receive user-supplied customizations.

However, on package upgrade this file gets overwritten, losing user's
customization.

Shouldn't this be declared as a "config" file in the debian package, so
that its content is not lost on upgrade? (debian/conffiles)

Thanks,

Alain

Bug#972387: [Info-mtools] mtools does not work in Turkish locale

[Alain Knaff]

Hi,

Thanks for the details, this is now fixed in 4.0.25

Regards,

Alain


On 22/10/2020 19:01, Pali Rohár wrote:

Hello!

On Thursday 22 October 2020 16:55:04 Chris Lamb wrote:

   $ LC_CTYPE=tr_TR.UTF-8 mtools
   Syntax error at line 5 for drive A: column 9 in file /etc/mtools.conf: 
unrecognized keyword

   $ echo $?
   1


...

As I describe in my followup to that bug, I can confirm that this is
indeed locale issue, as commenting out the setlocale(3) call at the
top of the "main" entry point fixes this issue.

The following "patch" against mtools.c also ""works"" for me:

   +#ifdef HAVE_SETLOCALE
   +   char *old_locale = setlocale(LC_ALL, NULL);
   +   setlocale(LC_ALL, "C");
   +   read_config();
   +   setlocale(LC_ALL, old_locale);
   +#else
   read_config();
   +#endif


.. but this is obviously not right, as it would mean that genuine
syntax errors printed in read_config() would not be translated into,
well, Turkish. Can't seem to get a "C" locale version of toupper(3) to
work right this second, and am assuming you folks will have a cleaner
solution anyway, hence forwarding this to you.


IIRC toupper() for lowercase i with dot in Turkish locale returns
uppercase I with dot. In English or C locale it is uppercase I without
dot.

I guess that for case-insensitive parsing of config options (which are
written in English) should be used toupper() variant in C locale.

There is a standard POSIX function toupper_l() which takes as a second
argument locale. So I think that for reading config file it should be
used function toupper_l() with C locale instead of locale-dependent
toupper() function.

Bug#972326: thunderbird extensions no longer work

[Alain Knaff]

Hi,

On 17/10/2020 08:35, Alain Knaff wrote:
[...]

However, when I checked this morning, most add-ons are back now,


Please disregard this. I accidentally tried on a computer which has not 
yet been "up"graded, and is still on 68.12.0


On 78.3.1, all add-ons are still pretty much broken :-(

Thanks,

Alain

Bug#972326: thunderbird extensions no longer work

[Alain Knaff]

Hi,

On 17/10/2020 00:57, Brett Gilio wrote:

Alain Knaff  writes:

Extensions no longer work since recent update.

Examples: QuickFolders, Toggle Word Wrap, DOM Instepctor Plus!, Dorando
keyconfig, ...

Please only push new thunderbird versions once it is clear that they work.


Could you specify what the behavior is?


All Add-ons were shown greyed-out (disabled) in Tools->Add-ons->Extensions

Their corresponding UI elements (such as the "folder's bookmarks" at the 
top of the window for QuickFolders) were absent (not displayed at all).


However, when I checked this morning, most add-ons are back now, except 
"Dom Inspector Plus!". However, it could be since that one is gone since 
longer already, I don't use Dom Inspector daily. It was the QuickFolders 
that got my attention, which I do use quite often.




Something like toggling word
wrap doesn't appear to be an extension, but is a built in behavior.


Nope. Without the Toggle Word Wrap extension, there is no 
Options->EnableWordWrap (Alt+W) menu entry.


So it seems that this extension is needed after all... unless there is 
another toggle elsewhere?



If
this is the case, then perhaps our build of Thunderbird is improper.



Seems to be ok by now except Dom Inspector Plus!

Thanks,

Alain

Bug#972326: thunderbird extensions no longer work

[Alain Knaff]

Package: thunderbird
Version: 1:78.3.1-2~deb10u2

Extensions no longer work since recent update.

Examples: QuickFolders, Toggle Word Wrap, DOM Instepctor Plus!, Dorando
keyconfig, ...

Please only push new thunderbird versions once it is clear that they work.

Thanks,

Alain

Bug#971985: $validFooterLinks flattened without checking it is non-empty

[Alain Knaff]

Package: mediawiki
Version: 1:1.31.10-1~deb10u1

Hi,

In /usr/share/mediawiki/includes/skins/BaseTemplate.php after line 601, 
the $validFooterLinks is "flattened" without checking that it is non-empty.


This results in an unsightly warning in the web server log:

[Sun Oct 11 09:19:03.631271 2020] [proxy_fcgi:error] [pid 27294:tid 
139621082044160] [client 114.119.136.128:13642] AH01071: Got error 'PHP 
message: PHP Warning:  array_merge() expects at least 1 parameter, 0 
given in /usr/share/mediawiki/includes/skins/BaseTemplate.php on line 
603PHP message: PHP Warning:  count(): Parameter must be an array or an 
object that implements Countable in 
/usr/share/mediawiki/skins/MonoBook/includes/MonoBookTemplate.php on 
line 527'


Bracketing the infringing code with count() as follows fixes the issue:

if(count($validFooterLinks) > 0) {
$validFooterLinks = call_user_func_array(
'array_merge',
array_values( $validFooterLinks )
);
}

(i.e. don't flatten the array if it is empty)

Thanks,

Alain

Bug#971986: $wgRedirectOnLogin ignored

[Alain Knaff]

Package: mediawiki
Version: 1:1.31.10-1~deb10u1

Hi,

The localSettings variable $wgRedirectOnLogin is ignored, apparently 
because the showReturnToPage function forgot to declare it global. This 
results in an unsightly warning in the web server log:


[Sun Oct 11 09:29:12.186114 2020] [proxy_fcgi:error] [pid 14121:tid 
139621415540480] [client 80.90.57.94:38882] AH01071: Got error 'PHP 
message: PHP Notice:  Undefined variable: wgRedirectOnLogin in 
/usr/share/mediawiki/includes/specials/helpers/LoginHelper.php on line 
68', referer: https://wiki.lll.lu/Special:UserLogin?returnto=HomePage



Adding the following to the top of the showReturnToPage in 
/usr/share/mediawiki/includes/specials/helpers/LoginHelper.php fixes the 
issue:

  global $wgRedirectOnLogin;


Thanks,

Alain

Bug#968888: vsftpd silently botches pasv_address setting if listen_ipv6 has been left to its default value

[Alain Knaff]

Package: vsftpd
Version: 3.0.3-12

Hi,

The pasv_address setting in vsftpd does not work if listen_ipv6 is set, 
with no clear error message anywhere in the log about what is going on.

This setting is used for ftp servers behind a reverse NAT.

If used while listen_ipv6=YES (as in default sample configuration 
shipped), the address specified in pasv_address is ignored, but instead 
0.0.0.0 is used, even if the client did indeed connect via IPV4.

Analysis:

at the top of function handle_pasv(), vsftpd does the following:

  int is_ipv6 = vsf_sysutil_sockaddr_is_ipv6(p_sess->p_local_addr);


... and then later:

  if (!is_ipv6)
  {
str_append_text(_pasv_res_str, vsf_sysutil_inet_ntop(s_p_sockaddr));
  }
  else
  {
const void* p_v4addr = vsf_sysutil_sockaddr_ipv6_v4(s_p_sockaddr);
if (p_v4addr)
{
  str_append_text(_pasv_res_str, vsf_sysutil_inet_ntoa(s_p_sockaddr));
}
else
{
  str_append_text(_pasv_res_str, "0,0,0,0");
}
  }

The first "if" goes into the second branch (address considered as IPv6).
The second "if" tests whether the s_p_sockaddr is indeed IPv6 (which it 
is not), and if not falls back to 0,0,0,0


Shouldn't this be a single test?

const void* p_v4addr = vsf_sysutil_sockaddr_ipv6_v4(s_p_sockaddr);
if (p_v4addr)
{
  str_append_text(_pasv_res_str, vsf_sysutil_inet_ntoa(s_p_sockaddr));
}
else
{
  vsf_sysutil_inet_ntop(s_p_sockaddr);
}

... or something similar?

Or if for some reason this is not doable, at least loudly warn in the 
log file if this condition occurs (pasv_address used along with 
listen_ipv6=YES)

Thanks,

Alain

Bug#964935: Zoneminder camera zma crashes since zoneminder_1.35.5~20200707.77

[Alain Knaff]

Package: zoneminder
Version: 1.35.5~20200707.77-buster
Severity: critical

Since a recent upgrade, we found the following message in the log 
repeatedly:

Jul 12 07:59:12 felix zma_m6[19229]: ERR [zma_m6] [Got empty memory map file 
size 0, is the zmc process for this monitor running?]

... and this for all cameras. When this happens the system shows the 
camera as being offline, then it automatically starts it again, until it 
crashes again a couple of seconds later.

Downgrading to zoneminder_1.35.5~20200627.22 fixed the issue

Thanks,

Alain

Bug#964336: Mimedefang's relay_is_blacklisted_multi function gets confused if Net::DNS::Resolver falls back to TCP in order to retry queries with truncated UDP response packets

[Alain Knaff]

Package: mimedefang
Version: 2.84-3
Severity: important
Tags: patch

Dear maintainer,

The relay_is_blacklisted_multi function seems to be unaware that 
Net::DNS::Resolver->bgread (and bgbusy) may change their $handle 
parameter in the caller's scope via the $_[1] = $newvalue idiom under 
certain conditions.


Indeed, such change happens when the reply to the UDP query is 
truncated, and Net::DNS::Resolver has to re-issue the query as a TCP 
query. This happens frequently with the bl.spamcop.net blacklist.


The result of this is that the lookup for the domain in the 
$sock_to_domain hash fails, as $sock is no longer the original $sock 
that it was before the call to bgread.


If this happens, you'll find entries such as the following in the log:
Jun 28 00:20:33 lll mimedefang-multiplexor[23337]: 05RMKV8R016512: Worker 5 
stderr: Use of uninitialized value $domain in hash element at 
/usr/bin/mimedefang.pl line 1714.
Jun 28 00:20:33 lll mimedefang-multiplexor[23337]: 05RMKV8R016512: Worker 5 
stderr: Use of uninitialized value in string eq at /usr/bin/mimedefang.pl line 
1714.
Jun 28 00:20:33 lll mimedefang-multiplexor[23337]: 05RMKV8R016512: Worker 5 
stderr: Use of uninitialized value $domain in hash element at 
/usr/bin/mimedefang.pl line 1717.

==> in order to be correct, $domain = $sock_to_domain{$sock}; has to 
happen *before* $res->bgread($sock). Likewise, $sel->remove($sock) also 
needs to happen before bgread.



Another issue is that if a TCP fallback was indeed performed, then 
bgread may still block even though its handle was in the select's 
can_read set.


==> so if we want to make sure that we parallelize all queries, rather 
than blocking on a single one of them, we need to test 
$res->bgbusy($sock). And if indeed busy, add $sock again to the 
sock_to_domain hash and $sel (as it may have been changed by 
Net::DNS::Resolver's bgbusy).


The attached patch accomplishes this.

Thanks,

Alain
--- mimedefang-orig.pl	2020-07-03 20:04:25.418013798 +0200
+++ mimedefang.pl	2020-07-05 21:01:38.566585418 +0200
@@ -1697,9 +1697,14 @@
 	my @ready;
 	@ready = $sel->can_read($expire);
 	foreach $sock (@ready) {
-	my $pack = $res->bgread($sock);
 	$sel->remove($sock);
 	$domain = $sock_to_domain{$sock};
+	if($res->bgbusy($sock)) {
+		$sock_to_domain{$sock}=$domain;
+		$sel->add($sock);
+		next;
+	}
+	my $pack = $res->bgread($sock);
 	undef($sock);
 	my($rr, $rcode);
 	$rcode = $pack->header->rcode;

Bug#959730: libgtk-3-0-dbgsym (3.22.11-1) out of phase with libgtk-3-0 (3.24.5-1)

[Alain Knaff]

On 04/05/2020 19:50, Simon McVittie wrote:

On Mon, 04 May 2020 at 19:05:36 +0200, Alain Knaff wrote:

While investigating a focus stealing bug in Firefox, which uses
libgtk-3.0, I noticed that the debug symbol package is out of phase with
the main package, preventing it from being installed:


What apt sources (/etc/apt/sources.list and /etc/apt/sources.list.d/*)
are you using to get these?

Please configure a source of debug symbols that corresponds to the
version of Debian you are running, whatever version that might be
(if you have libgtk-3-0=3.24.5-1 then it's presumably Debian 10 'buster').


Indeed, Debian 10.



I would expect to find libgtk-3-0-dbgsym=3.22.11-1 in:

 deb http://deb.debian.org/debian-debug stretch-debug main

but libgtk-3-0-dbgsym=3.24.5-1 in:

 deb http://deb.debian.org/debian-debug buster-debug main


Indeed, this was the reason. Probably a left over from when I had Debian 
9. Is updated now, and now it works. Thanks, and sorry for not thinking 
about this myself...





and libgtk-3-0-dbgsym=3.24.18-1 in:

 deb http://deb.debian.org/debian-debug unstable-debug main

(and so on for other suites).

http://debug.mirrors.debian.org/debian-debug/pool/main/g/gtk+3.0/ appears
to include all of those versions.

 smcv



Thanks,

Alain

Bug#959730: libgtk-3-0-dbgsym (3.22.11-1) out of phase with libgtk-3-0 (3.24.5-1)

[Alain Knaff]

Package: libgtk-3-0-dbgsym
Version: 3.22.11-1

Hi,

While investigating a focus stealing bug in Firefox, which uses 
libgtk-3.0, I noticed that the debug symbol package is out of phase with 
the main package, preventing it from being installed:

# apt install libgtk-3-0-dbgsym
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgtk-3-0-dbgsym : Depends: libgtk-3-0 (= 3.22.11-1) but 3.24.5-1 is to be 
installed
E: Unable to correct problems, you have held broken packages.


Please fix.

Thanks,

Alain

Bug#955362: Emacs steals focus

[Alain Knaff]

Package: emacs
Version: 1:26.1+1-3.2+deb10u1

Hi,

Since Debian 10, I've noticed that on occasion Emacs steals focus.

It doesn't happen always, but often enough to be annoying when working
with 2 applications and an emacs sitting in between both.

To reproduce, just quickly move the cursor between the 2 applications
and the extremity. Use konsole or similar application to easily see
whether you have focus by the shape of the cursor. After a couple of
seconds of shaking the mouse between the 2 consoles, you'll notice that
emacs has stolen the focus from them.

I've tried KDE's focus stealing prevention, to no avail. Emacs still
does it.

I've even written an LD_PRELOADable object which maps XGrabPointer and
XGrabKeyboard to a no-op: this doesn't help either (although it does
trigger when clicking on a menu item) => so I suppose emacs uses some
different X intrinsics call to steal the focus, but which one?

Is there a way from within Emacs to switch this annoying behavior off?

Thanks,

Alain

Bug#931830: Debian 10 includes known bad version of digikam => please make available .DEB of newer / more stable version

[Alain Knaff]

Package: digikam:amd64
Version: 4:5.9.0-1+b1

Hi,

Buster includes a known bad version of digikam, which freezes on
internal database access (409686) and makes it cumbersome to invoke its
image editor (395875).

Bug reported to upstream, they say it's an obsolete version which should
no longer be used: watch comment#2 by Maik Qualmann on bug 409686:

https://bugs.kde.org/show_bug.cgi?id=409686#c2


As far as I remember, it's not the first time that there have been
issues with bad digikam versions included in new Debian releases.
Wouldn't it be possible to check with upstream whether the version which
is planned to be included has known showstopper bugs before making a
major Debian release?

Thanks,

Alain

Bug#900625: Bug still present in stretch: [Bug#865987: libpcre3: Drop hard-coded Pre-Depends on deprecated multiarch-support]

[Alain Knaff]

Package: libpcre3:amd64
Version: 2:8.39-3


Hi,

A broken version of libpcre3 is still included in stretch, unfortunately :-(

Please fix this in stretch as well.

Moreover, the following packages are affected as well:

# dpkg -r multiarch-support
dpkg: dependency problems prevent removal of multiarch-support:
 libxau6:amd64 depends on multiarch-support.
 libshout3:amd64 depends on multiarch-support.
 libnfnetlink0:amd64 depends on multiarch-support.
 liblqr-1-0:amd64 depends on multiarch-support.
 libglade2-0:amd64 depends on multiarch-support.
 libogg0:amd64 depends on multiarch-support.
 libmhash2:amd64 depends on multiarch-support.
 libcdparanoia0:amd64 depends on multiarch-support.
 libpcre3:amd64 depends on multiarch-support.
 libxss1:amd64 depends on multiarch-support.
 liblockfile1:amd64 depends on multiarch-support.
 libnet1:amd64 depends on multiarch-support.
 libestr0 depends on multiarch-support.
 libart-2.0-2:amd64 depends on multiarch-support.

Thanks,

Alain

Bug#898536: Fail2ban is very slow to shut down

[Alain Knaff]

Package: fail2ban
Version: 0.9.6-2

Hi,

The version of fail2ban included in stretch (0.9.6-2) is very slow to
shut down.

root@lll:~# time service fail2ban stop

real3m1.331s
user0m0.004s
sys 0m0.000s

Thanks for fixing this,

Alain

Bug#898469: Squid waits on shutdown even though there are no active clients

[Alain Knaff]

Package: squid
Version: 3.5.23-5+deb9u1

Hi,

The comment about on shutdown_lifetime in the sample squid.conf file
says the following:

#  TAG: shutdown_lifetime   time-units
#   When SIGTERM or SIGHUP is received, the cache is put into
#   "shutdown pending" mode until all active sockets are closed.
#   This value is the lifetime to set for all open descriptors
#   during shutdown mode.  Any active clients after this many
#   seconds will receive a 'timeout' message.


However, in reality, squid waits the shutdown_lifetime regardless of
whether there are any active clients currently connected to or not.

Even if no clients are connected (squid freshly started, in the middle
of the night, verified using lsof and netstat), it still takes 30
seconds to shutdown.

So either the code (preferably...) or that comment needs to be fixed.

... or did I just misunderstand the documentation? ;^)

Thanks,

Alain

Bug#898328: Missing sgid bit on /usr/lib/squid/basic_pam_auth

[Alain Knaff]

Package: squid
Version: 3.5.23-5+deb9u1

In the Debian package, /usr/lib/squid/basic_pam_auth lacks its shadow
group and associated s-gid bit, and thus cannot fulfill its sole purpose
of authenticating users, as it cannot read the /etc/shadow file.

Manually adding fixes this for a while, but such fix undoes itself on
next update of squid package, resulting in cumbersome support calls.

Please fix.

Or maybe, if you feel that some people might be uncomfortable with
binaries that have setuid or setgid bits, just separate it into a
separate package? But just breaking it is _not_ nice.

Thanks,

Alain

Bug#893962: Acknowledgement (Modsecurity ignores phase 2 rules in Debian Stretch)

[Alain Knaff]

Found it: this was happening whenever the URL was redirecting.
Apparently, when a redirect using "Redirect permanent" happens,
mod-security's phase 2 is not called.

The Ubuntu host that I used for comparison had other configuration
differences which would cause the same URL to be served directly (and
thus be subject to phase 2) rather than redirected.

Sorry for the false alert.

Regards,

Alain

Bug#893962: Modsecurity ignores phase 2 rules in Debian Stretch

[Alain Knaff]

Package: libapache2-mod-security2
Version: 2.9.1-2

Modsecurity in stretch seems to ignore rules in phase 2.

I've defined the following test case:



SecResponseBodyAccess on

SecRuleEngine On

# Does not work
SecRule ARGS "/proc/(.*/)?self/(.*/)?environ" 
"phase:2,id:1420001,t:none,log,deny"

# Works
SecRule QUERY_STRING "^-[sdcr].*" 
"phase:1,id:1420701,t:none,t:urlDecodeUni,t:removeWhitespace,deny,log,msg:'Potential
 PHP-CGI Exploit Attempt',logdata:%{matched_var}"

SecRuleEngine On



The rule 1420701 triggers correctly (as shown via 
curl   "http://192.168.178.70/?-s;
)

However the rule 1420001 doesn't trigger (as shown by
curl   "http://192.168.178.70/?a=/proc/self/environ;
)

On an older Linux (Ubuntu 14.04 with modsecurity 2.7.7-2) both rules 
work all right, so this (apparently) isn't a case of ARGS not working 
"by principle" in phase 2.

Unfortunately, popular open rule collections such as CRS use phase 2 a 
lot (... and for instance RFI is not triggered by curl 
"http://192.168.178.70/?a=http://www.somewhere.com; when CRS is 
installed, but it is triggered correctly with CRS on the older Ubuntu)

So just changing phase 2 into phase 1 is not an option, as this would
require changing half of CRS, and risking breaking something else.

Any ideas how to fix this?

Thanks,

Alain

Bug#890585: davmail doesn't cleanly close sessions (to Exchange) on exit, or when client leaves?

[Alain Knaff]

Package: davmail
Version: 4.8.3.2554-1

Hi,

When shutting down davmail, and restarting it, we often get
Microsoft.Exchange.Data.Storage.TooManyObjectsOpenedExceptions when the
client (Thunderbird) reconnects.

This even happens when exiting Thunderbird before killing davmail.

==> Apparently davmail doesn't close its sessions with Exchange, neither
when its client (Thunderbird) closes the session, nor when it exits
(should catch the signal).

... or *does* it actually close the session, and Exchange doesn't do
proper accounting of open sessions?

Thanks,

Alain

Bug#887840: Otrs blocks on receipt of a mail with too long headers

[Alain Knaff]

Package: otrs2
Version: 3.3.18-1+deb8u4

Hi,

Recently a spammer sent a mail to our otrs address with way too many
recipients in To: and Cc:. This had the effect of completely stalling
otrs' mail processing. Rather than just skip over this faulty mail, and
move on to the other mails, the postmaster task just crashed. From then
on failed to process any mails, until we manually deleted this mail from
OTRS' imap mailbox.

Attached is the error message sent by otrs (2250.empl), as well as the
faulty mail that triggered this mess (marques.eml).

Thanks,

Alain
--- Begin Message ---
-- Message transféré --
De : Filipe Marques 
Date : 7 novembre 2017 à 11:44
Objet : Pour votre information.SMARTMETER.
À :
Cc : Ville de Dudelange , Ville de Dudelange - Maison
relais , loris.sp...@dudelange.lu,
rene.mandersch...@dudelange.lu, dan.biancal...@dudelange.lu,
ecolo...@dudelange.lu, mediat...@dudelange.lu, "patrick.h...@dudelange.lu" <
patrick.h...@dudelange.lu>, "francine.zigli...@dudelange.lu" <
francine.zigli...@dudelange.lu>, Sarah Pétré , "
dorothee.con...@dudelange.lu" , "
melanie.ar...@dudelange.lu" , "
danielle.ign...@dudelange.lu" , François
Olivieri , "victormatiasc...@dudelange.lu" <
victormatiasc...@dudelange.lu>, "guy.net...@dudelange.lu" <
guy.net...@dudelange.lu>, Alexis Cardoso , "
tom.bern...@dudelange.lu" , "
claire.dum...@dudelange.lu" , "
diogo.co...@dudelange.lu" , "
roby.goer...@dudelange.lu" , "
paulo.lo...@dudelange.lu" , "
circulat...@dudelange.lu" , "
gilber.l...@dudelange.lu" , "
sabatino.sp...@dudelange.lu" , "
dudela...@flammang.lu" , "serge.b...@dudelange.lu" <
serge.b...@dudelange.lu>, "claudia.dallagn...@dudelange.lu" <
claudia.dallagn...@dudelange.lu>, "chantal.nil...@dudelange.lu" <
chantal.nil...@dudelange.lu>, "jeanette.sin...@dudelange.lu" <
jeanette.sin...@dudelange.lu>, "annecaroleh...@dudelange.lu" <
annecaroleh...@dudelange.lu>, "michele.scha...@dudelange.lu" <
michele.scha...@dudelange.lu>, "manon.h...@dudelange.lu" <
manon.h...@dudelange.lu>, "muriel.hom...@dudelange.lu" <
muriel.hom...@dudelange.lu>, "tamara.monace...@dudelange.lu" <
tamara.monace...@dudelange.lu>, Nic krumlovsky ,
"alain.pal...@dudelange.lu" , "
jose.fav...@dudelange.lu" , "
carly.bo...@dudelange.lu" , "
pascal.capit...@dudelange.lu" , "
veronique.str...@dudelange.lu" , "
jeannette.sin...@dudelange.lu" , "
tatjana.greffr...@dudelange.lu" , "
henri.glese...@dudelange.lu" , "
chistian.we...@dudelange.lu" , "
bibliothe...@dudelange.lu" , "
sven.loschei...@dudelange.lu" , "
frank.c...@dudelange.lu" , "
mandy.kre...@dudelange.lu" , "
alain.b...@dudelange.lu" , "
mayriam.ham...@dudelange.lu" , "
cult...@dudelange.lu" , "sandy.b...@dudelange.lu" <
sandy.b...@dudelange.lu>, "marco.th...@dudelange.lu" <
marco.th...@dudelange.lu>, "nicole.arensd...@dudelange.lu" <
nicole.arensd...@dudelange.lu>, "robert.bigdow...@dudelange.lu" <
robert.bigdow...@dudelange.lu>, "daniel.welli...@dudelange.lu" <
daniel.welli...@dudelange.lu>, "myriam.kel...@dudelange.lu" <
myriam.kel...@dudelange.lu>, "natascha.pier...@dudelange.lu" <
natascha.pier...@dudelange.lu>, "julia.recktenw...@dudelange.lu" <
julia.recktenw...@dudelange.lu>, "gilbert.l...@dudelange.lu" <
gilbert.l...@dudelange.lu>, "nadine.gr...@dudelange.lu" <
nadine.gr...@dudelange.lu>, "veronique.her...@dudelange.lu" <
veronique.her...@dudelange.lu>, "biergerfo...@dudelange.lu" <
biergerfo...@dudelange.lu>, "josiane.piki...@dudelange.lu" <
josiane.piki...@dudelange.lu>, "cipa.dudela...@servior.lu" <
cipa.dudela...@servior.lu>, "romain.zeim...@dudelange.lu" <
romain.zeim...@dudelange.lu>, "patrick.capit...@dudelange.lu" <
patrick.capit...@dudelange.lu>, "romain.zu...@dudelange.lu" <
romain.zu...@dudelange.lu>, Claude Tritz , "
annabellelaboriersaf...@dudelange.lu" 


http://www.chd.lu/wps/portal/public/Accueil/TravailALaChambre/Recherche/
RoleDesAffaires?action=doQuestpaDetails=15846
--- End Message ---
--- Begin Message ---
DBD::Pg::db do failed: ERROR:  

Bug#865036: Installing something into a KVM guest via pass-thru USB triggers USB resets on host, slows down guest

[Alain Knaff]

On 19/06/17 09:42, Alain Knaff wrote:
> On 19/06/17 09:27, Michael Tokarev wrote:
>> 18.06.2017 22:32, Alain Knaff wrote:
> [...]
>>> kvm -usb -device usb-host,hostbus=1,hostport=1 \
>>>   -netdev user,id=net0 -device ne2k_pci,netdev=net0 \
>>>   -m 2G  -drive file=$HOME/tmp/hda.img -boot menu=on
>>
>> Please either use regular block device or high-speed usb
>> pass-thru (ehci or better xhci).
> 
> Thanks for this info, but can you please tell me how to do to use
> high-speed usb pass-thru?

Found it:

kvm -usb -device nec-usb-xhci,id=xhci \
 -device usb-host,bus=xhci.0,vendorid=0x13fe,productid=0x4100 \
 -netdev user,id=net0 -device ne2k_pci,netdev=net0 \
 -m 2G -drive file=$HOME/tmp/hda.img -boot menu=on

This does indeed "mostly" fix the problem (repeated resets), however 
there are still 3 resets happening on first access by the virtual 
machine.

Jun 19 12:54:47 alain-pc kernel: [14167.803353] usb 3-1: reset high-speed USB 
device number 5 using xhci_hcd
Jun 19 12:54:48 alain-pc kernel: [14168.719354] usb 3-1: reset high-speed USB 
device number 5 using xhci_hcd
Jun 19 12:54:49 alain-pc kernel: [14169.127355] usb 3-1: reset high-speed USB 
device number 5 using xhci_hcd


Thanks,

Alain

Bug#865036: Installing something into a KVM guest via pass-thru USB triggers USB resets on host, slows down guest

[Alain Knaff]

Package: qemu-kvm
Version: 1:2.8+dfsg-3~bpo8+1

Hi,

When installing something from a Kingston USB stick (13fe:4100) via 
pass-through into a KVM guest, there's a never ending stream of USB 
resets on the host, which slows down USB access in the guest 
tremendously:

Jun 18 21:20:14 hitchhiker kernel: [ 1985.108140] usb 1-1: reset high-speed USB 
device number 7 using xhci_hcd

These repeat roughly once a second.

Here is the command line triggering the problem:

kvm -usb -device usb-host,hostbus=1,hostport=1 \
  -netdev user,id=net0 -device ne2k_pci,netdev=net0 \
  -m 2G  -drive file=$HOME/tmp/hda.img -boot menu=on

It was observed while trying to test an USB stick with the Debian 8.8.0 
netboot on it, called using the following grub paragraph:

menuentry 'debian-8.8.0-amd64-netinst' {
linux /boot/iso/linux-netboot-debian-8.8.0-amd64
initrd /boot/iso/initrd-netboot-debian-8.8.0-amd64.gz
}

USB resets start scrolling by shortly before the installer prompts to 
select the language for the installation process.

This happens with different USB sticks, although the exact behavior 
changes, with some other sticks (05e3:0749) it is preceded by the 
following messages:

Jun 18 17:50:14 hitchhiker kernel: [20577.554228] usb 2-1: Disable of 
device-initiated U1 failed.
Jun 18 17:50:14 hitchhiker kernel: [20577.557690] usb 2-1: Disable of 
device-initiated U2 failed.

... and often followed by:

Jun 18 17:50:14 hitchhiker kernel: [20578.042211] sd 6:0:0:0: [sdb] tag#0 
FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 18 17:50:14 hitchhiker kernel: [20578.042214] sd 6:0:0:0: [sdb] tag#0 Sense 
Key : Unit Attention [current] 
Jun 18 17:50:14 hitchhiker kernel: [20578.042216] sd 6:0:0:0: [sdb] tag#0 Add. 
Sense: Not ready to ready change, medium may have changed
Jun 18 17:50:14 hitchhiker kernel: [20578.042217] sd 6:0:0:0: [sdb] tag#0 CDB: 
Read(10) 28 00 00 ee 1f 70 00 00 10 00
Jun 18 17:50:14 hitchhiker kernel: [20578.042218] blk_update_request: I/O 
error, dev sdb, sector 15605616
Jun 18 17:50:14 hitchhiker kernel: [20578.261820]  sdb: sdb1



Any ideas what might be going on here?

Thanks,

Alain

Bug#859270: OpenSSH should make it possible to explicitly chose public (long-lived) IPv6 address over temporary (anti-tracking) IPv6 address

[Alain Knaff]

Package: openssh-client
Version: 1:6.7p1-5+deb8u3

Executive summary: Browsers need short-lived addresses which can't be
tracked whereas ssh needs long-lived addresses which ensure that
connections aren't cut after a couple of hours.

Long explanation:

By default, IPv6 creates client addresses which contain the client PC's
MAC address, which exposes the user to tracking by malicious web
servers or ad networks.

That's why RFC 3041 introduced privacy extensions which allow to set up
"temporary" addresses which don't contain the MAC, but which are
recycled quickly. The temporary address is defined in _addition_ to the
public address. The temporary address is to be used for outgoing
connection by exposed programs, such as web browsers. The public
address is to be used for incoming connections (where PC is a server),
and by long-lived clients such as openssh which connect to trusted
servers

https://home.regit.org/2011/04/ipv6-privacy/
sysctl -w net.ipv6.conf.eth0.use_tempaddr=2

The issue: openssh too uses the temporary address, leading to
connection interruptions whenever the address cycles, or at least such
behavior should be configurable.

Openssh should use
setsockopt(socket, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, ,
sizeof(value))
to explicitly opt for the public address.

See also this bug on RedHat (which suggests to make the behavior
configurable):
https://bugzilla.redhat.com/show_bug.cgi?id=512032


Thanks,

Alain

Bug#859062: Apache2 segfaults when using ProxySet in a ProxyMatch block

[Alain Knaff]

Package: apache2
Version: 2.4.10-10+deb8u8

Hi,

The following config causes a segmentation fault:


  ProxySet connectiontimeout=86400 timeout=86400
  ...



==>
# systemctl status apache2.service -l
...
Mar 29 07:35:02 mysite systemd[1]: Reloaded LSB: Apache2 web server.
Mar 29 23:47:46 mysite systemd[1]: Reloading LSB: Apache2 web server.
Mar 29 23:47:46 mysite apache2[6157]: Reloading web server: apache2 failed!
Mar 29 23:47:46 mysite apache2[6157]: The apache2 configtest failed. Not doing 
anything. ... (warning).
Mar 29 23:47:46 mysite apache2[6157]: Output of config test was:
Mar 29 23:47:46 mysite apache2[6157]: Segmentation fault
Mar 29 23:47:46 mysite apache2[6157]: Action 'configtest' failed.
Mar 29 23:47:46 mysite apache2[6157]: The Apache error log may have more 
information.
Mar 29 23:47:46 mysite systemd[1]: apache2.service: control process exited, 
code=exited status=1

Thanks,

Alain

Bug#857550: Owncloud in Debian 8 is way outdated (7.0.4), and can no longer be easily upgraded to now-current version (9.1.4)

[Alain Knaff]

Package: owncloud
Version: 7.0.4+dfsg-4~deb8u4

Hi,

Following a security report at our owncloud installation, I attempted to
upgrade, but I noticed that I could only upgrade to 7.0.4 (from 7.0.3),
as that was the most recent version in the Debian repositories.

Fortunately, I located a third-party repository at
http://download.owncloud.org/download/repositories/stable/Debian_8.0/

However, the version they have is 9.1.4, and the gap is so big that the
database can't be upgraded. Apparently the recommended approach is to
upgrade by little steps, but the intervening debs can no longer be found
anywhere.

Thanks for remediating this (i.e. make available more recent versions
that 7.0.4, but still keep enough steps around to ease upgrading)

Thanks,

Alain

Bug#856169: Chromium installs a setuid binary without obvious need nor warning

[Alain Knaff]

Package: chromium
Version: 56.0.2924.76-1~deb8u1

Chromium's .deb install a suid root binary
(/usr/lib/chromium/chrome-sandbox), potentially exposing the user's
system to hostile javascripts downloaded from the untrusted web.

This has already been exploited in the past:

https://bugs.chromium.org/p/chromium/issues/detail?id=76542

Debian packages should not expose users' systems to these kinds of risks
without informed consent.

Alain

Bug#843242: solved (Was: Acknowledgement (When dealing with PDF files in another application, icedove frequently crashes with message "*** buffer overflow detected ***"))

[Alain Knaff]

Hi,

In the meantime, I found the real reason: a broken GTK2 "oxygen" Engine
(as hinted already by the stack trace... d'oh). After switching to
qtcurve, the issue disappeared.

Sorry for suspecting the wrong package at first,

Alain


On 11/05/2016 13:33, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Christoph Goehre 
> 
> If you wish to submit further information on this problem, please
> send it to 843...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

Bug#852206: Oxygen2 GTK engines make mozilla software unstable

[Alain Knaff]

Package: gtk2-engines-oxygen
Version: 1.4.6-1

Hi,

The oxygen theme seems to make Mozilla software misbehave.

- Text is shown garbled in lightning tasks:  
https://bugzilla.mozilla.org/show_bug.cgi?id=1325854
- Text is shown garbled in firefox in edition textareas of mediawiki: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1325867
- Icedove crashes when closing PDF documents in other applications: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843242

The last bug (PDF induced crash) clearly shows 
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so in its 
stacktrace

All 3 issues disappeared after switching to another GTK2 theming engine 
(qtcurve)

Thanks,

Alain

Bug#852058: Coreutils corrupts its own error messages with "smart" quotes

[Alain Knaff]

Package: coreutils
Version: 8.23-4

The version of coreutils included in Debian generates error messages
containing "smart" quotes. According to coreutils developers, the issue
is fixed in coreutils 8.25 in order to make it easier to cut and paste
file names from diagnostics into shells.

Please consider including that new version into stable Debian, or at
least spot-backporting the fix.

Thanks,

Alain

Bug#841135: Debian/Ubuntu multiboot USB sticks (Was: Re: Bug#841135: Acknowledgement (iso-scan/filename ignored in Debian 8.6.0 => cannot put it on multiboot USB stick))

[Alain Knaff]

Hi,

I had a little bit of time, so I continued to investigate the issue.

>From what I understand now, iso-scan is not meant to use any iso 
filename supplied to it via grub command line, but it rather prefers to 
scan the USB stick for usable images itself, and then present the user 
with a menu.

The issue that I described occurs when there is more than one 
"Debian-like" ISO image present at a level 1 subdirectory (such as 
/install).

In that case, it falls into case 20) of the state-machine:

20) # One or multiple ISO(s) found: ask which one we'll use
# FIXME: not l10n safe
db_subst iso-scan/ask_which_iso ISOS_LIST "$ISOS_FOUND"
db_input ${CRITICAL:-medium} iso-scan/ask_which_iso || true
;;

Note, that (by default), the input is treated with priority medium, 
which means that the user is not asked, but the system just assumes the 
first available choice as default => which leads to trouble if for 
instance both a Debian and a Ubuntu iso are present on the same USB 
stick.

If multiple images are present _deeper_ in the hierarchy (such as 
/boot/iso), it falls into state 30, which uses priority=high:

30) # One or multiple ISO(s) found: ask which one we'll use
db_clear
db_subst iso-scan/ask_which_iso ISOS_LIST "$ISOS_FOUND"
db_subst iso-scan/ask_which_iso SECOND_PASS "."
if echo "$ISOS_FOUND" | grep -q ', '; then
priority=high
else
priority=medium
fi
BACKUPSTATE=10
db_input ${CRITICAL:-$priority} iso-scan/ask_which_iso || true
;;

==> the user is asked.


So, with the existing code several workarounds would be available to 
solve the issue, of which none are completely satisfactory:

1. Store the ISOs in a level deep enough to fall under case 30. 
Downside: a costly full-disk scan is incurred on all media, including 
the built-in hard disk, which may contain an existing installation with 
many, many files...

2. Pass an exact name of ISO (with all decorations) as a boot parameter:

linux (loop)/install/vmlinuz iso-scan/ask_which_iso="[sdb1] $isofile (xenial - 
16.04)"

Downside: this includes the media name (sdb1), which may not always be 
the same on all computers where this bootable USB stick might be used.

3. Add debconf/priority=medium . This does allow the user to chose the 
ISO image in state 20, but at the price of having to manually navigate 
the installation procedure (pick each step from main menu, rather than 
being guided along by the wizard)


By changing the iso-scan.postinst code, several approaches would be 
possible:

1. Copy-paste the priority picking code from step 30 into 20, so that 
20 too asks the user to chose if more than one iso is found at that 
stage.

2. The find "$dir" $opt -name "*.iso" in scan_devices_for_iso could be 
replaced with the following:

db_get iso-scan/iso_pattern
isolist=$(find "$dir" $opt -iname "${RET:-*.iso}"  2>/dev/null)

That way, existing behavior is preserved if iso-scan/iso_pattern is not 
set, but if it is set, it scans for a specific filename.

3. A couple of steps could be added initially, looking for a specific 
full path on all connected devices, and only drop to the existing code 
if either no such full path was specified on kernel command line, or if 
that path could be found on no device.

4. The FIXME in analyze_cd about comparing the codename (or suite-name)
would help

Each of these changes would make it much easier to set up USB sticks 
bootable into multiple distributions.

Thanks for your attention,

Alain

Bug#843822: KDE binaries (ksplashqml) *silently* fail if they cannot allocate memory, causing a hang at startup

[Alain Knaff]

Package: kde-workspace-bin
Version: 4:4.11.13-2

When attempting to start kde with a too low ulimit -d applied, kde just 
hangs, without displaying its splash screen, nor popping up any error 
dialog, nor printing any error message to stderr (.xsession-errors)

This makes diagnosing such situations needlessly difficult.

strace shows the following sequence:

6907  execve("/usr/bin/ksplashqml", ["ksplashqml", "lines", "--pid"], [/* 59 
vars */]) = 0
...
6907  clone(child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f8ada54aa50) = 6908
...
6907  exit_group(0) = ?
6907  +++ exited with 0 +++
...
6908  mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0 
6908  <... mmap resumed> )  = -1 ENOMEM (Cannot allocate memory)
6908  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xbbadbeef} 
---
6908  +++ killed by SIGSEGV +++

This shows several problems:
1. No attempt is made by the victim process (ksplashqml) to write an 
error message to stderr
2. Apparently the victim process tries to use the pointer returned by 
mmap without first checking it for MAP_FAILED, which results in a 
segfault.
3. The process is started with a double-fork making it impossible for 
the parent process to react to the SEGV either. Double fork is a weird 
way of starting a child process that is meant to be shortlived (such as 
the splash screen)

This situation may seem cosmetical (it's the splash screen, after 
all...) but unfortunately it occurs similarly for 
/usr/bin/kbuildsycoca4 --incremental --checkstamps and 
/usr/bin/kdeinit4 --oom-pipe +kcminit_startup

Occasionally the following message is indeed printed to stderr:

QThread::start: Thread creation error: Resource temporarily unavailable

This is still misleading, as it doesn't tell *which* resource. Indeed, 
the error from the kernel is ENOMEM, and not EAGAIN.

This makes it needlessly difficult to debug such a situation. A memory 
issue is really not expected on a hang (rather than on a crash...)

Thanks for fixing this.

Alain

Bug#841669: MAP_NORESERVE vs. ulimit (was: Re: Bug#841669: Acknowledgement (KDE fails to start on kernel 4.7.0-0.bpo.1))

[Alain Knaff]

Hi,

After using logging in in "failsafe" mode, and using strace on kde, I 
found out what was going on.

The following call now fails with ENOMEM:

mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0)

Older kernels did not enforce ulimit -d with MAP_NORESERVE (confirmed 
this on (3.13.0-100-generic), whereas new ones do:

> uname -a ; ulimit -d 64000; ./memalloc-test 6900 
Linux lll 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux
Succeeded

> uname -a ; ulimit -d 64000; ./memalloc-test 6900 
Linux hitchhiker 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19) 
x86_64 GNU/Linux
Malloc: Cannot allocate memory

I'm not sure where the bug actually is (kde or kernel), as indeed the 
case could be made that KDE should not attempt to reserve a ridiculous 
amount of memory if it never intends to use it (and it doesn't use it, 
or else it would eventually get a SIGSEV on older kernels).

Thanks,

Alain
#include 
#include 
#include 

int main(int argc, char **argv) {
	void *r=mmap(0, atoi(argv[1]),
		 PROT_READ|PROT_WRITE,
		 MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE,
		 -1,
		 0);
	
	if(r != MAP_FAILED) {
		printf("Succeeded\n");
	} else {
		perror("Malloc");
		return -1;
	}
	return 0;
}

Bug#843242: When dealing with PDF files in another application, icedove frequently crashes with message "*** buffer overflow detected ***"

[Alain Knaff]

Package: icedove
Version: 1:45.4.0-1~deb8u1

Hi,

When dealing with PDF files in another application, icedove frequently 
crashes. This happens with applications unrelated to icedove apart from
sharing the same X-window screen (i.e. the apps have *not* been launched
from icedove after clicking a link or opening an attachment, but
completely independently)

These crashes happen in the following 2 situations:
 - saving a PDF document in okular (crash happens after clicking Save 
in okular's file dialog)
 - Printing to a PDF file from Chrome (again, crash happens after 
clicking Save after having chosen the destination file for the PDF to 
be generated).

It doesn't happen always when doing these things, but sufficiently often
to be disruptive.

When it happens, icedove prints the following to stderr (example 
collected while printing to PDF from Chrome):

(icedove:11928): Gtk-CRITICAL **: IA__gtk_clipboard_set_with_data: assertion 
'targets != NULL' failed
*** buffer overflow detected ***: icedove terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x731af)[0x7f10c20971af]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f10c211caa7]
/lib/x86_64-linux-gnu/libc.so.6(+0xf6cc0)[0x7f10c211acc0]
/lib/x86_64-linux-gnu/libc.so.6(+0xf8a17)[0x7f10c211ca17]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_spawn_sync+0x19c)[0x7f10b82332ec]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_spawn_command_line_sync+0x63)[0x7f10b82339e3]
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so(_ZNK6Oxygen10QtSettings10runCommandERKSsRPc+0x19)[0x7f107f645fd9]
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so(_ZNK6Oxygen10QtSettings17kdeConfigPathListEv+0x70)[0x7f107f64a3b0]
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so(_ZN6Oxygen10QtSettings10initializeEj+0x122)[0x7f107f65cf92]
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so(_ZN6Oxygen5Style10initializeEj+0x51)[0x7f107f67b2e1]
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so(_ZN6Oxygen5Style11fileChangedEP13_GFileMonitorP6_GFileS4_17GFileMonitorEventPv+0x11)[0x7f107f67b701]
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call_unix64+0x4c)[0x7f10bad41dc0]
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call+0x2f8)[0x7f10bad41828]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_generic_va+0x2ec)[0x7f10b84c2ebc]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x10474)[0x7f10b84c2474]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x8e7)[0x7f10b84dc087]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f10b84dc9df]
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(+0x55331)[0x7f10b7609331]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x15d)[0x7f10b81ecb6d]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f48)[0x7f10b81ecf48]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7f10b81ecffc]
/usr/lib/icedove/libxul.so(+0x1f3ff7a)[0x7f10bce83f7a]
/usr/lib/icedove/libxul.so(+0x1f233fe)[0x7f10bce673fe]
/usr/lib/icedove/libxul.so(+0x1f235ae)[0x7f10bce675ae]
/usr/lib/icedove/libxul.so(+0xce1e4a)[0x7f10bbc25e4a]
/usr/lib/icedove/libxul.so(+0xcfc69d)[0x7f10bbc4069d]
/usr/lib/icedove/libxul.so(+0xedcdbe)[0x7f10bbe20dbe]
/usr/lib/icedove/libxul.so(+0xecd2b9)[0x7f10bbe112b9]
/usr/lib/icedove/libxul.so(+0x1f219be)[0x7f10bce659be]
/usr/lib/icedove/libxul.so(+0x24faf27)[0x7f10bd43ef27]
/usr/lib/icedove/libxul.so(+0x252fcba)[0x7f10bd473cba]
/usr/lib/icedove/libxul.so(+0x252ff6e)[0x7f10bd473f6e]
/usr/lib/icedove/libxul.so(XRE_main+0xd0)[0x7f10bd474189]
icedove[0x404c37]
icedove[0x4043b7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f10c2045b45]
icedove[0x4044e0]
=== Memory map: 
0040-0041d000 r-xp  08:02 533421 
/usr/lib/icedove/icedove
0061c000-0061d000 r--p 0001c000 08:02 533421 
/usr/lib/icedove/icedove
0061d000-0061e000 rw-p 0001d000 08:02 533421 
/usr/lib/icedove/icedove
7f0e78bfa000-7f0e78bfb000 ---p  00:00 0 
7f0e78bfb000-7f0e808fb000 rw-p  00:00 0 
7f0e885fc000-7f0e885fd000 ---p  00:00 0 
7f0e885fd000-7f0e902fd000 rw-p  00:00 0 
7f0e9720-7f0e97f0 rw-p  00:00 0 
7f0e97ffe000-7f0e97fff000 ---p  00:00 0 
7f0e97fff000-7f0e9fcff000 rw-p  00:00 0 
7f0ea760-7f0ea900 rw-p  00:00 0 
7f0ea90fd000-7f0ea90fe000 ---p  00:00 0 
7f0ea90fe000-7f0eb0dfe000 rw-p  00:00 0 
7f0eb0dfe000-7f0eb0dff000 ---p  00:00 0 
7f0eb0dff000-7f0eb8aff000 rw-p  00:00 0 
7f0eb8aff000-7f0eb8b0 ---p  00:00 0 
7f0eb8b0-7f0ec0d0 rw-p  00:00 0 
7f0ec0d0-7f0ec250 rw-p  00:00 0 
7f0ec25ff000-7f0ec260 ---p  00:00 0 
7f0ec260-7f0ec670 rw-p  00:00 0 
7f0ec670-7f0ed060 rw-p  00:00 0 
7f0ed300-7f0ed8a0 rw-p  00:00 0 
7f0ed8a0-7f0edeb0 

Bug#841669: Acknowledgement (KDE fails to start on kernel 4.7.0-0.bpo.1)

[Alain Knaff]

On 10/21/2016 23:51, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  unknown-pack...@qa.debian.org
> 
> If you wish to submit further information on this problem, please
> send it to 841...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

After googling around for a while I found reports of other people having
similar issues where it was related to multi screen issues.

https://bugs.kde.org/show_bug.cgi?id=367828

I do indeed have 2 screens connected.

However, neither of the 2 screens shows anything.

Moreover, only very few KDE processes are running, so it seems unlikely
that KDE is just being displayed at some non-existant 3rd phantom screen
(much more processes would be running in that case)

Regards,

Alain

Bug#841669: KDE fails to start on kernel 4.7.0-0.bpo.1

[Alain Knaff]

Package: linux-image
Version: 4.7.0-0.bpo.1

Hi,

Just upgraded my kernel from 4.6.0-1 to 4.7.0-1, and after this, KDE
failed to start. It just hung forever at start without even the progress
banner displaying.

After downgrading again to 4.6.0-1, everything was fine (but I have a
suspicion that 4.6.0 will not be patched against dirty cow disease as
4.7.0 is out).

Unfortunately, no meaningful error messages in ~/.xsession-errors

Any ideas?

Thanks,

Alain

Xsession: X session started for alain at Fri Oct 21 23:19:21 CEST 2016
localuser:alain being added to access control list
startkde: Starting up...
Connecting to deprecated signal 
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.
kbuildsycoca4 running...
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable
QThread::start: Thread creation error: Resource temporarily unavailable

Bug#841135: iso-scan/filename ignored in Debian 8.6.0 => cannot put it on multiboot USB stick

[Alain Knaff]

Package: iso-scan
Version: 1.53

Hi,

I'm trying to set up a multiboot USB stick (containing bootable Debian,
Ubuntu, Redhat, etc. distributions on one media)

For this, I am following the instructions at
https://wiki.archlinux.org/index.php/Multiboot_USB_drive#Debian

However, despite all attempts to the contrary, iso-scan seems to
steadfastly ignore the iso-scan/filename parameter: it neither takes it
at face value (as the sole qualifying filename for an ISO), nor does it
prompt the user if multiple ISOs are on the stick.

With the result that it tries to install from an Ubuntu ISO that also
happens to be on the stick, and (predictably) fails.

However, modifying the /var/lib/dpkg/info/iso-scan.postinst script as
follows fixes the issue:

Before the "for dir in . ./*; do" loop, insert:

db_get iso-scan/filename
if [ -f "./$RET" ] ; then
iso=`echo "$RET" | sed 's;^/;;'`
log "Found ISO $iso on $dev"
ISO_COUNT=$(($ISO_COUNT + 1))
add_usable_iso $iso $dev
else

... and after it, insert:
fi


I'm also wondering why in Debian we have to download a special hd-media
initrd.gz from
https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/
at all, rather than having the standard initrd.gz included in the ISO
itself be able to also boot from an USB stick (as is the case in Ubuntu,
and in many other distros)

Thanks for your attention,

Alain

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

On 15/12/09 15:59, ael wrote:
 For what it is worth, here are the results from my debian testing box
 under 2.6.32_exact-55846-gf405425
 
 $ lsmod |grep floppy
 floppy 45327  0
 
 # setfdprm /dev/fd0 HD
 # fdformat /dev/fd0
 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.
 Formatting ... done
 Verifying ...
 Read: : Input/output error
 Problem reading cylinder 0, expected 18432, read -1
 
 # floppycontrol --resetnow 0
 # fdrawcmd recalibrate 0
 0: 20
 1: 0
 no disk change
 
 # fdrawcmd seek 0 1
 0: 20
 1: 1
 no disk change
 
 # fdrawcmd readid 0 repeat=18
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 6
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: a
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: b
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: d
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: e
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: f
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 11
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 12
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 1
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 2
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 3
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 4
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 6
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 7
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 8
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: 9
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: a
 6: 2
 no disk change
 
 0: 0
 1: 0
 2: 0
 3: 1
 4: 0
 5: c
 6: 2
 no disk change
 
 ael

This does indeed look like a different problem to me... No sector with a
bad track id, but lots of sectors skipped. But these skips look more
like they are happening during read (rather than being really missed), as
on the second pass, they are present.

Could you try the same with a higher repetition count:

fdrawcmd readid 0 repeat=40

Just to make sure that eventually all sectors show up

Also, on your case, the actual read error seems to be on track 0. Could you
give me also the headers of track 0?

Thanks,

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

ael wrote:
 Mark Hounschell wrote:
 On 12/15/2009 10:08 AM, Alain Knaff wrote:
 
 I mentioned I had multiple machines with this problem. Some running
 different versions of SuSE. Mainly 11.0, which is where all the info
 I've provided came from thus far. This machine also has a SuSE-11.2
 disk on it. When I do all this using SuSE-11.2 my results look more
 like ael's.

 So I think when the cause is found, it will be a single cause.
 
 Uninitialised variable? gcc version bugs?

In any case, something very veird must be going on.

Thhis is the loop that initializes the track headers, everything except
for the sector numbers:

for (count = 0; count  F_SECT_PER_TRACK; ++count) {
here[count].track = format_req.track;
here[count].head = format_req.head;
here[count].sect = 0;
here[count].size = F_SIZECODE;
}

The unitialized sector is always the first one of the track (not
necessarily the lowest numbered, because of skew...). Other fields (most
notably head) are initialized correctly, and only track seems to have
the value from the previous call.

Weird.

If you suspect a compiler bug, it might be interesting to compile a
kernel on one box, but run it on the other, just to see whether anything
interesting happens...


 I know that doesn't really help in tracking things down... :-(
 
 About to run with repeat=40. I have only just downloaded the data sheet
 and have only skimmed small portions, so I have some catching up to do...
 
 ael

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*? repeat=40

[Alain Knaff]

ael wrote:
 Alain Knaff wrote:
   Could you try the same with a higher repetition count:
 
 On same floppy (medium)  as before:
[...]

All sector ids seem to be present (although occasionally they are
skipped during read...), and track is correct everywhere... but if I
remember correctly, you got the error on track 0. So it might be
interesting to the headers of track 0 rather than 1.

Regards,

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

ael wrote:
 
 Is that what you wanted?
 
 ael

Yes. All sectors are there, ... so I wonder why you are getting errors.


So, next round of tests: trying to read these sectors:

fdrawcmd recalibrate 0
fdrawcmd read 0  0 0 1 2 18 1 1  length=18432 /dev/null


Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

A.E.Lawrence wrote:
 Alain Knaff wrote:
 ael wrote:
 Is that what you wanted?

 ael
 Yes. All sectors are there, ... so I wonder why you are getting errors.


 So, next round of tests: trying to read these sectors:

 fdrawcmd recalibrate 0
 fdrawcmd read 0  0 0 1 2 18 1 1  length=18432 /dev/null
 
 
 # fdrawcmd recalibrate 0
 0: 20
 1: 0
 no disk change
 
 # fdrawcmd read 0  0 0 1 2 18 1 1  length=18432 /dev/null
 remaining= 17920
 0: 40
 1: 20
 2: 20
 3: 0
 4: 0
 5: 1
 6: 2
 no disk change
 

A CRC error both in the header (1: 20) and in the data of the sector (2: 20)

It begins to look more and more like a hardware problem, at least in
your case...

Now it might be interesting to check it for all sectors separately.

fdrawcmd read 0  0 0  1 2 18 1 1  length=512 /dev/null
fdrawcmd read 0  0 0  2 2 18 1 1  length=512 /dev/null
fdrawcmd read 0  0 0  3 2 18 1 1  length=512 /dev/null
...
fdrawcmd read 0  0 0 18 2 18 1 1  length=512 /dev/null
fdrawcmd read 4  0 1  1 2 18 1 1  length=512 /dev/null
fdrawcmd read 4  0 1  2 2 18 1 1  length=512 /dev/null
...
fdrawcmd read 4  0 1 18 2 18 1 1  length=512 /dev/null


Which ones succeed, which ones fail...

Alain




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

ael wrote:
 A.E.Lawrence wrote:
 # fdrawcmd read 0  0 0 1 2 18 1 1  length=18432 /dev/null
 remaining= 17920
 0: 40   == So this is Abnormal termination?
 1: 20   == CRC error? (id or data)
 2: 20   == CRC error? (data)
 
 Did I decode them correctly?
 
 ael

Yes, that's correct.

Alain




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

On 14/12/09 12:27, ael wrote:
 # getfdprm -o /dev/fd0u1440
 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
 
 # fdrawcmd drive=/dev/fd0u1440 readid 0 repeat=18
 raw cmd: Invalid argument

... and if you try with /dev/fd0 instead?

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

On 14/12/09 15:58, ael wrote:
 Any point in running under strace?

Yes, this would be useful, especially for analyzing the Invalid argument
issue.

Regards,

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: [Fdutils] Cannot format floppies under kernel 2.6.*?

[Alain Knaff]

On 14/12/09 16:24, ael wrote:
 Alain Knaff wrote:
 On 14/12/09 15:58, ael wrote:
 Any point in running under strace?

 Yes, this would be useful, especially for analyzing the Invalid
 argument
 issue.
 
 Looks as if that was something to do with my command line.  Below is the
 strace giving the IO error which probably isn't much help :-)


 
  # strace fdrawcmd readid 0 repeat=18 21 |tee fdrawcmd.dump|less
[...]
 ioctl(3, FDRAWCMD, 0xbf8ce620)  = -1 EIO (Input/output error)

Well, at least we now that it is indeed the rawcmd ioctl that gets the
error (rather than some other system call), and this is interesting
information.

Could you also check whether anything interesting got output by the kernel
(dmesg) during the fdrawcmd attempt?

Thanks,

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: floppy: fdformat fails completely with current kernel

[Alain Knaff]

On 14/10/09 05:27, Aníbal Monsalve Salazar wrote:
 Sending this bug report to alain @ linux.lu
 
 You can see the discussion about this bug at:
 
 http://bugs.debian.org/548434

I tested both fdformat and superformat (from fdutils 5.5-20060227-3, and
then also from 20081027)  with kernel 2.6.32-rc6 and  on Kubuntu 9.04, and
both worked fine. Could it be a bad drive or a bad disk?

Regards,

Alain



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: ftutils so util-linux?

[Alain Knaff]

On 10/11/09 17:42, ael wrote:
 I tried setting the density to dd instead of hd -- something that I
 had also tried on fdformat without success. gfloppy managed to 

This is indeed very useful information, sorry to have not spotted this
earlier. Double density disks cannot be formatted as high density. Not only
because of the higher surface quality of HD disks, but more importantly
because the presence or not of the density select hole switches the _drive_
into the appropriate mode.

Software switches the FDC (which is on the motherboard) into the correct
mode, whereas the hole switches the drive itself into the correct mode.
Unfortunately, there is no communication about density between drive and

If both disagree, formatting will fail.

For most DD disks, surface quality should be good enough for HD (at least
when new...), but (normally...) you do need to drill that extra hole.
Computer magazines from the period of DD disks were full of articles
suggesting to do this... :-)

Now, if your disk _does_ have a HD hole (do not confuse this with the
write-protect hole), maybe the LED sensing this hole in your drive is
broken, and it wrongly considers every disk as DD?

 verify to around track 73.

This now is probably due to poor quality of disk (maybe due to age?). It's
mostly the higher tracks that fail, because on them the spatial density is
highest (these are the innermost tracks, thus shorter, but they still
contain the same amount of data = more bits crammed into less surface).

 I tried installing a dos filesystem despite
 the verification errors, and it seemed to work.

Yes, because most metadata is stored at the beginning of the disk. So
directory, etc will display fine. Files are also stored starting from the
beginning, so you won't see problems unless you make the disk almost full.

 I then tried fdformat, having used setfdprm to set hd. This time it worked
 and passed verification. Badblocks also ran without error.

really weird Normally, for a given disk, only one of hd or dd should
work (depending on the presence of the density select hole). Unless some
drives use different criteria to switch between HD and DD.

 I am not sure what to make of all of this, but I wonder if my initial
 attempts to format with fdformat without checking that the density was
 set to hd may have written some dense data to the floppy (well, several
 floppies) which caused problems later.
 
 Whatever the case, it does suggest that the problem may be with fdformat
 with is in util-linux rather than fdutils. So perhaps this report should
 be re-assigned?
 
 ael

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#548434: ftutils so util-linux?

[Alain Knaff]

On 03/12/09 16:28, ael wrote:
 
 I tested both fdformat and superformat (from fdutils 5.5-20060227-3,
 and then also from 20081027)  with kernel 2.6.32-rc6 and  on Kubuntu
 9.04, and both worked fine. Could it be a bad drive or a bad disk?
 
 No. I have used several known good discs and on several (4 actually)
 machines with known good drives. And I can format the same discs on an
 old redhat machine. So I am convinced that it isn't hardware: media or
 drive. Also I can read and write onto previously formatted discs (with
 file systems), so again that make drive problems unlikely.
 
 I said (but forgot later) in one of my first reports that a member of my
 local LUG had tested on Gentoo and had no problems with the same kernel.
 
 It seems to be something specific to Debian which is extremely odd,
 given you have tested on ubuntu.
 
 ael

This is indeed odd. If I'll find time next week, I'll set up my machine
with the floppy drive with Debian testing...

Btw, did you get around to check the /etc/driveprm (or
/usr/local/etc/driveprm file) to make sure nothing fishy is in there?

Regards,

Alain



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org