Bug#1079859: ITP: python-ntruprime -- python-ntruprime

[Jan Mojzis]

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

* Package name: python-ntruprime
  Version : 20240825.1
  Upstream Contact: Jan Mojzis 
* URL : https://github.com/janmojzis/python-ntruprime
* License : CC0
  Programming Lang: Python
  Description : Python wrapper around libntruprime library


libntruprime is a Streamlined NTRU Prime microlibrary.
libntruprime has a very simple stateless API based on the SUPERCOP API,
with wire-format inputs and outputs, providing functions that directly match
the KEM operations provided by Streamlined NTRU Prime, such as functions

ntruprime1277.keypair()
ntruprime1277.enc()
ntruprime1277.dec()
for the ntruprime1277 KEM.

This package is related to: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079669

I'm going to maintain the package using https://salsa.debian.org/
It is being prepared here: https://salsa.debian.org/janmojzis/python-ntruprime
I need sponsor for the first upload (I'm DM).

Jan

Bug#1070321: transition: nginx ABI change: nginx-abi-1.24.0-1 -> nginx-abi-1.26.0-1

[Jan Mojzis]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: ng...@packages.debian.org
Control: affects -1 + src:nginx

Hi,

a new version 1.26.0 of nginx has been released.

I have uploaded version 1.26.0-1~exp1 to the experimental and
would like to upload the new nginx 1.26.0-1 version to the unstable.

And with the upload of 1.26.0-1 nginx to unstable,
the nginx ABI version changes at the same time. Previous ABI 
nginx-abi-1.24.0-1, new ABI nginx-abi-1.26.0-1.

Therefore, we would also need to rebuild all 3rd party nginx modules 
(libnginx-mod-* packages)
which depends on nginx. Hence the transition request.

Furthermore, this upload/rebuild solves the problem that arises at time_t 64 
transition:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069997


Ben file:

title = "nginx";
is_affected = .build-depends ~ /nginx-dev/;
is_good = .depends ~ /nginx-abi-1.26.0-1/;
is_bad = .depends ~ /nginx-abi-1.24.0-1/;


Please when the nginx 1.26.0-1 arives to the unstable,
can You schedule binNMUs for the above mentioned packages in unstable on all 
architectures.

Thanks
Jan

PS: ABI versioning is a relatively new feature in nginx, so this is the first 
transition request.
And any ideas how to automate the transitions are welcome

Bug#1069997: nginx: NGX_MODULE_SIGNATURE has changed on 32-bit t64 architectures, but the ${nginx:abi} substvar has not

[Jan Mojzis]

Thanks for the report,
I am preparing nginx release 1.26.0, and the updated ABI version will be part 
of it.

Jan

Bug#1068207:

[Jan Mojzis]

Hi,

'https://wiki.debian.org/qa.debian.org/FTBFS'
see:
2024-03-13 -Werror=implicit-function-declaration
... In dpkg version 1.22.6, the compiler flag 
-Werror=implicit-function-declaration was enabled by default for all 
architectures in build flags
...
...


You  need to patch libnginx-mod-http-modsecurity source code:

~~~
diff --git a/config b/config
index c6e7467..3bf06a8 100644
--- a/config
+++ b/config
@@ -10,7 +10,8 @@
 
 ngx_feature_name=
 ngx_feature_run=no
-ngx_feature_incs="#include "
+ngx_feature_incs="#include 
+#include "
 ngx_feature_libs="-lmodsecurity"
 ngx_feature_test='printf("hello");'
 ngx_modsecurity_opt_I=
~~~

Jan

Bug#1055742: libnginx-mod-http-cache-purge: Segmentation fault caused by PURGE requests

[Jan Mojzis]

Hi,

how can I reproduce the segmentation fault?

I prepared a simple autopkg test
here: 
"https://salsa.debian.org/nginx-team/libnginx-mod-http-cache-purge/-/blob/main/debian/tests/purgetest?ref_type=heads";
but I didn't catch the segfault, the autopkgtest works with the 1.22.1 / 1.24.0 
nginx version.
The problem will probably be some special case related to the 
proxy_cookie_flags option.

Before applying the patch, I would like to have an autopkgtest to verify that 
the patch  works.

Jan

Bug#1053568: ITP: python-lib25519 -- Python wrapper around lib25519 library

[Jan Mojzis]

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

* Package name: python-lib25519
  Version : 20231006
  Upstream Contact: Jan Mojzis 
* URL : https://github.com/janmojzis/python-lib25519
* License : CC0
  Programming Lang: Python
  Description : Python wrapper around lib25519 library


lib25519 is a microlibrary for the X25519 encryption system and the Ed25519
signature system, both of which use the Curve25519 elliptic curve.

lib25519 has a very simple stateless API based on the SUPERCOP API, with
wire-format inputs and outputs, providing functions that directly match the
central cryptographic operations in X25519 and Ed25519:

lib25519.x25519.keypair(pk, sk): X25519 key generation
lib25519.x25519.dh(k, pk, sk): shared-secret generation
lib25519.ed25519.keypair(pk, sk): Ed25519 key generation
lib25519.ed25519.sign(sm, &smlen, m, mlen, sk): signing
lib25519.ed25519.open(m, &mlen, sm, smlen, pk): verification + message recovery

This package is related to: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051553


I'm going to maintain the package using https://salsa.debian.org/
It is being prepared here: https://salsa.debian.org/janmojzis/python-lib25519
I need sponsor for the first upload (I'm DM).

Jan

Bug#1053569: ITP: python-mceliece -- Python wrapper around libmceliece library

[Jan Mojzis]

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

* Package name: python-mceliece
  Version : 20231006
  Upstream Contact: Jan Mojzis 
* URL : https://github.com/janmojzis/python-mceliece
* License : CC0
  Programming Lang: Python
  Description : Python wrapper around libmceliece library


libmceliece is a Classic McEliece microlibrary.
libmceliece has a very simple stateless API based on the SUPERCOP API,
with wire-format inputs and outputs, providing functions that directly match
the KEM operations provided by Classic McEliece, such as functions

mceliece6960119.keypair()
mceliece6960119.enc()
mceliece6960119.dec()
for the mceliece6960119 KEM

This package is related to: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050531

I'm going to maintain the package using https://salsa.debian.org/
It is being prepared here: https://salsa.debian.org/janmojzis/python-mceliece
I need sponsor for the first upload (I'm DM).

Jan

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Jan Mojzis]

> 
> Great!
> 
> I have created it -- can you push everything there, and I will do a
> review via a merge request to that repository?
> 

Ready for the review:

Note:
- currently all ASM implementations are disabled,
so that we don't have a problem with a reproducible-build/symbols/PIC/etc... in 
the first phase

Jan

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Jan Mojzis]

> I would be happy to help review, co-maintain and upload this package.

Great, thank You.


First prototype for review:
'https://salsa.debian.org/janmojzis/lib25519'

if it's ok
can you please create 'salsa.debian.org/debian/lib25519 
',
I will move it there.

Currently without autopkgtest,
I will add it when librandombytes package  arrives in unstable.


Thanks
Jan

Bug#1051553: ITP: lib25519 -- X25519/Ed25519 microlibrary

[Jan Mojzis]

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

* Package name: lix25519
  Version : 20230630
  Upstream Authort: Daniel J. Bernstein
* URL : https://lib25519.cr.yp.to/
* License : LicenseRef-PD-hp OR CC0-1.0 OR 0BSD OR MIT-0 OR MIT
  Programming Lang: C
  Description : X25519 microlibrary


lib25519 is a microlibrary for the X25519 encryption system and the Ed25519 
signature system, both of which use the Curve25519 elliptic curve. Curve25519 
is the fastest curve in TLS 1.3, and the only curve in Wireguard, Signal, and 
many other applications (see Nicolai Brown's page 
https://ianix.com/pub/curve25519-deployment.html).

lib25519 has a very simple stateless API based on the SUPERCOP API, with 
wire-format inputs and outputs, providing functions that directly match the 
central cryptographic operations in X25519 and Ed25519:

lib25519_dh_keypair(pk,sk): X25519 key generation
lib25519_dh(k,pk,sk): shared-secret generation
lib25519_sign_keypair(pk,sk): Ed25519 key generation
lib25519_sign(sm,&smlen,m,mlen,sk): signing
lib25519_sign_open(m,&mlen,sm,smlen,pk): verification + message recovery
Internally, lib25519 includes implementations designed for performance on 
various CPUs, implementations designed to work portably across CPUs, and 
automatic run-time selection of implementations.

lib25519 is intended to be called by larger multi-function libraries, including 
libraries in other languages via FFI. The idea is that lib25519 will take 
responsibility for the details of X25519/Ed25519 computation, including 
optimization, timing-attack protection, and eventually verification, freeing up 
the calling libraries to concentrate on application-specific needs such as 
protocol integration. Applications can also call lib25519 directly.

I'm using this library and I'm going to maintain using https://salsa.debian.org/
I need sponsor for the first upload (I'm DM).

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Jan Mojzis]

> https://github.com/swananan/lua-resty-core/tree/support_pcre2
uploaded: 0.1.27-2~exp1

> https://github.com/swananan/lua-nginx-module/commits/support_pcre2
uploaded: 1:0.10.25-2~exp2

> https://github.com/swananan/stream-lua-nginx-module/commits/support_pcre2
not in debian

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Jan Mojzis]

Hi,
I've uploaded experimental version with the PCRE2 patch included
1:0.10.25-2~exp1 to the experimental.

Jan


On Tue, 29 Aug 2023 15:50:52 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?= 
 wrote:
> Le mar. 29 août 2023 à 15:43, Thomas Ward  a écrit :
> 
> > I apoligize I was thinking Lua deps not PCRE.
> >
> > However, I did more digging. OpenResty has been on NGINX cofe version
> > 1.21.4 for the longest time.  They do not have PCRE2 support in their
> > system.  As this is an OpenResty-originating module the 4th requirement as
> > stated in the linked GitHub issue is not met.
> >
> > I would not be so sure that "next update" will have a fix if OpenResty
> > core does not support PRCE2 (1.21.5 nginx introduced PCRE2 core
> > requirement/build fixes, OpenResty never inccuded that).  The reason PCRE3
> > is still used here in the Lua module is the custom workaround of mixing
> > PCRE2 nginx and PCRE3 Lua which use different build flags at compile time
> > with the linking options.
> >
> > Therefore, we need to not make assumptions and watch this closely.  If
> > there is not movement in a reasonable time period, then we may have to drop
> > this module from Debian due to PCRE3 being obsolete.
> >
> 
> Actually, openresty has started supporting nginx 1.25.1 recently:
> 
> [feature: upgrade nginx core to 1.25.1 which supports HTTP3](
> https://github.com/openresty/openresty/commit/6278b1aeae0593b17d3143aeb60a216f73b6bb1d)[feature:
> [upgrade nginx core to 1.25.1](
> https://github.com/openresty/stream-lua-nginx-module/commit/d48f057f18eb1f33123bf62be49c735c5cb98f16
> )
> [upgrade nginx core to 1.25.1](
> https://github.com/openresty/lua-nginx-module/commit/e69fd3de281f31804857aa6dc0b8e79055716138
> )
> >
> >
> Considering the work of the author of these patches, I'd be surprised if it
> wasn't finished soon (right now, only stream-lua-nginx has no support for
> pcre2).

Bug#1050531: ITP: libmceliece -- Classic McEliece microlibrary

[Jan Mojzis]

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

* Package name: libmceliece
  Version : 20230612
  Upstream Authort: Daniel J. Bernstein
* URL : https://lib.mceliece.org
* License : CC0
  Programming Lang: C
  Description : Classic McEliece microlibrary


libmceliece is a Classic McEliece microlibrary.
libmceliece has a very simple stateless API based on the SUPERCOP API,
with wire-format inputs and outputs, providing functions that directly match
the KEM operations provided by Classic McEliece, such as functions

mceliece6960119_keypair
mceliece6960119_enc
mceliece6960119_dec
for the mceliece6960119 KEM.

Internally, libmceliece is based on the official Classic McEliece software,
specifically the vec implementation (designed to work portably across CPUs) and
he avx implementation (designed for higher performance on Intel/AMD CPUs with
AVX2 instructions). libmceliece includes automatic run-time selection
of implementations.

libmceliece is intended to be called by larger multi-function libraries
(such as traditional cryptographic libraries), including libraries in other
languages via FFI. The idea is that libmceliece takes responsibility for
the details of Classic McEliece computation, including optimization,
timing-attack protection, and (in ongoing work) verification,
freeing up the calling libraries to concentrate on application-specific
needs such as protocol integration. Applications can also call libmceliece
directly.


I'm using this library and I'm going to maintain using https://salsa.debian.org/
I need sponsor for the first upload (I'm DM).

Bug#1032517: [Pkg-nginx-maintainers] Bug#1032517:

[Jan Mojzis]

Unless we find a better solution,
then we will need to rollback the configuration back to nginx-common package.

Bug#1032517: [Pkg-nginx-maintainers] Bug#1032517:

[Jan Mojzis]

> 
> Jan,
> Did default config files in /etc/nginx/  moved from nginx-common to nginx ?

Yes,
config files moved to the nginx package, and nginx-common is empty metapackage 
(since 1.22.1-6).

Jan

Bug#1032517:

[Jan Mojzis]

Hello,
can You please send me the steps how i can reproduce it
- packages list/versions before the upgrade
- exact apt/apt-get command
- packages list/versions after the upgrade

Jan

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Jan Mojzis]

> On 28. 1. 2023, at 21:42, Sam Hartman  wrote:
> 
>>>>>> "Jan" == Jan Mojzis  writes:
> 
> * Package name: randombytes
>  Version : 20230126
>  Upstream Author : Daniel J. Bernstein
> * URL : https://randombytes.cr.yp.to/
> * License : Public domain
> 
> Public domain is problematic  as a license.
> At least under US copyright law, there are very few circumstances when
> something can actually be public domain.
> One example is software written by US government employees.
> But I don't think any of those circumstances apply to this library.
> So I'm not sure the license is okay.

If I understand it correctly, CC0-style public-domain declaration in 
debian/copyright solves the problem.
(learned here: https://lists.debian.org/debian-mentors/2017/09/msg00171.html)

~~~
License: public-domain-CC0-1.0
 Public domain.
 .
 Upstream library is marked as public-domain 
https://randombytes.cr.yp.to/index.html.
 .
 Public-domain mark does not have the same meaning in all jurisdictions,
 to avoid confusion, please follow CC0 1.0 Universal.
 The complete text of the CC0 license, version 1.0,
 can be found in /usr/share/common-licenses/CC0-1.0.
~~~

Or am I wrong?

> 
> I'll  also admit to being skepticle of the utility of such a library
> given the getrandom() API in libc.

The library internally uses getrandom().
The primary bonus is in portability and usability. The library (namely 
randombytes-kernel) uses one of the variants
getrandom(), getentropy(), "/dev/urandom" and the user/aplication doesn't need 
to care what resource is on a given operating system available.
And the user/aplication also doesn't have to worry about whether the system has 
enough entropy (e.g. /dev/urandom initialized).
Randombytes() simply waits/blocks until there is enough entropy.

Jan

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Jan Mojzis]

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

* Package name: randombytes
  Version : 20230126
  Upstream Author : Daniel J. Bernstein
* URL : https://randombytes.cr.yp.to/
* License : Public domain
  Programming Lang: C
  Description : Library generating fresh randomness


 librandombytes is a public-domain library providing a simple API for
 applications generating fresh randomness: include ,
 call randombytes(x, xbytes) whenever desired to generate fresh random bytes
 x[0], x[1], ..., x[xbytes-1], and link with -lrandombytes.
 .
 Random bytes are often used directly in applications. Random bytes are also
 the foundation of more complicated random objects, such as random integers
 in a limited interval, random floating-point numbers from a (nearly) normal
 distribution, and random keys used in public-key cryptosystems. librandombytes
 is dedicated to obtaining fresh random bytes in the first place, and leaves
 it to higher-level libraries to convert those bytes into other types of random
 objects.
 .
 librandombytes aims for the following stringent randomness goal: no feasible
 computation will ever be able to tell the difference between the output bytes
 and true randomness (independent uniformly distributed random bytes). This
 makes the randombytes() output suitable for use in applications ranging from
 simulations to cryptography.

I'm using this library and I'm going to maintain using https://salsa.debian.org/
I need sponsor for the first upload (I'm DM).

Bug#1029433: luajit2: new upstream version 2.1-20230119

[Jan Mojzis]

Package: luajit2
Version: 2.1-20220411-5
Severity: normal

Dear Maintainer,

the latest version of luajit2 2.1-20230119 has been released,
contains mostly bug fixes,
so it would be worth updating the debian version as well
before bookworm freeze.

Thanks
Jan

Bug#1000013: Bug #1000013:nginx: depends on obsolete pcre3 library

[Jan Mojzis]

Currently nginx is compiled with the PCRE3 library and all modules
using PCRE must be compiled with the same version (PCRE3).

I made practical test,
nginx compiled with PCRE2 and lua compiled with PCRE3 and didn't work.

Bug#1001503: ITP: tlswrapper -- TLS encryption wrapper

[Jan Mojzis]

20221227 version released:
- LICENCE updated from public-domain to CC0
- updated examples and linked examples.md from README.md
- added more error log messages when proxy-protocol is used

+ in debian packaging I've temporary disabled two autopkg tests,
problem in newest curl 7.87.0 (curl --haproxy-protocol ... is currently broken),
... the curl problem is already fixed in the upstream 
https://github.com/curl/curl/commit/db5f833cc72a1ceb812dde55cf926858f61c086b

Bug#1001503: ITP: tlswrapper -- TLS encryption wrapper

[Jan Mojzis]

Hi,

> The examples are interesting, maybe tlswrapper documentation should include 
> them.
> I can sponsor this, but I have a feeling that won't be accepted before 
> freeze. Let's see.

Examples are taken from the upstream repo and from the manual pages,
I edited the upstream README.md to link to these examples.

> 
> For the salsa repo: let's keep using yours for now, and see in which team it 
> should go later.

OK

Bug#1001503: ITP: tlswrapper -- TLS encryption wrapper

[Jan Mojzis]

Hi,

Tlswrapper (similar to stunnel) adds TLS encryption functionality to programs 
without modifying their code.

The fundamental difference against stunnel is in the approach to security.
Tlswrapper s tries to defend against all possible bugs in the TLS library 
itself and
tries to mitigate the impact of such a bug.

It uses the capabilities that Unix OS has:

# Separate process for every connection
The tlswrapper is executed from systemd.socket/inetd/tcpserver/... which runs 
separate instance of tlswrapper for each TLS connection. It ensures that a 
vulnerability in the code (e.g. bug in the TLS library) can't be used to 
compromise the memory of another connection.

# Separate process for network connection and separate process for secret-key 
operation
To protect against secret-information leaks to the network connection (such 
Heartbleed) tlswrapper runs two independent processes for every TLS connection. 
One process holds secret-keys and runs secret-keys operations and second talks 
to the network. Processes communicate with each other through UNIX pipes.

# JAIL - Privilege separation, filesystem isolation, limits
The tlswrapper processes run under dedicated non-zero uid to prohibit kill, 
ptrace, etc. Is chrooted into an empty, unwritable directory to prohibit 
filesystem access. Sets ulimits to prohibit new files, sockets, etc. Sets 
ulimits to prohibit forks.


Example of how to use tlswrapper to protect mail protocols:

- run dovecot IMAPS service on port 993, authorization using client certs, and 
run under user extracted from client certificate from commonName:
tcpserver -HRDl0 0.0.0.0 993 \
/usr/bin/tlswrapper -U commonName -f /etc/ssl/sslcert.pem -a /etc/ssl/ca.pem \
/usr/lib/dovecot/imap

- run old QMAIL qmail-smtpd SMTP service on port 25 with STARTTLS enabled 
(without patching QMAIL)
tcpserver -HRDl0 0 25 \
tlswrapper -v -n -f /etc/ssl/cert.pem \
tlswrapper-smtp -v -u qmaild \
qmail-smtpd

In the example is used tcpserver (from deb. package ucspi-tcp) but similary can 
be used from e.g. systemd/inetd/... etc. .

Jan


> On 23. 12. 2022, at 10:02, Jérémy Lal  wrote:
> 
> Package: wnpp
> Followup-For: Bug #1001503
> 
> Can you explain a bit more how one will be able to use tlswrapper ?
> 
> Maybe compare it to available solutions like stunnel ?
> 
> Thanks,
> 
> Jérémy

Bug#1025515: ITP: libnginx-mod-http-brotli -- Nginx module libnginx-mod-http-brotli

[Jan Mojzis]

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

* Package name: libnginx-mod-http-brotli
  Version : 1.0.0rc
  Upstream Author : Google Inc
* URL : https://github.com/google/ngx_brotli
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-brotli module for Nginx


libnginx-mod-http-brotli is new module for Nginx web server.
it is a set of two nginx modules:
libnginx-mod-http-brotli-filter - filter module - used to compress responses 
on-the-fly,
libnginx-mod-http-brotli-static - used to serve pre-compressed files.

I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-brotli

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024379: ITP: libnginx-mod-http-upstream-fair -- Nginx module libnginx-mod-http-upstream-fair

[Jan Mojzis]

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

* Package name: libnginx-mod-http-upstream-fair
  Version : git20120408
  Upstream Author : Grzegorz Nosek
* URL : https://github.com/gnosek/nginx-upstream-fair
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-upstream-fair module for Nginx


libnginx-mod-http-upstream-fair module is currently a part of Debian Nginx 
package.

I would like to move the module to the separate package 
libnginx-mod-http-upstream-fair.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-upstream-fair
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-upstream-fair

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024377: ITP: libnginx-mod-nchan -- Nginx module libnginx-mod-nchan

[Jan Mojzis]

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

* Package name: libnginx-mod-nchan
  Version : 1.3.5
  Upstream Author : Leo Ponomarev
* URL : https://github.com/slact/nchan
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-nchan module for Nginx


libnginx-mod-nchan module is currently a part of Debian Nginx package.

I would like to move the module to the separate package libnginx-mod-nchan.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-nchan
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-nchan

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024374: ITP: libnginx-mod-rtmp -- Nginx module libnginx-mod-rtmp

[Jan Mojzis]

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

* Package name: libnginx-mod-rtmp
  Version : 1.2.2
  Upstream Author : Roman Arutyunyan
* URL : https://github.com/arut/nginx-rtmp-module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-rtmp module for Nginx


libnginx-mod-rtmp module is currently a part of Debian Nginx package.

I would like to move the module to the separate package libnginx-mod-rtmp.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-rtmp
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-rtmp

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024372: ITP: libnginx-mod-http-geoip2 -- Nginx module libnginx-mod-http-geoip2

[Jan Mojzis]

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

* Package name: libnginx-mod-http-geoip2
  Version : 3.4
  Upstream Author : Lee Valentine
* URL : https://github.com/leev/ngx_http_geoip2_module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-geoip2 module for Nginx


libnginx-mod-http-geoip2 module is currently a part of Debian Nginx package.

I would like to move the module to the separate package 
libnginx-mod-http-geoip2.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-geoip2
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-geoip2

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024371: ITP: libnginx-mod-http-dav-ext -- Nginx module libnginx-mod-http-dav-ext

[Jan Mojzis]

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

* Package name: libnginx-mod-http-dav-ext
  Version : 3.0.0
  Upstream Author : Roman Arutyunyan
* URL : https://github.com/arut/nginx-dav-ext-module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-dav-ext module for Nginx


libnginx-mod-http-dav-ext module is currently a part of Debian Nginx package.

I would like to move the module to the separate package 
libnginx-mod-http-dav-ext.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-dav-ext
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-dav-ext

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024370: ITP: libnginx-mod-http-subs-filter -- Nginx module libnginx-mod-http-subs-filter

[Jan Mojzis]

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

* Package name: libnginx-mod-http-subs-filter
  Version : 0.6.4
  Upstream Author : Weibin Yao
* URL : 
https://github.com/yaoweibin/ngx_http_substitutions_filter_module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-subs-filter module for Nginx


libnginx-mod-http-subs-filter module is currently a part of Debian Nginx 
package.

I would like to move the module to the separate package 
libnginx-mod-http-subs-filter.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-subs-filter
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-subs-filter

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024369: ITP: libnginx-mod-http-fancyindex -- Nginx module libnginx-mod-http-fancyindex

[Jan Mojzis]

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

* Package name: libnginx-mod-http-fancyindex
  Version : 0.5.2
  Upstream Author : Adrian Perez
* URL : https://github.com/aperezdc/ngx-fancyindex
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-fancyindex module for Nginx


libnginx-mod-http-fancyindex module is currently a part of Debian Nginx package.

I would like to move the module to the separate package 
libnginx-mod-http-fancyindex.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-fancyindex
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-fancyindex

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024213: ITP: libnginx-mod-http-cache-purge -- Nginx module libnginx-mod-http-cache-purge

[Jan Mojzis]

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

* Package name: libnginx-mod-http-cache-purge
  Version : 2.3
  Upstream Author : FRiCKLE 
* URL : https://github.com/FRiCKLE/ngx_cache_purge
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-cache-purge module for Nginx


libnginx-mod-http-cache-purge module is currently a part of Debian Nginx 
package.

I would like to move the module to the separate package 
libnginx-mod-http-cache-purge.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-cache-purge
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-cache-purge

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024211: ITP: libnginx-mod-http-uploadprogress -- Nginx module libnginx-mod-http-uploadprogress

[Jan Mojzis]

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

* Package name: libnginx-mod-http-uploadprogress
  Version : 0.9.2
  Upstream Author : Brice Figureau
* URL : https://github.com/masterzen/nginx-upload-progress-module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-uploadprogress module for Nginx


libnginx-mod-http-uploadprogress module is currently a part of Debian Nginx 
package.

I would like to move the module to the separate package 
libnginx-mod-http-uploadprogress.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-uploadprogress
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-uploadprogress

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024153: ITP: libnginx-mod-http-echo -- Nginx module libnginx-mod-http-echo

[Jan Mojzis]

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

* Package name: libnginx-mod-http-echo
  Version : 0.63
  Upstream Author : Yichun Zhang
* URL : https://github.com/agentzh/echo-nginx-module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-echo module for Nginx


libnginx-mod-http-echo module is currently a part of Debian Nginx package.

I would like to move the module to the separate package libnginx-mod-http-echo.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-echo
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-echo

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024152: ITP: libnginx-mod-http-auth-pam -- Nginx module libnginx-mod-http-auth-pam

[Jan Mojzis]

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

* Package name: libnginx-mod-http-auth-pam
  Version : 1.5.3
  Upstream Author : Sergio Talens Oliag
* URL : https://github.com/sto/ngx_http_auth_pam_module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-auth-pam module for Nginx


libnginx-mod-http-auth-pam module is currently a part of Debian Nginx package.

I would like to move the module to the separate package 
libnginx-mod-http-auth-pam.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-auth-pam
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-auth-pam

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024151: ITP: libnginx-mod-http-headers-more-filter -- Nginx module libnginx-mod-http-headers-more-filter

[Jan Mojzis]

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

* Package name: libnginx-mod-http-headers-more-filter
  Version : 0.34
  Upstream Author : Yichun Zhang
* URL : https://github.com/agentzh/headers-more-nginx-module
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-headers-more-filter module for Nginx


libnginx-mod-http-headers-more-filter module is currently a part of Debian 
Nginx package.

I would like to move the module to the separate package 
libnginx-mod-http-headers-more-filter.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-headers-more-filter
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-headers-more-filter

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1024150: ITP: libnginx-mod-http-ndk -- Nginx module libnginx-mod-http-ndk

[Jan Mojzis]

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

* Package name: libnginx-mod-http-ndk
  Version : 0.3.2
  Upstream Author : Marcus Clyne
* URL : https://github.com/simpl/ngx_devel_kit
* License : BSD
  Programming Lang: C
  Description : libnginx-mod-http-ndk module for Nginx


libnginx-mod-http-ndk module is currently a part of Debian Nginx package.

I would like to move the module to the separate package libnginx-mod-http-ndk.


I would like to maintain the package using 
https://salsa.debian.org/nginx-team/libnginx-mod-http-ndk
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/libnginx-mod-http-ndk

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1023382:

[Jan Mojzis]

Hello,
in the postinst script, the "ss" command from the iproute2 package is used,
which checks whether TCP port 80 is free or not.
If not, nginx will not start during installation.

commit:
https://salsa.debian.org/nginx-team/nginx/-/commit/cc65b80eb0bebe0e2d61c4e4b413b3bac729cf39
 


Jan

Bug#1000013:

[Jan Mojzis]

currently,
nginx and all modules distributed with it are compatible with PCRE2.

The last problem is with the libnginx-mod-http-lua module,
which PCRE2 does not support.
Issue here: https://github.com/openresty/lua-nginx-module/issues/1984 


Jan

Bug#1018918:

[Jan Mojzis]

Hello,
http_stub_status module is already enabled.

# dpkg -l | grep nginx-core
ii  nginx-core1.22.0-3  
amd64nginx web/proxy server (standard version)

# nginx -v
nginx version: nginx/1.22.0

# nginx -V 2>&1 | grep -o with-http_stub_status_module
with-http_stub_status_module

Bug#1016866: ITP: ngx-lua -- Lua module for Nginx

[Jan Mojzis]

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

* Package name: ngx-lua
  Version : 0.10.21
  Upstream Author : Yichun Zhang (agentzh) 
* URL : https://github.com/openresty/lua-nginx-module
* License : BSD-2-clause
  Programming Lang: (C, Lua)
  Description : Lua module for Nginx


Lua module is currently a part of Debian Nginx package.

I would like to move the module to the separate package ngx-lua.


I would like to maintain the package using https://salsa.debian.org/
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/ngx-lua

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1016054: ITP: lua-resty-lrucache -- Simple LRU cache for the ngx_lua module

[Jan Mojzis]

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

* Package name: lua-resty-lrucache
  Version : 0.13
  Upstream Author : Yichun Zhang (agentzh) 
* URL : https://github.com/openresty/lua-resty-lrucache
* License : BSD
  Programming Lang: Lua
  Description : Simple LRU cache for the ngx_lua module

This library implements a Simple LRU cache for the ngx_lua module.

I'm currenlty maintaining NGINX package, and new ngx_lua module needs the 
lua-resty-lrucache package.

I would like to maintain the package using https://salsa.debian.org/
I would need to create a 
https://salsa.debian.org/debian/lua-team/lua-resty-lrucache repository before 
uploading.
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/lua-resty-lrucache

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1016053: ITP: lua-resty-core -- New FFI-based Lua API for NGINX lua module

[Jan Mojzis]

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

* Package name: lua-resty-core
  Version : 0.10.13
  Upstream Author : Yichun Zhang (agentzh) 
* URL : https://github.com/openresty/lua-resty-core
* License : BSD
  Programming Lang: Lua
  Description : New FFI-based Lua API for NGINX lua module

This library implements a New FFI-based Lua API for NGINX lua module.

I'm currenlty maintaining NGINX package, and new ngx_lua module needs the 
lua-resty-core package.

I would like to maintain the package using https://salsa.debian.org/
I would need to create a 
https://salsa.debian.org/debian/lua-team/lua-resty-core repository before 
uploading.
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/lua-resty-core

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1010963: bullseye-pu: package nginx/1.18.0-6.1

[Jan Mojzis]

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

CVE-2021-3618 fix

[ Reason ]
fixes ALPACA attack CVE-2021-3618:
ALPACA is an application layer protocol content confusion attack, exploiting 
TLS servers implementing different protocols but using compatible certificates, 
such as multi-domain or wildcard certificates.  A MiTM attacker having access 
to victim's traffic at the TCP/IP layer can redirect traffic from one subdomain 
to another, resulting in a valid TLS session. This breaks the authentication of 
TLS and cross-protocol attacks may be possible where the behavior of one 
protocol service may compromise the other at the application layer.

[ Impact ]

Similarly to smtpd_hard_error_limit in Postfix and smtp_max_unknown_commands
in Exim, specifies the number of errors after which the connection is closed.

[ Tests ]
Patch sets default '5' error-cmd-tries.
It means, the server must close connection after 5 'bad commands'.

config:
~~~
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
worker_connections 768;
}

mail {
auth_http   localhost/cgi-bin/nginxauth.cgi;
server {
listen localhost:25;
protocol   smtp;
proxy  on;
smtp_auth login plain cram-md5;
}
}
~~~

~~~
# telnet 0 25
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
220 localtest ESMTP ready
badcommand1
500 5.5.1 Invalid command
badcommand2
500 5.5.1 Invalid command
badcommand3
500 5.5.1 Invalid command
badcommand4
500 5.5.1 Invalid command
badcommand5
500 5.5.1 Invalid command
Connection closed by foreign host.
root@dev:~/nginx/nginx-1.18.0#
~~~


[ Risks ]
A MiTM attacker having access to victim's traffic at the TCP/IP layer can 
redirect traffic from one subdomain to another, resulting in a valid TLS 
session. This breaks the authentication   of TLS and cross-protocol attacks may 
be possible where the behavior of one protocol service may compromise the other 
at the application layer.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Similarly to smtpd_hard_error_limit in Postfix and smtp_max_unknown_commands
in Exim, specifies the number of errors after which the connection is closed.

diff -Nru nginx-1.18.0/debian/changelog nginx-1.18.0/debian/changelog
--- nginx-1.18.0/debian/changelog   2022-03-15 21:36:18.0 +0100
+++ nginx-1.18.0/debian/changelog   2022-05-14 08:27:08.0 +0200
@@ -1,3 +1,11 @@
+nginx (1.18.0-6.1+deb11u2) bullseye; urgency=medium
+
+  * d/patches/CVE-2021-3618.patch: Include upstream changeset from NGINX
+that adds mitigations into the Mail module for CVE-2021-3618.patch.
+(Closes: #991328)
+
+ -- Jan Mojžíš   Sat, 14 May 2022 08:27:08 +0200
+
 nginx (1.18.0-6.1+deb11u1) bullseye; urgency=medium

   * Backport upstream bugfix for segfault in nginx core >= 1.15.0 when
diff -Nru nginx-1.18.0/debian/patches/CVE-2021-3618.patch 
nginx-1.18.0/debian/patches/CVE-2021-3618.patch
--- nginx-1.18.0/debian/patches/CVE-2021-3618.patch 1970-01-01 
01:00:00.0 +0100
+++ nginx-1.18.0/debian/patches/CVE-2021-3618.patch 2022-05-14 
08:23:49.0 +0200
@@ -0,0 +1,84 @@
+Subject: Patch mitigation for CVE-2021-3618
+ Mail: max_errors directive.
+ .
+ Similarly to smtpd_hard_error_limit in Postfix and smtp_max_unknown_commands
+ in Exim, specifies the number of errors after which the connection is closed.
+Origin: upstream, http://hg.nginx.org/nginx/rev/ec1071830799
+Bug-Debian: https://bugs.debian.org/991328
+
+--- a/src/mail/ngx_mail.h
 b/src/mail/ngx_mail.h
+@@ -115,6 +115,8 @@
+ ngx_msec_t  timeout;
+ ngx_msec_t  resolver_timeout;
+
++ngx_uint_t  max_errors;
++
+ ngx_str_t   server_name;
+
+ u_char *file_name;
+@@ -231,6 +233,7 @@
+ ngx_uint_t  command;
+ ngx_array_t args;
+
++ngx_uint_t  errors;
+ ngx_uint_t  login_attempt;
+
+ /* used to parse POP3/IMAP/SMTP command */
+--- a/src/mail/ngx_mail_core_module.c
 b/src/mail/ngx_mail_core_module.c
+@@ -85,6 +85,13 @@
+   offsetof(ngx_mail_core_srv_conf_t, resolver_timeout),
+   NULL },
+
++{ ngx_string("max_errors"),
++  NGX_MAIL_MAIN_CONF|NGX_MAIL_SRV_CONF|NGX_CONF_TAKE1,
++  ngx_conf_set_num_slot,
++  NGX_MAIL_SRV_CONF_OFFSET,
++  offsetof(ngx_mail_core_srv_conf_t, max_errors),
++  NULL },
++
+   ngx_null_command
+ };
+
+@@ -163,6 +170,8 @@
+ cscf->timeout = NGX_CONF_UNSET_MSEC;
+ cscf->resolver_timeout = NGX_CONF_UNSET_MSEC;
+
++cscf->max_errors = NGX_CONF_UNSET_UINT;
++
+ cscf->resolver = NGX_CONF_UNSET

