Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

[Romain Francoise]

tcpdump has no special handling of TZ, it just calls strftime() which
handles TZ as described in strftime(3).

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1067056: libpcap0.8: man page gives incorrect syntax specification for 'proto ICMP'

[Romain Francoise]

Hi,

On Sun, Mar 17, 2024 at 7:45 PM  wrote:
> From the pcap-filter man page:
[...]
> > tcp, udp, icmp
> >   Abbreviations for:
> >proto \protocol
[...]
> I was stumped. I could not work out why my usage was syntactically
> incorrect. I had to get support from someone who suggested simply
> removing “proto”. That worked. But according to the man page my
> original attempt should have also worked.

No, the backslash character in the example is significant and you did
not provide it. What you were looking for is either 'icmp', 'ip proto
1' or 'ip proto \icmp' which are equivalent.

'proto \icmp' also works but generates support code for IPv6 as well
which does not really make sense for ICMP and is likely not what you
wanted.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1064363: Keep tmux 3.4 out of testing for now

[Romain Francoise]

Package: tmux
Version: 3.4-1
Severity: serious

tmux 3.4 has a few regressions that I would like to have fixed before
the package is allowed to migrate to testing.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1064039: Unexpected string when using tmux with rxvt-unicode

[Romain Francoise]

Hi,

On Fri, Feb 16, 2024 at 10:42 AM Karine Crévecœur  wrote:
> I encounter a strange behaviour when I use tmux in rxvt-unicode since
> the version 3.4-1.

Yes, this is a bug in rxvt-unicode's support of OSC commands that is
exposed by tmux 3.4. There's an upstream fix here:

https://github.com/exg/rxvt-unicode/commit/417b540d6dba67d440e3617bc2cf6d7cea1ed968

I'll reassign this bug to rxvt-unicode.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1063938: closed by Philip Chung (Re: Bug#1063938: tmux: Does not automatically set mode-keys to vi based on VISUAL or EDITOR environment)

[Romain Francoise]

On Thu, Feb 15, 2024 at 04:21:03PM +, Philip Chung  wrote:
> The original behavior I reported seems to come from how I invoked
> tmux, which was actually through xfce4-terminal ("xfce4-terminal -x
> tmux"), and for some reason the EDITOR variable I export in .bashrc is
> not being set there for tmux to read. When I start a new tmux server
> from a shell with the variable set, mode-keys is set to vi as
> expected.

In that situation xfce4-terminal executes tmux directly, it's not going
through your shell at all. You can however use the trick of running
`bash -c tmux` or similar to force tmux to be launched from a shell, if
that helps.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1063938: tmux: Does not automatically set mode-keys to vi based on VISUAL or EDITOR environment

[Romain Francoise]

Hi,

On Thu, Feb 15, 2024 at 8:48 AM Philip Chung  wrote:
> The mode-keys option is no longer being set to vi based on the EDITOR
> environment variable.

Seems to work fine for me. How are you exporting the environment variable?

% unset EDITOR
% tmux -S /tmp/tmux-test -f /dev/null new -d \; show -g mode-keys \; kill-server
mode-keys emacs
% export EDITOR=/usr/bin/vi
% tmux -S /tmp/tmux-test -f /dev/null new -d \; show -g mode-keys \; kill-server
mode-keys vi
%

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1063838: tmux: new upstream released: tmux 3.4

[Romain Francoise]

Hi,

Yes, I am aware of it and will update the package later today, in sid.

On Tue, Feb 13, 2024 at 1:33 PM Yukiharu YABUKI  wrote:
> If you enable '--enable-sixel', I'd happy to use the feature.

If you want to try it, the tmux package in experimental is very close
to 3.4 and has had Sixel enabled for a few months already.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1063237: tmux: crash when pasting into dead pane

[Romain Francoise]

Fix merged upstream:

https://github.com/tmux/tmux/commit/4bdb855020d266ea0a480a53e13c806fcaad9b45

And tmux 3.4 is also out, so it'll be part of that upload.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1063237: tmux: crash when pasting into dead pane

[Romain Francoise]

Hi,

On Mon, Feb 5, 2024 at 9:15 PM Jakub Wilk  wrote:
> #0  0xf7ea662b in bufferevent_write (bufev=0x0, data=0x5745f730, size=1) at 
> ./bufferevent.c:454
> #1  0x5659d0a6 in cmd_paste_buffer_exec (self=0x57442f20, item=0x574751d0) at 
> ./cmd-paste-buffer.c:98
> [...]

Thank you for reporting this issue. The fix is straightforward enough
and I've submitted here:

 https://github.com/tmux/tmux/pull/3830

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1055257: tcpdump fails to change ownership of savefile if built with libcap-ng

[Romain Francoise]

Hi,

On Thu, Nov 2, 2023 at 11:21 PM Alex Kompel  wrote:
> If the binary is built with lipcap-ng, tcpdump fails with "Couldn't change 
> ownership of savefile". If HAVE_LIBCAP_NG is defined, chown is called after 
> CAP_CHOWN capability is dropped.
> I believe this is caused by the recent patch introduced as part of 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935112 : 
> https://salsa.debian.org/rfrancoise/tcpdump/-/blob/master/debian/patches/drop-privs-after-opening-savefile.diff

Can you tell me more about the use case for building with libcap-ng?

(For the record, the patch referenced above was introduced in 2019,
it's not recent.)

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1048011: rcs: Fails to build source after successful build

[Romain Francoise]

Hi,

On Mon, Aug 14, 2023 at 1:18 AM Lucas Nussbaum  wrote:
> This package fails to build a source package after a successful build
> (dpkg-buildpackage ; dpkg-buildpackage -S).
[...]
> > dpkg-source: info: local changes detected, the modified files are:
> >  rcs-5.10.1/man/REL
> >  rcs-5.10.1/man/ci.1
> >  rcs-5.10.1/man/co.1
> >  rcs-5.10.1/man/ident.1
> >  rcs-5.10.1/man/merge.1
> >  rcs-5.10.1/man/rcs.1
> >  rcs-5.10.1/man/rcsclean.1
> >  rcs-5.10.1/man/rcsdiff.1
> >  rcs-5.10.1/man/rcsfile.5
> >  rcs-5.10.1/man/rcsfreeze.1
> >  rcs-5.10.1/man/rcsmerge.1
> >  rcs-5.10.1/man/rlog.1

Yes, building the package regenerates various source files like the
man and info pages, changing timestamps compared to the version
shipped in the upstream tarball. Building out-of-tree (with
--builddir) avoids some of those changes but not all, and I don't
think this is worth spending a lot of time on. It's been like this for
many years and nobody ever cared.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1043196: tmux: Manpages are broken because of unnecessary utf8 characters

[Romain Francoise]

Hi,

This doesn't seem to be specific to tmux and I don't want to carry a
patch for ever escaping the hyphens. I'll just merge this report with
the original one in groff-base for now.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1035842: Namespaces: Operation not permitted. Fails to setgroups due to EPERM

[Romain Francoise]

On Wed, May 10, 2023 at 7:12 AM Tj  wrote:
> When working with user namespaces tcpdump fails. Upstream has several
> open issues and at least one pull request for this since 2019.
>
> https://github.com/the-tcpdump-group/tcpdump/pull/812

Thank you. Yes, this patch seems sensible, I'll pick it up.

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

[Romain Francoise]

As per discussion with Niels, reopening to keep as a beacon to guide
others to the links above.

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

[Romain Francoise]

Hi,

On Sat, Jul 15, 2023 at 9:38 PM Niels Thykier  wrote:
> This is #1031695, which was closed and archived (marking it hard for
> people to see this is a known item). [...]

Thank you. I was unaware of the previous discussion, and my favorite
search engine was as well.

I'll forcemerge this bug with the original one.

Cheers,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

[Romain Francoise]

Package: debhelper
Version: 13.11.4
Severity: normal

I'm working on packaging a new upstream project which installs a number
of systemd units directly to /usr/lib/systemd/system and I noticed that
dh_installsystemd doesn't add the required maintscript stanzas to enable
these units.

If I patch the upstream build system to install the units under
/lib/systemd/system (which is the same location on a real system, but
not in the .deb) then everything works as expected.

Thanks.

Bug#1038269: tmux: server exits unexpectedly with libtinfo6 from experimental

[Romain Francoise]

On Sat, Jun 17, 2023 at 11:57 AM Sven Joachim  wrote:
> I had a look myself already, and it is definitely not a trivial task.
> Commit 8f34504736 gave me various conflicts, and so I decided to go down
> the easy route and try the Arch Linux patch first, you can find the
> result on [1].  I have split the Arch Linux patch into three again,
> following the naming convention in debian/patches, but not done any code
> review as I am not familiar with tmux at all.

Ah, but I was pretty much done already. Sorry for the duplicated
effort! And thank you for caring about your downstream packages :-)

