Bug#972189: sympa: CVE-2020-10936 regression - removal of needed environment variables

[Sylvain Beucler]

Hi,

From what I understand the FCGI wrapper was used as CGI through e.g. 
fcgiwrap, and upstream recommended to switch to fcgi-spawn following 
https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html


Carsten agreed and suggested we add a note about this in the Debian 
documentation, so I plan to add a note in README.Debian or NEWS.Debian.

https://github.com/sympa-community/sympa/issues/1020#issuecomment-710763168

Given there were no other reports I believe this addresses the issue.

Cheers!
Sylvain Beucler
Debian LTS Team

Bug#973767: dolfin FTBFS: The MPI_Comm_rank() function was called before MPI_INIT was invoked.

[Drew Parsons]

Source: dolfin
Followup-For: Bug #973767

Yeah, I'm more certain SLEPc is the problem.  In the new release they
abolishing SLEPc.pc, renaming it slepc.pc.  Since pkg-config is
case-sensitive, the unexpected change is causing problems. 

Notice how the reported error is only with dolfin64. Because the
proper SLEPc is not detected, the 64-bit build is mixing up 32-bit and
64-bit builds of PETSc and SLEPc.

Resolution in progress.

Bug#954271: libsys-sigaction-perl: arm64 autopkgtest time out

[Adrian Bunk]

Control: forwarded -1 https://github.com/labaxter/sys-sigaction/issues/2
Control: tags -1 buster bullseye sid

On Thu, Apr 23, 2020 at 10:06:47PM +0300, Niko Tyni wrote:
> On Thu, Mar 19, 2020 at 03:20:34PM +0100, Paul Gevers wrote:
> > Source: libsys-sigaction-perl
> > Version: 0.23-1
> > Severity: important
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: timeout
>  
> > libsys-sigaction-perl fails its autopkgtest on arm64 due to a time out
> > after 2h47. Can you please investigate the situation?
> > 
> > To avoid wasting lots of time on the ci.debian.net infrastructure, I
> > have added your package to the ignore list for arm64.
> 
> Thanks.
> 
> The module has several upstream workarounds for arm platforms, but those
> aren't used for arm64 because its $Config{archname} starts with 'aarch64'
> not 'arm'.
> 
> The comments point to defects in either the arm platform or the base Perl
> implementation there. I don't know if these things have been triaged on
> the Perl side upstream.
> 
> Possibly we should make this arch:any to see if there are other
> problematic architectures. Or just tune the test suite to skip on aarch64
> as well.
>...

In Debian the test hangs since buster, but succeeds in stretch:
https://tests.reproducible-builds.org/debian/rb-pkg/buster/arm64/libsys-sigaction-perl.html

libsys-sigaction-perl hasn't changed since stretch.

Someone else recently reported the same issue elsewhere also for arm64,
see the forwarded URL above.

> Niko

cu
Adrian

Bug#973890: RM: tty-server/0.0~git20201105.50b9367+ds-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Fri, 2020-11-06 at 21:26 +, Francisco Vilmar Cardoso Ruviaro
wrote:
> Please, remove the tty-server from testing because it was deprecated
> by tty-proxy.

That will happen automatically once the package is removed from
unstable.

Is there a reason that testing removal can't / shouldn't just wait for
that?

Regards,

Adam

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

[Felix Lechner]

Hi Pierre-Elliott,

On Fri, Nov 6, 2020 at 5:20 AM Pierre-Elliott Bécue  wrote:
>
> A technical project consisting of people who may have opinions, even
> some based on non-very-technical aspects.

There are no "non-technical" aspects in my effort to provide the best
possible service, aside from being a nice person, despite your
tendency to insert them. This is a bug report.

> Because I made an assumption on your intents and tried to tell you
> something you don't want to hear, which is that it should stay in Debian
> infra?

The solution provided on the current Debian infrastructure has
performed poorly for a long time (and well before my arrival). There
is nothing untoward about my intentions. The prominence of your
suspicions in your reasoning cannot change it. You are either being
manipulative, or you are trying to provoke a reaction. Either way,
your accusations have no basis.

> Come on, you should accept the idea that other people has
> different opinions than yours and have a right to state these. The
> "it's not technical" argument is not a valid answer.

Again, this is a bug report. Please be your own judge.

> The fact that you are working on a
> project does not mean others can't express concerns and raise their
> voice if they think the decisions you seem to be willing to take are
> bad.

Please explain which of my contributions to Lintian are "bad". I
regularly reverse changes that did not deliver the expected benefits.
Many of Lintian's bug reports are also about changes I made that did
not work. To the best of my ability, I respond timely. I challenge you
to prove otherwise. Your suggestion that I am reluctant to engage with
criticism is unsupported and faise.

My point is further bolstered by this letter. Its writing consumed
valuable time and kept me from contributing in other and probably more
productive ways.

> I'm not coercing you and the way you represent it is your sole
> interpretation, which is a bit scary.

You yourself wrote that you made assumptions about my intentions. (You
offer no details, but they are presumably unbecoming.) Plus, you raise
no technical points. Like it or not, the effect of your messages is to
malign and intimidate.

> I don't have to mention technical concerns to have a right to feel
> ill-at-ease with the idea of seeing lintian.debian.org disappear in
> favour of an externally hosted service. But actually, "it's
> Debian-centric and used by core components, so it's better having it
> in our infrastructure" also is a technical concern.

I agree with you. Unfortunately, the infrastructure provided by DSA is
presently insufficient for the service people expect. (Just look at
this bug.) Your point is therefore hypothetical.

Eventually, I plan to approach DSA with a wishlist for deployment on
Debian hardware. As I stated previously, I am not ready because I am
still experimenting.

> This is what I call a test version.

What an odd point to make! In my first response to this bug, I called
it an experiment. The words mean the same thing.

> DSA delivers machines, what you do of these is your call. See
> nm.debian.org, which is auto-deployed when we release on master et al.

Thank you for your thoughtful reference. I previously watched Enrico's
talk [1] with great interest and also multiple times. Unfortunately,
the mechanism does not cover the automatic installation of runtime
prerequisites and is probably not helpful for Lintian (although it may
be for the website).

Please also keep in mind that the Lintian maintainers try to produce
data for lintian.d.o with released versions (for easier comparison
with the BTS). Upon reflection, Debian's packaging system is ideally
suited to solve those issues.

[1] https://debconf18.debconf.org/talks/71-autodeploy-from-salsa/

> Surely, that excludes tracker.debian.org, wiki.debian.org,
> nm.debian.org, ddpo.debian.org, udd.debian.org, …

All I can say is, it was the response I got.

> I can't see how and why DSA would forbid you to have a new website set
> in production on lintian.debian.org, and if they do, that's probably
> something worth a discussion on debian-devel to have things explained
> and understood, don't you think?

At this point, I do not think such a broad call for assistance is
necessary. It also would not be helpful for my negotiations. My
counterparties at DSA will assume that I tried to sidestep them. It
embarrasses them and violates their trust. It is an awful way to beg
for understanding and compromise. I hope you understand.

DSA will eventually have to engage in a conversation when I present a
viable alternative. (If not, I will ask for your help.) For the time
being, I am developing both websites in parallel. Most of my work has
gone to the static one. The dynamic website is not even up yet.

