Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script

[Raphael Hertzog]

Package: kitty
Version: 0.26.5-4
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hello,

I was reading https://lists.debian.org/20230425190728.ga1471...@subdivi.de
in mutt and that mail contains 3 shell scripts as attachments
(application/x-sh). I wanted to have a look at the scripts and thus I
"opened" those attachments... that open operation has been handled by
Kitty due its MimeType declaration in
/usr/share/applications/kitty-open.desktop [1] and the shell script has
thus been fed to "kitty +open 

Bug#1020056:

[Raphael Hertzog]

Hello,

Le jeudi 13 octobre 2022, Thomas Braun a écrit :
> so I think it should be as easy as adding cppzmq-dev to the build
> dependencies.
> 
>  $diff -Nur control control.new
> --- control 2022-10-13 16:19:07.384578078 +0200
> +++ control.new 2022-10-13 16:19:03.972578004 +0200
> @@ -7,6 +7,7 @@
> default-libmysqlclient-dev,
> libcos4-dev,
> libzmq5-dev | libzmq3-dev,
> +   cppzmq-dev,
> omniidl,
> po-debconf
>  Build-Depends-Indep: doxygen,

FWIW, there's also a related MR here:
https://salsa.debian.org/science-team/tango/-/merge_requests/3

That MR replaces the "libzmq5-dev | libzmq3-dev" build dep with
cppzmq-dev. But the CI in the MR failed, though it seems to be for
unrelated reasons.

Adrian, I see you tagged this bug as pending. Why? I don't see any
fix pushed to git yet.

Cheers,
-- 
Raphaël Hertzog

Bug#1016090: python-django breaks lots of autopkgtests

[Raphael Hertzog]

Hi,

On Mon, 01 Aug 2022, Chris Lamb wrote:
> Regardless of that though, I think we have two options:
> 
> a) Revert back to the 3.2.14 LTS version in Debian unstable.
> 
> b) Wait for the 4.x stream to become designated LTS. I believe this
>should happen with version 4.2, due for release in about 6 or 7
>months:

The Django and Debian releases are not well aligned. The 4.2 release
is planned in April 2023 so a bit late given the freeze. If the number of
reverse dependencies was lower, it could argued to try to have some sort
of exceptions and offering extra work to help fix/migrate the reverse
dependencies.

But unfortunately I assume that most of the important reverse dependencies
track mainly the LTS releases and the upstream fixes for 4.x compatibility
will only materialize once Django 4.2 is released and we would have to
commit to too much work to be able to push Django 4.x (including 4.2~rc1
or similar) in bookworn.

As such, as much as I hate it, I think than only (a) is realistic.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1016090: python-django breaks lots of autopkgtests

[Raphael Hertzog]

On Tue, 26 Jul 2022, Paul Gevers wrote:
> Source: python-django
> Control: found -1 python-django/2:4.0.6-1

I'm surprised that we uploaded an non-LTS release to unstable.

Chris, why did you do that? 

> I note that the changelog has this:
> "This security release mitigates the issue, but we have identified
> improvements to the Database API methods related to date extract and
> truncate that would be beneficial to add to Django 4.1 before it's final
> release. This will impact 3rd party database backends using Django 4.1
> release candidate 1 or newer, until they are able to update to the API
> changes. We apologize for the inconvenience."
> 
> I guess that means that these breakages might be intentional, but even if
> all this is to be expected, it would be good to add a *versioned* Breaks to
> python-django3 for all the packages that it really breaks (not just the
> autopkgtest).

I don't think that the above changelog entry is relevant. The issue is
broader, it's more likely that we moved from 3.2 to 4.0 and that many
packages have not been prepared for that switch.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#1013493: python-django-jsonfield: FTBFS: ImportError: cannot import name 'ugettext_lazy' from 'django.utils.translation' (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)

[Raphael Hertzog]

Hello,

On Fri, 24 Jun 2022, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks but I will not fix this bug. Intsead I have asked to remove
this package from unstable since it has been superseded by a native
field provided by Django:
https://docs.djangoproject.com/en/3.2/ref/models/fields/#jsonfield

Removal bug: https://bugs.debian.org/1016370

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

[Raphael Hertzog]

Control: tags -1 + patch
Control: user de...@kali.org
Control: usertags -1 + kali-patch

On Sun, 17 Jul 2022 05:50:20 +0200 Cyril Brulebois  wrote:
> I suppose the journal bits could be patched out for the udeb build (right
> now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
> I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
> could have for arrays built at installation time (the function call itself
> is already guarded within an #ifdef/#endif block, so it seems somewhat
> optional already).

I confirm that a build with this patch gets rid of the libsystemd0
dependency in the udeb:

diff --git a/debian/rules b/debian/rules
index f1a9df9bd..bef9b2df3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -71,6 +71,8 @@ define CONFARGS.udeb
--with-pool=none
--disable-readline
--disable-selinux
+   --disable-app-machineid
+   --disable-systemd-journal
 endef
 
 BUILDS :=

I looked up the impact of --disable-app-machineid and I concluded that it
should be safe to use it even if the non-udeb build has it enabled.

The option only adds a supplementary source (named "appmachineid") for lvm
to get a "system_id". The DEFAULT_SYSTEM_ID_SOURCE is "none" and it's not
overriden by what we ship as Debian configuration files. Given that it was
non-existent up-to-now, we can be pretty sure that d-i is not overriding
the lvm configuration to set global/system_id_source to "appmachineid".

man lvmsystemid has some explanation about the feature related to
"systemid" and from a quick check on my system, it looks like that
VG created by d-i do not set any system id.

Bastian, do you agree with the above assessment? If yes, can you upload
a fixed package please?

Cheers,
-- 
Raphaël Hertzog

Bug#997522: logidee-tools: FTBFS: make[2]: kpsepath: No such file or directory

[Raphael Hertzog]

Control: tag -1 + wontfix

On Sat, 23 Oct 2021, Lucas Nussbaum wrote:
> Source: logidee-tools
> Version: 1.2.19
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Note that I requested removal of this package so I will not handle this
bug. See https://bugs.debian.org/996776

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#995445: logidee-tools: creates incorrect TeX code, breaks other packages via autopkgtests

[Raphael Hertzog]

Hello,

On Fri, 01 Oct 2021, Norbert Preining wrote:
> The failed autopkgtest can be boiled down to the following example (all
> the code is as taken from the logidee-tools generated code):

Sorry that logidee-tools created issues for you. For the record, I have
just requested the removal of that package since I'm no longer using
it and in fact nobody else is using it either.

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

Hopefully the package will be removed soon.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#993204: Bug#996079: gnome-shell-timer: does not declare compatibility with GNOME Shell 41

[Raphael Hertzog]

Control: forcemerge 993204 996079

Le dimanche 10 octobre 2021, Simon McVittie a écrit :
> Package: gnome-shell-timer
> 
> The metadata.json for this extension doesn't declare compatibility with
> GNOME 41. I don't know whether the actual code will need changes or not:
> the conservative assumption is that it probably will (so please test).
> gnome-shell 41 should be available in experimental soon.

FWIW, you had already filed #993204 for the same issue (but for GNOME 40).
In any case, I have just filed a RM request to get this package removed
from Debian.

(I'm saying that so that nobody invest time into those RC bugs)

Cheers,
-- 
Raphaël Hertzog

Bug#970809: python3-venv is gone

[Raphael Hertzog]

Hi,

the package has been dropped from testing a while ago due to this bug
but it's not clear to me that there's a real bug here.

On Wed, 23 Sep 2020, Matthias Klose wrote:
> Package: pipx
> Version: 0.12.3.1-3
> Severity: serious
> Tags: sid bullseye
> 
> This package depends or build-depends on python3-venv, which is gone upstream.
> Please remove or re-implement that usage.

Can you be more verbose and back up this assertion with something
concrete?

What is gone exactly?

I still see the "venv" module in python3.9-stdlib. The reason why
python3-venv has been added in the Depends is because "ensurepip" was
required for the "python3 -m venv" to actually work.

See https://bugs.debian.org/954939

How is that wrong?

Cheers,

PS: Jonas, the package could use some love anyway, it's behind several
upstream releases.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#977354: libmagics++-dev: Invalid dependency on "i" package

[Raphael Hertzog]

Package: libmagics++-dev
Version: 4.5.2-1
Severity: grave
Justification: renders package unusable

I was alerted by a strange log in the package tracker:
/usr/lib/python3/dist-packages/debian/deb822.py:1403: UserWarning: cannot parse 
package
relationship "i", returning it raw

I looked up what package would depend on "i" and I found libmagics++-dev:

$ apt show libmagics++-dev
Package: libmagics++-dev
Version: 4.5.2-1
Priority: optional
Section: libdevel
Source: magics++
Maintainer: Alastair McKinstry 
Installed-Size: 587 kB
Depends: libmagplus3v5 (= 4.5.2-1), i, python3, libmagics++-metview-dev, 
libterralib-dev, magics++, libodc-dev
[...]

Obviously that package doesn't exist and is not installable so your package
can't migrate.

Please upload a fixed package ASAP as it generates annoying noise
every 6 hours in my INBOX ;-)

Cheers,

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#976633: gnome-shell-extension-hamster: crash: TypeError: this.panelWidget is null

[Raphael Hertzog]

Control: severity -1 important
Control: tag -1 + unreproducible

On Sun, 06 Dec 2020, Paul Wise wrote:
> On Sun, 2020-12-06 at 10:49 +0100, Raphael Hertzog wrote:
> 
> > Duh, I am using it with GNOME Shell 3.38 but I have 3.38.1-2+b1 right
> > now and it's what I used to test it before upload.
> 
> Yeah, I'm using 3.38.2-1 as I needed to upgrade to test something else.

I just upgraded to 3.38.2, restarted gnome-shell and the extension was
still here, no error message in the logs. I then disabled it with Tweaks
and reenabled it in the same way. It worked fine.

Maybe there's a bad interaction with another extension?

On my side I have "gnome-shell-extension-timer" and "ubuntu-appindicators"
and "system-monitor" among the non-standard extensions.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#976633: gnome-shell-extension-hamster: crash: TypeError: this.panelWidget is null

[Raphael Hertzog]

Hi,

On Sun, 06 Dec 2020, Paul Wise wrote:
> When I try to load the Hamster extension, GNOME shell from unstable
> prints the following traceback into the systemd user journal, I guess
> it isn't compatible with GNOME shell 3.38 at this point in time.

Duh, I am using it with GNOME Shell 3.38 but I have 3.38.1-2+b1 right now
and it's what I used to test it before upload.

>JS ERROR: Extension cont...@projecthamster.org: TypeError: 
> this.panelWidget is null
>
> _removeWidget@/usr/share/gnome-shell/extensions/cont...@projecthamster.org/extension.js:262:13
>
> disable@/usr/share/gnome-shell/extensions/cont...@projecthamster.org/extension.js:195:14
>
> _callExtensionDisable@resource:///org/gnome/shell/ui/extensionSystem.js:108:32
>
> _disableAllExtensions/<@resource:///org/gnome/shell/ui/extensionSystem.js:611:22
>
> _disableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:610:52

It's also weird that we have calls to "disable" and "removeWidget" when
you try to load the hamster extension... do you have this when you enable
the extension or rather when you lock the system after having enabled the
extension ?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#975519: scapy fails autopkg test, blocking python3-defaults

[Raphael Hertzog]

Hi,

On Mon, 23 Nov 2020, Matthias Klose wrote:
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/scapy/8359116/log.gz
> 
> [...]
>   File "", line 25
> 
> ^
> SyntaxError: expression cannot contain assignment, perhaps you meant "=="?

I see the following commit upstream:
https://github.com/secdev/scapy/commit/fba21efcddb7fbb94c24befa18edf82c6c791e69

I have cherry-picked it, hopefully it will be sufficient.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#930908: Letting mailcap and mime-support migrate

[Raphael Hertzog]

Control: severity -1 important

I'm reducing the severity of this bug because this forbids
mailcap and mime-support to migrate to testing and they have to
migrate because the current mime-support is uninstallable in
a freshly installed testing system because media-types
(installed by default due to its standard priority) has a Breaks against
the version of mime-support in testing.

I'm not sure why britney allowed media-types to migrate but
the fact is that we have a broken testing for anyone who runs
d-i on testing.

And while this bug is assigned against mailcap, the issue already exists
in testing where /etc/mailcap is likely handled by mime-support instead
of mailcap. So letting the package migrate does not allow any regression.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#972858: zim FTBFS: FileNotFoundError: [Errno 2] No such file or directory: '/run/user/2952'

[Raphael Hertzog]

FWIW, this is really a bug in the build daemon that should not
set XDG_RUNTIME_DIR to some incorrect value:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842565

But I'll work around it in the mean time.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#972500: hamster-time-tracker does not launch on Buster using the backported package

[Raphael Hertzog]

Hi,

Philipp, you uploaded the backport. Can you have a look at this report?

Ulrike, did you restart your computer after the upgrade just to make sure
that the dbus service was properly using the new code ?

Thank you in advance.

On Mon, 19 Oct 2020, Ulrike Uhlig wrote:
> Package: hamster-time-tracker
> Version: 3.0.2-3~bpo10+1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where
> appropriate ***
> 
>* What led up to the situation?
> 
> I'm trying to start hamster-time-tracker. I have used the program for
> many years (as hamster-applet) and upgraded to the transitional package.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Trying to start the program is ineffective.
> Trying to reinstall the program did not solve the issue.
> 
>* What was the outcome of this action?
> $ hamster
> Traceback (most recent call last):
>   File "/usr/bin/hamster", line 149, in on_activate_window
> self._open_window(action.get_name(), data)
>   File "/usr/bin/hamster", line 184, in _open_window
> self.overview_controller = Overview()
>   File "/usr/lib/python3/dist-packages/hamster/overview.py", line 477, in
> __init__
> self.find_facts()
>   File "/usr/lib/python3/dist-packages/hamster/overview.py", line 531, in
> find_facts
> self.facts = self.storage.get_facts(start, end, search_terms=search)
>   File "/usr/lib/python3/dist-packages/hamster/client.py", line 156, in
> get_facts
> for fact in self.conn.GetFactsJSON(dbus_range, search_terms)]
>   File "/usr/lib/python3/dist-packages/hamster/client.py", line 99, in conn
> server_version = self._connection.Version()
>   File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 70, in
> __call__
> return self._proxy_method(*args, **keywords)
>   File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in
> __call__
> **keywords)
>   File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 654, in
> _message_cb
> (candidate_method, parent_method) = _method_lookup(self, method_name,
> interface_name)
>   File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 246, in
> _method_lookup
> raise UnknownMethodException('%s is not a valid method of interface
> %s' %
> (method_name, dbus_interface))
> UnknownMethodException: org.freedesktop.DBus.Error.UnknownMethod: Unknown
> method: Version is not a valid method of interface org.gnome.Hamster
> 
> Traceback (most recent call last):
>   File "/usr/bin/hamster", line 149, in on_activate_window
> self._open_window(action.get_name(), data)
>   File "/usr/bin/hamster", line 184, in _open_window
> self.overview_controller = Overview()
>   File "/usr/lib/python3/dist-packages/hamster/overview.py", line 477, in
> __init__
> self.find_facts()
>   File "/usr/lib/python3/dist-packages/hamster/overview.py", line 531, in
> find_facts
> self.facts = self.storage.get_facts(start, end, search_terms=search)
>   File "/usr/lib/python3/dist-packages/hamster/client.py", line 156, in
> get_facts
> for fact in self.conn.GetFactsJSON(dbus_range, search_terms)]
>   File "/usr/lib/python3/dist-packages/hamster/client.py", line 99, in conn
> server_version = self._connection.Version()
>   File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 70, in
> __call__
> return self._proxy_method(*args, **keywords)
>   File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in
> __call__
> **keywords)
>   File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 654, in
> _message_cb
> (candidate_method, parent_method) = _method_lookup(self, method_name,
> interface_name)
>   File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 246, in
> _method_lookup
> raise UnknownMethodException('%s is not a valid method of interface
> %s' %
> (method_name, dbus_interface))
> UnknownMethodException: org.freedesktop.DBus.Error.UnknownMethod: Unknown
> method: Version is not a valid method of interface org.gnome.Hamster
> 
>* What outcome did you expect instead?
> 
> Package should work. Reinstalling should install, or propose missing
> libraries,
> or software if any.
> 
> *** End of the template - remove these template lines ***
> 
> 
> 
> -- System Information:
> Debian Release: 10.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-11-amd64 (SMP w/4 CPU cores)