Bug#1009758: ITP: flask-restx -- Flask-RESTX is an extension for Flask that adds support for quickly building REST APIs

[Jan Mojzis]

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

* Package name: flask-restx
 Version : 0.5.1
 Upstream Author : python-restx Authors
* URL : https://github.com/python-restx/flask-restx
* License : BSD-3-Clause
 Programming Lang: Python
 Description : Flask-RESTX is an extension for Flask that adds support for 
quickly building REST APIs


Flask-RESTX is an extension for Flask that adds support for quickly
building REST APIs. Flask-RESTX encourages best practices with minimal setup.
If you are familiar with Flask, Flask-RESTX should be easy to pick up. It
provides a coherent collection of decorators and tools to describe your API and
expose its documentation properly using Swagger.

I would like to maintain the package using https://salsa.debian.org/
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/python-flask-restx

I need sponsor for the first upload (I'm DM).

Bug#483171: /usr/bin/tai64n: There should be a /commands symlink to /usr/bin

[Jan Mojzis]

Hello,
this bug seems to be obsolete,
we will close it.
If the problem persists in the new version (>= 0.76-8),
and the fix doesn't violate debian rules
please reopen the bug.

Thank You!

Bug#1007305:

[Jan Mojzis]

Hello,
new version 0.76-8 (uploaded today) has completely reworked /debian part
and fixes the problem.

We did not notice the bug before the release,
so it is not listed in the changelog
and will not be closed automatically.

Jan

Bug#1007950: bullseye-pu: package tinyssh/20190101-1

[Jan Mojzis]

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

After upgrade openssh client from 8.8 to 8.9 rejects tinyssh
connections.

[ Reason ]
Tinyssh has very strict packet_length checking and when 
client doesn't horor max. packet lenght, closes the connection.

[ Impact ]
Using new openss client 8.9 stoped tinyssh working,
rejects all connections.

[ Tests ]
The bug was catched by autopkgtest e.g. here:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/t/tinyssh/20220226_180547_e244f@/log.gz

And can be triggered manually using 2 versions openssh:
~~~
openssh-8.8p1# ./ssh test@127.0.0.1 "cat >/tmp/testfile2" < /tmp/testfile1 && 
echo OK || echo BAD
OK

openssh-8.9p1# ./ssh test@127.0.0.1 "cat >/tmp/testfile2" < /tmp/testfile1 && 
echo OK || echo BAD
client_loop: send disconnect: Broken pipe
BAD
~~~

After fix:
~~~
openssh-8.9p1# ./ssh test@127.0.0.1 "cat >/tmp/testfile2" < /tmp/testfile1 && 
echo OK || echo BAD
OK
~~~


[ Risks ]
Patch is trivial.
And already applied in ubuntu: 
http://launchpadlibrarian.net/590133636/tinyssh_20190101-1build1_20190101-1ubuntu1.diff.gz

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

diff -Nru tinyssh-20190101/debian/changelog tinyssh-20190101/debian/changelog
--- tinyssh-20190101/debian/changelog   2019-01-02 06:01:58.0 +0100
+++ tinyssh-20190101/debian/changelog   2022-03-19 08:28:29.0 +0100
@@ -1,3 +1,10 @@
+tinyssh (20190101-1+deb11u1) bullseye; urgency=medium
+
+  * Workaround for incoming packets that doesn't honor
+  the max. packet length (Closes: 1006801)
+
+ -- Jan Mojžíš   Sat, 19 Mar 2022 08:28:29 +0100
+
 tinyssh (20190101-1) unstable; urgency=medium
 
   * d/tests - added 03exitcodes test, it creates ssh connection, exits
diff -Nru tinyssh-20190101/debian/patches/series 
tinyssh-20190101/debian/patches/series
--- tinyssh-20190101/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ tinyssh-20190101/debian/patches/series  2022-03-19 08:28:29.0 
+0100
@@ -0,0 +1 @@
+workaround-1006801-packet-length.patch
diff -Nru 
tinyssh-20190101/debian/patches/workaround-1006801-packet-length.patch 
tinyssh-20190101/debian/patches/workaround-1006801-packet-length.patch
--- tinyssh-20190101/debian/patches/workaround-1006801-packet-length.patch  
1970-01-01 01:00:00.0 +0100
+++ tinyssh-20190101/debian/patches/workaround-1006801-packet-length.patch  
2022-03-19 08:28:29.0 +0100
@@ -0,0 +1,24 @@
+From: Jan Mojzis 
+Date: Sat, 19 Mar 2022 08:36:48 +0100
+Origin: 
https://github.com/janmojzis/tinyssh/commit/0613ae9ef2fbac88522c8312456fb64d14020597
+Subject: Workaround for incoming packets that doesn't honor
+  the max. packet length
+
+Index: tinyssh-20190101/tinyssh/packet_channel_open.c
+===
+--- tinyssh-20190101.orig/tinyssh/packet_channel_open.c
 tinyssh-20190101/tinyssh/packet_channel_open.c
+@@ -49,7 +49,12 @@ int packet_channel_open(struct buf *b1,
+ buf_putnum32(b2, id);   /* uint32 
   recipient channel */
+ buf_putnum32(b2, id);   /* uint32 
   sender channel */
+ buf_putnum32(b2, localwindow);  /* uint32 
   initial window size */
+-buf_putnum32(b2, PACKET_LIMIT); /* uint32 
   maximum packet size */
++/*
++XXX
++use PACKET_LIMIT/2 as maximum packet size,
++workaround for miscalculated packet_length
++*/
++buf_putnum32(b2, PACKET_LIMIT / 2); /* uint32 
   maximum packet size */
+ packet_put(b2);
+ buf_purge(b2);
+ return 1;

Bug#1007762: bullseye-pu: package nginx/1.18.0-6.1

[Jan Mojzis]

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

Current version of nginx currently shipped in Debian 11
segfaults when libnginx-mod-http-lua is loaded and init_worker_by_lua* is used.

[ Reason ]
There is a bug in the libnginx-mod-http-lua module.
In the C code is 'conf. file variable' which is copied to the unalocated memory
space which cause segmentation fault.

[ Impact ]
Nginx crash.

[ Tests ]

/etc/nginx/nginx/conf:
~~~
user www-data;

load_module modules/ndk_http_module.so;
load_module modules/ngx_http_lua_module.so;

events {
worker_connections 768;
}

http {

init_worker_by_lua_block {
}

server {
listen 80;

location / {
return 200;
}
}
}
~~~

curl -D- http://127.0.0.1/


[ Risks ]
Minimal, the patch is trivial.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

debdiff:

diff -Nru nginx-1.18.0/debian/changelog nginx-1.18.0/debian/changelog
--- nginx-1.18.0/debian/changelog   2021-05-29 16:21:37.0 +0200
+++ nginx-1.18.0/debian/changelog   2022-03-15 21:36:18.0 +0100
@@ -1,3 +1,11 @@
+nginx (1.18.0-6.1+deb11u1) bullseye; urgency=medium
+
+  * Backport upstream bugfix for segfault in nginx core >= 1.15.0 when
+libnginx-mod-http-lua is loaded and init_worker_by_lua* is used.
+(Closes: #994178)
+
+ -- Jan Mojžíš   Tue, 15 Mar 2022 21:36:18 +0100
+
 nginx (1.18.0-6.1) unstable; urgency=high

   * Non-maintainer upload.
diff -Nru 
nginx-1.18.0/debian/modules/patches/http-lua/bug-994178-segfault.patch 
nginx-1.18.0/debian/modules/patches/http-lua/bug-994178-segfault.patch
--- nginx-1.18.0/debian/modules/patches/http-lua/bug-994178-segfault.patch  
1970-01-01 01:00:00.0 +0100
+++ nginx-1.18.0/debian/modules/patches/http-lua/bug-994178-segfault.patch  
2022-03-15 21:36:18.0 +0100
@@ -0,0 +1,31 @@
+From: Datong Sun 
+Date: Wed Jul 18 16:21:09 2018 -0700
+Origin: 
https://github.com/openresty/lua-nginx-module/commit/e94f2e5d64daa45ff396e262d8dab8e56f5f10e0
+Subject: fixed segfault in NGINX core >= 1.15.0 when init_worker_by_lua* is
+ used.
+
+Signed-off-by: Yichun Zhang (agentzh) 
+
+diff --git a/src/ngx_http_lua_initworkerby.c b/src/ngx_http_lua_initworkerby.c
+index 4a722a06..2a82fcb9 100644
+--- a/src/ngx_http_lua_initworkerby.c
 b/src/ngx_http_lua_initworkerby.c
+@@ -25,6 +25,7 @@ ngx_http_lua_init_worker(ngx_cycle_t *cycle)
+ void*cur, *prev;
+ ngx_uint_t   i;
+ ngx_conf_t   conf;
++ngx_conf_file_t  cf_file;
+ ngx_cycle_t *fake_cycle;
+ ngx_module_t   **modules;
+ ngx_open_file_t *file, *ofile;
+@@ -166,6 +167,10 @@ ngx_http_lua_init_worker(ngx_cycle_t *cycle)
+ conf.pool = fake_cycle->pool;
+ conf.log = cycle->log;
+
++ngx_memzero(&cf_file, sizeof(cf_file));
++cf_file.file.name = cycle->conf_file;
++conf.conf_file = &cf_file;
++
+ http_ctx.loc_conf = ngx_pcalloc(conf.pool,
+ sizeof(void *) * ngx_http_max_module);
+ if (http_ctx.loc_conf == NULL) {
diff -Nru nginx-1.18.0/debian/modules/patches/http-lua/series 
nginx-1.18.0/debian/modules/patches/http-lua/series
--- nginx-1.18.0/debian/modules/patches/http-lua/series 2021-05-29 
16:21:37.0 +0200
+++ nginx-1.18.0/debian/modules/patches/http-lua/series 2022-03-15 
21:36:18.0 +0100
@@ -1,2 +1,3 @@
 discover-luajit-2.1.patch
 CVE-2020-11724.patch
+bug-994178-segfault.patch

Bug#1006908: O: daemontools -- collection of tools for managing UNIX services

[Jan Mojzis]

Package: wnpp
Severity: normal
Control: affects -1 src:daemontools

I planned to manage the daemontools package 
(new repo is here https://salsa.debian.org/debian/daemontools),
but I didn't get a sponsor.
I leave the packaging to someone else.

The package is orphaned.

Bug#1006801: tinyssh: autopkgtests fail with OpenSSH 8.9

[Jan Mojzis]

Problem fixed in the release 20220305,
also update debian package https://salsa.debian.org/debian/tinyssh 
<https://salsa.debian.org/debian/tinyssh>
and debian package is ready to upload.

I need sponsor.

Jan.

> On 5. 3. 2022, at 16:24, Jan Mojzis  wrote:
> 
> Hello,
> 
> I can confirm that the autopkgtest does not pass the latest tinyssh version 
> (20220222).
> The problem is related to the openssh upgrade from 8.8 -> 8.9.
> 
> openssh-8.8p1# ./ssh test@127.0.0.1 "cat >/tmp/testfile2" < /tmp/testfile1 && 
> echo OK || echo BAD
> OK
> 
> openssh-8.9p1# ./ssh test@127.0.0.1 "cat >/tmp/testfile2" < /tmp/testfile1 && 
> echo OK || echo BAD
> client_loop: send disconnect: Broken pipe
> BAD
> 
> """
> tinysshd: VjEOjvCa: BUG:  (protocol error){sshcrypto_cipher_chachapoly.c:88}
> """
> Tinyssh receives too large packet (32784 bytes), instead of maxpacket ( 32768 
> bytes) and
> immediately closes the connection.
> 
> I have to look deeper where the bug is, if in tinyssh or in openssh client.
> 
> Jan
> 
> 
> 
> 
>> On 5. 3. 2022, at 13:04, Colin Watson  wrote:
>> 
>> Package: tinyssh
>> Version: 20190101-1
>> Severity: important
>> 
>> tinyssh's autopkgtests are failing with OpenSSH 8.9 in unstable.  See
>> e.g.:
>> 
>> https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/t/tinyssh/20220226_180547_e244f@/log.gz
>> 
>> autopkgtest [18:05:25]: test 06transfer: preparing testbed
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Starting pkgProblemResolver with broken count: 0
>> Starting 2 pkgProblemResolver with broken count: 0
>> Done
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> 1 not fully installed or removed.
>> After this operation, 0 B of additional disk space will be used.
>> Setting up autopkgtest-satdep (0) ...
>> (Reading database ... 66551 files and directories currently installed.)
>> Removing autopkgtest-satdep (0) ...
>> autopkgtest [18:05:28]: test 06transfer: [---
>> 1048576+0 records in
>> 1048576+0 records out
>> 1048576 bytes (1.0 MB, 1.0 MiB) copied, 2.42825 s, 432 kB/s
>> Warning: Permanently added '[127.0.0.1]:1' (ED25519) to the list of 
>> known hosts.
>> tinysshd: VjEOjvCa: BUG:  (protocol error){sshcrypto_cipher_chachapoly.c:88}
>> client_loop: send disconnect: Broken pipe
>> ssh transfer failed
>> autopkgtest [18:05:31]: test 06transfer: ---]
>> autopkgtest [18:05:31]: test 06transfer:  - - - - - - - - - - results - - - 
>> - - - - - - -
>> 06transfer   FAIL non-zero exit status 1
>> 
>> I see that there's a new upstream release of tinyssh not yet in Debian,
>> though I haven't checked whether that fixes this problem.  Do you need
>> help with sponsorship?
>> 
>> -- 
>> Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1006801: tinyssh: autopkgtests fail with OpenSSH 8.9

[Jan Mojzis]

Hello,

I can confirm that the autopkgtest does not pass the latest tinyssh version 
(20220222).
The problem is related to the openssh upgrade from 8.8 -> 8.9.

openssh-8.8p1# ./ssh test@127.0.0.1 "cat >/tmp/testfile2" < /tmp/testfile1 && 
echo OK || echo BAD
OK

openssh-8.9p1# ./ssh test@127.0.0.1 "cat >/tmp/testfile2" < /tmp/testfile1 && 
echo OK || echo BAD
client_loop: send disconnect: Broken pipe
BAD

"""
 tinysshd: VjEOjvCa: BUG:  (protocol error){sshcrypto_cipher_chachapoly.c:88}
"""
Tinyssh receives too large packet (32784 bytes), instead of maxpacket ( 32768 
bytes) and
immediately closes the connection.

I have to look deeper where the bug is, if in tinyssh or in openssh client.

Jan




> On 5. 3. 2022, at 13:04, Colin Watson  wrote:
> 
> Package: tinyssh
> Version: 20190101-1
> Severity: important
> 
> tinyssh's autopkgtests are failing with OpenSSH 8.9 in unstable.  See
> e.g.:
> 
>  
> https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/t/tinyssh/20220226_180547_e244f@/log.gz
> 
>  autopkgtest [18:05:25]: test 06transfer: preparing testbed
>  Reading package lists...
>  Building dependency tree...
>  Reading state information...
>  Starting pkgProblemResolver with broken count: 0
>  Starting 2 pkgProblemResolver with broken count: 0
>  Done
>  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>  1 not fully installed or removed.
>  After this operation, 0 B of additional disk space will be used.
>  Setting up autopkgtest-satdep (0) ...
>  (Reading database ... 66551 files and directories currently installed.)
>  Removing autopkgtest-satdep (0) ...
>  autopkgtest [18:05:28]: test 06transfer: [---
>  1048576+0 records in
>  1048576+0 records out
>  1048576 bytes (1.0 MB, 1.0 MiB) copied, 2.42825 s, 432 kB/s
>  Warning: Permanently added '[127.0.0.1]:1' (ED25519) to the list of 
> known hosts.
>  tinysshd: VjEOjvCa: BUG:  (protocol error){sshcrypto_cipher_chachapoly.c:88}
>  client_loop: send disconnect: Broken pipe
>  ssh transfer failed
>  autopkgtest [18:05:31]: test 06transfer: ---]
>  autopkgtest [18:05:31]: test 06transfer:  - - - - - - - - - - results - - - 
> - - - - - - -
>  06transfer   FAIL non-zero exit status 1
> 
> I see that there's a new upstream release of tinyssh not yet in Debian,
> though I haven't checked whether that fixes this problem.  Do you need
> help with sponsorship?
> 
> -- 
> Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1001503: ITP: tlswrapper -- TLS encryption wrapper

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 

* Package name: tlswrapper
  Version : 20211210
  Upstream Author : Name 
* URL : https://github.com/janmojzis/tlswrapper
* License : public-domain
  Programming Lang: C
  Description : TLS encryption wrapper

The tlswrapper is an TLS encryption wrapper between remote client and
local program prog.
.
Internet <--> tcpserver/inetd/systemd.socket/... <--> tlswrapper <--> prog
.
Separate process for every connection
.
The tlswrapper is executed from systemd.socket/inetd/tcpserver/... which
runs separate instance of tlswrapper for each TLS connection.
It ensures that a vulnerability in the code (e.g. bug in the TLS library)
can't be used to compromise the memory of another connection.
.
Separate process for network connection and for secret-key operation
.
To protect against secret-information leaks to the network connection
(such Heartbleed) tlswrapper runs two independent processes for every
TLS connection. One process holds secret-keys and runs secret-keys operations
and second talks to the network. Processes communicate with each other through
unix pipes.
.
Privilege separation, filesystem isolation, limits
.
The tlswrapper processes run  under dedicated non-zero uid to prohibit kill,
ptrace, etc. Is chrooted into an empty, unwritable directory to prohibit
filesystem access. Sets ulimits to prohibit new files, sockets, etc.
Sets ulimits to prohibit forks.
.
TLS library
.
The tlswrapper is using BearSSL library which implements only secure
versions of TLS protocol (TLS1.0 - TLS1.2). And implements safe and
constant-time algorithms.

I'm using this software and I'm going to maintain using 
https://salsa.debian.org/
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/tlswrapper,
I would need to create a https://salsa.debian.org/debian/tlswrapper repository 
before uploading.
I need sponsor.

Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Jan Mojzis]

Repacked version without exe-binary is in the git repository:
https://salsa.debian.org/debian/bearssl

Best regards,
Jan

> On 5 Oct 2021, at 19:44, Jan Mojzis  wrote:
> 
> Ok
> I understand,
> first i will contact ‘upstream’ to remove the binary from the package.
> 
> Jan
> 
>> On 5 Oct 2021, at 19:03, Bastian Germann  wrote:
>> 
>> Am 05.10.21 um 18:59 schrieb Jan Mojzis:
>>> Hello,
>>> I have removed the patch, it wasn’t good idea.
>>> The exe binary doesn’t affect debian package.
>>> So I just updates the d/source/include-binary file.
>> 
>> Hi Jan,
>> 
>> Actually, it does affect the source package legally. You cannot know without 
>> a long process of reverse engineering what is contained in the binary. Odds 
>> are that it violates the distribution permission of additional software that 
>> is included but not documented.
>> 
>> So if you want the package sponsored by me, you would have to repack, 
>> removing that file from the source package.
>> 
>> Thanks,
>> Bastian
>> 
> 

Bug#995790: RFS: daemontools/0.76-8 #947696

[Jan Mojzis]

Package: daemontools
Severity: normal 

Dear mentors,

I would like to maintain package 'daemontools'
and I need a sponsor.

Package is maintained here: https://salsa.debian.org/debian/daemontools
ITA: #947696


thanks
Jan

Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Jan Mojzis]

Ok
I understand,
first i will contact ‘upstream’ to remove the binary from the package.

Jan

> On 5 Oct 2021, at 19:03, Bastian Germann  wrote:
> 
> Am 05.10.21 um 18:59 schrieb Jan Mojzis:
>> Hello,
>> I have removed the patch, it wasn’t good idea.
>> The exe binary doesn’t affect debian package.
>> So I just updates the d/source/include-binary file.
> 
> Hi Jan,
> 
> Actually, it does affect the source package legally. You cannot know without 
> a long process of reverse engineering what is contained in the binary. Odds 
> are that it violates the distribution permission of additional software that 
> is included but not documented.
> 
> So if you want the package sponsored by me, you would have to repack, 
> removing that file from the source package.
> 
> Thanks,
> Bastian
> 

Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Jan Mojzis]

Hello,
I have removed the patch, it wasn’t good idea.
The exe binary doesn’t affect debian package.
So I just updates the d/source/include-binary file.

Thanks
Jan 

> On 1 Oct 2021, at 12:02, Bastian Germann  wrote:
> 
> On Sat, 06 Feb 2021 19:18:43 +0100 Jan Mojzis  wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Jan Mojzis 
>> * Package name: bearssl
>>  Version : 0.6
>>  Upstream Author : Thomas Pornin 
>> * URL : https://bearssl.org
>> * License : MIT
>>  Programming Lang: C
>>  Description : BearSSL is an implementation of the SSL/TLS protocol (RFC 
>> 5246) written in C
>> BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in 
>> C. It aims at offering the following features:
>> - Be correct and secure. In particular, insecure protocol versions and 
>> choices of algorithms are not supported, by design; cryptographic algorithm 
>> implementations are constant-time by default.
>> - Be small, both in RAM and code footprint. For instance, a minimal server 
>> implementation may fit in about 20 kilobytes of compiled code and 25 
>> kilobytes of RAM.
>> - Be highly portable. BearSSL targets not only “big” operating systems like 
>> Linux and Windows, but also small embedded systems and even special contexts 
>> like bootstrap code.
>> - Be feature-rich and extensible. SSL/TLS has many defined cipher suites and 
>> extensions; BearSSL should implement most of them, and allow extra algorithm 
>> implementations to be added afterwards, possibly  from third parties
>> Library doesn't have compatible API with mainstream OpenSSL.
>> And it's not intended as an OpenSSL 1-1 replacement.
>> I'm using this software and I'm going to maintain using 
>> https://salsa.debian.org/.
>> I need sponsor.
> 
> Please replace the exe removing patch with a Files-Excluded rule in 
> d/copyright. This is a repack then, which has to be reflected in the version 
> string.
> Else this looks good to me.
> 
> The usual process to ask for sponsors is filing an RFS. It will get more 
> attention then.

Bug#947696:

[Jan Mojzis]

Severity: normal

I intend to addopt daemontools.

Best Regards,
Jan Mojzis

Bug#982135: Acknowledgement (ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C)

[Jan Mojzis]

The packaging is ready in my personal repository:
https://salsa.debian.org/janmojzis/bearssl 


… and prefered final location is:
https://salsa.debian.org/debian/bearssl 


Jan

Bug#982136: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 

* Package name: bearssl
 Version : 0.6
 Upstream Author : Thomas Pornin 
* URL : https://bearssl.org
* License : MIT
 Programming Lang: C
 Description : BearSSL is an implementation of the SSL/TLS protocol (RFC 
5246) written in C


BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C. 
It aims at offering the following features:
- Be correct and secure. In particular, insecure protocol versions and choices 
of algorithms are not supported, by design; cryptographic algorithm 
implementations are constant-time by default.
- Be small, both in RAM and code footprint. For instance, a minimal server 
implementation may fit in about 20 kilobytes of compiled code and 25 kilobytes 
of RAM.
- Be highly portable. BearSSL targets not only “big” operating systems like 
Linux and Windows, but also small embedded systems and even special contexts 
like bootstrap code.
- Be feature-rich and extensible. SSL/TLS has many defined cipher suites and 
extensions; BearSSL should implement most of them, and allow extra algorithm 
implementations to be added afterwards, possibly  from third parties

Library doesn't have compatible API with mainstream OpenSSL.
And it's not intended as an OpenSSL 1-1 replacement.

I'm using this software and I'm going to maintain using 
https://salsa.debian.org/.
I need sponsor.

Bug#982135: ITP: bearssl -- BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 

* Package name: bearssl
  Version : 0.6
  Upstream Author : Thomas Pornin 
* URL : https://bearssl.org
* License : MIT
  Programming Lang: C
  Description : BearSSL is an implementation of the SSL/TLS protocol (RFC 
5246) written in C


BearSSL is an implementation of the SSL/TLS protocol (RFC 5246) written in C. 
It aims at offering the following features:
- Be correct and secure. In particular, insecure protocol versions and choices 
of algorithms are not supported, by design; cryptographic algorithm 
implementations are constant-time by default.
- Be small, both in RAM and code footprint. For instance, a minimal server 
implementation may fit in about 20 kilobytes of compiled code and 25 kilobytes 
of RAM.
- Be highly portable. BearSSL targets not only “big” operating systems like 
Linux and Windows, but also small embedded systems and even special contexts 
like bootstrap code.
- Be feature-rich and extensible. SSL/TLS has many defined cipher suites and 
extensions; BearSSL should implement most of them, and allow extra algorithm 
implementations to be added afterwards, possibly  from third parties

Library doesn't have compatible API with mainstream OpenSSL.
And it's not intended as an OpenSSL 1-1 replacement.

I'm using this software and I'm going to maintain using 
https://salsa.debian.org/.
I need sponsor.

Bug#911539: tinysshd: Use Recommends: systemd rather than Depends

[Jan Mojzis]

Hello,

fixed here: 
https://salsa.debian.org/debian/tinyssh/commit/64ab1d6729ecf5e0a7115bffa634beb8dbb5b3e6
 


Jan


> On 21 Oct 2018, at 19:01, Marvin Renich  wrote:
> 
> Package: tinysshd
> Version: 20180201-1
> 
> [Jan Mojžíš: this is a reply to a thread on debian-devel; some of the
> statements below are directed toward that thread, not to you
> personally.]
> 
> * Vincent Bernat  [181021 11:29]:
>> ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov :
>> 
>> tinysshd only ships a systemd unit file; neomutt links against
>> libgpgme11 which again Depends on gnupg.  It’s the kind of
>> dependencies that individually make sense,
>>> 
>>> I beg to differ; I suppose (though haven’t actually tried) I
>>> can start tinysshd straight from rc.local just as well, or even
>>> write my own init.d script, right?  Having the dependency in
>>> place just makes it harder to me to contribute an init.d script
>>> for the package.
>> 
>> tinysshd requires some kind of socket server to run. It could run from
>> inetd, so if you were an actual user, I would propose you file a bug
>> report against the package to let the maintainer knows the dependency is
>> too strong for your use (and maybe propose a patch to integrate with
>> inetd).
>> 
>> As you are not, please, do not. Our resources are scarce and we already
>> cater for the need of many non-existent users.
> 
> Recommends, rather than Depends is correct, based on your description,
> even without a patch to enable use with inetd.  Anyone who is not using
> systemd, either out of dislike of systemd or because they have real
> requirements for no or a stripped-down init system, is able to add a
> single line to inetd (or one of its successors).
> 
> However, adding Depends just because the package ships with a systemd
> unit file, and no other init integration, is simply wrong.
> 
> Don't let the fact that systemd antagonists keep annoying you prevent
> you from doing the right thing.  openssh-server has an uncompressed size
> of 922k with a long list of Depends.  tinysshd has an uncompressed
> size of 606k with only two Depends, libc6 and systemd.  Changing systemd
> to a Recommends would make tinysshd significantly more useful in some
> of the use cases where its stated description "minimalistic SSH server"
> already makes it the preferred ssh server.
> 
> As a general rule, please use Recommends over Depends whenever it will
> not truly break the package.  This is exactly what Recommends is for.
> 
> ...Marvin

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Jan Mojzis]

> "extremely outdated"?
> 
> This sounds like a hack from ~ 20 years ago when people realized that 
> running several programs at the same time as nobody does not isolate
> them from each other.
> 
> Much better solutions for restricting what a process can or cannot do 
> are now available.
> 

The basic idea is taken from extreme - sandboxing:
https://cr.yp.to/talks/2007.04.27/extremesandbox.c[1] 

My 2 tools currently making only small
part on this idea, only droping uids/gids.
I would like to improve my tools in the future, 

but I thing first step:
- running current daemons/cron scripts/... under differentd UIDs in the system
simply by using extremesetuidgid/extremeenvuidgid (instead of 
setuidgid/envuidgid)

second step:
- create (library ??) to use buggy libraries such openssl sandboxed using idea 
from
extreme sandbox


> tinysshd [1] is another worrisome example.
> 
> Writing an own "tiny" sshd from scratch, and the result is not even 
> smaller than the dropbear everyone else uses for that purpose.

dropbear is nice example here.
https://matt.ucc.asn.au/dropbear/CHANGES[2] 
First line in the changelog:
"""
Security: Message printout was vulnerable to format string injection.
"""

I'm trying in my software eliminate bugs such 'format string injection',
this is exactly why I'm not using  sprint*,vsprint*,... and other functions 
from libc,
and also trying to eliminate varargs functions.

> 
> To make the NIH complete, it uses own versions of standard C library
> string functions and an own (pretty primitive) build system.

Yes,
the build script (and also Makefile) is very small.
I'm following the rule "less code means less bugs"
Everyone can read what it does.
It simply works on Linux, *BSD, Solaris, AIX, ...

Jan


[1] https://cr.yp.to/talks/2007.04.27/extremesandbox.c
[2] https://matt.ucc.asn.au/dropbear/CHANGES

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Jan Mojzis]