> Just because you feel hurt by the fact someone tries to tell you you
> should reconsider an idea doesn't mean their opinion or suggestion is
> moot. I'm sorry if you're feeling hurt, but I stand my 

Bug#973889: raptor2: CVE-2017-18926

[Salvatore Bonaccorso]

Source: raptor2
Version: 2.0.14-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for raptor2.

CVE-2017-18926[0]:
| raptor_xml_writer_start_element_common in raptor_xml_writer.c in
| Raptor RDF Syntax Library 2.0.15 miscalculates the maximum nspace
| declarations for the XML writer, leading to heap-based buffer
| overflows (sometimes seen in raptor_qname_format_as_xml).


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-18926
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18926
[1] 
https://github.com/LibreOffice/core/blob/master/external/redland/raptor/0001-Calcualte-max-nspace-declarations-correctly-for-XML-.patch.1
[2] https://www.openwall.com/lists/oss-security/2017/06/07/1

Regards,
Salvatore

Bug#973889: raptor2: diff for NMU version 2.0.14-1.1

[Salvatore Bonaccorso]

Control: tags 973889 + patch
Control: tags 973889 + pending

Dear maintainer,

I've prepared an NMU for raptor2 (versioned as 2.0.14-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru raptor2-2.0.14/debian/changelog raptor2-2.0.14/debian/changelog
--- raptor2-2.0.14/debian/changelog	2014-05-05 20:15:34.0 +0200
+++ raptor2-2.0.14/debian/changelog	2020-11-06 22:08:54.0 +0100
@@ -1,3 +1,11 @@
+raptor2 (2.0.14-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Calcualte max nspace declarations correctly for XML writer
+(CVE-2017-18926) (Closes: #973889)
+
+ -- Salvatore Bonaccorso   Fri, 06 Nov 2020 22:08:54 +0100
+
 raptor2 (2.0.14-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch
--- raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch	1970-01-01 01:00:00.0 +0100
+++ raptor2-2.0.14/debian/patches/Calcualte-max-nspace-declarations-correctly-for-XML-.patch	2020-11-06 22:08:54.0 +0100
@@ -0,0 +1,45 @@
+From: Dave Beckett 
+Date: Sun, 16 Apr 2017 23:15:12 +0100
+Subject: Calcualte max nspace declarations correctly for XML writer
+Origin: https://github.com/dajobe/raptor/commit/590681e546cd9aa18d57dc2ea1858cb734a3863f
+Bug-Debian: https://bugs.debian.org/973889
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-18926
+
+(raptor_xml_writer_start_element_common): Calculate max including for
+each attribute a potential name and value.
+
+Fixes Issues #617 http://bugs.librdf.org/mantis/view.php?id=617
+and #618 http://bugs.librdf.org/mantis/view.php?id=618
+---
+ src/raptor_xml_writer.c | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/raptor_xml_writer.c b/src/raptor_xml_writer.c
+index 693b946863e6..0d3a36a5a21c 100644
+--- a/src/raptor_xml_writer.c
 b/src/raptor_xml_writer.c
+@@ -181,9 +181,10 @@ raptor_xml_writer_start_element_common(raptor_xml_writer* xml_writer,
+   size_t nspace_declarations_count = 0;  
+   unsigned int i;
+ 
+-  /* max is 1 per element and 1 for each attribute + size of declared */
+   if(nstack) {
+-int nspace_max_count = element->attribute_count+1;
++int nspace_max_count = element->attribute_count * 2; /* attr and value */
++if(element->name->nspace)
++  nspace_max_count++;
+ if(element->declared_nspaces)
+   nspace_max_count += raptor_sequence_size(element->declared_nspaces);
+ if(element->xml_language)
+@@ -237,7 +238,7 @@ raptor_xml_writer_start_element_common(raptor_xml_writer* xml_writer,
+ }
+   }
+ 
+-  /* Add the attribute + value */
++  /* Add the attribute's value */
+   nspace_declarations[nspace_declarations_count].declaration=
+ raptor_qname_format_as_xml(element->attributes[i],
+_declarations[nspace_declarations_count].length);
+-- 
+2.29.1
+
diff -Nru raptor2-2.0.14/debian/patches/series raptor2-2.0.14/debian/patches/series
--- raptor2-2.0.14/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ raptor2-2.0.14/debian/patches/series	2020-11-06 22:08:54.0 +0100
@@ -0,0 +1 @@
+Calcualte-max-nspace-declarations-correctly-for-XML-.patch


signature.asc
Description: PGP signature

Bug#973333: lintian.d.o: please add a symlink/redirect to the most recent version

[Pierre-Elliott Bécue]

Hi Felix,

Le vendredi 06 novembre 2020 à 14:01:22-0800, Felix Lechner a écrit :
> Hi Pierre-Elliott,
> 
> On Fri, Nov 6, 2020 at 5:20 AM Pierre-Elliott Bécue  wrote:
> >
> > A technical project consisting of people who may have opinions, even
> > some based on non-very-technical aspects.
> 
> There are no "non-technical" aspects in my effort to provide the best
> possible service, aside from being a nice person, despite your
> tendency to insert them. This is a bug report.

In my opinion (and I failed to find any Debian resource telling
otherwise), a bug report does not necessarily have to stick to technical
aspects, and is a perfectly valid place to raise such questions. I
thought it'd be better than redirecting this matter on debian-devel or
other without prior discussion, especially to avoid involving a load of
people which would indeed have been aggressive.

> > Because I made an assumption on your intents and tried to tell you
> > something you don't want to hear, which is that it should stay in Debian
> > infra?
> 
> The solution provided on the current Debian infrastructure has
> performed poorly for a long time (and well before my arrival).

The lintian.debian.org website, probably. The infrastructure is just a
machine and I don't see how it could perform poorly except if it lacks
physical resources.

> There is nothing untoward about my intentions. The prominence of your
> suspicions in your reasoning cannot change it. You are either being
> manipulative, or you are trying to provoke a reaction. Either way,
> your accusations have no basis.

I'll be blunt, but you should really review the way you interact with
people if you see manipulation or aggression in a question raised along
with concerns. As I see it, your reaction is as much inappropriate as
you claim my message is.

When someone comes and say "It feels to me that you could have the
intent to move the *production* lintian site out of Debian's machines.",
which is voluntarily written as hypotheticall, it means that one wonders
if it is your intention, and, indeed, to avoid accusation, it is turned
as an hypothesis.

Feeling attacked by someone asking if you intend to do something and if
so, that they think it could be a bad idea is something that prompts me
to tell you, as you do downwards, /please get some rest/.

> 
> > Come on, you should accept the idea that other people has
> > different opinions than yours and have a right to state these. The
> > "it's not technical" argument is not a valid answer.
> 
> Again, this is a bug report. Please be your own judge.

And it's easy to say why and how someone could see "moving part of an
infra outside Debian" as a bug. I'm fine with asking it here, but if you
feel like there'd be a better place, please do tell and I'll be glad to
forward our discussion there.

> > The fact that you are working on a
> > project does not mean others can't express concerns and raise their
> > voice if they think the decisions you seem to be willing to take are
> > bad.
> 
> Please explain which of my contributions to Lintian are "bad". I
> regularly reverse changes that did not deliver the expected benefits.
> Many of Lintian's bug reports are also about changes I made that did
> not work. To the best of my ability, I respond timely. I challenge you
> to prove otherwise. Your suggestion that I am reluctant to engage with
> criticism is unsupported and faise.

You seem (to me) reluctant to engage with criticism in that very case: I
came with a simple question and you actually jumped at me, telling that
I was forcing you to do something and intimidating you. That is not fine
at all.

Furthermore, I did not tell that any of your contributions to Lintian
were bad, but I do tell that if you were willing to have, on the long
run, the *production* lintian website hosted outside of the Debian
infrastructure, then I think it would be a bad decision. I may be wrong,
but that is what I think.

> My point is further bolstered by this letter. Its writing consumed
> valuable time and kept me from contributing in other and probably more
> productive ways.

Feel free to ignore me then, but I'm pretty convinced this discussion is
useful, as I'm clearly trying to understand your thoughts and vision for
lintian (the tool and the website), which are not written anywhere I
could find (maybe I did missearch).

> > I'm not coercing you and the way you represent it is your sole
> > interpretation, which is a bit scary.
> 
> You yourself wrote that you made assumptions about my intentions.

Yes I did. Assuming one's intentions is not being coercitive, and having
that person implying that I am trying to coerce them is their own
interpretation, and scary, because nothing in my message could imply
that I want to force you doing anything. And as I don't, I'd rather you
to avoid telling that.

> (You offer no details, but they are presumably unbecoming.) Plus, you
> raise no technical points. Like it or not, the effect of your messages
> is 

Bug#963509: prospector: Version 1.3.1 now available

[Rogério Brito]

Package: prospector
Version: 1.1.7-2
Followup-For: Bug #963509
X-Debbugs-Cc: team+pyt...@tracker.debian.org, locutusofb...@debian.org, 
mat...@debian.org, czc...@debian.org

Hi.

There is a new version of prospector upstream at

https://pypi.org/project/prospector/

that is supposed to fix all the problems that are currently in debian (read:
prospector doesn't work at all).

I'm including in the CC some of the people that last touched the package (at
least according to changelog.Debian.gz in my system). If anybody could fix
it, that would be awesome.


Thanks,

Rogério Brito.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages prospector depends on:
ii  dodgy  0.1.9-3
ii  libjs-sphinxdoc3.2.1-2
ii  pylint 2.6.0-1
ii  python33.8.2-3
ii  python3-astroid2.4.2-1
ii  python3-mccabe 0.6.1-3
ii  python3-mypy   0.790-2
ii  python3-pep8-naming0.10.0-1
ii  python3-pycodestyle2.6.0-1
ii  python3-pydocstyle 2.1.1-1
ii  python3-pyflakes   2.2.0-1
ii  python3-pylint-celery  0.3-5
ii  python3-pylint-django  2.0.13-1
ii  python3-pylint-flask   0.5-4
ii  python3-pylint-plugin-utils0.6-1
ii  python3-pyroma 2.6b2-1
ii  python3-requirements-detector  0.6-2
ii  python3-setoptconf 0.2.0-5
ii  python3-typed-ast  1.4.1-1+b2
ii  python3-yaml   5.3.1-3

Versions of packages prospector recommends:
ii  vulture  2.1-1

prospector suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#973822: ITP: dosbox-staging -- DOSBox Staging is a full x86 CPU emulator (independent of host architecture), capable of running DOS programs that require real or protected mode.

[Ben Hutchings]

On Fri, 2020-11-06 at 17:55 +0100, David Heidelberg wrote:
> Hello Ben,
> 
> I asked about possibility of changing name and the final reply is [1].
> 
> Quoting dreamer:
> Right now, we are fighting to convince users (and developers) to move 
> on from using a myriad of tiny DOSBox forks (link - very incomplete, 
> there are ~50 other dead forks I know of) or maintain their own 
> patchsets based on 10-year old 0.74. We have already certain (hard 
> thought for) recognition and community formed up - changing name at 
> this point will only cause confusion and hurt the project's prospects 
> for future.

Oh well, thanks for asking anyway.  I suggest you make the long
description clearly state that this is independent of the original
DOSBox project.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.




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

Bug#973884: make-dfsg: fix for extraordinarily-long command lines (#688601) has gone missing

[Mike Crowe]

Source: make-dfsg
Severity: normal

Dear Maintainer,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688601 was fixed back in
2014 by applying a patch (dgit:407e2fb3130d4540482a04987222dead70936122)
and this fix worked well for us for several years.

Unfortunately, this change appears to have been removed as part of:

 commit 0e957340243587eeffb525aff3200b5e143ac274
 Author: Manoj Srivastava 
 Date:   Mon Feb 12 16:26:34 2018 -0800

 [master]: revert debian specific patches that have been integrated 
differently upstream.

 Signed-off-by: Manoj Srivastava 

so this fix is no longer present in Buster, and apparently Bullseye. I've
been unable to find any other information about reverting the fix.

The main part of the original patch still applied and the conflicts in the
configure.ac file appeared to be straightforward to resolve. The resulting
patch is attached. Applying it fixed the problem for me.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (400, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
commit f079489160d620e5eb50dc09e51f09f71a7dcffb
Author: Mike Crowe 
Date:   Fri Nov 6 15:22:37 2020 +

Resurrect fix for large command line

This patch was originally applied by Manoj Srivastava to fix Debian bug
other changes that had apparently been fixed differently upstream. That
turns out not to have been true for this particular fix.

The original patch description follows.

---8<---
[handle_excessive_command_length]: Patch to fix large cmmand line

When presented with a very very long command line (e.g. WebKit's linking
of libWebCore.la in current git), make fails to execute the command as
it doesn't split the command line to fit within the limits.

This patch provides a POSIX specific fix.
--->8---

diff --git a/configure.ac b/configure.ac
index a1d41640..98dd2309 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,7 +75,7 @@ AC_HEADER_STAT
 AC_HEADER_TIME
 AC_CHECK_HEADERS([stdlib.h locale.h unistd.h limits.h fcntl.h string.h \
   memory.h sys/param.h sys/resource.h sys/time.h sys/timeb.h \
-  sys/select.h sys/file.h spawn.h])
+  sys/select.h sys/file.h spawn.h sys/user.h linux/binfmts.h])
 
 AM_PROG_CC_C_O
 AC_C_CONST
diff --git a/src/job.c b/src/job.c
index ae1f18b9..3abba81a 100644
--- a/src/job.c
+++ b/src/job.c
@@ -26,6 +26,14 @@ this program.  If not, see .  */
 #include "variable.h"
 #include "os.h"
 
+#if defined (HAVE_LINUX_BINFMTS_H) && defined (HAVE_SYS_USER_H)
+#include 
+#include 
+#endif
+#ifndef PAGE_SIZE
+# define PAGE_SIZE (sysconf(_SC_PAGESIZE))
+#endif
+
 /* Default shell to use.  */
 #ifdef WINDOWS32
 # ifdef HAVE_STRINGS_H
@@ -3217,6 +3225,7 @@ construct_command_argv_internal (char *line, char **restp, const char *shell,
 #ifdef WINDOWS32
 char *command_ptr = NULL; /* used for batch_mode_shell mode */
 #endif
+char *args_ptr;
 
 # ifdef __EMX__ /* is this necessary? */
 if (!unixy_shell && shellflags)
@@ -3382,8 +3391,17 @@ construct_command_argv_internal (char *line, char **restp, const char *shell,
 return new_argv;
   }
 
+#ifdef MAX_ARG_STRLEN
+static char eval_line[] = "eval\\ \\\"set\\ x\\;\\ shift\\;\\ ";
+#define ARG_NUMBER_DIGITS 5
+#define EVAL_LEN (sizeof(eval_line)-1 + shell_len + 4   \
+  + (7 + ARG_NUMBER_DIGITS) * 2 * line_len / (MAX_ARG_STRLEN - 2))
+#else
+#define EVAL_LEN 0
+#endif
+
 new_line = xmalloc ((shell_len*2) + 1 + sflags_len + 1
-+ (line_len*2) + 1);
++ (line_len*2) + 1 + EVAL_LEN);
 ap = new_line;
 /* Copy SHELL, escaping any characters special to the shell.  If
we don't escape them, construct_command_argv_internal will
@@ -3403,6 +3421,30 @@ construct_command_argv_internal (char *line, char **restp, const char *shell,
 #ifdef WINDOWS32
 command_ptr = ap;
 #endif
+
+#if !defined (WINDOWS32) && defined (MAX_ARG_STRLEN)
+if (unixy_shell && line_len > MAX_ARG_STRLEN)
+  {
+   unsigned j;
+   memcpy (ap, eval_line, sizeof (eval_line) - 1);
+   ap += sizeof (eval_line) - 1;
+   for (j = 1; j <= 2 * line_len / (MAX_ARG_STRLEN - 2); j++)
+ ap += sprintf (ap, "\\$\\{%u\\}", j);
+   *ap++ = '\\';
+   *ap++ = '"';
+   *ap++ = ' ';
+   /* Copy only the first word of SHELL to $0.  */
+   for (p = shell; *p != '\0'; ++p)
+ {
+   if (isspace ((unsigned char)*p))
+ break;
+   *ap++ = *p;
+ }
+   *ap++ = ' ';
+  }
+#endif
+args_ptr = ap;
+
 for 

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Pablo Mestre]

