Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Vincent Lefevre]

On 2024-03-06 06:29:24 +0100, Jonas Smedegaard wrote:
> Quoting Arnaud Rebillout (2024-03-06 02:26:00)
> > However it's true that some packages are installed before that, at the 
> > debootstrap stage, and I guess debootstrap doesn't honor "Recommends:"?
> 
> Correct.  This is tracked as bug#742977

Bug#742977 is about whether to mark installed packages as
auto-installed or not. It is not about Recommends.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Policy: should libraries depend on services (daemons) that they can speak to?

[Vincent Lefevre]

On 2024-01-15 11:15:32 -0500, Theodore Ts'o wrote:
> For example, when I implemented libuuid, if you want to create a huge
> number of UUID's very quickly, because you're a large enterprise
> resource planning application, the the uuidd daemon will allow
> multiple processes to request "chunks" of UUID space, and create
> unique UUID's without having to having to go through some kind of
> locking protocol using a single shared state file.
> 
> So libuuid works just fine without uuidd, but if you are populating a
> large ERP system, then you very much will want uuidd to be installed.
> So in that case, you can make the dependency relationship be either
> suggests or recommends, instead of a hard dependency.

Except that in Debian, this is a "Recommends:", and "Recommends:"
are normally installed by default... except by the Debian installer!
This is inconsistent.

So, in the present case, uuid-runtime wasn't installed by default,
though libuuid1 was installed and had a "Recommends: uuid-runtime".

But with the 64-bit time_t transition, libuuid1 got replaced by
libuuid1t64 a few days ago, which pulled uuid-runtime.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: On merging bin and sbin

[Vincent Lefevre]

On 2024-02-28 12:25:13 +0100, Ansgar  wrote:
> I totally agree: we should aim at moving all service binaries such as
> daemons which are not directly invoked by users out of PATH to
> /usr/lib{,exec} or similar to make shell completion more helpful.

I disagree. The goal should not be to make shell completion
more helpful. The main issue about shell completion is that
most executables in /usr/bin will never be used from the shell
(so, in any case, something else needs to be done), while if
you move some binaries out of PATH, you could break existing
scripts (some of them written by the end user / admin).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

possible issues with downgrading and *.md5sums (was: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems)

[Vincent Lefevre]

[to debian-devel only]

On 2024-03-01 10:13:18 +0100, Helmut Grohne wrote:
> On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote:
> > Well, officially downgrading isn't supported (although it typically works)
> > *and* losing files is one of the problems of our merged-/usr solution (see
> > [1]). I *suspect* this might be the cause. We're working hard (well, helmut
> > is) to protect us and our users from loosing files on upgrades. We don't
> > protect against downgrades.
> 
> As much as we like blaming all lost files on the /usr-move, this is not
> one them. If you are downgrading from to a package that formerly has
> been replaced, you always have lost files and you always had to
> reinstall the package.

In the past, when I asked why downgrading wasn't supported, i.e. the
possible issues with downgrading, I was answered something about the
files handled by maintainer scripts, which is fairly understandable
(BTW, this is mentioned at [1], with an example). But no documented
issues with the files directly provided by the packages, like library
files (from what I could see about the complaints). Indeed, I thought
that the presence of /var/lib/dpkg/info/*.md5sums would be sufficient
to detect issues. So, what's the point of these files?

[1] https://wiki.debian.org/MaintainerScripts

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 16:30:25 -0800, Russ Allbery wrote:
> I was only able to find this discussion of why pkexec checks $SHELL, and
> it doesn't support my assumption that it was an intentional security
> measure, so I may well be wrong in that part of my analysis.  Apologies
> for that; I clearly should have done more research.  git blame points to a
> commit that only references this thread:
> 
> https://lists.freedesktop.org/archives/polkit-devel/2009-December/000282.html
> 
> which seems to imply that this was done to match sudo behavior and because
> the author believed this was the right way to validate the SHELL setting.

This is the kind of information that should have been put as a comment
in the source code. But the pkexec code seems to be buggy because sudo
does *not* check that the $SHELL value is in /etc/shells?

In the sudo(8) man page:

  -s, --shell
 Run the shell specified by the SHELL environment variable if it
 is set or the shell specified by the invoking  user's  password
 database entry. [...]
[...]
  SHELLUsed to determine shell to run with -s option.

and there is no mention of /etc/shells.

/etc/shells is mentioned in sudoers(5):

  runas_check_shell
If enabled, sudo will only run  commands  as  a  user
whose  shell appears in the /etc/shells file, even if
the invoking user's Runas_List would otherwise permit
it. [...]

So this concerns the login shell of the target user, not the $SHELL
value. This is confirmed by the sudo source:

/*
 * Returns true if the user's shell is considered to be valid.
 */
bool
user_shell_valid(const struct passwd *pw)
{
debug_decl(user_shell_valid, SUDOERS_DEBUG_NSS);

if (!def_runas_check_shell)
debug_return_bool(true);

debug_return_bool(valid_shell(pw->pw_shell));
}

where valid_shell() does

while ((entry = CALL(getusershell)()) != NULL) {
if (strcmp(entry, shell) == 0)
debug_return_bool(true);
}

But chsh will set the login shell to a pathname from /etc/shells,
so that there are no issues with aliases pathnames in this case.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 16:17:58 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
> 
> >> and pkexec is essentially a type of sudo and should be unavailable to
> >> anyone who is using a restricted shell.
> 
> > The pkexec source doesn't say that the goal is to check whether
> > the user is in a restricted shell.
> 
> So far as I am aware, the only purpose served by /etc/shells historically
> and currently is to (a) prevent users from shooting themselves in the foot
> by using chsh to change their shell to something that isn't a shell, and
> (b) detect users who are not "normal users" and therefore should have
> restricted access to system services.  See shells(5), for example:
> 
> Be aware that there are programs which consult this file to find out
> if a user is a normal user; for example, FTP daemons traditionally
> disallow access to users with shells not included in this file.

But note that checking the login shell of the user in /etc/shells
(which seems OK for me) is different from checking the value of
$SHELL.

> > Also note than even in a restricted shell, the user may set $SHELL to a
> > non-restricted shell.
> 
> This is generally not the case; see, for example, rbash(1):
> 
> It behaves identically to bash with the exception that the following
> are disallowed or not performed:
> 
> [...]
> 
> * setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or
>   BASH_ENV

Well, SHELL is read-only. But a restricted shell can be started
with a $SHELL value that doesn't point to a restricted shell:

$ echo $SHELL
/bin/sh
$ rbash -l
vinc17@qaa:~$ echo $SHELL
/bin/sh

So, making decisions based on the $SHELL value is prone to
security issues, and I think that it would be better to look
at the login shell in /etc/shells.

> > Moreover, /etc/shells also contains restricted shells.
> 
> That definitely should not be the case and any restricted shell that adds
> itself to /etc/shells is buggy.  See chsh(1):
> 
> The only restriction placed on the login shell is that the command
> name must be listed in /etc/shells, unless the invoker is the
> superuser, and then any value may be added. An account with a
> restricted login shell may not change her login shell. For this
> reason, placing /bin/rsh in /etc/shells is discouraged since
> accidentally changing to a restricted shell would prevent the user
> from ever changing her login shell back to its original value.

On my machine, both rbash and rksh93 are in /etc/shells.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
> Thorsten Glaser  writes:
> 
> > Right… and why does pkexec check against /etc/shells?
> 
> pkexec checks against /etc/shells because this is the traditional way to
> determine whether the user is in a restricted shell,

Could you explain? This seems an orthogonal problem.

> and pkexec is essentially a type of sudo and should be unavailable
> to anyone who is using a restricted shell.

The pkexec source doesn't say that the goal is to check whether
the user is in a restricted shell. Also note than even in a
restricted shell, the user may set $SHELL to a non-restricted
shell. Moreover, /etc/shells also contains restricted shells.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 17:18:43 +, Thorsten Glaser wrote:
> Russ Allbery dixit:
> 
> >3. Something else that I don't yet understand happened that caused pkexec
> >   to detect the shell as /usr/bin/mksh instead of /bin/mksh.  I'm not
> 
> What sets $SHELL for the reporter’s case? Fix that instead.

$SHELL is meant to be set by the user. To set $SHELL to the
current shell, for instance, the result with mksh:

$ SHELL=$(readlink /proc/$$/exe)
$ echo $SHELL
/usr/bin/mksh

And I suppose that /usr/bin/mksh comes from the "real path".

> login(1) sets it to the path from passwd(5), which hopefully
> is from shells(5).

login(1) is not the only way to start a shell.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 09:00:57 -0800, Russ Allbery wrote:
> I think the obvious solution is to ensure that both the /bin and /usr/bin
> paths for mksh are registered in /etc/shells.  In other words, I think we
> have a missing usrmerge-related transition here that we should just fix.
> I'm copying Thorsten on this message in case he hasn't noticed this
> thread, but if I were you I'd just file a bug against mksh asking for the
> /usr/bin paths to also be added to /etc/shells to match the new behavior
> of add-shell.

I had reported a bug:

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

but Thorsten closed it because

|The OP’s $SHELL should not be set to /usr/bin/bash as that
|value is not in /etc/shells and not its canonical path in
|the first place.

(The issue was initially detected with bash, which gave bug 817168.)

But having a requirement on what pathnames $SHELL may contain (in the
case a same shell can be referenced by several pathnames, e.g. due to
the /bin -> /usr/bin symbolic link) is not acceptable. Hence my post
about this.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 16:59:28 +, Holger Levsen wrote:
> On Thu, Feb 15, 2024 at 10:08:11AM +0100, Vincent Lefevre wrote:
> > Not for mksh.
>  
> so the subject should be "mksh is broken with usrmerge"?

No, because my bug report about mksh was closed because it is
not regarded as a bug in mksh.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-15 09:39:51 +0100, Marc Haber wrote:
> On Thu, 15 Feb 2024 00:05:36 +0100, Vincent Lefevre
>  wrote:
> >This is invalid. See
> >
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817168
> 
> That doesnt answer the question asked, it is a bug from 2016 that was
> fixed since then, and I am one of those who fails to see the
> connection between the subject of this thread and the nebulous claims
> you make in the messages AND obviously refuse to explain your
> reasoning if asked.

There's no indication that the bug in pkexec has been fixed.
Bug 817168 just implemented a workaround in add-shell, which
is not used by mksh.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 17:16:23 -0800, Russ Allbery wrote:
> I have literally no idea what you're talking about.  It would be really
> helpful if you would describe what program rejected your setting and what
> you expected to happen instead.

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

| with usrmerge, some programs - such as pkexec, or LEAP's bitmask
| on top of that- fails to run. Specifically, the error I get is:
|
| The value for the SHELL variable was not found the /etc/shells file

> You mentioned /etc/shells in your previous message, but /etc/shells on my
> system contains both the /usr/bin and the /bin paths, so I'm still at a
> complete loss.

Not for mksh.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 10:41:44 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> 
> > POSIX says:
> 
> >   SHELL   This variable shall represent a pathname of the user's
> >   preferred command language interpreter. If this interpreter
> >   does not conform to the Shell Command Language in XCU
> >   Chapter 2 (on page 2345), utilities may behave differently
> >   from those described in POSIX.1-2017.
> 
> > There is no requirement to match one of the /etc/shells pathnames.
> > The user or scripts should be free to use any arbitrary pathname to
> > the command language interpreter available on the system, and Debian
> > should ensure that this is allowed, in particular the one give by
> > the realpath command.
> 
> I'm sorry, this is probably a really obvious question, but could you
> explain the connection between the subject of your mail message and the
> body of your mail message?  I can't see any relationship, so I guess I
> need it spelled out for me in small words.
> 
> (I believe /etc/shells enforcement is done via PAM or in specific
> programs that impose this as an additional non-POSIX restriction.  This is
> outside the scope of POSIX.)