>I read manpage on github, but did not understood, what exactly this
> program provides.  Can it replace creation system users for dropping
> privileges?

It's doesn't create users.
It only drops privileges (extremesetuidgid) or sets $UID/$GID env. variables 
(extremeenvuidgid).

For example:
extremesetuidgid -b 10 sleep 1

runs command 'sleep 1' under unprivileged uid/gid (computed getpid() +10) 
e.g. for:
pid=10 ... uid=gid=100010
pid=11 ... uid=gid=100011
pid=12 ... uid=gid=100011
...

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Jan Mojzis]

> It appears there is copies of GPLv3 code from NaCL in the source. I'm not a
> lawyer, but I think that is making the distribution as "public domain"
> pretty much illegal? Or am I missing something here?

Hello,
NaCl is not GPL3.
It's public-domain https://nacl.cr.yp.to/features.html[1] 

Jan


[1] http://nacl.cr.yp.to/features.html

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Jan Mojzis]

On Monday 17 of October 2016 19:57:53 Ben Hutchings wrote:
> Jan Mojzis  wrote:
> [...]
> > I'm going to maintain the package using collab-maint.
> > I need sponsor.
> >
> > Debian package:
> >  - has autotest
> >  - is using debhelper
> >  - is using git-dpm https://anonscm.debian.org/cgit/collab-maint/extr
> emetools.git
> >  - lintian clean (no warnings)
> 
> However, the code:
> 
> - Has a silent failure mode
where?