Bug#964399: Should ganglia be removed?

[Raphael Hertzog]

Hi,

On Tue, 07 Jul 2020, Marcos Fouces wrote:
> I also done some work on ganglia-web and ganglia-linux-modules packages
> (also unpublished).
> 
> I believe that it is still a good piece of software that deserve its
> place on Debian so i would like to step up as uploader (co-uploaders
> welcome!) if needed.
> 
> I also would like to maintain it under pkg-security team umbrella.

Why pkg-security? It doesn't seem related to the team's purpose.

I can create you repositories in the "debian" namespace if you want but
I'd rather not add random packages to the pkg-security team...

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

[Raphael Hertzog]

Hi,

On Thu, 18 Jun 2020, Raphael Hertzog wrote:
> Actually your fix does not work because pkg_resources is not documented in
> setup.py or requirements.txt and thus it will not magically appear in
> ${python3:Depends} just by adding it in Build-Depends.
> 
> I opened https://github.com/SecureAuthCorp/impacket/issues/885 upstream to
> get this fixed but in the meantime we have to hardcode the dependency in
> Depends. I'll do that for now.

Actually, I'm not sure that anything needs to happen at the upstream
level... pkg_resources is part of setuptools, we have packaged it
separately but I believe that there's no way for us to track its usage
based on upstream dependencies so we must always manually add such a
depency (this really smells like a big deficiency in our packaging tools).

Am I correct?

Should upstream list setuptools in their requirements.txt or setup.py
because they use "pkg_resources"?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

[Raphael Hertzog]

On Wed, 17 Jun 2020, Emmanuel Arias wrote:
> I've just pushed to salsa the fix, could anyone review it and sponsor
> it, please?

Actually your fix does not work because pkg_resources is not documented in
setup.py or requirements.txt and thus it will not magically appear in
${python3:Depends} just by adding it in Build-Depends.

I opened https://github.com/SecureAuthCorp/impacket/issues/885 upstream to
get this fixed but in the meantime we have to hardcode the dependency in
Depends. I'll do that for now.

Cheers,
> El mié., 17 de jun. de 2020 a la(s) 19:18, Emmanuel Arias
> (emmanuelaria...@gmail.com) escribió:
> >
> > Hi,
> >
> > I will fix it today
> >
> > Cheers,
> > Arias Emmanuel
> > @eamanu
> > http://eamanu.com
> >
> > El mié., 17 de jun. de 2020 a la(s) 19:18, Scott Kitterman
> > (deb...@kitterman.com) escribió:
> > >
> > > On Wed, 17 Jun 2020 21:12:40 +0200 Paul Gevers  wrote:
> > > > Source: impacket, smbmap
> > > > Control: found -1 impacket/0.9.21-1
> > > > Control: found -1 smbmap/1.8.2-1
> > > > Severity: serious
> > > > Tags: sid bullseye
> > > > X-Debbugs-CC: debian...@lists.debian.org
> > > > User: debian...@lists.debian.org
> > > > Usertags: breaks needs-update
> > > >
> > > > Dear maintainer(s),
> > > >
> > > > With a recent upload of impacket the autopkgtest of smbmap fails in
> > > > testing when that autopkgtest is run with the binary packages of
> > > > impacket from unstable. It passes when run with only packages from
> > > > testing. In tabular form:
> > > >
> > > >passfail
> > > > impacket   from testing0.9.21-1
> > > > smbmap from testing1.8.2-1
> > > > all others from testingfrom testing
> > > >
> > > > I copied some of the output at the bottom of this report. Is the latest
> > > > impacket missing a dependency or is the version function not supported
> > > > anymore?
> > > >
> > > > Currently this regression is blocking the migration of impacket to
> > > > testing [1]. Due to the nature of this issue, I filed this bug report
> > > > against both packages. Can you please investigate the situation and
> > > > reassign the bug to the right package?
> > > >
> > > > More information about this bug and the reason for filing it can be 
> > > > found on
> > > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> > > >
> > > > Paul
> > > >
> > > > [1] https://qa.debian.org/excuses.php?package=impacket
> > > >
> > > > https://ci.debian.net/data/autopkgtest/testing/amd64/s/smbmap/5914948/log.gz
> > > >
> > > > autopkgtest [07:08:34]: test command1: smbmap -h
> > > > autopkgtest [07:08:34]: test command1: [---
> > > > Traceback (most recent call last):
> > > >   File "/usr/bin/smbmap", line 19, in 
> > > > from impacket import version, smbserver
> > > >   File "/usr/lib/python3/dist-packages/impacket/version.py", line 7, in
> > > > 
> > > > import pkg_resources
> > > > ModuleNotFoundError: No module named 'pkg_resources'
> > > > autopkgtest [07:08:35]: test command1: ---]
> > > >
> > > Looks like a missing depends on python3-pkg-resources for impacket since
> > > that's where it's imported.
> > >
> > > Scott K
> 

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

[Raphael Hertzog]

Hi,

On Wed, 17 Jun 2020, Emmanuel Arias wrote:
> I've just pushed to salsa the fix, could anyone review it and sponsor
> it, please?

I'll take care of it right now.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#938438: scap-security-guide: Python2 removal in sid/bullseye

[Raphael Hertzog]

Hi,

On Fri, 08 May 2020, Jeremy Bicha wrote:
> Maintainers, please indicate whether you are working on a fix or else
> this package will be removed from Debian Unstable soon. (You can
> always reintroduce the package if you remove the Python2
> dependencies.)

I just looked at the upstream source code and it seems to support Python 3
since quite a while.

https://github.com/ComplianceAsCode/content

Philippe, can you take care to prepare an update and get rid of Python 2?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#936206: binplist: Python2 removal in sid/bullseye

[Raphael Hertzog]

Hi,

On Fri, 08 May 2020, Moritz Mühlenhoff wrote:
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
> 
> https://github.com/google/binplist/issues/6 is without any update since 2016 
> and there
> are no reverse deps, let's remove?

No objection from me.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#955474: FTBFS: fatal error: stropts.h: No such file or directory

[Raphael Hertzog]

Control: retitle 954582 FTBFS: fatal error: stropts.h: No such file or directory
Control: forcemerge 954582 -1

I was mislead by the title of the other RC bug, it looks like both are
reporting the same underlying issue.

