Bug#606885: marked as done (xpdf: no longer asks for password in dialog window)

2021-01-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Jan 2021 08:19:59 +
with message-id 
and subject line Bug#606885: fixed in xpdf 3.04+git20210103-1
has caused the Debian Bug report #606885,
regarding xpdf: no longer asks for password in dialog window
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
606885: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606885
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xpdf
Version: 3.02-11
Severity: normal
Tags: security


Hi Debian xpdf maintainers!
Thanks a lot for maintaining my favorite PDF viewer!

I noticed a little regression (probably introduced during the
conversion into a libpoppler front-end).

In the past, xpdf used to pop up a useful dialog window to ask
the user for a password, when dealing with password-protected PDF
files. After typing the password in, the user was able to view
the contents of the password-protected PDF file.

Nowadays, when the user attempts to view a password-protected PDF
file, no dialog window is shown and xpdf exits immediately with
the following error:

  $ xpdf protected_file.pdf
  Error: Incorrect password
  $ echo $?
  1

On the other hand, if the user provides the correct password
through the command-line option:

  $ xpdf -upw my_secret_password protected_file.pdf

everything works fine and the file contents are correctly visualized.

Of course, requiring the user to provide a password on the command
line is not a good idea, from a security point of view: the password
(in clear) is visible to anyone who takes a look at the screen, it's 
saved in the shell history, and so forth.

As a consequence, I miss the old "insert password" dialog window!
Could this feature be restored, please?

Thanks for your time!


N.B.:
Before filing this bug report, I took a look at the already filed ones
and noticed bug #601375. I thought it could be the same issue, but it
probably isn't, since the file mentioned in that bug report gives me
a different error message:

  $ xpdf HTUSA-EBU4-3.pdf 
  Error: Weird encryption info
  Error: Incorrect password



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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xpdf depends on:
ii  lesstif2  1:0.95.2-1 OSF/Motif 2.1 implementation relea
ii  libc6 2.11.2-7   Embedded GNU C Library: Shared lib
ii  libgcc1   1:4.4.5-8  GCC support library
ii  libpoppler5   0.12.4-1.2 PDF rendering library
ii  libstdc++64.4.5-8The GNU Standard C++ Library v3
ii  libx11-6  2:1.3.3-4  X11 client-side library
ii  libxt61:1.0.7-1  X11 toolkit intrinsics library