El 11/1/20 a las 3:33 PM, Otto Kekäläinen escribió:
> Hello Pablo!
>
> Please also check that your watchfile is a working one. Now it fails with:
>
> ± gbp import-orig --uscan --no-interactive --verbose
> gbp:debug: ['git', 'rev-parse', '--show-cdup']
> gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
> gbp:debug: ['git', 'rev-parse', '--git-dir']
> gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
> gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream']
> gbp:debug: ['git', 'status', '--porcelain']
> gbp:info: Launching uscan...
> uscan warn: In watchfile debian/watch, reading webpage
>   https://github.com/palantir/python-jsonrpc-servers/tags failed: 404 Not 
> Found
> gbp:error: Uscan failed: In watchfile debian/watch, reading webpage
>   https://github.com/palantir/python-jsonrpc-servers/tags failed: 404 Not 
> Found

Done :)

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#973880: krb5: CVE-2020-28196

[Sam Hartman]

Thanks for the note.  I've been meaning to do a much needed krb5 update
and this definitely pushes it up the priority stack.
I'll work on this over the weekend.

Bug#973886: xserver-xorg-video-nouveau: Suspend to ram is not working with GeForce 210

[Goran Delcev]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.16-1
Severity: normal
X-Debbugs-Cc: barney67...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