As insurance against any backporting side effects, I'm uploading a Git
snapshot to experimental as well.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1038269: tmux: server exits unexpectedly with libtinfo6 from experimental

[Romain Francoise]

Hi Sven,

On Fri, Jun 16, 2023 at 10:27 PM Sven Joachim  wrote:
> People have reported server crashes with recent ncurses when copying
> text with the mouse, see the upstream bug report above and
> https://bugs.archlinux.org/task/78584.

Thank you for letting me know. I had somehow missed these discussions
in the tmux upstream bug tracker.

> The Arch Linux maintainer seems to have backported the upstream fixes,
> see https://gitlab.archlinux.org/archlinux/packaging/packages/tmux.
> I'll have at look at these in the next few days if nobody beats me to
> it.

I will take care of doing the backports later today and compare my
work with the Arch Linux package.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1035661: libpcap0.8: Manpages pcap-tstamp(7) and pcap-savefile(5) not installed

[Romain Francoise]

Hi,

On Sun, May 7, 2023 at 11:54 AM Thierry Rascle  wrote:
> I see that in 2009, bug #527599 triggered the move of pcap-filter(7)
> from libcap0.8-dev to libcap0.8. I think the same should be done for
> pcap-savefile(5) and pcap-tstamp(7).

Makes sense. I will do that in the next upload. Thanks for the suggestion.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1035663: ITP: foomuuri -- multizone bidirectional nftables firewall

[Romain Francoise]

Package: wnpp
Severity: wishlist
Owner: Romain Francoise 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: foomuuri
  Version : 0.18
  Upstream Contact: "Kim B. Heino" 
* URL : https://github.com/FoobarOy/foomuuri
* License : GPL-2.0
  Programming Lang: Python
  Description : multizone bidirectional nftables firewall

  Foomuuri is a firewall generator for nftables based on the concept
  of zones. It is suitable for all systems from personal machines to
  corporate firewalls, and supports advanced features such as a rich
  rule language, IPv4/IPv6 rule splitting, dynamic DNS lookups, a
  D-Bus API and firewalld emulation for NetworkManager's zone
  support.

Bug#1032298: tcpdump: apparmor blocks writing to stdout/stderr in lxd container [PATCH]

[Romain Francoise]

Hi,

On Fri, Mar 3, 2023 at 9:45 AM Gianfranco Costamagna
 wrote:
> +  # allow printing to stdout/stderr when inside a container
> +  # (LP: #1667016)
> +  /dev/pts/* rw,

Thank you for reporting this issue, and the patch. While the change is
indeed trivial, giving unfettered rw access to /dev/pts/* it is a high
price to pay in terms of weakening the sandbox for an uncommon use
case. With access to /dev/pts, an attacker can access SSH sessions and
other terminals.

Is there any way this could be fixed on the LXD side, or made more restrictive?

Regards,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1034086: tcpdump: CVE-2023-1801

[Romain Francoise]

Consequently I'm going to mark this bug as fixed in 4.9.3-1, which was
the first version to disable the SMB code in Debian (in 2019).

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1034086: tcpdump: CVE-2023-1801

[Romain Francoise]

Hi Salvatore,

On Sat, Apr 8, 2023 at 1:51 PM Salvatore Bonaccorso  wrote:
> The following vulnerability was published for tcpdump.
>
> CVE-2023-1801[0]:
> | The SMB protocol decoder in tcpdump version 4.99.3 can perform an out-
> | of-bounds write when decoding a crafted network packet.

Thanks. Just in case, I will mention that the SMB printer code is
*not* enabled in Debian anymore. None of the supported distributions
(oldstable, stable, testing/sid) are affected.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#962695: iftop resolves all IPv6 addresse to the same hostname

[Romain Francoise]

On Fri, Feb 24, 2023 at 10:18 PM Markus Koschany  wrote:
> Sure, if it helps.

Thank you.

Bug#962695: iftop resolves all IPv6 addresse to the same hostname

[Romain Francoise]

On Fri, Jun 12, 2020 at 12:31:14PM +0300, Harald Hannelius wrote:
> When running iftop on a server with serveral IPv6-connections ongoing,
> iftop seems to resolve the ip-addresses to the same hostname. This is a
> bit confusing. By pressing 'n' to get numerical output everything looks 
> correct.

Yes, this is very annoying. It looks like this might have been fixed by
this upstream commit:
https://code.blinkace.com/pdw/iftop/-/commit/35af3cf65f17961d173b31fd3b00166ec095c226

If so, can we have it in a new upload targeted at bookworm?

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1030733: shorewall: "shorewall6 start" gives bash error message: "[: 64: unexpected operator" if "ip addr show" has "metric" information

[Romain Francoise]

On Sat, Feb 11, 2023 at 03:37:00PM +, Jeremy Sowden wrote:
> My inclination is just to use awk to pick out the second field.  For
> example,
>
>   $ ip -f inet6 addr show dev lo | awk '$1 == "inet6" { print $2 }'
>   ::1/128

Yes. Although all this parsing of `ip' output is fraught with danger,
ideally Shorewall would use the JSON version (but that requires a
dependency on `jq' or similar)...

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1030898: please enable rdma support

[Romain Francoise]

Thanks for the suggestion. So far I've resisted adding extra binary
dependencies to libpcap and this seems like a very specialized use
case.

Bug#1029403: shorewall: fails to start with "Couldn't load match `iface':No such file or directory"

[Romain Francoise]

On Thu, Jan 26, 2023 at 09:47:07PM +0200, Vincas Dargis wrote:
> Wait a minute, why there's two bug reports? Yes, I believe the core
> issue should be in xtables.

Do you mind if I merge them?

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#986152: Offer of help

[Romain Francoise]

Now finally uploaded! (And it didn't go through NEW.)

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1029403: shorewall: fails to start with "Couldn't load match `iface':No such file or directory"

[Romain Francoise]

Hi,

Isn't this already tracked as #973990?

There is something specific to your setup because I can assure you that
Shorewall generally works in sid. Please provide more information.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#986152: Offer of help

[Romain Francoise]

On Sun, Jan 22, 2023 at 02:08:41PM +, Jeremy Sowden wrote:
> Agreed.  Not sure what the thinking was (those changes were initially
> made in April, '21).  I think we can then remove the shorewall.postinst
> and shorewall6.postinst scripts completely.

Ok, I will do that in the next few days.

Thanks,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#986152: Offer of help

[Romain Francoise]

On Sat, Jan 21, 2023 at 10:47:12AM -0500, Roberto C. Sánchez wrote:
> Whenever a source package produces a new binary package, whether that
> package exists in the archive already or not, it will land in NEW.

Ah, makes sense. Thanks.

Experimental it is, then. :-)

Bug#986152: Offer of help

[Romain Francoise]

I noticed while testing that you removed the '--no-start' argument to
dh_installinit calls in the unified package, and that's not right, as
README.Debian documents.

The situation is even a bit more complex:

 * shorewall.postinst and shorewall6.postinst source the config file in
   /etc/default and just exit if 'startup' is not 1. So the postinst bits
   added by debhelper don't get executed at all, even though they exist.
 * shorewall-init.postinst is fully generated by debhelper and does not
   have this logic, so it enables and starts the shorewall-init service
   which by default refuses to start ("ERROR: No products configured"),
   leaving a failed systemd service behind.

I think we should call dh_installinit with '--no-enable --no-start'.

Also, the systemd services don't honor the 'startup' variable in
/etc/default/shorewall{,6} at all, so it feels wrong for the postinst
scripts to act differently based on it.

Bug#986152: Offer of help

[Romain Francoise]

On Fri, Jan 20, 2023 at 05:18:19PM -0500, Roberto C. Sánchez wrote:
> I think that the bug is actually assigned to the shorewall-doc binary
> package, not the shorewall-doc source package. Assuming that the
> shorewall source package will start to emit a shorewall-doc binary
> package, I think that the BTS will do the right thing and leaving the
> bug assigned to shorewall-doc is correct.

That's my understanding as well.

Bug#986152: Offer of help

[Romain Francoise]

On Fri, Jan 20, 2023 at 11:59:44AM +, Jeremy Sowden wrote:
> The Developer's Reference, § 5.6.1, expresses the preference that when
> new binary packages are added to a source package, it should be
> uploaded to experimental, so I've updated the version and distribution
> in the change-log entry accordingly.

But these are not *new* binary packages, so I don't think the upload
will go through NEW. In fact, I hope it won't because there's still the
freeze to consider and I'd really like the new package to be in
bookworm.

Bug#986152: Offer of help

[Romain Francoise]

Hi Jeremy,

On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden  wrote:
> I've pushed all the work to my repo on Salsa:
>
>   https://salsa.debian.org/azazel/shorewall
>
> Do you want to review it before I push to the shorewall-team repo?

It all looks pretty good to me! In fact, it's a radical improvement
over the previous packaging with seven source packages.

I've been staring at the diffoscope output for a few hours and I was
wondering why /etc/network/if-down.d/shorewall seemed to disappear in
shorewall-init but that's actually an upstream change from
5.2.5-beta1. All the other cleanups and changes look sensible to me,
especially the removal of the debconf bits.

I have not yet actually tested the packages in my lab but please feel
free to push your changes to the team repo, and I will do the final
testing and upload over the week-end. I can also take care of opening
the bugs to have the previous source packages removed from unstable.

Thanks again for the huge amount of work you put in!

> The 5.2.8 source package closes the following bugs:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852

Awesome.

> In addition, I think these are candidates for manual closure:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217

Yup. You already marked #928912 as fixed, so nothing more to do there.

Bug#986152: Offer of help

[Romain Francoise]

Hi,

Replying to the latest messages in the thread in one go...

On Sun, Jan 08, 2023 at 02:35:17PM +, Jeremy Sowden wrote:
> I've created a Shorewall team on tracker.d.o and added you both to it.

Thanks!

On Mon, Jan 09, 2023 at 08:51:54AM -0500, Roberto C. Sánchez wrote:
> For a bit of historical context, the current multi-branch structure from
> the SF repo is quite antiquiated.  It is from a time before debhelper
> supported multiple .orig.tar.gz components.  It might make sense to
> consider starting with a new repo, with a more sensible branch
> structure (one that works more easily with tools like gbp), and that
> makes use of the multi-tarball capabilities so that you have have all
> the source packages in view at the same time.

That would be simpler indeed. The only worry is that it probably means
going through NEW very close to freeze... but on the other hand it eases
maintenance for the next few years in stable.

On Mon, Jan 09, 2023 at 08:48:38AM -0500, Roberto C. Sánchez wrote:
> My needs have been evolving the last few years and I have much less of a
> need for a tool like Shorewall these days.  Additionally, I have never
> used some of the advanced features (e.g., Multi-ISP, tc, accounting,
> etc.).  It would be good to have others involved in maintenance who are
> able to contribute in that way.

FWIW, I use the Multi-ISP feature.

> I'd like to mention that there is already a Gitlab group for upstream
> Shorewall work (which has been essentially dormant for some time):
> https://gitlab.com/shorewall
>
> It might make sense to consider if there is any overlap and if any of
> the Salsa work might be better house under the Shorewall Gitlab group.

Personally, I'm not a fan of hosting Debian source on upstream
infrastructure. And Salsa provides preconfigured CI pipelines that are
very useful. (I configured them already but they didn't run because
nothing was pushed the new repo yet.)

On Sun, Jan 15, 2023 at 10:38:43AM +, Jeremy Sowden wrote:
> I've managed to coax gbp into importing 5.2.8 into one upstream branch
> with each upstream tar-ball as a subdirectory:
>
>   [azazel@ulthar:/space/azazel/work/git/repos/salsa/azazel/shorewall 
> (master>)] $ ls -1
>   debian/
>   shorewall/
>   shorewall6/
>   shorewall6-lite/
>   shorewall-core/
>   shorewall-docs-xml/
>   shorewall-init/
>   shorewall-lite/

> I'm currently working on merging the debian/ directories.

Cool! Thanks for working on this.

Bug#986152: Offer of help

[Romain Francoise]

On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden  wrote:
> I've imported my fork of Roberto's SF repo to Salsa:
>
>   https://salsa.debian.org/azazel/shorewall
>
> I haven't touched it in 18 months, so I'll give it a polish when I have
> some time, and perhaps we can use it as a starting point.

Thanks. I created a Salsa team and repo here:
https://salsa.debian.org/shorewall-team/shorewall and added you both
as co-owners.

I felt more comfortable using Roberto's original SF repo as a starting
point, and merging in your changes after review. I can do that in the
next few days, the freeze is coming up very soon and I would like to
have the new upstream in bookworm. If you have further changes please
push them to your repo.

I'll also configure the CI on Salsa to have all the usual QA tools run
automatically on each push.

Did you find a practical way to do changes across all seven source
packages at once?

Bug#986152: Offer of help

[Romain Francoise]

Hi,

[Cc'ing Roberto directly to make sure he's aware of this discussion.]

I'm also a Shorewall[6] user and while the state of the package isn't
really alarming right now, I need it to be properly maintained going
forward.

We could set up a pkg-shorewall team on Salsa and co-maintain the
packages there. Jeremy, would that work for you?

Thanks.

Bug#964985: libpcap0.8: build with rpcap support (--enable-remote)

[Romain Francoise]

Hi,

On Thu, Dec 29, 2022 at 11:42 AM Peter Vanpoucke  wrote:
> Could this get picked up? I've used a port for Linux separately before,
> but that one will no longer be maintained:
> .

I will look into it.

Thanks.

Bug#1023315: tmux: manage /etc/shells using dpkg triggers

[Romain Francoise]

Hi,

On Wed, Nov 2, 2022 at 10:51 AM Helmut Grohne  wrote:
> tmux manages its entry in /etc/shells using add-shell/remove-shell.
> Consider managing this entry declaratively instead. Since version 5.3-1,
> debianutils recognizes /usr/share/debianutils/shells.d/tmux and will add
> those shells to /etc/shells via dpkg triggers. I'm attaching a patch for
> your convenience.

Thank you for the patch. Indeed, that's a change I'm planning to make
in order to fix #939889, but it will have to wait for the new trigger
mechanism to be available in Debian stable because I maintain a
backport of tmux. So that's for after bookworm, but that's only a few
months away now.

Bug#1016475: tmux sessions do not persist through logout

[Romain Francoise]

Hi,

There’s nothing tmux can do right now about systemd killing user
sessions without lingering enabled; just run `sudo loginctl
enable-linger $USER`.

Thanks.

Bug#1011426: bullseye-pu: package tcpdump/4.99.0-2+deb11u1

[Romain Francoise]

Hi Adam,

On Sat, May 28, 2022 at 8:51 PM Adam D. Barratt
 wrote:
> Please go ahead, thanks.

Uploaded. Thanks!

Bug#1011426: bullseye-pu: package tcpdump/4.99.0-2+deb11u1

[Romain Francoise]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I would like to update the AppArmor profile for tcpdump in bullseye to
match the one in bookworm; the changes don't really qualify for a stable
update per se, but they are trivial and would be important
quality-of-life improvements for users who are not knowledgeable about
AppArmor and don't understand why they get -EPERM in some cases.

The update would fix the following bugs (both "normal"):
* "AppArmor grants access to *.pcap but not *.cap"
  https://bugs.debian.org/989433
* "apparmor profile prevents -C -W"
  https://bugs.debian.org/1010688

Full debdiff is attached.

Thanks.
diffstat for tcpdump-4.99.0 tcpdump-4.99.0

 changelog   |8 
 usr.bin.tcpdump |4 
 2 files changed, 12 insertions(+)

diff -Nru tcpdump-4.99.0/debian/changelog tcpdump-4.99.0/debian/changelog
--- tcpdump-4.99.0/debian/changelog 2021-01-15 23:41:47.0 +0100
+++ tcpdump-4.99.0/debian/changelog 2022-05-22 18:22:50.0 +0200
@@ -1,3 +1,11 @@
+tcpdump (4.99.0-2+deb11u1) bullseye; urgency=medium
+
+  * Minor AppArmor profile updates (debian/usr.bin.tcpdump):
++ Grant access to *.cap (closes: #989433).
++ Account for numerical suffix in filenames added by -W (closes: #1010688).
+
+ -- Romain Francoise   Sun, 22 May 2022 18:22:50 +0200
+
 tcpdump (4.99.0-2) unstable; urgency=medium
 
   * Add autopkgtest support, running the upstream test suite.
diff -Nru tcpdump-4.99.0/debian/usr.bin.tcpdump 
tcpdump-4.99.0/debian/usr.bin.tcpdump
--- tcpdump-4.99.0/debian/usr.bin.tcpdump   2021-01-03 21:25:50.0 
+0100
+++ tcpdump-4.99.0/debian/usr.bin.tcpdump   2022-05-22 18:19:03.0 
+0200
@@ -54,6 +54,10 @@
 
   # for -r, -F and -w
   /**.[pP][cC][aA][pP] rw,
+  /**.[cC][aA][pP] rw,
+  # -W adds a numerical suffix
+  /**.[pP][cC][aA][pP][0-9]* rw,
+  /**.[cC][aA][pP][0-9]* rw,
 
   # for convenience with -r (ie, read pcap files from other sources)
   /var/log/snort/*log* r,

Bug#1010688: apparmor profile prevents -C -W

[Romain Francoise]

Duh, thanks for the report. Not sure how this was never found despite
the profile being included since 2017 and Debian having AppArmor
enabled by default since Debian 10 (for new installs). I'll fix this
in unstable but it may not qualify for a stable upload. I'll ask.

Bug#996684: lintian: emits bogus embedded-library error for libtinfo6 package

[Romain Francoise]

On Sun, Oct 17, 2021 at 12:46:24PM +0200, Sven Joachim wrote:
> I am getting the following error in libtinfo6 (as well as in libtinfo5
> and lib{32,64}tinfo6), which according to the FTP masters leads to
> autorejection unless overridden:
>
> ,
> | $ lintian /var/cache/apt/archives/libtinfo6_6.2+20210905-1_amd64.deb
> | E: libtinfo6: embedded-library ncurses lib/x86_64-linux-gnu/libtinfo.so.6.2
> `

As noted on IRC, the same bug occurs for libpcap0.8 with libpcap.so vs.
libpcap.a.

Bug#994112: bullseye-pu: package tmux/3.1c-1+deb11u1

[Romain Francoise]

Hi Adam,

On Sat, Sep 18, 2021 at 01:30:27PM +0100, Adam D. Barratt wrote:
> Please go ahead.

Ok, uploaded. I noticed while I was doing the upload that I had left a
typo in the changelog entry and applied the following on top of the diff
you have already reviewed. Sorry about that.

Thanks!


diff -u tmux-3.1c/debian/changelog tmux-3.1c/debian/changelog
--- tmux-3.1c/debian/changelog  2021-09-11 23:24:41.0 +0200
+++ tmux-3.1c/debian/changelog  2021-09-18 15:02:56.0 +0200
@@ -1,11 +1,11 @@
 tmux (3.1c-1+deb11u1) bullseye; urgency=medium

-  * Cherry-pick commit 7a4aa14618 from upstream to fix race condition
+  * Cherry-pick commit 7a4aa14618 from upstream to fix a race condition
 which results in the config not being loaded if several clients are
 interacting with the server while it's initializing (upstream GitHub
 issue #2438, closes: #992202).

- -- Romain Francoise   Sat, 11 Sep 2021 23:24:41 +0200
+ -- Romain Francoise   Sat, 18 Sep 2021 15:02:56 +0200

 tmux (3.1c-1) unstable; urgency=medium

Bug#992949: tmix FTCBFS: AC_RUN_IFELSE

[Romain Francoise]

Actually the simple fix in upstream commit b1a8c0fe02 fixes the
cross-build since the package now builds successfully for arm64 on
amd64 in the CI job autoconfigured by Salsa templates, so I'll go with
that.

Thanks.

Bug#994112: bullseye-pu: package tmux/3.1c-1+deb11u1

[Romain Francoise]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hello,

I'm seeking permission to upload tmux/3.1c-1+deb11u1 to bullseye; it
fixes a regression which results in tmux not loading its configuration
during startup in some situations (#992202).

Full debdiff attached.

Thanks,
diffstat for tmux-3.1c tmux-3.1c

 changelog|9 +
 patches/series   |1 +
 patches/upstream-7a4aa14618.diff |   28 
 3 files changed, 38 insertions(+)

diff -Nru tmux-3.1c/debian/changelog tmux-3.1c/debian/changelog
--- tmux-3.1c/debian/changelog  2020-11-01 13:45:43.0 +0100
+++ tmux-3.1c/debian/changelog  2021-09-11 23:24:41.0 +0200
@@ -1,3 +1,12 @@
+tmux (3.1c-1+deb11u1) bullseye; urgency=medium
+
+  * Cherry-pick commit 7a4aa14618 from upstream to fix race condition
+which results in the config not being loaded if several clients are
+interacting with the server while it's initializing (upstream GitHub
+issue #2438, closes: #992202).
+
+ -- Romain Francoise   Sat, 11 Sep 2021 23:24:41 +0200
+
 tmux (3.1c-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru tmux-3.1c/debian/patches/series tmux-3.1c/debian/patches/series
--- tmux-3.1c/debian/patches/series 2020-11-01 13:45:43.0 +0100
+++ tmux-3.1c/debian/patches/series 2021-09-11 23:06:29.0 +0200
@@ -1 +1,2 @@
 platform-quirks.diff
+upstream-7a4aa14618.diff
diff -Nru tmux-3.1c/debian/patches/upstream-7a4aa14618.diff 
tmux-3.1c/debian/patches/upstream-7a4aa14618.diff
--- tmux-3.1c/debian/patches/upstream-7a4aa14618.diff   1970-01-01 
01:00:00.0 +0100
+++ tmux-3.1c/debian/patches/upstream-7a4aa14618.diff   2021-09-11 
23:06:36.0 +0200
@@ -0,0 +1,28 @@
+commit 7a4aa146187cc60d2df66333b3e7dd5a5176f793
+Author: Nicholas Marriott 
+Date:   Wed Oct 28 10:09:10 2020 +
+
+Do not require that there be no other clients before loading the config,
+being the first client is enough. GitHub issue 2438.
+
+--- a/server-client.c
 b/server-client.c
+@@ -1975,13 +1975,13 @@
+   }
+ 
+   /*
+-   * If this is the first client that has finished identifying, load
+-   * configuration files.
++   * If this is the first client, load configuration files. Any later
++   * clients are allowed to continue with their command even if the
++   * config has not been loaded - they might have been run from inside it
+*/
+   if ((~c->flags & CLIENT_EXIT) &&
+-  !cfg_finished &&
+-  c == TAILQ_FIRST() &&
+-  TAILQ_NEXT(c, entry) == NULL)
++   !cfg_finished &&
++   c == TAILQ_FIRST())
+   start_cfg();
+ }
+ 