The proper solution seems to be to rebuild python 3.8 against glibc 2.30
and I just requested this in #955478.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#944553: midori deletes my files

[Raphael Hertzog]

Control: severity -1 important

On Tue, 18 Feb 2020, Sergio Durigan Junior wrote:
> Thanks for the report.
> 
> It's not clear from your description whether tmpa_crtoef.htm is the
> only file that triggers this behaviour, or if this happens with any file
> when you try opening it with Midori.
> 
> I gave it a quick try with a simple file here and could not reproduce
> the issue:

Given this and the lack of upstream answer I'm downgrading this bug to
important because midori has been removed from testing due to this
unreproducible issue!

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#951120: hydra: Non-free licence exception

[Raphael Hertzog]

Control: forwarded -1 https://github.com/vanhauser-thc/thc-hydra/issues/497

On Tue, 11 Feb 2020, Dominik George wrote:
> The licence of hydra states:

Actually the LICENSE file does not contain that sentence. It's only in the
README and it has been added 3 years ago

> The additional exception to the AGPL contradicts the Debian Free Software
> Guidelines.

Indeed.

> I propose moving hydra to non-free.

I'd rather convince upstream to fix this. I opened a ticket here:
https://github.com/vanhauser-thc/thc-hydra/issues/497

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#939260: Ready for Python 3

[Raphael Hertzog]

FTR, upstream just notified me that the latest version available on GitHub
is now ready for Python 3:
https://github.com/websploit/websploit

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#948257: Bug#948350: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '[...]/lib/modules/[kernelversion]/modules.builtin.bin'

[Raphael Hertzog]

Hello,

On Tue, 07 Jan 2020, Marco d'Itri wrote:
> #948257

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#105, Ben is
wondering whether the fix should not be done in kmod since the ERROR
displayed is due to a Debian-specific patch that you applied
(debian/patches/verbose_missing_bin):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#95

Can you please take position and explain why you think this should be
fixed in initramfs-tools when the message is not even displayed
in upstream's kmod ?

The message also seems to appear during a manual kernel build and install:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#110

Given all this, it seems cleaner to drop the patch
debian/patches/verbose_missing_bin that you applied.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#939260: websploit: Python2 removal in sid/bullseye

[Raphael Hertzog]

On Mon, 16 Dec 2019 14:28:33 +0100 Raphael Hertzog  wrote:
> Great. Looking forward to it. Do you have any idea how much time you need
> to complete this Python 3 port of websploit?

On the 21th, I got a private reply saying that he might need 20 days
to complete the Python 3 port.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#947387: [Python-modules-team] Bug#947387: python3-pcapy: missing Breaks+Replaces: python-pcapy

[Raphael Hertzog]

On Wed, 25 Dec 2019, Emmanuel Arias wrote:
> Raphaël, please could you review my patch?

Reviewed and uploaded.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#945723: Upstream progress on python 3 port

[Raphael Hertzog]

Hello,

upstream seems to be close to release a Python 3 version, current
WIP is in https://github.com/epinna/weevely3/tree/Debian-master
according to https://github.com/epinna/weevely3/pull/119#issuecomment-568770367

Sending this mail to reset the auto-rm clock, hoping that Samuel will
upload a fixed version once this is ready at the upstream level.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#939260: websploit: Python2 removal in sid/bullseye

[Raphael Hertzog]

Hello,

On Tue, 10 Dec 2019, 0X0Ptim0Us wrote:
> Got it, thank you. I will work on it

Great. Looking forward to it. Do you have any idea how much time you need
to complete this Python 3 port of websploit?

Regards,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#927135: src:rekall: Please update to python3 version

[Raphael Hertzog]

Hi,

On Fri, 18 Oct 2019, Moritz Mühlenhoff wrote:
> > I started having a look at packaging the new upstream release of
> > rekall, to support python 3 (mostly because rekall is a r-dep of some
> > of the packages i maintain). For now it looks like the most immediate
> > need is to get aff4 ported to python3, as it's a strong dependency of
> > rekall, so i filed #936091
> 
> JFTR, src:pyaff4 is now in the archive.

We prepared the update in git a while ago, I uploaded it to experimental
because I'm not sure that it's really working at this point. I'm not a
rekall user and would like Hilko and/or Sasha to have a look at it.

But I wanted to upload it right now because of the binary-NEW delay that
we will have in any case...

In fact, I'm pretty sure it's broken. I get the same error when I run
debian/tests/linux-image-tests and when I run "rekal --filename
/proc/kcore":

[...]
  File "/usr/lib/python3/dist-packages/rekall/plugins/addrspaces/aff4.py", line 
125, in __init__
os.path.join(cache_dir, "aff4_cache")))
TypeError: Set() missing 1 required positional argument: 'value'

Looks like rekall needs an older version of pyaff4 :-(

https://github.com/google/rekall/issues/493

Since rekall is the only reverse dependency I will likely prepare
a 0.27+really0.26.post6 for python3-pyaff4 unless you feel like patching
the code for this update:
https://github.com/aff4/pyaff4/commit/c72c52ab1faea21ca1afb331d5bdf31270fe3dc2

I don't know if there are others API breaking change in 0.27.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Raphael Hertzog]

On Thu, 17 Oct 2019, Ximin Luo wrote:
> Who is using reprepro to archive Debian Rust packages? That's the first

Anybody who is mirroring Debian unstable with reprepro right now. I have
no special interest in rust, but I do maintain a debian derivative
that we build with reprepro merging debian testing and our own packages
(and we mirror unstable as well because we cherry-pick fixes from unsatble
from time to time, hence the reason why I discovered this before it has
his testing).

> time I've heard of this. I suspect this is a small number (its popcon
> [1] is less than that of rustc itself), and that they will be perfectly
> happy to upgrade to a fixed version of reprepro.

Such a fixed version will not magically appear and will not be magically
deployed. I have no problem upgrading to a newer reprepro once there's a
fixed version but I do still believe that your use of Provides is abusive
and that you should rethink the approach.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Raphael Hertzog]

Hello Ximin,

On Thu, 17 Oct 2019, Ximin Luo wrote:
> >> Do you have some concrete suggestions on how to improve the tool to reduce 
> >> this "abuse"?
> > 
> > Yes, I gave you one.
> 
> It doesn't work.

Look, I'm not a cargo/rust expert, I won't design the tool for you but I
implemented dpkg-gensymbols and the symbols support for dpkg-shlibdeps
and I'm pretty confident that such a solution can work for your case too.