I have Installed bullseye (clean install).
After installation I have installed firmware for nvidia graphics card. Rebooted 
the
system. Tried to suspend to ram, screen goes black but power is still on.
I cannot rebbot the system or X. I have to use hardware reset.
After this I have installed Nvidia legacy driver from the Debian repository,
rebooted the system, and everything is working fine.
Conclusion: there is a bug in nouveau driver.

*** End of the template - remove these template lines ***


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.1-1 (2020-10-17)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 75393 Nov  6 19:57 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[18.636] (--) Log file renamed from "/var/log/Xorg.pid-545.log" to 
"/var/log/Xorg.0.log"
[18.684] 
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[18.684] Build Operating System: Linux 4.19.0-8-amd64 x86_64 Debian
[18.684] Current Operating System: Linux living 5.9.0-1-amd64 #1 SMP Debian 
5.9.1-1 (2020-10-17) x86_64
[18.684] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.9.0-1-amd64 
root=UUID=2e3cbbdf-a1b2-451d-a50b-c0fe04e7b7de ro quiet
[18.684] Build Date: 31 March 2020  10:14:40AM
[18.684] xorg-server 2:1.20.8-2 (https://www.debian.org/support) 
[18.684] Current version of pixman: 0.36.0
[18.684]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[18.684] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[18.684] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Nov  6 19:48:33 
2020
[18.791] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[18.890] (==) No Layout section.  Using the first Screen section.
[18.890] (==) No screen section available. Using defaults.
[18.890] (**) |-->Screen "Default Screen Section" (0)
[18.890] (**) |   |-->Monitor ""
[18.891] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[18.891] (==) Automatically adding devices
[18.891] (==) Automatically enabling devices
[18.891] (==) Automatically adding GPU devices
[18.891] (==) Max clients allowed: 256, resource mask: 0x1f
[18.931] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[18.931]Entry deleted from font path.
[18.948] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[18.948] (==) ModulePath set to "/usr/lib/xorg/modules"
[18.948] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[18.948] (II) Loader magic: 0x55f91fcd6e20
[18.948] (II) Module ABI versions:
[18.948]X.Org ANSI C Emulation: 0.4
[18.948]X.Org Video Driver: 24.1
[18.948]X.Org XInput driver : 24.1
[18.948]X.Org Server Extension : 10.0
[18.949] (++) using VT number 7

[18.949] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[18.950] (II) xfree86: Adding drm device (/dev/dri/card0)
[18.954] (--) PCI:*(1@0:0:0) 10de:0a65:1458:3530 rev 162, Mem @ 
0xf900/16777216, 0xd000/268435456, 0xee00/33554432, I/O @ 
0xef00/128, BIOS @ 0x/131072
[18.954] (II) LoadModule: "glx"
[18.969] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[19.128] (II) Module glx: vendor="X.Org Foundation"
[19.128]compiled for 1.20.8, module version = 1.0.0
[19.128]ABI class: X.Org Server Extension, version 10.0
[19.251] 

Bug#971704: gnome-shell-pomodoro: diff for NMU version 0.18.0-0.1

[Joseph Herlant]

Thanks for doing that. I unfortunately haven't taken any time for
opensource since the beginning of this COVID madness.

Feel free to push it now. It's totally fine with me.

Thanks
Joseph

Bug#973657: src:rust-onig: autopkgtest uses enormous amount (> 25 GB) of disk space

[Paul Gevers]

Hi Paride,

Thanks for the quick fix.

On 06-11-2020 09:38, Paride Legovini wrote:
> I'm [ ... ] unsure on why the
> autopkgtest started misbehaving, given that 5.0.0-3 was uploaded back in
> April 2020.

That's because I only recently reported the issue. I had blocked your
package already for a while on arm64. Sorry for not filing earlier, but
I try to balance infrastructure issues to issues worth bothering
maintainers. Apparently I balanced weirdly a while ago when I check arm64.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

[Xavier]

Le 06/11/2020 à 19:08, Nicholas Guriev a écrit :
> On Thu, 2020-11-05 at 06:27 +0100, Xavier wrote:
>> I'm unable to reproduce the bug: libtgvoip build works fine here. Could
>> you verify that the bug still exists?
>>
>> Cheers,
>> Xavier
> 
> Xavier, which version of the libtgvoip package did you try to build? The
> bug is reproducible with 2.4.4-2 as stated in the start message in this
> thread. Newer versions do not depend on GYP. But the issue is still
> present. Minimal example needs almost nothing:
> 
>mymedia@barberry:~$ gyp --format=cmake --depth=. - < /dev/null
>Traceback (most recent call last):
>  File "/usr/bin/gyp", line 11, in 
>load_entry_point('gyp==0.1', 'console_scripts', 'gyp')()
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 552, in 
> script_main
>return main(sys.argv[1:])
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 545, in main
>return gyp_main(args)
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 518, in 
> gyp_main
>[generator, flat_list, targets, data] = Load(
>  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 98, in Load
>generator = __import__(generator_name, globals(), locals(), 
> generator_name)
>  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line 43, 
> in 
>_maketrans = string.maketrans
>AttributeError: module 'string' has no attribute 'maketrans'
>mymedia@barberry:~$ 

Hi,

sorry, I launched a full rebuild in unstable and didn't see this change.
However I don't understand this error (I'm not Python dev), code is:

 try:
   # maketrans moved to str in python3.
   _maketrans = string.maketrans
 except NameError:
   _maketrans = str.maketrans

So error should be discarded, isn't it?

Bug#973492: abseil: Please consider explicitly enable -latomic with armel build

[Benjamin Barenblat]

On Tuesday, November  3, 2020, at 10:27 AM -0500, Benjamin Barenblat wrote:
> [...] the CMake support files that get installed with libabsl-dev should
> probably specify -latomic on armel [...]. I think a single patch might
> be able to do both of these [...]

It turns out Abseil upstream doesn’t have a great way of specifying
dependencies on external libraries in their CMake support files. So far,
this hasn’t been an issue, probably because most projects using the
CMake support files are happy with the default dynamic linking, where
dependencies are handled by the loader. But I’m now more skeptical that
a single patch will solve both of these issues.

I’ll continue investigation, but in the meantime, I’m going to do an
upload with -latomic in the right places. That should solve the build
problems on armel.


signature.asc
Description: PGP signature

Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

[Nicholas Guriev]

On Fri, 2020-11-06 at 22:06 +0100, Xavier wrote:
> sorry, I launched a full rebuild in unstable and didn't see this change.
> However I don't understand this error (I'm not Python dev), code is:
> 
>  try:
>    # maketrans moved to str in python3.
>    _maketrans = string.maketrans
>  except NameError:
>    _maketrans = str.maketrans
> 
> So error should be discarded, isn't it?