Bug#940562: Some context

[Romain Francoise]

The Debian package used to modify upstream's Makefiles to install
rcsfreeze along with the rest of the RCS binaries. Sometime in 2012 I
dropped this patch with the following commit message:

  * Stop shipping the rcsfreeze script as upstream doesn't support it.

I don't remember if ttn (RCS upstream) specifically requested for the
Debian patch to be dropped, or if it's the result of some mailing-list
discussion. Either way I don't think there's much point in re-adding
this script, at this point it's of historical interest only.

Bug#992949: tmix FTCBFS: AC_RUN_IFELSE

[Romain Francoise]

See also these PRs for previous attempts at fixing this:

https://github.com/tmux/tmux/pull/2651
https://github.com/tmux/tmux/pull/2755

Removing the patch tag as I'm not going to apply this until it goes
through upstream first.

Bug#797780: Still happening in current tmux?

[Romain Francoise]

Does this still happen with current versions of tmux?

Thanks.

Bug#990554: tcpdump: leftover legacy configuration /etc/apparmor.d/local/usr.sbin.tcpdump

[Romain Francoise]

Hi intrigeri,

Thanks for following up, appreciate your help.

On Fri, Sep 3, 2021 at 10:12 AM intrigeri  wrote:
> Meanwhile, I'm afraid the only way to deal with such leftovers
> is via maintainer scripts, taking care of not deleting contents
> added by the user :/