> - Reinvents common C library functions like strtol(), getopt(),
> strerror()
I will NEVER use str* functions from libc in my code.

> - Defines many similar functions differing only in number of arguments,
> where a varargs function would be appropriate
Is it problem ?

> - Doesn't have a 'make install' rule
Is it problem ?

> - Has manually maintained dependencies on headers
Is it problem ?

> 
> I really think you should get a little more experience with C and
> makefiles, and a full code review, before packaging something that aims
> to be a security-critical tool.
> 
> Ben.

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 

* Package name: extremetools
  Version : 20161017
  Upstream Author : Jan Mojžíš 
* URL : https://github.com/janmojzis/extremetools
* License : public-domain
  Programming Lang: C
  Description : tools for running processes under extreme uid and gid

Extremetools consists of 2 simple tools extremesetuidgid and extremeenvuidgid.
 - extremesetuidgid runs program under unique (extreme) uid and gid
 - extremeenvuidgid runs program with environment variables indicating
   unique (extreme) uid and gid

This is useful for running processes in the system under unique (extreme) 
uids/gids.
So processes can't ptrace each other, can't send signal each other, etc ...

---

I'm going to maintain the package using collab-maint.
I need sponsor.

Debian package:
 - has autotest
 - is using debhelper
 - is using git-dpm 