Versions of packages xpdf recommends:
ii  gsfonts-x11   0.21   Make Ghostscript fonts available t
ii  poppler-data  0.4.3-1Encoding data for the poppler PDF 
ii  poppler-utils 0.12.4-1.2 PDF utilitites (based on libpopple

xpdf suggests no packages.

-- no debconf information


--- End Message ---
--- Begin Message ---
Source: xpdf
Source-Version: 3.04+git20210103-1
Done: Florian Schlichting 

We believe that the bug you reported is fixed in the latest version of
xpdf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 606...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Schlichting  (supplier of updated xpdf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 28 Jan 2021 15:58:32 +0800
Source: xpdf
Architecture: source
Version: 3.04+git20210103-1
Distribution: unstable
Urgency: medium
Maintainer: Florian Schlichting 
Changed-By: Florian Schlichting 
Closes: 606885 848631 863382 942086 945188 968354 971805 977182
Changes:
 xpdf (3.04+git20210103-1) unstable; urgency=medium
 .
   * Import new upstream version 3.04+git20210103
 + switch to xpopple as new upstream (closes: #977182)

Bug#942086: marked as done (xpdf: Memory leak on large document (even w/ continuousView turned off))

2021-01-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Jan 2021 08:19:59 +
with message-id 
and subject line Bug#942086: fixed in xpdf 3.04+git20210103-1
has caused the Debian Bug report #942086,
regarding xpdf: Memory leak on large document (even w/ continuousView turned 
off)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
942086: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942086
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xpdf
Version: 3.04-13
Severity: important

I have a PDF document which seems to cause xpdf to leak memory as I
advance through its pages.  The severity of the leak seems to scale
with the window size of xpdf, at least to some extent.

I don't think this is the same bug as #926501, because I experience
this with continuousView turned off.  I checked /etc/xpdf/xpdfrc and
~/.xpdfrc and didn't find continuousView listed in either file.  I
verified that it seems to be disabled for me (to ensure it's not
enabled by default) by checking the scrollbar: the scrollbar
represents only the current page.

In a 1276x2113 pixel window, xpdf starts by using 43752 KiB RSS while
displaying the first page.  If I advance through all pages of this
document until I get to the end, RSS climbs to 2052816 KiB (2.0 GiB).

In a 3840x2117 pixel window, xpdf starts on the same document using
55936 KiB RSS.  After advancing to the end, it finishes using 3309660
KiB (3.2 GiB) RSS.

I prefer xpdf because it's responsive and, until now, been very
lightweight in my experience.  However, this bug led me to compare
xpdf's memory utilization performance to that of evince.  On the same
document, in a 3840x2117 pixel window, evince version 3.30.2-3 starts
at 147144 KiB RSS.  After advancing to the end (and allowing enough
time for each page to render as I do so), evince finishes at 215876
KiB (211 MiB) RSS.

I configured both xpdf and evince to scale each page to fit the
window.

The document I'm experiencing this is with
https://www.andersonpower.com/content/dam/app/ecommerce/product-pdfs/CAT-PPMP.pdf
.  The version currently published there has these attributes:

  Size: 13529602 B (12.9 MiB)
  SHA256: 64079ffb140cca6c8747e9b0c9d88864098093b49e34a0e35399282467b09d73
  HTTP Last-Modified: Tue, 10 Sep 2019 15:46:50 GMT
  PDF ModDate: Tue Sep  4 12:29:21 2018 PDT
  Page count: 124

I've made sure that this version of the document is available at the
Internet Archive Wayback Machine at this URL:
https://web.archive.org/web/20191010060834/https://www.andersonpower.com/content/dam/app/ecommerce/product-pdfs/CAT-PPMP.pdf

I chose severity "important" because this is bad enough for me to stop
using xpdf until the bug can be addressed.  I lost 20 minutes to my
system thrashing in swap (with xpdf alongside other big RAM users
too).

Thanks,
-Jean-Paul

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xpdf depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libpaper1 1.1.28
ii  libpoppler82  0.71.0-5
ii  libstdc++68.3.0-6
ii  libx11-6  2:1.6.7-1
ii  libxm42.3.8-2
ii  libxt61:1.1.5-1+b3

Versions of packages xpdf recommends:
ii  cups-bsd2.2.10-6+deb10u1
ii  gsfonts-x11 0.26
ii  poppler-data0.4.9-2
ii  poppler-utils   0.71.0-5
ii  sensible-utils  0.0.12

xpdf suggests no packages.

-- no debconf information

-- 
J.P. Larocque 
--- End Message ---
--- Begin Message ---
Source: xpdf
Source-Version: 3.04+git20210103-1
Done: Florian Schlichting 

We believe that the bug you reported is fixed in the latest version of
xpdf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 942...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Schlichting  (supplier of updated xpdf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-

Bug#863382: marked as done (xpdf: Config Error: Unknown config file command 'errQuiet')

2021-01-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Jan 2021 08:19:59 +
with message-id 
and subject line Bug#863382: fixed in xpdf 3.04+git20210103-1
has caused the Debian Bug report #863382,
regarding xpdf: Config Error: Unknown config file command 'errQuiet'
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
863382: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863382
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xpdf
Version: 3.04-4
Severity: normal

Starting xpdf from a command line throws the error "Config Error: Unknown 
config file command 'errQuiet' (/home/user/.xpdfrc:3) 
According to the xpdfrc manpage, if errQuiet is set to yes it should suppress 
all warning and error messages.  The .xpdfrc file contains:

include /etc/xpdf/xpdfrc
urlCommand  "firefox-esr -new-tab '%s'"
errQuietyes

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xpdf depends on:
ii  libc6 2.24-10
ii  libgcc1   1:6.3.0-18
ii  libpoppler64  0.48.0-2
ii  libstdc++66.3.0-18
ii  libx11-6  2:1.6.4-3
ii  libxm42.3.4-13
ii  libxt61:1.1.5-1

Versions of packages xpdf recommends:
ii  cups-bsd   2.2.1-8
ii  gsfonts-x110.24
ii  poppler-data   0.4.7-8
ii  poppler-utils  0.48.0-2

xpdf suggests no packages.

-- Configuration Files:
/etc/xpdf/xpdfrc changed:
psFile  "|lpr"
urlCommand  "sensible-browser '%s'"
unbind down any
unbind right any
unbind up any
unbind left any
bind down window scrollDown(16) 
bind right window scrollRight(16)
bind up window scrollUp(16)
bind left window scrollLeft(16)
bind down fullScreen nextPage
bind right fullScreen nextPage
bind up fullScreen prevPage
bind left fullScreen prevPage


-- no debconf information
--- End Message ---
--- Begin Message ---
Source: xpdf
Source-Version: 3.04+git20210103-1
Done: Florian Schlichting 

We believe that the bug you reported is fixed in the latest version of
xpdf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 863...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Schlichting  (supplier of updated xpdf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 28 Jan 2021 15:58:32 +0800
Source: xpdf
Architecture: source
Version: 3.04+git20210103-1
Distribution: unstable
Urgency: medium
Maintainer: Florian Schlichting 
Changed-By: Florian Schlichting 
Closes: 606885 848631 863382 942086 945188 968354 971805 977182
Changes:
 xpdf (3.04+git20210103-1) unstable; urgency=medium
 .
   * Import new upstream version 3.04+git20210103
 + switch to xpopple as new upstream (closes: #977182)
 + fix obvious memory leaks (closes: #945188, #942086)
 + no longer crash on empty documents (closes: #968354)
 + properly ask for passwords (closes: #606885)
 + correctly recognize working and document obsolete config file commands
   (closes: #971805, #863382)
   * Drop patches, all applied in (or obsoleted by) xpopple upstream
   * Bump dh compat to level 13
   * Greatly simplify d/rules (but keep linking to libpaper)
   * Keep installing our xpdf wrapper script
   * Ensure wrapper script correctly handles all xpdf options
   * Add wrapper script options back to xpdf manpage
   * Drop obsolete language support files and infrastructure
   * Mention new upstream in relevant places, drop d/watch
   * Adopt xpdf (closes: #848631)
   * Ship TODO in docs
   * Add Rules-Requires-Root: no
   * Declare compliance with Debian Policy 4.5.1
Checksums-Sha1:
 40e2a06d4197afe5c59194743175ed5cb76bce55 1954 xpdf_3.04+git20210103-1.dsc
 c49eefa7d8a2359fa6f75d97753547340fe1158a 123005 
xpdf_3.04+git20210103.orig.tar.gz
 4b83474cdabc693f1bdf1f7c1c778c0446157781 23668 
xpdf_3.04+git20210103-1.debian.tar.xz
 9cad89f4b3518e7f8d6e58980da150431e24b8e0 8092 
xpdf_3.04+git20210103-1_amd64.buildinfo
Checksums-Sha256:
 3e47cdedacae8

Bug#971805: marked as done (Configuration file keyword 'textEncoding' not recognised)

2021-01-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Jan 2021 08:20:00 +
with message-id 
and subject line Bug#971805: fixed in xpdf 3.04+git20210103-1
has caused the Debian Bug report #971805,
regarding Configuration file keyword 'textEncoding' not recognised
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
971805: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971805
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xpdf
Version: 3.04-13

Like described in #863382 for a different config file command, xpdf reports

Config Error: Unknown config file command 'textEncoding' 
(/etc/xpdf/xpdfrc:)

when the config file contains it. However, xpdfrc(5) lists this option as 
valid.

I assume this needs to be fixed upstream - either in the code, or in the 
manpage.
--- End Message ---
--- Begin Message ---
Source: xpdf
Source-Version: 3.04+git20210103-1
Done: Florian Schlichting 

We believe that the bug you reported is fixed in the latest version of
xpdf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 971...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Schlichting  (supplier of updated xpdf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 28 Jan 2021 15:58:32 +0800
Source: xpdf
Architecture: source
Version: 3.04+git20210103-1
Distribution: unstable
Urgency: medium
Maintainer: Florian Schlichting 
Changed-By: Florian Schlichting 
Closes: 606885 848631 863382 942086 945188 968354 971805 977182
Changes:
 xpdf (3.04+git20210103-1) unstable; urgency=medium
 .
   * Import new upstream version 3.04+git20210103
 + switch to xpopple as new upstream (closes: #977182)
 + fix obvious memory leaks (closes: #945188, #942086)
 + no longer crash on empty documents (closes: #968354)
 + properly ask for passwords (closes: #606885)
 + correctly recognize working and document obsolete config file commands
   (closes: #971805, #863382)
   * Drop patches, all applied in (or obsoleted by) xpopple upstream
   * Bump dh compat to level 13
   * Greatly simplify d/rules (but keep linking to libpaper)
   * Keep installing our xpdf wrapper script
   * Ensure wrapper script correctly handles all xpdf options
   * Add wrapper script options back to xpdf manpage
   * Drop obsolete language support files and infrastructure
   * Mention new upstream in relevant places, drop d/watch
   * Adopt xpdf (closes: #848631)
   * Ship TODO in docs
   * Add Rules-Requires-Root: no
   * Declare compliance with Debian Policy 4.5.1
Checksums-Sha1:
 40e2a06d4197afe5c59194743175ed5cb76bce55 1954 xpdf_3.04+git20210103-1.dsc
 c49eefa7d8a2359fa6f75d97753547340fe1158a 123005 
xpdf_3.04+git20210103.orig.tar.gz
 4b83474cdabc693f1bdf1f7c1c778c0446157781 23668 
xpdf_3.04+git20210103-1.debian.tar.xz
 9cad89f4b3518e7f8d6e58980da150431e24b8e0 8092 
xpdf_3.04+git20210103-1_amd64.buildinfo
Checksums-Sha256:
 3e47cdedacae84aee3ec1cbf3151698afe3a2ca83bd0aaa4611dbaf0487968e5 1954 
xpdf_3.04+git20210103-1.dsc
 8c00465f2e362377459ec6d82c0bfe2df9b80ddd98d602e08f41c988efa56fc0 123005 
xpdf_3.04+git20210103.orig.tar.gz
 6504e23ca0ce5e8a91b17973d6fc5e73aefe0ccadba73707a1de4721d2f2ecce 23668 
xpdf_3.04+git20210103-1.debian.tar.xz
 bfc3e2a91a4a4df46f6aca43efbafdbd6b91350dbb0928ab31fdab3059e503cc 8092 
xpdf_3.04+git20210103-1_amd64.buildinfo
Files:
 b38ab56c1cc5eeef1ece34a05a280648 1954 text optional xpdf_3.04+git20210103-1.dsc
 80eaa44277edac0f6de780f13e1bb350 123005 text optional 
xpdf_3.04+git20210103.orig.tar.gz
 0662269a02ad92d16e0d2fced32301e5 23668 text optional 
xpdf_3.04+git20210103-1.debian.tar.xz
 e61a6d01cc94f6b03260a1c1a09f2f78 8092 text optional 
xpdf_3.04+git20210103-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEMLI8i05qOwnqprZSEpc7bnLcB7UFAmAScC8ACgkQEpc7bnLc
B7UsmBAAlXvbdIpZNFC4+ul+d2U8NvxmKburY+iS7pG0OzUSmfXjsGeiXDSuVlBk
wMI4pWlGFfLE86/nJKC0Ik7anG23GmBHdPrUeowyxFpEHPyoP23IBgu4xX7Jry4t
R7mSAV96vE62HKOabjas65oaKTEp8y1iXiJaqa0HB5YUvZUahtChGjQvvTry3mop
fa0EIF5BHYr7f0iNcHJy7GJwI6fZVVctHoqLCvKRU1eNj4jsUU2Ab/ddVff7OZfj
1R7vjEJz3MxhTwFCeYjY54rPwHOt2mS0l7/+FmAF531//sY1w9n9SFiIapu6fwYA
oz45ahF4DjvF1nR9WnAwkgWhrJEhcYsYK2

Bug#945188: marked as done (xpdf: memory leak when changing page)

2021-01-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Jan 2021 08:19:59 +
with message-id 
and subject line Bug#945188: fixed in xpdf 3.04+git20210103-1
has caused the Debian Bug report #945188,
regarding xpdf: memory leak when changing page
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
945188: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945188
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xpdf
Version: 3.04-13
Severity: important

When one changes the displayed page (e.g. with PageDown or PageUp),
xpdf takes more memory, even if the page has already been displayed
(thus this is not due to caching).

For instance, consider /usr/share/pari/doc/users.pdf from pari-doc.
It starts with 32 MB. And each time I do a PageDown or PageUp, it
takes an additional 16 MB.

One can easily end up filling the memory of the machine. This happened
to me several times, with my machine completely freezing for several
minutes, until I found out that xpdf was the main cause.

-- System Information:
Debian Release: bullseye/sid
  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 5.3.0-2-amd64 (SMP w/8 CPU cores)
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

Versions of packages xpdf depends on:
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-19
ii  libpaper1 1.1.28+b1
ii  libpoppler82  0.71.0-6
ii  libstdc++69.2.1-19
ii  libx11-6  2:1.6.8-1
ii  libxm42.3.8-2
ii  libxt61:1.1.5-1+b3

Versions of packages xpdf recommends:
ii  cups-bsd2.3.0-7
ii  gsfonts-x11 0.27
ii  poppler-data0.4.9-2
ii  poppler-utils   0.71.0-6
ii  sensible-utils  0.0.12

xpdf suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- End Message ---
--- Begin Message ---
Source: xpdf
Source-Version: 3.04+git20210103-1
Done: Florian Schlichting 

We believe that the bug you reported is fixed in the latest version of
xpdf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 945...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Schlichting  (supplier of updated xpdf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 28 Jan 2021 15:58:32 +0800
Source: xpdf
Architecture: source
Version: 3.04+git20210103-1
Distribution: unstable
Urgency: medium
Maintainer: Florian Schlichting 
Changed-By: Florian Schlichting 
Closes: 606885 848631 863382 942086 945188 968354 971805 977182
Changes:
 xpdf (3.04+git20210103-1) unstable; urgency=medium
 .
   * Import new upstream version 3.04+git20210103
 + switch to xpopple as new upstream (closes: #977182)
 + fix obvious memory leaks (closes: #945188, #942086)
 + no longer crash on empty documents (closes: #968354)
 + properly ask for passwords (closes: #606885)
 + correctly recognize working and document obsolete config file commands
   (closes: #971805, #863382)
   * Drop patches, all applied in (or obsoleted by) xpopple upstream
   * Bump dh compat to level 13
   * Greatly simplify d/rules (but keep linking to libpaper)
   * Keep installing our xpdf wrapper script
   * Ensure wrapper script correctly handles all xpdf options
   * Add wrapper script options back to xpdf manpage
   * Drop obsolete language support files and infrastructure
   * Mention new upstream in relevant places, drop d/watch
   * Adopt xpdf (closes: #848631)
   * Ship TODO in docs
   * Add Rules-Requires-Root: no
   * Declare compliance with Debian Policy 4.5.1
Checksums-Sha1:
 40e2a06d4197afe5c59194743175ed5cb76bce55 1954 xpdf_3.04+git20210103-1.dsc
 c49eefa7d8a2359fa6f75d97753547340fe1158a 123005 
xpdf_3.04+git20210103.orig.tar.gz
 4b83474cdabc693f1bdf1f7c1c778c0446157781 23668 
xpdf_3.04+git

Bug#977182: marked as done (xpdf: Switch to xpopple as new upstream for Debian's xpdf?)

2021-01-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Jan 2021 08:20:00 +
with message-id 
and subject line Bug#977182: fixed in xpdf 3.04+git20210103-1
has caused the Debian Bug report #977182,
regarding xpdf: Switch to xpopple as new upstream for Debian's xpdf?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
977182: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977182
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xpdf
Version: 3.04-14
Severity: important
X-Debbugs-Cc: Gianfranco Costamagna ,GOTO Masanori 
,Sebastien Bacher ,Iain Lane 


Dear people interested in Debian's xpdf,

looking at how things went with Debian's xpdf since Micheal orphaned the
package in 2016, I'm doubtful how long this is still feasible. In fact,
I thought it was already dead, when I found the xpopple repository,
which already contained all that was necessary to adapt to current
poppler (which still took several hours fighting or rather hand-patching).

I think if we want to continue to have a motif and poppler based xpdf in
Debian, we should switch to using xpopple as upstream. To this end I
wrote the below email (but failed to properly involve the bts).

This also relates to the question raised in #873951 whether we shouldn't
follow xpdf 4.x's switch to QT and related development, but given that
they're not using poppler, IMHO this is only going to be even more
complicated that continuing as before.

Florian

-

From: Florian Schlichting 
To: Adam Sampson 
Date: Fri, 11 Dec 2020 11:18:48 +0100
Subject: xpopple as new upstream for Debian's xpdf?

Hi Adam,

the other day, when I looked into the build failures that have kept
Debian's xpdf package out of the upcoming release for several months, I
happened upon your xpopple project (http://offog.org/code/xpopple/),
which I hadn't been aware of before. It seems that since 2014, you've
been doing right what we've struggled to do in Debian: deleting obsolete
code, moving files for good instead of just for the build, applying
patches instead of fighting with an unwieldy quilt queue, and most of
all: following poppler development closely, updating xpdf accordingly
while cleaning up some legacy code. This has been enormously helpful
for my recent upload, thanks a ton!

>From my position it looks like Debian should stop what it's been
increasingly unable to accomplish properly, and instead switch over to
xpopple as its upstream source for the xpdf package.

Do you think xpopple is ready for that? Are there areas where xpopple
does not provide any features that Debian's xpdf currently offers? (I
notice you're based off xpdf 3.03, but am unable to judge which parts if
any of the 3.04 changelog apply to the part that we're still using; the
new text extractor seems to be patched out again?)

And: Are you interested to act as upstream developer for what may be a
substantial user base, which can come up with all kinds of problems and
suggestions not related to your personal use case?

(Cc the Debian bug tracker so that other people interested in xpdf can
know what's going on; I might be able to help with packaging and bug
triaging, but I've never found the time to familiarize myself with
poppler enough to know what's going on)

Looking forward to hear from you!
Florian
--- End Message ---
--- Begin Message ---
Source: xpdf
Source-Version: 3.04+git20210103-1
Done: Florian Schlichting 

We believe that the bug you reported is fixed in the latest version of
xpdf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 977...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Schlichting  (supplier of updated xpdf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 28 Jan 2021 15:58:32 +0800
Source: xpdf
Architecture: source
Version: 3.04+git20210103-1
Distribution: unstable
Urgency: medium
Maintainer: Florian Schlichting 
Changed-By: Florian Schlichting 
Closes: 606885 848631 863382 942086 945188 968354 971805 977182
Changes:
 xpdf (3.04+git20210103-1) unstable; urgency=medium
 .
   * Import new upstream version 3.04+git20210103
 + switch to xpoppl

Bug#968354: marked as done (xpdf crash with empty document)

2021-01-28 Thread Debian Bug Tracking System 
Your message dated Thu, 28 Jan 2021 08:19:59 +
with message-id 
and subject line Bug#968354: fixed in xpdf 3.04+git20210103-1
has caused the Debian Bug report #968354,
regarding xpdf crash with empty document
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
968354: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968354
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: xpdf
Version: 3.04-13
Severity: normal
Tag: security

On Debian Bullseye this crashes xpdf with coredump:

touch x.pdf; xpdf x.pdf

Funny, after a 2-byte Virtualbox (and now qemu) crash, this is 
the shortest input for a DoS-bug I have seen so far :-)

For xpdf this bug itself is not really a security risk: an attacker
could also send a white page document or no document at all if
he wants the victim not to see a document. Still someone familiar
with the code should look at it, maybe some half-broken document
could turn the NULL-dereference into something more useful.

rax0x0 0

   0x5556e6d0 <+16>:je 0x5556e6e0 

   0x5556e6d2 <+18>:mov%ebp,%eax
   0x5556e6d4 <+20>:pop%rbx
   0x5556e6d5 <+21>:pop%rbp
   0x5556e6d6 <+22>:pop%r12
   0x5556e6d8 <+24>:retq   
   0x5556e6d9 <+25>:nopl   0x0(%rax)
   0x5556e6e0 <+32>:mov0x8(%rbx),%rax
=> 0x5556e6e4 <+36>:mov(%rax),%rax   (doc is null)
   0x5556e6e7 <+39>:mov(%rax),%rdi 
   0x5556e6ea <+42>:callq  0x5557d730 


Relevant source:

int XPDFCore::loadFile(const GString *fileName, GString *ownerPassword,
   GString *userPassword) {
  int err;

  err = PDFCore::loadFile(fileName, ownerPassword, userPassword);
  if (err == errNone) {
// save the modification time
modTime = getModTime(doc->getFileName()->getCString());

// update the parent window
if (updateCbk) {
  (*updateCbk)(updateCbkData, doc->getFileName(), -1,
   doc->getNumPages(), NULL);
}
  }
  return err;
}

(gdb) print doc
$1 = (PDFDoc *) 0x0

If understand correctly, "PDFCore::loadFile" does not return
an error when processing an empty file, but also does not set
static variable "doc". This seems to be due to "xpdf/PDFCore.cc":

int PDFCore::loadFile2(PDFDoc *newDoc) {
  int err;
  double w, h, t;
  int i;

  // open the PDF file
  if (!newDoc->isOk()) {
err = newDoc->getErrorCode();
delete newDoc;
return err;
  }

...

The PDFDoc seems to come from "libpoppler.so.82" already and
detects the problem:

Syntax Error: Document stream is empty

On a quick glance I could not see this may result in !isOk()
but also "err" not set correctly. If error should be in libpoppler,
then this is the relevant version:

ii  libpoppler82:amd64   0.71.0-6
amd64PDF rendering library
--- End Message ---
--- Begin Message ---
Source: xpdf
Source-Version: 3.04+git20210103-1
Done: Florian Schlichting 

We believe that the bug you reported is fixed in the latest version of
xpdf, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 968...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Schlichting  (supplier of updated xpdf package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 28 Jan 2021 15:58:32 +0800
Source: xpdf
Architecture: source
Version: 3.04+git20210103-1
Distribution: unstable
Urgency: medium
Maintainer: Florian Schlichting 
Changed-By: Florian Schlichting 
Closes: 606885 848631 863382 942086 945188 968354 971805 977182
Changes:
 xpdf (3.04+git20210103-1) unstable; urgency=medium
 .
   * Import new upstream version 3.04+git20210103
 + switch to xpopple as new upstream (closes: #977182)
 + fix obvious memory leaks (closes: #945188, #942086)
 + no longer crash on empty documents (closes: #968354)
 + properly ask for passwords (closes: #606885)
 + correctly recognize working and document obsolete config file commands
   (closes: #971805, #863382)
   * Drop patches, all applied in (or obsoleted

Bug#981244: ssmtp “FromLineOverride=NO” has no impact

2021-01-28 Thread René Neumaier 
Package: ssmtp
Version: 2.64-9 amd64

A new lxd container with debian testing/bullseye has to send emails to
a SMTP-Relay. The chosen software is ssmtp 2.64-9 and the configuration
looks like that:

(not auth internal relay)

/etc/ssmtp/revaliases

# sSMTP aliases
# 
# Format:   local_account:outgoing_address:mailhub
#
# Example: root:your_login@your.domain:mailhub.your.domain[:port]
# where [:port] is an optional port number that defaults to 25.
root:ad...@example.com:mailout.example.com
www-data:ad...@example.com:mailout.example.com


/etc/ssmtp/ssmtp.conf

#
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=ad...@example.com

# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named ...
mailhub=mailout.example.com

# Where will the mail seem to come from?
#rewriteDomain=

# The full hostname
hostname=srv0815

# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
FromLineOverride=NO


I can send an email as following and everything looks like expected:

www-data@srv0815:~# echo "Test message" | mail -s "Test message - is
from?" it...@example.com


But if I send an email with an additional "from address" like this...

www-data@srv0815:~# echo "Test message" | mail -s "Test message - is
from?" it...@example.com -a From:otheraddr...@example.com


...I will receive the email with the given "From address" (e.g. From:
otheraddr...@example.com). But this shouldn't be possible!? I've
explicitly set "FromLineOverride=NO" in my configuration. Therefore, as
far as I know, ssmtp should ignore any additional "from address".

The same configuration works as expected on another container with
gentoo linux (its ssmtp-2.64-r3 here). Probably the same upstream
version.

Also, I've tried an older ssmtp version on the same lxd container:
ssmtp-2.64-8.1+b1

With 2.64-8.1+b1, no issues. The additional from parameter will be
ignored correctly.

I think it could be a bug in the current testing version of ssmtp.


Best,
René

-- 
_
GPG-Fingerprint:
EC0E B6F6 B3FF 6324 B0C8 9452 EF6B 4E3C 2E59 F5AA


signature.asc
Description: This is a digitally signed message part

Villas front de Mer à Dar Bouazza à partir de 2.8M Dhs seulement!

2021-01-28 Thread BEACHFRONT VILLAS 
In order to see your message, click on the following link: 
http://link.news-sarouty.ma/v/443/de86ac2aa9610f176dcfa84aa17079f28de5a97f6a48af20

Appartements sans vis-à-vis avec une vue imprenable à Casablanca Finance City!

2021-01-28 Thread AERIA PARK 
In order to see your message, click on the following link: 
http://link.news-sarouty.ma/v/443/de86ac2aa9610f178baab2464d5513158de5a97f6a48af20

Bug#981276: pexec FTCBFS: help2man

2021-01-28 Thread Helmut Grohne 
Source: pexec
Version: 1.0~rc8-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pexec fails to cross build from source, because it uses help2man. Given
that pexec has very little dependencies, we can add a native build pass
for generating the manual page before performing the cross build. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru pexec-1.0~rc8/debian/changelog 
pexec-1.0~rc8/debian/changelog
--- pexec-1.0~rc8/debian/changelog  2018-07-11 14:54:41.0 +0200
+++ pexec-1.0~rc8/debian/changelog  2021-01-28 16:19:44.0 +0100
@@ -1,3 +1,9 @@
+pexec (1.0~rc8-5) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Add a native build pass for help2man. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 Jan 2021 16:19:44 +0100
+
 pexec (1.0~rc8-4) unstable; urgency=medium
 
   * Orphaned.
diff --minimal -Nru pexec-1.0~rc8/debian/rules pexec-1.0~rc8/debian/rules
--- pexec-1.0~rc8/debian/rules  2012-06-04 20:31:15.0 +0200
+++ pexec-1.0~rc8/debian/rules  2021-01-28 16:18:51.0 +0100
@@ -45,6 +45,13 @@
 
 config.status: configure
dh_testdir
+ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
+   ./configure
+   $(MAKE) man
+   mv doc/pexec.1 doc/pexec.1.orig
+   $(MAKE) clean
+   mv doc/pexec.1.orig doc/pexec.1
+endif
./configure $(CROSS) --prefix=/usr --mandir=\$${prefix}/share/man 
--infodir=\$${prefix}/share/info CFLAGS="$(CFLAGS)" LDFLAGS="-Wl,-z,defs"
 
 build: build-arch build-indep

Bug#951770: libpam-radius-auth: do not release in bullseye without active maintainer

2021-01-28 Thread Carsten Schoenert 
retitle -1 ITA: picking up maintenance of libpam-radius-auth

Hello Salvatore,

Am Fri, Feb 21, 2020 at 03:03:12PM +0100 schrieb Salvatore Bonaccorso:
> Source: libpam-radius-auth
> Version: 1.4.0-3
> Severity: serious
> Justification: should not be released in bullseye without active maintainer
> 
> libpam-radius-auth has been orphaned in Debian since several years and
> QA maintained. It did had at least the CVE-2015-9542 security issue.
> 
> There are no packages blocking a potential removal, so the package
> should get an active maintainer to be part of bullseye ideally.

Christoph Goehre and myself are taking over the maintenace of this
package, we use RADIUS authentication daily on our day job and we have a
strong interrest that this package will stay in Debian. ;)

Regards
Carsten

Bug#951770: libpam-radius-auth: do not release in bullseye without active maintainer

2021-01-28 Thread Salvatore Bonaccorso 
Hi Carsten, hi Christoph,

On Thu, Jan 28, 2021 at 05:15:46PM +0100, Carsten Schoenert wrote:
> retitle -1 ITA: picking up maintenance of libpam-radius-auth
> 
> Hello Salvatore,
> 
> Am Fri, Feb 21, 2020 at 03:03:12PM +0100 schrieb Salvatore Bonaccorso:
> > Source: libpam-radius-auth
> > Version: 1.4.0-3
> > Severity: serious
> > Justification: should not be released in bullseye without active maintainer
> > 
> > libpam-radius-auth has been orphaned in Debian since several years and
> > QA maintained. It did had at least the CVE-2015-9542 security issue.
> > 
> > There are no packages blocking a potential removal, so the package
> > should get an active maintainer to be part of bullseye ideally.
> 
> Christoph Goehre and myself are taking over the maintenace of this
> package, we use RADIUS authentication daily on our day job and we have a
> strong interrest that this package will stay in Debian. ;)

That is perfect, thank you in this case of taking care of it!

Regards,
Salvatore

Bug#981310: tcm FTCBFS: uses the build architecture compiler

2021-01-28 Thread Helmut Grohne 
Source: tcm
Version: 2.20+TSQD-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tcm fails to cross build from source, because it does not pass cross
tools to make. Since it does not use the standard variable names, using
dh_auto_build is not helpful here. Passing them explicitly makes tcm
cross build. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tcm-2.20+TSQD/debian/changelog 
tcm-2.20+TSQD/debian/changelog
--- tcm-2.20+TSQD/debian/changelog  2020-08-02 22:17:38.0 +0200
+++ tcm-2.20+TSQD/debian/changelog  2021-01-28 16:57:06.0 +0100
@@ -1,3 +1,9 @@
+tcm (2.20+TSQD-7) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 28 Jan 2021 16:57:06 +0100
+
 tcm (2.20+TSQD-6) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru tcm-2.20+TSQD/debian/rules tcm-2.20+TSQD/debian/rules
--- tcm-2.20+TSQD/debian/rules  2020-08-02 22:08:21.0 +0200
+++ tcm-2.20+TSQD/debian/rules  2021-01-28 16:57:06.0 +0100
@@ -3,6 +3,8 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+include /usr/share/dpkg/buildtools.mk
+
 CFLAGS = -Wall -g
 CFLAGS += -fcommon
 
@@ -27,7 +29,9 @@
 build-stamp: configure-stamp
dh_testdir
 
-   $(MAKE) CFLAGS='$(CFLAGS) -DCONFIG_INSTALL=\"/etc/tcm/\" 
-DTCM_INSTALL_DIR=\"/usr\" -DTCM_INSTALL_LIB=\"/usr/lib/\" 
-DTCM_INSTALL_SHARE=\"/usr/share/doc/tcm-doc/\" -DCONFIG_FILE=\"tcm.conf\" 
-DHELP_DIR=\"/usr/share/doc/tcm-doc/help/\" -DCOLOR_FILE=\"colorrgb.txt\" 
-DBANNER_FILE=\"banner.ps\"' \
+   $(MAKE) Cc='$(CC)' \
+   CC='$(CXX)' \
+   CFLAGS='$(CFLAGS) -DCONFIG_INSTALL=\"/etc/tcm/\" 
-DTCM_INSTALL_DIR=\"/usr\" -DTCM_INSTALL_LIB=\"/usr/lib/\" 
-DTCM_INSTALL_SHARE=\"/usr/share/doc/tcm-doc/\" -DCONFIG_FILE=\"tcm.conf\" 
-DHELP_DIR=\"/usr/share/doc/tcm-doc/help/\" -DCOLOR_FILE=\"colorrgb.txt\" 
-DBANNER_FILE=\"banner.ps\"' \
TCM_INSTALL_DIR=/usr \
CONFIG_INSTALL=/etc/tcm/ \
TCM_INSTALL_DOC=/usr/share/doc/tcm-doc \