Ok. Unfortunately the cat is somewhat out of the bag on this one
because the bug was released with buster and so we have millions of
systems out there with the leftover file. Their next tcpdump update
may not be before months or years, which gives users ample time to
notice and move their config to the new location... resulting in the
package having to do a three-way merge somehow.

I think I will opt for the simple solution and just check if the old
file is still present and empty, in which case it's safe to simply
remove. If it's not empty, it contains user configuration that
shouldn't be cleaned up anyway and the user needs to move it to the
new location manually.

WDYT?

Bug#992949: tmix FTCBFS: AC_RUN_IFELSE

[Romain Francoise]

Hi,

Thanks for the report. Can you submit the patch upstream through the
GitHub issue tracker? It'll be more efficient than having to push a
patch on your behalf.

Bug#992234: uninstallable; incompatible with tmux 3.2

[Romain Francoise]

Package: tmuxinator
Version: 2.0.2-1
Severity: serious

tmux 3.2a is now in sid, which makes tmuxinator uninstallable because it
is apparently incompatible and has the following Depends field:

Depends: ruby | ruby-interpreter, ruby-erubis, ruby-thor, ruby-xdg, tmux (<< 
3.2)

Please update the package to a compatible version ASAP as this will
prevent tmux from migrating to bookworm properly.

Thanks.

Bug#992202: tmux doesn't read tmux.conf upon login

[Romain Francoise]

Looks like this is upstream issue #2438:

 https://github.com/tmux/tmux/issues/2438

It was fixed on master in the 3.1b timeframe, but unfortunately the
backport was missed and the fix is not included in 3.1c.

I can probably get the fix included in a stable update. Alternatively,
tmux 3.2a will be available via bullseye-backports in the near future.

Bug#992202: tmux doesn't read tmux.conf upon login

[Romain Francoise]

Hi,

On Sun, Aug 15, 2021 at 7:54 PM Allan Wind  wrote:
> I just upgraded to bullseye and on subsequent login tmux doesn't
> appear to read tmux.conf.  This worked fine in buster.

Can you check your display manager logs (or equivalent) for an error
message that would indicate what's happening?

> The work-around is to exit all 3 instances before a subsequent
> start of tmux will read my tmux.conf file and behave as expected.

Not sure I understand what you mean here...

> I ran strace -ff tmux and I did not see an access or open of
> the tmux.conf file.

If the server is already running, that would be expected.

Bug#990554: tcpdump: leftover legacy configuration /etc/apparmor.d/local/usr.sbin.tcpdump

[Romain Francoise]

 user pkg-apparmor-t...@lists.alioth.debian.org
 usertags #990554 + help-needed
 thanks

On Fri, Jul 2, 2021 at 1:57 AM Christoph Anton Mitterer
 wrote:
> So is it tcpdump's responsibility to clean this up (manually) or should 
> debhelper
> do it (somehow ^^) automatically, i.e. also migrate the existing file
> automatically, because people might have had config in
> /etc/apparmor.d/local/usr.sbin.tcpdump which should have gotten moved to
> /etc/apparmor.d/local/usr.bin.tcpdump
>
> So maybe this needs to be reassigned to dh-apparmor.

Thank you for bringing this to my attention, I wasn't aware that the
dh_apparmor script snippets would create this file upon installation.
Technically the file isn't part of the package, so indeed it's not
clear whose responsibility it is to clean it up.

Let's add a usertag to loop in the pkg-apparmor team...

Bug#990215: tmux: Missleading error message if socket path has wrong permissions

[Romain Francoise]

Hi,

On Wed, Jun 23, 2021 at 8:57 AM Uwe Kleine-König  wrote:
> To improve this, the following patch helps: [...]

Thanks for the bug report and the patch. Can you contribute this
directly upstream? It's always a bit awkward for me to try and get
someone else's patch merged...

Bug#989433: tcpdump: -Z doesn't seem to work properly

[Romain Francoise]

Right, this is indeed about apparmor.

The apparmor profile for tcpdump grants rw access to *.pcap. You're
using a capture file named "ax0.cap", which doesn't match. I couldn't
reproduce because I was testing the same scenario with the correct
extension. I guess the simple fix would be to also grant access to
*.cap in addition to *.pcap.

And in this case, "-Z root" doesn't restore the expected behavior
because the apparmor sandbox applies to the process even when it's
running as root, so it can only open files it owns or that otherwise
match the policy.

Bug#989433: tcpdump: -Z doesn't seem to work properly

[Romain Francoise]

Hi,

On Thu, Jun 3, 2021 at 7:30 PM Dennis Boone  wrote:
> The following session was executed as root:
>
> ozymandias 179 # tcpdump -r /tmp/ax0.cap -Z root
> tcpdump: /tmp/ax0.cap: Permission denied
> ozymandias 180 # tcpdump -r /tmp/ax0.cap -Z tcpdump
> tcpdump: /tmp/ax0.cap: Permission denied
> ozymandias 181 # dir /tmp/ax0.cap
> -rw-r--r-- 1 tcpdump tcpdump 434176 jun  3 11:41 /tmp/ax0.cap
>
> Order of the "-r" and "-Z" options make no difference.

Thanks for the report. Is there anything specific to your setup that
could explain this? I can't reproduce it and as described it seems
surprising that root would get EPERM no matter what -Z option is used.
What are the mount options on /tmp? Does this file have extended
attributes?

Bug#962921: Please fix spam for bullseye

[Romain Francoise]

Hi Tiago,

apticron is scheduled for automatic removal on 04/12 and the fixed
package will not migrate because you included an arch-all binary in your
upload. Please upload a source-only version.

Thanks.

Bug#651783: libpcap0.8: libpcap should be linked with libnl

[Romain Francoise]

Hi Steev,

While the libnl landscape indeed seems to have simplified since the
last time I took a look at it, I don't think we are in a good place
right now. The last upload of libnl3 was in 2018. The packaging Git
repository has disappeared. Upstream-wise, there's a 3.5.0 release on
GitHub (picked up by Fedora), but it's not listed on the project
homepage... Not very encouraging.

There's also a known issue with the integration related to tcpdump
which now drops privileges by default and cannot delete the mon
interface it creates, leaking interfaces at each invocation.

So I won't be enabling this. I'm still of the opinion that libpcap
should do the work by itself and not require libnl.

Thanks.

Bug#976094: buster-pu: package grub2/2.02+dfsg1-20+deb10u3

[Romain Francoise]

On Mon, Jan 11, 2021 at 03:57:10PM +0100, Cyril Brulebois wrote:
> If I'm getting this right, the udeb part shouldn't be much of an issue,
> but the change regarding the fresh install vs. grub-install /could/ have
> side effects. As documented, the installer /should/ be doing the right
> thing already (via grub-installer), but checking (if only for peace of
> mind) would be best.

For the record, 2.02+dfsg1-20+deb10u3 broke a custom cloud installation
system at $work which relied on the fact that grub-pc would DTRT in its
postinst when preseeded with the device to install on. Fixing that issue
isn't particularly hard (adding the missing grub-install + mkconfig),
however I'm surprised that such a behavior change was deemed appropriate
for a stable release update.

Bug#979338: Upgrading severity

[Romain Francoise]

severity 979338 serious
quit

Upgrading severity as this is blocking migration of tcpdump 4.99 to testing.

Bug#979338: Acknowledgement (python3-scapy: hardcodes tcpdump location to /usr/sbin/tcpdump)

[Romain Francoise]

By the way, it looks like this will block migration of tcpdump 4.99.0
to testing and the freeze is coming up fast, let me know if I can help
in any way.

Bug#979338: python3-scapy: hardcodes tcpdump location to /usr/sbin/tcpdump

[Romain Francoise]

Package: python3-scapy
Version: 2.4.4-3
Severity: normal