We are not adding a provides to libc6 for each symbol that the library is
exporting. And you should not add a provides for each "interface" (or
whatever it's called in rust) that a package is providing.

You should export the list of interfaces in a separate metadata file thas
is not part of the generated "Packages" file and you should have a tool to
generate the binary dependencies pointing back to the correct package that
is exporting the interface.

It might not be as flexible as the current approach as it might require
rebuilds when the package providing the interface changes, but that's
quite usual in Debian.

> > You are being arrogant. Replying in the same tone, I would say that the
> > design of your tool suck.
> 
> That's cool, and it really doesn't persuade me to have any sympathy
> towards your issue. Note that the next time this package is
> automatically regenerated, your "fixes" will be undone.

Note that if you re-introduce the issue I will ask ftpmasters to
remove the package and/or ask the tech-ctte to decide about it.

(I can play that game too... but it's not helping)

You can't just ignore problems when you are breaking the infrastructure of
derivative distributions and users... right now the problem is limited to
unstable and I'm the first to have discovered it but I'm pretty confident
that others will hit it as well.

And as I said, those servers are not running unstable so if you really
want to go down the route of fixing reprepro (while ignoring the fact
that Ansgar, who is a ftpmaster, is asking you to not continue with such a
Provides header), you will have to get fixes pushed to stable...

> Please be a bit more self-critical about your own opinion. Have you
> considered the possibility that it is the reading tool (reprepro in this
> case) that "sucks" and not the writing tool?

Yes, reprepro sucks in some ways. But a design that puts 270K of metadata
in a single Provides line sucks too.

But reprepro is in wide use and your new package is the first one to
trigger the limit. You can't just ignore the reality, you have to cope
with the fact that we have reprepro users and that we can't deploy
a package with 270K-long Provides header currently.

(And IMO we should never allow this but that's another discussion)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Raphael Hertzog]

On Thu, 17 Oct 2019, Ximin Luo wrote:
> Can you please explain why 256 KB provides field is "abuse"?

Because that's the amount of metadata required for 250 common packages.

> Do you have some concrete suggestions on how to improve the tool to reduce 
> this "abuse"?

Yes, I gave you one.

> BTW, the tool is run not at build time but to generate the source
> package. So it can't use these "foo.cargo" files, because you don't need
> to install all of the dependencies in order to use the tool.

If you run a tool to generate the source package, you can include
whatever call you want during your source package build. i.e. you
control debian/rules too. And you can process the source package
and/or the binary package built to create those meta-information
and also to use the existing meta-information on the system.

> It is 2019. If a tool can't handle 256 KB of data, I'd say the tool is
> at fault and not the 256 KB of data.

You are being arrogant. Replying in the same tone, I would say that the
design of your tool suck.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#942487: [Pkg-rust-maintainers] Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Raphael Hertzog]

Hi,

On Thu, 17 Oct 2019, Sylvestre Ledru wrote:
> I will see how to add a lintian check to block that from happening again.

FWIW, I already filed #942493 against lintian this morning.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#942487: [Pkg-rust-maintainers] Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Raphael Hertzog]

On Thu, 17 Oct 2019, Ximin Luo wrote:
> Control: tags -1 + wontfix

This is clearly not acceptable. You can't ignore problems like this one.
I saw you already broke debian-installer once with the former packages
that overflowed the 16K limit of cdebootstrap. Now it's the turn of
reprepro and this one is harder to fix because there are real servers
running stable version of reprepro, etc.

> The tool's algorithm was suggested by the maintainer of dpkg and has his
> blessing. It is partly due to limitations in dpkg, see #901827 for
> details.

The algorithm is one thing... but the design of your tool is another
thing.

dpkg has dpkg-shlibdeps to build dependencies based on exported
information by various package (through
/var/lib/dpkg/info/*.{shlibs,symbols}).

cargo should build the same infrastructure, i.e. have a
/var/lib/dpkg/info/foo.cargo used by dh-cargo to build the correct
dependency.

Don't abuse the "Provides" field when you have such a volume of
interfaces to document.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Raphael Hertzog]

On Thu, 17 Oct 2019, Raphaël Hertzog wrote:
> For this reason, I'm going to NMU the package and disable/reduce the Provides
> field until you find a reasonable solution.

Uploaded rust-web-sys_0.3.28-1.1_source.changes. It's still 150K but
should make reprepro happy.

I believe it's unreasonable to hardcode so many "interfaces" in the
provides field, in particular when you represent each interface with 4
different versioned variants.

Will all the package really have an auto-generated Depends line listing
all those interfaces ?

FWIW, IRC discussion on #debian-devel concurred that it was really not 
reasonable.

And as a data point:
09:30  Longest Provides currently in unstable/amd64: 277987 
librust-web-sys;  59926 librust-winapi;  7505 oca-addons-account;  3357 
librust-x11+default-dev;  3280 librust-slog+default-dev
09:31  So at least it's only very few packages that have this problem.

But from the top 5, 4 are rust packages. And this one is like 40 times
bigger than the next non-rust package with a big provides line...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#939626: Upstream

[Raphael Hertzog]

Control: tag -1 fixed-upstream

On Wed, 11 Sep 2019 14:00:54 +0200 =?utf-8?Q?S=C3=A9bastien?= Delafond 
 wrote:
> Upstream indicates that:
> 
>   We are working actively on that subject. So the next release of
>   centreon-broker won't need qt4 nor qt5. Qt will be completely removed
>   from it. We hope this change to be finish for the next release of
>   Centreon.
> 
> This is targetted for 19.10, to be released in October 2019.

Sending this mail to avoid the testing autoremoval and giving us more
time, basically waiting for the new upstream release.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875190: [shiboken] Future Qt4 removal from Buster

[Raphael Hertzog]

On Tue, 01 Oct 2019, Didier 'OdyX' Raboud wrote:
> > There are no reverse dependencies of src:shiboken in unstable and it has
> > been replaced by src:pyside2, let's remove from the archive?
> 
> As maintainer: agreed!

Can you file the RM request then?

Thank you.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#934691: rekall: maintainer address bounces

[Raphael Hertzog]

Control: tag -1 + pending

On Tue, 13 Aug 2019, peter green wrote:
> While sending https://lists.debian.org/debian-python/2019/08/msg00072.html I 
> got
> 
>   forensics-de...@lists.alioth.debian.org
> (generated fromrek...@packages.debian.org)
> host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
> SMTP error from remote mail server after RCPT 
> TO::
> 550 Unrouteable address

The maintainer email has been fixed in git a long time ago but no upload
happened so far. I wanted to wait for the python 3 conversion but since
it might take some time still, I'll go ahead with an upload right now
to get this RC bugs out of the picture.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#927135: src:rekall: Please update to python3 version

[Raphael Hertzog]

Hi,

On Sun, 25 Aug 2019, Scott Kitterman wrote:
> If you have lost interest in the package, please let me know so I can ask to 
> have it removed.

Don't remove rekall please. There's a new upstream release with Python 3
support. We will get to it eventually.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#934483: virtualbox-guest-dkms: Doesn't build with latest kernel in unstable 5.2.0-2-686-pae

[Raphael Hertzog]

On Sun, 11 Aug 2019, Christian Marillat wrote:
> But bevare fixind the include file path (drm/ttm/ttm_page_alloc.h) doesn't
> work at all the virtualbox doesn't start.

I fixed the path, the build went through. I rebooted my VM and it worked.

What exactly was the failure that you had? Did you have some error message
in the kernel logs?

However on the gdm3 login screen, after I have input my login/password,
the picture stays fixed and I have to resize the window or force a VT
switch to get it working again...

In the kernel log I see this:
> [drm] Error -12 pinnning new fb, out of video mem?

And as you mentionned in your other mail, if I increase the allocated
memory for video to 32 Mb (I had 16), this problem goes away.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#934483: virtualbox-guest-dkms: Doesn't build with latest kernel in unstable 5.2.0-2-686-pae

[Raphael Hertzog]

Hi,

On Thu, 15 Aug 2019, Darsey Litzenberger wrote:
> I haven't gotten around to testing, but it looks like maybe all that needs
> to be done is to disable building some of these modules after a certain
> kernel version.

At least I can confirm that if you disable "vboxvideo" from the
dkms configuration (in dkms.conf and Makefile in the
/usr/src/virtualbox-guest-6.0.10/ directory), then the DKMS build
works.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#932506: elastalert: (build-)depends on cruft packages.

[Raphael Hertzog]

Control: tag -1 + confirmed upstream fixed-upstream

Hi,

On Sat, 20 Jul 2019, peter green wrote:
> elastalert (build-)depends on the python-croniter binary package which
> is no longer built by the python-croniter binary package.
> 
> If you want to keep your package in Debian you will probablly need to
> migrate to python 3.

There's a new upstream release compatible with Python 3. We will update
the package next week (mainly replying this to reset the timer for the
autoremoval from testing).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#930929: [Pkg-libvirt-maintainers] Bug#930929: marked as done (libvirt: is no longer able to use kvm)

[Raphael Hertzog]

Hi,

On Sun, 23 Jun 2019, Guido Günther wrote:
> > But after a reboot with the good systemd, it began again to work... sorry
> > for the noise!
> 
> Thanks for reporting all the details! Should we expect issues with newer
> systemd then or do you deem the problems related to the patches you
> tested?

I don't see any relationship between the patches that I tested and this
issue... but at the same time, I don't see any significant upstream change
either to 50-udev-default.rules so I'm not sure where it came from.

Maybe related to some other changes on how "uaccess" works? Every time I
modified manually /dev/kvm to "chgrp kvm /dev/kvm "and when I restarted
libvirtd, it was back to "root:root" ownership.

FWIW, I was running a git snapshot of June 13th with a patch for
PR12795 that I built on top of the packaging of what's in experimental.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#930929: libvirt: is no longer able to use kvm

[Raphael Hertzog]

On Sat, 22 Jun 2019, Raphael Hertzog wrote:
> And despite this I still have the error and yet the libvirt-qemu user
> is part of the kvm group:
> $ id libvirt-qemu
> uid=124(libvirt-qemu) gid=130(kvm) groupes=130(kvm),132(libvirt-qemu)

Still I confirm that the libvirt-qemu user is not able to open /dev/kvm.

$ sudo -u libvirt-qemu qemu-system-x86_64 -enable-kvm -S -no-user-config 
-nodefaults -nographic -machine none,accel=kvm:tcg -qmp 
unix:/tmp/qmp.monitor,server,nowait
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
qemu-system-x86_64: Back to tcg accelerator
^Cqemu-system-x86_64: terminating on signal 2

Running the same command with my personal user works fine.

Looking with strace in this command run as libvirt-qemu gives this:
openat(AT_FDCWD, "/dev/kvm", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(2, "Could not access KVM kernel modu"..., 54Could not access KVM kernel 
module: Permission denied
) = 54
write(2, "qemu-system-x86_64: failed to in"..., 64qemu-system-x86_64: failed to 
initialize KVM: Permission denied
) = 64

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#930929: libvirt: is no longer able to use kvm

[Raphael Hertzog]

Control: found -1 5.0.0-3
Control: found -1 5.2.0-2

On Sat, 22 Jun 2019, Raphaël Hertzog wrote:
> For a few days/weeks (I'm not sure when it started exactly), I can no
> longer run my VM with virt-manager.

I tried downgrading to the version in testing, but the problem stayed the
same. I also tried with the version 5.2.0-2 in experimental, same result.
(But that was before I realized the problem with my systemd version, see
below)

> When I try to start a VM I see this in the logs of libvirtd:
> libvirtd[12569]: Unable to read from monitor: Connexion ré-initialisée par le 
> correspondant

FWIW, the part of this message in French is "Connection reset by peer".

> $ ls -al /dev/kvm
> crw-rw+ 1 root root 10, 232 juin  22 19:07 /dev/kvm

This was wrong, and it was due to a systemd/udev version that I manually
built out of experimental with upstream patches to test... now I
downgraded to the version in unstable and I have this:

$ ls -al /dev/kvm
crw-rw+ 1 root kvm 10, 232 juin  22 21:14 /dev/kvm

And despite this I still have the error and yet the libvirt-qemu user
is part of the kvm group:

$ id libvirt-qemu
uid=124(libvirt-qemu) gid=130(kvm) groupes=130(kvm),132(libvirt-qemu)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Raphael Hertzog]

Hi,

On Wed, 05 Jun 2019, Michael Biebl wrote:
> systemd-networkd.service in v241 is locked down more tightly then v232.
> It might be worth a try to comment out the hardening features one by one
> to see if one of them causes your problem.

Thanks for the idea! I tried that but it did not help. I found the issue
after a few more tries tweaking the network configuration file. It's
simply that the system has IPv6 disabled in the kernel policy while the
.network file instructs to configure an IPv6 address.

Both are contradictory but they happily lived together up-to-now.
I don't know what changed but if we don't improve systemd-networkd
to just skip IPv6 configuration when the kernel has a policy disabling
IPv6, then we will have plenty of servers broken on upgrades because
it's quite common to keep the network configuration file provided by
the hoster and just disable IPv6 at the kernel level with sysctl:

$ grep ipv6 /etc/sysctl.conf
# Disable ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

[Raphael Hertzog]

Hi,

On Wed, 05 Jun 2019, Michael Biebl wrote:
> What's the status of this bug?

No progress.

> Can you reproduce it with v242 from experimental?

Yes.

> I guess upstream is waiting for your feedback:
> https://github.com/systemd/systemd/issues/12656#issuecomment-496293294

I will provide my result with systemd from git master soon. But there's
not much else that I can do.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#924042: tomb: Multiple package relations for optionally used tools are missing (steghide, dcfldd, gettext-base, qrencode, unoconv, lsof, swish-e)

[Raphael Hertzog]

Control: severity -1 important

On Fri, 08 Mar 2019, Axel Beckert wrote:
> tomb's exhume subcommand calls steghide:
> 
> ~ → tomb exhume /tmp/example.jpg
> tomb [E] Steghide not installed: cannot exhume keys from images.

The failure mode is rather clean, I don't think the missing
recommends/suggests warrants a serious bug. I'm downgrading
this bug to important.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#920377: dpkg > 1.19.3 breaks reprepro

[Raphael Hertzog]

Hi,

On Thu, 24 Jan 2019, Alf Gaida wrote:
> Commit 
> https://salsa.debian.org/dpkg-team/dpkg/commit/4a4619831de8b8972f86b489660dc98f187cfa34.patch
>  breaks reprepro.

For reference, that commit says this:
| dpkg-genchanges: Only reference binary packages being uploaded
| 
| The .changes file describes an upload, and its Binary and Description
| fields should contain (as documented) only references to the packages
| being uploaded.
| 
| In case of a source-only upload, the Binary and Description fields
| should be empty.
|
| Closes: #818618

And the "--ignore=missingfield" option is not sufficient to ignore the
error (the "Binary" field is not among the fields that are ignorable).

$ reprepro --ignore=missingfield processincoming kali 
rfcat_170508-0kali3_source.changes
In 'rfcat_170508-0kali3_source.changes': Missing 'Binary' field!
There have been errors!

This is rather annoying as we can't use the latest dpkg to upload packages
to any reprepro-based repository.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#891670: pymssql FTBFS with freetds-dev 1.00.82-2

[Raphael Hertzog]

Hi,

On Sun, 24 Jun 2018, Geoffrey Thomas wrote:
> Upstream is being slow to put out a new release, there's some blocker
> involving the new freetds. I asked if that was resolved yet:
> 
> https://github.com/pymssql/pymssql/issues/528
> 
> At some point (probably in a month or two, honestly...) I'll cherry-pick the
> relevant patches if there's no release, but I'd prefer to see upstream be
> confident about the new freetds version.

There's a new upstream release available. We need this package
updated for Python 3.7 for Kali so we will look into this if nobody
else is quicker.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#920366: developers-reference: ftbfs in sid, builds fine in stable

[Raphael Hertzog]

Hi,

On Sat, 26 Jan 2019, Norbert Preining wrote:
> FIrst of all, I cannot reproduce this error on sid, so with all packages
> properly upgraded.
> 
> That means, I assume you have a mixed upgrade of packages where it
> fails, is this correct?

Yes, debci triggers autopkgtest of reverse dependencies but it only
upgrades the candidate package when it can (there might be more package
updates at the same time if dependencies require it).

> I will upload new packages that include the fontspec fixes, as well as
> tighter package coupling. This will fix 2- and most probably also 1-,
> but I still hope that I get feedback from logidee-tools maintainers.

Honestly, I haven't looked into this problem but if you look at
https://ci.debian.net/packages/l/logidee-tools/ you will see that it
always passed in "sid" but that it failed in testing when you inject
texlive-base or texlive-extra from sid:
https://ci.debian.net/packages/l/logidee-tools/testing/amd64/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#919578: rozofs: FTBFS with undefined references to major, minor

[Raphael Hertzog]

Hi,

On Thu, 17 Jan 2019, Andreas Beckmann wrote:
> rozofs recently started to FTBFS in an up-to-date sid+experimental
> pbuilder environment:

FWIW, I filed earlier today an RM bug:
https://bugs.debian.org/919568

So I don't plan to handle this bug.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#822586: Upstream status update

[Raphael Hertzog]

Hello,

just FYI since upstream was unable to port the code to the GObject
Introspection bindings, he started to rewrite the application in
C++ using GTKmm. This is happening in the "future" directory of the
upstream git repository (master branch) and the author shares
some progress information here:
https://www.giuspen.com/topic/status-of-the-development/

As of today, it seems that the C++ rewrite is able to display
content in read-only mode so it's not finished yet.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#917199: pivy, unbuildable on mips* due to testsuite failures in patchelf.

[Raphael Hertzog]

Hi,

On Sun, 13 Jan 2019, Adrian Bunk wrote:
> Test cases that passed in patchelf 0.8 fail since 0.9,
> and segmentation fault on things like setting rpath
> might be close enough to "entirely broken".

In that case, it would certainly help upstream if someone
(maintainer/porter) could try to "git bisect" the issue so that we can
better identify the issue.

And maybe we want to revert to the former patchelf in Debian
(i.e. 0.9+really0.8) if it lasts too long.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#917199: pivy, unbuildable on mips* due to testsuite failures in patchelf.

[Raphael Hertzog]

Hi,

On Sat, 12 Jan 2019, Adrian Bunk wrote:
> pyside2 is now built without patchelf on mips64el.
> 
> Doing the same for mips and mipsel should fix the problem for pivy.

Yeah, but this is not going in the right direction. This means that
pyside will be built with the embedded patchelf. The embedded patchelf is
outdated. But it will build and do its work...

Really, if the test suite failure can't be fixed quickly, it would be
better to ignore the failure on the broken architectures and let the
package build anyway. It's unlikely that the tool is entirely broken...
and it's just a pity to ask pyside to deal with a varying set of
architectures for patchelf.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#849308: Please let wireguard migrate to testing

[Raphael Hertzog]

Hello Daniel,

we want wireguard in Kali and Kali is based on Debian testing. For now we
imported it manually from Debian Unstable but it's counter-productive, 
we have rolling distributions (kali and testing) and an upstream
following a rolling model and yet we don't have its packages
automatically.

My suggestion is to just let the package migrate to testing so that you
can provide stable backports to users. At freeze time, you reconsider the
situation:
- either it's not a good idea to ship it in stable and then you ask
  the release manager for a removal hint (quick and easy)
- or you discuss with the security team (or SRM) if it's possible
  to regularly import new upstream release as upstream is only supporting
  the latest release...
- or upstream changed its policy because it has been merged in the kernel
  and you're good to go

Please close this bug. Thank you.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#853310: android-platform-system-core: ftbfs with GCC-7

[Raphael Hertzog]

Hi,

On Thu, 13 Sep 2018, 殷啟聰 | Kai-Chung Yan wrote:
> > It would have helped if you had given me the URL of the repository.
> > Anyway, I'm willing to sponsor the update (even though I don't know much
> > about Android Tools) but I have a few comments:
> 
> Thank you for the sponsor, it will help us a lot!
>
> The repository is at
> .
> Sorry about that, I thought it was too trivial.

It's not hard but I did not know the name of the team on salsa and there
are many packages in the team and the Vcs-Git in the current source
package was obviously outdated. :)

Anyway, I sponsored this upload targetting experimental.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#853310: android-platform-system-core: ftbfs with GCC-7

[Raphael Hertzog]

Hello,

On Tue, 11 Sep 2018, 殷啟聰 | Kai-Chung Yan wrote:
> Sorry for being dormant on the matter. We had been in the process of
> updating the whole SDK suite to Oreo but it is blocked by an upload of
> this package. The latest update produces several new packages so I don't
> have the permission to upload it, and the DDs in the team were too busy
> as well.

Who are the DD in the team? Are there other contributors currently
following the process to become a DD?

> It would be wonderful if you could sponsor the upload. We have prepared
> everything on Salsa, all you need to do is to change "UNRELEASED" to
> "experimental" in the changelog. The RFS [1] has more details.

It would have helped if you had given me the URL of the repository.
Anyway, I'm willing to sponsor the update (even though I don't know much
about Android Tools) but I have a few comments:

1/ your RFS mentions the need to do a "stage1" upload but you actually
manually dropped the package and the build dependencies that were tagged
stage1, why did you do that?

2/ I don't understand why you replace "android-tools-mkbootimg" with
"mkbootimg". The latter package has a very generic name while the former
was rather explicit. It looks like a step backwards. Yes, now it matches
the name of the executable inside the package, but I'm not sure it
justifies introducing a new package and dealing with a transitional
package. What was your rationale? And you should have documented your
rationale in the commit messages and in the changelog entry.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#853310: android-platform-system-core: ftbfs with GCC-7

[Raphael Hertzog]

Hello,

this bug on android-platform-system-core is the reason why
apktool got dropped from Debian Testing. I would like it to go back
to Debian Testing.

I saw that the package has many updates in the git repository.
I guess the FTBFS issue is fixed in the new upstream version that you
packaged in git. Can you thus release the update and get back to a better
state ?

Let me know if I can help (for example if you need sponsorship).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#901572: acccheck: CVE-2018-12268: Patch proposal

[Raphael Hertzog]

Control: affects 904200 acccheck

On Mon, 03 Sep 2018, p...@reseau-libre.net wrote:
> I've updated the acccheck.pl behavior to correct (i hope) the
> CVE-2018-12268. User and password input files are sanitized before any use
> in the generated commandline string. The patch is given attached to this
> mail.

FWIW, I requested the removal of the package a while ago:
https://bugs.debian.org/904200

And this is not the only security issue in that script... there's no point
in spending any time on this issue.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Raphael Hertzog]

Hi,

On Mon, 27 Aug 2018, Sean Whitton wrote:
> On Mon 27 Aug 2018 at 12:58PM +0200, Raphael Hertzog wrote:
> > Or you could have read dh_linktree's manual page and see that you can
> > use "replace" instead of "deduplicate" to get a weak dependency.
> 
> I did read this -- unfortunately, though, it would not help make
> debian-policy installable on stretch, which was the original bug
> reporter's problem.

Ok, sorry for having commented too hastily.

(But this is the kind of thing which makes me believe that we go
too far in the avoid duplicating code, so much energy spent for
almost no gain)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#906139: debian-policy: versioned depends on libjs-sphinxdoc unsatisfiable on stretch

[Raphael Hertzog]

Hi,

On Sat, 25 Aug 2018, Sean Whitton wrote:
> Urgh.
> 
> I am reluctantly (yet gratefully!) working on implementing Ian's
> substvar hack.

Or you could have read dh_linktree's manual page and see that you can
use "replace" instead of "deduplicate" to get a weak dependency.

$ git diff
diff --git a/debian/debian-policy-ja.linktrees 
b/debian/debian-policy-ja.linktrees
index bb8ef9b..74aef4c 100644
--- a/debian/debian-policy-ja.linktrees
+++ b/debian/debian-policy-ja.linktrees
@@ -1 +1 @@
-deduplicate /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/ja/policy.html/_static/
+replace /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/ja/policy.html/_static/
diff --git a/debian/debian-policy.linktrees b/debian/debian-policy.linktrees
index 88fadfd..ea76805 100644
--- a/debian/debian-policy.linktrees
+++ b/debian/debian-policy.linktrees
@@ -1 +1 @@
-deduplicate /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/policy.html/_static/
+replace /usr/share/javascript/sphinxdoc/1.0/ 
usr/share/doc/debian-policy/policy.html/_static/

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#902812: wcc FTBFS

[Raphael Hertzog]

Hi,

On Wed, 18 Jul 2018, Axel Beckert wrote:
> > Axel mentioned failed bin-nmu but it looks like the bin-nmu worked:
> > https://buildd.debian.org/status/fetch.php?pkg=wcc=amd64=0.0.2%2Bdfsg-3%2Bb2=1531313043=0
> 
> Sorry, I deduced that from "uninstallable + FTBFS".
> 
> > I downgraded the bug for now.
> 
> Fair enough, but it's still uninstallable, even despite that BinNMU:
> 
> The following packages have unmet dependencies:
>  wcc : Depends: libbinutils (< 2.30.90.20180711) but 2.31-1 is to be installed
> E: Unable to correct problems, you have held broken packages.
> 
> So raising to RC again.
> 
> From my point of view this means that either another BinNMU was
> necessary since the previous BinNMU, but was not yet triggered, or
> something else is broken in the package.

Yeah, a new binutils got uploaded multiple times in the last days.

Matthias, I don't know how many reverse deps there are but given that you
have so strict dependencies on libbinutils, you have to handle a small
transition for every upload of a new upstream release.

For now I requested a bin-nmu in #904073.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#902812: wcc FTBFS

[Raphael Hertzog]

Control: severity -1 important
Control: tag -1 + unreproducible

Philippe, if you don't put Sylvestre and Axel in copy, they won't get
your mail sent only to 902...@bugs.debian.org.

On Wed, 18 Jul 2018, Philippe Thierry wrote:
> I take a look at the bug you reported and I didn't managed to reproduce
> it. I've rebuilt wcc in a newly updated sid pbuilder env and the package
> was built correctly.

Same here.

> Does the build fail on a buildd host ? Can you confirm it is still
> failing ? I attach the package buildinfo to this mail in order to
> compare if needed.

Axel mentioned failed bin-nmu but it looks like the bin-nmu worked:
https://buildd.debian.org/status/fetch.php?pkg=wcc=amd64=0.0.2%2Bdfsg-3%2Bb2=1531313043=0

I downgraded the bug for now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#875885: netkit-tftp: does not trap ./configure errors

[Raphael Hertzog]

Hello Alberto,

it's been 8 years that you haven't touched netkit-tftp and the package
has been removed from Debian testing due to the bug I'm replying to.

Can you take care of fixing the bug and/or properly orphaning the package
if you are no longer interested in it?

Regards,

On Fri, 15 Sep 2017, Helmut Grohne wrote:
> Source: netkit-tftp
> Version: 0.17-18.1
> Severity: serious
> Justification: policy 4.6
> 
> netkit-tftp's debian/rules does not trap errors from ./configure. In
> case ./configure fails, the build continues. This can produces
> apparently successful misbuilds and is prohibited by the Debian policy
> in section 4.6.
> 
> Helmut

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#899688: Bug#899851: schroot: Invalid maintainer address buildd-tools-de...@lists.alioth.debian.org

[Raphael Hertzog]

Hi Simon,

On Wed, 06 Jun 2018, Simon McVittie wrote:
> Since nobody seems to have objected to this and I found myself wanting to
> refer to up-to-date schroot/sbuild source code today, I've imported both
> projects into Salsa using `git push --mirror` from the archives in
> . They are now at
>  and
> . Please move or delete those
> repositories if they are not what you wanted.

Thanks for doing this. I enabled the integration with the package tracker
and the tagpending hook. 

> The RC bug regarding the Maintainer address remains open.

I just orphaned schroot to fix the maintainer email.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#899851: schroot: Invalid maintainer address buildd-tools-de...@lists.alioth.debian.org

[Raphael Hertzog]

Hi,

On Thu, 24 May 2018, Johannes Schauer wrote:
> yes, I read about this possibility on debian-devel@ and it sounds intriguing.
> But I neither know how to set up that team on tracker, nor am I convinced yet,
> that it would make sense to do so. Which packages would be maintained by that
> team? Would it just be sbuild and schroot?

Yes, just sbuild and schroot, just like now. 

> Does it still make sense to have one address for both? The packages are
> quite independent IMHO.

They are, technically, but in practice they are used together in most
cases. And it makes sense to make it easy to follow both and to have a
point of contact to join maintainers of both packages.

Also we have multiple uploaders for each package, so it makes sense to not
put back an individual maintainer in the Maintainer field. If we don't want
a mailing list, we only have two alternatives team+buildd-tools@tracker or
(sbuild|schroot)@packages.debian.org.

The former is better handled right now (the latter will generate duplicate
emails). Uploaders are free to subscribe either to the team or to the
individual package depending on what they want (even through the team you
can tweak your package subscription).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#899851: schroot: Invalid maintainer address buildd-tools-de...@lists.alioth.debian.org

[Raphael Hertzog]

Hi,

On Thu, 24 May 2018, Christoph Biedl wrote:
> as you've probably heard, Debian's alioth services are shutting down.
> This affects your package schroot since the list address
> buildd-tools-de...@lists.alioth.debian.org used in the Maintainer:
> field was not transferred to the alioth-lists service that provides a
> continuation for the lists in the @lists.alioth.debian.org domain.

Johanness, what's your plan for sbuild?

My suggestion would be to to create a tracker.debian.org team (let's say
buildd-tools) and use team+buildd-tools@t.d.o as maintainer email.

As for git repositories, we should move them to salsa in the "debian"
group I believe. I don't see the point of a dedicated team at this stage.

What do you think?

> * Upload another version with a new maintainer address of your choice,

BTW Christoph, it would be nice to include a word about the possibility
to use team+...@tracker.debian.org after having created a team with slug
"foo" on https://tracker.debian.org/teams/+create/

Referring directly to
https://wiki.debian.org/Salsa/AliothMigration#tracker.debian.org is a
possibility for now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#896071: debootstrap fails to retrive Release file over https

[Raphael Hertzog]

On Mon, 23 Apr 2018, Hideki Yamane wrote:
> Hi,
> 
> On Sun, 22 Apr 2018 09:40:54 +1000
> David Margerison  wrote:
> > >  "$@" is extracted as '' and wget tries to fetch it and fails,
> > >  then returns 1.
> > 
> > Regarding the proposed fix, in general using $@ without quotes is fragile.
> 
>  Most of the case, quotes is better. But in this case, "$@" is extracted like
> >> wget '' '' '' https://deb.debian.org/debian/dist/unstable/InRelease
>  Then, it outputs
> >>http://: Invalid host name.
> >>http://: Invalid host name.
> >>http://: Invalid host name.
>  and returns 1.

I agree with David that using $@ without quotes is not a good idea.
What you want is to not pass empty arguments to wgetprogress. So you should
likely drop the quotes around the first 3 parameters on this line:
if wgetprogress "$CHECKCERTIF" "$CERTIFICATE" "$PRIVATEKEY" -O 
"$dest" "$from"; then

I'm suggesting only the first 3 since those are the variables that can be
empty. And we want to keep the quote on "$dest" to be able to use path
containing spaces (which you likely lost with your fix).

But even here it's not perfect since we loose the possibility to handle
arguments containing spaces in the first 3 parameters. A complete fix would
involve setting up the argument list manually:

set -- -O "$dest" "$from"
if [ -n "$PRIVATEKEY" ]; then
set -- "$PRIVATEKEY" "$@"
fi
if [ -n "$CERTIFICATE" ]; then
set -- "$CERTIFICATE" "$@"
fi
if [ -n "$CHECKCERTIF" ]; then
set -- "$CHECKCERTIF" "$@"
fi
if wgetprogress "$@"; then
[...]

Here we should be safe even if those 3 variables do contain spaces.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#896071: debootstrap fails to retrive Release file over https

[Raphael Hertzog]

Hi,

On Tue, 24 Apr 2018, Hideki Yamane wrote:
>  I'll revert below your commit since this regression fix also solve it.
> 
> > commit c1c20ed48e83fe9d4f3512c524f7734d4e1469ac
> > Author: Raphaël Hertzog 
> > Date:   Thu Apr 12 12:18:29 2018 +0200
> > 
> > Do not use HTTPS for Kali bootstrap script
> 
>  Please let me know if you don't want it.

Honestly, I'd prefer not to diverge from Debian and use plain http as well
so that we limit the risk of regression related to https support.

In particular since our main http.kali.org host redirects to many other
mirrors whose certificates are not under our control. We are not monitoring
that all the certificates are valid.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#890043: wcc: diff for NMU version 0.0.2+dfsg-2.1

[Raphael Hertzog]

On Fri, 09 Mar 2018, Adrian Bunk wrote:
> I've prepared an NMU for wcc (versioned as 0.0.2+dfsg-2.1) and uploaded 
> it to DELAYED/3. Please feel free to tell me if I should cancel it.

Thanks for this, but I just uploaded a new version with this change and
other cleanups too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#889187: [Pkg-e-devel] Bug#889187: e17-dbg is empty

[Raphael Hertzog]

Control: severity -1 important

On Sat, 03 Feb 2018, Andreas Metzler wrote:
> > Debug information is in e17-dbgsym,
> > likely the fix is to drop e17-dbg.
> 
> This is fixed in experimental.

Why not in unstable? This bug was marked as grave (it probably did not
deserve this severity, but nobody changed it) and the package has been
removed from Debian testing now. :-(

Can we upload the experimental version to unstable or what's holding it
up?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#887062: [Pkg-raspi-maintainers] Bug#887062: raspi3-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/

[Raphael Hertzog]

Hello Michael,

On Thu, 18 Jan 2018, Michael Stapelberg wrote:
> Given that the package’s only purpose is to populate /boot/firmware, may I
> ask why it’s being installed in your builds at all? I’d like to understand
> the use-case before adding code to deal with it.

The package name contains "firmware" so it's automatically installed by
live-build in the chroot. This is an hardware-enablement feature of
live-build.

See "--firmware-chroot true" in:
https://manpages.debian.org/stretch/live-build/lb_config.1.html

And in general, even if only for automated testing purposes, packages
should be installable without any special pre-requisites.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#886506: busybox sh broken on i386 with glibc 2.26, leads to kernel panic

[Raphael Hertzog]

Hello,

On Wed, 17 Jan 2018, Aurelien Jarno wrote:
> busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has
> the same effect of reducing the default stack alignment from 16 bytes to
> 2 bytes. This comes from arch/i386/Makefile:
> 
> |  # -mpreferred-stack-boundary=2 is essential in preventing gcc 4.2.x
> |  # from aligning stack to 16 bytes. (Which is gcc's way of supporting SSE).
> |  CFLAGS += $(call cc-option,-march=i386 -mpreferred-stack-boundary=2,)
> 
> I don't really get why it is essential to prevent gcc from aligning
> stack to 16 bytes, anyway this is a bad idea. Removing this option just
> fixes the issue.

I confirm that rebuilding busybox with this option dropped fixed the issue
for me. I uploaded a fixed busybox to Kali. I'm happy to do the same for
Debian if it can help the current maintainers.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#828483: osslsigncode: FTBFS with openssl 1.1.0

[Raphael Hertzog]

[ Copy to upstream author to know his plans wrt openssl 1.1
  and to invite him to review the current patches ]

Hello Stephen,

On Sun, 26 Jun 2016, Stephen Kitt wrote:
> On Sun, 26 Jun 2016 12:23:30 +0200, Kurt Roeckx  wrote:
> > If you have problems making things work, feel free to contact us.
> 
> I've managed to fix most of the build issues, the remaining issue I'm faced
> with is the apparent disappearance of the STACK API (DECLARE_STACK_OF()) etc.
> What should I be using instead?

There's a patch that has been submitted to upstream here:
https://sourceforge.net/p/osslsigncode/patches/10/
https://sourceforge.net/p/osslsigncode/patches/10/attachment/0001-Make-code-work-with-OpenSSL-1.1.patch

It removes (not very cleanly) the "pagehash" functionality alltogether to
avoid this problem (-ph command line option).

This package has already been dropped out of testing so it would be
nice if we could complete this OpenSSL 1.1 transition to bring
it back into Debian testing.

Per, do you have plans to make osslsigncode compatible with OpenSSL 1.1?
Could you review the above patch and work with Reimar Döffinger and/or
Stephen Kitt to have something suitable for merge?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#887062: [Pkg-raspi-maintainers] Bug#887062: raspi3-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/

[Raphael Hertzog]

On Sat, 13 Jan 2018, Michael Stapelberg wrote:
> The only change that seems in any way related to me is
> https://anonscm.debian.org/cgit/pkg-raspi/raspi3-firmware.git/commit/?id=c977f0210ab5c577b9d5296e4e4391225a7f85ca

This change is not the cause of the regression. The package fails at
initial installation, not on upgrade. I have added "set -x" and I get
this:

# dpkg --configure raspi3-firmware
Setting up raspi3-firmware (1.20171201-2) ...
+ ischroot
+ basename /usr/lib/raspi3-firmware/bootcode.bin
+ file=bootcode.bin
+ cp /usr/lib/raspi3-firmware/bootcode.bin /boot/firmware/bootcode.bin
cp: cannot create regular file '/boot/firmware/bootcode.bin': No such file or 
directory
dpkg: error processing package raspi3-firmware (--configure):
 installed raspi3-firmware package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 raspi3-firmware

I wonder how it worked before. Maybe the package shipped /boot/firmware or
another package supplied that directory and it now fails because no
package is creating it.

In any case, you should probably not attempt to copy the files there if the
directory is not existing.

Something like this:

--- /tmp/postinst   2018-01-15 11:35:43.223477268 +
+++ /var/lib/dpkg/info/raspi3-firmware.postinst 2018-01-15 11:40:31.818918341 
+
@@ -13,19 +13,23 @@
   fi
 fi

-for file in /usr/lib/raspi3-firmware/*
-do
-  file=$( basename "$file" )
-  cp "/usr/lib/raspi3-firmware/$file" "/boot/firmware/$file"
-  # sync might fail when running under qemu, which, as of version 2.7,
-  # has not implemented the syncfs syscall.
-  sync -f "/boot/firmware/$file" || true
-done
+if [ -d /boot/firmware ]; then
+   for file in /usr/lib/raspi3-firmware/*
+   do
+ file=$( basename "$file" )
+ cp "/usr/lib/raspi3-firmware/$file" "/boot/firmware/$file"
+ # sync might fail when running under qemu, which, as of version 2.7,
+ # has not implemented the syncfs syscall.
+ sync -f "/boot/firmware/$file" || true
+   done

-# Manually trigger the kernel postinst hook when raspi3-firmware is first
-# installed (or upgraded), as the kernel package might already be installed
-# (or not upgraded) and hence the hook would not get triggered otherwise.
-DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/raspi3-firmware
+   # Manually trigger the kernel postinst hook when raspi3-firmware is 
first
+   # installed (or upgraded), as the kernel package might already be 
installed
+   # (or not upgraded) and hence the hook would not get triggered 
otherwise.
+   DEB_MAINT_PARAMS="configure" /etc/kernel/postinst.d/raspi3-firmware
+else
+   echo "Warning: not copying firmwares as /boot/firmware does not exist." 
>&2
+fi
 ;;
 esac

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#882372: Processed: Bug fix for ohcount #882372

[Raphael Hertzog]

Hello Sylvestre,

On Thu, 07 Dec 2017, Sylvestre Ledru wrote:
> I don't see the patch fixing the issue?!

The debian security tracker has a note with this patch:
https://github.com/blackducksoftware/ohcount/commit/6bed45d6fb7c080ae5c163c12b4eb8749a3492ac

It looks like the problematic "file" invocation has been replaced by
the use of libmagic.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#881097: To be removed from wheezy as well

[Raphael Hertzog]

On Tue, 19 Dec 2017, Emilio Pozuelo Monfort wrote:
> > Chris or Thorsten, could you possibly look into what it involves and see 
> > whether
> > it's doable on the ftpmaster side ?
> 
> Another, easier option would be to declare these packages as unsupported
> security-wise.

I pushed a commit into debian-security-support's git repo for this. But it
would still be nice to see what it involves to actually update the
Packages* files when we want to remove a source package.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#881097: To be removed from wheezy as well

[Raphael Hertzog]

Hi,

On Tue, 19 Dec 2017, Salvatore Bonaccorso wrote:
> > Actually it got removed from wheezy in the mean time. Since it was
> > marked that way in dla-needed.txt, I pinged the ftp.d.o bug report and 
> > pinged Chris Lamb (as ftp assistant) and the package is gone from wheezy:
> > 
> > $ rmadison libnet-ping-external-perl
> > libnet-ping-external-perl | 0.13-1| oldstable-kfreebsd | source, all
> > 
> > https://tracker.debian.org/pkg/libnet-ping-external-perl
> 
> But I don't think thas worked as you might have expected, and it's not
> really gone yet. While the dak rm works, there is no point release
> mechanism for wheezy (LTS) and you still will find
> libnet-ping-external-perl in the archive (and on the mirrors), as
> there was not the usual procedure of removing the package, making a
> new release, and pushing out the updates to the mirrors.

Indeed, you are right:
rhertzog@nas:/srv/debian/mirror/dists/wheezy/main/binary-i386$ zgrep 
libnet-ping-external-perl Packages.gz
Package: libnet-ping-external-perl
Filename: 
pool/main/libn/libnet-ping-external-perl/libnet-ping-external-perl_0.13-1_all.deb

The Packages* files have not been updated since June 4th 2016. Only the Release 
file
gets regular updates.

Maybe it's time to see what is required to be able to update wheezy... I don't
think there's any technical reason behind this behaviour. It's just policy that
we don't want to touch the Packages* files except during point releases.

Given the current LTS policies, I believe that we could have unannounced point
releases that do not increment any version number... as long as we just remove
some packages.

Chris or Thorsten, could you possibly look into what it involves and see whether
it's doable on the ftpmaster side ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#881097: To be removed from wheezy as well

[Raphael Hertzog]

Hello,

On Sun, 17 Dec 2017, Ola Lundqvist wrote:
> After some more reading I think removing it should be ok anyway. I'll
> change the wording from "will be removed" to "may be removed" to allow
> us the freedom to keep it if nobody takes the action to actually
> remove it.

Actually it got removed from wheezy in the mean time. Since it was
marked that way in dla-needed.txt, I pinged the ftp.d.o bug report and 
pinged Chris Lamb (as ftp assistant) and the package is gone from wheezy:

$ rmadison libnet-ping-external-perl
libnet-ping-external-perl | 0.13-1| oldstable-kfreebsd | source, all

https://tracker.debian.org/pkg/libnet-ping-external-perl

Cheers,

> On 17 December 2017 at 20:28, Ola Lundqvist  wrote:
> > Hi
> >
> > I agree that it may not be the best to remove it then. I suggest we
> > mark it as no-dsa then. Any objections?
> >
> > // Ola
> >
> > On 22 November 2017 at 21:00, Emilio Pozuelo Monfort  
> > wrote:
> >> On 08/11/17 20:19, Ola Lundqvist wrote:
> >>> Hi
> >>>
> >>> Considering that this package is about to be removed from jessie I
> >>> guess it should be removed from wheezy too. How is that done? Should I
> >>> contact the FTP maintainers about it, or do we simply ignore the
> >>> issue?
> >>
> >> We don't have point releases, so I'm not sure we can get a package removed 
> >> at
> >> this stage without extra work by the ftp masters. So our options would be:
> >>
> >> - mark as no-dsa if it's not important enough
> >> - mark as unsupported / end-of-life
> >> - fix it
> >> - get it removed
> >>
> >> The issue seems only exploitable if it's used by a service that is exposed
> >> remotely or to other issues... and has no rdeps in wheezy. OTOH there is at
> >> least one sponsor using that package. So removing it may not be the best 
> >> course
> >> given there is a proposed patch. So I'd go with either no-dsa or fix it,
> >> depending on the assessed importance.
> >>
> >> Cheers,
> >> Emilio
> >
> >
> >
> > --
> >  --- Inguza Technology AB --- MSc in Information Technology 
> > /  o...@inguza.comFolkebogatan 26\
> > |  o...@debian.org   654 68 KARLSTAD|
> > |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> > \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
> >  ---
> 
> 
> 
> -- 
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---
> 

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory

[Raphael Hertzog]

On Tue, 28 Nov 2017, Goirand Thomas (aka zigo) wrote:
> I did try to purge and it didn't help. The issue is indeed about 2
> kernels installed, though as I wrote, upgrading linux-image-amd64 first
> works arround the problem. So I'm not sure what's going on, really. Any
> hint/clue ?

Run "update-initramfs -u -v" to get more information on where it's
failing?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory

[Raphael Hertzog]

Hi Thomas,

On Sun, 26 Nov 2017, Thomas Goirand wrote:
> After booting a Stretch live image, I tried to upgrade it to Sid, and
> it fails with this error:
> 
> update-initramfs: deferring update (trigger activated)
> cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory

This is usually a sign that you have multiple kernel images installed
and the (failing) script is only able to cope with one.

But I have no idea what script is involved here.

> Removing the package live-boot-initramfs-tools before the upgrade isn't
> even a workaround, it continues to crash.

Did you try to purge it? (The problematic hook script might still be
installed after removal if it's in /etc)

> I need this to be fixed ASAP, as I'm using Live to test OpenStack, and
> this is a major blocker to me. I probably will attempt to fix it myself
> and NMU the package with no delay if you're fine with that, however,

So far you haven't even proven that the problem is in live-boot so
please don't be too hasty.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#882463: Wheezy update of xrdp?

[Raphael Hertzog]

Hello Dominik,

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of xrdp:
https://security-tracker.debian.org/tracker/CVE-2017-16927

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of xrdp updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#882372: Wheezy update of ohcount?

[Raphael Hertzog]

Hello Sylvestre,

The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of ohcount:
https://security-tracker.debian.org/tracker/CVE-2017-16926

Would you like to take care of this yourself?

I tried to file an upstream bug as a first step (since there is not patch
available yet) but there is no upstream bug tracker apparently... and last
upstream activity dates back to 2010.  I pinged the project owner on
sourceforge with its integrated messaging feature but I'm not sure that I
will get any reply back.

Do you have contacts with the upstream authors ?

In any case, if you want to handle the wheezy upload, then
please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of ohcount updates
for the LTS releases.

Thank you very much.

Raphaël Hertzog,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#880902: RC bug on zfs-linux that has to be fixed

[Raphael Hertzog]

Hello,

This bug should be quickly fixed because ZFS is broken in Debian
Testing right now, spl-linux migrated already and zfs-linux did not
migrate due to this bug.

Someone reported this problematic mismatch in Kali (which is based on
Debian testing):
https://bugs.kali.org/view.php?id=4351

Adding the required header is rather easy so I hope that a maintainer
can take care of preparing the required update.

Given that both packages are tightly coupled, you should consider
adding more tight dependencies as well so that this does not happen
again in the future.

Thank you!
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#880409: python-django: add Breaks: openstack-dashboard (<< 3:12)

[Raphael Hertzog]

Hi,

On Tue, 31 Oct 2017, Chris Lamb wrote:
> > Oh, #867254 was only filed for the "trivial" case in sid. But the
> > problem also occurs on upgrades from stretch (openstack-dashboard gets
> > triggered after python-django was upgraded and blows up), which is the
> > case we need the Breaks for.
> > 
> > https://piuparts.debian.org/stretch2buster/fail/openstack-dashboard_None.log
> 
> Perhaps I'm missing something, but isn't there a solution in
> openstack-dashboard itself? (Pre-Depends...?)
> 
> Again, it just feels really wrong to fix it here..

FWIW, it doesn't look wrong to me. Any big package with an evolving API
usually ends up with Breaks like these. Have a look at dpkg for
instance...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

[Raphael Hertzog]

Hello Kurt,

On Fri, 22 Sep 2017, Kurt Roeckx wrote:
> I have to admit that I didn't consider derivatives that take a
> snapshot of testing, and we also seem to have a large amount of
> people that do use testing. My intention was to target the more
> advanced users, and having it in testing might be affecting more
> people than I thought.
> 
> So I am considering to only disable it in unstable and not in
> testing.

Any progress on this?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#879002: Should the package be removed?

[Raphael Hertzog]

Source: libpam4j
Severity: serious

Hello,

I just came across libpam4j while handlinge CVE-2017-12197 and I noticed
that:
- the package has not seen an update since 2012
- the package has no reverse dependency in Debian
- upstream seems to have disappeared (the current Homepage URL is dead
  and I could not find any other upstream code repository)

So I would suggest to drop this package from Debian. If you agree, please
reassign the bug to ftp.debian.org and retitle it into "RM: libpam4j --
ROM; unmaintained, no reverse dependency"

Thank you.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#879001: CVE-2017-12197: libpam4j: Account check bypass

[Raphael Hertzog]

Source: libpam4j
Version: 1.4-2
Severity: grave
Tags: security

Hi,

the following vulnerability was published for libpam4j.

CVE-2017-12197[0]: libpam4j: Account check bypass

PAM.authentication() does not call pam_acct_mgmt(). As a consequence, the
PAM account is not properly verified. Any user with a valid password but
with deactivated or disabled account is able to log in.

https://bugzilla.redhat.com/show_bug.cgi?id=1503103

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-12197
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12197

Please adjust the affected versions in the BTS as needed.



-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#870873: exiv2: FTBFS: some symbols or patterns disappeared in the symbols file

[Raphael Hertzog]

On Sat, 05 Aug 2017, Jakub Wilk wrote:
> exiv2 FTBFS on i386:

And on amd64 currently too:
   dh_makeshlibs -O--parallel -O--buildsystem=cmake
dpkg-gensymbols: avertissement: certains nouveaux symboles sont apparus dans le 
fichier des symboles : Veuillez consulter le fichier de différences ci-dessous
dpkg-gensymbols: avertissement: certains symboles ou motifs ont disparu du 
fichier des symboles : Veuillez consulter le fichier de différences ci-dessous
dpkg-gensymbols: avertissement: debian/libexiv2-26/DEBIAN/symbols ne correspond 
pas complètement à debian/libexiv2-26.symbols
--- debian/libexiv2-26.symbols (libexiv2-26_0.26-1_amd64)
+++ dpkg-gensymbolsp9ehnh   2017-09-26 15:54:10.161285312 +
@@ -465,16 +465,20 @@
  
_ZN5Exiv213parseRationalERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERb@Base
 0.25
  
_ZN5Exiv213pathOfFileUrlERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 0.25
  _ZN5Exiv213plusImageTypeE@Base 0.26
- 
_ZN5Exiv213toBasicStringIcA10_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
- 
_ZN5Exiv213toBasicStringIcA13_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
+#MISSING: 0.26-1# 
_ZN5Exiv213toBasicStringIcA10_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
+#MISSING: 0.26-1# 
_ZN5Exiv213toBasicStringIcA13_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
  
_ZN5Exiv213toBasicStringIcA14_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
  
_ZN5Exiv213toBasicStringIcA15_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
- 
_ZN5Exiv213toBasicStringIcA32_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
+#MISSING: 0.26-1# 
_ZN5Exiv213toBasicStringIcA32_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
  
_ZN5Exiv213toBasicStringIcA4_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
+ 
_ZN5Exiv213toBasicStringIcA59_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26-1
  
_ZN5Exiv213toBasicStringIcA5_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26
+ 
_ZN5Exiv213toBasicStringIcA7_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26-1
+ 
_ZN5Exiv213toBasicStringIcA9_cEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26-1
  
(optional=templinst)_ZN5Exiv213toBasicStringIcNS_8Internal5IfdIdEEENSt7__cxx1112basic_stringIT_St11char_traitsIS5_ESaIS5_EEERKT0_@Base
 0.26
  
(optional=templinst)_ZN5Exiv213toBasicStringIcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS2_IT_S3_IS7_ESaIS7_EEERKT0_@Base
 0.26
  
(optional=templinst)_ZN5Exiv213toBasicStringIcPKcEENSt7__cxx1112basic_stringIT_St11char_traitsIS5_ESaIS5_EEERKT0_@Base
 0.26
+ 
_ZN5Exiv213toBasicStringIcPcEENSt7__cxx1112basic_stringIT_St11char_traitsIS4_ESaIS4_EEERKT0_@Base
 0.26-1
  
(optional=templinst)_ZN5Exiv213toBasicStringIciEENSt7__cxx1112basic_stringIT_St11char_traitsIS3_ESaIS3_EEERKT0_@Base
 0.26
  
(optional=templinst)_ZN5Exiv213toBasicStringIclEENSt7__cxx1112basic_stringIT_St11char_traitsIS3_ESaIS3_EEERKT0_@Base
 0.26
  
(optional=templinst)_ZN5Exiv213toBasicStringIcmEENSt7__cxx1112basic_stringIT_St11char_traitsIS3_ESaIS3_EEERKT0_@Base
 0.26
@@ -3137,8 +3141,9 @@
  
(optional=templinst)_ZN5Exiv28stringToIfEET_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERb@Base
 0.26
  
(optional=templinst)_ZN5Exiv28stringToIjEET_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERb@Base
 0.26
  
(optional=templinst)_ZN5Exiv28stringToIlEET_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERb@Base
 0.26
- 
_ZN5Exiv28toStringIA4_cEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26
- 
_ZN5Exiv28toStringIA9_cEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26
+ 
_ZN5Exiv28toStringIA37_cEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26-1
+#MISSING: 0.26-1# 
_ZN5Exiv28toStringIA4_cEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26
+#MISSING: 0.26-1# 
_ZN5Exiv28toStringIA9_cEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26
  
(optional=templinst)_ZN5Exiv28toStringIPKhEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26
  
(optional=templinst)_ZN5Exiv28toStringIPhEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26
  
(optional=templinst)_ZN5Exiv28toStringISt4pairIiiEEENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKT_@Base
 0.26
@@ -3718,7 +3723,7 @@
  _ZNK5Exiv215StringValueBase6toLongEl@Base 0.25
  _ZNK5Exiv215StringValueBase7toFloatEl@Base 0.25
  
_ZNK5Exiv215XmpPropertyInfoeqERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 0.25
- 
_ZNK5Exiv222LangAltValueComparatorclERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_@Base
 0.26
+#MISSING: 0.26-1# 

Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

[Raphael Hertzog]

Hi,

On Thu, 21 Sep 2017, Sebastian Andrzej Siewior wrote:
> The changes Kurt asked about is something that openssl upstream supports
> and is something that openssl 1.1 considers the right way of doing
> things (in contrast to the disable TLS-version X thingy which are marked
> deprecated or going to…).

Why has it been implemented as a Debian specific patch then?

I don't think that upstream planned to deprecate TLS 1.0 and TLS 1.1
at this point yet. Yes, there are methods to control which TLS versions
you accept to use but those are optional and the default is to accept
all TLS versions and this default effectively changed in Debian, forcing
all applications to add code to re-enable all TLS versions.

> So what problems do those users see? If the package lacks 1.2 support
> then it should be reported & fixed. If the package requries <1.2 support
> because the remote side can't be changed then this should reported and
> patched as well.

I think the discussions has been rather clear on the fact that the remote
side is not always patchable (old android versions which are not
getting updates, etc.).

> since it is unlikely that things change here. Also it is unwise to make
> such a change two days before the release of Buster. *Now* we have the
> time to act.

buster should not ship with TLS 1.0 and TLS 1.1 disabled.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

[Raphael Hertzog]

Hi Kurt,

On Fri, 22 Sep 2017, Kurt Roeckx wrote:
> I have to admit that I didn't consider derivatives that take a
> snapshot of testing, and we also seem to have a large amount of
> people that do use testing. My intention was to target the more
> advanced users, and having it in testing might be affecting more
> people than I thought.
> 
> So I am considering to only disable it in unstable and not in
> testing.

Thank you!

> I'm actually surprised how few things broke.

When an app outside of Debian breaks when trying to connect to a
service running on a Debian machine, it's unlikely that said users
will report it back to Debian... it's a long chain.

Also servers will run stable and the large impact will only be noticeable
once this reaches stable.

On Fri, 22 Sep 2017, Kurt Roeckx wrote:
> On Mon, Sep 11, 2017 at 11:33:22AM +0200, Raphaël Hertzog wrote:
> > Or at least I would like a system-wide flag (in a configuration file?) to
> > let me re-enable old protocols easily.
> 
> It was my understanding that other people also prefered to do this
> on a per package level and not system wide.

I don't see why this would be mutually exclusive. We should be able to
control the system-wide default and override the values for specific
services too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#876093: openvas-libraries FTBFS on amd64: override_dh_auto_configure failed

[Raphael Hertzog]

Control: tag -1 + patch

Hello,

On Mon, 18 Sep 2017, SZ Lin wrote:
> CMake Error at nasl/CMakeLists.txt:147 (add_library):
> Target "openvas_nasl_shared" links to item " -lpcap" which has leading or
> trailing whitespace. This is now an error according to policy CMP0004.
> 
> This issue is caused by libpcap-dev [1], and the following patch could
> solve this issue.
> [1] 
> https://anonscm.debian.org/cgit/users/rfrancoise/libpcap.git/commit/?id=95f3623920effd288b7add3e8d2f0092c5bb46a6
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 033d122..71deefc 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -212,6 +212,7 @@ if (NOT OPENVAS_OMP_ONLY)
>  execute_process (COMMAND pcap-config --cflags
>OUTPUT_VARIABLE PCAP_CFLAGS
>OUTPUT_STRIP_TRAILING_WHITESPACE)
> +string(STRIP "${PCAP_LDFLAGS}" PCAP_LDFLAGS)
>else (PCAP_CONFIG)
>  message (STATUS "pcap-config not found, using defaults...")
>  set (PCAP_LDFLAGS "-L/usr/lib -lpcap")
> 
> Any feedback on it?

No, looks good. Feel free to push the fix to git and to submit it
upstream.

Thank you.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

[Raphael Hertzog]

On Mon, 11 Sep 2017, Philipp Kern wrote:
> https://packages.qa.debian.org/o/openssl/news/20170824T211015Z.html seems to
> have pushed this onto client applications? I.e. it's no longer hard disabled
> but client applications need to explicitly enable them?

Yes, I'm aware of that but Kurt never said that he would be willing to
back off from completely disabling it before the buster release and
I don't see any benefit in modifying all server applications to re-enable
the protocols that we want to support out-of-the box because there 
are (outside of Debian) old applications that will have to connect to
those servers.

I understand we need to fix the client applications that we ship in Debian
so that they work with TLS 1.2-only servers and for this it might be
useful to disable TLS 1.0 and TLS 1.1 by default in unstable for a while.

But in Debian testing, we have real end-users (direct and through
"rolling" derivatives) and they should not have to be impacted by this
experiment IMO.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#873718: Fixes for security vulnerabilities on libgig?

[Raphael Hertzog]

[ Copy to the Debian bugtracker ]

Hello Christian,

a few security issues have been reported against libgig:
http://seclists.org/fulldisclosure/2017/Aug/39

The reproducer files are attached too:
http://seclists.org/fulldisclosure/2017/Aug/att-39/poc_zip.bin

I wanted to check that you were aware of those issues and if
you had any patch already. I could not find any bug tracker
with open issues so I'm writing to you directly. The subversion
repository has no recent history related to those issues either.

Thank you!
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#873718: Multiple security issues (CVE-2017-12950 to CVE-2017-12954)

[Raphael Hertzog]

Source: libgig
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: grave
Tags: security

Hi,

the following vulnerabilities were published for libgig. See
http://seclists.org/fulldisclosure/2017/Aug/39 for the initial report
with reproducer files.

CVE-2017-12950[0]:
| The gig::Region::Region function in gig.cpp in libgig 4.0.0 allows
| remote attackers to cause a denial of service (NULL pointer
| dereference and application crash) via a crafted gig file.

CVE-2017-12951[1]:
| The gig::DimensionRegion::CreateVelocityTable function in gig.cpp in
| libgig 4.0.0 allows remote attackers to cause a denial of service
| (stack-based buffer over-read and application crash) via a crafted gig
| file.

CVE-2017-12952[2]:
| The LoadString function in helper.h in libgig 4.0.0 allows remote
| attackers to cause a denial of service (NULL pointer dereference and
| application crash) via a crafted gig file.

CVE-2017-12953[3]:
| The gig::Instrument::UpdateRegionKeyTable function in gig.cpp in
| libgig 4.0.0 allows remote attackers to cause a denial of service
| (invalid memory write and application crash) via a crafted gig file.

CVE-2017-12954[4]:
| The gig::Region::GetSampleFromWavePool function in gig.cpp in libgig
| 4.0.0 allows remote attackers to cause a denial of service (invalid
| memory read and application crash) via a crafted gig file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12950
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12950
[1] https://security-tracker.debian.org/tracker/CVE-2017-12951
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12951
[2] https://security-tracker.debian.org/tracker/CVE-2017-12952
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12952
[3] https://security-tracker.debian.org/tracker/CVE-2017-12953
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12953
[4] https://security-tracker.debian.org/tracker/CVE-2017-12954
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12954

Please adjust the affected versions in the BTS as needed.


-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/