It seems wrong exception is handled here. NameError[1] happens when
unknown top-level variable is referenced. However, above this line,
there is importing of string module. So NameError is not possible here.
I daresay an original author meant AttributeError[2] here that is raised
when code is trying to get non-existent attribute (a thing after dot).

I suggest replace NameError with AttributeError:

   try:
 # maketrans moved to str in python3.
 _maketrans = string.maketrans
   except AttributeError:
 _maketrans = str.maketrans

(not tested)

 [1]: https://docs.python.org/3/library/exceptions.html#NameError
 [2]: https://docs.python.org/3/library/exceptions.html#AttributeError



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

Bug#973698: g++-10: regresson in 10.2.0-16: internal compiler error: in tsubst_decl, at cp/pt.c:14666

[Michael R. Crusoe]

Thanks for making the issue upstream with the minimal example!

I just built with gcc-snapshot 1:20201023-1 and now I get a build error:
https://github.com/seqan/seqan3/issues/2236#issuecomment-723232918


On Fri, 6 Nov 2020 at 17:13, Matthias Klose  wrote:

> Control: forwarded -1 https://gcc.gnu.org/PR97745
>
> please could you try to build the package with gcc-snapshot to see if you
> get an
> error?
>

Bug#973887: alsa-utils: alsamixer default Sound Card hangs (high CPU usage) with `pulseaudio --kill`

[rv]

Package: alsa-utils
Version: 1.2.3-1
Severity: normal
X-Debbugs-Cc: riveravaldezm...@gmail.com

Dear Maintainer,

   * What led up to the situation?

AFAICT, last system update (yesterday).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

With alsamixer running in a separated terminal [F6: Sound Card : - (default)] I 
did `pulseaudio --kill`.

   * What was the outcome of this action?

CPU starts to work a lot and non-stoping. Going to alsamixer and doing F6: 
select another Card (the '0' one, for instance) stops this hang. But then when 
trying to choose again '- (default)' I have this message:
> Error
> Cannot open mixer device 'default'.
> Connection refused

Which I suppose it's OK since PA is not running.
If I do `pulseaudio --start` and try again alsamixer seems to recover 
('default' appears again).

   * What outcome did you expect instead?

Not high-CPU-hanging, I suppose.

Thanks a lot. Best regards.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages alsa-utils depends on:
ii  kmod  27+20200310-2
ii  libasound21.2.3.2-1
ii  libatopology2 1.2.3.2-1
ii  libc6 2.30-8
ii  libfftw3-single3  3.3.8-2
ii  libncursesw6  6.2+20200918-1
ii  libsamplerate00.1.9-2
ii  libtinfo6 6.2+20200918-1
ii  lsb-base  11.1.0

alsa-utils recommends no packages.

Versions of packages alsa-utils suggests:
ii  dialog  1.3-20190808-1

-- no debconf information

Bug#973570: fzf: keybinding files should be installed under /etc

[Jai Flack]

On Sun, 01 Nov 2020 23:56:28 + yacoob  wrote:
> Right now the example keybindings for different shells
> (/usr/share/doc/fzf/examples/key-bindings.*) are placed under
> /usr/share/doc. This is all fine and good, except for cases where you're using
> a slimed down file (eg. debian-slim image from docker) which doesn't have
> /usr/share/doc. Please consider placing those keybindings somewhere under 
> /etc.

/usr/share/doc is the standard location for these in Debian. What would
be the use-case for having these in a docker (or other) image designed
to not include unnecessary files?

-- 
Thanks,
Jai

Bug#972905: some more information

[Mahashakti89]

Hi,

Only provisory way out of this: I fetched last version of
sane-backends, compiled and installed in /usr/local and it works now.

Regards

-- 
Lumière de tous les chakras ! ⚡⚡⚡藍 藍藍

Bug#973877: tcpdump: CVE-2020-8037

[Salvatore Bonaccorso]

Hi Romain,

On Fri, Nov 06, 2020 at 07:01:46PM +0100, Romain Francoise wrote:
> Hi,
> 
> On Fri, Nov 6, 2020 at 1:48 PM Salvatore Bonaccorso  wrote:
> > The following vulnerability was published for tcpdump.
> >
> > CVE-2020-8037[0]:
> > | The ppp decapsulator in tcpdump 4.9.3 can be convinced to allocate a
> > | large amount of memory.
> 
> Thanks for the bug report. I am aware of this CVE and working on a new
> upload to unstable.
> Is this no-dsa?