In tcpdump 4.99.0-1, the location of the tcpdump binary was changed from
/usr/sbin/tcpdump to /usr/bin/tcpdump. This causes autopkgtest to fail
for scapy, as the path is hardcoded to the old location via this patch:

 
https://salsa.debian.org/pkg-security-team/scapy/-/raw/debian/master/debian/patches/use-absolute-paths.patch

Simply removing the patch will allow the test suite to pass again,
however you may consider versioning the dependency on tcpdump in the
autopkgtest control file to ensure that the location will match the
tcpdump version.

Note that the location change may also impact operation of Scapy itself,
in which case the severity of this bug would likely be higher than
'normal'. I have not tested this.

Thanks.

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

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

Versions of packages python3-scapy depends on:
ii  libjs-sphinxdoc  3.4.1-1
ii  python3  3.9.1-1
ii  sphinx-rtd-theme-common  0.5.0+dfsg-1

Versions of packages python3-scapy recommends:
ii  ipython3  7.19.0-3
pn  python3-cryptography  
ii  tcpdump   4.99.0-1

Versions of packages python3-scapy suggests:
pn  graphviz
pn  python3-matplotlib  
pn  python3-pyx 
pn  sox 
pn  tcpreplay   
pn  wireshark   

-- no debconf information

Bug#979229: libpcap0.8-dev: missing dependency on libdbus-1-dev causes build failures

[Romain Francoise]

Hi Luca,

On Mon, Jan 4, 2021 at 2:36 PM Luca Boccassi  wrote:
> libpcap0.8-dev sets "Libs.private: -ldbus-1" in its pkg-config file,
> but it does not have a dependency on libdbus-1-dev, causing a build
> failure in reverse dependencies that use pkg-config --static (or macro
> variations thereof).
>
> Please consider adding this dependency, so that everything works out
> of the box.

Sure, makes sense. I'll pick up your change in the next upload, thanks!

Bug#973917: buster-pu: package tcpdump/4.9.3-1~deb10u2

[Romain Francoise]

Hi Adam,

On Thu, Nov 19, 2020 at 9:31 PM Adam D. Barratt
 wrote:
> Please go ahead.

Thanks, uploaded.

Bug#973917: buster-pu: package tcpdump/4.9.3-1~deb10u2

[Romain Francoise]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hello,

