Bug#1076624: netplug: /sbin/ip no longer exists

[Pali Rohár]

Hello, I have prepared a quick fix version 1.2.9.2-5:
https://mentors.debian.net/package/netplug/

Please look at it, if you are happy with it.

Note that mentioned script is part of the application and not of the
debian packaging files. /sbin/ip worked fine since 2004, so I have not
idea why somebody has to break all existing applications which use
/sbin/ip by removing this binary. But seems that it is common now to
break support for existing / already written applications, ah :-(

On Saturday 20 July 2024 09:53:59 Vincent Lefevre wrote:
> Package: netplug
> Version: 1.2.9.2-4
> Severity: grave
> Justification: renders package unusable
> 
> /etc/netplug/netplug contains
> 
> probe)
> exec /sbin/ip link set "$dev" up >/dev/null 2>&1
> ;;
> 
> but /sbin/ip no longer exists:
> 
> iproute2 (6.10.0-1) unstable; urgency=medium
> 
>   The legacy /usr/sbin/ip symlink has been dropped. /usr/bin/ip has been
>   available since Buster (oldoldstable) and can be used unconditionally
>   everywhere.
> 
>  -- Luca Boccassi   Fri, 19 Jul 2024 10:36:13 +0100
> 
> As said, it should have been replaced since oldoldstable!
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
> (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages netplug depends on:
> ii  iproute2   6.9.0-1
> ii  libc6  2.38-13
> ii  sysvinit-utils [lsb-base]  3.09-2
> 
> netplug recommends no packages.
> 
> netplug suggests no packages.
> 
> -- Configuration Files:
> /etc/netplug/netplug changed [not included]
> 
> -- no debconf information
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1058767: netplug: unmaintained

[Pali Rohár]

On Wednesday 20 December 2023 22:32:38 Chris Hofstaedtler wrote:
> Hi,
> 
> * Pali Rohár  [231216 11:35]:
> > On Friday 15 December 2023 21:56:01 Chris Hofstaedtler wrote:
> > Hello, I talked with the author of the netplug (Bryan O'Sullivan) and I
> > got permission to continue working on this project. I can continue
> > maintaining this package on Debian, so please let me know what is needed
> > to fix for preventing its removal. Thanks.
> 
> Well, the immediate thing to do is: close this bug.

Ok, I have closed it.

> But the more important thing: actually maintain the package,
> including ongoing quality work in the packaging, responding
> to/fixing bugs, etc.
> 
> If I were in your shoes, I'd make sure to know if/where the users of
> this package are. If all users are using vyos, then maybe its better
> maintained as part of vyos, and removed from Debian.
> Debian has a number of other things that can react to network
> events, some of those have active upstreams ...
> 
> Best,
> Chris

I'm going to ask vyos what they think about it and decide next steps
then. Thanks.

Bug#1058767: closing 1058767

[Pali Rohár]

close 1058767 
thanks

Bug#1058767: netplug: unmaintained

[Pali Rohár]

On Friday 15 December 2023 21:56:01 Chris Hofstaedtler wrote:
> Source: netplug
> Version: 1.2.9.2-3.2
> Severity: serious
> 
> I'm filing this to get netplug removed from testing, with the goal
> of removing it from unstable later, and before that happens, anyone
> who wants to actually maintain this package can speak up.
> 
> As demonstrated today, having packages in stable that end up used in
> downstream distros, and at the same time being completely
> unmaintained in Debian for ~7 years is bad for everybody.
> 
> If you like to keep netplug in Debian, please start maintaining it
> and then close this bug.
> 
> Otherwise I'll also file an RM bug for unstable later in this
> development cycle.
> 
> Chris

Hello, I talked with the author of the netplug (Bryan O'Sullivan) and I
got permission to continue working on this project. I can continue
maintaining this package on Debian, so please let me know what is needed
to fix for preventing its removal. Thanks.

Bug#982717: udfclient: FTBFS: bmake[1]: no target to make.

[Pali Rohár]

On Monday 15 February 2021 18:11:16 Dennis Filder wrote:
> The current bmake backend for debhelper no longer inherits from the
> autoconf backend.  The attached patch devises an override that
> restores the old behaviour, and I've verified that it works.

Hello Dennis! Thank you for investigation and the patch. Will you update
also the package? Or should I do it? Note that I do not have Debian
Developer permissions so I can update new version of package only to
mentors server (which takes a long to appear in Debian archive...).

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#982717: udfclient: FTBFS: bmake[1]: no target to make.

[Pali Rohár]

On Saturday 13 February 2021 18:32:17 Lucas Nussbaum wrote:
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> >  debian/rules build
> > dh build --buildsystem=bmake
> >dh_update_autotools_config -O--buildsystem=bmake
> > install -d debian/.debhelper/bucket/files
> > cp -an --reflink=auto config.guess 
> > debian/.debhelper/bucket/files/420138cb266d63505ec54f169a34e1cc9aba80dc20a1eeac76b7bf5c9e5ff74e.tmp
> > mv 
> > debian/.debhelper/bucket/files/420138cb266d63505ec54f169a34e1cc9aba80dc20a1eeac76b7bf5c9e5ff74e.tmp
> >  
> > debian/.debhelper/bucket/files/420138cb266d63505ec54f169a34e1cc9aba80dc20a1eeac76b7bf5c9e5ff74e
> > cp -f /usr/share/misc/config.guess ./config.guess
> > cp -an --reflink=auto config.sub 
> > debian/.debhelper/bucket/files/6585881331b69439aec3e94b9167983f9c3609b1b5dca9fa77d6941a3f79ccc2.tmp
> > mv 
> > debian/.debhelper/bucket/files/6585881331b69439aec3e94b9167983f9c3609b1b5dca9fa77d6941a3f79ccc2.tmp
> >  
> > debian/.debhelper/bucket/files/6585881331b69439aec3e94b9167983f9c3609b1b5dca9fa77d6941a3f79ccc2
> > cp -f /usr/share/misc/config.sub ./config.sub
> >dh_autoreconf -O--buildsystem=bmake
> > find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' 
> > -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f 
> > -exec md5sum {} + -o -type l -printf "symlink  %p
> > " > debian/autoreconf.before
> > grep -q ^XDT_ configure.ac
> > autoreconf -f -i
> > find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*' 
> > -o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f 
> > -exec md5sum {} + -o -type l -printf "symlink  %p
> > " > debian/autoreconf.after
> >dh_auto_configure -O--buildsystem=bmake
> >dh_auto_build -O--buildsystem=bmake
> > bmake
> > bmake[1]: no target to make.
> > 
> > bmake[1]: stopped in /<>
> > dh_auto_build: error: bmake returned exit code 2

Hello Lucas!

This looks like a bug in dh_auto_configure. dh_autoreconf correctly
started autoreconf but dh_auto_configure did not start ./configure.
So ./configure did not generated Makefile and bmake complained.

> > make: *** [debian/rules:8: build] Error 25
> 
> The full build log is available from:
>http://qa-logs.debian.net/2021/02/13/udfclient_0.8.11-1_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with me
> so that we can identify if something relevant changed in the meantime.
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#954189: Backport to buster?

[Pali Rohár]

On Monday 27 April 2020 11:15:30 Paul van Tilburg wrote:
> Hi!
> 
> This bug report was originally about buster and in my opinion a
> backport is necessary (stretch also had one). I reckon mostly servers
> use Let's Encrypt, and they mostly run Debian buster/stable.
> Given that upstream doesn't seem to change to that much, is that a
> possibility?
> 
> I didn't reopen this bug report and will leave that to the maintainer's
> discretion, however, I did want to mention this.

Yes, I reported this bug to Debian Buster, but in Buster release this
bug is not still fixed. So I think it should stay open.

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#954189: acmetool: Buster acmetool stops working in June 1, 2020

[Pali Rohár]

Package: acmetool
Version: 0.0.62-3+b11
Severity: grave

Hello! I'm using Debian Buster 10.3 on servers with acmetool for
updating Let's encrypt certificates and I got following email from
letsencrypt:


According to our records, the software client you're using to get Let's
Encrypt TLS/SSL certificates issued or renewed at least one HTTPS 
certificate
in the past two weeks using the ACMEv1 protocol. Here are the details of one
recent ACMEv1 request from each of your account(s):

...
User agent:  acmetool acmeapi Go-http-client/1.1 linux/amd64
...

Beginning June 1, 2020, we will stop allowing new domains to validate using
the ACMEv1 protocol. You should upgrade to an ACMEv2 compatible client 
before
then, or certificate issuance will fail. For most people, simply upgrading 
to
the latest version of your existing client will suffice. You can view the
client list at: https://letsencrypt.org/docs/client-options/


It means that acmetool package which is in Debian Buster stops working
in June 1, 2020. So please update this package in Debian Buster
repository to a new version which supports ACMEv2 protocol.

Also I would suggest to put acmetool version number into User agent
string so it could be easier to identify exact version which is used.

I'm marking this issue with severity grave as it matches that
description "makes the package in question unusable", which really
happens in two months and few days.

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#916006: udftools FTBFS with glibc 2.28

[Pali Rohár]

On Sunday 09 December 2018 13:20:49 Adrian Bunk wrote:
> main.c: In function 'is_whole_disk':
> main.c:170:8: warning: implicit declaration of function 'major' 
> [-Wimplicit-function-declaration]
>   maj = major(st.st_rdev);
> ^
> main.c:171:8: warning: implicit declaration of function 'minor'; did you mean 
> 'mknod'? [-Wimplicit-function-declaration]
>   min = minor(st.st_rdev);
> ^

Hi! This problem is already fixed in upstream udftools git repository
and I'm planning to release a new version of udftools in this month,
including new Debian package upload.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#902452: Kamailio TLS module in Debian Stretch is unusable

[Pali Rohár]

Package: kamailio-tls-modules
Version: 4.4.4-2+deb9u1
Severity: grave

After installation of kamailio-tls-modules package on Debian Stretch and
enabling TLS support in kamailio.cfg via #!define WITH_TLS I'm just
getting following fatal error (in syslog):

Jun 27 00:19:57 pali /usr/sbin/kamailio[15055]: : tls [tls_init.c:651]: 
init_tls_h(): ERROR: tls: init_tls_h: openssl compile options mismatch: library 
has kerberos support disabled and Kamailio tls enabled (unstable 
configuration)#012 (tls_force_run in kamailio.cfg will override this check)
Jun 27 00:19:57 pali /usr/sbin/kamailio[15055]: CRITICAL:  [main.c:2592]: 
main(): could not initialize tls, exiting...

And kamailio refuse to start.

Therefore current version of kamailio-tls-modules package in Debian
Stretch is unusable as TLS support which it provides cannot be enabled.

It looks like this package needs to be (re)compiled against correct
version of openssl with correct configure options or it needs to runtime
depends on correct version of openssl libraries.

As package currently does not work at all, I'm marking this issue with
severity grave.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686

[Pali Rohár]

Package: libemail-address-perl
Version: 1.908-1
Severity: grave

Hi! Perl Email::Address module has CVE-2015-7686 defect, which means 
that for specially prepared input, parse() method can take exponential 
time for processing input buffer. Primary use of Email::Address was to 
parse From/To/Cc email headers, which means that attacker could DOS 
server application which uses this module for parsing emails.

Since 2015 there was no new release of Email::Address module and 
meanwhile I created new module named: Email::Address::XS

https://metacpan.org/pod/Email::Address::XS

It has backward compatible API, but uses completely different way how to 
parse input. It is written in C, instead of perl regexps and uses parts 
of dovecot parses which was already widely tested.

Fixing current Email::Address is very hard if we want to aim two things: 
1) RFC-correctness 2) polynomial time complexity in worst case

This is reason why I chose to write Email::Address::XS from scratch 
instead of hacking Email::Address.

Due to fact that there is no new version of Email::Address for 2 years 
which could address CVE-2015-7686 defect, I would suggest to drop 
libemail-address-perl package from Debian completely.

That is probably not easy as more packages depends on libemail-address-
perl (Email::Address module). But because Email::Address::XS has 
backward compatible API, it can be used as drop-in-replacement for 
Email::Address.

Something like sed 's/Email::Address/Email::Address::XS/g' on sources of 
3rd applications/modules should be enough.

And if not, I can help with porting existing perl applications in Debian 
which uses Email::Address, to be compatible with Email::Address::XS.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#827048: kopete+otr send messages unencrypted without notice

[Pali Rohár]

On Sat, 11 Jun 2016 17:43:14 +0200 Francois Gerin  
wrote:
> Subject: kopete+otr send messages unencrypted without notice
> Package: kopete
> Version: 4:4.14.1-2
> Justification: user security hole
> Severity: grave
> Tags: security upstream
> 
> Dear Maintainer,
> 
> Using kopete with OTR plugin lead to messages sent unencrypted without 
> notice. (I discovered this 
after sending sensitive credentials while helping some people remotely...)
> 
> After checking that OTR encryption was working ("private session started" 
> notice), I was helping 
people remotely while feeling secure. After a first restart of the other end 
computer, I saw a 
notification saying that OTR session was refreshed (which is normal$
> Later on, I detected that, in fact, the people at the other end were getting 
> all my messages 
unencrypted... despite of the notification I got on my end.
> First detection was done with "Opportunistic" policy on both sides. Then I 
> tested again with a 
full restart at both ends + "Always" policy for OTR plugin. Same result: when 
the other end restarts 
and I keep my session opened, I get the "OTR session refreshed"$
> 
> Several accounts credentials were sent in clear, among which for a root 
> account.
> 
> When I pay attention for the "OTR session refreshed" message, and especially 
> when "Always" policy 
is used on both sides, I would expect to be alerted that some internal issue 
canceled the 
encryption, no matters what's the reason.
> The notifications are not reliable, and we're talking about a secure 
> messaging system here 
(OTR)... This forced me to uninstall kopete, since I cannot rely on it for 
secure messaging.
> 
> Remarks:
>  - Two bugs already mention this in the bug tracking of kopete at 
https://bugs.kde.org/show_bug.cgi?id=274099 and 
https://bugs.kde.org/show_bug.cgi?id=362535
>  - While the kopete team cannot solve this (old) issue, I cannot believe 
> debian can go on 
propagating this dangerous thing and the heavy security consequences to the 
community, among which 
are key journalists.
>  - Until it is fixed, the OTR plugin should be disabled for kopete, or the 
> kopete UI should at 
least alert about its experimental support status in red uppercases.
> 
> Thanks a lot in advance for any action, to disable it or fix it!
> 
> 
> 
> 
> -- System Information:
> Debian Release: 8.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages kopete depends on:
> ii  kde-runtime 4:4.14.2-2
> ii  kdepim-runtime  4:4.14.2-3
> ii  libc6   2.19-18+deb8u4
> ii  libexpat1   2.1.0-6+deb8u3
> ii  libgadu31:1.12.0-5
> ii  libgif4 4.1.6-11+deb8u1
> ii  libglib2.0-02.42.1-1+b1
> ii  libidn111.29-1+deb8u1
> ii  libjasper1  1.900.1-debian1-2.4+deb8u1
> ii  libkabc44:4.14.2-2+b1
> ii  libkcmutils44:4.14.2-5
> ii  libkde3support4 4:4.14.2-5
> ii  libkdecore5 4:4.14.2-5
> ii  libkdeui5   4:4.14.2-5
> ii  libkdnssd4  4:4.14.2-5
> ii  libkemoticons4  4:4.14.2-5
> ii  libkhtml5   4:4.14.2-5
> ii  libkio5 4:4.14.2-5

Hi! This problem is fixed in Kopete 16.12.

Debian KDE team now needs to update Kopete package...

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#817360: aspell-sk: Removal of debhelper compat 4

[Pali Rohár]

On Wednesday 29 June 2016 21:17:38 Pali Rohár wrote:
> Hi! Is somebody already migrating package aspell-sk to new debhleper?
> If not, I can look at it.

No answer for 4 days, so I uploaded nmu update to mentors.debian.net.

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#817360: aspell-sk: Removal of debhelper compat 4

[Pali Rohár]

Hi! Is somebody already migrating package aspell-sk to new debhleper?
If not, I can look at it.

-- 
Pali Rohár
pali.ro...@gmail.com


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