Yes it does not warrant a DSA, but if you are at it and have capacity
for it, please do include a fix for it in the upcoming point release
(cf. https://lists.debian.org/debian-live/2020/11/msg0.html).

Regards,
Salvatore

Bug#973002: Any hint what needs to be done to finalize tensorflow?

[Andreas Tille]

On Thu, Nov 05, 2020 at 03:32:17AM +, Mo Zhou wrote:
> I'm not sure what packages are exactly missing from Debian, but this
> directory is worth being checked, I think:
> https://github.com/tensorflow/tensorflow/tree/master/third_party
> Some of them are meanwhile PyTorch dependencies, so this portion
> is supposed to be in a good shape.

Hmmm, that seems to be a lot.  Strangely enough if I try to build in
pbuilder it downloads several dependencies from the internet - except if
sitting behind a proxy that is unknown to the pbuilder environment.  I
have never observed this before - seems bazel knows "tricks" to
undermine the offlineish nature of the pbuilder environment.  I have
never seen this happening before.
 
> Besides, one of the most valuable reverse dependency of tensorflow is
> tensorboard (feel free to take over this ITP since I feel overloaded):
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973002

I've commited some initial packaging to Salsa[1].  It also needs
some third party software.  The first one is

  
http://mirror.tensorflow.org/github.com/bazelbuild/bazel-skylib/archive/0.7.0.tar.gz

I wonder whether all those dependencies are mandatory or whether
we might be able to exclude something optional.
 
> I'm not able to participate in TF maintenance, but I care about
> tensorboard because it can be used by PyTorch as well. Acceptance of
> tensorboard also unblocks the debianization of my favorate PyTorch
> abstraction layer "pytorch-lightning".

I could *help* with this - but I'm clearly neither qualified
nor does my time limit permit really focussing on this work.

Kind regards

   Andreas.

[1] https://salsa.debian.org/deeplearning-team/tensorboard

-- 
http://fam-tille.de

Bug#964497: Info received (ITP: python-jsonrpc-server -- JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol)

[Otto Kekäläinen]

Thanks!

I will update the changelog and upload current
https://salsa.debian.org/python-team/packages/python-jsonrpc-server/-/commits/debian/master
unless Boyuan or Jochen have something more to add/review about the packaging.

Bug#973890: RM: tty-server/0.0~git20201105.50b9367+ds-1

[Francisco Vilmar Cardoso Ruviaro]

Hello Adam,

On 2020-11-06 21:38, Adam D. Barratt wrote:
> That will happen automatically once the package is removed from
> unstable.
> 

Ohh Sorry, I thought I should open a bug to remove from testing as well.

> Is there a reason that testing removal can't / shouldn't just wait for
> that?
> 

There is no reason, I can wait.

> Regards,

Thanks!
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#964195: guacamole-client: CVE-2020-9497 and CVE-2020-9498

[Markus Koschany]

Control: tags -1 patch


Hi,

I'm attaching my patch for Stretch to this bug report. Since the 
versions in Stretch and unstable are identical, it should work there 
too. However I don't intend to NMU guacamole-server because I believe a 
new upstream version should be packaged instead.


Regards,

Markus
diff -Nru 
guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch 
guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch
--- guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch 
1970-01-01 01:00:00.0 +0100
+++ guacamole-server-0.9.9/debian/patches/CVE-2020-9497-and-CVE-2020-9498.patch 
2020-11-06 22:44:56.0 +0100
@@ -0,0 +1,355 @@
+From: Markus Koschany 
+Date: Tue, 3 Nov 2020 13:45:20 +0100
+Subject: CVE-2020-9497 and CVE-2020-9498
+
+Bug-Debian: https://bugs.debian.org/964195
+Origin: 
https://github.com/apache/guacamole-server/commit/a0e11dc81727528224d28466903454e1cb0266bb
+---
+ src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c   | 40 ++
+ .../rdp/guac_rdpdr/rdpdr_fs_messages_file_info.c   | 12 +++
+ src/protocols/rdp/guac_rdpdr/rdpdr_messages.c  | 18 ++
+ src/protocols/rdp/guac_rdpdr/rdpdr_printer.c   |  7 
+ src/protocols/rdp/guac_rdpdr/rdpdr_service.c   |  3 ++
+ src/protocols/rdp/guac_rdpsnd/rdpsnd_messages.c| 29 
+ src/protocols/rdp/guac_rdpsnd/rdpsnd_service.c |  5 +++
+ 7 files changed, 114 insertions(+)
+
+diff --git a/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c 
b/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c
+index bfd8ead..10d41bb 100644
+--- a/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c
 b/src/protocols/rdp/guac_rdpdr/rdpdr_fs_messages.c
+@@ -58,6 +58,10 @@ void guac_rdpdr_fs_process_create(guac_rdpdr_device* device,
+ int create_disposition, create_options, path_length;
+ char path[GUAC_RDP_FS_MAX_PATH];
+ 
++/* Check remaining stream data prior to reading. */
++if (Stream_GetRemainingLength(input_stream) < 32)
++return;
++
+ /* Read "create" information */
+ Stream_Read_UINT32(input_stream, desired_access);
+ Stream_Seek_UINT64(input_stream); /* allocation size */
+@@ -67,6 +71,11 @@ void guac_rdpdr_fs_process_create(guac_rdpdr_device* device,
+ Stream_Read_UINT32(input_stream, create_options);
+ Stream_Read_UINT32(input_stream, path_length);
+ 
++/* Check to make sure the stream contains path_length bytes. */
++if(Stream_GetRemainingLength(input_stream) < path_length) {
++return;
++}
++
+ /* Convert path to UTF-8 */
+ guac_rdp_utf16_to_utf8(Stream_Pointer(input_stream), path_length/2 - 1,
+ path, sizeof(path));
+@@ -133,6 +142,10 @@ void guac_rdpdr_fs_process_read(guac_rdpdr_device* device,
+ 
+ wStream* output_stream;
+ 
++/* Check remaining bytes before reading stream. */
++if (Stream_GetRemainingLength(input_stream) < 12)
++return;
++
+ /* Read packet */
+ Stream_Read_UINT32(input_stream, length);
+ Stream_Read_UINT64(input_stream, offset);
+@@ -181,6 +194,10 @@ void guac_rdpdr_fs_process_write(guac_rdpdr_device* 
device,
+ 
+ wStream* output_stream;
+ 
++/* Check remaining length. */
++if (Stream_GetRemainingLength(input_stream) < 32)
++return;
++
+ /* Read packet */
+ Stream_Read_UINT32(input_stream, length);
+ Stream_Read_UINT64(input_stream, offset);
+@@ -190,6 +207,11 @@ void guac_rdpdr_fs_process_write(guac_rdpdr_device* 
device,
+ "%s: [file_id=%i] length=%i, offset=%" PRIu64,
+  __func__, file_id, length, (uint64_t) offset);
+ 
++/* Check to make sure stream contains at least length bytes */
++if (Stream_GetRemainingLength(input_stream) < length) {
++return;
++}
++
+ /* Attempt write */
+ bytes_written = guac_rdp_fs_write((guac_rdp_fs*) device->data, file_id,
+ offset, Stream_Pointer(input_stream), length);
+@@ -252,6 +274,10 @@ void guac_rdpdr_fs_process_volume_info(guac_rdpdr_device* 
device, wStream* input
+ 
+ int fs_information_class;
+ 
++/* Check remaining length */
++if (Stream_GetRemainingLength(input_stream) < 4)
++return;
++
+ Stream_Read_UINT32(input_stream, fs_information_class);
+ 
+ /* Dispatch to appropriate class-specific handler */
+@@ -294,6 +320,10 @@ void guac_rdpdr_fs_process_file_info(guac_rdpdr_device* 
device, wStream* input_s
+ 
+ int fs_information_class;
+ 
++/* Check remaining length */
++if (Stream_GetRemainingLength(input_stream) < 4)
++return;
++
+ Stream_Read_UINT32(input_stream, fs_information_class);
+ 
+ /* Dispatch to appropriate class-specific handler */
+@@ -341,6 +371,10 @@ void 
guac_rdpdr_fs_process_set_file_info(guac_rdpdr_device* device,
+ int fs_information_class;
+ int length;
+ 
++/* Check remaining length */
++if (Stream_GetRemainingLength(input_stream) < 32)

Bug#973892: consul: CVE-2020-25201

[Salvatore Bonaccorso]

Source: consul
Version: 1.7.4+dfsg1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/hashicorp/consul/pull/9024
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for consul.

I'm not particularly familiar with consul, but just skimmed over the
current sources in unstable.

CVE-2020-25201[0]:
| HashiCorp Consul Enterprise version 1.7.0 up to 1.8.4 includes a
| namespace replication bug which can be triggered to cause denial of
| service via infinite Raft writes. Fixed in 1.7.9 and 1.8.5.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-25201
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25201
[1] https://github.com/hashicorp/consul/pull/9024

Regards,
Salvatore

Bug#973888: RFS: tinydyndns/0.4.2.debian1-2 [QA] -- pop-before-dyndns service using djbdns

[Baptiste Beauplat]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tinydyndns
   Version : 0.4.2.debian1-2
   Upstream Author : Gerrit Pape 
 * URL : http://smarden.org/tinydyndns/
 * License : BSD-3-Clause, public-domain
 * Vcs : https://salsa.debian.org/debian/tinydyndns
   Section : net

It builds those binary packages:

  tinydyndns - pop-before-dyndns service using djbdns

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tinydyndns/tinydyndns_0.4.2.debian1-2.dsc


Changes since the last upload:

 tinydyndns (0.4.2.debian1-2) unstable; urgency=medium
 .
   * QA upload.
   * Set Maintainer to Debian QA Group (#947703)
   * Bump Standard-Version to 4.5.0
   * Add Homepage url (Closes: #949223)
   * Add VCS url to salsa project
   * Set Rules-Requires-Root to no
   * Convert source format to 3.0 (quilt)
   * Convert copyright to DEP5
   * Add missing license for djbdns files
   * Fix spacing in debian/control
   * Convert rules to dh sequencer (Closes: #911393, #776929, #847032)
   * Add Build-Depends to debhelper-compat (= 13)
   * List binaries to install in d/install
   * List manpages to install in d/manpages
   * Add ${misc:Depends}
   * Fix typo in manpages and docs
   * Add salsa CI pipeline
   * Use recommended branch name from DEP-14
   * Remove unused implicit file in debian packaging
   * Add an explanation to the repacked upstream sources

Regards,
--
Baptiste Beauplat - lyknode



OpenPGP_signature
Description: OpenPGP digital signature

Bug#944372: Backtrace

[Jochen Betz]

Hi still experience the same issue. To me it seems that it has problems
parsing/handling the mail file in /var/mail/USERNAME. As long as it is
empty, it does not fail.
As soon as it contains something... segfault!

The following is a stack trace I could gather:


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
"/var/mail/jochen": 1 message 1 new

Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65  ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or
directory.
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x775e0dae in __GI___strdup (s=0x0) at strdup.c:41
#2  0x77a43b5f in mu_strdup (s=0x0) at alloc.c:77
#3  0x55576818 in util_get_charset () at util.c:1067
#4  0x55576891 in util_rfc2047_decode (value=0x7fffb248) at
util.c:1087
#5  0x555657f9 in hdr_from (args=0x7fffb2e0, data=0x0) at
from.c:273
#6  0x5556518d in format_headline (seg=0x555a39f0,
mspec=0x7fffb370, msg=0x555b0280) at from.c:97
#7  0x555664c3 in mail_from0 (mspec=0x7fffb370,
msg=0x555b0280, data=0x0) at from.c:609
#8  0x5556db95 in page_do (func=0x55566495 ,
data=0x0) at page.c:178
#9  0x55566537 in mail_headers (argc=1, argv=0x555b0c28) at
headers.c:35
#10 0x5557462f in util_do_command (fmt=0x55578eca "headers")
at util.c:143
#11 0x55567d0d in main (argc=0, argv=0x7fffb7b0) at mail.c:654
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
No locals.
#1  0x775e0dae in __GI___strdup (s=0x0) at strdup.c:41
len = 
new = 
#2  0x77a43b5f in mu_strdup (s=0x0) at alloc.c:77
news = 0x0
#3  0x55576818 in util_get_charset () at util.c:1067
lc_all = {flags = 0, language = 0x0, territory = 0x0, charset =
0x0, modifier = 0x0}
tmp = 0x7fffee86 ""
charset = 0x55588b70 "auto"
#4  0x55576891 in util_rfc2047_decode (value=0x7fffb248) at
util.c:1087
charset = 0x7fffb280 "\020\263\377\377\377\177"
tmp = 0x77a5ee63 
"H\213E\370H\211E\360H\203", 
rc = 0
#5  0x555657f9 in hdr_from (args=0x7fffb2e0, data=0x0) at
from.c:273
hdr = 0x555b2140
from = 0x5558fe00 "jochen"
#6  0x5556518d in format_headline (seg=0x555a39f0,
mspec=0x7fffb370, msg=0x555b0280) at from.c:97
width = 1
len = 1
cols_rest = 181
p = 0x55589870 " "
screen_cols = 188
out_cols = 7
args = {mspec = 0x7fffb370, msg = 0x555b0280, cols_rest
= 181, buf = 0x55591660 "1", size = 2}
#7  0x555664c3 in mail_from0 (mspec=0x7fffb370,
msg=0x555b0280, data=0x0) at from.c:609
No locals.
#8  0x5556db95 in page_do (func=0x55566495 ,
data=0x0) at page.c:178
msg = 0x555b0280
set = {next = 0x0, npart = 1, msg_part = 0x555a3250}
i = 0
#9  0x55566537 in mail_headers (argc=1, argv=0x555b0c28) at
headers.c:35
No locals.
#10 0x5557462f in util_do_command (fmt=0x55578eca "headers")
at util.c:143
ws = {ws_wordc = 1, ws_wordv = 0x555b0c20, ws_offs = 1,
ws_wordn = 128, ws_flags = 33558086, ws_options = 1632, ws_delim =
0x77ad6e9e " \t\n", ws_comment = 0x0, ws_escape = {0x77af6360
 "\"\"a\ab\bf\fn\nr\rt\tv\v",
0x77af6360 
"\"\"a\ab\bf\fn\nr\rt\tv\v"}, ws_alloc_die = 0x77ab20d8
<_wsplt_alloc_die>, ws_error = 0x77ab2116 <_wsplt_error>, ws_debug =
0x55585fd8 , ws_env = 0x1, ws_envbuf = 0x555ad430,
ws_envidx = 483314001, ws_envsiz = 0, ws_getvar = 0x1, ws_closure = 0x0,
ws_command = 0x0, ws_input = 0x555b09e0 "@\"[UUU", ws_len = 7,
ws_endp = 7, ws_errno = 0, ws_usererr = 0x555799b6 "header", ws_head
= 0x0, ws_tail = 0x0, ws_lvl = 0}
argc = 1
argv = 0x555b0c28
status = 0
entry = 0x55582500 
cmd = 0x555b09e0 "@\"[UUU"
size = 512
ap = {{gp_offset = 8, fp_offset = 48, overflow_arg_area =
0x7fffb5d0, reg_save_area = 0x7fffb500}}
#11 0x55567d0d in main (argc=0, argv=0x7fffb7b0) at mail.c:654
mode = 0x55589f60 "read"
prompt = 0x0
p = 0x555a35c7 "/home/jochen/.mailrc"
i = 56
rc = 0

Thread 1 (Thread 0x76739980 (LWP 7076)):
#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
No locals.
#1  0x775e0dae in __GI___strdup (s=0x0) at strdup.c:41
len = 
new = 
#2  0x77a43b5f in mu_strdup (s=0x0) at alloc.c:77
news = 0x0
#3  0x55576818 in util_get_charset () at util.c:1067
lc_all = {flags = 0, language = 0x0, territory = 0x0, charset =
0x0, modifier = 0x0}
tmp = 0x7fffee86 ""
charset = 0x55588b70 "auto"
#4  

Bug#973891: RM: tty-server -- ROM; no longer maintained

[Francisco Vilmar Cardoso Ruviaro]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

Please, remove the tty-server from unstable because it was deprecated by 
tty-proxy.

[0]
https://github.com/elisescu/tty-server/blob/50b9367cd19c07017b9578adca5e8d15db2382b0/README.md
[1]
https://github.com/elisescu/tty-server/commit/50b9367cd19c07017b9578adca5e8d15db2382b0
[2]
https://github.com/elisescu/tty-share/blob/93cdfa0e887c210d097c891ffaaf5e3ccd8f35d8/doc/old-version.md
[3] https://github.com/elisescu/tty-proxy

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00



signature.asc
Description: OpenPGP digital signature

Bug#973890: RM: tty-server/0.0~git20201105.50b9367+ds-1

[Francisco Vilmar Cardoso Ruviaro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Dear Release Team,

Please, remove the tty-server from testing because it was deprecated by 
tty-proxy.

[0]
https://github.com/elisescu/tty-server/blob/50b9367cd19c07017b9578adca5e8d15db2382b0/README.md
[1]
https://github.com/elisescu/tty-server/commit/50b9367cd19c07017b9578adca5e8d15db2382b0
[2]
https://github.com/elisescu/tty-share/blob/93cdfa0e887c210d097c891ffaaf5e3ccd8f35d8/doc/old-version.md
[3] https://github.com/elisescu/tty-proxy

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00



signature.asc
Description: OpenPGP digital signature

Bug#963320: libtgvoip: FTBFS: AttributeError: module 'string' has no attribute 'maketrans'

[Xavier]

Le 06/11/2020 à 22:23, Nicholas Guriev a écrit :
> On Fri, 2020-11-06 at 22:06 +0100, Xavier wrote:
>> sorry, I launched a full rebuild in unstable and didn't see this change.
>> However I don't understand this error (I'm not Python dev), code is:
>>
>>  try:
>>    # maketrans moved to str in python3.
>>    _maketrans = string.maketrans
>>  except NameError:
>>    _maketrans = str.maketrans
>>
>> So error should be discarded, isn't it?
> 
> It seems wrong exception is handled here. NameError[1] happens when
> unknown top-level variable is referenced. However, above this line,
> there is importing of string module. So NameError is not possible here.
> I daresay an original author meant AttributeError[2] here that is raised
> when code is trying to get non-existent attribute (a thing after dot).
> 
> I suggest replace NameError with AttributeError:
> 
>try:
>  # maketrans moved to str in python3.
>  _maketrans = string.maketrans
>except AttributeError:
>  _maketrans = str.maketrans
> 
> (not tested)

I tried but now I've a new error:

Traceback (most recent call last):
  File "/usr/bin/gyp", line 11, in 
load_entry_point('gyp==0.1', 'console_scripts', 'gyp')()
  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 552, in
script_main
return main(sys.argv[1:])
  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 545, in main
return gyp_main(args)
  File "/usr/lib/python3/dist-packages/gyp/__init__.py", line 530, in
gyp_main
generator.GenerateOutput(flat_list, targets, data, params)
  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line
1238, in GenerateOutput
GenerateOutputForConfig(target_list, target_dicts, data,
  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line
1194, in GenerateOutputForConfig
WriteTarget(namer, qualified_target, target_dicts, build_dir,
config_to_use,
  File "/usr/lib/python3/dist-packages/gyp/generator/cmake.py", line
990, in WriteTarget
for xcode_setting, xcode_value in xcode_settings.viewitems():
AttributeError: 'dict' object has no attribute 'viewitems'

Bug#973893: Traducción: es_AR: Preferencias: "Bloquear ventanas emergentesu"

[rv]

Package: epiphany-browser
Version: 3.38.1-1
Severity: minor
X-Debbugs-Cc: riveravaldezm...@gmail.com

Hi, dear Maintainer,

there's a misspelled word in this Spanish translation:

Preferencias: General: "Bloquear ventanas emergentesu"

That las 'u' shouldn't be there.

Best regards!



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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  epiphany-browser-data 3.38.1-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  iso-codes 4.5.0-1
ii  libatk1.0-0   2.36.0-2
ii  libc6 2.30-8
ii  libcairo2 1.16.0-4
ii  libdazzle-1.0-0   3.38.0-1
ii  libgcr-base-3-1   3.38.0-1
ii  libgcr-ui-3-1 3.38.0-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libglib2.0-0  2.66.2-1
ii  libgmp10  2:6.2.0+dfsg-6
ii  libgtk-3-03.24.23-2
ii  libhandy-1-0  1.0.1-1
ii  libhogweed6   3.6-2
ii  libjavascriptcoregtk-4.0-18   2.30.1-1
ii  libjson-glib-1.0-01.6.0-1
ii  libnettle83.6-2
ii  libpango-1.0-01.46.2-2
ii  libsecret-1-0 0.20.3-1
ii  libsoup2.4-1  2.72.0-2
ii  libsqlite3-0  3.33.0-1
ii  libwebkit2gtk-4.0-37  2.30.1-1
ii  libxml2   2.9.10+dfsg-6.1

Versions of packages epiphany-browser recommends:
ii  ca-certificates  20200601
pn  evince   
ii  yelp 3.38.1-1

epiphany-browser suggests no packages.

-- no debconf information

Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)

[Diane Trout]

On Fri, 2020-11-06 at 08:23 +0100, Andreas Tille wrote:
> Dear Diane,
> 
> would you mind pushing your patch to the Git repository?  I mean its
> your ITP and you are Uploader - so I hesitate to push your very own
> patch on behalf of you. ;-)
> 
> Thanks a lot for your helpful hints and contacting upstream


I pushed the patches... Is there anything else anyone wants to do to
the package or should I submit to NEW?