Bug#733060: ITP: svxlink -- voice services system for ham radio use

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

  Package name: svxlink
  Version : 13.12
  Upstream Author : Tobias Blomberg 
  URL : http://sourceforge.net/projects/svxlink/
  License : GPLv2 dated June 1991, except as noted below
  Programming Lang: C++
  Description : voice services system for ham radio use

The svxLINK server provides access to a ham radio transceiver via the
EchoLink® protocol. A graphical client, Qtel, is included.

EchoLink® allows licensed amateur radio operators to communicate over the
Internet, including remote access to station equipment. The server can act as a
repeater controller or operate on a simplex channel. Based on a modular design,
the server can be configured to provide voice mail and other services.

Copyright and license details:

Most of the software is released under the GNU General Public License.
Exceptions are:

(1) WOL (Wide Open License, please see below):
async/audio/AudioDecimator.*
async/audio/AudioInterpolator.*

(2) Custom license (Aladdin Enterprises, please see below):
echolib/md5.{c,h}

(1) Original code by by Grant R. Griffin modified by Tobias Blomberg / SM0SVX.
Provided by Iowegian's "dspGuru" service (http://www.dspguru.com). Copyright
2001, Iowegian International Corporation (http://www.iowegian.com)

 The Wide Open License (WOL)

Permission to use, copy, modify, distribute and sell this software and its
documentation for any purpose is hereby granted without fee, provided that the
above copyright notice and this license appear in all source copies. THIS
SOFTWARE IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND.
See http://www.dspguru.com/wol.htm for more information.

(2)   Copyright (C) 1999, 2000, 2002 Aladdin Enterprises.  All rights reserved.

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this software.

  Permission is granted to anyone to use this software for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
 claim that you wrote the original software. If you use this software
 in a product, an acknowledgment in the product documentation would be
 appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
 misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.

  L. Peter Deutsch
  gh...@aladdin.com


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

Bug#733182: RFS: svxlink/13.12-1 ITP -- Voice over IP system for ham radio use

[Felix Lechner]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "svxlink"

  Package name: svxlink
  Version : 13.12-1
  Upstream Author : Tobias Blomberg 
  URL : http://sourceforge.net/projects/svxlink/
  License : GPL-2+, except as noted
  Section : hamradio

It builds these binary packages:

  qtel - Graphical client for the EchoLink® protocol
  qtel-dbg - Graphical client for the EchoLink® protocol (debug symbols)
  remotetrx - Remote controller for radio transceivers
  remotetrx-dbg - Remote controller for radio transceivers (debug symbols)
  svxlink-server - Voice-over-IP server for ham radio operators
  svxlink-server-dbg - Voice-over-IP server for ham radio operators
(debug symbols)
  libasyncaudio-dev - Svxlink audio library - development files
  libasyncaudio1.2 - Svxlink audio library
  libasynccore-dev - Svxlink core library - development files
  libasynccore1.2 - Svxlink core library
  libasynccpp-dev - Svxlink cpp library - development files
  libasynccpp1.2 - Svxlink cpp library
  libasyncqt-dev - Svxlink qt library - development files
  libasyncqt1.2 - Svxlink qt library
  libecholib-dev - Svxlink echo library - development files
  libecholib1.2 - Svxlink echo library
  libsvxlink-dev - Svxlink static libraries - development files

For further information about the package, please visit the following URL:

  http://mentors.debian.net/package/svxlink

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

  dget -x
http://mentors.debian.net/debian/pool/main/s/svxlink/svxlink_13.12-1.dsc

My sole changelog entry closes the ITP bug:

  * Initial release (Closes: #733060 )

Regards,
 Felix Lechner


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

Bug#718190: [Pkg-systemd-maintainers] Bug#718190: Bug#736092: systemd-sysv: Systemd mount lvm root but do not mount /usr on lvm.

[Felix Lechner]

Michael's new patch works for me. I did what Guillaume did, but also added
the patch to the 'series' file manually.


On Sun, Jan 26, 2014 at 8:12 AM, Michael Stapelberg
wrote:

> Hi Guillaume,
>
> Guillaume Seren  writes:
> > So I try to patch against the last version available in sid
> > '2.02.98-6+b1', and it doesn't work for me, I got the same bug :
> Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728486#163
> for an up-to-date patch which works on my machine. Or just install the
> pre-comiled packages mentioned earlier in this bug, they have been
> confirmed to work by various users :).
>
> --
> Best regards,
> Michael
>
> --
> To unsubscribe, send mail to 718190-unsubscr...@bugs.debian.org.
>

Bug#737830: ITP: belle-sip -- SIP stack from the Linphone team

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

* Package name: belle-sip
  Version : 1.2.4
  Upstream Author : Jehan Monnier 
* URL : http://www.linphone.org/
* License : GPL2+, GPL3+, BSD, MIT, zlib
  Programming Lang: C and ANTLR
  Description : SIP stack from the Linphone team

Belle-Sip is a new SIP stack (RFC3261) developed by the Linphone team.

Belle-Sip supports multiple transports at the same time, has a dual IPv6 and
IPv4 stack, is fully asynchronous and implements the +sip.instance and alias
parameters. It also handles network disconnections better, offers a privacy API
and supports rich presence.

SIP/TLS is handled by the lightweight polarssl library (as opposed to openssl).

Relevance:

This library is required to build the latest Linphone beta version 3.6.99. It
will probably replace libosip and libeXosip, a more mature SIP stack, in future
Linphone releases.

Maintenance:

I plan to submit the package to the Debian VOIP Team and hope to contribute to
maintenance going forward.


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

Bug#744082: ITP: wolfssl-jni -- Java interface for CyaSSL

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

* Package name: wolfssl-jni
  Version : 1.0
  Upstream Author : Chris Conlon 
* URL : http://www.wolfssl.com/
* License : GPL-2+
  Programming Lang: Java, C
  Description : Java interface for CyaSSL

The wolfSSL JNI package provides a Java interface to the wolfSSL
SSL/TLS library, providing Java applications with SSL/TLS support
up to the current TLS 1.2 and DTLS 1.2 standards.

In addition to the interface, the package provides an example
client and server, written in Java, which utilize the interface
to make an SSL/TLS connection.

The interface is provided through the use of JNI and standard
Java practices.

CyaSSL is an SSL library offering a compatibility layer for OpenSSL.
It is popular with developers of embedded systems.

'cyassl' is a prerequisite for this JNI package. The two packages are
released separately. I plan to maintain both of them.


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

Bug#598391: Work in progress

[Felix Lechner]

This library is being packaged.

Bug#795723: RM: cyassl -- RoQA; replaced by wolfssl

[Felix Lechner]

Moritz,

Thanks for taking care of it!

Felix


On Sun, Aug 16, 2015 at 5:51 AM, Moritz Muehlenhoff  wrote:

> Package: ftp.debian.org
> Severity: normal
>
> Hi,
> cyassl has been replaced by wolfssl, which is in stretch for
> a month now. So I think it's time to remove cyassl.
>
> CCing Felix for confirmation.
>
> Cheers,
> Moritz
>

Bug#858476: RFS: wolfssl/3.10.2+dfsg-1 [RC] -- wolfSSL encryption library

[Felix Lechner]

For some reason, the latest version enabled SHA-224 only on amd64. Upstream
advised that the algorithm should be available on all architectures. I
uploaded an updated package to Mentors
<https://mentors.debian.net/package/wolfssl>, but did not cross-build. Will
you please try again? Thank you!


On Fri, Apr 7, 2017 at 7:53 PM, Adam Borowski  wrote:

> On Wed, Mar 22, 2017 at 12:15:49PM -0700, Felix Lechner wrote:
> > I am looking for a sponsor for my package "wolfssl":
> >
> >   * Package name: wolfssl
> > Version : 3.10.2+dfsg-1
>
> > It builds those binary packages:
> >
> > libwolfssl10 - wolfSSL encryption library
>vs libwolfssl3 in unstable, but as there are no rdepends, no transition
> is needed, so that's ok
> > libwolfssl-dev - Development files for the wolfSSL encryption library
>
> >   Changes since the last upload:
> >
> >   * New upstream release.
> >   * New major version is 10
> >   * New maintainer email address
> >   * Fixes a low level vulnerability for buffer overflow when loading a
> > malformed temporary DH file
> >   * Fixes a medium level vulnerability for processing of OCSP response
> >   * Fixes CVE-2017-6076, a low level vulnerability for a potential cache
> attack
> > on RSA operations (Closes: #856114)
>
> I'm afraid it FTBFSes due to missing symbols on many architectures: out of
> those I tried, it succeeds on amd64 and x32, fails on armhf, arm64 and
> i386.
>
>
> --- debian/libwolfssl10.symbols (libwolfssl10_3.10.2+dfsg-1_armhf)
> +++ dpkg-gensymbolsptZH0b   2017-04-08 02:31:07.803935398 +
> @@ -135,7 +135,7 @@
>   wc_InitRng_ex@Base 3.10.2
>   wc_InitRsaKey@Base 3.10.2
>   wc_InitRsaKey_ex@Base 3.10.2
> - wc_InitSha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_InitSha224@Base 3.10.2
>   wc_InitSha256@Base 3.10.2
>   wc_InitSha384@Base 3.10.2
>   wc_InitSha512@Base 3.10.2
> @@ -209,10 +209,10 @@
>   wc_SetSubjectBuffer@Base 3.10.2
>   wc_SetSubjectKeyId@Base 3.10.2
>   wc_SetSubjectKeyIdFromPublicKey@Base 3.10.2
> - wc_Sha224Final@Base 3.10.2
> - wc_Sha224GetHash@Base 3.10.2
> - wc_Sha224Hash@Base 3.10.2
> - wc_Sha224Update@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Final@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224GetHash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Hash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Update@Base 3.10.2
>   wc_Sha256Final@Base 3.10.2
>   wc_Sha256GetHash@Base 3.10.2
>   wc_Sha256Hash@Base 3.10.2
> @@ -749,7 +749,7 @@
>   wolfSSL_EVP_rc4@Base 3.10.2
>   wolfSSL_EVP_ripemd160@Base 3.10.2
>   wolfSSL_EVP_sha1@Base 3.10.2
> - wolfSSL_EVP_sha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_EVP_sha224@Base 3.10.2
>   wolfSSL_EVP_sha256@Base 3.10.2
>   wolfSSL_EVP_sha384@Base 3.10.2
>   wolfSSL_EVP_sha512@Base 3.10.2
> @@ -885,9 +885,9 @@
>   wolfSSL_SHA1_Final@Base 3.10.2
>   wolfSSL_SHA1_Init@Base 3.10.2
>   wolfSSL_SHA1_Update@Base 3.10.2
> - wolfSSL_SHA224_Final@Base 3.10.2
> - wolfSSL_SHA224_Init@Base 3.10.2
> - wolfSSL_SHA224_Update@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Final@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Init@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_SHA224_Update@Base 3.10.2
>   wolfSSL_SHA256_Final@Base 3.10.2
>   wolfSSL_SHA256_Init@Base 3.10.2
>   wolfSSL_SHA256_Update@Base 3.10.2
>
> --- debian/libwolfssl10.symbols (libwolfssl10_3.10.2+dfsg-1_arm64)
> +++ dpkg-gensymbolsUx3QLk   2017-04-08 02:39:25.711217905 +
> @@ -135,7 +135,7 @@
>   wc_InitRng_ex@Base 3.10.2
>   wc_InitRsaKey@Base 3.10.2
>   wc_InitRsaKey_ex@Base 3.10.2
> - wc_InitSha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_InitSha224@Base 3.10.2
>   wc_InitSha256@Base 3.10.2
>   wc_InitSha384@Base 3.10.2
>   wc_InitSha512@Base 3.10.2
> @@ -209,10 +209,10 @@
>   wc_SetSubjectBuffer@Base 3.10.2
>   wc_SetSubjectKeyId@Base 3.10.2
>   wc_SetSubjectKeyIdFromPublicKey@Base 3.10.2
> - wc_Sha224Final@Base 3.10.2
> - wc_Sha224GetHash@Base 3.10.2
> - wc_Sha224Hash@Base 3.10.2
> - wc_Sha224Update@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Final@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224GetHash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Hash@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wc_Sha224Update@Base 3.10.2
>   wc_Sha256Final@Base 3.10.2
>   wc_Sha256GetHash@Base 3.10.2
>   wc_Sha256Hash@Base 3.10.2
> @@ -749,7 +749,7 @@
>   wolfSSL_EVP_rc4@Base 3.10.2
>   wolfSSL_EVP_ripemd160@Base 3.10.2
>   wolfSSL_EVP_sha1@Base 3.10.2
> - wolfSSL_EVP_sha224@Base 3.10.2
> +#MISSING: 3.10.2+dfsg-1# wolfSSL_EVP_sha224@Base 3.10.2
>   wolfSSL_EVP_sha256@Base 3.10.2

Bug#858476: RFS: wolfssl/3.10.2+dfsg-1 [RC] -- wolfSSL encryption library

[Felix Lechner]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

  * Package name: wolfssl
Version : 3.10.2+dfsg-1
Upstream Author : wolfSSL Inc. 
  * URL : www.wolfssl.com
  * License : various
Section : libs

It builds those binary packages:

libwolfssl10 - wolfSSL encryption library
libwolfssl-dev - Development files for the wolfSSL encryption library

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wolfssl/wolfssl_3.10.2+dfsg-1.dsc

More information about wolfSSL can be obtained from https://www.wolfssl.com.

  Changes since the last upload:

  * New upstream release.
  * New major version is 10
  * New maintainer email address
  * Fixes a low level vulnerability for buffer overflow when loading a
malformed temporary DH file
  * Fixes a medium level vulnerability for processing of OCSP response
  * Fixes CVE-2017-6076, a low level vulnerability for a potential cache attack
on RSA operations (Closes: #856114)

Best regards,
Felix Lechner




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

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

Bug#858476: RFS: wolfssl/3.10.2+dfsg-1 [RC] -- wolfSSL encryption library

[Felix Lechner]

Well, the security issue is probably worth fixing, but it may not make
sense to ship the library in stretch. No other official packages depend on
it.


On Wed, Mar 22, 2017 at 12:28 PM, Andrey Rahmatullin 
wrote:

> On Wed, Mar 22, 2017 at 12:15:49PM -0700, Felix Lechner wrote:
> >   Changes since the last upload:
> >
> >   * New upstream release.
> >   * New major version is 10
> >   * New maintainer email address
> >   * Fixes a low level vulnerability for buffer overflow when loading a
> > malformed temporary DH file
> >   * Fixes a medium level vulnerability for processing of OCSP response
> >   * Fixes CVE-2017-6076, a low level vulnerability for a potential cache
> attack
> > on RSA operations (Closes: #856114)
> According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856114#20
> this is not intended to be fixed in testing, is that correct?
>
> --
> WBR, wRAR
>

Bug#856114: wolfssl: CVE-2017-6076

[Felix Lechner]

Hi Salvatore,

A version fixing the vulnerability is available on Mentors
<https://mentors.debian.net/package/wolfssl>. Please feel free to upload it.

With a new soname version, this upload will go through NEW. Also I am not
sure the library will make it into stretch. Currently, no packages depend
on it.

In the past, I cooperated with Clint Byrum as a sponsor and copied him on
this message. Perhaps he would prefer to upload? Thank you!

Best regards,
Felix


On Mon, Feb 27, 2017 at 5:14 AM, Salvatore Bonaccorso 
wrote:

> Hi Felix,
>
> Sorry for the late reply!
>
> On Sat, Feb 25, 2017 at 08:10:22AM -0800, Felix Lechner wrote:
> > Hi Salvatore,
> >
> > Thank you for your email. I would like to package the new version but
> > 3.10.2 was not signed on GitHub. (Upstream recently added those
> signatures
> > for us.) The more recent release actually fixes two additional
> > vulnerabilities, with one being more serious. Details are in [0] and
> > replicated in part here:
>
> To have the fixes in stretch, at this point of the release I suspect
> we will need to have them cherry-picked. Otherwise I think the release
> team will not ack it to unblock.
>
> >
> > This release of wolfSSL fixes 2 low and 1 medium level security
> > vulnerability.
> >
> > Low level fix of buffer overflow for when loading in a malformed
> temporary
> > DH file. Thanks to Yueh-Hsun Lin and Peng Li from KNOX Security, Samsung
> > Research America for the report.
> >
> > Medium level fix for processing of OCSP response. If using OCSP without
> > hard faults enforced and no alternate revocation checks like OCSP
> stapling
> > then it is recommended to update.
> >
> > Low level fix for potential cache attack on RSA operations. If using
> > wolfSSL RSA on a server that other users can have access to monitor the
> > cache, then it is recommended to update wolfSSL. Thanks to Andreas Zankl,
> > Johann Heyszl and Georg Sigl at Fraunhofer AISEC for the initial report.
> >
> > I will wait with packaging until the release is signed, which may be
> after
> > the weekend. Meanwhile, you are welcome to file reports for the other
> > vulnerabilities. Did MITRE have them too? Thank you!
>
> Alright, thanks for the information. I will check later today if I
> find if CVEs were already assigned. Will come back to you if I have
> some questions!
>
> Regards and thanks for your work!
>
> Salvatore
>

Bug#856992: libpam-mount: Patch for doc target adresses FTBFS on repeated debuilds

[Felix Lechner]

Package: libpam-mount
Version: 2.16-2.1
Severity: wishlist
Tags: patch

Package may FTBFS with the error below when building repeatedly with debuild.
The included patch ensures 'pam_mount.txt' is regenerated.

As a side note, debhelper 10 runs autoreconf, so calling autogen.sh may no
longer be necessary.

* * *

   dh_installdocs
cp: cannot stat 'doc/pam_mount.txt': No such file or directory
dh_installdocs: cp --reflink=auto -a doc/pam_mount.txt debian/libpam-
mount/usr/share/doc/libpam-mount returned exit code 1
debian/rules:6: recipe for target 'binary' failed
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
debuild: fatal error at line 1116:
dpkg-buildpackage -rfakeroot -us -uc -b failed



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

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

Versions of packages libpam-mount depends on:
ii  libc6   2.24-9
ii  libcryptsetup4  2:1.7.3-3
ii  libhx28 3.22-1
ii  libmount1   2.29.1-1
ii  libpam-runtime  1.1.8-3.5
ii  libpam0g1.1.8-3.5
ii  libpcre32:8.39-2.1
ii  libssl1.1   1.1.0e-1
ii  libxml2 2.9.4+dfsg1-2.2

libpam-mount recommends no packages.

Versions of packages libpam-mount suggests:
pn  cifs-utils  
pn  davfs2  
ii  fuse2.9.7-1
ii  lsof4.89+dfsg-0.1
ii  openssl 1.1.0e-1
ii  psmisc  22.21-2.1+b2
pn  sshfs   
ii  xfsprogs4.9.0

-- Configuration Files:
/etc/security/pam_mount.conf.xml changed [not included]

-- no debconf information


013-fix-doc-target.gz
Description: application/gzip

Bug#857244: Please allow luserconf outside home [PATCH]

[Felix Lechner]

Package: libpam-mount
Version: 2.16-2.1
Severity: wishlist
Tags: patch

When mounting encrypted home folders, 'luserconf' files are better located
outside home directories. The attached patch makes that possible.

Currently, all values for 'luserconf' are prepended by $(HOME). The patch
recognizes absolute paths. As a bonus, variables such as $(USER) and $(HOME)
are also expanded.

As an example, we point 'luserconf' to something like
/acct/$(USER)/absent/pam_mount.conf.xml.



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

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

Versions of packages libpam-mount depends on:
ii  libc6   2.24-9
ii  libcryptsetup4  2:1.7.3-3
ii  libhx28 3.22-1
ii  libmount1   2.29.1-1
ii  libpam-runtime  1.1.8-3.5
ii  libpam0g1.1.8-3.5
ii  libpcre32:8.39-2.1
ii  libssl1.1   1.1.0e-1
ii  libxml2 2.9.4+dfsg1-2.2

libpam-mount recommends no packages.

Versions of packages libpam-mount suggests:
pn  cifs-utils  
pn  davfs2  
ii  fuse2.9.7-1
ii  lsof4.89+dfsg-0.1
ii  openssl 1.1.0e-1
ii  psmisc  22.21-2.1+b2
pn  sshfs   
ii  xfsprogs4.9.0

-- Configuration Files:
/etc/security/pam_mount.conf.xml changed [not included]

-- no debconf information


014-allow-luserconf-outside-home.gz
Description: application/gzip

Bug#857244: Updated patch

[Felix Lechner]

Updated patch to avoid segfault when no  is present. Thank you!


014-allow-luserconf-outside-home.gz
Description: GNU Zip compressed data

Bug#855401: Also affects testing

[Felix Lechner]

Control: retitle -1 ifupdown2: missing dependency on python-pkg-resources
Control: severity -1 important

Affects the version in testing, as well (1.0~git20170114-1).

Also, headless machines may not boot properly, so I am upgrading the
severity.

Bug#855593: krb5-config: Please widen dependency on 'host'

[Felix Lechner]

Package: krb5-config
Version: 2.6
Severity: wishlist

The exclusive dependency on bind9-host prevents the installation of
knot-host. The package could allow competing implementations
by depending on bind9-host | host. Thank you!


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

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

Versions of packages krb5-config depends on:
ii  bind9-host 1:9.10.3.dfsg.P4-11.1
ii  debconf [debconf-2.0]  1.5.60

krb5-config recommends no packages.

krb5-config suggests no packages.

-- debconf information excluded

Bug#855972: 2ping: Missing dependency on python-pkg-resources

[Felix Lechner]

Package: 2ping
Version: 3.2.1-1
Severity: normal

Starting 2ping or 2ping6 aborts with the error below. Please add a
dependency on python-pkg-resources. Thank you!

Traceback (most recent call last):
  File "/usr/bin/2ping", line 5, in 
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources


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

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

Versions of packages 2ping depends on:
ii  init-system-helpers1.47
ii  libpython2.7-stdlib [python-argparse]  2.7.13-2
ii  python 2.7.13-2
pn  python:any 

2ping recommends no packages.

2ping suggests no packages.

-- no debconf information

Bug#856114: wolfssl: CVE-2017-6076

[Felix Lechner]

Hi Salvatore,

Thank you for your email. I would like to package the new version but
3.10.2 was not signed on GitHub. (Upstream recently added those signatures
for us.) The more recent release actually fixes two additional
vulnerabilities, with one being more serious. Details are in [0] and
replicated in part here:

This release of wolfSSL fixes 2 low and 1 medium level security
vulnerability.

Low level fix of buffer overflow for when loading in a malformed temporary
DH file. Thanks to Yueh-Hsun Lin and Peng Li from KNOX Security, Samsung
Research America for the report.

Medium level fix for processing of OCSP response. If using OCSP without
hard faults enforced and no alternate revocation checks like OCSP stapling
then it is recommended to update.

Low level fix for potential cache attack on RSA operations. If using
wolfSSL RSA on a server that other users can have access to monitor the
cache, then it is recommended to update wolfSSL. Thanks to Andreas Zankl,
Johann Heyszl and Georg Sigl at Fraunhofer AISEC for the initial report.

I will wait with packaging until the release is signed, which may be after
the weekend. Meanwhile, you are welcome to file reports for the other
vulnerabilities. Did MITRE have them too? Thank you!

Best regards,
Felix

[0] https://github.com/wolfSSL/wolfssl/releases/tag/v3.10.2-stable


On Sat, Feb 25, 2017 at 2:27 AM, Salvatore Bonaccorso 
wrote:

> Source: wolfssl
> Version: 3.9.10+dfsg-1
> Severity: grave
> Tags: upstream security patch fixed-upstream
>
> Hi,
>
> the following vulnerability was published for wolfssl.
>
> CVE-2017-6076[0]:
> | In versions of wolfSSL before 3.10.2 the function fp_mul_comba makes
> | it easier to extract RSA key information for a malicious user who has
> | access to view cache on a machine.
>
> From the release notes:
>
> Low level fix for potential cache attack on RSA operations. If using
> wolfSSL RSA on a server that other users can have access to monitor
> the cache, then it is recommended to update wolfSSL. Thanks to Andreas
> Zankl, Johann Heyszl and Georg Sigl at Fraunhofer AISEC for the
> initial report.
>
> 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-6076
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6076
> [1] https://github.com/wolfSSL/wolfssl/commit/
> 345df93978c41da1ac8047a37f1fed5286883d8d
> [2] https://github.com/wolfSSL/wolfssl/pull/674
>
> Regards,
> Salvatore
>

Bug#860046: wolfssl: Incomplete debian/copyright?

[Felix Lechner]

Chris,

Sorry about the oversight. Please find a new upload
 on Mentors, closing two bugs.
Thank you!

Best regards,
Felix


On Mon, Apr 10, 2017 at 10:13 AM, Chris Lamb  wrote:

> Source: wolfssl
> Version: 3.10.2+dfsg-1
> Severity: serious
> Justication: Policy 12.5
>
> Hi,
>
> I just ACCEPTed wolfssl from NEW but noticed it was missing
> attribution in debian/copyright for at least the files under m4/
>
> (This is not exhaustive so please check over the entire package
> carefully and address these on your next upload.)
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>

Bug#859623:

[Felix Lechner]

Thank you for documenting the issue. I have had this problem for a long
time.

Bug#822532: Should not conflict with slapd

[Felix Lechner]

Package: 389-ds-base
Version: 1.3.4.9-1

Port assignments are flexible with SRV records. Conflict with slapd may be
unnecessary.

Bug#786574: ITP: msx264 -- Mediastreamer plugin for the H.264 video codec

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

* Package name: msx264
  Version : 1.5.1
  Upstream Author : Simon Morlat 
* URL : http://www.linphone.org
* License : GPL-2+
  Programming Lang: C
  Description : Mediastreamer plugin for the H.264 video codec

This dynamically loaded codec wrapper is part of Linphone. It will be
maintained in the Debian VOIP Team.


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

Bug#787150: ITP: mediastreamer2 -- Voice and video streaming engine for telephony

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

 * Package name: mediastreamer2
  Version : 2.11.2
  Upstream Author : Simon Morlat 
* URL :
http://www.linphone.org/technical-corner/mediastreamer2/downloads
* License : GPL-2+, GPL-3+, LGPL-2.1, Apache, BSD-3-clause, BSD-2-clause
  Programming Lang: C
  Description : Voice and video streaming engine for telephony

 Mediastreamer2 is a powerful and lightweight streaming engine
 specially designed for voice/video telephony applications.The
 library is part of Linphone.
 .
 Like ortp, the library was previously shipped and versioned
 together with Linphone. The two libraries are being separated.
 Their versioning will require a new epoch.

Bug#785407: Reportbug still crashes

[Felix Lechner]

The problem still exists with reportbug 6.6.3 on testing.


Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2211, in 
main()
  File "/usr/bin/reportbug", line 1081, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1703, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py", line
1505, in func
args, kwargs = op.sync_pre_operation (*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/reportbug/ui/gtk2_ui.py", line
886, in sync_pre_operation
http_proxy=http_proxy, archived=archived, source=source)
  File "/usr/lib/python2.7/dist-packages/reportbug/debbugs.py", line 1275,
in get_reports
stats = debianbts.get_status(bugs)
  File "/usr/lib/pymodules/python2.7/debianbts.py", line 179, in get_status
reply = server.get_status(*nr)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 545, in
__call__
return self.__r_call(*args, **kw)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 567, in
__r_call
self.__hd, self.__ma)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 430, in
__call
timeout = self.timeout)
  File "/usr/lib/python2.7/dist-packages/SOAPpy/Client.py", line 318, in
call
raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: 

Bug#785407: Now it works

[Felix Lechner]

Now it works. Thank you!

Bug#785461: ITP: bzrtp -- Library for the ZRTP key exchange protocol

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

* Package name: bzrtp
  Version : 1.0.2
  Upstream Author : Simon Morlat 
* URL : http://www.linphone.org/
* License : GPL-2+
  Programming Lang: C
  Description : Library for the ZRTP key exchange protocol

This package is part of Linphone, but is packaged separately. Like Linphone it
will be maintained by the Debian VOIP Team.

This new library enables certain encrypted communications in Linphone.


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

Bug#785480: ITP: bcg729 -- ITU G.729 Annex A compatible audio codec

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

* Package name: bcg729
  Version : 1.0.0
  Upstream Author : Felix Lechner 
* URL : http://www.linphone.org/technical-corner/bcg729/overview
* License : GPL-2+, BSD-2-clause
  Programming Lang: C
  Description : ITU G.729 Annex A compatible audio codec

 Bcg729 is an open source implementation of the ITU G729 Annex A
 speech codec. Written in C 99, the library is fully portable. It
 runs on many platforms, including ARM and x86.
 .
 Bcg729 supports concurrent channels encoding/decoding for multi
 call application such as conferencing.
 .
 The project was developed as part of mediastreamer2, Linphone's
 media processing engine. It also contains the glue forintegration
 into Linphone/mediastreamer2.


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

Bug#785499: ITP: msamr -- Mediastreamer plugin for AMR audio codec

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

 * Package name: msamr
  Version : 1.0.1
  Upstream Author : Simon Morlat 
* URL :
http://www.linphone.org/technical-corner/mediastreamer2/downloads
* License : GPL-2+
  Programming Lang: C
  Description : Mediastreamer plugin for AMR audio codec

 This package contains the AMR (adaptive multi-rate) codec plugin for
 mediastreamer, which is part of Linphone.
 .
 The project was developed as part of mediastreamer2, Linphone's
 media processing engine.

Bug#785522: ITP: ortp -- Real-time Transport Protocol (RTP) stack

[Felix Lechner]

Package: wnpp
Severity: wishlist
Owner: Felix Lechner 

 * Package name: ortp
  Version : 0.24.2
  Upstream Author : Simon Morlat 
* URL :
http://www.linphone.org/technical-corner/mediastreamer2/downloads
* License : LGPL-2.1, BSD-3-clause, BSD-2-clause
  Programming Lang: C
  Description : Real-time Transport Protocol (RTP) stack

 This library implements RFC 1889 (RTP) and offers an easy to
 use API with high-level and low-level access. The library is
 part of Linphone.
 .
 The library was previously shipped and versioned together
 with the Linphone executable. That now causes circular
 dependencies. The latest version of Linphone depends on
 bzrtp, which is released separately, for additional encrypted
 communications, but bzrtp depends on ortp and mediastreamer2.
 .
 To avoid the circular dependency, the two libraries ortp and
 mediastreamer2 are being separated. They are on different
 release cycles anyway. Unfortunately, their versioning
 requires a new epoch.

Bug#801265: Build problem has been fixed upstream

[Felix Lechner]

A recent upload to Mentors fixes this issue. It should be in the archive
shortly.

Should Britney remove the package from testing on Nov 5, you can still get
it from unstable. Just download it from https://packages.debian.org or via
apt.


On Mon, Nov 2, 2015 at 2:25 PM, SM0SVX  wrote:

> Hi!
>
> I'm the original author of the SvxLink software.
>
> The C++11 problem appeared because libsigc++ in Debian was upgraded to a
> version that require C++11 support to be turned on in the compiler.
> However,
> if C++11 support was turned on, SvxLink would not compile since some
> existing
> static const declations seemed to be illegal in C++11.
>
> The problem has now been fixed upstream in the 14.08.2 release:
>
> https://github.com/sm0svx/svxlink/releases/tag/14.08.2
>
> Best regards,
> Tobias
>

Bug#766606: Workaround not working here

[Felix Lechner]

The work-around did not work for me. I couldn't get the host command to
wait with -W 5 and didn't try shell wait. I use dnssec-trigger, a
validating resolver, which may have something to do with it. I also added
'-N 2' to host for better domain parsing and set my domain in
/etc/resolv.conf (in dnssec-trigger.conf, in my case).

I believe systemd will eventually make this better. For now, I tried the
Required-Start boot facility to have nslcd depend on dnsssec-trigger, but
that did not work. Some kind of retry interplay between k5start and nslcd
might also be useful.

Bug#733060: ITP: svxlink -- voice services system for ham radio use

[Felix Lechner]

Hello Ian,

I am, but I could not find a sponsor for my 'svxlink' package.

Felix

On Mon, Sep 15, 2014 at 1:25 PM, Iain R. Learmonth  wrote:

> Hi,
>
> Are you still working on this?
>
> Thanks,
> Iain.
>
> --
> e: i...@fsfe.orgw: iain.learmonth.me
> x: i...@jabber.fsfe.org t: +447875886930
> c: MM6MVQ  g: IO87we
> p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
>

Bug#733060: ITP: svxlink -- voice services system for ham radio use

[Felix Lechner]

Hello Ian,

I wrote to 'debian-h...@lists.debian.org' on December 1, 2013.
Unfortunately, I could not find a sponsor there.

I maintain other packages, but do not have upload privileges for the
archive. We need a Debian Developer.

Felix

On Mon, Sep 15, 2014 at 3:50 PM, Iain R. Learmonth  wrote:

> On Mon, Sep 15, 2014 at 03:44:43PM -0700, Felix Lechner wrote:
> > I am, but I could not find a sponsor for my 'svxlink' package.
>
> Have you got a link to the VCS for this? I can take a look at the package
> first and if there's no problems I can see, you can ask the Debian Hams
> mailing list for sponsorship.
>
> Thanks,
> Iain.
>
> --
> e: i...@fsfe.orgw: iain.learmonth.me
> x: i...@jabber.fsfe.org t: +447875886930
> c: MM6MVQ  g: IO87we
> p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
>

Bug#744082: Progress report

[Felix Lechner]

This is a JNI glue library. I should ask the sponsor of wolfSSL to upload
it, but have not done so. The Debian package is ready to go.

wolfSSL is the latest version of an encryption library popular in embedded
environments. It is used in MySQL and Skype. cURL, stunnel, lighttpd can
build with it. Other software that uses it is cataloged here:

https://www.wolfssl.com/wolfSSL/Community.html

Bug#769905: Marked for closure

[Felix Lechner]

>From release 3.3.0 onward the library will not allow SSLv3 unless the user
enables it with CyaSSL_SetMinVersion(). I will therefore close this bug
with release 3.3.0.

Per upstream:

We're working on phasing out SSL 3.0 support, as described here:

http://wolfssl.com/yaSSL/Blog/Entries/2014/11/5_Deprecating_SSL_3.0_from_wolfSSL.html

CyaSSL 3.3.0 implemented item #1 from that post, where a CyaSSL server
using the CyaSSLv23_server_method() or client using
CyaSSLv23_client_method(), will only downgrade to a minimum of TLS 1.0,
unless the user specifically enables SSL 3.0 with CyaSSL_SetMinVersion().
Future releases will implement items #2 and #3.

Bug#873741: pius: Manpage describes '-H' incorrectly

[Felix Lechner]

Package: pius
Version: 2.2.4-1
Severity: normal

The man page for 'pius' says the default for '-H' is 'localhost' when it is in
fact 'none'.

The correct default is available via 'pius -h'.



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

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

Versions of packages pius depends on:
ii  gnupg   2.1.18-8
ii  gnupg2  2.1.18-8
ii  python  2.7.13-2

pius recommends no packages.

pius suggests no packages.

-- no debconf information

Bug#857248: nullmailer: bug found!

[Felix Lechner]

David,

I found the bug affecting the tests. (It was an issue only when TLS was
enabled, and there were some race conditions.) I packaged version 2.0
and uploaded
it to Mentors .

You are still welcome to adopt the package. Or, you can sponsor me---I
really don't care. Just trying to help.

Some of the open items in my version are:

1. Syslog code (and therefore '--daemon') not adopted from prior version.
It probably would be a good idea, but is complicated, and the package works
without it.

2. I slightly modified the interplay between '/etc/mailname', 'me' and
'defaulthost' to allow the tests to complete. Not sure if that broke the
'/etc/mailname' behavior. I don't use that feature.

Sorry I did not work through collab-maint. I did not see the package on
Alioth until today. (I also did not see your bug message from Aug 2,
although I did see your letter to upstream.)

Best regards,
Felix

Bug#853672: svxlink: diff for NMU version 15.11-2.1

[Felix Lechner]

Adrian,

Thank you for doing this!

Felix


On Fri, Sep 1, 2017 at 6:20 AM, Adrian Bunk  wrote:

> Control: tags 853672 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for svxlink (versioned as 15.11-2.1) and uploaded
> it to DELAYED/10. Please feel free to tell me if I should cancel it.
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
>

Bug#857248: nullmailer: bug found!

[Felix Lechner]

On Tue, Sep 5, 2017 at 3:52 AM, David Bremner  wrote:

> Felix Lechner  writes:
>
> > David,
> >
> > I found the bug affecting the tests. (It was an issue only when TLS was
> > enabled, and there were some race conditions.) I packaged version 2.0
> > and uploaded
> > it to Mentors <https://mentors.debian.net/package/nullmailer>.
> >
> > You are still welcome to adopt the package. Or, you can sponsor me---I
> > really don't care. Just trying to help.
>
> OK, I'm (slowly) looking at your patches. My current plan is to
> integrate (most of) your changes and add you as an Uploader to the
> package in collab-maint. That's mostly symbolic but it might help get a
> sponsor in the future if I'm not available.
>
>
That's a great solution. Thank you!


> > Some of the open items in my version are:
> >
> > 1. Syslog code (and therefore '--daemon') not adopted from prior version.
> > It probably would be a good idea, but is complicated, and the package
> works
> > without it.
>
> I think this is probably gone for good. We do have to take a bit more
> care: I think /etc/init.d/nullmailer probably needs to be dropped from
> the package, since it relies on -s. A NEWS item for those people relying
> on non-systemd inits seems also needed.
>
>
Thank you for catching that. It's probably the right thing to do.


> >
> > 2. I slightly modified the interplay between '/etc/mailname', 'me' and
> > 'defaulthost' to allow the tests to complete. Not sure if that broke the
> > '/etc/mailname' behavior. I don't use that feature.
> >
>
> Was there more than just grouping patches here?
>

Yes, I honored 'me' when '/etc/mailname' does not exist; the previous
maintainer ignored 'me'. (Now the tests complete and testing for a
Debian-compliant '/etc/mailname' may not be necessary.) Also, the patched
man pages substitute '/etc/mailname' for 'me', so the fallback behavior is
undocumented.

-  if (!config_read("me", me)) {
+  if (!config_read("../mailname", me) && !config_read("me", me)) {

vs.

-  if (!config_read("me", me)) {
+  if (!config_read("../mailname", me)) {

In addition, I did not follow the previous maintainer when he no longer
required at least one dot in the domain part of an email address. He
commented out a call in src/queue.cc to upstream's function find_first(),
which is replicated here for your convenience. The check takes place after
a possible remapping of 'localhost' and seemed reasonable, so I kept it.

int mystring::find_first(char ch, size_t offset[default 0]) const
{
  if(offset >= rep->length)
return -1;
  char* ptr = strchr(rep->buf+offset, ch);
  return ptr ? ptr-rep->buf : -1;
}

bool validate_addr(mystring& addr, bool doremap)
{
  int i = addr.find_last('@');
  if(i < 0)
return false;
  mystring hostname = addr.right(i+1);
  if(doremap && remapadmin) {
if(hostname == me || hostname == "localhost")
  addr = adminaddr;
  }
  // else if(hostname.find_first('.') < 0) [NOT ADOPTED]
// return false; [NOT ADOPTED]
  return true;
}

Best regards,
Felix

Bug#857248: nullmailer: bug found!

[Felix Lechner]

Hi David,

To save you and others time I filed pull requests for the 'errno' bug
<https://github.com/bruceg/nullmailer/pull/43> and the fix for race
conditions <https://github.com/bruceg/nullmailer/pull/44>. Hope this did
not preempt your review. Thank you for looking at my patches!

Best regards,
Felix


On Tue, Sep 5, 2017 at 3:52 AM, David Bremner  wrote:

> Felix Lechner  writes:
>
> > David,
> >
> > I found the bug affecting the tests. (It was an issue only when TLS was
> > enabled, and there were some race conditions.) I packaged version 2.0
> > and uploaded
> > it to Mentors <https://mentors.debian.net/package/nullmailer>.
> >
> > You are still welcome to adopt the package. Or, you can sponsor me---I
> > really don't care. Just trying to help.
>
> OK, I'm (slowly) looking at your patches. My current plan is to
> integrate (most of) your changes and add you as an Uploader to the
> package in collab-maint. That's mostly symbolic but it might help get a
> sponsor in the future if I'm not available.
>
> > Some of the open items in my version are:
> >
> > 1. Syslog code (and therefore '--daemon') not adopted from prior version.
> > It probably would be a good idea, but is complicated, and the package
> works
> > without it.
>
> I think this is probably gone for good. We do have to take a bit more
> care: I think /etc/init.d/nullmailer probably needs to be dropped from
> the package, since it relies on -s. A NEWS item for those people relying
> on non-systemd inits seems also needed.
>
> >
> > 2. I slightly modified the interplay between '/etc/mailname', 'me' and
> > 'defaulthost' to allow the tests to complete. Not sure if that broke the
> > '/etc/mailname' behavior. I don't use that feature.
> >
>
> Was there more than just grouping patches here?
>

Bug#857248: nullmailer: bug found!

[Felix Lechner]

On Wed, Sep 6, 2017 at 5:44 PM, David Bremner  wrote:

> Felix Lechner  writes:
>
> >   }
> >   // else if(hostname.find_first('.') < 0) [NOT ADOPTED]
> > // return false; [NOT ADOPTED]
> >   return true;
> > }
>
> That change was originally to fix
>
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504184
>
> Do you know if the configurations discussed there will still work?
>
> d
>

Hi David,

Nice detective work! Attached please find a patch to allow unqualified
domain names.

I further attached an updated patch for '/etc/mailname'. A small warning is
issued when 'me' is present, but the file is disregarded---as it says in
the man pages. The tests use '/etc/mailname', as well.

Please apply the second patch after the first.

Finally, I added some information to an empty section for nullmailer on the
Debian Wiki for '/etc/mailname' <https://wiki.debian.org/EtcMailName>.
Please edit further if needed. Thank you!

Best regards,
Felix


allow-unqualified-domains.patch.gz
Description: GNU Zip compressed data


etc-mailname.patch.gz
Description: GNU Zip compressed data

Bug#852730: (no subject)

[Felix Lechner]

Subject: simple-scan: When saving, please confirm before overwriting files
Package: simple-scan
Version: 3.23.2-1
Severity: wishlist
Tags: upstream

Hi,

Thanks to the simple interface, it's easy to delete a page after saving it. 
Unfortunately,
subsequent scans will then replace the most recent file without confirmation 
(unless one
hits the "New Scan" button). In this commenter's view it would be better to 
confirm before
replacing an existing file in that situation. Thank you!

Best regards,
Felix

-- Package-specific info:

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

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

Versions of packages simple-scan depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.14-1
ii  dbus-x11 [dbus-session-bus]   1.10.14-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-8
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libcolord21.3.3-2
ii  libgdk-pixbuf2.0-02.36.3-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk-3-03.22.6-1
ii  libgusb2  0.2.9-1
ii  libpackagekit-glib2-181.1.4-3
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libsane   1.0.25-2+b1
ii  libsqlite3-0  3.16.2-1
ii  libusb-1.0-0  2:1.0.21-1
ii  xdg-utils 1.1.1-1
ii  zlib1g1:1.2.8.dfsg-4

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information

Bug#852730: (no subject)

[Felix Lechner]

Hi Jörg,

Please try the following procedure: (1) scan, (2) save, (3) delete, (4)
scan, (5) save. The "Start New Document" button is never pressed. Step 5
will overwrite the file from 2 without confirmation.

Perhaps the second save should also prompt for a file name (in addition to
confirming the replacement) since the user may have had a separate use for
the first file, such as saving a document without attachments. Thank you!

Best regards,
Felix


On Jan 27, 2017 9:40 AM, "Jörg Frings-Fürst" 
wrote:

tags 852730 + moreinfo
thanks


Hello Felix,


thank you for spending your time helping to make Debian better with
this bug report.

I have checked the handling.

 * scan one page
 * save the page
 * select "Start new document"
 * scan one page
 * select "Start new document"
 * - opens "Save current document"
 * and so on...


All save function are "Save as" so that the file name can selected or
written.

Multiple Scans are saved with -1, -2, ... as index.

So I don't see any replace without confirmation.


Please can you explain what you mean?


CU
Jörg

--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list:
 - Please send me a picture from the nature at your home.

Bug#849215: encfs: 1.9.1-3 not a drop in replacement for previous version

[Felix Lechner]

Package: encfs
Version: 1.9.1-3
Severity: important

When an encrypted home directory is on kerberized NFS4, upgrading to version 
1.9.1-3 in testing causes errors not present in the previous version.
Logging in via terminal works, but not via GNOME/gdm 3.

Also, at some point an error appears when accessing the cleartext mountpoint. 
Then the "Transport endpoint is not connected" (even though
the default idle unmount setting was disabled in /etc/security/pam_encfs.conf). 
Furthemore, some subsequent mount attempts via PAM seem to trigger
segfaults like the ones below. It is currently unclear if the idle override is 
being ignored or there is another, potentially more serious problem.

Dec 23 08:27:01 lechner-desktop kernel: [  192.786639] encfs[2308]: segfault at 
0 ip 7fce39883f36 sp 7fce37b4d970 error 4 in 
libencfs.so.1.9.1[7fce3982a000+75000]
Dec 23 08:32:50 lechner-desktop kernel: [  146.913824] encfs[1763]: segfault at 
0 ip 7f052e4dff36 sp 7f052b7a7970 error 4 in 
libencfs.so.1.9.1[7f052e486000+75000]
Dec 23 08:57:11 lechner-desktop kernel: [  166.904051] traps: encfs[1856] 
general protection ip:7fba93de28d4 sp:7fba92219958 error:0 in 
libc-2.24.so[7fba93c9e000+195000]
Dec 23 09:13:49 lechner-desktop kernel: [  747.796823] encfs[1952]: segfault at 
0 ip 7f63c3cf7f36 sp 7f63c1c91970 error 4 in 
libencfs.so.1.9.1[7f63c3c9e000+75000]

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

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

Versions of packages encfs depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  fuse   2.9.7-1
ii  libc6  2.24-8
ii  libfuse2   2.9.7-1
ii  libgcc11:6.2.1-5
ii  libssl1.1  1.1.0c-2
ii  libstdc++6 6.2.1-5
ii  libtinyxml2-4  4.0.1-1
ii  mount  2.29-1

encfs recommends no packages.

encfs suggests no packages.

-- debconf information:
* encfs/security-information:

Bug#845284: Seeking a sponsor

[Felix Lechner]

Hi,

I packaged Pius version 2.2.2. Seeking a sponsor, please. Thank you!

Best regards,
Felix

Bug#846621: override: pius:utils/extra

[Felix Lechner]

Package: ftp.debian.org
Severity: normal

The package ships four python 'application' scripts together with an interal
library called 'libpius'. Changing the section from utils to python triggers
the experimental tag 'application-in-library-section'. After checking on IRC,
it seems utils/extra is correct. Thank you!



(Describe here the reason for this change)

Bug#793134: Packaging of newest upstream version in progress

[Felix Lechner]

Uploaded and pending in NEW.


On Fri, Dec 2, 2016 at 12:11 AM, Nobuhiro Iwamatsu 
wrote:

> Hi,
>
> > Newest version will be uploaded soon. Upstream is reviewing configured
> > ciphers and options.
>
> ping?
>
> --
> Nobuhiro Iwamatsu
>iwamatsu at {nigauri.org / debian.org}
>GPG ID: 40AD1FA6
>

Bug#849608: nfs-common: For rpc.gssd, keytab location is hardcoded to /etc/krb5.keytab

[Felix Lechner]

Package: nfs-common
Version: 1:1.3.4-2
Severity: normal
Tags: patch

Hi,

Someone using a keytab other than /etc/krb5.keytab must pass the location with
"-k" to rpc.gssd. Currently, those arguments are not collected from
/etc/defaults/nfs-common. (A similar point is addressed in report #846950.) As
an additional hurdle, rpc.gssd's systemd service will not run unless the
specific location /etc/krb5.keytab exists. The attached patch makes it possible
to specify custom keytab locations with "-k" in /etc/defaults/nfs-common.

A better solution would probably be to patch rpc.gssd so that it uses the
"default_keytab_name" from the [libdefaults] section in /etc/krb5.conf, unless
overridden. To salvage the systemd test, one may have to specify the keytab
location separately from other command-line options in /etc/defaults/nfs-
common. The attached patch does not do any of that.

Thank you for providing this package!

Best regards,
Felix



-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
1000241   udp  55091  status
1000241   tcp  35661  status
-- /etc/default/nfs-common --
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=yes
NEED_GSSD=yes
RPCGSSDOPTS="-k /etc/keytabs/host.keytab"
-- /etc/idmapd.conf --
[General]
Verbosity = 5
Pipefs-Directory = /run/rpc_pipefs
Domain = us-core.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
-- /etc/fstab --
wallace-server:/acct /acct nfs4 rw,sec=krb5i 0 0
-- /proc/mounts --
wallace-server:/acct /acct nfs4
rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=2601:641:1:1c4e:baca:3aff:fe87:5f15,local_lock=none,addr=2601:641:1:1c4e::240a:2308
0 0

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nfs-common depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  keyutils 1.5.9-9
ii  libc62.24-8
ii  libcap2  1:2.25-1
ii  libcomerr2   1.43.3-1
ii  libdevmapper1.02.1   2:1.02.137-1
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libgssapi-krb5-2 1.15-1
ii  libk5crypto3 1.15-1
ii  libkeyutils1 1.5.9-9
ii  libkrb5-31.15-1
ii  libmount12.29-1
ii  libnfsidmap2 0.25-5
ii  libtirpc10.2.5-1.1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20161125
ii  rpcbind  0.2.3-0.5
ii  ucf  3.0036

Versions of packages nfs-common recommends:
ii  python  2.7.11-2

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- Configuration Files:
/etc/default/nfs-common changed [not included]

-- no debconf information

-- debsums errors found:


nfs-utils.diff.gz
Description: application/gzip

Bug#846950: Merging with #849608

[Felix Lechner]

Hi,

Sebastian's point is also addressed in #849608 ('keytab location is
hardcoded to /etc/krb5.keytab'). Pursuant to the maintainer's request from
December 15, I will try to merge both reports.

Best regards,
Felix

Bug#846950: It is not only RPCSVCGSSDOPTS but also RPCGSSDOPTS that is not correctly propagated

[Felix Lechner]

Hi Joachim,

Thank you! As you pointed out, a similar issue exists with rpc.svcgssd but
that daemon honors the default keytab location specified in /etc/krb5.conf.
The systemd service file simply tests for the wrong condition. Since our
issues are related but different, I am cloning the bug. A patch for my
issue is attached.

As a side note, anyone using a custom keytab on the server must pass
arguments to rpc.svsgssd, yet the daemon runs as root and any separation of
privileges, for example by providing /etc/keytabs/nfs.keytab, may not
provide additional security benefits.

Your patch is also very much needed. For consistency, I would probably go
with RPCSVCGSSDARGS in /lib/systemd/system/rpc-svcgssd.service and provide
a default entry for RPCSVCGSSDOPTS in /etc/default/nfs-kernel-server. Thank
you!

Best regards,
Felix


rpc-svcgssd.service.patch.gz
Description: GNU Zip compressed data

Bug#849850:

[Felix Lechner]

Hi Timo,

I filed a similar report under #849215 but was unable to pin the issue on
the encfs package. What is your underlying file system, please? Also, are
you using pam_encfs.so to mount? Thank you!

Best regards,
Felix

Bug#793134: Packaging of newest upstream version in progress

[Felix Lechner]

Newest version will be uploaded soon. Upstream is reviewing configured
ciphers and options.

Bug#1057340: Please drop Felix from Uploaders

[Felix Lechner]

Package: wolfssl
Severity: wishlist
X-Debbugs-CC: Bastian Germann 

Hi Bastian,

Please replace my name with yours in the Uploaders field when you get a
chance. I do not have time to help maintain wolfSSL at the moment since
my wife had a baby. Thanks!

Kind regards
Felix

Bug#1023697: Keep out of testing

[Felix Lechner]

Hi,

On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
>
> wolfssl has no active maintainer, plenty of open security issues and we 
> already
> have too many TLS libraries in our releases. Keep it out of testing. I'm going
> to file bugs against the handful of reverse deps.

Sorry, I have been out ill, but please do what you think is right.

Kind regards
Felix

Bug#1023697: Version 5.5.3-1 is in the NEW queue

[Felix Lechner]

Hi,

FWIW, version 5.5.3-1 was accepted into the NEW queue.

Kind regards
Felix Lechner

Bug#1040002: Drop Felix from Uploaders

[Felix Lechner]

Package: nullmailer
Severity: wishlist

Hi David,

I have not used nullmailer in a little while, and I do not plan to
work on the package in the near future.

Please remove my email address from the Uploaders field at your leisure. Thanks!

Kind regards
Felix

P.S. The proposed change alone did not seem to justify an upload.

Bug#1021021: Upload planned

[Felix Lechner]

Hi,

I plan to upload version 5.5.1 in the near future.

Kind regards
Felix Lechner

Bug#1025789: bullseye-pu: wolfssl/4.6.0+p1-0+deb11u1_4.6.0+p1-0+deb11u2.debdiff

[Felix Lechner]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: sirkilam...@msn.com

Hi,

The wolfssl upstream released three patches for the version in Debian
stable specifically in order to address the following three
vulnerabilities present in bullseye:

- CVE-2022-42961, scored by NVD as "5.3 medium" [1]
- CVE-2022-39173, scored by NVD as "7.5 high" [2]
- CVE-2022-42905, scored by NVD as "9.1 critical" [3]

All three vulnerabilities are being tracked by DSA. [4] They were
already fixed in unstable.

There is no separate bug for the stable package.

Given the increased popularity of the package [5] and the severity of
the vulnerabilities, it seemed prudent to offer users of Debian stable
an update.

This bug was filed with a view toward the upcoming point release 11.6
for bullseye, which is scheduled for December 17. The freeze starts
this weekend.
The proposed upload has not seen a lot of testing.

Following devref 5.5.1 [7] a source debdiff was attached.

Please let me know if the version number is right and if you need any
more information, or whether I may upload the package. Thanks!

Kind regards,
Felix Lechner

[1] https://nvd.nist.gov/vuln/detail/CVE-2022-42961
[2] https://nvd.nist.gov/vuln/detail/CVE-2022-39173
[3] https://nvd.nist.gov/vuln/detail/CVE-2022-42905
[4] https://security-tracker.debian.org/tracker/source-package/wolfssl
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023697#28
[6] https://lists.debian.org/debian-release/2022/11/msg00251.html
[7] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions


wolfssl_4.6.0+p1-0+deb11u1.dsc_wolfssl_4.6.0+p1-0+deb11u2.dsc.debdiff.xz
Description: Binary data

Bug#1023697: Keep out of testing

[Felix Lechner]

Hi,

On Fri, Nov 25, 2022 at 4:27 AM Bastian Germann  wrote:
>
> It would be great to address the CVEs with patches on 4.6.0+p1-0+deb11u1.

A proposed update for the 11.6 point release of bullseye, which is
scheduled for next weekend, was filed with the release team. [1] They
were also contacted for guidance via IRC.

Kind regards
Felix Lechner

[1] https://bugs.debian.org/1025789

cc: Security Team

Bug#1023835: wolfssl: FTBFS because of amd64-only symbols in symbols file

[Felix Lechner]

Hi,

On Thu, Nov 10, 2022 at 4:06 PM Bastian Germann  wrote:
>
> Please keep the three symbols out of the symbols file or make them optional.

Thanks. We are aware of the issue.

Unfortunately, your suggestion will likely cause a build failure on
amd64. How do you make the symbols "optional" please? Thanks!

Kind regards,
Felix Lechner

Bug#1023697: Keep out of testing

[Felix Lechner]

Hi,

On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
>
> open security issues

I also just uploaded a backport for bullseye.

Kind regards,
Felix Lechner

Bug#920691: lintian gets stuck collecting info after failed objdump-info

[Felix Lechner]

On Mon, Feb 4, 2019 at 5:03 AM Raphael Hertzog  wrote:
> Thanks for the notice, I tried with that version of Perl but the problem I
> reported is still present. So it seems unrelated.

Here is a merge request that seems to fix the issue by reverting:
https://salsa.debian.org/lintian/lintian/merge_requests/139

I am only making it available in case downgrading is not an option.
The merge request should not be accepted. Still looking for the actual
bug.

Bug#920691: lintian gets stuck collecting info after failed objdump-info

[Felix Lechner]

On Mon, Feb 4, 2019 at 5:03 AM Raphael Hertzog  wrote:
> Thanks for the notice, I tried with that version of Perl but the problem I
> reported is still present. So it seems unrelated.

This MR fixes the hang here:

https://salsa.debian.org/lintian/lintian/merge_requests/140

Bug#886036: Salsa merge request

[Felix Lechner]

The patches were consolidated in this merge request
(https://salsa.debian.org/lintian/lintian/merge_requests/14).

Bug#904707: fakeroot chown fails on kerberized NFSv4

[Felix Lechner]

Package: lintian
Version: 2.5.94

Hi,

When the Lintian test suite runs on a kerberized NFSv4 volume,
't/tests/files-wrong-owner' fails with this error message:

tests::files-wrong-owner: chown: changing ownership of
'debian/files-wrong-owner/usr/lib/filenames/wrong-owner-100:0':
Invalid argument
tests::files-wrong-owner: make[1]: *** [debian/rules:13:
override_dh_fixperms] Error 1

The full log is attached.

I can replicate the behavior by cloning Lintian from salsa and running
'./debian/rules runtests onlyrun=files-wrong-owner'. I isolated the
error in the shell script below (also attached). In a strange twist,
the script produces no error for some low uids here, including 0 and
1, but fails consistently for uids that don't exist. (The uid 100
exists but fails.) Please try a different uid if you do not get the
error right away.

#!/bin/sh
set -x
tmpdir="$(mktemp -d --tmpdir=.)"
tmpfile="$(mktemp --tmpdir=$tmpdir)"
fakeroot -- chown 17171:0 $tmpfile   # offending command
rm $tmpfile
rmdir $tmpdir

I do not see a workaround in Lintian, so the bug should probably be
reassigned to 'nfs-utils'. The bugs over there did not strike me
immediately as related. (I have other bugs open and would be happy to
help.) Here are my mount and export details:

/etc/exports (on server):
/srv/nfs
*(rw,sync,no_subtree_check,no_root_squash,sec=krb5i:krb5p,fsid=0)
/srv/nfs/acct
*(rw,sync,no_subtree_check,no_root_squash,sec=krb5i:krb5p,mountpoint)

/etc/fstab (on client):
server:/acct /acct nfs4 rw,sec=krb5i,fsc 0 0

Perhaps it is relevant that 'root' on the client is allowed to use the
machine credentials:

/etc/idmapd (on server):
[Translation]
Method = nsswitch
GSS-Methods = static,nsswitch
[Static]
host/client.domain@domain.tld = root
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup


Also,

(client) Linux client.domain.tld 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1
(2018-07-20) x86_64 GNU/Linux
(server) Linux server.domain.tld 4.16.0-2-amd64 #1 SMP Debian
4.16.16-2 (2018-06-22) x86_64 GNU/Linux

and finally,

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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils   2.31.1-1
ii  bzip2  1.0.6-8.1
ii  diffstat   1.61-1+b1
ii  dpkg   1.19.0.5+b1
ii  file   1:5.33-3
ii  gettext0.19.8.1-6+b1
ii  intltool-debian0.35.0+20060710.4
ii  libapt-pkg-perl0.1.34
ii  libarchive-zip-perl1.60-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.39-1
ii  libdigest-sha-perl 6.02-1
ii  libdpkg-perl   1.19.0.5
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b3
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.74-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.72+repack-1
ii  man-db 2.8.3-2
ii  patchutils 0.3.4-2
ii  perl [libdigest-sha-perl]  5.26.2-6
ii  t1utils1.41-2
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-1
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.53-1

-- no debconf information

Thank you!


lintian-nfs-fakeroot-error.log.gz
Description: application/gzip


nfsv4-fakeroot-chown-test.sh.gz
Description: application/gzip

Bug#904707: fakeroot chown fails on kerberized NFSv4

[Felix Lechner]

Control: reassign 904707 nfs-utils 1:1.3.4-2.2

> I think your next step might be to try and create a minimal testcase
> outside of Lintian. If you can, then it should not be assigned here
> (naturally).

It's already isolated---maybe you did not see the script. Reassigned. Thank you!

Bug#519361: Patch

[Felix Lechner]

Control: tags 519361 patch

Hi,

This has been bothering me for years, as well. The attached patch
excludes backup files (*~). I don't have problems with emacs crashing,
but the second patch addresses those files (#*#) also, in 1.1.8-3.7.
As an alternative, Daniel's suggestion about a standard suffix is a
good one. Thank you!

Best regards,
Felix


exclude-emacs-backups.patch.gz
Description: application/gzip


exclude-emacs-backups-and-crashes.patch.gz
Description: application/gzip

Bug#905398: RFS: wolfssl/3.15.3+dfsg-2 [RC]

[Felix Lechner]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "wolfssl"

* Package name: wolfssl
  Version : 3.15.3+dfsg-2
  Upstream Author : wolfSSL, Inc.
* URL : https://www.wolfssl.com/products/wolfssl/
* License : GPL-2+ et al.
  Section : libs

It builds those binary packages:

 libwolfssl-dev - Development files for the wolfSSL encryption library
 libwolfssl18 - wolfSSL encryption library

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wolfssl/wolfssl_3.15.3+dfsg-2.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

* Ship wolfssl/control.h (Closes: #904711)
* Enabled TLS 1.3 (Closes: #904710)

Regards,
 Felix Lechner

Bug#904710: On Mentors

[Felix Lechner]

Hi, I am waiting for a sponsor to upload the fixed version. If you are
in a hurry, please build from Mentors
(https://mentors.debian.net/package/wolfssl). Thank you!

Bug#901825: [simple-scan] Change in page size not immediately effective

[Felix Lechner]

Package: simple-scan
Version: 3.26.2-1
Severity: normal

Hi, using a Fujitsu ScanSnap S510 on testing, changing the page size
from 'letter' to 'legal' is not effective until an image parameter
like brightness is changed (can be undone before scanning). Thank you!

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.16.0-2-amd64

Debian Release: buster/sid
  500 xenial  updates.signal.org
  500 unstablestorage.googleapis.com
  500 unstablepackages.us-core.com
  500 testing deb.debian.org
  500 stable  dl.bintray.com
  500 apt/stable  download.sublimetext.com

--- Package information. ---
Depends (Version) | Installed
=-+-=
default-dbus-session-bus  |
OR dbus-session-bus  |
xdg-utils | 1.1.3-1
dconf-gsettings-backend   | 0.28.0-2
OR gsettings-backend |
libc6   (>= 2.14) |
libcairo2 (>= 1.4.10) |
libcolord2(>= 0.1.10) |
libgdk-pixbuf2.0-0(>= 2.22.0) |
libglib2.0-0  (>= 2.37.3) |
libgtk-3-0(>= 3.16.2) |
libgusb2   (>= 0.2.2) |
libpackagekit-glib2-18 (>= 0.9.4) |
libsane   (>= 1.0.24) |
zlib1g   (>= 1:1.1.4) |


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#882730: RFS: wolfssl/3.12.2+dfsg-1 [requires NEW] -- wolfSSL encryption library

[Felix Lechner]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

  * Package name: wolfssl
Version : 3.12.2+dfsg-1
Upstream Author : wolfSSL Inc. 
  * URL : www.wolfssl.com
  * License : various
Section : libs

It builds these binary packages:

libwolfssl14 - wolfSSL encryption library
libwolfssl-dev - Development files for the wolfSSL encryption library

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wolfssl/
wolfssl_3.12.2+dfsg-1.dsc

More information about wolfSSL can be obtained from https://www.wolfssl.com.

  Changes since the last upload:

  * New upstream release
  * New major number 14
  * Updated symbols file
  * Updated watch file
  * Replaced upstream signing key with 0xEBC80E415CA29677
  * Updated Standard-Versions: to 4.1.1

Best regards,
Felix Lechner

Bug#883836: RFS: svxlink/15.11+20171207~git445-380e5333-1 [NEW trip required]

[Felix Lechner]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "svxlink"

 * Package name: svxlink
   Version : 15.11+20171207~git445-380e5333-1
   Upstream Author : Tobias Blomberg
 * URL : https://www.svxlink.org
 * License : GPL-2+, LGPL-2.1, WOL, Zlib, MIT, CC0-1.0
   Section : hamradio

It builds those binary packages:

 libasyncaudio-dev - AsyncAudio library for SvxLink (development files)
 libasyncaudio1.4 - AsyncAudio library for SvxLink
 libasynccore-dev - AsyncCore library for SvxLink (development files)
 libasynccore1.4 - AsyncCore library for SvxLink
 libasynccpp-dev - AsyncCpp library for SvxLink (development files)
 libasynccpp1.4 - AsyncCpp library for SvxLink
 libasyncqt-dev - AsyncQt library for SvxLink (development files)
 libasyncqt1.4 - AsyncQt library for SvxLink
 libecholib-dev - EchoLib library for SvxLink (development files)
 libecholib1.3 - EchoLib library for SvxLink
 qtel  - Graphical client for the EchoLink® protocol
 qtel-icons - Icons for graphical client for the EchoLink® protocol
 remotetrx  - Remote controller for radio transceivers
 svxlink-calibration-tools - Calibration tools for SvxLink amateur radio suite
 svxlink-gpio - GPIO control scripts SvxLink amateur radio server
 svxlink-server - Voice-over-IP server for ham radio operators
 svxreflector - Conference server for SvxLink amateur radio servers

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/svxlink/svxlink_15.11+20171207~git445-380e5333-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  * Pulled new upstream master
  * Bumped Standards-Version: 4.1.2
  * Updated maintainer email address
  * Removed Build-Depends: tcl-dev, qttools5-dev-tools
  * Changed Build-Depends: libgcrypt20-dev to libgcrypt-dev
  * Bumped library minor version in lintian-overrides
  * Placed shared libraries in Section: libs
  * Manually create icon directories in rules (for Raspbian Jessie)
  * Shipping svxreflector in new binary package
  * Shipping calibration tools in a separate binary package
  * Shipping GPIO auxiliaries in separate architecture independent package
  * Set make verbosity and install directories in rules instead of patch
  * Enabled systemd integration in rules
  * Switched to systemd scripts provided by upstream
  * Pulled systemd files for svxreflector from Richard Neese
  * Provided basic init.d file for svxreflector
  * Removed obsolete syslog.target from systemd service files
  * Added .gitignore file
  * Changed package descriptions
  * Moved CC0 license nearer the original icons
  * Updated copyright info

  Regards,
   Felix Lechner

Bug#884959: RFS: wolfssl/3.13.0+dfsg-1 [requires NEW, fixes CVE] -- wolfSSL encryption library

[Felix Lechner]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

  * Package name: wolfssl
Version : 3.13.0+dfsg-1
Upstream Author : wolfSSL Inc. 
  * URL : www.wolfssl.com
  * License : various
Section : libs

It builds these binary packages:

libwolfssl14 - wolfSSL encryption library
libwolfssl-dev - Development files for the wolfSSL encryption library

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wolfssl/wolfss
l_3.13.0+dfsg-1.dsc

More information about wolfSSL can be obtained from https://www.wolfssl.com.

  Changes since the last upload:

  * New upstream release
  * Fixes "robot attack" CVE-2017-13099 (Closes: #884235)
  * New major number 15
  * Set Standards-Version: 4.1.2
  * Improved clean target for repeated builds

Best regards,
Felix Lechner

Bug#885621: Watch could verify downloads when upstream key is present

[Felix Lechner]

Package: lintian
Version: 2.5.65
Severity: wishlist
Tags: patch

Hi,

The attached patch emits a new tag 'watch-could-verify-download' when an
upstream key and a watch file are present, but 'pgpsigurlmangle' is not
used.

Best regards,
Felix


0001-c-watch-file-watch-could-verify-downloads-when-upstr.patch.xz
Description: application/xz

Bug#886036: Improve changelog version parsing

[Felix Lechner]

Package: lintian
Version: 2.5.67
Severity: wishlist
Tags: patch

Hi,

The attached patch set improves the version parsing in changelog. The
patches are annotated, but I also copied brief descriptions below.

The patches apply to the 2.5.68 master—one after the other, and
ordered in likelihood of acceptance. Thank you!

Best regards,
Felix

0001:
c/changelog-file: Fix version parsing for hyphen in upstream version
This patch fixes an issue when the upstream version contains a hyphen.
While the presence of a hyphen may not be desirable, it is okay
according to policy. This patch is superseded by another more elegant
patch later in the series.

0002:
c/cruft: Fix version parsing for native packages
This patch improves version parsing for native packages. It removes an
outdated pattern for non-maintainer uploads. The patch is superseded
by another patch later in the series.

0003:
c/source-changelog: Add version parsing
This patch adds version parsing to checks/source-changelog, where it
may be more appropriate than in the various places it is presently.
The parsing employs a somewhat long but hopefully correct regular
expression.

0004:
c/cruft: Transfer native and non-native version checking to c/source-changelog
This patch transfers two checks for version strings from checks/cruft
to checks/source-changelog, where they may a better home. The original
author also thought they did not belong in their original place. That
deficiency is now cured.

0005:
c/source-changelog: Add version info to native and non-native tag output
This patch prints the offending version string when the tags
'native-package-with-dash-version' or
'non-native-package-with-native-version' are emitted. Perhaps it helps
the user.

0006:
c/source-changelog: Add tag for hyphens in upstream versions
This patch adds a new tag 'hyphen-in-upstream-version' to warn about
the legal but occasionally perilous presence of hyphens in version
strings. It was the original motivation behind this patch series. I
had accidentally uploaded a package with such a version and tried to
work on it with Debian tools for shared libraries (dpkg-gensymbols or
its KDE cousin). I would like to see such a warning in the future, if
possible.

0007:
c/source-changelog: Rename tag 'native-package-with-dash-version' to
'hyphen-in-native-version'
This patch renames the tag 'native-package-with-dash-version' to
'hyphen-in-native-version'. The tag is totally related to
'hyphen-in-upstream-version' and deserves a less crufty and perhaps
less cryptic name.

0008:
c/source-changelog: Rename tag
'non-native-package-with-native-version' to
'debian-changelog-missing-debian-revision'
This patch renames the tag 'non-native-package-with-native-version' to
'debian-changelog-missing-debian-revision'. It is an attempt to add
clarity and userfriendliness to the name.


 checks/changelog-file.pm |  8 +++---
 checks/cruft.desc| 35 
 checks/cruft.pm  | 14 --
 checks/source-changelog.desc | 46 
 checks/source-changelog.pm   | 38 ++
 t/tests/changelog-file-experimental/tags |  2 +-
 t/tests/changelog-file-general/desc  |  8 +-
 t/tests/changelog-file-general/tags  |  1 +
 t/tests/cruft-native-dash-version/desc   |  3 ++-
 t/tests/cruft-native-dash-version/tags   |  2 +-
 t/tests/cruft-non-native-version/desc|  3 ++-
 t/tests/cruft-non-native-version/tags|  2 +-
 t/tests/legacy-binary/desc   |  2 +-
 t/tests/legacy-binary/tags   |  2 +-
 t/tests/legacy-fields/desc   |  2 +-
 t/tests/legacy-fields/tags   |  2 +-
 t/tests/legacy-filenames/tags|  1 +
 t/tests/legacy-libbaz/desc   |  2 +-
 t/tests/legacy-libbaz/tags   |  2 +-
 t/tests/legacy-maintainer-scripts/tags   |  1 +
 20 files changed, 111 insertions(+), 65 deletions(-)

-- 
2.15.1


improve-changelog-version-parsing.tar.xz
Description: application/xz

Bug#886036: Improve changelog version parsing

[Felix Lechner]

Dear Chris,

On Mon, Jan 1, 2018 at 1:41 PM, Chris Lamb  wrote:
> (Could you push these to a Git repository somewhere? That would make
> them easier to apply... Thanks in advance!)

Please have a look at https://github.com/lechner/lintian. The repo
contains my locally synchronized copy of your master as well as my
branch 'improve-changelog-version-parsing'. Each commit passes all
tests and is perl-tidy.

Unfortunately, I annotated the patches manually in greater detail. You
may wish to consult them. The upshot is:

Many version checks happen on binary packages in
checks/changelog-file.pm, although they may be more helpful on source
packages. Per suggestion from Paul Wise, one could check that binary
packages ship with the source changelog. If the maintainers are
receptive to part of this patch series, the author would be happy help
consolidate further checks in checks/source-changelog. Thank you!

Best regards,
Felix

Bug#886036: Improve changelog version parsing

[Felix Lechner]

Hi Chris!

Here are two preliminary bug fixes:

* 0001 Addresses an issue when the version contains two hyphens; now
the string is split properly into two parts.
* 0002 Removes an old exception allowing -0.X on native source NMUs,
which now triggers the appropriate warning.

The patches were rebased for today's master. They are perl-tidy and
run on all tests.

Please don't close the bug just yet. Thank you!

Best regards,
Felix



On Tue, Jan 2, 2018 at 8:33 AM, Chris Lamb  wrote:
> Hi Felix!
>
>> Please have a look at https://github.com/lechner/lintian
>
> Woah, looks great! Thank you. Before I merge, can you just…
>
>   a) Add some tests for the debian-changelog-version-malformed
>  tag.
>
>   b) Add a changelog entry that closes this bug (#886036)
>
> Many thanks again...
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-


0001-c-changelog-file-Fix-version-parsing-for-hyphen-in-u.patch.xz
Description: application/xz


0002-c-cruft-Fix-version-parsing-for-native-packages.patch.xz
Description: application/xz

Bug#911355: False negative for 'multi-arch-same-package-has-arch-specific-overrides'

[Felix Lechner]

Package: lintian
Version: 2.5.109
Severity: minor
Tags: patch

Hi,

The Lintian test suite identified a potential false negative for the
tag 'multi-arch-same-package-has-arch-specific-overrides' when the
value of the Architecture: field in 'debian/control' does not match
the extension of the lintian-override file. Both fields could be
architecture wildcards. A positive finding should take place when the
latter is a subset of the former.

Attached please find a patch fixing the issue.

To reproduce, please manually change both package architectures in the
test 'fields-multi-arch-same-package-has-arch-specific-overrides' to
Architecture: any (in the file 'debian/debian/control.in'). The tag
'multi-arch-same-package-has-arch-specific-overrides' should
disappear.

To assist the developers, I will also file a merge request on salsa
with a commit message that references the assigned bug number. Thank
you!

Best regards,
Felix


fix-false-negative.patch.xz
Description: application/xz

Bug#911403: Please always include a copyright notice in 'LicenseWithSummary::summary_or_text'

[Felix Lechner]

Package: libsoftware-licensemoreutils-perl
Version: 1.002-1
Tags: patch
Control: block 905614 by -1

Hi,

The routine 'LicenseWithSummary::summary' produces only a license
summary, while 'Software::License::fulltext' produces a copyright
notice in addition to the full text. Please return a copyright notice
when producing a summary in 'LicenseWithSummary::summary_or_text' so
the output of the method becomes more symmetrical. Attached please
find a patch. Thank you!

Kind regards,
Felix Lechner

(from Software::License)

#pod =method fulltext
#pod
#pod This method returns the complete text of the license, preceded by
the copyright
#pod notice.
#pod
#pod =cut

sub fulltext {
  my ($self) = @_;
  return join "\n", $self->notice, $self->license;
}


include-copyright-notice-in-summary-or-text.patch.xz
Description: application/xz

Bug#905614: Patch

[Felix Lechner]

Tags: patch

Hi,

The test fails because sometimes
'Software::LicenseMoreUtils::LicenseWithSummary::summary_or_text'
includes a copyright notice already. I filed a bug there to include it
always. Therefore, the copyright notice is no longer needed here. The
attached patch removes it. Thank you!

Kind regards,
Felix Lechner


remove-duplicate-copyright-notice.patch.xz
Description: application/xz

Bug#911725: RFS: golang-github-pkg-xattr/0.3.1-1 [team upload]

[Felix Lechner]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org

Dear mentors,

I am looking for a sponsor to update the team-maintained package
"golang-github-pkg-xattr".

This version is a prerequisite for the latest version 1.6 of
'gocryptfs', which I co-maintain.

 * Package name: golang-github-pkg-xattr
   Version : 0.3.1-1
   Upstream Author : Kuba Podgórski & Dave Cheney
 * URL : https://github.com/pkg/xattr
 * License : BSD-2-clause
   Section : devel

  It builds those binary packages:

golang-github-pkg-xattr-dev - Extended attribute support for Go

  If you have access to Salsa, please have a look at:

https://salsa.debian.org/go-team/packages/golang-github-pkg-xattr

  Otherwise, please visit the following URL:

https://mentors.debian.net/package/golang-github-pkg-xattr

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-pkg-xattr/golang-github-pkg-xattr_0.3.1-1.dsc

  Thank you!

  Changes since the last upload:

[ Alexandre Viau ]
  * Point Vcs-* urls to salsa.debian.org.

  [ Felix Lechner ]
  * Team upload
  * New upstream version
  * Set Standards-Version: 4.2.1
  * Added Build-Depends: golang-golang-x-sys-dev
  * Added Testsuite: autopkgtest-pkg-go

  Regards,
   Felix Lechner

Bug#911726: RFS: golang-github-xanzy-go-gitlab/0.11.3-1

[Felix Lechner]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org

  Dear mentors,

  I am looking for a sponsor for my package "golang-github-xanzy-go-gitlab".

  The package is a prerequisite for my upcoming package 'git-lab' (#898246).

 * Package name: golang-github-xanzy-go-gitlab
   Version : 0.11.3-1
   Upstream Author : Sander Van Harmelen 
 * URL : https://github.com/xanzy/go-gitlab
 * License : Apache-2.0
   Section : devel

  It builds those binary packages:

golang-github-xanzy-go-gitlab-dev - Simple and uniform GitLab API for Go

  If you have access to Salsa, please check out:

https://salsa.debian.org/go-team/packages/golang-github-xanzy-go-gitlab

  Otherwise, please visit the following URL: (You can also find the
orig.tar.gz here.)

https://mentors.debian.net/package/golang-github-xanzy-go-gitlab


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-xanzy-go-gitlab/golang-github-xanzy-go-gitlab_0.11.3-1.dsc

  Changes since the last upload:

 * Initial release (Closes: #906986)


  Regards,
   Felix Lechner

Bug#911959: Subject: RFS: git-lab/0.14.0-1 [ITP]

[Felix Lechner]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org
Control: block -1 by 905240
Control: block -1 by 906986
Control: block -1 by 905262

  Dear mentors,

  I am looking for a sponsor for my package "git-lab"

  Some dependencies may still be the 'sponsorship-requests' queue, or
in NEW. Please check out the blocking bugs.

 * Package name: git-lab
   Version : 0.14.0-1
   Upstream Author : Zaq? Wiedmann 
 * URL : https://github.com/zaquestion/lab
 * License : Unlicense
   Section : devel

  It builds those binary packages:

git-lab- Clone, fork, and interact with repositories on GitLab

  If you have access to Salsa, please have a look at:

https://salsa.debian.org/go-team/packages/git-lab

Otherwise (and to get the orig.tar.gz), please visit the following URL:

https://mentors.debian.net/package/git-lab


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/git-lab/git-lab_0.14.0-1.dsc

  More information about git-lab can be obtained from https://www.example.com.

  Changes since the last upload:

  * Initial release (Closes: #898246)

  The package will be maintained as part of the Debian Go team going
forward. Thank you!

  Regards,
   Felix Lechner

Bug#922737: lintian rarely hangs

[Felix Lechner]

Hi Helmut,

I have also had this problem since December and hoped no one would
notice. Personally, I think it is related to Perl 5.28.1-3, but I am
not sure.

We also recently added a parallel collection that may have a race
condition. I will look at it in the coming days. Thank you for your
diligence in reporting this.

Kind regards,
Felix Lechner


On Tue, Feb 19, 2019 at 9:15 PM Helmut Grohne  wrote:
>
> Package: lintian
> Version: 2.6.0
> Severity: important
> User: helm...@debian.org
> Usertags: rebootstrap
>
> I use lintian to detect wrongly cross built packages. In this setup,
> lintian is run by sbuild inside the (unstable) schroot after the build.
> I pass "-T
> binary-from-other-architecture,triplet-dir-and-architecture-mismatch" to
> lintian and it all works fine ... most of the time.
>
> In roughly 1/2000 builds, lintian hangs. Now the bad part is that I have
> little details on what is going on here.
>
>  * A process list shows just "lintian" without any command line flags.
>  * lintian has a zombie chiled called "[rm]".
>  * lintian has the following file descriptors:
>+ 0 is /dev/null inherited from the sbuild invocation
>+ 1 and 2 are the same writable pipe (presumably to sbuild)
>+ 3 is /dev/null (inside the schroot) for writing
>+ 4 and 5 are the read and write ends of a pipe
>+ 6 is /usr/share/perl5/Net/DNS/Resolver/Base.pm inside the schroot
>  * It already happend with 2.6.0 and continues to happen with 2.7.0.
>  * Attaching the hanging lintian with strace only yields
>restart_syscall.
>
> Given the 1/2000 builds nature, it takes a while (days) to reproduce.
> I'll leave one such hanging process around for a while in case you have
> ideas on how to debug this.
>
> Helmut
>

Bug#922737: lintian rarely hangs

[Felix Lechner]

On Tue, Feb 19, 2019 at 9:15 PM Helmut Grohne  wrote:
>
> In roughly 1/2000 builds, lintian hangs.

I submitted a merge request in hope it will solve your issue:

https://salsa.debian.org/lintian/lintian/merge_requests/154

Bug#903399: Fix makes tag untestable

[Felix Lechner]

The fix for this bug makes the tag 'old-python-version-field'
untestable. When the version for old-python equals ancient-python,
there is no way to reach the second block:

if (versions_lte($v, $ancient)) {
tag 'ancient-python-version-field', $field, $v;
} elsif (versions_lte($v, $old)) {
tag 'old-python-version-field', $field, $v;

The tags cannot be combined. They have different severities. I can
fake a test that swaps an actual 'ancient' tag for an 'old' tag, but
it would be a last resort. The test suite has almost full tag
coverage. Can we please find another solution, so that this tag is
testable, too?

Bug#903399: Fix makes tag untestable

[Felix Lechner]

On Thu, Feb 21, 2019 at 11:51 AM Chris Lamb  wrote:
>
> Not sure how we can get around this. Have you implemented similar
> things for other tags...?

So far I have not faked a test, but sed will do a great job. Could the
Python minor number differ between the tags?

Bug#903399: Fix makes tag untestable

[Felix Lechner]

On Thu, Feb 21, 2019 at 11:51 AM Chris Lamb  wrote:
> Not sure how we can get around this. Have you implemented similar
> things for other tags...?

The best alternative would be for the test to read the the value from
data/python/versions when constructing the test package. That way the
test fails when the value is changed. We can then remove the sed
script. Perhaps the sed script could even check before running if the
versions are the same. Then the whole thing would be on autopilot.

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Felix Lechner]

Hi Daniel,

On Wed, Feb 27, 2019 at 12:03 PM Daniel Kahn Gillmor
 wrote:
>
> I guess if we wanted some version of lintian to be able to check on the
> git tag, we need to have some sort of export (git shallow
> something-or-other?) that could be included in debian/ to recreate a git
> repo that would be sufficient to verify the contents of the files and
> confirm the git signature.

I wrote a Debian tool to create a shipping manifest with file-based
hashes. Would it help to include that at the time of packaging? If the
manifest is signed, we could do away with tarball signatures.

Felix

Bug#923696: lintian: Bad examples in Lintian::Tutorial::TestSuite

[Felix Lechner]

Hi Xavier,

On Sun, Mar 3, 2019 at 2:27 PM Xavier Guimard  wrote:

>
> To launch part of the tests, Lintian::Tutorial::Testsuite proposes to
> use either:
>
>   $ debian/rules runtests onlyrun=tag:$tag
>   $ t/bin/runtests --dump-logs -k t debian/test-out tag:$tag
>
> None of these examples work (all test launched or error). Looking at
> source code, I ran with success:
>
>   $ t/bin/runtests --unattended --work-dir=debian/test-out --onlyrun
> tag:$tag t
>
> Same for other examples ($check,...)
>

Thanks for reporting this. I saw your note on #debian-qa, but you were gone
when I got there. I will work on the documentation very soon.

In most cases, you should be able to drop the work-dir and and the test
base 't', like so

t/bin/runtests --onlyrun=tag:$tag

-k will run all selected tests even if the code quality scripts or the
internal harness tests have failed.

--unattended will never prompt for user input, for example to offer to
re-calibrate tests when new tags appeared or some disappeared.

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Felix Lechner]

Hi Daniel,

On Fri, Mar 1, 2019 at 4:12 AM Daniel Kahn Gillmor 
wrote:
>
>
> I think what you're describing takes aim a different problem, so i don't
> think it addresses the underlying concern here.

I believe it solves your problem, just not the way you expect.

As you point out, the current approach of validating different upstream
signature formats is the point of this bug. You list two, but as you note
there could be more:

> At issue in #920763 is our attempt to capture verified *upstream*
> cryptographic signatures.  There are (at least) two common practices for
> such signatures by upstreams across the free software ecosystem:
>
>  a) detached signatures over tarballs
>  b) signed git tags

With source format 3.0 (git) that logic even found a way into the packaging
system. Let's flip it around for a moment: Why not validate upstream
signatures when the package is built?

My shipping manifest offers an "origin statement" to include git or tarball
signatures (even multiple) that tie the original source (in any format) to
the list of file hashes. Signed by a Debian maintainer, the manifest
provides a trust path.

To pick up on Chris's comment, the validation happens when our tools can be
reasonably expected to have network access (or the maintainer has a git
repo nearby).

> aiui, your tool is
> designed to something operated by the debian developer/maintainer.
>

That cannot be an obstacle. You just suggested it earlier in this thread:

I guess if we wanted some version of lintian to be able to check on the
> git tag, we need to have some sort of export (git shallow
> something-or-other?) that could be included in debian/ to recreate a git
> repo that would be sufficient to verify the contents of the files and
> confirm the git signature.
>

Yours were the very words that made me believe I could help. :)

A signed manifest is less complex, more universal, and would likely take up
less space.

As an aside, maintainer involvement is always required when repacking for
DFSG-compliance. A manifest with an origin statement would handle that case
with ease.

> Today, we have pretty decent tooling to handle (a).  we even distribute>
upstream tarball signatures directly when we have them:
> (e.g.
https://mirrors.edge.kernel.org/debian/pool/main/k/knot/knot_2.6.8.orig.tar.xz
> can be verified against the upstream signer's key by fetching
>
https://mirrors.edge.kernel.org/debian/pool/main/k/knot/knot_2.6.8.orig.tar.xz.asc
)
>
> So for (a), we're effectively assembling an archive of all of the
> upstream signatures that we know about, which could be used later for
> verifying provenance of the source code used.
>
> What we don't have is tooling to handle or aggregate such a verifiable
> archive for those upstream signatures that fall under (b).  Do you think
> the tool you're describing would help with that?

I believe my tool covers a) and b) as well as any other past, current, or
future authentication method for upstream sources.

As a side note, the signed manifest could even be the sole item uploaded
for a new version if it also includes a list of URLs where the sources may
be found. Right now, I call it the Light Upload Format.

Kind regards,
Felix

Bug#926334: lintian: Does the SafeSEH check make sense for Mono/.NET DLLs?

[Felix Lechner]

Control: tags 926334 moreinfo

On Wed, Apr 3, 2019 at 9:30 AM Hilko Bengen  wrote:
>
> In this
> context, looking for the x86-specific SafeSEH feature does not make much
> sense, does it?

I do not know enough about Mono to say whether your DLLs are
vulnerable to manipulation of the Structured Exception Handler. Why
don't you just override the tag if you are sure?

Bug#926409: lintian: autopkgtest takes very long to finish

[Felix Lechner]

On Thu, Apr 4, 2019 at 10:42 AM Chris Lamb  wrote:
>
>  * I'm not sure *how* we can speed up the tests. I mean, they all
>essentially involve building Debian packages with all the usual
>debhelper calls, etc. Speeding *this* up is somewhat out-of-scope
>of this Lintian wishlist issue, alas.
>
> However, perhaps Felix has some input here as he has been doing a lot
> of work on the test suite recently?

About 95% of the time is spent building packages, even though they
almost never change. The tests would run much faster if we shipped
pre-built packages. One way to accomplish that would be to package the
tests separately.

Bug#926409: lintian: autopkgtest takes very long to finish

[Felix Lechner]

On Thu, Apr 4, 2019 at 11:24 AM Balint Reczey
 wrote:
>
> One criterion that came to my mind is filtering by severity, including
> errors for sure, but not pedantic ones.

The pedantic setting may become the default for tests, but very little
time is spent running Lintian.

Things may speed up a little if we run only the checks being tested
(using the '-C' option), but that won't make much of a difference in
the overall run time of the tests, which is primarily spent building packages.

Bug#926409: lintian: autopkgtest takes very long to finish

[Felix Lechner]

On Thu, Apr 4, 2019 at 12:19 PM Chris Lamb  wrote:

>
> Felix Lechner wrote:
>
> > About 95% of the time is spent building packages, even though they
> > almost never change. The tests would run much faster if we shipped
> > pre-built packages.
>
> Another way to accomplish this could be that we could cache/store them
> across autopkgtest runs? IIRC (at least) Gitlab supports caching stuff
> like this.
>

Upon reflection, each test should be packaged separately. That way I no
longer have to worry about using chroot to build tests with potentially
conflicting build dependencies.

Bug#926823: executable-not-elf-or-script should consider PE binaries

[Felix Lechner]

On Wed, Apr 10, 2019 at 2:33 PM Michael Biebl  wrote:
>
> systemd ships EFI binaries which are PE executables.
>
> usr/lib/systemd/boot/efi/linuxia32.efi.stub [amd64, i386]
> usr/lib/systemd/boot/efi/linuxx64.efi.stub [amd64, i386]
> usr/lib/systemd/boot/efi/systemd-bootia32.efi [amd64, i386]
> usr/lib/systemd/boot/efi/systemd-bootx64.efi [amd64, i386]
>
> I wonder whether executable-not-elf-or-script should be made aware of PE
> executables and not warn about them.

Does systemd-boot require the executable bits to be set on these files?

Bug#926823: executable-not-elf-or-script should consider PE binaries

[Felix Lechner]

On Wed, Apr 10, 2019 at 4:16 PM Michael Biebl  wrote:
>
> Those bits are set by ld respectively objcopy when the binaries are
> generated. Are you implying that ld/objcopy should not do that?

No, you may well need it. It's just that the lintian tag is not
triggered when the bit is off.

Bug#978636: move to merged-usr-only?

[Felix Lechner]

Hi,

On Tue, Jan 26, 2021 at 3:45 AM Wouter Verhelst  wrote:
>
> You can start writing a lintian check today

Here is a Lintian check that follows Ansgar's specification in the
second d-d thead. Of course, it will not be merged until the project
works out a suitable consensus on this controversial topic:

https://salsa.debian.org/lintian/lintian/-/merge_requests/349

Thank you!

Kind regards
Felix Lechner

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Felix Lechner]

Hi,

On Tue, Jan 26, 2021 at 5:48 PM Sandro Tosi  wrote:
>
> the ability to talk privately with the committee is something CTTE has
> allowed for a long time

Debian has many great traditions, but the Magna Carta is much older. I
found a great article about it ([1], p. 5):

"the simple human need for fairness, reflected in western
jurisprudence since at least 1215 when it was pronounced in the Magna
Carta, underlies the legal concerns about ex parte communications
during administrative decisionmaking processes. Fairness certainly
requires an impartial decisionmaker, and often the appearance of
impartiality can become as important a factor in the legal review of
fairness as actual impartiality."

The State of Hawai'i publishes a simpler guidance prohibiting private
communications with a judge. [2]

Kind regards
Felix Lechner

[1] 
https://www.cacities.org/Resources-Documents/Member-Engagement/Professional-Departments/City-Attorneys/Library/2016/Annual-2016/10-2016-Annual_Calonne_Lets-Ex-Parte!-The-Limits-a.aspx
[2] https://www.courts.state.hi.us/self-help/exparte/ex_parte_contact

Bug#980862: lintian: Add detection of typo in d/control: not a dot separating description lines

[Felix Lechner]

Hi Vasyl,

On Sat, Jan 23, 2021 at 2:54 AM Vasyl Gello  wrote:
>
> regexp like '/^[ ]*[,:+%&-]*$/'

My preference would be to warn on any single character in second
position (no asterisk) but without special mention of i10n.

/^ [ ] . $/sx

I believe that the formatting error described in Bug#980853 relates
primarily to the extended, dot-separated text format in Deb822 files,
and not necessarily to i10n (translations are not a concern in
d/copyright). Would that be acceptable?

Kind regards
Felix Lechner