What's the point of having a standard if programs are allowed to
reject user settings for arbitrary and undocumented reasons?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: usrmerge breaks POSIX

[Vincent Lefevre]

On 2024-02-14 19:46:58 +0100, Ansgar  wrote:
> Hi Vincent,
> 
> On Wed, 2024-02-14 at 18:20 +0100, Vincent Lefevre wrote:
> > POSIX says:
> > 
> >   SHELL   This variable shall represent a pathname of the user's
> >   preferred command language interpreter. If this interpreter
> >   does not conform to the Shell Command Language in XCU
> >   Chapter 2 (on page 2345), utilities may behave differently
> >   from those described in POSIX.1-2017.
> > 
> > There is no requirement to match one of the /etc/shells pathnames.
> 
> I have hopefully good news for you! You can set the SHELL variable
> yourself to your preferred value. For example:
> 
> export SHELL=/home/user/.bin/the-best-shell-of-all
> 
> (The details might vary depending on the shell you are currently in.)
> usrmerge does not affect this at all.

This is invalid. See

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

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

usrmerge breaks POSIX

[Vincent Lefevre]

POSIX says:

  SHELL   This variable shall represent a pathname of the user's
  preferred command language interpreter. If this interpreter
  does not conform to the Shell Command Language in XCU
  Chapter 2 (on page 2345), utilities may behave differently
  from those described in POSIX.1-2017.

There is no requirement to match one of the /etc/shells pathnames.
The user or scripts should be free to use any arbitrary pathname to
the command language interpreter available on the system, and Debian
should ensure that this is allowed, in particular the one give by
the realpath command.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

mutt removed from testing while the bug was closed (fixed)

[Vincent Lefevre]

Hi,

I've seen on https://tracker.debian.org/pkg/mutt that mutt was
removed from testing on 2023-10-25, with a link to

  https://tracker.debian.org/news/1473564/mutt-removed-from-testing/

which says:

--
FYI: The status of the mutt source package
in Debian's testing distribution has changed.

  Previous version: 2.2.12-0.1
  Current version:  (not in testing)
  Hint: 
# 1051563
--

but on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563
I can see that the bug was closed on 2023-09-12:

From: Debian FTP Masters 
To: 1051563-cl...@bugs.debian.org
Subject: Bug#1051563: fixed in mutt 2.2.12-0.1
Date: Sun, 10 Sep 2023 11:12:35 +
[...]
Format: 1.8
Date: Sun, 10 Sep 2023 12:21:34 +0200
Source: mutt
Architecture: source
Version: 2.2.12-0.1
Distribution: unstable
Urgency: medium
Maintainer: Mutt maintainers 
Changed-By: Sebastian Andrzej Siewior 
Closes: 1051563
Changes:
 mutt (2.2.12-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New upstream release (Closes: #1051563).
 - CVE-2023-4874 ("Null pointer dereference when viewing a specially
   crafted email).
 - CVE-2023-4875 ("Null pointer dereference when composing from a specially
   crafted draft message").
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: mutt removed from testing while the bug was closed (fixed)

[Vincent Lefevre]

On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote:
> Hi,
> 
> I've seen on https://tracker.debian.org/pkg/mutt that mutt was
> removed from testing on 2023-10-25, with a link to
> 
>   https://tracker.debian.org/news/1473564/mutt-removed-from-testing/
> 
> which says:
> 
> --
> FYI: The status of the mutt source package
> in Debian's testing distribution has changed.
> 
>   Previous version: 2.2.12-0.1
>   Current version:  (not in testing)
>   Hint: <https://release.debian.org/britney/hints/auto-removals>
> # 1051563
> --
> 
> but on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563
> I can see that the bug was closed on 2023-09-12:

Actually on 2023-09-10. That's

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#20

> From: Debian FTP Masters 
> To: 1051563-cl...@bugs.debian.org
> Subject: Bug#1051563: fixed in mutt 2.2.12-0.1
> Date: Sun, 10 Sep 2023 11:12:35 +
> [...]
> Format: 1.8
> Date: Sun, 10 Sep 2023 12:21:34 +0200
> Source: mutt
> Architecture: source
> Version: 2.2.12-0.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Mutt maintainers 
> Changed-By: Sebastian Andrzej Siewior 
> Closes: 1051563
> Changes:
>  mutt (2.2.12-0.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* New upstream release (Closes: #1051563).
>  - CVE-2023-4874 ("Null pointer dereference when viewing a specially
>crafted email).
>  - CVE-2023-4875 ("Null pointer dereference when composing from a 
> specially
>crafted draft message").
> [...]

Hmm... This seems to be due to a bug in the BTS when the bug was
reopened for stable. At

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#25

"Bug reopened Request was from Antonio Radici  to 
cont...@bugs.debian.org. (Sun, 10 Sep 2023 11:36:03 GMT) (full text, mbox, 
link).

No longer marked as fixed in versions mutt/2.2.12-0.1."

But both

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563;msg=32
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563;msg=34

just show "reopen 1051563".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potential MBF: packages failing to build twice in a row

[Vincent Lefevre]

On 2023-08-15 09:38:32 +0200, Lucas Nussbaum wrote:
> On 15/08/23 at 01:29 -0400, Michael Stone wrote:
> > we don't know, since the test was "regenerate source"--a thing very few
> > people care about--rather than "build twice" which is the thing people do
> > seem to care about. It seems likely that the difference is thousands of
> > packages.
> > 
> > I'm somewhat concerned we magically went from "should we do an MBF" to "I
> > just did an MBF" without any real consensus in the middle. This being so
> > painfully obvious that the MBF itself basically says there's no consensus.
> 
> I agree that the distinction between "fails to build source after
> successful build" and "fails to build binary packages after successful
> build" is useful. My initial test covered both, but I separated both
> issues later on to provide more specific bug reports, so the MBF only
> covered the first case. I also plan to do a MBF for "fails to build
> binary packages after successful build" (there are about 700 packages
> failing this).

Note that if the source has been modified, it may be possible that
the second build succeeds but is incorrect. I suppose that you need
to check that both builds are identical.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potential MBF: packages failing to build twice in a row

[Vincent Lefevre]

On 2023-08-13 16:32:03 -0500, John Goerzen wrote:
> - Upstream wants to ship things that may get modified during build.  Ie,
>   autoconf/automake replaces files they ship because they want it to
>   work "out of the box" in some fashion.  Another example is
>   documentation; upstream may ship built docs even though we rebuild it
>   for completeness.

Yes, the GNU Coding Standards even say:

  GNU distributions usually contain some files which are not
  source files—for example, Info files, and the output from
  Autoconf, Automake, Bison or Flex.

For mpfr4, the test is failing just because the makeinfo version
is now newer in Debian:

--- mpfr4-4.2.0.orig/doc/mpfr.info
+++ mpfr4-4.2.0/doc/mpfr.info
@@ -1,4 +1,4 @@
-This is mpfr.info, produced by makeinfo version 6.8 from mpfr.texi.
+This is mpfr.info, produced by makeinfo version 7.0.3 from mpfr.texi.
 This manual documents how to install and use the Multiple Precision
 Floating-Point Reliable Library, version 4.2.0.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

nvidia-graphics-drivers-legacy-390xx uploaded 8 days ago but not yet installed

[Vincent Lefevre]

Hi,

Bug 1042892 in nvidia-legacy-390xx-kernel-dkms was fixed on 2 August,
and the packages for amd64 and i386 were built 8 days ago, but they
are still in the "Uploaded" state (contrary to armhf):

https://buildd.debian.org/status/package.php?p=nvidia-graphics-drivers-legacy-390xx

What happens?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[Vincent Lefevre]

On 2022-10-14 12:44:25 +0200, Marco d'Itri wrote:
> On Oct 14, Vincent Lefevre  wrote:
> > > This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to 
> > > recommend awful things in the past.
> > But it is still considered in the present times by the dpkg developers.
> > Bug 923423 was closed several hours ago based on this dpkg FAQ:
> This is obviously convenient on Guillem's part, but we have to optimize 
> systems by default for the general case and not just for dpkg -i.

This dpkg FAQ says that this is not beneficial for just dpkg,
but also "for any application in the system".

> > (the issue here is that there is a fsync for *every* file, so that for
> And at this point I am wondering if this is a good design, or if it 
> would be better to use a different strategy.

IMHO, this should time based or perhaps the strategy could depend
on the package being installed (critical packages like libc6 could
use fsync for every file, but all these intermediate fsync's are
useless for packages that can simply be reinstalled in case of
crash or hardware related failure).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[Vincent Lefevre]

On 2022-10-14 11:59:09 +0200, Marco d'Itri wrote:
> On Oct 14, Vincent Lefevre  wrote:
> 
> > The /etc/fstab file is created using by default ext4 with just
> > the errors=remount-ro option. However, the Debian FAQ recommends
> > the nodelalloc mount option to avoid performance degradation and
> > preserve data safety:
> This is not "the Debian FAQ" but "the DPKG FAQ", which has been known to 
> recommend awful things in the past.

But it is still considered in the present times by the dpkg developers.
Bug 923423 was closed several hours ago based on this dpkg FAQ:


All these fsync()s you see in rapid succession are used as a
synchronization points, way after the data has been requested to be
synced to disk asynchronously via sync_file_range().

What this is trying to achieve is durability, so that dpkg can know
the data is on the disk, so that it can mark the package as installed.

This is explained on the dpkg FAQ:

  
<https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slow_when_using_new_filesystems_such_as_btrfs_or_ext4.3F>


(the issue here is that there is a fsync for *every* file, so that for
a package with many small files, such as texlive-fonts-extra, which
currently has more than 92000 files, this can be awfully slow).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[Vincent Lefevre]

Package: general
Severity: normal

The /etc/fstab file is created using by default ext4 with just
the errors=remount-ro option. However, the Debian FAQ recommends
the nodelalloc mount option to avoid performance degradation and
preserve data safety:

https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slow_when_using_new_filesystems_such_as_btrfs_or_ext4.3F

  For ext4, use instead the "nodelalloc" mount option, which should
  fix both the performance degradation and the data safety issues,
  and not for just dpkg, but for any application in the system.

So this option should be used by default for btrfs and ext4.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Lefevre]

On 2022-09-08 17:58:25 +0200, Dylan Aïssi wrote:
> We cannot talk about PipeWire without mentioning its session manager.
> Thus, this change should go along the switch of the default session manager,
> i.e. from the deprecated pipewire-media-session to WirePlumber.
> We still use pipewire-media-session as default session manager because it
> enables PipeWire *only* for screen-sharing and not for managing audio.
> Whereas WirePlumber always configures PipeWire for audio excepted by modifying
> conf files in a non-compatible packaging way. This issues was also hit on
> the Arch Linux side [4]. This WirePlumber behavior may be solved in the next
> major release 0.5 planned later this year.

In the case WirePlumber is used, what is the status of bug 998073?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998073
  wireplumber: fails to automatically switch to headphones when connected

(which is an issue for those who use both speakers and headphones
and want to automatically switch between them). The upstream bug

  https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/267

is still open and users are still reporting problems. There is no such
issue with PA.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: transition announcement: gsfonts + gsfonts-x11 -> fonts-urw-base35

[Vincent Lefevre]

Hi,

On 2022-08-28 16:55:04 +0200, Fabian Greffrath wrote:
[...]
> A preliminary package fonts-urw-base35_20200910-3 to enable the
> transition can be found in experimental, So, in case anyone want to
> check how the transition works out, any help will be appreciated [5].
[...]
> PS: Please keep me in CC, I am not subscribed to d-devel.

As this is now in unstable, shouldn't bugs be reported to packages
that recommend gsfonts or gsfonts-x11 so that they change them to
fonts-urw-base35? Otherwise one cannot remove gsfonts and gsfonts-x11
without a complaint, such as

  --\ Leave the following recommendations unresolved:
libmagickcore-6.q16-6 recommends gsfonts
xpdf recommends gsfonts-x11
xscreensaver recommends gsfonts-x11 | xfonts-100dpi

from aptitude.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-31 14:55:44 +0500, Andrey Rahmatullin wrote:
> On Tue, May 31, 2022 at 11:43:06AM +0200, Vincent Lefevre wrote:
> > Indeed, this is what happened with pipewire 0.3.39-1, as I can see
> > in my dpkg logs and the changelog:
> > 
> >   * Change priority order between pipewire-media-session and wireplumber,
> >   WirePlumber is now the recommended session manager.
> > 
> > and this is what led to the pipewire-pulse installation.
> So "pipewire-media-session was installed" is indeed irrelevant.

No, because pipewire-pulse got removed a bit later. This was in
October 2021. Since then, pipewire-pulse was no longer installed.
But Dylan Aïssi said:

| Indeed, but pipewire service doesn't take control of audio over
| pulseaudio. Only pipewire-pulse does that.
| So, if you don't want to use pipewire for audio, then don't install
| pipewire-pulse and that's it.

So there's something contradictory. If the pipewire service alone
doesn't take control of audio over pulseaudio, then the only culprit
would be pipewire-media-session. Or what? A bug in pipewire, which
would actually take control of audio even without pipewire-pulse?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-31 11:43:06 +0200, Vincent Lefevre wrote:
> Anyway, when I upgraded the vlc package two weeks ago, this had the
> effect that PulseAudio was no longer used as the sound server (for
> both vlc and ogg123), though pipewire was already installed (due to
> a Recommends from libpipewire-0.3-0, itself due to a Depends from
> xdg-desktop-portal). The only new package was vlc-plugin-pipewire,
> due to
> 
>   * debian/control: Recommend vlc-plugin-pipewire
> 
> pipewire-pulse was not installed.

A clarification about this point: Concerning ogg123, it was actually
using the ALSA device (I had default_driver=alsa in /etc/libao.conf),
and before the vlc upgrade, this was automatically forwarding the
stream to PulseAudio (something like that, I don't know the internals).
It is only after the upgrade of the vlc package[*] that things got
really broken with ogg123 too.

[*] I also used VLC after the upgrade, and I suspect that this had
the effect to change something in the configuration, as neither vlc
nor ogg123 was using PulseAudio any longer, as seen in pavucontrol.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-31 14:04:18 +0500, Andrey Rahmatullin wrote:
> On Tue, May 31, 2022 at 10:55:55AM +0200, Vincent Lefevre wrote:
> > > >  a) pipewire package enables pipewire service by default
> > > 
> > > Indeed, but pipewire service doesn't take control of audio over
> > > pulseaudio. Only pipewire-pulse does that.
> > 
> > This is incorrect. The pipewire-pulse package was not installed
> > at all (pipewire-pulse had been installed automatically in
> > October 2021 due to dependencies, but the change was reverted,
> > and the package got removed on my machine 3 days later).

Sorry. Actually it got removed because I downgraded the pipewire
packages back to the previous version (it's clearer with the
/var/log/apt/term.log* log files).

> > I don't know whether this could cause the issue, but
> > pipewire-media-session was installed, because pipewire-bin
> > recommends it. There were already issues with it in the past:
> What issues?

The ones mentioned below ("Closes: ...").

> > https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
> > which says:
> > 
> >* Remove pipewire-media-session from Recommends.
> >(Closes: #995116, #996994, #997859)
> The context of this was "replace pipewire-media-session with wireplumber"

Indeed, this is what happened with pipewire 0.3.39-1, as I can see
in my dpkg logs and the changelog:

  * Change priority order between pipewire-media-session and wireplumber,
  WirePlumber is now the recommended session manager.

and this is what led to the pipewire-pulse installation.

> and it was rolled back in the next upload as you can see in d/changelog.

More precisely, pipewire-media-session was removed from Recommends
in pipewire 0.3.39-3. I upgraded to this version, and pipewire-pulse
was installed again. So, I downgraded again, so that pipewire-pulse
got removed again.

Then the rollback was done in pipewire 0.3.39-4:

  * Re-add pipewire-media-session as an alternative to Wireplumber,
  it is now back in the archive as a separate source package.

and pipewire-pulse was no longer installed again on my machine.

Anyway, when I upgraded the vlc package two weeks ago, this had the
effect that PulseAudio was no longer used as the sound server (for
both vlc and ogg123), though pipewire was already installed (due to
a Recommends from libpipewire-0.3-0, itself due to a Depends from
xdg-desktop-portal). The only new package was vlc-plugin-pipewire,
due to

  * debian/control: Recommend vlc-plugin-pipewire

pipewire-pulse was not installed.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-30 14:30:38 +0200, Dylan Aïssi wrote:
> Le lun. 30 mai 2022 à 12:55, Jonas Smedegaard  a écrit :
> >  a) pipewire package enables pipewire service by default
> 
> Indeed, but pipewire service doesn't take control of audio over
> pulseaudio. Only pipewire-pulse does that.

This is incorrect. The pipewire-pulse package was not installed
at all (pipewire-pulse had been installed automatically in
October 2021 due to dependencies, but the change was reverted,
and the package got removed on my machine 3 days later).

I don't know whether this could cause the issue, but
pipewire-media-session was installed, because pipewire-bin
recommends it. There were already issues with it in the past:

https://tracker.debian.org/news/1271014/accepted-pipewire-0339-3-source-into-unstable/
which says:

   * Remove pipewire-media-session from Recommends.
   (Closes: #995116, #996994, #997859)

But pipewire-bin still has:

Recommends: dbus-user-session, pipewire-media-session | wireplumber, rtkit

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-28 10:41:34 +0200, Sebastian Ramacher wrote:
> On 2022-05-28 01:27:13 +0200, Vincent Lefevre wrote:
> > On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
[...]
> > > That's needed for Bluetooth audio, *if* you are using Pipewire for audio,
> > > which (as a distribution) we are not yet aiming to do. It isn't needed
> > > (or useful) if you are only using Pipewire as a video multiplexer.
> > 
> > The issue appeared automatically with the upgrade of the vlc package.
> > 
> > > pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth,
> > > if people consider Bluetooth audio to be sufficiently important to
> > > justify that (of course, every critical feature for one user is considered
> > > "bloat" by someone else, so we can't win). pipewire probably shouldn't,
> > > until such time as we are ready to recommend Pipewire as a replacement
> > > for PulseAudio.
> > 
> > So why did Sebastian Ramacher reassign bug 1011035 to pipewire?
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22
> 
> If pipewire-pulse is the better place for this relationship, feel free
> to reassign it.

My comment was on "until such time as we are ready to recommend
Pipewire as a replacement for PulseAudio". If Debian is not ready
to use Pipewire as a replacement for PulseAudio, then VLC shouldn't
try to use Pipewire by default instead of PulseAudio. So that would
be a bug in VLC.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-27 12:34:26 +0100, Simon McVittie wrote:
> If vlc-plugin-pipewire is prioritized higher than other audio backends,
> then I can see how that could happen. It's probably premature for
> vlc-plugin-pipewire to be prioritized higher than PulseAudio or ALSA in
> Debian.
> 
> The dependency graph around this stuff is complicated, particularly in
> a distribution like Debian where the answer to "do we try to support A
> or B?" is always "yes". Some early-adopter distributions have switched
> to Pipewire as their preferred audio service, replacing PulseAudio,
> and in *those* distributions, it would make sense to prioritize
> vlc-plugin-pipewire ahead of other audio backends - but Pipewire was not
> sufficiently mature to replace PulseAudio in bullseye, and it remains
> to be seen whether it will be sufficiently mature to replace PulseAudio
> in bookworm.
> 
> If Pipewire was only an audio service, then the right thing to do would be
> to make sure it was completely optional and not pulled in by depenencies,
> but it's a video service too, and during a global pandemic with a lot of
> people working and socializing remotely, not having working screen-sharing
> or screencasting in GNOME/KDE (together with not having working webcams
> in sandboxed Flatpak/Snap apps) seemed like a sufficiently major issue
> to make Pipewire worth the headaches it can cause.

So I suppose that the solution should be that PulseAudio have the
priority over Pipewire.

> > and apparently ditto with ogg123 (via ALSA, which I had as the default)
> 
> I don't know why that would be. The Pipewire module for libasound is in
> pipewire-audio-client-libraries, which nothing depends on.

It has never been installed.

> Could it be the case that the chain of Recommends pulled in wireplumber
> (which Recommends pipewire-pulse) instead of the preferred alternative
> pipewire-media-session (which was not always listed first, see #999363),
> resulting in pipewire-pulse taking over audio routing from PulseAudio?

The wireplumber package was installed from 2021-10-26 to 2021-10-29
only. So, perhaps ogg123 was using something else. But the ogg123
audio stream was not appearing in pavucontrol, and the sound was
sent to the speaker of my laptop instead of the bluetooth speakers.

> > However, for the support of bluetooth devices, libspa-0.2-bluetooth
> > is needed, but it isn't even pulled when pipewire is installed!
> 
> That's needed for Bluetooth audio, *if* you are using Pipewire for audio,
> which (as a distribution) we are not yet aiming to do. It isn't needed
> (or useful) if you are only using Pipewire as a video multiplexer.

The issue appeared automatically with the upgrade of the vlc package.

> pipewire-pulse should probably have a Recommends on libspa-0.2-bluetooth,
> if people consider Bluetooth audio to be sufficiently important to
> justify that (of course, every critical feature for one user is considered
> "bloat" by someone else, so we can't win). pipewire probably shouldn't,
> until such time as we are ready to recommend Pipewire as a replacement
> for PulseAudio.

So why did Sebastian Ramacher reassign bug 1011035 to pipewire?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011035#22

> > But xdg-desktop-portal just depends
> > on the libpipewire-0.3-0 library package. If it needs more than
> > the library, then I suppose that it should also recommend pipewire
> > directly and not expect that the library will do it.
> 
> Perhaps. If I add that Recommends, how many angry bug reports are we
> going to get accusing me of forcing people to use Pipewire against
> their will?

Fewer: This is already an issue because xdg-desktop-portal depends
on libpipewire-0.3-0, which recommends pipewire. The advantage would
be that packages just depending on libpipewire-0.3-0 would not pull
pipewire. So, this would solve the pipewire issue in some cases.

Said otherwise, this would not change anything for xdg-desktop-portal,
but could improve things for other packages (if xdg-desktop-portal and
other packages pulling pipewire are not installed).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-26 23:55:02 +, Alberto Garcia wrote:
> On Fri, May 27, 2022 at 01:03:57AM +0200, Jonas Smedegaard wrote:
> > > It was actually due to a problem in Evolution that we made WebKitGTK
> > > depend on xdg-desktop-portal (later downgraded to a recommendation):
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1845743
> > > https://bugs.webkit.org/show_bug.cgi?id=213148
> > 
> > Ok, so Evolution uses sandboxing
> 
> It's WebKit that does. The web content is handled by a process
> (separate from the UI process) that runs inside a bubblewrap sandbox.
> 
> In this case you need the portal in order to have access to the font
> settings:
> 
>https://github.com/flatpak/flatpak/issues/2861#issuecomment-494145504
> 
> It won't fail horribly if you don't have the portal installed, if
> you're using X11 in principle it should work fine, but under Wayland
> you won't get antialiased fonts.

IMHO, such explanations could be useful to users, who may wonder
why xdg-desktop-portal-gtk is recommended or why some features
are not available (in case the Recommends got broken, but this
is unnoticed by the user). That could be some file under the
/usr/share/doc/libwebkit2gtk-4.0-37 directory.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-26 20:08:22 +0100, Simon McVittie wrote:
> On Thu, 26 May 2022 at 17:21:27 +0200, Vincent Lefevre wrote:
> > Here, this could be
> > 
> >   Recommends: pipewire | pulseaudio
> 
> Those are not interchangeable.
> 
> pipewire started as a multiplexer for video streams, and only later
> gained audio capabilities. The reason most people with pipewire will
> have it installed is that it's necessary when doing screen-sharing or
> screencasting from a Wayland environment like GNOME.
> 
> If you're *also* using pipewire as an audio multiplexing server, which
> is not the default for any installation of Debian yet (but might be in
> future), then you will also need pipewire-pulse, which has two purposes:
> 
> * it configures the pipewire service to open the audio device;
> * it provides a separate PulseAudio-compatible server which acts as a
>   wire-protocol-compatible replacement for pulseaudio
> 
> Without pipewire-pulse, pipewire is only a video multiplexer, not an
> audio multiplexer.

This doesn't seem to be correct. The pipewire-pulse package was not
installed on my machine (it got installed on 2021-10-26 due to some
upgrade, but the change was reverted or something like that, and it
got removed 3 days later). However, with the installation of
vlc-plugin-pipewire, VLC was automatically using pipewire, and
apparently ditto with ogg123 (via ALSA, which I had as the default).

> pipewire is actually more like a metapackage, which pulls in the packages
> that are needed to have Pipewire actually work for a particular library
> architecture (libpipewire-0.3-0 cannot pull in libpipewire-0.3-modules
> itself, because that would be a circular dependency), together with the
> pipewire service from the primary architecture (pipewire-bin).

However, for the support of bluetooth devices, libspa-0.2-bluetooth
is needed, but it isn't even pulled when pipewire is installed!

> > Indeed, for a remote VM, it is silly to recommend a sound server,
> > just because a library appears in the chain of dependencies:
> > 
> > joooj:~> apt-get install -s atril | grep '^Inst pipewire'
> 
> It looks like that's happening because atril depends on WebKitGTK, a
> relatively complete web browser engine, which uses xdg-desktop-portal
> to invoke per-user services across a sandbox boundary (so that it can
> provide the web APIs people expect from it, without having arbitrary
> websites able to access your webcam without your permission).
> 
> xdg-desktop-portal depends on pipewire because one of the services it
> provides is access to webcams, and another is screen-sharing and
> screencasting. Both of those use the Pipewire video protocol to get the
> actual frames across the sandbox boundary.
> 
> Maybe Atril never actually uses WebKitGTK to access arbitrary websites,
> but WebKitGTK is a fully-featured web browser engine, so it has to
> be prepared to do anything that an arbitrary website expects to work,
> and that includes (for example) the Jitsi web frontend.

Thanks for the explanations. But xdg-desktop-portal just depends
on the libpipewire-0.3-0 library package. If it needs more than
the library, then I suppose that it should also recommend pipewire
directly and not expect that the library will do it. Moreover,
even with pipewire installed automatically, users should expect
regressions (see above about bluetooth devices).

Packages depend on library packages just to be able to use some
provided functions, in case they will be called. It doesn't mean
that the intent is that associated optional services will be used.

For instance, many packages (providing applications or libraries)
depend on libcups2, but this doesn't mean that the user will need
a CUPS server (or client). Ditto for libavahi-client3 and various
other libraries.

Concerning WebKitGTK, in a similar way, I think that there should
be a separation between the basic rendering library and the fully
featured web browser engine. So libwebkit2gtk-4.0-37 should not
recommend anything, and there could be a metapackage webkit2gtk-full
(or webkit2gtk-extra) that has the complete Recommends. Something
like that.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-17 08:54:59 -0400, Marvin Renich wrote:
> There is, unfortunately, a catch here.  In order for any of the
> applications that require a sound server to work, one of them must be
> installed.  For example, mpd links with libasound, libpipewire, and
> libpulse.  If each of these libs simply provides the glue to another
> package that provides the middleware and drivers, and for the reasons
> stated above they each only Suggest their middleware package, then it is
> possible for _none_ of the sound servers to be installed.

AFAIK, this kind of issue is normally solved with on ORed Recommends
(when a virtual package is not defined for that). For instance,
libaspell15 has

  Recommends: aspell-en | aspell-dictionary | aspell6a-dictionary

So, if the user already chose a solution, it won't be overridden
by the default.

Here, this could be

  Recommends: pipewire | pulseaudio

but IMHO, it is not up to libraries to do such Recommends, but
to audio applications or desktop environments, or something
done automatically at installation time where the user chooses
which kind of installation he wants? But isn't a sound system
already installed by default with a typical installation of a
desktop machine?

Indeed, for a remote VM, it is silly to recommend a sound server,
just because a library appears in the chain of dependencies:

joooj:~> apt-get install -s atril | grep '^Inst pipewire'
Inst pipewire-bin (0.3.19-4 Debian:11.3/stable [amd64])
Inst pipewire (0.3.19-4 Debian:11.3/stable [amd64])

(FYI, atril is just a PDF/PS/DVI document viewer, no relation
with audio at all.)

Ditto for the gnucash accounting software:

joooj:~> apt-get install -s gnucash | grep '^Inst pipewire'
Inst pipewire-bin (0.3.19-4 Debian:11.3/stable [amd64])
Inst pipewire (0.3.19-4 Debian:11.3/stable [amd64])

> I do not fully understand the relationships between the different sound
> servers, for example I think pulseaudio can use ALSA as one of its
> backends, but do I think that they all need to be co-installable without
> interfering with the operation of each other, because some applications
> appear to only use pulseaudio and others only pipewire.  Clearly from
> the original message in this thread, installing pipewire breaks at least
> some setups when using VLC and ogg123.

Worse than that, ogg123 (when used with ALSA) remained broken after
I uninstalled pipewire (perhaps because default choices were
automatically changed in the mean time). I eventually managed to
fix the issue by randomly changing options in pavucontrol.

> This is definitely a bug, either of severity "serious" (violates
> Debian Policy definition of "Recommends") or "critical" (breaks
> other software). But I think to sort this out will require the sound
> server maintainers to come up with a way for the user specify which
> sound server to use, and then have a metapackage that forces at
> least one of them to be installed.
> 
> I think you (Vincent) are fully justified in filing a bug against
> libpipewire of severity at least "serious", however it may take more
> than just downgrading the Recommends to Suggests in order to straighten
> this out correctly.

Any comment from anyone else?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-16 16:14:02 +, Bill Allombert wrote:
> On Mon, May 16, 2022 at 12:56:03AM +0200, Sebastian Ramacher wrote:
> > And for the record: you get pipewire installed because libpipewire-0.3-0
> > recommends it.
> 
> For a similar situation, I advocated to add a apt option so that apt
> only install Recommends of the packages on the command line, but not
> Recommends of dependencies (and not Recommends of Recommends).
> This would make recommends more usable but less deterministic.

So, if I understand correctly, this implies that if a package A needs
package B and package B recommends package C, and if it happens that
A needs C, then package A should also depend on or recommend C.

And what about upgrades? Should Recommends be checked only for
manually installed packages?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

On 2022-05-16 00:56:03 +0200, Sebastian Ramacher wrote:
> On 2022-05-16 00:40:25 +0200, Vincent Lefevre wrote:
> > The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
> > users to use pipewire instead of pulseaudio (which broke the use of
> > VLC, but also apparently ogg123 with the alsa device). IMHO, this is
> > a bad use of Recommends. It is not up to applications to choose what
> > sound server to use, even via a meta-package like vlc.
> > 
> > Shouldn't there be something in the policy about that?
> 
> Nothing forces pipewire on you. If you don't want it, don't install it.

I repeat: I have *NEVER* installed pipewire manually.

> It isn't a dependency.
> 
> And for the record: you get pipewire installed because libpipewire-0.3-0
> recommends it.

Yes, but users should not be forced to go against "Recommends",
as this yields various issues.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

use of Recommends by vlc to force users to use pipewire

[Vincent Lefevre]

The vlc package now uses a Recommends (vlc-plugin-pipewire) to force
users to use pipewire instead of pulseaudio (which broke the use of
VLC, but also apparently ogg123 with the alsa device). IMHO, this is
a bad use of Recommends. It is not up to applications to choose what
sound server to use, even via a meta-package like vlc.

Shouldn't there be something in the policy about that?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

[Vincent Lefevre]

On 2022-04-08 18:55:14 +0500, Andrey Rahmatullin wrote:
> On Fri, Apr 08, 2022 at 03:22:07PM +0200, Vincent Lefevre wrote:
> > Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind
> > hasn't been rebuilt yet?
> Was anything done for that to happen? Because otherwise the answer is
> "nobody did that".

I would have assumed that this would be done when bug 993316 was closed.
Or should I open a new bug against rpcbind to ask for a rebuild?

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

rebuild of rpcbind (and other packages?) due to old debhelper bug 993316

[Vincent Lefevre]

Hi,

Due to the old bug 993316 in debhelper[*], rpcbind is still buggy as
it hasn't been rebuilt yet: rpcbind_1.2.6-2_amd64.deb contains

-rw-r--r-- root/root   626 2021-08-17 17:31:36 
./usr/lib/systemd/system/rpcbind.service
-rw-r--r-- root/root   325 2021-08-17 17:31:36 
./usr/lib/systemd/system/rpcbind.socket
lrwxrwxrwx root/root 0 2021-08-17 17:31:36 
./lib/systemd/system/portmap.service -> rpcbind.service

thus with a dangling symlink, while this should be

/lib/systemd/system/rpcbind.service
/lib/systemd/system/rpcbind.socket
/lib/systemd/system/portmap.service -> rpcbind.service

i.e. without the "/usr".

Bug 993316 was fixed on 23 September 2021. Any reason why rpcbind
hasn't been rebuilt yet?

I don't know whether there are other affected packages.

[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993316

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: build-depend on autoconf-archive and rm convenience copy in orig.tar.gz?

[Vincent Lefevre]

On 2022-01-19 11:03:15 -0800, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
> > Thanks for elaborating.
> 
> > The concern is not licensing, but maintenance.  It is covered in Debian 
> > Policy § 4.13: 
> > https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
> 
> Debian packages should not make use of these convenience copies unless
> the included package is explicitly intended to be used in this way.
> 
> The part after the "unless" is the case for autoconf-archive upstream:
> shipping a copy with your package is how it is intended to be used.

FYI, this is what we now do in GNU MPFR (there's only one file),
after we got a failure due to the upgrade to Autoconf 2.71:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985458

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]G

[Vincent Lefevre]

On 2021-08-23 07:43:07 +0100, Tim Woodall wrote:
> On Mon, 23 Aug 2021, Holger Wansing wrote:
> > Am 23. August 2021 07:19:26 MESZ schrieb Tomas Pospisek 
> > :
> > > 
> > > The thing is, if you close a bug report via `Bcc:
> > > -cl...@bugs.debian.org` then the mail that arrives at the
> > > BTS does *not* have the -cl...@bugs.debian.org address in
> > > the email header but only in the mail envelope - that is, when
> > > connecting the sending MTA will tell the BTS MTA "RCPT TO:
> > > -cl...@bugs.debian.org"
> > > and that's it. This will close the bug, but the address
> > > -cl...@bugs.debian.org will not be visible in the email
> > > that's archived...
> > 
> > Funny, just some minutes before your mail I have filed
> > bug #992755 as a place to test and document this
> > behaviour.
> > 
> > It's indeed as you stated.
> > 
> > Thus, I will reopen and rename that bug accordingly.
> 
> When I toggle "show useless messages" I think I do see the closure. And
> I see the one for 989734 too.

Yes, but only the notification (and one needs to see the full message).
But what if the close message is sent when an empty From or with
a From containing the -cl...@bugs.debian.org address
of the bug[*] (such messages could come from spammers)?

[*] That could yield a loop, and this may depend on how it is broken.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: inconsistent mailgraph settings

[Vincent Lefevre]

On 2021-08-21 10:36:04 +0200, Tomas Pospisek wrote:
> In particular it *seems* to work for him and he doesn't have access to your
> system where things apparently went wrong so it could be really hard for him
> to know. So what you can do is to try to debug *yourself* why the upgrade
> went wrong and come forth with some analysis that shows to root cause of the
> breakage. And then you can also propose a fix. I am sure that would make it
> a lot easier for the maintainer to do "the right thing".

Unfortunately, that's too late, because the issue (at least one part
of it) occurred during the upgrade, and unfortunately, I can't install
the previous version (due to unsatisfied dependencies) to try to
reproduce the bug.

> > While mailgraph was started on boot in the past, this stopped
> > working with the upgrade to Debian 10, and I had to enable it
> > again. So issues with the upgrade to Debian 11, but the mailgraph
> > package has not changed. And who knows what will happend with
> > the next upgrade...
> > 
> > I can see in the debian/default.conf file:
> > 
> > # Should Mailgraph start on boot (true|false) (default: true)
> > BOOT_START="true"
> > 
> > So I don't understand what is the intent for the default settings.
> > To run it on boot or not???
> 
> Evidently the package is offering a choice on whether to start or not to
> start mailgraph on boot. By virtue of that option existing it seems that not
> everybody wants mailgraph to be started on boot.

Yes, but this option was honored in the previous version and
is no longer honored (note that there wasn't an announce of
any change).

> > Note that I was already using systemd in Debian 9, so that it is
> > not normal that mailgraph stopped working after the upgrade to
> > Debian 10.
> 
> Don't be all up in arms about the problem. Try to find out why it's broken
> and try to propose a fix and to work with the maintainer.

I no longer have any Debian 9 machine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]

[Vincent Lefevre]

On 2021-08-22 23:32:15 +0500, Andrey Rahmatullin wrote:
> On Sun, Aug 22, 2021 at 08:25:41PM +0200, Tomas Pospisek wrote:
> > Wouldn't the Bcc'ed email that arrived to the BTS be visible in the bug's
> > log/archive (on the bug's page (https://bugs.debian.org/989734))?
> It's visible: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=27

Where? I don't see any "close" or "done".

Note that the "Done:" in the metadata at the top just reflects the
*current* status of the bug; it is currently also present at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=5

where the bug was obviously open.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Q: Use https for {deb,security}.debian.org by default

[Vincent Lefevre]

On 2021-08-20 12:11:30 -0700, Russ Allbery wrote:
> The most naive attempt to mess with the update channel (intercepting the
> http connection and replacing a package with a malicious one) will fail
> immediately with both http or https.  The primary difference in that case
> with https is that the the network connection will fail (assuming no
> compromise of the TLS certificate authority chain, which is possible of
> course and which degrades to the http case), whereas with http you will
> download the malicious package first and then apt will refuse to install
^^
> it when the hash doesn't match.  That difference mostly doesn't matter.

But what if one doesn't install packages with apt?

I use the sources.list also to download the source with "apt source".

And what about dget?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

inconsistent mailgraph settings

[Vincent Lefevre]

My bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734
has been closed again, with no explanations.

While mailgraph was started on boot in the past, this stopped
working with the upgrade to Debian 10, and I had to enable it
again. So issues with the upgrade to Debian 11, but the mailgraph
package has not changed. And who knows what will happend with
the next upgrade...

I can see in the debian/default.conf file:

# Should Mailgraph start on boot (true|false) (default: true)
BOOT_START="true"

So I don't understand what is the intent for the default settings.
To run it on boot or not???

Note that I was already using systemd in Debian 9, so that it is
not normal that mailgraph stopped working after the upgrade to
Debian 10.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Proposal: plocate as standard for bookworm

[Vincent Lefevre]

On 2021-02-09 22:12:31 +0100, Ansgar wrote:
> "Steinar H. Gunderson" writes:
> > On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote:
> >> Furthermore, any mechanism they use to configure one of them
> >> (e.g. for privacy or performance reasons) will not control the other,
> >> and again they may well be unaware of the existence of the other one.
> >
> > I'm not sure what privacy reasons you're referring to? I'm not aware that
> > neither mlocate/plocate nor e.g. tracker will leak data across users.
> 
> If you have an encrypted /home (or /home/), but unencrypted
> /var/lib/plocate, you leak information about the encrypted files.

This would be the user's fault. I can also see /home/ "leaks"
in log files. And mail "leaks" under /var/mail. So, in short, /var
should be encrypted.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Mass bug filing: dependencies on GTK 2

[Vincent Lefevre]

On 2020-04-29 18:37:50 +0100, Simon McVittie wrote:
> Given GTK 2's lack of feature development (for things like HiDPI) it
> seems higher-severity than "a problem which doesn't affect the package's
> usefulness", and it's certainly not "presumably trivial to fix" in
> many cases.

Note that missing HiDPI support is not necessarily an issue on
a HiDPI screen. I use gkrellm on a HiDPI screen, and did not
even notice that it was based on GTK 2 until now. Things look
fine with it, and I don't see what could be missing in the UI.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

[Vincent Lefevre]

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote:
> The /etc/mailcap file contains many rules with '%s' instead of %s,
> for instance:
> 
> text/*; less '%s'; needsterminal
> audio/ogg; ogginfo '%s'; copiousoutput
> 
> This is incorrect. [...]

I suppose that the update-mime script could automatically fix those
(note that there can be a prefix, e.g. 'jpeg:%s').

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

[Vincent Lefevre]

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote:
>   execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less 
> ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0
> 
> i.e. the filename is eventually not quoted!
> 
> Here the filename is sanitized, but I'm not sure that this is always
> the case (there's a mailcap_sanitize option that can be set to "no",
> even though this is strongly discouraged). [...]

After reading the Mutt code, %s is not affected by this
mailcap_sanitize option: there is no attempt to sanitize
the filename in rfc1524.c, probably because the filename
is expected to have been sanitized earlier, but I don't
know whether this is always the case.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

[Vincent Lefevre]

On 2019-06-22 10:51:35 +0200, Vincent Lefevre wrote:
[...]
> as seen in strace output:
> 
>   execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less 
> ''/var/tmp/_.txt''"], 0x564ffe666f40 /* 132 vars */) = 0

FYI, the sh.screen is due to a modification I've done and is used
as a sh wrapper to support Mutt in GNU Screen and avoid a bug in
dash. But the issue does not depend on that and is shown by the

  "less ''/var/tmp/_.txt''"

argument.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#930908: general: incorrect rules for %s in /etc/mailcap yielding potentially unquoted metacharacters

[Vincent Lefevre]

Package: general
Severity: grave
Tags: security
Justification: user security hole
Affects: mutt

The /etc/mailcap file contains many rules with '%s' instead of %s,
for instance:

text/*; less '%s'; needsterminal
audio/ogg; ogginfo '%s'; copiousoutput

This is incorrect. For instance, Mutt quotes the filename, so that
it generates command lines like

  less ''filename''

as seen in strace output:

  execve("/home/vinc17/bin/sh.screen", ["sh", "-c", "less ''/var/tmp/_.txt''"], 
0x564ffe666f40 /* 132 vars */) = 0

i.e. the filename is eventually not quoted!

Here the filename is sanitized, but I'm not sure that this is always
the case (there's a mailcap_sanitize option that can be set to "no",
even though this is strongly discouraged). And Mutt wouldn't need to
quote the filename if this were ensured; anyway, one of its security
features (quoting the filename, just in case) is broken by these
incorrect mailcap rules. Other programs might also strongly rely on
correct rules.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Re: Debian, so ugly and unwieldy!

[Vincent Lefevre]

On 2019-06-07 17:24:17 +0200, Adam Borowski wrote:
> * CSD is still a thing.  No, your special program shouldn't get to ignore
>   system theme, put controls in wrong order, miss some controls, not respond
>   to minimize/etc if it's currently busy, etc.  Consistency not one-off
>   designs.
> 
>   => Install gtk3-nocsd by default in all desktop tasks but Gnome.  It's not
>  perfect but it helps.

I have gtk3-nocsd installed on my machines, but I don't think a
default install is a good idea, as its necessary use via LD_PRELOAD
breaks *any* program using ASan.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

[resent with group-reply, sorry]

On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote:
> Also, I think it's worth trying to identify what the worst extent
> of the issue is. Whilst I don't agree with some who say that this isn't
> a security issue at all, I don't know of any real-world cases where
> it would be exploitable for remote code execution.

Probably not directly, but if the user doesn't check the filenames,
this can obviously occur. Those using "wget -r" should be very
careful with this. I had a Perl script working on such a "wget -r"
result. Fortunately it was just a Perl script that did all the work,
and it was using the 3-arg open on the files, so that it wasn't
vulnerable.

There is a potential exploit if the user calls a vulnerable script
on files obtained with "wget -r".

> If someone would like to contradict me, please feel free to mail
> off-list. Either way, the fact remains that if untrusted/unsanitised
> input is being passed into your @ARGV, then something is already
> wrong.

I recall that a part of the issue is that this wasn't documented
(in addition to being unintuitive). As pure filenames, they are
already sanitized: a filename that ends with "|" is perfectly
valid.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-25 10:36:42 +, Dominic Hargreaves wrote:
> Also, I think it's worth trying to identify what the worst extent
> of the issue is. Whilst I don't agree with some who say that this isn't
> a security issue at all, I don't know of any real-world cases where
> it would be exploitable for remote code execution.

Probably not directly, but if the user doesn't check the filenames,
this can obviously occur. Those using "wget -r" should be very
careful with this. I had a Perl script working on such a "wget -r"
result. Fortunately it was just a Perl script that did all the work,
and it was using the 3-arg open on the files, so that it wasn't
vulnerable.

There is a potential exploit if the user calls a vulnerable script
on files obtained with "wget -r".

> If someone would like to contradict me, please feel free to mail
> off-list. Either way, the fact remains that if untrusted/unsanitised
> input is being passed into your @ARGV, then something is already
> wrong.

I recall that a part of the issue is that this wasn't documented
(in addition to being unintuitive). As pure filenames, they are
already sanitized: a filename that ends with "|" is perfectly
valid.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-25 13:55:47 +, Ian Jackson wrote:
> The easiest way to sanitise a string to make it safe for 2-argument
> open involves:
>  * prepending ./ if the string does not start with /
>  * appending \0 (a nul byte)
> The result is also a valid operand for 3-argument open.

However, the null byte trick is not portable. As documented in the
open description:

[...]
   otherwise it's necessary to protect any leading and trailing
   whitespace:

   $file =~ s#^(\s)#./$1#;
   open(my $fh, "< $file\0")
   || die "Can't open $file: $!";

   (this may not work on some bizarre filesystems). One should
[...]

And some filesystems may want to see \0 as an error (i.e. making
open fail), e.g. for security reasons:

  
https://security.stackexchange.com/questions/45955/what-does-it-mean-to-have-a-file-name-with-null-bytes-in-serialized-instances

(IMHO, it would be safer if Perl did this everywhere.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 15:18:40 +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Potentially insecure Perl scripts"):
> > The right answer is to fix the behaviour to be secure and sane by
> > default.  We can arrange for an environment variable for people who
> > want to turn the crazy back on.
> 
> To the Debian Perl maintainers: if I make a patch to make
>   -p -n <>
> use the 3-argument form of open (or equivalent), will you apply it ?

I fear that this is not that simple: I suppose that this will break
scripts that modify @ARGV to make <> secure. :(

Now, perhaps the number of such scripts is close to 0. I don't know.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 11:18:06 +0100, Adam Borowski wrote:
> On Thu, Jan 24, 2019 at 04:41:29AM +, Ben Hutchings wrote:
> > On Wed, 2019-01-23 at 09:07 -0800, Russ Allbery wrote:
> > > Ian Jackson  writes:
> > > > Apparently this has been klnown about for EIGHTEEN YEARS
> > > >   https://rt.perl.org/Public/Bug/Display.html?id=2783
> > > > and no-one has fixed it or even documented it.
> > > 
> > > It's been documented for pretty close to eighteen years too.  See
> > > perlop(1):
> > > 
> > >The null filehandle "<>" is special: it can be used to emulate the
> > >behavior of sed and awk, and any other Unix filter program that
> > >takes a list of filenames, doing the same to each line of input
> > >from all of them.  Input from "<>" comes either from standard
> > >input, or from each file listed on the command line.
> > 
> > But this initial description is actively misleading.  It doesn't matter
> > that the giant booby-trap is documented several paragraphs further
> > down.  Why would a programmer expect that they need to read further
> > when they already understand this Unix convention?
> > 
> > There should be a big flashing WARNING or DEPRECATED right at the top
> > of the description.
> 
> Even that wouldn't be enough.  This won't help those who learned Perl
> before.

Agreed.

> I for one did most of my Perl learning ~20 years ago (so just before those
> "EIGHTEEN YEARS" you name), and I guess a good deal of Perl users are

Note that the "EIGHTEEN YEARS" was about the above initial bug report.
Concerning the documentation, perlrun(1) was improved only about
10 years ago. This is even more recent.

> similar -- those pesky annoying millenials seem to use exclusively Python,
> Perl users being correlated to low-saturation colors of beard.  Yet <>
> being broken in such a fundamental way is news to me.  And I don't quite
> see any way you could communicate that to me in a way other than a
> run-time warning -- you don't re-read docs for basics you believe you
> already know well.

As for me, even though I knew that <> did something special a few
years ago, I completely forgot it, and only now I noticed that it
could be a security issue in practice.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 09:46:56 +0100, Ansgar wrote:
> But "<>" isn't the only problem, there are way too many uses of the
> two-argument form of Perl's "open" too...

Perhaps, but at least "open" had correctly been documented since the
beginning, and I quickly learnt to preprend "<" to the filename in
the 1990s (the 3-arg version did not exist at that time, IIRC).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-24 11:12:43 +0100, Alex Mestiashvili wrote:
> On 1/24/19 2:40 AM, Vincent Lefevre wrote:
> But I disagree that a language can be considered insecure, just because

Note: just a feature, not the language itself.

> it lets you shoot in the foot.
> The first thing I learned when doing CGI coding is to sanitize the
> input. That's the root problem in the most cases IMHO.

Not really: The point is that if there were real filenames as usual
(possibly with the safe and common exception for "-"), there would
be nothing to sanitize. And as most developers thought these were
real filenames (due to past boggus documentation), they did not try
to sanitize @ARGV. Hence the issue.

> It's also good to see that perl's documentation gets improved.

Yes, but even though it gets improved, it will take much time before
most non-official documentation and examples get fixed too.

> May be lintian's warning for something like "while\s?(\s?<>\s?)" in perl
> script explaining people that they should test the scripts is a good
> start to eliminate that in Debian?

Perhaps, with (as a Perl regexp): (foreach|while)\s*\(\s*<>\s*\)

glilypond, gperl and gpinyin use foreach (perhaps not a good idea,
but that's another matter).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-23 17:23:10 +0100, Alex Mestiashvili wrote:
> On 1/23/19 4:44 PM, Vincent Lefevre wrote:
> > On 2019-01-23 15:32:00 +, Ian Jackson wrote:
> >> This is completely mad and IMO the bug is in perl, not in all of the
> >> millions of perl scripts that used <> thinking it was a sensible thing
> >> to write.
> > 
> > I agree that it would be better to drop this "feature" of Perl.
> > It is probably never used, and probably useless (I would rather
> > use the features from the shell if I need a pipe).
> 
> Perl's open is well documented.

What wasn't clear was not about open, but the fact that <> uses the
2-arg open in a raw way. FYI, I learnt Perl in 1994 or early 1995,
just after Perl 5.000 was released, and at that time, I'm not sure
that <> was properly documented. More importantly, security was not
really a consideration (not much except file permissions).

The fact that the perlsec(1) man page doesn't mention the issue with
the null filehandle doesn't help either.

One also has (had) plenty of misleading documentation, starting with
the perlrun(1) man page:

   -n   causes Perl to assume the following loop around your
program, which makes it iterate over filename arguments
somewhat like sed -n or awk:

  LINE:
while (<>) {
... # your program goes here
}

"like sed -n and awk". Really?

Now, this man page also says:

Also note that "<>" passes command line arguments to
"open" in perlfunc, which doesn't necessarily interpret
them as file names.  See  perlop for possible security
implications.

But in 2008, it was still not there. Thus programs written before 2008
or by developers who started to learn Perl before 2008 can easily be
affected by this issue.

BTW, I've just seen that I already reported a documentation bug in
the past:

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

This was about the behavior, which is not specified, e.g. on
the argument '>file'.

> Quoting the perlipc:
> 
> "it's much more efficient to process the file one line or record at a
> time because then you don't have to read the whole thing into memory at
> once."

Well, with a pipe used from the shell (either with "|" or with
process substitution) instead of a special Perl syntax, the
behavior is the same.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Potentially insecure Perl scripts

[Vincent Lefevre]

On 2019-01-23 15:32:00 +, Ian Jackson wrote:
> This is completely mad and IMO the bug is in perl, not in all of the
> millions of perl scripts that used <> thinking it was a sensible thing
> to write.

I agree that it would be better to drop this "feature" of Perl.
It is probably never used, and probably useless (I would rather
use the features from the shell if I need a pipe).

If this is modified, "-" must still be supported as being
regarded as stdin (this one is normally safe, and at least
developers should already be aware of it).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Potentially insecure Perl scripts

[Vincent Lefevre]

Hi,

I've just reported

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

against gropdf (also reported upstream to bug-groff), about the use of
the insecure null filehandle "<>" in Perl, which can lead to arbitrary
command execution, e.g. when using wildcards.

I've noticed that some other Perl scripts also use this filehandle and
might be affected by the same issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: no{thing} build profiles

[Vincent Lefevre]

On 2018-10-24 10:33:30 +0100, Jonathan Dowland wrote:
> That is sort-of what is happening for neomutt (20171215+dfsg.1-1)
> at least, it reports
> 
>sh: 1: gpg: not found
> 
> There's room for improvement there. mutt (1.9.2-1) is worse
> 
>Error: verification failed: Unsupported protocol
> 
> both with the default configurations.

Mutt is correct here. It just reports the error from GPGME:

  err = gpgme_op_verify (ctx, signature, message, NULL);
[...]
  if (err)
{
  char buf[200];
  
  snprintf (buf, sizeof(buf)-1, 
_("Error: verification failed: %s\n"),
gpgme_strerror (err));
  state_puts (buf, s);
}

You need to complain to GPGME.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: no{thing} build profiles

[Vincent Lefevre]

On 2018-10-23 17:01:04 +0200, Wouter Verhelst wrote:
> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> > That would be a bad idea -- we don't want gratuitous dependencies
> > all around. Just because I use xfce doesn't mean I want a daemon
> > for some old kinds of iApple iJunk
> 
> Why not? What does it cost you, other than a few bits on your hard disk,
> to have those things installed?

If executables are installed somewhere in $PATH, this hurts
completion.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: no{thing} build profiles

[Vincent Lefevre]

On 2018-10-23 16:55:00 +0200, Wouter Verhelst wrote:
> On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote:
> > * Sune Vuorela  [181021 06:05]:
> > > On 2018-10-21, Jonas Smedegaard  wrote:
> > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at 
> > > > all: 
> > > > As a library it cannot possibly declare how tight a relationship to 
> > > > declare - instead, all _consumers_ of the library must declare whether 
> > > > they depend/recommend/suggest gnupg.
> > > 
> > > libgpgme is completely useless without gnupg. I think it is perfectly
> > > fine for these kind of relations, unless we really are in corner-case
> > > territory. See for example fam.
> > 
> > I strongly agree with Jonas.  Upstream links to libgpgme as a .so to
> > provide optional behavior.  This requires libgpgme to be installed in
> > order to even run neomutt, whether the user wants the feature or not.
> > It is perfectly reasonable to want to install neomutt but want to _not_
> > install gnupg.
> 
> Not in Debian.
> 
> The Debian philosophy in this has always been to link against all
> libraries where possible, and to detect at runtime whether something can
> be used. [...]

This matches what Marvin said just above: Link against libgpgme (thus
depend on it) and let the user choose whether to install gnupg or not.
The availability of gnupg is checked at runtime.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: no{thing} build profiles

[Vincent Lefevre]

On 2018-10-22 10:47:05 +0100, Jonathan Dowland wrote:
> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
> > It can be argued that libgpgme11 does not “provide a significant
> > amount of functionality” (7.2) without gnupg.
> 
> It won't function at all without gnupg.

That's pointless. A library *alone* is not usable. The real dependency
should come from the application that will use gnupg via libgpgme11.

Imagine a package A that provides an application that is linked
against libgpgme because gnupg may be used as an optional feature,
say by 0.1% of the users. This package must depend on libgpgme11,
otherwise the application wouldn't even run (even in the case
libgpgme will not be used). But a Depends or Recommends on gnupg
will annoy 99.9% of the users; thus it should just be a Suggests.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Removing packages perhaps too aggressively?

[Vincent Lefevre]

On 2018-05-29 15:35:24 +0200, Steve Cotton wrote:
> On Tue, May 29, 2018 at 03:03:11PM +0200, Vincent Lefevre wrote:
> > On 2018-05-23 09:46:09 +0800, Paul Wise wrote:
> > > Depends on obsolete WebKit version (fixed in experimental):
> > > 
> > > https://tracker.debian.org/pkg/gnucash
> > > https://tracker.debian.org/news/859896/gnucash-removed-from-testing/
> > > https://bugs.debian.org/790204
> > 
> > This bug was closed 4 months ago.
> 
> Fixed in experimental, but still open on the version in unstable.

But the bug status is closed. In particular, it is no longer shown
by the tracker:

  https://tracker.debian.org/pkg/gnucash

If one clicks on the number in the "RC" line, one just gets #893077,
which is a different bug.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Removing packages perhaps too aggressively?

[Vincent Lefevre]

On 2018-05-23 09:46:09 +0800, Paul Wise wrote:
> On Tue, May 22, 2018 at 5:43 PM, Heinz Repp wrote:
> 
> > GnuCash removed from testing in August 2017
> 
> Depends on obsolete WebKit version (fixed in experimental):
> 
> https://tracker.debian.org/pkg/gnucash
> https://tracker.debian.org/news/859896/gnucash-removed-from-testing/
> https://bugs.debian.org/790204

This bug was closed 4 months ago.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Removing packages perhaps too aggressively?

[Vincent Lefevre]

On 2018-05-22 15:19:50 +0500, Andrey Rahmatullin wrote:
> On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote:
> > Just stumbled over some removals:
> > 
> > GnuCash removed from testing in August 2017
> > FreeCad removed from testing in October 2017
> > 
> > no sign of any effort to readd them in sight ...
> Maybe you are looking in a wrong place.
> Last gnucash upload was in April.

But still not in testing:

$ apt-show-versions -a gnucash
gnucash:amd64 1:2.6.19-1 install ok installed
gnucash:amd64 1:2.6.15-1 stable   ftp.fr.debian.org
No stable-updates version
No testing version
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: gnucash status

[Vincent Lefevre]

On 2018-05-16 01:21:01 +, Anthony DeRobertis wrote:
> It appears to be fixed in experimental, which has 3.0. Presumably
> that'll hit unstable when the maintainer feels it's ready.
> 
> It appears the the BTS's version tracking may not have fully
> realized what was going on, explaining why it's closed and archived.

It appears that the maintainer closed the bug explicitly when
submitting the package to experimental (or is there a bug in
the BTS management system?):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790204#78

Shouldn't the bug remain open until it is fixed in unstable? Or
is the "sid" tag + version information (now present) sufficient
to make the bug remain visible?

BTW, I've just tagged it "fixed-in-experimental".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

gnucash status

[Vincent Lefevre]

Though the following bug was closed several months ago, gnucash from
sid still depends on libwebkitgtk-1.0-0. What is the current status?
Shouldn't this bug have remained open until sid got a fixed version?

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Automatic way to install dbgsym packages for a process?

[Vincent Lefevre]

On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote:
> Now, where to put it? Into devscripts? The disadvantage is that devscripts 
> already pulls in quite a few other packages via recommends. But I don't 
> have a better idea. Unless we want to include it in reportbug or something 
> like that?

The one-line description of devscripts is:

  scripts to make the life of a Debian Package maintainer easier

So it's mainly targeted at Debian Package maintainers, while such
a script would be useful to end users.

Perhaps debian-goodies?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: OpenSSL disables TLS 1.0 and 1.1

[Vincent Lefevre]

On 2017-08-08 13:26:52 +0200, Stephan Seitz wrote:
> On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:
> > Is there an actual need for the removal of TLS v1.{0,1}? Are either
> > considered broken or unsupported by upstream? If not, I'd be much more
> 
> That’s I like to know as well.

BTW, IMHO, as it can break things, this change should be announced
in NEWS.Debian, together with known problems with other Debian
software, and so on.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug in https://release.debian.org/transitions/ page?

[Vincent Lefevre]

On 2017-08-08 14:13:31 +0200, Mattia Rizzolo wrote:
> Trying to guess what your actual question is...
> 
> On Tue, Aug 08, 2017 at 01:05:03PM +0200, Vincent Lefevre wrote:
> > The https://release.debian.org/transitions/ lists in
> > "Ongoing transitions":
> > 
> > which are actually finished. And in "(almost) Finished transitions",
> > one can see:
> > which has 3 packages in "good", 2 packages in "partial", and
> > 60 packages in "bad"!
> 
> "ongoing" means the new library has yet to migrate to testing, "almost
> finished" means the new library already migrated to testing, but the old
> one did not yet get removed.

Thanks for the explanations. I think that this should be documented.
There's nothing about that on this web page, and not either on the
following wiki pages:
  https://wiki.debian.org/Teams/ReleaseTeam/Transitions
  https://wiki.debian.org/OngoingTransitions

> Please consider using a more welcoming tone though, as reading your
> email I nearly perceived something disrespectful…

? Sorry if this is your perception. This was not intended.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: DocBook 5 for Debian

[Vincent Lefevre]

Hi,

On 2017-08-01 23:24:20 -0700, Paul Hardy wrote:
> Therefore, I propose filing ITPs for packages "docbook5", "docbook5-xsl",
> and "docbook5-xml".  The packages initially would be based on DocBook 5.1,
> unless DocBook 5.2 is finalized in the meantime.

FYI, docbook5-xml has existed for years, but is not up-to-date
(last updated in 2009).

I've just submitted

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

against emacs25-common as it contains an obsolete DocBook RNC schema.
IMHO, Emacs should use the schema provided by the docbook*-xml packages.

So, I wonder whether there should be some form of catalog system
for the schemas (/etc/xml/catalog is for the DTD's only). Now that
DocBook 5 has its own namespace, this should be more reliable than
before.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug in https://release.debian.org/transitions/ page?

[Vincent Lefevre]

The https://release.debian.org/transitions/ lists in
"Ongoing transitions":

  auto-golang-goleveldb (100%)
  auto-libratbag (100%)

which are actually finished. And in "(almost) Finished transitions",
one can see:

  auto-libevent (5%)

which has 3 packages in "good", 2 packages in "partial", and
60 packages in "bad"!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: systemd, ntp, kernel and hwclock

[Vincent Lefevre]

On 2017-03-05 03:52:33 +, Ben Hutchings wrote:
> I would also expect that users running command-line tools to set the
> time, such as ntpdate, have enough technical understanding to
> distinguish the system clock and RTC.

And what's worse is that by default, ntpdate is run automatically from
/etc/network/if-up.d, so that the date could become incorrect without
a control from the user.

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: systemd, ntp, kernel and hwclock

[Vincent Lefevre]

On 2017-02-28 20:01:52 +0100, Carsten Leonhardt wrote:
> Daniel Pocock  writes:
> 
> > On 27/02/17 21:26, Ben Hutchings wrote:
> >> But ntpd is also known to have a large amount of code written
> >> without as much regard for security as one would hope.  It seems
> >> like an unnecessary risk for most systems.
> 
> > Thanks for that security tip, I'm tempted to get rid of some ntpd
> > instances now, however a few more questions come to mind before I rush in:
> 
> Have a look at openntpd, that's coded with security in mind.

But this doesn't apply to the Debian version, as documented. And it
is buggy. I had to remove it from my machine because it did more harm
than solving problems.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: problem with libc6 / iconv

[Vincent Lefevre]

On 2016-10-09 10:21:03 +0300, Lars Wirzenius wrote:
> On Sun, Oct 09, 2016 at 01:49:14AM +0200, Jérémy Lal wrote:
> > node-iconv used to be able to translit utf-8 chars (ça va) to ascii (ca va)
> > using setlocale("C.UTF-8") trick.
> > 
> > However, several libc6 version ago, that behavior changed, to the point
> > node-iconv fails its tests now.
> > 
> > I've failed to work around that, and i'm lacking libc6 knowledge to fix it,
> > or even properly report a bug about that. Please help me !
> 
> Write a short script that reproduces the problem, and attach it to a
> mail that explains what you want to do, what you expect the script to
> output, and what the actual output is. Sen report the problem to
> one of:
> 
> * upstream: https://www.gnu.org/software/libc/bugs.html
> * Debian: https://www.debian.org/Bugs/
> 
> I would expect this to be an upstream bug, and that it would faster to
> get it fixed by reporting it upstream.

No, I doubt that this can be an upstream bug as upstream does not
support/provide C.UTF-8. It is an addition in Debian and some other
distributions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#837606: general: system freeze

[Vincent Lefevre]

On 2016-09-19 09:50:19 +0200, Abou Al Montacir wrote:
> On Thu, 2016-09-15 at 11:30 +0200, Vincent Lefevre wrote:
> > Then I think that you should give strace information + system logs.
> Thanks Vincent for the only valuable answer I've got on this.
> 
> I tried that but unfortunately could not reproduce it again due to probably my
> recent upgrade. I'll keep trying until I get it.

Note that since system logs don't always give enough information
and for problems that are not easily reproducible, you can't get
strace information, I suggest to install the atop package, which
monitors system resources and process activity. So, when a crash
occurs, in addition to system logs, you can see what atop has
recorded (for instance, in the past I could see that some freeze
or crash was due to that some process was taking more than the
amount of RAM, thanks to atop information).

The atop package from unstable unfortunately triggers some trap
divide errors, with the consequence that nothing is recorded for
some days (the daemon seems to be restarted everyday). This is
apprently fixed in experimental, but this new version yields a
timeout at shutdown with systemd (90 seconds by default).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug#837606: general: system freeze

[Vincent Lefevre]

On 2016-09-15 10:10:23 +0200, Abou Al Montacir wrote:
> That is very similar to the issue I'm experiencing. However I can
> reproduce this 100% when opening a page on linkedIn using epiphany
> browser.

Then I think that you should give strace information + system logs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Upcoming change to perl: current directory in @INC

[Vincent Lefevre]

On 2016-09-08 08:44:54 -0700, Russ Allbery wrote:
> That's a little better but not a lot better.  It means that it's still
> unsafe to run any script out of a world-writeable directory such as /tmp,
> even if the sticky bit is set.

Running things in /tmp or its subdirectories is prone to security
bugs people do not care to fix.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: spammers closing bugs in BTS

[Vincent Lefevre]

On 2016-08-18 16:13:29 +0200, Patrick Matthäi wrote:
> 
> Am 18.08.2016 um 15:48 schrieb Vincent Lefevre:
> > Reject mail with "X-PHP-Originating-Script:", at least for -done?
> > I quite often see this in spam not caught by the filters, and I
> > suppose that PHP scripts do not send mail to the BTS; well, this
> > should be easy to see with the archives.
> Then you would exclude people using (PHP based) Webmailers / Colab. suites.

I don't think so. In my own archives, all the messages with
the above header have been sent automatically, not directly
by a human. In particular, webmailers don't seem to use this
header.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: spammers closing bugs in BTS

[Vincent Lefevre]

On 2016-08-17 14:47:24 -0500, Don Armstrong wrote:
> All of that said, we certainly do appreciate better anti-spam SA rules
> for the BTS, and we do already give negative scores for messages which
> have things which look like PGP signatures and/or come from an address
> which is in the whitelist. This enables us to be slightly more punitive
> with some of the rulesets that we have in place.

Reject mail with "X-PHP-Originating-Script:", at least for -done?
I quite often see this in spam not caught by the filters, and I
suppose that PHP scripts do not send mail to the BTS; well, this
should be easy to see with the archives.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: ifupdown2: debconf followup

[Vincent Lefevre]

On 2016-08-01 16:43:27 +0100, Simon McVittie wrote:
> This seems reasonable. I think NM is a better choice than ifupdown for
> roaming client devices (e.g. laptops), and systemd-networkd is a good
> choice for "infrastructure" devices like servers and NAS boxes.

I don't have any problem with ifupdown on my laptops, where I can
use different configurations via virtual interfaces, depending on
the place I go (this is necessary due to broken modem-routers).
And for wifi, I want a GUI, so that I use wicd.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Vincent Lefevre]

On 2016-07-28 01:03:04 +0100, Simon McVittie wrote:
> libdbus-1-3 shouldn't depend on a session bus, because you might only
> be using it to access the system bus;

Or because the user might not use the system bus at all, but the
application depends on libdbus-1-3 it because it's a library and
uses it as an optional feature (e.g. if available). This is the
case with emacs24 (which works even when the system bus is broken,
one just gets annoying warning messages). Similarly, emacs24
depends on libx11-6, but an X11 server (local or remote) is
entirely optional.

It's up to the desktop to provide what the user really wants.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Vincent Lefevre]

On 2016-07-21 21:53:11 +0100, Ben Hutchings wrote:
> It's true that if the system has to swap a lot of data out then it is
> likely to become unresponsive.  However, I think there are good reasons
> to enable a small amount of swap space:
> 
> - Some long-running applications have, effectively, memory leaks of a
> bounded size that can profitably be swapped out
> - The exact same problem can occur with memory-mapped files, and by
> disabling swap you prevent the kernel from balancing demand for
> anonymous and file-backed memory

Unfortunately, AFAIK, one cannot tell the kernel to use swap only
in these cases.

I'd prefer to buy "a small amount" of additional RAM that would
replace swap in these cases, and avoid a system freeze if something
goes wrong.

Swap could actually be interesting if the swap/RAM ratio were
important, say 10 or more, because in such a case one couldn't
avoid swap by buying more RAM (too expensive or not possible).
But this means that one should have control of how swap is used.
To give an example, I think that /tmp = 4 GB tmpfs + 80 GB swap
could be a better solution than /tmp being a part of the root
filesystem. Something like that.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Vincent Lefevre]

> Vincent Lefevre writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR 
> ?"):
> > On 2016-07-21 18:19:43 +0530, Ritesh Raj Sarraf wrote:
> > > Swap will come into effect when the kernel needs more memory.
> > 
> > Anyway, even if it had worked, swap should not be a solution for the
> > limited /tmp size. The reason is that enabling swap can make the whole
> > system freeze for several dozens of minutes when a program misbehaves.
> > A misbehaving program should crash, not freeze the whole system.
> 
> Uhhh.  You run your systems with no swap at all ?

What's the problem if swap is *never* used under normal conditions?
On current machines, I typically use less than 10% the amount of
physical RAM.

On an older laptop, I had 4 GB RAM, and under normal conditions,
I was using only around 1 GB. Swap was used only in two cases:

1. Because Firefox was taking more than 4 GB after some time, but
in this case, the system was more or less frozen. So, the only thing
I could do was to kill Firefox from a terminal, which was taking me
several minutes... I ended up by using a wrapper script that did:

  ulimit -v 4096000
  exec /usr/bin/firefox "$@"

so that Firefox would crash instead of freezing the system. Now, it
seems that Firefox has improved and no longer take so much memory.

2. Due to bugs in my programs, or something similar. Ditto, I would
have preferred a crash than a frozen system.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Vincent Lefevre]

On 2016-07-21 15:24:10 +0200, Philip Hands wrote:
> It's configurable.
> 
> See TMPFS_SIZE in /etc/defaults/tmpfs

If you mean /etc/default/tmpfs, it doesn't work with systemd
(as documented), and there's the global problem with swap.

> And it'll cheerfully use swap, so just make sure you have enough swap
> for your use case, and set the limit to suit your needs.
> 
> Alternatively, you can always create a new temporary location where you
> have enough space (i.e. ~/.tmp/ ) and then either set TMPDIR to that in
> the relevant user's shell profile/rc or define an alias such as:
> 
>   alias debdiff="TMPDIR=~/.debdiff-scratch-space debdiff" 

That's just a workaround. If some tool uses TMPDIR, it should work
in the first place.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Vincent Lefevre]

On 2016-07-21 18:19:43 +0530, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Thu, 2016-07-21 at 13:15 +0100, Neil Williams wrote:
> > > Now, back to the actual problem. For many applications, we rely on
> > > the TMPDIR environments. Tools like Python's modules help use these
> > > variables and not worry about the underneath platform.
> > > 
> > > Under Linux, with /tmp more commonly on tmpfs, how are developers
> > > dealing with it? tmpfs is limited and multi gigabyte operations may
> > > end up filling it all (as is the case in the debdelta bug report
> > > above).
> > 
> > As a drive backend, why doesn't swap work for this? There's no
> > mention of swap in the original bug report.
> 
> Swap will come into effect when the kernel needs more memory.

Anyway, even if it had worked, swap should not be a solution for the
limited /tmp size. The reason is that enabling swap can make the whole
system freeze for several dozens of minutes when a program misbehaves.
A misbehaving program should crash, not freeze the whole system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Packaging of static libraries

[Vincent Lefevre]

On 2016-04-13 12:40:39 +0100, Ian Jackson wrote:
> Vincent Lefevre writes ("Re: Packaging of static libraries"):
> > Note that by default, shared libraries would still be used, so that
> > this would affect only users with specific applications, who would
> > want to optimize as much as possible.
> 
> This assumption, that someone using static libraries wants to
> "optimizse as much as possible" (ie, that they would prefer a fast
> non-working program to a slow working one) is completely unfounded.

For libraries with a good testsuite (good coverage...) and checked
with an UB sanitizer, the program would be working. At least the
remaining bugs should not be related to UB.

> IMO we should be compiling almost all our code with what you are
> calling `UB sanitisation' and what I would call `traditional
> semantics'.

Yes, especially for software dealing with external data (e.g. web
browsers, mail software, etc.), but for computations that need to
run for weeks / months / years, full optimization is important
(after doing tests with UB sanitization).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Packaging of static libraries

[Vincent Lefevre]

On 2016-04-12 14:52:33 +0100, Ian Jackson wrote:
> I'm afraid that LTO is probably too dangerous to be used as a
> substitute for static linking.  See my comments in the recent LTO
> thread here, where I referred to the problem of undefined behaviour,
> and pointed at John Regehr's blog.

This is not specific to LTO at all. Other form of optimization can
yield "non-working" code (not expected by the developers). Note that
by default, shared libraries would still be used, so that this would
affect only users with specific applications, who would want to
optimize as much as possible. And code should also be tested with an
UB sanitizer (which could possibly enabled by default in cases where
it is shown that it does not slow things down[*]); this would allow
one to detect most UB related bugs.

[*] For instance, I use a patched Mutt built with the UB sanitizer,
as I could not see time differences, even on slow operations.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Packaging of static libraries

[Vincent Lefevre]

On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> (1) When performance matters. Here we need the static library to be
> built without position independent code. This can still give several
> percent gains depending on arch / programming language.

Yes, but in that case, the best thing to do is to recompile everything
for the target processor (instead of generic x86_64, for instance),
with LTO. For GMP+MPFR, I noticed a gain of up to 37% a few years ago.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload

[Vincent Lefevre]

On 2016-01-03 16:54:40 +1100, Brian May wrote:
> The package called "unison2.40.102" version 2.40.102-3+b1 in testing and
> unstable is broken. This broken package is not in stable. If it can't
> get fixed, it probably should get removed.

Yes, I think that it should be removed ASAP. Thus, users of
testing/unstable could still use unison2.40.102 from stable
(hoping there won't be any conflict in the near future) so
that they would be able to sync with stable machines without
requiring a backport of unison 2.48 in stable.

This is what I currently do, but since the broken unison2.40.102
is still in testing/unstable, I had to downgrade then mark it as
frozen in aptitude, so that the stable version is not replaced by
the testing/unstable version.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#809705: general: let people use non-free software but opt-out of non-open software

[Vincent Lefevre]

On 2016-01-04 23:14:11 +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote:
> > Your second item has been brought up before with different
> > focus/rationale/purpose.  At least I remember there being an interest
> > in splitting "non-free" into "non-free/firmware" vs. various other
> > non-free sub components.
> 
> Another one that is worth mentioning here --- which I discussed in the
> context of non-free.org with Dafydd Harries and others --- is
> introducing a debtags facet to capture the reason why a package is in
> non-free. At least two hierarchies come to mind: 1) which point of DFSG
> is not respected, and 2) which one of the 4 freedoms are not granted.

And could something similar be done for free packages that can
download non-free stuff?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: is the whole unstable still broken by gcc-5?

[Vincent Lefevre]

On 2015-09-13 23:57:13 +0200, Paul Wise wrote:
> This config option improves the aptitude resolver for some situations:
> 
> /etc/apt/apt.conf.d/99aptitude-resolver:
> Aptitude::ProblemResolver { SolutionCost "removals"; }

Unfortunately this has the consequence that aptitude sometimes wants
to downgrade packages (more or less silently), which is not supported
by Debian, thus with the risk to break the whole system.

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: the status of gstreamer1.0-plugins-bad

[Vincent Lefevre]

On 2015-09-03 10:26:25 +0200, Fabian Greffrath wrote:
> Hi Vincent,
> 
> > which is unacceptable from a security and stability point of view.
> 
> do you conclude this from the package description?

and information from upstream. Thus I don't want to be forced to
use plug-ins I don't need.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

the status of gstreamer1.0-plugins-bad

[Vincent Lefevre]

The gstreamer1.0-plugins-bad package description says:

[...]
 GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared
 to the rest. They might be close to being good quality, but they're missing
 something - be it a good code review, some documentation, a set of tests, a
 real live maintainer, or some actual wide use.

which is unacceptable from a security and stability point of view.
One problem is that if this package is installed, then Iceweasel
automatically uses these plugins (even when not needed, currently
making it crash[*]), with apparently no way to disable them. IMHO,
either there should be a way to disable them for some applications,
or this package shouldn't be in dependencies.

Note: Disabling all gstreamer plugins (i.e. including those from the
good set) is not a solution.

[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797227

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Debian with HiDPI / 4K displays

[Vincent Lefevre]

On 2015-08-09 18:02:05 +0200, Vincent Bernat wrote:
 While it is possible to derive the true DPI setting from the resolution
 and the dimension, I don't think that's what users would be
 expecting. On a laptop, you'll want smaller fonts than on a desktop
 because the screen is usually nearer from your eyes.
 
 For example, on my laptop, the screen is 310mm x 174mm for 2560 x
 1440. Strictly speaking, DPI is 210. However, I am setting it to 144
 because at 210, everything is far too big.
 
 On my desktop station, I am using 23 monitors (510mm x 290mm). It's 96
 DPI and it is just fine.

The best choice really depends on the user, but what's important is
that the default is not too small, otherwise the machine is hardly
usable just after installation. One needs to have some time to be
able to configure it (see below).

 What could be a goal is to only have one universal setting. This setting
 could be Xft.dpi since most applications work just fine with
 that. However, this hijacks the original purpose of this setting, but I
 think most people would like to have a bigger interface if they need
 bigger fonts.

This makes sense at least for icons attached to text (e.g. in menus).
There could (should) also be separate configuration, but it would be
nice if the global size of the UI followed the default font size.
Hardcoded icon size is unacceptable.

For instance, see

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

concerning lightdm-gtk-greeter (one can change the font size, but not
the size of the icons, which are tiny on high-dpi screens).

On 2015-08-10 11:49:03 +0200, Daniel Pocock wrote:
 On 10/08/15 00:17, Simon McVittie wrote:
  On 09/08/15 17:02, Vincent Bernat wrote:
  While it is possible to derive the true DPI setting from the resolution
  and the dimension
  
  ... except for when the stated dimensions in the display's EDID are full
  of lies and claim that it is 4cm x 3cm, or 16cm x 9cm, or even 0cm x
  0cm. See also
  https://lists.fedoraproject.org/pipermail/devel/2011-October/157760.html
  and its surrounding thread - admittedly that was a few years ago. I'd be
  delighted to be proved wrong, but I suspect hardware manufacturers
  haven't got a whole lot better at this since then.

Unfortunately the default dpi setting to 96 is also completely wrong:
text is hardly readable on high-dpi screens. The screen definition
(WxH in pixels) is at least correct, so that the default dpi could be
based on that. For instance, if one has a 4K (3840×2160) screen, then
probably either this is a high-dpi screen or the physical dimensions
are large (e.g. 32), but in which case the screen may also be far
from the user. So, choosing a large dpi value (e.g. 192) makes sense
in both cases.

 This brings a few thoughts to mind - I realize opinions may differ and
 there would be some work involved in any of these:
 
 - could there be some prompt on the first X startup or the first time a
 new screen is detected, asking the user to confirm DPI or dimensions?

There's still the problem that you need to display the prompt with
large enough font. One probably doesn't need a prompt. Just a sane
default and an easy way to change it.

 - could X use detected values that are in some range considered to be
 sane and if some users are unhappy, encourage them to complain to the
 monitor vendor?  To put this another way, isn't it better to favor those
 monitors that do things correctly?

IMHO, the screen definition should be OK to choose a default dpi value
(as said above).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150810142004.ga6...@ypig.lip.ens-lyon.fr

Re: Debian with HiDPI / 4K displays

[Vincent Lefevre]

On 2015-08-08 20:58:37 +0200, Daniel Pocock wrote:
 So, is there any strategy for HiDPI with Debian?  Is a BTS tag needed to
 track such issues perhaps?  Or is it already dealt with in unstable and
 people just have to wait for it?

I have similar problems with a 3200x1800 15 screen. Here's my
Xresources file for high DPI:

! X resources for high-definition screens

! This will define the unit for the font sizes below.
Xft.dpi:132

Emacs*font: Monospace 10
Emacs*geometry: 80x48

! With the following, the width should be $((11*COLUMNS+13)) pixels;
! in contrast, the fixed = 6x13 bitmap font is typically used on a
! low-definition screen, giving a width of $((6*COLUMNS+13)) pixels.
XTerm*faceName: Monospace
XTerm*faceSize: 10
! For xterm menus. This font is large enough, but a bit ugly.
XTerm*font: -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1

! The fontList resource is not documented, but found in xpdf/XPDFApp.cc.
Xpdf*fontList:  -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1
Xpdf.initialZoom:   200



and my firefox.cfg file:

// IMPORTANT: Start your code on the 2nd line
var hdef = getenv(X11_HDEF);
if (hdef = 2400) {
  pref(layout.css.devPixelsPerPx, 1.77);
} else {
  pref(layout.css.devPixelsPerPx, -1.0);
}

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150809102545.ga6...@ioooi.vinc17.net