https://anonscm.debian.org/cgit/collab-maint/extremetools.git
 - lintian clean (no warnings)

Bug#838481: RFS: daemontools/0.76-7 [RC]

[Jan Mojzis]

Hello,
Gerrit is currently very busy, I will help him using NMU.
Gerrit knows about it.

NMU fixes the RC bug (#831921) and also fixes:
- all problems reported by Ondrej
- and also fixes 3 important bugs:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776876
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793003
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819036

NMU fixes only release-critical and important bugs -> 
DELAYED/5

Regards,

Jandiff -u daemontools-0.76/debian/changelog daemontools-0.76/debian/changelog
--- daemontools-0.76/debian/changelog
+++ daemontools-0.76/debian/changelog
@@ -1,3 +1,18 @@
+daemontools (1:0.76-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * supervise.c: restart the monitored process when
+fork(2) fails (Closes: #819036)
+  * d/rules: fix mtimes before building binary package to produce
+reproducible output (Closes: #793003) (Closes: #776876)
+  * d/rules: do not FTBFS with dpkg-buildpackage -A (thx Santiago
+Vila) (Closes: #831921)
+  * d/implicit: fixed md5sums permissions 0664 -> 0644
+  * d/control: bump to standards-version 3.9.8
+  * d/control: fixed the description
+
+ -- Jan Mojzis   Tue, 20 Sep 2016 06:17:20 +0200
+
 daemontools (1:0.76-6) unstable; urgency=medium
 
   * workaround #767933 by copying from sysvinit-2.88dsf:
diff -u daemontools-0.76/debian/control daemontools-0.76/debian/control
--- daemontools-0.76/debian/control
+++ daemontools-0.76/debian/control
@@ -2,7 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: Gerrit Pape 
-Standards-Version: 3.9.5.0
+Standards-Version: 3.9.8
 
 Package: daemontools
 Architecture: any
@@ -10,7 +10,7 @@
 Suggests: daemontools-run | runit
 Depends: ${shlibs:Depends}
 Replaces: daemontools-doc
-Description: a collection of tools for managing UNIX services
+Description: collection of tools for managing UNIX services
  supervise monitors a service. It starts the service and restarts the
  service if it dies. Setting up a new service is easy: all supervise
  needs is a directory with a run script that runs the service. 
diff -u daemontools-0.76/debian/implicit daemontools-0.76/debian/implicit
--- daemontools-0.76/debian/implicit
+++ daemontools-0.76/debian/implicit
@@ -35,7 +35,7 @@
 	debian/$*/usr/share/doc/$*/changelog'
 	@test -s debian/$*/usr/share/doc/$*/changelog || \
 	  sh -cx 'rm -f debian/$*/usr/share/doc/$*/changelog'
-	@gzip -9 debian/$*/usr/share/doc/$*/changelog*
+	@gzip -9n debian/$*/usr/share/doc/$*/changelog*
 %.deb-docs-docs: %.deb-docs-base
 	@for i in `cat debian/$*.docs 2>/dev/null || :`; do \
 	  if test -d $$i; then \
@@ -54,7 +54,7 @@
 	@if test -r debian/$*.NEWS.Debian; then \
 	  sh -cx 'install -m0644 debian/$*.NEWS.Debian \
 	debian/$*/usr/share/doc/$*/NEWS.Debian && \
-	  gzip -9 debian/$*/usr/share/doc/$*/NEWS.Debian'; \
+	  gzip -9n debian/$*/usr/share/doc/$*/NEWS.Debian'; \
 	fi
 %.deb-docs-examples: %.deb-docs-docs
 	@rm -rf debian/$*/usr/share/doc/$*/examples
@@ -88,6 +88,7 @@
 	@rm -f debian/$*/DEBIAN/md5sums
 	@cd debian/$* && find * -path 'DEBIAN' -prune -o \
 	  -type f -exec md5sum {} >>DEBIAN/md5sums \;
+	@chmod 644 debian/$*/DEBIAN/md5sums
 %.deb-DEBIAN: %.deb-checkdir %.deb-DEBIAN-base %.deb-DEBIAN-scripts \
 	  %.deb-DEBIAN-md5sums
 	: debian/$*/DEBIAN/ ok
diff -u daemontools-0.76/debian/rules daemontools-0.76/debian/rules
--- daemontools-0.76/debian/rules
+++ daemontools-0.76/debian/rules
@@ -7,6 +7,8 @@
 
 DIR =$(shell pwd)/debian/daemontools
 
+BUILD_DATE := $(shell dpkg-parsechangelog --show-field Date)
+
 patch: deb-checkdir patch-stamp
 patch-stamp:
 	for i in `ls -1 debian/diff/*.diff || :`; do \
@@ -14,6 +16,8 @@
 	done
 	touch patch-stamp
 
+build-arch: build
+build-indep: build
 build: deb-checkdir build-stamp
 build-stamp: patch-stamp
 	cd daemontools-0.76 && package/compile
@@ -47,7 +51,7 @@
 	install -d -m0755 '$(DIR)'/usr/share/man/man8
 	for i in debian/daemontools-man/*.8; do \
 	  install -m0644 $$i '$(DIR)'/usr/share/man/man8/ && \
-	  gzip -9 '$(DIR)'/usr/share/man/man8/$${i##*/} || exit 1; \
+	  gzip -9n '$(DIR)'/usr/share/man/man8/$${i##*/} || exit 1; \
 	done
 	#  changelog
 	test -r changelog || ln -s daemontools-0.76/src/CHANGES changelog
@@ -62,7 +66,7 @@
 	  '$(DIR)'-run/usr/sbin/update-service
 	install -d -m0755 '$(DIR)'-run/usr/share/man/man8
 	install -m0644 debian/update-service.8 '$(DIR)'-run/usr/share/man/man8/
-	gzip -9 '$(DIR)'-run/usr/share/man/man8/update-service.8
+	gzip -9n '$(DIR)'-run/usr/share/man/man8/update-service.8
 	#  systemd service
 	install -d -m0755 '$(DIR)'-run/lib/systemd/system
 	install -m0644 debian/systemd/daemontools.service \
@@ -94,14 +98,18 @@
 binary-arch: install-arch daemontools.deb
 	dpkg-shlibdeps '$(DIR)'/usr/bin/*
 	dpkg-gencontrol -isp -pdaemontools -P&

Bug#834828: dqcache-run: lock file in /etc

[Jan Mojzis]

Hello,
fixed here:
https://anonscm.debian.org/cgit/collab-maint/dq.git/commit/?id=7e8addfa1f0830ff6c7c83955ce40da89af0aa2b[1]
 

will be in the next release.

Jan


[1] 
https://anonscm.debian.org/cgit/collab-maint/dq.git/commit/?id=7e8addfa1f0830ff6c7c83955ce40da89af0aa2b

Bug#834728: cron: enable restarts under systemd

[Jan Mojzis]

Package: cron
Version: 3.0pl1-128
Severity: wishlist

Dear Maintainer,
please allow automatic restarts in cron.service.


Patch:
--- pkg-cron/debian/cron.service2016-08-18 13:44:34.811408220 +0200
+++ pkg-cron.restart/debian/cron.service2016-08-18 13:44:03.756220281 
+0200
@@ -8,6 +8,7 @@
 ExecStart=/usr/sbin/cron -f $EXTRA_OPTS
 IgnoreSIGPIPE=false
 KillMode=process
+Restart=on-failure
 
 [Install]
 WantedBy=multi-user.target


Thanks
Jan

Bug#832611: ITP: tinyssh -- Tiny SSH server

[Jan Mojzis]

On Wednesday 27 of July 2016 18:05:01 Dmitry Bogatov wrote:
> [2016-07-27 16:13] Jan Mojzis 
> >
> > Package: wnpp
> > Severity: wishlist
> > Owner: Jan Mojzis 
> >
> > * Package name: tinyssh
> >   Version     : 20160726
> >   Upstream Author : Jan Mojzis 
> > * URL : https://tinyssh.org/
> > * License : public domain
> >   Programming Lang: C
> >   Description : Tiny SSH server
> >
> > This is tiny SSH server which implement 'less'.
> > TinySSH supports only secure crypto (min 128-bit security,
> > protected against cache-timing attacks).
> > Unnecessary features (such SSH1 protocol, compression, scp, sftp, ...),
> > unsafe crypto (such rsa, dsa, hmac-md5, hmac-sha1, 3des, arcfour, ...) and
> > unsafe features (such password or hostbased authentication)
> > are simply NOT implemented.
> > TinySSH has less than 10 words of code, so it's very easy auditable.
> 
> Sounds nice. How does it compare with dropbear?

Hello,
TinySSH not implements 100% of SSH protocol.
It has limited amount of features.

1. only safe crypto:

implemented:
ssh-ed25519, curve25519-sha...@libssh.org, chacha20-poly1...@openssh.com

also implemented older standard (but disabled by default)
ecdsa-sha2-nistp256, ecdh-sha2-nistp256, aes128-ctr, aes256-ctr, hmac-sha2-256

not implemented:
rsa, dsa, hmac-md5, hmac-sha1, 3des, arcfour, 

2. only safe protocol
implemented:
subset of SSHv2 features

not implemented:
SSHv1

3. only safe authentification
implemented:
only authorized_keys authentification

not implemented:
password or hostbased authentication

4. no unnecesary programs
scp (‘rsync -e ssh’ makes same job)
sftp (TinySSH doesn’t have sftp program, but can run e.g. OpenSSH 
/usr/libexec/openssh/sftp-server)


5.  TinySSH has less than 100.000 word of code
computed using shell command:
cat *.c *.h \
| (cpp -fpreprocessed || gcpp -fpreprocessed) \
| sed 's/[_a-zA-Z0-9][_a-zA-Z0-9]*/x/g' \
| tr -d ' \012' | wc -c | tr -d ' '

'word of code' idea is taken from:
https://cr.yp.to/qmail/qmailsec-20071101.pdf[1] 


Jan




[1] https://cr.yp.to/qmail/qmailsec-20071101.pdf

Bug#832611: ITP: tinyssh -- Tiny SSH server

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 

* Package name: tinyssh
  Version : 20160726
  Upstream Author : Jan Mojzis 
* URL : https://tinyssh.org/
* License : public domain
  Programming Lang: C
  Description : Tiny SSH server

This is tiny SSH server which implement 'less'.
TinySSH supports only secure crypto (min 128-bit security,
protected against cache-timing attacks).
Unnecessary features (such SSH1 protocol, compression, scp, sftp, ...),
unsafe crypto (such rsa, dsa, hmac-md5, hmac-sha1, 3des, arcfour, ...) and
unsafe features (such password or hostbased authentication)
are simply NOT implemented.
TinySSH has less than 10 words of code, so it's very easy auditable.

I'm an upstream author and I'm going to maintain using collab-maint.
I need sponsor.

Bug#832163: override: dq:net/optional

[Jan Mojzis]

Package: ftp.debian.org
Severity: normal

Hello,
could you please downgrade the priority of all dq 
packages(dq,dqcache,dqcache-run) to
optional in the archive (dq_20160621-1).

Thanks
Jan Mojzis

Bug#825174: ITP: dq -- DNS/DNSCurve query tool

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis 

* Package name: dq
  Version : 20160523
  Upstream Author : Jan Mojzis 
* URL : https://mojzis.com/software/dq/
* License : public domain
  Programming Lang: C
  Description : DNS/DNSCurve query tool

The dq package provides software for DNS/DNSCurve.
This software is derived from djbdns, adds DNSCurve protection and
support for IPv6.

Contains 2 programs dq and dqcache:

Dq is commandline tool similar to dnsq, dnsqr from djbdns.
Is used to query DNS/DNSCurve server for specific
type of records about a given domain name.

Dqcache is recursive DNS/DNSCurve server derived from dnscache.

---

This software implements DNSCurve (https://dnscurve.org/).
Adds strong end-to-end encryption into DNS comunication and
protect DNS packets against:
- espionage
- packet corruption
- sabotage


I'm using this software and I'm going to maintain using collab-maint.
I need sponsor.

Bug#819051: nacl-tools: curvecpmessage does not correctly collect zombies

[Jan Mojzis]

Package: nacl-tools
Version: 20110221-4.1
Severity: normal

Dear Maintainer,

I would like to report problem with curvecpmessage.

Curvecpmessage program (serverside) does not correctly collect zombies when 
child process died.

How to reproduce:
1.run server side
../curvecpserver -v this.machine.name serverkey 127.0.0.1 1 
31415926535897932384626433832795 ./curvecpmessage sh -c 'timeout 10 cat 
/dev/zero'

2.run client side:
timeout 1 ./curvecpclient this.machine.name `cat serverkey.hex` 127.0.0.1 1 
31415926535897932384626433832795 ./curvecpmessage -c sh -c 'exit 111'

You can run client again and again, and after 10 seconds You will see 'sh' 
zombies.


I'm using workaround to fix the problem:

diff -Nur nacl-20110221.orig/curvecp/curvecpmessage.c 
nacl-20110221/curvecp/curvecpmessage.c
--- nacl-20110221.orig/curvecp/curvecpmessage.c 2011-02-21 02:49:34.0 
+0100
+++ nacl-20110221/curvecp/curvecpmessage.c  2011-10-31 12:52:10.727215587 
+0100
@@ -135,6 +135,9 @@

 long long lastpanic = 0;

+int childdied = 0;
+int pollret;
+
 void earliestblocktime_compute(void) /* XXX: use priority queue */
 {
   long long i;
@@ -304,7 +307,10 @@
 else
   timeout = (nextaction - recent) / 100 + 1;

-if (poll(p,q - p,timeout) < 0) {
+/* XXX */
+if (childdied) timeout = 10;
+pollret = poll(p,q - p,timeout);
+if (pollret < 0) {
   watch8 = 0;
   watchtochild = 0;
   watchfromchild = 0;
@@ -314,6 +320,11 @@
   if (watchfromchild) if (!watchfromchild->revents) watchfromchild = 0;
 }

+/* XXX */
+if (childdied && !pollret) {
+if (childdied++ > 999) goto finish;
+}
+
 /* XXX: keepalives */

 do { /* try receiving data from child: */
@@ -642,12 +653,23 @@
   tochild[1] = -1;
 } while(0);

+/* XXX */
+if (!childdied){
+if (waitpid(child,&childstatus, WNOHANG) > 0) {
+  close(tochild[1]);
+  tochild[1] = -1;
+  childdied = 1;
+}
+}
   }

+  if (!childdied) {
+do {
+  r = waitpid(child,&childstatus,0);
+} while (r == -1 && errno == EINTR);
+  }

-  do {
-r = waitpid(child,&childstatus,0);
-  } while (r == -1 && errno == EINTR);
+finish:

   if (!WIFEXITED(childstatus)) { errno = 0; die_fatal("process killed by 
signal",0,0); }
   return WEXITSTATUS(childstatus);




-- System Information:
Debian Release: 8.3
  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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nacl-tools depends on:
ii  libc6  2.19-18+deb8u3

nacl-tools recommends no packages.

nacl-tools suggests no packages.

-- no debconf information

Bug#819045: nacl-tools: address family not supported

[Jan Mojzis]

Package: nacl-tools
Version: 20110221-4.1
Severity: important

Dear Maintainer,

I would like to report bug in nacl-tools.
socket_bind library does'n correctly setup PF_INET flag for socket.

How to reproduce:
curvecpserver -v this.machine.name serverkey 127.0.0.1 1 
31415926535897932384626433832795 curvecpmessage cat /usr/share/dict/words
curvecpserver: fatal: unable to bind socket: address family not supported

The fix is simple:

diff -Nur nacl-20110221.orig/curvecp/socket_bind.c 
nacl-20110221/curvecp/socket_bind.c
--- nacl-20110221.orig/curvecp/socket_bind.c2012-06-27 16:48:27.877207880 
+0200
+++ nacl-20110221/curvecp/socket_bind.c 2012-06-27 16:50:10.393710544 +0200
@@ -9,6 +9,7 @@
 {
   struct sockaddr_in sa;
   byte_zero(&sa,sizeof sa);
+  sa.sin_family = PF_INET;
   byte_copy(&sa.sin_addr,4,ip);
   byte_copy(&sa.sin_port,2,port);
   return bind(fd,(struct sockaddr *) &sa,sizeof sa);

-- System Information:
Debian Release: 8.3
  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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nacl-tools depends on:
ii  libc6  2.19-18+deb8u3

nacl-tools recommends no packages.

nacl-tools suggests no packages.

-- no debconf information

Bug#819036: daemontools: supervise does not handle restarting the monitored process if fork(2) fails

[Jan Mojzis]

Source: daemontools
Severity: normal

Dear Maintainer,

I would like to report bug in daemontools.
Supervise process in daemontools does not correctly hande the situation when 
the monitored process (e.g. dnscache) died
and supervise is trying to fork new process and fork() fails.
Supervise then only logs:
supervise: warning: unable to fork for dnscache, sleeping 60 seconds: out of 
memory 

Here is the patch (6 years tested) which fixes the problem:

diff -Nur admin.orig/daemontools-0.76/src/supervise.c 
admin/daemontools-0.76/src/supervise.c
--- admin.orig/daemontools-0.76/src/supervise.c 2010-02-19 11:08:15.0 
+0100
+++ admin/daemontools-0.76/src/supervise.c  2010-02-19 12:53:16.0 
+0100
@@ -86,6 +86,8 @@

 const char *run[2] = { "./run", 0 };

+int flagfailed = 0;
+
 void trystart(void)
 {
   int f;
@@ -94,6 +96,7 @@
 case -1:
   strerr_warn4(WARNING,"unable to fork for ",dir,", sleeping 60 seconds: 
",&strerr_sys);
   deepsleep(60);
+  flagfailed = 1;
   trigger();
   return;
 case 0:
@@ -153,6 +156,11 @@
   }
 }

+if (flagfailed && flagwant && flagwantup){
+  flagfailed = 0;
+  trystart();
+}
+
 if (read(fdcontrol,&ch,1) == 1)
   switch(ch) {
case 'd':


-- System Information:
Debian Release: 8.3
  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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#459318: ITP: ucspi-tcp -- tcpclient, tcpserver and other TCP easy-use commandline-tools

[Jan Mojzis]

Package: wnpp
Severity: wishlist
Owner: Jan Mojzis <[EMAIL PROTECTED]>


* Package name: ucspi-tcp
  Version : 0.88
  Upstream Author : Daniel J. Bernstein
* URL : http://cr.yp.to/ucspi-tcp.html
* License : public domain
  Programming Lang: C
  Description : tcpclient, tcpserver and other TCP easy-use 
commandline-tools

 Written by Dan J. Bernstein, tcpclient and tcpserver are
 powerful easy-to-use command-line tools for building TCP
 client-server applications. tcpserver provides TCP access control
 features, similar to tcp-wrappers/tcpd's hosts.allow but much
 faster; it can run high-availability services much better than
 inetd.
 .
 Real-time Blocking List support is also included in tcpserver, so
 you can run qmail-smtpd with it and avoid a lot of SPAM.
 .
 tcpclient and tcpserver conform to UCSPI, the UNIX Client-Server
 Program Interface, using the TCP protocol.
 .

 For now is ucspi-tcp released into the public domain including distributing
 modified version.


 (I can help with packaging)
 Jan Mojzis
 [EMAIL PROTECTED]




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#335495: Segfault when loading xmlrpclib module

[Jan Mojzis]

Package: python2.4
Version: 2.4.1-2  

When I load xmlrpclib module from binary linked with xmlrpc-c library, program terminate with Segmentation fault.
Problem is somewhere in pyexpat module (look to test program). Problem is in python2.3 (2.3.5-3) too.


I am using Debian GNU/Linux 3.1, vanila kernel 2.6.12.2,  libc6 2.3.2.ds1-22





test.tgz
Description: GNU Zip compressed data