Bug#1064376: 1064376-d...@bugs.debian.org

[Marcos Fouces]

Hello

i changed my mind on this subject. ganglia-web was updated to run on
PHP8 [1] so i will (try to) continue to use and maintain ganglia,
ganglia-modules-linux and ganglia-web packages.

Greetings, 

Marcos

[1] https://github.com/ganglia/ganglia-web/releases/tag/3.7.6

Bug#1064376: RM: ganglia -- ROM; Unmaintained upstream, better alternatives exist

[Marcos Fouces]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: mar...@debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

Bug#1029317: arp-scan: depends on libtext-csv-perl, only recommends libwww-perl

[Marcos Fouces]

Hello Sven, 

Fixed in:
https://salsa.debian.org/pkg-security-team/arp-scan/-/commit/ceee4464afacb8dd522e47bc162ee3325429c198

Greetings, 
Marcos


El sáb, 21-01-2023 a las 11:00 +0100, Sven Joachim escribió:
> Package: arp-scan
> Version: 1.10.0-1
> Severity: normal
> 
> The latest upload added a dependency on libtext-csv-perl.  No
> justification was given, but I figured out that get-uoi needs it.
> 
> However, get-uoi also needs libwww-perl and only recommends it, which
> inconsistent.  Considering that get-uoi is not essential for arp-
> scan's
> functionality, I think both libtext-csv-perl and libwww-perl should
> be
> in Recommends.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'experimental')
> merged-usr: no
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.164-nouveau (SMP w/2 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages arp-scan depends on:
> ii  ieee-data 20220827.1
> ii  libc6 2.36-8
> ii  libpcap0.8    1.10.3-1
> ii  libtext-csv-perl  2.02-2
> 
> Versions of packages arp-scan recommends:
> ii  libwww-perl  6.67-1
> 
> arp-scan suggests no packages.
> 
> -- no debconf information
> 

Bug#1029318: arp-scan: /usr/share/doc/arp-scan/NEWS is a dangling symlink

[Marcos Fouces]

Hello Sven, 

Fixed in [1].

Greetings, 
Marcos

[1]
https://salsa.debian.org/pkg-security-team/arp-scan/-/commit/bffc303795679fdf86a56eb6a22cb5f0a5662122

El sáb, 21-01-2023 a las 11:12 +0100, Sven Joachim escribió:
> Package: arp-scan
> Version: 1.10.0-1
> Severity: normal
> 
> ,
> > $ file /usr/share/doc/arp-scan/NEWS
> > /usr/share/doc/arp-scan/NEWS: broken symbolic link to NEWS.md
> `
> 
> Looks like NEWS.md should be added to debian/arp-scan.docs.
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'experimental')
> merged-usr: no
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.164-nouveau (SMP w/2 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages arp-scan depends on:
> ii  ieee-data 20220827.1
> ii  libc6 2.36-8
> ii  libpcap0.8    1.10.3-1
> ii  libtext-csv-perl  2.02-2
> 
> Versions of packages arp-scan recommends:
> ii  libwww-perl  6.67-1
> 
> arp-scan suggests no packages.
> 
> -- no debconf information
> 

Bug#1029319: arp-scan: should be built with libcap support

[Marcos Fouces]

Hi Sven,

Thanks for your report!

arp-scan is an admin command. It is installed (by default) in
/usr/sbin/, this directory is not in the $PATH of a normal user.


Personally, I don't think it's a good idea for a non-privileged user to
execute administrator commands, although it's a matter of preference.
In my opinion, this is fine this way and this bug should be closed.

Greetings, 
Marcos

El sáb, 21-01-2023 a las 11:15 +0100, Sven Joachim escribió:
> Package: arp-scan
> Version: 1.10.0-1
> Severity: normal
> 
> Reading the NEWS.md file, it seems that arp-scan should be built with
> POSIX.1e capabilities support on Linux.  Probably you want to add
> libcap-dev to Build-Depends (on Linux architectures) and try
> "setcap cap_net_raw+p /usr/sbin/arp-scan" in the postinst so that
> arp-scan can be run by an ordinary user.
> 
> 
> -- System Information:
> Debian Release: bookworm/Sid's
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (101, 'experimental')
> merged-usr: no
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.164-nouveau (SMP w/2 CPU threads)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages arp-scan depends on:
> ii  ieee-data 20220827.1
> ii  libc6 2.36-8
> ii  libpcap0.8    1.10.3-1
> ii  libtext-csv-perl  2.02-2
> 
> Versions of packages arp-scan recommends:
> ii  libwww-perl  6.67-1
> 
> arp-scan suggests no packages.
> 
> -- no debconf information
> 

Bug#1022844: man subsection directories are needed for mandoc(1)

[Marcos Fouces]

Hello Alejandro,

Debian policy is clear on this point: manual pages should be assigned
to man[1..9]/ dirs [1]. Lintian also issues error tags when this
behavior is not observed [2].

The desired section expressed through the file extension and the .TH
field is not modified. All .so links are corrected to point to the
corresponding man page. 

>From dh_installman(1) manual page:

" ...you tell dh_installman what man pages go in your packages, and it
figures out where to install them based on the section field in their
.TH or .Dt line. If you have a properly formatted .TH or .Dt line, your
man page will be installed into the right directory, with the right
name (this includes proper handling of pages with a subsection, like
3perl, which are placed in man3, and given an extension of .3perl). If
your .TH or .Dt line is incorrect or missing, the program may guess
wrong based on the file extension."

What is the precise drawback of this solution?

Greetings, 
Marcos

[1] https://www.debian.org/doc/debian-policy/ch-docs.html#manual-pages
[2] https://lintian.debian.org/tags/odd-place-for-manual-page

Bug#1023217: manpages: Wrongly sorted man pages

[Marcos Fouces]

Hello Helge,
The presence of these *.2 and *.3 manpages in the manpages package
instead of manpages-dev is to avoid sending broken links in the
manpages-dev package.

The source package even provides a script [1] to check for this problem
and make corrections.

There is also an example in the manpages-dev package: console_ioctl.4
is moved to the manpages-dev package because it points to
ioctl_console.2.

Unless a better solution is proposed, I think it's best to close this
bug in a few days.

Greetings,
Marcos

[1]https://sources.debian.org/src/manpages/6.02-1/debian/move_links_to_correct_package/

Bug#1019014: Control: 1019014 retitle ITA: termit -- Simple terminal emulator based on vte library, embedded lua

[Marcos Fouces]

Control: 1019014 retitle ITA: termit -- Simple terminal emulator based
on vte library, embedded lua

Bug#893879: Seems to be fixed

[Marcos Fouces]

Hello

i cannot reproduce this bug in 3.7.5+debian-4 release. 

Bullseye ships 1.7 release of rrdtool so the gap you mention between
1.4 and 1.5 releases of rrdtool is an old stuff, IMHO.

If no further information is provided i'll close this bug.

Greetings, 
Marcos

Bug#1002558: chkrootkit: false positive: knockd

[Marcos Fouces]

Hello, 

i believe that it is not appropriate to hide processes that, we
suppose, are legitimate [1].
It is somewhat easy to parse any regular expression, and customize
files/directories names of the rootkit that match it, thus avoiding its
detection.

Please, use etc/chkrootkit/chkrootkit.ignore to set all the stuff you
want to ignore.

Greetings, 
Marcos

[1]https://sources.debian.org/src/chkrootkit/0.55-4/debian/README.FALSE-POSITIVES/

Bug#982998: Forwarded to upstream author

[Marcos Fouces]

Hello, 
Sorry for the delay.

I forwarded this bug to upstream author.

Greetings, 
Marcos.

Bug#991444: ganglia-monitor: gmond and gmetric look for /etc/gmond.conf instead of /etc/ganglia/gmond.conf

[Marcos Fouces]

Hi Jochen, 

many thanks for this bug report.

I uploaded a fixed release in the git repo [1]. Due to the deep freeze
policy, i cannot upload it to unstable until Bullseye comes to life.

Greetings, 
Marcos

[1] https://salsa.debian.org/debian/ganglia

Bug#991073: unblock: ganglia-modules-linux/1.3.4-5

[Marcos Fouces]

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

Please unblock package ganglia-modules-linux

[ Reason ]
Configs path are wrong. Users must manually fix the configuration
files for all modules contained in this package.

Upstream uses "/usr/lib/ganglia" as path for all cases. Debian package
support multiarch, so paths must be adapted for each architecture, for
example "/usr/lib/x86_64-linux-gnu/ganglia" for amd64.

Modules are properly allocated at install time but the values in config
files are wrong.

This fix is done via dpkg-architecture DEB_HOST_MULTIARCH in d/rules
file. There is no other change as you can check in the diff.

[ Other info ]
I still not uploaded the package to sid waiting for aproval.

unblock ganglia-modules-linux/1.3.4-5

diff -Nru ganglia-modules-linux-1.3.6/debian/changelog ganglia-modules-linux-1.3.6/debian/changelog
--- ganglia-modules-linux-1.3.6/debian/changelog	2021-01-17 11:43:42.0 +0100
+++ ganglia-modules-linux-1.3.6/debian/changelog	2021-07-12 00:22:06.0 +0200
@@ -1,3 +1,9 @@
+ganglia-modules-linux (1.3.6-5) unstable; urgency=medium
+
+  * Fix multiarch support in *.conf files (Closes: #990808).
+
+ -- Marcos Fouces   Mon, 12 Jul 2021 00:22:06 +0200
+
 ganglia-modules-linux (1.3.6-4) unstable; urgency=medium
 
   * Remove version requirement for libganglia1-dev as 3.3.5 is older than
diff -Nru ganglia-modules-linux-1.3.6/debian/rules ganglia-modules-linux-1.3.6/debian/rules
--- ganglia-modules-linux-1.3.6/debian/rules	2021-01-17 11:43:42.0 +0100
+++ ganglia-modules-linux-1.3.6/debian/rules	2021-07-12 00:22:06.0 +0200
@@ -2,13 +2,20 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = $(shell apr-1-config --cflags --cppflags --includes) -I/usr/include/tirpc/
 export DEB_LDFLAGS_MAINT_APPEND = -ltirpc
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
 	dh $@
 
-override_dh_auto_install:
+override_dh_auto_install: debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_fs.conf-sample debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_io.conf debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_multicpu.conf-sample
 	dh_auto_install
-	cp conf.d/mod_fs.conf debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_fs.conf-sample
-	cp conf.d/mod_io.conf debian/ganglia-modules-linux/etc/ganglia/conf.d
-	cp conf.d/mod_multicpu.conf debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_multicpu.conf-sample
 	find debian/ \( -name "*.la" -o -name "*.a" -o -name "modmulticpu.so" \) -delete
+
+debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_fs.conf-sample: conf.d/mod_fs.conf
+	sed 's/usr\/lib\/ganglia/usr\/lib\/$(DEB_HOST_MULTIARCH)\/ganglia/g' $< > $@
+
+debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_io.conf: conf.d/mod_io.conf
+	sed 's/usr\/lib\/ganglia/usr\/lib\/$(DEB_HOST_MULTIARCH)\/ganglia/g' $< > $@
+
+debian/ganglia-modules-linux/etc/ganglia/conf.d/mod_multicpu.conf-sample: conf.d/mod_multicpu.conf
+	sed 's/usr\/lib\/ganglia/usr\/lib\/$(DEB_HOST_MULTIARCH)\/ganglia/g' $< > $@

Bug#973554: /etc/cron.monthly/acct does not handle missing wtmp.1

[Marcos Fouces]

Hello Ellen

I just remember that i rewrote partially this script on the next
release due to this bug :-)

This was due to the old logrotate configuration for wtmp rotation that
was done once a month just before the execution of this script. So
wtmp.1 (or wtmp.1.gz) was always present. This is no longer the case
and i updated this script to reflect this new situation.

This bug was already fixed in the current testing release (6.6.4-4).
This is current acct.cron.monthly:
https://salsa.debian.org/pkg-security-team/acct/-/raw/debian/master/debian/acct.cron.monthly

Greetings, 
Marcos.



l mié, 13-01-2021 a las 15:16 -0800, Ellen Wang escribió:
> Here we go:
> 
> # ls -l /var/log/wtmp*
> -rw-rw-r-- 1 root utmp 198144 Jan  6 09:24 /var/log/wtmp
> -rw-r- 1 root adm  88 Jan 13 15:05 /var/log/wtmp.report
> 
> # sh -x /etc/cron.monthly/acct
> + LOGROTATE=/etc/cron.daily/logrotate
> + test -x /usr/sbin/accton
> + date
> + echo Login accounting for the month ended Wed Jan 13 15:07:43 PST
> 2021:
> + echo
> + [ -f /etc/cron.daily/logrotate ]
> + [ -x /usr/sbin/logrotate ]
> + [ -f /var/log/wtmp.1 ]
> + [ -f /var/log/wtmp.1.gz ]
> + ac -f  -p
> + sort -nr -k2
> couldn't open file '': No such file or directory
> + echo
> + last -f
> last: cannot open : No such file or directory
> + [ -n  ]
> + chown root:adm /var/log/wtmp.report
> + chmod 640 /var/log/wtmp.report
> 
> --
> 
> What does your script look like?  I ran the one installed in 
> /etc/cron.monthly (with 10.7 buster).  Your output looks like there
> are 
> some differences besides not failing.
> 
> 
> On 1/13/21 2:16 PM, Marcos Fouces wrote:
> > Hello Ellen
> > 
> > I renamed temporarily wtmp.1 and i run the script with "set-x" to
> > see
> > what is going on:
> > 
> > # ./$HOME/Debian/Packages/acct/debian/acct.cron.monthly
> > + test -x /usr/sbin/accton
> > + echo
> > ###
> > #
> > + echo # LOGIN ACCOUNTING MONTHLY REPORT
> > ##
> > + echo
> > ###
> > #
> > + echo
> > + date
> > + echo Login accounting for the month ended mié 13 ene 2021
> > 23:09:40
> > CET:
> > + echo
> > + test -f /var/log/wtmp.1
> > + test -f /var/log/wtmp.1.gz
> > + echo Data contained in current wtmp file:
> > + ac -p
> > + sort -nr -k2
> > + echo
> > + last
> > + chown root:adm /var/log/wtmp.report
> > + chmod 640 /var/log/wtmp.report
> > 
> > 
> > Could you check this on your machine, please.
> > 
> > Thanks for your bug report.
> > 
> > Greetings,
> > Marcos.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Thanks for your bug report.
> > 
> > 
> > El dom, 01-11-2020 a las 11:03 -0800, Ellen Wang escribió:
> > > Package: acct
> > > Version: 6.6.4-2
> > > 
> > > On a newly installed system, /etc/cron.monthly/acct complains:
> > > 
> > > /etc/cron.monthly/acct:
> > > couldn't open file '': No such file or directory
> > > last: cannot open : No such file or directory
> > > 
> > > The problem is that the script wants to use /var/log/wtmp.1
> > > instead
> > > of
> > > wtmp if logrotate exists, on the assumption that logrotate has
> > > already
> > > moved wtmp to wtmp.1.  However, this is not true if wtmp is not
> > > big
> > > enough to have been rotated.
> > > 
> > > This patch gets rid of the error:
> > > 
> > > --- /etc/cron.monthly/acct# 2018-08-23 09:01:38.0 -
> > > 0700
> > > +++ /etc/cron.monthly/acct  2020-11-01 10:13:58.310091356 -
> > > 0800
> > > @@ -33,7 +33,10 @@
> > > 
> > >   gunzip -c /var/log/wtmp.1.gz >
> > > "${WTMP}"
> > >   fi
> > > +   fi
> > > 
> > > +   if [ -n "${WTMP}" ]
> > > +   then
> > >   ac -f "${WTMP}" -p | sort -nr -k2 >>
> > > /var/log/wtmp.report
> > >   echo >> /var/log/wtmp.report
> > >   last -f "${WTMP}" >> /var/log/wtmp.report
> > > 
> > > Perhaps a better fix would be to fall back to wtmp.1 only if wtmp
> > > is
> > > empty.  Alternatively, if we want a monthly report that covers
> > > exactly
> > > one month, then not specifying minsize in /etc/logrotate.d/wtmp
> > > is
> > > the
> > > solution.
> > > 
> > 

Bug#973554: /etc/cron.monthly/acct does not handle missing wtmp.1

[Marcos Fouces]

Hello Ellen

I renamed temporarily wtmp.1 and i run the script with "set-x" to see
what is going on:

# ./$HOME/Debian/Packages/acct/debian/acct.cron.monthly
+ test -x /usr/sbin/accton
+ echo

+ echo # LOGIN ACCOUNTING MONTHLY REPORT
##
+ echo

+ echo
+ date
+ echo Login accounting for the month ended mié 13 ene 2021 23:09:40
CET:
+ echo
+ test -f /var/log/wtmp.1
+ test -f /var/log/wtmp.1.gz
+ echo Data contained in current wtmp file:
+ ac -p
+ sort -nr -k2
+ echo
+ last
+ chown root:adm /var/log/wtmp.report
+ chmod 640 /var/log/wtmp.report


Could you check this on your machine, please.

Thanks for your bug report.

Greetings, 
Marcos.
















Thanks for your bug report. 


El dom, 01-11-2020 a las 11:03 -0800, Ellen Wang escribió:
> Package: acct
> Version: 6.6.4-2
> 
> On a newly installed system, /etc/cron.monthly/acct complains:
> 
> /etc/cron.monthly/acct:
> couldn't open file '': No such file or directory
> last: cannot open : No such file or directory
> 
> The problem is that the script wants to use /var/log/wtmp.1 instead
> of 
> wtmp if logrotate exists, on the assumption that logrotate has
> already 
> moved wtmp to wtmp.1.  However, this is not true if wtmp is not big 
> enough to have been rotated.
> 
> This patch gets rid of the error:
> 
> --- /etc/cron.monthly/acct# 2018-08-23 09:01:38.0 -0700
> +++ /etc/cron.monthly/acct  2020-11-01 10:13:58.310091356 -0800
> @@ -33,7 +33,10 @@
> 
>  gunzip -c /var/log/wtmp.1.gz > "${WTMP}"
>  fi
> +   fi
> 
> +   if [ -n "${WTMP}" ]
> +   then
>  ac -f "${WTMP}" -p | sort -nr -k2 >>
> /var/log/wtmp.report
>  echo >> /var/log/wtmp.report
>  last -f "${WTMP}" >> /var/log/wtmp.report
> 
> Perhaps a better fix would be to fall back to wtmp.1 only if wtmp is 
> empty.  Alternatively, if we want a monthly report that covers
> exactly 
> one month, then not specifying minsize in /etc/logrotate.d/wtmp is
> the 
> solution.
> 

Bug#975403: RM: knocker -- ROM; unmaintained, better alternatives

[Marcos Fouces]

Package: ftp.debian.org
Severity: normal

Please, remove knocker package. It is unmaintained upstream and it is
affected by #957411. Also there are other better network scanners
(nmap, hping3...).

Also it has a low popcon (72 at the time of writing).

Thanks in advance.

Marcos.

Bug#964399: Should ganglia be removed?

[Marcos Fouces]

Hi Moritz!

Yes, i uploaded it to salsa.d.o and i am waiting for Frontdesk aproval
to become DD (that should happens in a few days) in order to upload it
myself instead of asking for sponsorship.

Its new home is here: https://salsa.debian.org/debian/ganglia.

Thanks, 
Marcos


El vie, 11-09-2020 a las 21:04 +0200, Moritz Mühlenhoff escribió:

> Are you still interested in adopting ganglia? Otherwise I'll file an
> RM bug soon.
>  
> Cheers,
>  Moritz
>  

Bug#967885: Forwarded to upstream authors

[Marcos Fouces]

tags 967885 forwarded
thanks

Bug#967205: No python package

[Marcos Fouces]

Hi!

I think that rfdump package is not related with Python. I think there
is a mistake.

Greetings, 
Marcos

Bug#964399: Should ganglia be removed?

[Marcos Fouces]

Hello Moritz

I did some work time ago on ganglia [1] but i never get this work
published due to unactive/unresponsive uploaders.

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.

Please, let me know your thoughs.

Greetings,
 
Marcos

[1] https://salsa.debian.org/mfouces-guest/ganglia



El lun, 06-07-2020 a las 20:12 +0200, Moritz Muehlenhoff escribió:
> Source: ganglia
> Severity: serious
> 
> Should ganglia be removed? It's dead upstream (last commits from over
> three years ago,
> last release from 2015), is now orphaned (last active maintainer is
> no longer a DD, but
> wasn't very actively maintained to begin with, the current packaged
> version is from 2013),
> most of the plugins depend on Python 2, there's unfixed security
> issues dating back to
> 2013 and doesn't even support ipv6 (730257).
> 
> Unless anyone steps up for maintenance (and partly becomes upstream),
> it should better
> be removed.
> 
> Cheers,
> Moritz
> 

Bug#919911: Please add enpXsY wlanX wlpXsY to to /etc/cron.daily/chkrootkit Bug#919911

[Marcos Fouces]

Hello Witold, 

i believe that patch implemented for bug #580491, also fixes this
issue. Please,check 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580491.

I plan to upload a new chkrootkit release soon.

Greetings, 
Marcos.

Bug#745433: chkrootkit: Allow to choose the start time. Bug#745433

[Marcos Fouces]

Hello Frederic,

Thanks for your suggestion.

I assume that you means using a crontab entry to define the exact start
time for this script. I think that this is good for machines that runs
continously but not for the rest.

Triggering it through a crontab entry, the task will not be executed if
the computer is not running at the precise moment.

I prefer to stay on the safe side and use a more flexible tool. IMHO,
it is better to let anacron keeping up with this job.

I suggest edit the script and renice chkrootkit execution rather than
running it with cron.

Greetings, 
Marcos.








> __
> 
>View this message in rfc822 format
> 
>From: Frederic MASSOT 
>To: Debian Bug Tracking System 
>Subject: Bug#745433: chkrootkit: Allow to choose the start time
>Date: Mon, 21 Apr 2014 18:02:18 +0200
> 
> Package: chkrootkit
> Version: 0.49-4.1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> On some server when chkrootkit and another IO task (backup, rsync,
> find, etc) wo
> rk together, the load goes high (greater than 100).
> 
> It would be interesting to choose the time of launch of daily
> chkrootkit. This w
> ould launch earlier in the night, or at a different time of the
> backup server.
> 
> The "/etc/cron.daily/chkrootkit" file could be moved into
> "/usr/sbin/" folder an
> d daily launch managed by a file in the "/etc/cron.d/" folder. This
> file would b
> e able to change the start time.
> 
> 
> Regards.
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.13-1-686-pae (SMP w/1 CPU core)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages chkrootkit depends on:
> ii  binutils   2.24-4
> ii  debconf [debconf-2.0]  1.5.52
> ii  libc6  2.18-4
> ii  net-tools  1.60-25
> ii  procps 1:3.3.9-2
> 
> chkrootkit recommends no packages.
> 
> chkrootkit suggests no packages.
> 
> -- debconf information:
> * chkrootkit/run_daily: true
> * chkrootkit/diff_mode: false
> * chkrootkit/run_daily_opts: -q -e '/lib/init/rw/.ramfs'
>  
> __
> 
>Acknowledgement sent to Frederic MASSOT :
>New Bug report received and forwarded. Copy sent to Giuseppe
> Iuculano
>. (Mon, 21 Apr 2014 16:15:06 GMT) (full text,
>mbox, link).
>  
> __
> 
>View this message in rfc822 format
> 
>From: ow...@bugs.debian.org (Debian Bug Tracking System)
>To: Frederic MASSOT 
>Subject: Bug#745433: Acknowledgement (chkrootkit: Allow to choose
> the
>start time)
>Date: Mon, 21 Apr 2014 16:15:06 +
> 
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Giuseppe Iuculano 
> 
> If you wish to submit further information on this problem, please
> send it to 745...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 745433: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745433
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>  
> __
> 
>Send a report that this bug log contains spam.
>  
> __
> 
> 
> Debian bug tracking system administrator .
> Last modified: Thu Apr 9 09:12:55 2020; Machine Name: buxtehude
> Debian Bug tracking system
> Debbugs is free software and licensed under the terms of the GNU
> Public License version 2. The current version can be obtained
> from
> https://bugs.debian.org/debbugs-source/.
> Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation
> Ltd,
> 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other
> contributors.

Bug#647962: Cannot reproduce

[Marcos Fouces]

tags 647962 unreproducible
thank you


Hello Christoph

I cannot reproduce this bug. Please, could you give me the exact
options an arguments you used?

Greetings, 
Marcos.

Bug#633926: Seems fixed

[Marcos Fouces]

Hello

I am testing it on 2.4b1+debian-29 and *-26 too and it does not fail. 
Please, tell me if this is your case so i could close this bug or do
some testing.

Greetings, 
Marcos.

Bug#953234: Fix pending in Git repo

[Marcos Fouces]

El jue, 16-04-2020 a las 13:50 +0200, Marcos Fouces escribió:
> tags 953234 pending
> thanks
> 
> Hello
> 
> An updated release is on salsa.d.o repo:
> 
> https://salsa.debian.org/pkg-security-team/recon-ng
> 
> Just needs a sponsor review.
> 
> Greetings, 
> Marcos.
> 
> 

Bug#617918: False positives in chkrootkit

[Marcos Fouces]

Hello Samuel

False positives always fall on the safe vs. sorry argument. Please,
check 
https://salsa.debian.org/pkg-security-team/chkrootkit/-/blob/debian/master/debian/README.FALSE-POSITIVES

You can always use the "-e" option or an exclude file (defined in
/etc/chkrootkit.conf) to avoid this warning.

I don't believe that is a bug and i would like to close it if you don't
have any objection.

Greetings, 
Marcos.


> 
> Hello,
> 
> Running chkrootkit with the slice package installed says TH-Sharpe is
> installed, while the slice package is simply a wml dependency.
> 
> Samuel
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'),
> (1, 'experim
> ental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> 
> Versions of packages chkrootkit depends on:
> ii  binutils   2.21.0.20110302-1 The GNU assembler,
> linker and bina
> ii  cdebconf [debconf-2.0] 0.153 Debian Configuration
> Management Sy
> ii  debconf [debconf-2.0]  1.5.38Debian configuration
> management sy
> ii  libc6  2.11.2-11 Embedded GNU C Library:
> Shared lib
> ii  net-tools  1.60-23   The NET-3 networking
> toolkit
> ii  procps 1:3.2.8-10/proc file system
> utilities
> 
> chkrootkit recommends no packages.
> 
> chkrootkit suggests no packages.
> 
> -- debconf information excluded
> 
> --
> Samuel Thibault 
>  bouhouhouh, b il m'a abandonné. Tout ca parce que je regardais
> plus mon emac
> s que lui !
>  s/lui/ses messages irc/
>  -+- #ens-mim esseulé -+-
> 
> 
> 
>  
> __
> 
>Acknowledgement sent to Samuel Thibault :
>New Bug report received and forwarded. Copy sent to Giuseppe
> Iuculano
>. (Sat, 12 Mar 2011 15:27:04 GMT) (full text,
>mbox, link).
>  
> __
> 
>View this message in rfc822 format
> 
>From: ow...@bugs.debian.org (Debian Bug Tracking System)
>To: Samuel Thibault 
>Subject: Bug#617918: Acknowledgement (chkrootkit: False positive:
>slice)
>Date: Sat, 12 Mar 2011 15:27:04 +
> 
> Thank you for filing a new Bug report with Debian.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due
> course.
> 
> Your message has been sent to the package maintainer(s):
>  Giuseppe Iuculano 
> 
> If you wish to submit further information on this problem, please
> send it to 617...@bugs.debian.org.
> 
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> --
> 617918: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617918
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 
>  
> __
> 
>Send a report that this bug log contains spam.
>  
> __
> 
> 
> Debian bug tracking system administrator .
> Last modified: Thu Apr 9 09:12:22 2020; Machine Name: buxtehude
> Debian Bug tracking system
> Debbugs is free software and licensed under the terms of the GNU
> Public License version 2. The current version can be obtained
> from
> https://bugs.debian.org/debbugs-source/.
> Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation
> Ltd,
> 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other
> contributors.

Bug#754711: Bug seems solved.

[Marcos Fouces]

Hello

I cannot test this o-o-stable kernel, but searching this particular
chunk i found that this test is no more performed this way but:

 KALLSYMS="/proc/kallsyms"
 [ -f /proc/ksysm ] && KALLSYMS="/proc/$KALLSYMS"

So kernel release is no more relevant.

I believe that this bug is fixed.

Could you confirm my findings?

Greetings,
Marcos

Bug#750629: wrong mail options in /etc/chkrootkit.conf

[Marcos Fouces]

Hello Enrico

In fact, you have to escape quotas in the argments you supply to the
RUN_DAILY_OPTS variable.

It should be posible to insert needed escape characters in debconf (i
suppose that you configured it that way) but i suggest that let cron
daemon send the mail for you.

IMHO, this is not a bug.

Greetings, 
Marcos

Bug#586897: Debian Bugs information: detailed logs for Bug#586897

[Marcos Fouces]

Hello Jean Baptiste

Thanks for your bug report. I will improve the info in the manpage and
in the "-h" output but the help display if user set an erroneous value
on any option has to be dealt upstream.

I will close the bug as soon as i upload a new revision with this
improvements and i forward your suggestion to upstream.

Greetings, 
Marcos.

Bug#934486: Debian Bugs information: detailed logs for Bug#934486

[Marcos Fouces]

Hello Peter

Thanks for pointing this out! As you stated, this was a simple
oversight and i upload a fix in no time.

Greetings, 
Marcos

Bug#956153: ITP: fierce -- Domain DNS scanner

[Marcos Fouces]

Package: wnpp
Severity: wishlist
Owner: Marcos Fouces 

* Package name: fierce
  Version : 1.4.0
  Upstream Author : Mschwager <https://github.com/mschwager/>
* URL : https://github.com/mschwager/fierce
* License : GPL
  Programming Lang: Python
  Description : Domain DNS scanner

 Fierce is a semi-lightweight scanner that helps locate non-contiguous
 IP space and hostnames against specified domains. It's really meant as
 a pre-cursor to nmap, unicornscan, nessus, nikto, etc, since all of
 those require that you already know what IP space you are looking for.
 This does not perform exploitation and does not scan the whole internet
 indiscriminately. It is meant specifically to locate likely targets both
 inside and outside a corporate network.
 Because it uses DNS primarily you will often find mis-configured networks
 that leak internal address space. That's especially useful in targeted
malware.
 Originally written by RSnake along with others at http://ha.ckers.org/.
 This is simply a conversion to Python 3 to simplify and modernize the
codebase.

Bug#924362: Failure upgrading chkrootkit

[Marcos Fouces]

Hello

If no more information is provided, i will close this bug in a few
days.

Greetings, 
Marcos.

El mar, 24-03-2020 a las 23:21 +0100, Marcos Fouces escribió:
> Hello Adam
> 
> I am trying to reproduce the bug with current version of chkrootkit
> but
> i obtain a different result:
> 
> # sudo /usr/share/debconf/frontend
> /var/lib/dpkg/info/chkrootkit.postinst configure 0.53-1; echo $?
> 
> # 0
> 
> I used a (still unreleased) 0.53-2 version and it seems to be
> correctly
> upgraded.
> 
> Could you confirm this?
> 
> Greetings, 
> Marcos.
> 

Bug#348991: Confirm for iotop behavior

[Marcos Fouces]

Hello

If no more informartion is provided, i will close this bug in a few
days.

Greetings, 
Marcos

Bug#936188: bbqsql: Python2 removal in sid/bullseye

[Marcos Fouces]

Hello Moritz

I believe that bbqsql could be removed. It has a very low popcon and i
didn't see any repo on Github taking over from Neophasis.

Greetings, 
Marcos.


El jue, 26-03-2020 a las 23:05 +0100, Moritz Mühlenhoff escribió:
> On Fri, Aug 30, 2019 at 07:11:19AM +, Matthias Klose wrote:
> > Package: src:bbqsql
> > Version: 1.1-4
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > 
> > 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.
> 
> Hi Marcos,
> bbqsql seems dead upstream, development mostly stopped in 2013 and
> the
> author mentions in https://github.com/Neohapsis/bbqsql/pull/61 "he
> no 
> longer works for the company".
> 
> Are you planning to port it to Python 3 yourself or should it be
> removed?
> 
> Cheers,
> Moritz

Bug#937521: pyrit: Python2 removal in sid/bullseye

[Marcos Fouces]

Hi Sandro

My work was unsuccessful.  With this patch, the package FTBFS and i am
not in a position to fix this problem.

Keep in mind that patch submiter highlights the need for more testing
but nobody else steps forward for two months, even upstream developer.

I am afraid that i cannot provide a Python3 pyrit in a timely manner.

Greetings, 
Marcos.



El jue, 26-03-2020 a las 23:55 -0400, Sandro Tosi escribió:
> Hey Marcos,
> 
> On Thu, Mar 19, 2020 at 7:33 AM Marcos Fouces <
> marcos.fou...@gmail.com> wrote:
> > Hello Sandro
> > 
> > Upstream seems a bit stalled but there is a patch (by Kimocoder
> > from
> > aircrack project) to migrate it. You can see it here:
> > 
> > https://github.com/JPaulMora/Pyrit/pull/593
> > 
> > As i have some time these days,i will try to test it a see if it is
> > a
> > valid approach.
> 
> i wanted to check in to see how your tests are going: do you have
> already a python3 pyrit? if not, how mich longer do you think it
> would
> take you?
> 
> Cheers,

Bug#576470: chkrootkit: false positives for libsmlnj-smlnj

[Marcos Fouces]

Hello Norman

I checked this package (ibsmlnj-smlnj) in Debian testings (upcoming
Bullseye) and still contains the files you mention and that triggers
this false positive.

I believe that chkrootkit's nature is very trigger-happy and i tend to
consider this behaviour more like a feature rater than a bug.

As a workaround: Once you checked *carefully* all this files and dirs,
i suggest to put this dir names in an exclude file. I don't feel that
this should be done in the package as it is posible to exclude some
suspicious files that every sysadmin should inspect closely.

if the thread doesn't get any more responses, i will close this bug in
a few days.

Greetings, 
Marcos

Bug#566687: chkrootkit False Positives

[Marcos Fouces]

Hello

chkrootkit is certainly very "trigger-happy" but IMHO this is a feature
not a bug. Quoting the README.FALSE-POSITIVES file included with the
package:

"bindshell listens on a lot of ports.  these ports are also used by
other legitimate programs.  chkrootkit's detection algorithm cannot
determine the difference between a legitimate program and bindshell."

IMHO, the best solution is tweaking the report in order to avoid such
message when you *really* know this is a false positive and you already
investigated it.

If you want to discuss it, please go ahead. If not i will close this
bug in a few days.

Greetings, 
Marcos

Bug#924362: Failure upgrading chkrootkit

[Marcos Fouces]

Hello Adam

I am trying to reproduce the bug with current version of chkrootkit but
i obtain a different result:

# sudo /usr/share/debconf/frontend
/var/lib/dpkg/info/chkrootkit.postinst configure 0.53-1; echo $?

# 0

I used a (still unreleased) 0.53-2 version and it seems to be correctly
upgraded.

Could you confirm this?

Greetings, 
Marcos.

Bug#937521: Attempt to migrate pyrit to Python3

[Marcos Fouces]

Hi, 

I tried to use a patch from kimocoder to migrate Pyrit to Python3 but
the result was unsucesfull as the package FTBFS. I created a separate
branch (Python3Migration) in order to work on that [0].

Upstream stated that is rewriting pyrit from scratch but he still
didn't react to this pull request [0]

[0] https://github.com/JPaulMora/Pyrit/pull/593

Greetings, 
Marcos

Bug#771266: chkrootkit: hangs on checking lkm and causes system load to increase by ~1.0

[Marcos Fouces]

Hi Ximin!

I will close this bug if i don't receive more info in the next days.

Greetings, 
Marcos

Bug#937521: pyrit: Python2 removal in sid/bullseye

[Marcos Fouces]

Hello Sandro

Upstream seems a bit stalled but there is a patch (by Kimocoder from
aircrack project) to migrate it. You can see it here:

https://github.com/JPaulMora/Pyrit/pull/593

As i have some time these days,i will try to test it a see if it is a
valid approach. 

Greetings, 
Marcos


El mié, 18-03-2020 a las 19:43 -0400, Sandro Tosi escribió:
> Hello everyone,
> 
> On Fri, 30 Aug 2019 07:35:12 + Matthias Klose 
> wrote:
> > Package: src:pyrit
> > Version: 0.5.1+git20180801-1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> 
> What is the future for pyrit? i see upstream published 3 months ago
> that:
> 
> ```
> Pyrit is old, is outdated and it's still Python2 I am currently
> attempting to rewrite it from scratch, so thanks for all the stars
> but
> remember to keep an eye for Python3 version.
> ```
> 
> and Raphael pinged upstream regarding where to actual "watch" for
> this
> new version: 
> https://github.com/JPaulMora/Pyrit/issues/200#issuecomment-581859819
> 
> but nothing really happened in between: i could see no public
> progress
> from upstream, and only visible push towards python3 compatibility is
> this PR which is now https://github.com/JPaulMora/Pyrit/pull/593 3
> months old with no comments or sign of an imminent merge.
> 
> the reason i'm here is because pyrit is the last reverse dependency
> of
> python-scapy, which in turn is the last reverse dependency of
> ipython.
> 
> since i dont know when (and even if) a pyrit python3 port will be
> available, i was considering removing it (which will also require
> removing the b-d from wifite) so that scapy and ipython can drop
> their
> python2 support.
> 
> What do you guys think about this approach? I would like to proceed
> quickly so please reply withing a week or two.
> 
> Regards,
> Sandro

Bug#348991: Confirm for iotop behavior

[Marcos Fouces]

Hello Gerrit

Could you confirm the behavior of iotop?

These are my results:

$ sudo iostat ALL
Linux 5.4.0-4-amd64 (debian)18/03/20_x86_64_(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  23,390,098,692,080,00   65,74

Device tpskB_read/skB_wrtn/skB_dscd/skB_rea
dkB_wrtnkB_dscd
sda  10,2696,1591,01 0,00   3901930
9   36931337  0
scd0  0,00 0,00 0,00 0,00  
0  0  0


$ uname -a
Linux debian 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64
GNU/Linux

There are no data for r/s, w/s, d/s or f/s. Man page for iostat states
that the result contain only data that are provided by the kernel.

AFAIK, the kernel is not collecting this info.

Greetings, 
Marcos.

Bug#922533: Review of proposed move of /var/log/account to /var/account

[Marcos Fouces]

Good!

I already uploaded a new release in the git repo:

https://salsa.debian.org/pkg-security-team/acct

It contains this and other changes.

Any DD available for review and upload this new release.

Thank you. Greetings

Marcos

El mié, 18-03-2020 a las 11:33 +, Sergio Gelato escribió:
> Thank you for the feedback. I'm quite happy for the change not to
> happen. It's certainly less work that way.
> 
> From: Marcos Fouces 
> Sent: Tuesday, March 17, 2020 18:48
> To: 922...@bugs.debian.org
> Cc: Sergio Gelato
> Subject: Re: Review of proposed move of /var/log/account to
> /var/account
> 
> Hello Sergio
> 
> I am considering the fact that this change could do more harm than
> good. The path for pacct* files was changed a long time ago and every
> Debian user of acct is aware of it.
> 
> The submiter himself has finally some doubts about it, so i believe
> that it is pointless.
> 
> I can't see any good reason to do this.
> 
> I am all for listen to different point of view but i will close this
> bug and revert this changes if no good reason arise.
> 
> Greetings,
> Marcos

Bug#922533: Review of proposed move of /var/log/account to /var/account

[Marcos Fouces]

Hello Sergio

I am considering the fact that this change could do more harm than
good. The path for pacct* files was changed a long time ago and every
Debian user of acct is aware of it.

The submiter himself has finally some doubts about it, so i believe
that it is pointless.

I can't see any good reason to do this. 

I am all for listen to different point of view but i will close this
bug and revert this changes if no good reason arise.

Greetings, 
Marcos


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

Bug#949782: ITP: python-ezcolor -- Python colorizing strings library (Python 3)

[Marcos Fouces]

Package: wnpp
Severity: wishlist
Owner: Marcos Fouces 

* Package name: python-ezcolor
  Version : 0.7
  Upstream Author : Fardin Allahverdinazhand <0x0ptim...@gmail.com>
* URL : https://github.com/0x0ptim0us/ezcolor
* License : MIT
  Programming Lang: Python
  Description : Python colorizing strings library (Python 3)

 A lightweight library for applying color and HTML text styles to the strings
 that uses the builder pattern for configuration. The ezcolor lets you have
 nice colorized output with extra HTML text styles like bold/italic/underline.
 compatible with bash/sh/zsh.

This package is needed for the new release of websploit. I plan to maintain it
under DPMT umbrella.

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

[Marcos Fouces]

Hello Fardin
I am the uploader of websploit in Debian distro. I am trying to package
your new release but AFAIK one of the dependencies (python-wifi) is
only for python2. Currently we cannot package new python2 modules in
Debian.
Please, let me know  if i am wrong because i am all for packaging this
release for Debian, Kali...
Greetings, Marcos.



El lun, 20-01-2020 a las 08:07 -0500, Optimous Prime escribió:
> Hi RaphaelI just finished updating websploit. latest version now
> available on github 
> https://github.com/websploit/websploit
> Cheers
> On Wed, Jan 15, 2020 at 5:00 AM 0X0Ptim0Us <0x0ptim...@gmail.com>
> wrote:
> > Hi Raphael
> > I’m working on it and i will release new version before 24th.
> > Thanks
> > 
> > 
> > 
> > > On Jan 15, 2020 at 12:27 PM,  wrote:
> > > 
> > > Hello Fardin,
> > > 
> > > 
> > > any update?
> > > 
> > > 
> > > Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939260,
> > > https://tracker.debian.org/pkg/websploit indicates that websploit
> > > will
> > > be auto-removed from Debian testing on January 24th.
> > > 
> > > 
> > > It would be nice to have a Python 3 version until then.
> > > 
> > > 
> > > Cheers,
> > > 
> > > 
> > > On Sat, 21 Dec 2019, Optimous Prime wrote:
> > > > Hi, i'm working on it, maybe 20 day .
> > > >  
> > > > On Mon, Dec 16, 2019 at 8:28 AM Raphael Hertzog <
> > > hert...@debian.org> wrote:
> > > >  
> > > > > 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
> > > 
> > > > >
> > > 
> > > 
> > > --  
> > >   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
> > >   ⣾⠁⢠⠒⠀⣿⡁
> > >   ⢿⡄⠘⠷⠚⠋The Debian Handbook: 
> > > https://debian-handbook.info/get/
> > > 
> > >   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
> > > 

Bug#944432: ITP: python-rq -- Simple job queues for Python 3

[Marcos Fouces]

Package: wnpp
Severity: wishlist
Owner: Marcos Fouces 

* Package name: python-rq
  Version : 1.1.0
  Upstream Author : Vincent Driessen 
* URL : https://python-rq.org/
* License : BSD
  Programming Lang: Python
  Description : Simple job queues for Python 3

RQ (Redis Queue) is a simple Python library for queuing jobs and processing
them in the background with workers. It is backed by Redis and it is designed
to have a low barrier to entry. It can be integrated in your web stack easily.

This python module is needed for newer releases of recon-web (part of recon-ng
package). It will be maintained inside Debian Modules Packaging Team.

Bug#944430: ITP: python-flasgger -- Extract swagger specs from your flask project

[Marcos Fouces]

Package: wnpp
Severity: wishlist
Owner: Marcos Fouces 

* Package name: python-flasgger
  Version : 0.9.3
  Upstream Author : Bruno Rocha
* URL : https://github.com/flasgger/flasgger/
* License : Expat
  Programming Lang: Python
  Description : Extract swagger specs from your flask project

 Flasgger is a Flask extension to extract OpenAPI-Specification from all
 Flask views registered in your API.
 It also comes with SwaggerUI embedded so you can access
 http://localhost:5000/apidocs and visualize and interact
 with your API resources.
 It also provides validation of the incoming data, using the same specification
 it can validates if the data received as as a POST, PUT, PATCH is valid
against
 the schema defined using YAML, Python dictionaries or Marshmallow Schemas.
 Flasgger can work with simple function views or MethodViews using docstring
 as specification, or using @swag_from decorator to get specification from
 YAML or dict and also provides SwaggerView which can use
 Marshmallow Schemas as specification.

This python module is needed for new releases of recon-web (part of recon-ng
package). It will be maintained inside Python Modules Pacakaging Team.

Bug#944129: arp-scan: not returning any results

[Marcos Fouces]

Hello

I just uploaded a new release of arp-scan to git [0]. I tested it and
it works well on my machine (Debian testing).

Could some DD review and upload the package?

Greetings, 
Marcos

[0] https://salsa.debian.org/pkg-security-team/arp-scan



El lun, 04-11-2019 a las 18:42 +0100, Reiner Herrmann escribió:
> Package: arp-scan
> Version: 1.9.5-1
> Severity: serious
> Tags: fixed-upstream
> 
> Dear maintainer,
> 
> arp-scan is no longer returning any results in Debian sid.
> 
> > # arp-scan 10.0.0.0/24
> > Interface: wlan0, datalink type: EN10MB (Ethernet)
> > Starting arp-scan 1.9.5 with 256 hosts (
> > https://github.com/royhills/arp-scan)
> > 
> > 14 packets received by filter, 0 packets dropped by kernel
> > Ending arp-scan 1.9.5: 256 hosts scanned in 2.031 seconds (126.05
> > hosts/sec). 0 responded
> 
> With wireshark I can actually see arp replies (and it sounds like
> they
> were also received ("14 packets received")),
> With another machine that is running buster I can still see the
> results, so it could have been introduced by a different libpcap
> version?
> 
> After noticing that the bug has also been filed in Ubuntu [0],
> I also tested the version from git and got it running successfully.
> This is the first commit at which it is returning results again: [1].
> It is contained in the new upstream release 1.9.6.
> 
> Kind regards,
>   Reiner
> 
> [0] https://bugs.launchpad.net/ubuntu/+source/arp-scan/+bug/1849740
> [1] https://github.com/royhills/arp-scan/commit/8513a18

Bug#935042: Privacy Breach is not in policy

[Marcos Fouces]

Hello

Similar issues were discussed in: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726998

You could also find that Lintian folks uses several levels of error
tags to describe this problem, for instance:

* 
https://lintian.debian.org/tags/privacy-breach-statistics-website.html.
It is considered as "serious"

* https://lintian.debian.org/tags/privacy-breach-generic.html. It is
considered as "important"

Both tags are related to the present issue.

AFAIK, there is nothing in Debian Policy about this but it is plain
common sense to avoid this kind of privacy breaches.

Greetings, 

Marcos

Bug#935042: Privacy on Debian

[Marcos Fouces]

Hello Michael,

I am aware of the configuration option you mention but i decided to
create a patch changing the CheckUpdates() function because i don't know
if it is used in another part of the software.

I also can understand your desire to know where and when an Lynis audit
is performed but it shouldn't be done without user knowledge. It is up
to the user to decide to check if an update is available or to decide if
he wants to get informed about it.

If users give consent to check for updates each time an audit is
performed -which it must be done phoning home, for obvious reasons- then
it is ok for you to use this info. Anyway, i believe that this  function
should be disabled in Debian. It does not make much sense for distros as
they has their own updating system.

Except for this matter, i believe that Lynis is a good piece of software.

Greetings,

Marcos

Bug#348991: What needs to be done to kernel to collect disk I/O statistics?

[Marcos Fouces]

Hello

I can confirm that the problem persists with the kernel i use(Linux 
4.19.0-4-amd64). I am inclined to close this bug because it has nothing
to do with acct but with the kernel.

Greetings,

Marcos

Bug#680263: Illegal number - maybe already fixed

[Marcos Fouces]

Hello Vincent,

i believe that we should don't care about bugs that affect kernels
before oldstable release.

In this case, the script test the existence of /proc/ksyms and set the
variable KALLSYMS to /proc/kallsyms only if it doesn't exist so the
kernel version should not be relevant. AFAIK, the name of the file was
changed at some point during 2.6 releases of Linux kernel.

FTR. I share your opinion about closing this bug.

Greetings,

Marcos

Bug#680263: Illegal number - maybe already fixed

[Marcos Fouces]

Hello

Since 0.50 release, the test to check the name of the file (ksysm or
kallsyms) is the following:

 KALLSYMS="/proc/kallsyms"
 [ -f /proc/ksysm ] && KALLSYMS="/proc/$KALLSYMS"

so i believe that it is not a problem anymore. Anyway I cannot test it
with an kernel older enough to use /proc/ksysm.

If you could test it, please tell me if it is really fixed.

Greetings,

Marcos

Bug#922533: please document location of accounting file

[Marcos Fouces]

On 22/2/19 16:55, Marc Haber wrote:
> I am not sure whether this was a brilliant idea, many local mechanisms
> on existing installations might be looking for the file in the old
> place. Also, migration probably needs a gazillion of tests to make sure
> that nothing breaks. For how long has the data been in /var/log/?

Hello Marc

The /var/log/account/ path was introduced by a previous maintainer in
6.3.99+6.4pre1-3 release (2006).

I can't figure out any reason for that. In fact, there were several bugs
reporting troubles caused by this change (#377835
, #380744
, #385626
, #392045
, #396444
).

Instead of reverting this change to the standard path (/var/account), he
decided to fix them setting this new path properly in all pertinent
files and it was in use it since then. AFAIK, you could define any path
you want for store log files.

Greetings,

Marcos.

Bug#922533: please document location of accounting file

[Marcos Fouces]

Hello Marc

I did some investigation about the localization for pacct in various
distros and i saw that /var/account is the more widely used (Fedora,
RedHat, Gentoo...). This path is the standard even on {Free,Net,Open}BSD
where this file is called acct. So, i migrated the log files to this new
path.

I uploaded a new revision to salsa.d.o [0] but i am not sure if this bug
fixing worths an upload in the middle of a freeze.

If so, could you consider sponsor the package?

Greetings,

Marcos

[0] https://salsa.debian.org/pkg-security-team/acct/



On 20/2/19 17:46, Marc Haber wrote:
> Hi Marcos,
>
> thanks for your answer.
>
> My suggestion is to have a well documented file in a stable location
> that says where to find the actual accounting file. Currently, atop's
> code is full of constructs like
>
> for PACCTFILE in /var/account/pacct /var/log/pacct
> do
> if [ -f "$PACCTFILE" ]  # file exists?
> then
>
> (which is obviously missing the current plac /var/log/account/pacct)
>
> otoh, if this will be a Debianism, atop's code won't get any easier since atop
> will need to continue handling all those places in other
> distributions.
>
> Greetings
> Marc
>
>
> On Tue, Feb 19, 2019 at 11:44:39PM +0100, Marcos Fouces wrote:
>> From: Marcos Fouces 
>> Subject: Re: Bug#922533: please document location of accounting file
>> To: Marc Haber , 922...@bugs.debian.org,
>>  Debian Bug Tracking System 
>> Date: Tue, 19 Feb 2019 23:44:39 +0100
>> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
>>  Thunderbird/60.5.0
>> X-Spam-Score: (--) -2.1
>> X-Spam-Report: torres.zugschlus.de  Content analysis details:   (-2.1
>>  points, 5.0 required)   pts  rule name  description  
>>  -- --- -1.9
>>  BAYES_00   BODY: Bayes spam probability is 0 to 1%
>>  [score: 0.] -0.0 RCVD_IN_DNSWL_NONE
>>  RBL: Sender listed at http://www.dnswl.org/,
>>  no trust
>>  [2a00:1450:4864:20:0:0:0:42c listed in]
>>  [list.dnswl.org]  0.0 FREEMAIL_FROM
>>   Sender email is commonly abused enduser mail
>>  provider (marcos.fouces[at]gmail.com) -0.0
>>  SPF_PASS   SPF: sender matches SPF record -0.1 DKIM_VALID_AU
>>   Message has a valid DKIM or DK signature from
>>  author's domain  0.1 DKIM_SIGNED
>> Message has a DKIM or DK signature, not necessarily
>>  valid -0.1 DKIM_VALID_EF  Message has
>>  a valid DKIM or DK signature from
>>  envelope-from domain -0.1 DKIM_VALID
>>  Message has at least one valid DKIM or DK signature
>>
>> Hi Marc
>>
>> In Debian, the pacct file is located in /var/log/account/pacct while in
>> Fedora it is in /var/account/pacct.
>>
>> I don't see the reason to be less parsable in that location.
>>
>> What is your suggestion?
>>
>> Greetings,
>>
>> Marcos
>>
>> On 17/2/19 20:50, Marc Haber wrote:
>>> Package: acct
>>> Version: 6.6.4-2
>>> Severity: wishlist
>>>
>>> Hi,
>>>
>>> my package atop needs to adapt itself to acct being installed or not. If
>>> acct is installed, atop reads from acct's log files, while establishing
>>> its own accounting interface it acct is not installed.
>>>
>>> Historically, the pacct file is found in various different places,
>>> varying across distribution, so atop's upstream code does through
>>> various contortions to find the correct file. It for example acts on
>>> /etc/logrotate.d/psacct to find the file being rotated, which fails on
>>> Debian since Debian's acct package uses savelog in /etc/cron.d/acct.
>>>
>>> atop on Debian is currently growing code to parse for the savelog line
>>> in /etc/cron.d/acct to find out the acct file being used.
>>>
>>> Would it be possible ot have the acct file's location in a more easily
>>> parsable location? Thanks for helping!
>>>
>>> Greetings
>>> Marc
>>>
>>>
>>> -- System Information:
>>> Debian Release: buster/sid
>>>   APT prefers unstable
>>>   APT policy: (500, 'unstable'), (500, 'stable')
>>> Architecture: amd64 (x86_64)
>>> Foreign Architectures: i386
>>>
>>> Kernel: Linux 4.20.8-zgws1 (SMP w/4 CPU cores)
>>> Kernel taint flags: TAINT_OOT_MODULE
>>> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
>>> (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>>
>>> Versions of packages acct depends on:
>>> ii  dpkg  1.19.4
>>> ii  install-info  6.5.0.dfsg.1-4+b1
>>> ii  libc6 2.28-7
>>> ii  lsb-base  10.2018112800
>>>
>>> acct recommends no packages.
>>>
>>> acct suggests no packages.
>>>

Bug#922533: please document location of accounting file

[Marcos Fouces]

Hi Marc

In Debian, the pacct file is located in /var/log/account/pacct while in
Fedora it is in /var/account/pacct.

I don't see the reason to be less parsable in that location.

What is your suggestion?

Greetings,

Marcos

On 17/2/19 20:50, Marc Haber wrote:
> Package: acct
> Version: 6.6.4-2
> Severity: wishlist
>
> Hi,
>
> my package atop needs to adapt itself to acct being installed or not. If
> acct is installed, atop reads from acct's log files, while establishing
> its own accounting interface it acct is not installed.
>
> Historically, the pacct file is found in various different places,
> varying across distribution, so atop's upstream code does through
> various contortions to find the correct file. It for example acts on
> /etc/logrotate.d/psacct to find the file being rotated, which fails on
> Debian since Debian's acct package uses savelog in /etc/cron.d/acct.
>
> atop on Debian is currently growing code to parse for the savelog line
> in /etc/cron.d/acct to find out the acct file being used.
>
> Would it be possible ot have the acct file's location in a more easily
> parsable location? Thanks for helping!
>
> Greetings
> Marc
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.20.8-zgws1 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages acct depends on:
> ii  dpkg  1.19.4
> ii  install-info  6.5.0.dfsg.1-4+b1
> ii  libc6 2.28-7
> ii  lsb-base  10.2018112800
>
> acct recommends no packages.
>
> acct suggests no packages.
>

Bug#788851: Patch for acct

[Marcos Fouces]

Hello Dominique

Thanks for your report.

I also believe that is not a acct bug as you admit ("...so the cause may
be the kernel having an open file handle.")

BTW. i cannot reproduce this bug myself. Could you please check if the
problem persist with a newer kernel?

If no more info is provided i eventually close this bug.

Greetints,

Marcos.

Bug#3251: Any reason to keep a wontfix bug opened for years?

[Marcos Fouces]

Hello

I also believe that this bug report is useless. As today (January 2019)
it is almost 23 years old!

Upstream is dead and, as far as i know, nobody took over upstream
maintenance.

For this reason i close this bug now.

Greetings,

Marcos

Bug#916977: snoopy w/ ld preload enabled breaks "apt upgrade" jessie-to-buster

[Marcos Fouces]

Hello,

I use testing and updated hundreds of package without any trouble.

Please, could you give an example of a package that fails to upgrade?

Greetings,

Marcos.

On 11/1/19 18:52, Adrian Bunk wrote:
> On Thu, Dec 20, 2018 at 05:26:25PM -0500, deb...@mailinator.com wrote:
>> Package: snoopy
>> Version: 2.4.6-4
>> Severity: critical
>> Justification: breaks unrelated software
>>
>> Dear Maintainer,
>>
>> With snoopy installed and enabled on jessie, apt upgrade to buster will 
>> break the upgrade process, as the snoopy library goes missing while the ld 
>> preload setting persists.  This causes every command invocation to trigger 
>> an error message concerning the missing library.  
>> ...
> Hw did you upgrade from jessie to buster?
>
> Skipping a release when upgrading is not supported,
> only jessie -> stretch -> buster is supported.
>
> cu
> Adrian
>

Bug#915718: RFS: arno-iptables-firewall/2.0.3-1 [ITA]

[Marcos Fouces]

Hello Sven

As Adam stated, you should reconsider this change. I cannot see any
reason no to be backward compatible with sysvinit.

There is also some Lintian informative and pedantic tags that are
triggered. I found most of them reasonable, so it should also a good
idea to address them.

BTW: this is a security tool that would fit perfectly on the
pkg-security tools team. Please consider joining us [0]if you are
interested in maintain this package within a team.

[0] https://wiki.debian.org/Teams/pkg-security

Greetings,

Marcos.

Bug#913191: override: libnids1.21/libs

[Marcos Fouces]

Package: ftp.debian.org

Please move the libnids1.21 package to "libs" section. It was wrongly
tagged as "libdevel".

d/control file has already been updated and the proper package had also
been uploaded.

Greetings,

Marcos

Bug#904200: RM: acccheck -- ROM; Insecure, unmaintained, better alternatives

[Marcos Fouces]

Hello

I am agree with this. Some days ago -when this bugs were published- I
contacted upstream but i get no answer.

Greetings,

Marcos


On 21/07/18 15:02, Raphaël Hertzog wrote:
> Package: ftp.debian.org
> Severity: normal
>
> Please remove the acccheck package. It is affected by multiple security
> vulnerabilities that are unlikely to be fixed by upstream as this was a
> script written and shared a long time ago, upstream is not actively
> maintaining it.
>
> The feature set of this package is also redundant with other better tools:
> metasploit, hydra, medusa, ncrack and patator
>
> FWIW the package has been dropped from Debian Testing due to #901572
> and Kali followed suite, it has been dropped from their meta-package too.
>
> Thank you in advance.
>
> PS: I first tried to patch the security vulnerability but when I looked at
> the code more closely, it's literaly riddled with shell injection
> vulnerabilities and it would be time-consuming to fix them all.
>
> PS: I'm requesting this as a member of the pkg-security packaging team
> even though I'm not listed in Uploaders of the package. I have put Marcos
> Fouces in copy of the bug.
>

Bug#613000: Convert Hardening Debian to XML

[Marcos Fouces]

El 06/05/18 a las 18:40, Osamu Aoki escribió:
>
> We need to move to salsa (debian group), I think.
>
> I mean in https://salsa.debian.org/debian
>
> like https://salsa.debian.org/debian/debian-reference
OK, could you give me access?

BTW, is there any plan to create a ddp group?

> This way, all DD has access.
>
> https://wiki.debian.org/Salsa/Doc
>
>> On Sun, Apr 16, 2017 at 03:16:24PM +0200, Marcos Fouces wrote:
>>
>> Hello
>>
>> I would be glad to (try my best to) convert this book to XML. I have 
>> a
>> personal interest in it because (time ago) i learn a lot from it.
>>
>> Great.
>>
>>
>> I already did a clean and complete (hopefully...) of its SVN repo to 
>> git and
>> asked for write access on alioth ddp repo.
>>
>> Please coordinate how exactly push this through.  Javi is the maintainer
>> of FAQ.
> This is still pending, I think.
No, i talked with Javi on IRC a year ago. He told me to work on *.po
files (i already had done the migration to git and to xml at that time).

The simplest build system i found was the debian-handbook so i re-used
its Publican based system.

Greetings,
Marcos

Bug#613000: Convert Hardening Debian to XML

[Marcos Fouces]

Hello

I already done the following work so far and uploaded to the repo [1]:

* Imported SVN repo to git.

* Migrated debiandoc sgml to Docbook XML. In order to test it, i
slightly adapted the debian-handbook build apparatus moslty due to its
simplicity.

* Merged german an french *.po files with latest version of original text.

* Used po4a-gettextize in order to get every translated string in the
rest of available languages (spanish, italian, japanese,  chinese,
portuguese).

All languages have at least 30% translated strings.

Hope that helps to maintain this good manual.

Greetings.

Marcos

[1] https://anonscm.debian.org/cgit/ddp/securing-debian-howto.git/log/


> On Sun, Apr 16, 2017 at 03:16:24PM +0200, Marcos Fouces wrote:
>> Hello
>>
>> I would be glad to (try my best to) convert this book to XML. I have a
>> personal interest in it because (time ago) i learn a lot from it.
> Great.
>  
>> I already did a clean and complete (hopefully...) of its SVN repo to git and
>> asked for write access on alioth ddp repo.
> Please coordinate how exactly push this through.  Javi is the maintainer
> of FAQ.  
>
> Please check with:
>  https://wiki.debian.org/Teams/DDP
>
> I just added you but please discuss with javi how exactly you start
> committing.
>
> Osamu

Bug#890635: chkrootkit: Errors when trying to exclude known false positives

[Marcos Fouces]

Hello Lorenzo and Maxim,

It also works fine with me.

Maxim, could you please try 0.52 release and see if it works fine?

Greetings,

Marcos


> On 02/18/2018 03:10 PM, Lorenzo "Palinuro" Faletra wrote:
>> On 02/17/2018 02:35 AM, Maxim Biro wrote:
>> Package: chkrootkit
>> Version: 0.50-4+b2
>> Severity: important
>>
>> Dear Maintainer,
>>
>> I have installed both fail2ban and chkrootkit on Debian Stretch. It is not 
>> the
>> system I'm writing this report from. When running chkrootkit, it complains
>> about hidden files from fail2ban:
>>
>>
>> The issue seems to be that chkrootkit doesn't parse its arguments correctly 
>> or
>> it has a limit on how long the -e argument can be. In fact, if you remove
>> several file paths from either the beginning or the end of the -e argument,
>> chkrootkit works as intended and lists just the removed file paths as false
>> positives. Ideally users should be able to specify any number of file paths 
>> to
>> be excluded.
> Sorry, in my previous message i have misunderstood the real problem (i
> was on my mobile phone).
>
> I did a test on my computer (debian buster testing) and i was able to
> put a string of 20722 characters in the exclusion list (-e) and have all
> the files blacklisted properly.
>
> Don't forget that stretch includes chkrootkit 0.50, while buster
> provides the 0.52 version which worked properly for me.
>
> Try the 0.52 version from buster and let me know if it works for you.
>
>

Bug#887832: [arp-scan] Segmentation fault at launch

[Marcos Fouces]

Hello Manu

I believe that is the same problem as described in bug #881125. It is
solved in 1.9-3 release in the Debian testing

Could you install the package from testing and check if it works for
you? If so, i will close this bug.

Many thanks for your report.

Greetings.

Marcos



El 20/01/18 a las 12:33, manu escribió:
> Package: arp-scan
> Version: 1.9-1
> Severity: normal
>
> --- Please enter the report below this line. ---
> Hello,
> launching either "arp-scan" or "arp-scan --localnet" from command line
> leads to a segmentation fault.
> Feel free to ask for more information,
>
>
> --- System information. ---
> Architecture: Kernel:   Linux 3.19.0-trunk-amd64
>
> Debian Release: 9.3
>   900 stable  security.debian.org   900 stable
> ftp2.fr.debian.org   500 zesty   ppa.launchpad.net   100
> unstabledebian.qelectrotech.org
> --- Package information. ---
> Depends (Version) | Installed
> =-+-===
> libc6   (>= 2.15) | libpcap0.8 (>= 0.9.8) | ieee-data
>  |
>
> Recommends   (Version) | Installed
> ==-+-===
> libwww-perl| 6.15-1
>
>
> Package's Suggests field is empty.
>
>

Bug#844303: Working on it porting ncrack to OpenSSL 1.1

[Marcos Fouces]

Hello Hilko!

Great news!


El 11/12/17 a las 01:14, Hilko Bengen escribió:
> Hi,
>
> just a heads-up: I am working on porting ncrack to OpenSSL 1.1. There
> are two main causes of issues:
>
> (1) OpenSSL-related checks in opensshlib/configure.ac are broken, they use
> old SSLeay_* APIs, this is fixed easily.
>
> (2) The usual getter/setter mess. There's a lot of code and in
> opensshlib/ that needs to be touched. Since this is more than just
> search/replace, I'll try to get my patch reviewed by upstream before
> making updates to the Debian package.
>
> Cheers,
> -Hilko
>
>
>

Bug#866843: New maintainer for chkrootkit

[Marcos Fouces]

Hello

I close this bug as chkrootkit is currently maintained by the Debian 
pkg-security tools team.

Bug#715646: Processed: Bug#715646 marked as pending

[Marcos Fouces]

Hi Adrian,

i agree to prepare a package for the next Jessie point release. I think 
these issues are not grave enough for a DSA.


That is my opinon, but i would appreciate feedback.

Greetings,

Marcos


El 11/05/17 a las 21:51, Adrian Bunk escribió:

On Sun, Mar 12, 2017 at 09:06:34AM +0100, Marcos Fouces wrote:

control: severity -1 grave

This could lead to DOS or, even worst, remote code execution. Following
Hilko Bengen's advice: i re-adjust the severity.

Hi Marcos,

thanks a lot for fixing this bug as well as the similar #716355, #716457
and #716458 in dsniff for stretch.

If these issues are serious enough, please coordinate with the security
team (added to Cc) for getting them to jessie as part of a DSA.

If they are not serious enough for a DSA, it would be appreciated if you
could prepare a package for the next jessie point release.

Thanks
Adrian

Bug#860611: dsniff: FTBFS: ld: cannot find -lmissing

[Marcos Fouces]

Hello Lukas

Maybe you should create a "debian/stretch" branch from 2.4b1+debian-24 
tag and commit your patch here. If you want, you can add yourself as 
uploader and tag it as "2.4b1+debian-25" release. Later we will merge it 
with "debian/master" branch.


I hope there's some DD willing to sponsor it.

Thanks for your work!

Greetings,

Marcos


El 19/04/17 a las 10:29, Lukas Schwaighofer escribió:

Hi,

I just checked the build log. I think the problem is that the Makefile
does not properly enforce the correct build order: PROGS actually
depend on libmissing.a. The build log shows that, at the time of the
build error, libmissing.a is not yet build (but tried to link against).
I suspect the problem surfaced due to the level of parallelism on the
buildd (-j 64).


I've prepared a minimal patch against version 2.4b1+debian-24
(currently in stretch) that should be suitable for an unblock, see
attachment.

If you want I can push that into our git repo, tag it as new release
and then merge that commit into our development branch (bumping the
version for the newer changes when merging the commit log).


Thanks
Lukas

Bug#613000: Convert Hardening Debian to XML

[Marcos Fouces]

Hello

I would be glad to (try my best to) convert this book to XML. I have a 
personal interest in it because (time ago) i learn a lot from it.


I already did a clean and complete (hopefully...) of its SVN repo to git 
and asked for write access on alioth ddp repo.


Greetings,

Marcos

Bug#857577: unblock: dsniff/2.4b1+debian-24

[Marcos Fouces]

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

Please unblock package dsniff in order to fix its five grave bugs

Dear release team,

dsniff is to be removed from testing due to five grave bugs
affecting several of its tools:

#715646 [G|P|  ]  arpspoof crashes with exit status 139
#716355 [G|P|  ]  sshmitm crashes with exit status 139
#716457 [G|P|  ]  webmitm crashes with exit status 139
#716458 [G|P|  ]  webspy crashes with exit status 139
#855869 [G|P|  ]  segfaults on portmapper messages

All of them would get fixed with these patches

+ 29_libnet_name2addr4.patch
+ 30_pntohl_shift.patch  
+ 31_sysconf_clocks.patch 
+ 32_rpc_segfault.patch

They are already implemented time ago in Fedora. 

Also i would like to implement some minor changes:

 * Add -g compiler flag
Avoid creating an empty dbgsym package.
 * Pass triplet-prefixed CC to configure.
Closes a minor bug avoiding FTBFS in some archs.
 * Add 33_sshcrypto_DES.patch
Replacing all des_ methods and structs with DES_ equivalents.
Already implemented in OpenBSD
 * Polish, reorder and refresh patches.
Just a cosmetic change.

Thanks for your time and effort to get release stretch!

You can see the full changes in the diff file attached.

Cheers, 
Marcos

unblock dsniff/2.4b1+debian-24

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

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru dsniff-2.4b1+debian/debian/changelog 
dsniff-2.4b1+debian/debian/changelog
--- dsniff-2.4b1+debian/debian/changelog2016-12-20 22:40:25.0 
+0100
+++ dsniff-2.4b1+debian/debian/changelog2017-02-15 23:42:16.0 
+0100
@@ -1,3 +1,19 @@
+dsniff (2.4b1+debian-24) UNRELEASED; urgency=medium
+
+  * Add -g compiler flag.
+  * Fix FTCBFS: Pass triplet-prefixed CC to configure.
+Thanks to Helmut Grohne (Closes: #852360).
+  * Add four patches from Fedora:
+(Closes: #715646, #716355, #716457, #716458)
++ 29_libnet_name2addr4.patch
++ 30_pntohl_shift.patch
++ 31_sysconf_clocks.patch
++ 32_rpc_segfault.patch (Closes: #855869)
+  * Polish, reorder and refresh patches.
+  * Add 33_sshcrypto_DES.patch
+
+ -- Marcos Fouces <mfou...@yahoo.es>  Wed, 15 Feb 2017 23:42:16 +0100
+
 dsniff (2.4b1+debian-23) unstable; urgency=medium
 
   * Assign to pkg-security team (Closes: #847505)
diff -Nru dsniff-2.4b1+debian/debian/copyright 
dsniff-2.4b1+debian/debian/copyright
--- dsniff-2.4b1+debian/debian/copyright2016-12-20 22:39:02.0 
+0100
+++ dsniff-2.4b1+debian/debian/copyright2017-02-15 23:42:16.0 
+0100
@@ -7,7 +7,7 @@
 License: BSD-3-Clause
   
 Files: debian/*
-Copyright: 2016 Marcos Fouces <mfou...@yahoo.es>
+Copyright: 2016-2017 Marcos Fouces <mfou...@yahoo.es>
2013 Andrew Shadura <andre...@debian.org>
2011-2012 William Vera <bi...@billy.com.mx>
2011 Ondřej Surý <ond...@debian.org>
diff -Nru 
dsniff-2.4b1+debian/debian/patches/0001-arpspoof-add-r-switch-to-poison-both-directions.patch
 
dsniff-2.4b1+debian/debian/patches/0001-arpspoof-add-r-switch-to-poison-both-directions.patch
--- 
dsniff-2.4b1+debian/debian/patches/0001-arpspoof-add-r-switch-to-poison-both-directions.patch
   2016-12-20 22:39:02.0 +0100
+++ 
dsniff-2.4b1+debian/debian/patches/0001-arpspoof-add-r-switch-to-poison-both-directions.patch
   1970-01-01 01:00:00.0 +0100
@@ -1,174 +0,0 @@
->From 8fbf0ac15e5fe2df427e3e028f9aa8d96788986a Mon Sep 17 00:00:00 2001
-From: Stefan Tomanek <ste...@pico.ruhr.de>
-Date: Sun, 6 Nov 2011 22:44:54 +0100
-Subject: [PATCH 1/3] arpspoof: add -r switch to poison both directions
-
-
-Signed-off-by: Stefan Tomanek <ste...@pico.ruhr.de>

- arpspoof.8 |5 -
- arpspoof.c |   59 +++
- 2 files changed, 51 insertions(+), 13 deletions(-)
-
-diff --git a/arpspoof.8 b/arpspoof.8
-index a05b5d3..544e06c 100644
 a/arpspoof.8
-+++ b/arpspoof.8
-@@ -9,7 +9,7 @@ intercept packets on a switched LAN
- .na
- .nf
- .fi
--\fBarpspoof\fR [\fB-i \fIinterface\fR] [\fB-t \fItarget\fR] \fIhost\fR
-+\fBarpspoof\fR [\fB\-i \fIinterface\fR] [\fB\-t \fItarget\fR] [\fB\-r\fR] 
\fIhost\fR
- .SH DESCRIPTION
- .ad
- .fi
-@@ -26,6 +26,9 @@ Specify the interface to use.
- .IP "\fB-t \fItarget\fR"
- Specify a particular host to ARP poison (if not specified, all hosts
- on the LAN).
-+.IP "\fB\-r\fR"
-+Poison both hosts (host and target) to capture traffic in both directions.
-+(only valid in conjuntion with \-t)
- .IP \fIhost\fR

Bug#716355: Processed: Bug#716355 marked as pending

[Marcos Fouces]

control: severity -1 grave

This could lead to DOS or, even worst, remote code execution. Following
Hilko Bengen's advice: i re-adjust the severity.


El 03/03/17 a las 00:27, Debian Bug Tracking System escribió:

Processing commands for cont...@bugs.debian.org:


tag 716355 pending

Bug #716355 [dsniff] [Mayhem] Bug report on dsniff: sshmitm crashes with exit 
status 139
Added tag(s) pending.

thanks

Stopping processing here.

Please contact me if you need assistance.

Bug#716457: Processed: Bug#716457 marked as pending

[Marcos Fouces]

control: severity -1 grave

This could lead to DOS or, even worst, remote code execution. Following
Hilko Bengen's advice: i re-adjust the severity.


El 03/03/17 a las 00:27, Debian Bug Tracking System escribió:

Processing commands for cont...@bugs.debian.org:


tag 716457 pending

Bug #716457 [dsniff] [Mayhem] Bug report on dsniff: webmitm crashes with exit 
status 139
Added tag(s) pending.

thanks

Stopping processing here.

Please contact me if you need assistance.

Bug#715646: Processed: Bug#715646 marked as pending

[Marcos Fouces]

control: severity -1 grave

This could lead to DOS or, even worst, remote code execution. Following
Hilko Bengen's advice: i re-adjust the severity.


El 03/03/17 a las 00:27, Debian Bug Tracking System escribió:

Processing commands for cont...@bugs.debian.org:


tag 715646 pending

Bug #715646 [dsniff] [Mayhem] Bug report on dsniff: arpspoof crashes with exit 
status 139
Added tag(s) pending.

thanks

Stopping processing here.

Please contact me if you need assistance.

Bug#716458: Processed: Bug#716458 marked as pending

[Marcos Fouces]

control: severity -1 grave

This could lead to DOS or, even worst, remote code execution. Following 
Hilko Bengen's advice: i re-adjust the severity.

Bug#855869: Processed: Re: Bug#855869: dsniff: segfaults on portmapper messages

[Marcos Fouces]

Anyone?


El 09/03/17 a las 15:33, Marcos Fouces escribió:

Hello Hilko

I pushed a "debian/stretch" branch  [1] to the repo without all 
changes i've made so far bug the patch that fixes this bug.


It is still posible to get sniff in shape for stretch? If so, could 
you sponsor it or tell me what else to do?


Thanks,

Marcos

[1] 
https://anonscm.debian.org/cgit/pkg-security/dsniff.git/log/?h=debian/stretch



El 05/03/17 a las 15:39, Debian Bug Tracking System escribió:

Processing control commands:


severity -1 grave

Bug #855869 [dsniff] dsniff: segfaults on portmapper messages
Severity set to 'grave' from 'important'

Bug#855869: Processed: Re: Bug#855869: dsniff: segfaults on portmapper messages

[Marcos Fouces]

Hello Hilko

I pushed a "debian/stretch" branch  [1] to the repo without all changes 
i've made so far bug the patch that fixes this bug.


It is still posible to get sniff in shape for stretch? If so, could you 
sponsor it or tell me what else to do?


Thanks,

Marcos

[1] 
https://anonscm.debian.org/cgit/pkg-security/dsniff.git/log/?h=debian/stretch



El 05/03/17 a las 15:39, Debian Bug Tracking System escribió:

Processing control commands:


severity -1 grave

Bug #855869 [dsniff] dsniff: segfaults on portmapper messages
Severity set to 'grave' from 'important'

Bug#856300: ITA: swatch -- Log file viewer with regexp matching,

[Marcos Fouces]

Hello

I already uploaded a new revision of swatch  to the pkg-security team repo:

https://anonscm.debian.org/cgit/pkg-security/swatch.git

Greetings,

Marcos

Bug#706766: Diff for this fix

[Marcos Fouces]

Hello João

Could you create a patch and post it in this thread?

Thank you very much for the fix!

Greetings,

Marcos

Bug#851060: libnids 1.23-2.1 NMU

[Marcos Fouces]

El 26/02/17 a las 18:05, James Cowgill escribió:


Well now that I've collected all the fixes together and tested it, I'm
going to do the NMU anyway :)


Good to read that! Now i will try to contact Vassillis. if he is MIA, 
then i incorporate libnids to pkg-security team.


Cheers,

Marcos




Control: tags -1 patch pending

Hi,

On 25/02/17 18:00, James Cowgill wrote:

On 23/02/17 22:44, Marcos Fouces wrote:

I am agree with you, when i fix these bugs i will create a separate git
branch, cherry-pick only freeze-allowed changes and try to get a package
ready for stretch.

Ok. Since I can now get dsniff working, I will happily NMU this unless
you want to do it.

Well now that I've collected all the fixes together and tested it, I'm
going to do the NMU anyway :)

Uploaded NMU attached.

Thanks,
James

Bug#851060: New dsniff revision

[Marcos Fouces]

Hi James,


El 23/02/17 a las 12:57, James Cowgill escribió:

Hi,

On 22/02/17 23:16, Marcos Fouces wrote:

Hello

I uploaded to repo a first attempt of libnids1.24 package wich aims to
close its two critical bugs:

#855602: fixed upstream in 1.24 release.

As I wrote in the bugreport, the fix applied by upstream is not enough
to fix this. You also need to apply the patch from Fedora otherwise
dsniff will FTBFS on i386.


I applied the patch you mentioned and after a rebuild of dsniff and 
libnids, it still seems to work properly at least on amd64


Please, check it:

https://anonscm.debian.org/cgit/pkg-security/libnids.git



#851060: i tried using -fno-strict-aliasing flag as reporter indicates.
I didn't noticed any change on my amd64, but he talked about armhf arch.

I built dsniff (1) against this new version of libnids-dev (2) and here
is the result:

* Run dsniff

* Run the same test as bug reporter: curl -v --basic --user foo:bar
http://neverssl.com/

dsniff says this:

dsniff: listening on eth0
-
02/22/17 23:56:32 tcp 192.168.1.3.47942 ->
s3-website-us-west-2.amazonaws.com.80 (http)
GET / HTTP/1.1
Host: neverssl.com
Authorization: Basic Zm9vOmJhcg== [foo:bar]

So interestingly, after recompiling your new versions of both libnids
and dsniff, things start working again. I'm not sure what happened
before when I couldn't get anything to work.

I really don't know, i couldn' t reproduce this bug at any time.


(1) https://anonscm.debian.org/cgit/pkg-security/dsniff.git

For stretch, I don't think dsniff needs to be changed.


(2) https://anonscm.debian.org/cgit/pkg-security/libnids.git

At the moment Debian is frozen and you've made a number of changes here
which are not sutible for the freeze. These include:
- Packaging a new version of libnids.
- Breaking the ABI of libnids.
- Bumping debhelper compat

For stretch, the fixes need to be targeted so as to only change as much
stuff as necessary to fix the two RC bugs.


I am agree with you, when i fix these bugs i will create a separate git 
branch, cherry-pick only freeze-allowed changes and try to get a package 
ready for stretch.


For buster, can I suggest you rewrite the rules file. I expect it could
be simplified much more using dh.


Sure


Looking at the diff from upstream, I can't help but stare in disbelief
at this:

diff --git a/src/hash.c b/src/hash.c
index 7e4c611..3eb28ca 100644
--- a/src/hash.c
+++ b/src/hash.c
@@ -57,7 +57,8 @@ mkhash (u_int src, u_short sport, u_int dest,

u_short dport)

u_int res = 0;
int i;
u_char data[12];
-  *(u_int *) (data) = src;
+  u_int *stupid_strict_aliasing_warnings=(u_int*)data;
+  *stupid_strict_aliasing_warnings = src;
*(u_int *) (data + 4) = dest;
*(u_short *) (data + 8) = sport;
*(u_short *) (data + 10) = dport;

A minor note: as someone not part of the pkg-security team, I find it
confusing to have both a "debian/master" and "master" branch in the same
repository both referring to Debian packaging. I think you should remove
the "master" branch (unless this is a team policy?)

Thanks,
James
This is the default behaviour of gbp when creating a repo. In 
pkg-security team we don't use it but you can see it in some packages. 
Anyway, i deleted it. :-)


Cheers,

Marcos

Bug#851060: marked as pending

[Marcos Fouces]

Hello Axel

This compiler flag (-fno-strict-aliasing) is needed in libnids. You are 
right. I will revert this change in dsniff. I added the other flag (-g) 
in order to avoid creating an empty dbgsym package.


I cannot reproduce this bug in amd64 with the current libnids package 
version (1.21). In fact, dsniff works as expected with this testcase.


I built and installed libnids 1.24 (which fix another minor issue 
already solved in Ubuntu) with -fno-strict-aliasing. At least in amd64, 
dsniff still works as expected and i did not noticed any difference.


If the current maintainer of libnids (CC'ed) gives me permission, i can 
import the package to pkg-security team repo, upload my work and 
maintain (or co-maintain) it by now. This makes sense as dsniff seems to 
be the only reverse dependence of libnids.


I believe that in pkg-security team there are some people with access to 
armhf machines so testing should not be an issue. Unfortunately, i can 
do it myself.


Greetings,

Marcos



El 17/02/17 a las 00:41, Axel Beckert escribió:

Hi Marcos,

Marcos Fouces wrote:

+dsniff (2.4b1+debian-24) UNRELEASED; urgency=medium
+
+  * Add -fno-strict-aliasing compiler flag in order to fix
+  TCP reassemble in some architectures as armhf.
+  Thanks to guent...@unix-ag.uni-kl.de (Closes: #851060)
+  * Add -g flag to compiler.

So it does not need those compiler flags in libnids but in dsniff?

Have you tested it on armhf?

Because I tried recompiling libnids with these flags and noticed no
difference. :-/

(But then again I could even reproduce the reported issue on amd64, so
I'm not 100% sure if I actually reproduced it correctly.)

Regards, Axel

Bug#828287: dsniff: FTBFS with openssl 1.1.0

[Marcos Fouces]

A new revision of the package is hosted at pkg-security team. I did some 
improvements (i also add your patch) and the package is hopefully ready 
for upload. Just need a sponsor.


Check it here:

https://anonscm.debian.org/cgit/pkg-security/dsniff.git/

Cheers,

Marcos


El 20/12/16 a las 15:37, Christoph Biedl escribió:

Christoph Biedl wrote...


Adrian Bunk wrote...


Can you make an NMU with your patch
(or by changing it to libssl1.0-dev)?

Can even, even upon short notice. However, dsniff got a new maintainer
(#847505), included.

This probably didn't work due to a local error, sorry.


Marcos, do you want to take over? Personally, I'd
switch to libssl1.0-dev, it's less intrusive and the package needs a
lot of love anyway - which can wait until the stretch release.

Marcos, I suggest to take over. That was also the opportunity to
update the maintainer field so it will be correct for stretch.

Adrian, find a debdiff attached, using the libssl1.0-dev package. I'd
suggest to upload to delayed+2, so Marcos has some time to react. The
frame is small I admit but time's almost up, and it's just to get dsniff
into stretch, nothing else.

All the best,

 Christoph

Bug#847505: retitle 847505 ITA: dsniff -- Various tools to sniff network traffic for cleartext insecurities

[Marcos Fouces]

retitle 847505 ITA: dsniff -- Various tools to sniff network traffic for 
cleartext insecurities

Second try... Hope that works...

Bug#847505: retitle 847505 ITA: dsniff -- Various tools to sniff network traffic for cleartext insecurities

[Marcos Fouces]

retitle847505   ITA: dsniff -- Various tools to 
sniff network traffic for cleartext insecurities

I am interesed in this package. I already uploaded a new revision here:

https://anonscm.debian.org/cgit/pkg-security/dsniff.git/

I will be maintained under the umbrella of pkg-security tools team.

Greetings,
Marcos