I am seeking permission to upload a new version of tcpdump to
stable-proposed-updates to address CVE-2020-8037 (bug #973877).

Full debdiff attached.

Thanks,
diffstat for tcpdump-4.9.3 tcpdump-4.9.3

 changelog|7 
 patches/series   |1 
 patches/upstream-32027e1993.diff |   61 +++
 3 files changed, 69 insertions(+)

diff -Nru tcpdump-4.9.3/debian/changelog tcpdump-4.9.3/debian/changelog
--- tcpdump-4.9.3/debian/changelog  2019-10-19 16:55:18.0 +0200
+++ tcpdump-4.9.3/debian/changelog  2020-11-07 13:36:24.0 +0100
@@ -1,3 +1,10 @@
+tcpdump (4.9.3-1~deb10u2) buster; urgency=high
+
+  * Cherry-pick commit 32027e1993 from the upstream tcpdump-4.9 branch to fix
+untrusted input issue in the PPP printer (CVE-2020-8037, closes: #973877).
+
+ -- Romain Francoise   Sat, 07 Nov 2020 13:36:24 +0100
+
 tcpdump (4.9.3-1~deb10u1) buster-security; urgency=high
 
   * New upstream release, with fixes for 24 different CVEs (closes: #941698).
diff -Nru tcpdump-4.9.3/debian/patches/series 
tcpdump-4.9.3/debian/patches/series
--- tcpdump-4.9.3/debian/patches/series 2019-10-19 00:20:22.0 +0200
+++ tcpdump-4.9.3/debian/patches/series 2020-11-07 13:34:47.0 +0100
@@ -2,3 +2,4 @@
 man-section.diff
 platform-quirks.diff
 disable-tests.diff
+upstream-32027e1993.diff
diff -Nru tcpdump-4.9.3/debian/patches/upstream-32027e1993.diff 
tcpdump-4.9.3/debian/patches/upstream-32027e1993.diff
--- tcpdump-4.9.3/debian/patches/upstream-32027e1993.diff   1970-01-01 
01:00:00.0 +0100
+++ tcpdump-4.9.3/debian/patches/upstream-32027e1993.diff   2020-11-07 
13:34:39.0 +0100
@@ -0,0 +1,61 @@
+commit 32027e199368dad9508965aae8cd8de5b6ab5231
+Author: Guy Harris 
+Date:   Sat Apr 18 14:04:59 2020 -0700
+
+PPP: When un-escaping, don't allocate a too-large buffer.
+
+The buffer should be big enough to hold the captured data, but it
+doesn't need to be big enough to hold the entire on-the-network packet,
+if we haven't captured all of it.
+
+(backported from commit e4add0b010ed6f2180dcb05a13026242ed935334)
+
+diff --git a/print-ppp.c b/print-ppp.c
+index 891761728b..33fb034127 100644
+--- a/print-ppp.c
 b/print-ppp.c
+@@ -1367,19 +1367,29 @@ trunc:
+   return 0;
+ }
+ 
++/*
++ * Un-escape RFC 1662 PPP in HDLC-like framing, with octet escapes.
++ * The length argument is the on-the-wire length, not the captured
++ * length; we can only un-escape the captured part.
++ */
+ static void
+ ppp_hdlc(netdissect_options *ndo,
+  const u_char *p, int length)
+ {
++  u_int caplen = ndo->ndo_snapend - p;
+   u_char *b, *t, c;
+   const u_char *s;
+-  int i, proto;
++  u_int i;
++  int proto;
+   const void *se;
+ 
++  if (caplen == 0)
++  return;
++
+ if (length <= 0)
+ return;
+ 
+-  b = (u_char *)malloc(length);
++  b = (u_char *)malloc(caplen);
+   if (b == NULL)
+   return;
+ 
+@@ -1388,10 +1398,10 @@ ppp_hdlc(netdissect_options *ndo,
+* Do this so that we dont overwrite the original packet
+* contents.
+*/
+-  for (s = p, t = b, i = length; i > 0 && ND_TTEST(*s); i--) {
++  for (s = p, t = b, i = caplen; i != 0; i--) {
+   c = *s++;
+   if (c == 0x7d) {
+-  if (i <= 1 || !ND_TTEST(*s))
++  if (i <= 1)
+   break;
+   i--;
+   c = *s++ ^ 0x20;

Bug#973877: tcpdump: CVE-2020-8037

[Romain Francoise]

Hi,

On Fri, Nov 6, 2020 at 1:48 PM Salvatore Bonaccorso  wrote:
> The following vulnerability was published for tcpdump.
>
> CVE-2020-8037[0]:
> | The ppp decapsulator in tcpdump 4.9.3 can be convinced to allocate a
> | large amount of memory.

Thanks for the bug report. I am aware of this CVE and working on a new
upload to unstable.
Is this no-dsa?

Bug#970437: libpcap0.8: typo in manpage of pcap-filter

[Romain Francoise]

tags 970437 upstream fixed-upstream
thanks

Hi,

On Wed, Sep 16, 2020 at 1:33 PM Sven Dreyer  wrote:
> the manpage of pcap-filter contains a typo:
>
> 
> mpls [label_num]
>True  if  the  packet  is  an MPLS packet.  If [label_num] is 
> specified, only true is the packet has the specified label_num.
> 
>
> Replace "true is" with "true if".

Thanks, this appears to have been fixed already by upstream commit 5bf4977:

https://github.com/the-tcpdump-group/libpcap/commit/5bf4977df9ad36621a8959a19eb8321867947b15#diff-dd6946922849ea53e5dfa48290a566b7R697

Bug#964985: libpcap0.8: build with rpcap support (--enable-remote)

[Romain Francoise]

Hi,

On Mon, Jul 13, 2020 at 11:03 PM Lukas Tribus
 wrote:
> since libpcap 1.9, rpcap (remote-pcap) is supported [1] and can
> be enabled at build by specifying --enable-remote or in cmake
> -DENABLE_REMOTE=YES [2].
>
> Please consider enabling this for libpcap 1.9.

Thank you for the suggestion. Having rpcapd packaged for Debian and
having remote capture support in libpcap could be useful in some
situations, however I'm not sure that the code is supposed to be
production-ready just yet.

Guy, do you think it's generally safe to enable remote capture in
Debian's packaged libpcap?

Thanks,

Bug#959698: tmux: "incompatible server protocol change" does not seem acceptable

[Romain Francoise]

Hi,

On Mon, May 4, 2020 at 10:15 AM Julien Cristau  wrote:
> I don't think that's acceptable.  Running upgrades inside screen or
> tmux is a best practice, so IMO it needs to work, and people need to be
> able to re-attach to existing sessions across the upgrade.

The tmux authors make no promise about the compatibility between new
clients and old servers, and some versions break the protocol. That's
just how it is.

However: in this specific instance, I lazily copied the same NEWS
blurb I always use when the protocol version changes, but upstream
made a deliberate decision *not* to bump the protocol version this
time because the incompatibility issue in 3.1 only affects some
commands (the ones that send data on stdout from the client). It's
possible to attach to an old server from the new client and terminate
it properly, and even if that wasn't the case you could use the old
binary from /proc/pid/exe (which, as I discovered in 2012 in the bug
you linked, is not possible with screen because it's setgid).

So with that in mind, I rephrased the NEWS entry as follows:

https://salsa.debian.org/rfrancoise/tmux/-/commit/15dd27614d659b8cae53c9e5acb54d70f321fcb4

That's the best I can do about this, and I will therefore close this
bug with the upload.

Also, the entire point of adding entries like this to NEWS.Debian is
that apt-listchanges will prompt for confirmation before starting the
upgrade if it's configured properly. Perhaps that configuration should
be more widely documented and encouraged.

Thanks.

Bug#958639: libpcap0.8: libpcap should be linked with libdbus

[Romain Francoise]

Hi,

On Thu, Apr 23, 2020 at 11:00 PM Francois-Xavier Le Bail
 wrote:
> It will permit to add some interfaces to capture on, like:
>
> - dbus-system (D-Bus system bus)
> - dbus-session (D-Bus session bus)

Ok. dbus is now priority standard (and has apparently been since 2015
because of libpam-systemd), so libdbus is probably installed on the
vast majority of Debian systems out there. popcon suggests that 97.4%
of reporting systems have it installed. There is therefore probably no
harm in enabling dbus support, so I've done that in version 1.9.1-4.

Thanks.

Bug#954378: tcpdump: Support pcapng captures wiht snaplen 524288

[Romain Francoise]

I just uploaded the backport, it may take a few days before it appears
in the archive.

Bug#954378: tcpdump: Support pcapng captures wiht snaplen 524288

[Romain Francoise]

Hi,

Thanks for the report. Wireshark has its own implementation of the
PcapNg format, so it's not unexpected that it behaves differently than
tcpdump.

The fix is a bit too intrusive for a stable update, especially for a
minor bug like this. I will simply do a buster backport of libpcap
1.9.1-2 from bullseye.

Can you share your modified test file? Thanks.

Bug#954181: Please stop disabling Bluetooth monitor support in libpcap

[Romain Francoise]

Hi Guy,

On Tue, Mar 17, 2020 at 10:15 PM Guy Harris  wrote:
> Please remove this, so that people can use the bluetooth-monitor device on 
> Debian - and on its derivatives, once it trickles down to all the 
> derivatives.  I built the current master-branch versions of libpcap and 
> tcpdump on Ubuntu 18.04, and they work Just Fine, at least on my VMware 
> Fusion VM with my Mac's Bluetooth adapter turned on (they may have found some 
> problems in the Wireshark *dissector* for Bluetooth monitor messages, but 
> that's another matter).

Ok, sure, I can do that. Thanks for the heads up.

Bug#953141: tmux: Please add Suggests: ncurses-term to allow us using TERM=tmux or tmux-256color

[Romain Francoise]

Hi,

On Thu, Mar 5, 2020 at 7:45 AM Ryo IGARASHI  wrote:
> ncurses-term package contains termcap entry of tmux and tmux-256color.
> Using these entry, I can use e.g. italic which is not available using
> TERM=screen.
> However, this fact is not indicated anywhere on tmux package
> description. It would be nice to add Suggest: ncurses-term.

Good idea, I will do that. Thanks.

Bug#943648: tmux: FTBFS twice in a row: deletes cmd-parse.c which cannot be regenerated due to lack of yacc

[Romain Francoise]

Hi,

On Sun, Oct 27, 2019 at 3:21 PM Andreas Beckmann  wrote:
> The first build succeeds, but the subsequent distclean removes
> cmd-parse.c which cannot be regenerated due to yacc (bison) not being
> available.

Thanks for the report. Indeed this file is now generated and shipped
in the upstream tarball. I will add a build-depends on bison.

Bug#942315: tcpdump: Version in oldoldstable is higher than oldstable and stable

[Romain Francoise]

On Thu, Oct 17, 2019 at 10:02 AM Moritz Muehlenhoff  wrote:
> IMHO for stretch-security/buster-security we should rather rebase the old
> 4.9.2ish packages to 4.9.3, given that it creates new system users etc.
> it seems not really suitable for a security update.

Ok, that is what I did. Review welcome:

https://people.debian.org/~rfrancoise/tcpdump/tcpdump_4.9.3-1~deb10u1_source.changes
https://people.debian.org/~rfrancoise/tcpdump/tcpdump_4.9.3-1~deb9u1_source.changes

Thanks.

Bug#942315: tcpdump: Version in oldoldstable is higher than oldstable and stable

[Romain Francoise]

On Wed, Oct 16, 2019 at 9:48 PM Salvatore Bonaccorso  wrote:
> Ideally given the issues are denial of service issues, this would have
> been okay via a point release. But we discussed this coincidentally in
> the team concluding we could as well release it via security. But we
> were thinking of postponing it a bit yet to see if some bug
> reports/regression reports did appear after the unstable version was
> exposed.

Ah, okay. 4.9.3~git20190901-1 included significant packaging changes
to drop root privileges by default, is that appropriate for an upload
via security? (If so, it is my preferred avenue to reach stable users,
as point releases aren't very frequent.)

> Can you prepare updates for buster-security and stretch-security?

I don't have much free time these days but I will try to get this done
over the week-end.

Thanks.

Bug#942315: tcpdump: Version in oldoldstable is higher than oldstable and stable

[Romain Francoise]

Hi Guillem,

On Mon, Oct 14, 2019 at 3:45 PM Guillem Jover  wrote:
> With the latest upload to oldoldstable-security, the versions in
> oldstable and stable are now lower. This means that upgrades will
> not take effect for this package, which will be left built against
> libraries and packaging from oldoldstable.

Yes, the jessie-lts team kinda jumped the gun here. I think the best
way forward is to request approval for a buster-pu update of tcpdump
to 4.9.3 as well...

Salvatore, any thoughts?

Thanks.

Bug#941698: Bug#942171: tcpdump: FTBFS on ppc64el for test ikev2pI2

[Romain Francoise]

On Fri, Oct 11, 2019 at 2:06 PM Thierry fa...@linux.ibm.com
 wrote:
> This is similar to bug #873377 which was supposed to be fixed in V 4.9.1-2 - 
> logs show that for v4.9.1-2 and -3 test was not run - then it was failing but 
> not reported as an error for the global count of success !

Sigh. I re-enabled this test in 4.9.3-1 thinking that it had been
fixed, but alas no, it still fails. Will disable again...

Bug#940309: tmux: Random segfaults

[Romain Francoise]

Hi,

On Sun, Sep 15, 2019 at 2:12 PM Kamil Jonca  wrote:
> At random moments tmux segfaults, destroying all sessions.
> in dmesg we have: [...]

Thanks for the report. Can you try with 3.0-rc4 from experimental?

Bug#939889: tmux: removal followed by reinstallation uses /etc/shells entry

[Romain Francoise]

On Fri, Sep 13, 2019 at 8:07 PM Sven Joachim  wrote:
> I think that would be correct.  When filing the bug, I was worried that
> leaving the entry in /etc/shells might fool an unsuspecting user to
> chsh(1) to a non-existent program, but chsh does not actually let you do
> this (unless you are root in which case it only warns, and then
> /etc/shells is ignored anyway).

Good, thanks for checking.

> Since apparently just about everyone currently gets this wrong, I think
> it would be good to discuss it on debian-devel and file bugs against the
> affected packages when a solution is agreed upon.

Would you like to lead the charge here? My time budget for Debian is
quite limited these days...

Thanks.

Bug#939889: tmux: removal followed by reinstallation uses /etc/shells entry

[Romain Francoise]

Hi Sven,

On Mon, Sep 9, 2019 at 9:27 PM Sven Joachim  wrote:
> I guess the purpose is to preserve local configuration and give the
> local admin to the ability to remove the /usr/bin/tmux entry from
> /etc/shells.

Yes, I don't remember the details but that is apparently the intent
and it's probably inspired in part by #477750.

> Looking at what other shells do, bash and dash behave the same way as
> tmux, but only really brave souls dare to remove either of those.  On
> the other hand fish, ksh, mksh, rc, screen, tcsh and zsh call add-shell
> unconditionally.

Would it help to only call remove-shell on purge?

Bug#938962: user-mode-linux needs update for new linux

[Romain Francoise]

Hi,

On Tue, Sep 3, 2019 at 3:21 PM Ritesh Raj Sarraf  wrote:
[...]
> In file included from /usr/include/pcap.h:43,
>  from arch/um/drivers/pcap_user.c:7:
> /usr/include/pcap/pcap.h:835:18: note: previous declaration of ‘pcap_open’ 
> was here
>  PCAP_API pcap_t *pcap_open(const char *source, int snaplen, int flags,
>   ^
> make[2]: *** [scripts/Makefile.build:309: arch/um/drivers/pcap_user.o] Error 1

libpcap 1.9 includes support for remote capture, which was originally
a part of WinPcap extensions. The `pcap_open()' symbol is part of that
API and that's why it's defined in the header file even though remote
support is not enabled in Debian. I suggest you rename the function
defined in your program so that it doesn't conflict with libpcap.

Bug#935112: Drop root privileges

[Romain Francoise]

Hi,

On Mon, Aug 19, 2019 at 4:57 PM Laurent Bigonville  wrote:
> tcpdump is apparently able to drop its root privileges to run as an
> unprivileged user.

Yes, with the -Z option (e.g. `tcpdump -Z nobody').

> In RHEL they are passing "--with-user=tcpdump" to the configure.

What this does is configure tcpdump to switch to user 'tcpdump' *by default*.

I think it's time for Debian to adopt the same posture and drop
privileges by default as well, it's a significant departure from the
historical behavior but tcpdump's security track record isn't very
good so there is justification. I will work on that for the next
package release, thank you for the prod.

Bug#933514: tmux: Screen garbling in ncurses apps

[Romain Francoise]

On Wed, Jul 31, 2019 at 8:17 PM Sven Joachim  wrote:
> Maybe the problems with screen updates have been triggered by
> ncurses-base 6.1+20190713-1, see #933572?  I could reproduce that one
> with tmux 2.8-3, 2.9a-2 and 3.0~rc3-1.

Do you mind if I merge this bug with #933572?

Thanks.

Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux

[Romain Francoise]

Hi Sven,

On Wed, Aug 7, 2019 at 6:26 PM Sven Joachim  wrote:
> So now all of this has happened in the meantime, and ncurses
> 6.1+20190803-1 should be ready for upload.  The problematic "rin"
> feature has been removed from tmux* and from screen, but not from other
> screen-derived terminfo entries.

Great, thanks for the update.

> There are probably a few people who have followed advice on the web[1]
> and set TERM to screen-256color, those would still be affected.  Do we
> care about them?

Yes, very much. For instance, I am one of them. :-)

Bug#933514: tmux: Screen garbling in ncurses apps

[Romain Francoise]

This bug will be fixed by a future update to ncurses, which I assume
is waiting for the current version to migrate to testing. Thanks.

Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux

[Romain Francoise]

Hi Sven,

On Wed, Jul 31, 2019 at 7:57 PM Sven Joachim  wrote:
> So rin=\E[%p1%dT has been added in sid, apparently because of the
> following change in the 20190630 patchlevel:
>
> ,
> |   + add a check in tic for paired indn/rin
> `

Would it be possible to temporarily revert this change in Debian,
perhaps until tmux 3.0 is released sometime in October? The patch to
support rin is large, and I'm not comfortable carrying it as a
Debian-specific backport. Thanks.

Bug#933514: tmux: Screen garbling in ncurses apps

[Romain Francoise]

A patch for this is now available in the upstream bug tracker
(https://github.com/tmux/tmux/issues/1861) and I have tested it
successfully using the Mutt recipe from #933572.

Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux

[Romain Francoise]

Hi Sven,

On Wed, Jul 31, 2019 at 7:57 PM Sven Joachim  wrote:
> So rin=\E[%p1%dT has been added in sid, apparently because of the
> following change in the 20190630 patchlevel:
>
> ,
> |   + add a check in tic for paired indn/rin
> `
>
> It looks like tmux does not quite cope with this correctly or so.

Thank you very much for this. I have opened an issue upstream to have
nicm's input:

https://github.com/tmux/tmux/issues/1861

Bug#933514: tmux: Screen garbling in ncurses apps

[Romain Francoise]

On Wed, Jul 31, 2019 at 5:42 AM T. Joseph Carter
 wrote:
> The latest version of tmux has issues with screen updates under GNOME
> Terminal with ncurses apps. This causes eg weechat's scrollback (pgup,
> pgdn) to not draw correctly, causes specific issues with aptitude as
> well.

Thanks for the report. I don't use GNOME Terminal and I haven't
experienced any similar issues myself, but I will investigate.

Can you provide more details about how to reproduce using aptitude?

> I think this may be the result of the cherry-pick of 38b8a198bac6 from
> upstream, you may need an additional patch as well.

Why? This is a fix for a crash which doesn't look related.

Do you experience the issue only when multiple panes are used in a window?

> I suspect the version of tmux found in experimental will not have this
> problem, but I haven't tested it yet. I expect you're holding it due to
> the freeze, but I do not believe 2.9a-2 makes a good release candidate.

No, the freeze is over but the 3.0 release was pushed back to October,
so 3.0-rc will remain in experimental for the immediate future.

Bug#932282: libnet-pcap-perl: FTBFS: error: redefinition of ‘struct pcap_rmtauth’

[Romain Francoise]

Hi Niko,

On Wed, Jul 17, 2019 at 12:51 PM Niko Tyni  wrote:
> This package fails to build from source on current sid/amd64.
>
> Presumably this regressed with libpcap 1.9.0-2 so copying
> the maintainer in case it's an oversight.

Thank you for the report!

Fedora uses the following patch to fix the build with libpcap 1.9.0,
it seems fine to me and indeed fixes the FTBFS:

https://src.fedoraproject.org/rpms/perl-Net-Pcap/raw/master/f/Net-Pcap-0.18-Fix-build-with-libpcap-1.9.0.patch

Bug#928648: Sessions do not survive X restart under some conditions

[Romain Francoise]

Hi,

On Wed, May 8, 2019 at 11:09 AM chrysn  wrote:
> In 2.9a-1 and 2.8-3, the following procedure resulted in tmux sessions
> not surviving an X restart (which is my primary use case for tmux): [...]

It looks to me like something is killing the tmux server, and I'm not
sure there's anything that can be done on the tmux side to avoid it.

Google suggests that you're not alone with this issue:
https://github.com/tmux/tmux/issues/1307
https://bbs.archlinux.org/viewtopic.php?id=228128

Can you try starting tmux with -v and then providing the server log?

Thanks.

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever

[Romain Francoise]

Hi,

On Fri, May 3, 2019 at 2:14 PM Salvatore Bonaccorso  wrote:
> Not yet decided, and might need imput from stable release managers as
> well, but the issue might be worth fixing before a next point release
> already via stretch-updates and a SUA.

Agreed.

> I have already cherry-picked the commit in the stretch branch in the
> kernel-team packaging repo at [1].

Thanks!

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever

[Romain Francoise]

Hi,

v4.9.172 is out with the offending commit reverted. Is there a stretch
update with the same revert planned soon to address this? And via which
suite?

Thanks.