Bug#1106040: unblock: ocserv/1.3.0-2
Hi,
On Wed, May 21, 2025 at 1:47 AM Sebastian Ramacher <sramacher@debian.org> wrote:
>
> Control: tags -1 moreinfo
>
> On 2025-05-19 14:57:00 +0800, Aron Xu wrote:
> > Package: release.debian.org
> > Control: affects -1 + src:ocserv
> > X-Debbugs-Cc: ocserv@packages.debian.org
> > User: release.debian.org@packages.debian.org
> > Usertags: unblock
> > Severity: normal
> >
> > Please unblock package ocserv
> >
> > ocserv/1.3.0-2 in unstable has a few cherry picks from upstream and
> > the debdiff is included in attachment.
> >
> > 0001-Check-return-value-of-remove.patch
> > 0002-src-ocpasswd-ocpasswd.c-handle-strup-errors.patch
> > 0003-Update-to-increase-pam-stack-size-per-https-gitlab.c.patch
> > 0004-Make-path-to-ocserv-fw-script-conform-to-config-pref.patch
> > 0005-Allow-the-readlinkat-syscall-when-socket_wrapper-is-.patch
>
> What is the impact of these patches? Do the fix any issues? Have they
> been tested?
>
These patches are all upstream cherry-picks and I've independently
tested them. Also for a friendlier view:
https://salsa.debian.org/debian/ocserv/-/tree/master/debian/patches?ref_type=heads
> 0001-Check-return-value-of-remove.patch
This is an upstream fix for Coverity Scan warning that the return
value isn't checked, in real life it handles the situation when
removing a socket isn't successful.
> 0002-src-ocpasswd-ocpasswd.c-handle-strup-errors.patch
At some rare case the strdup() at previous block might fail, and this
patch adds checks to that.
> 0003-Update-to-increase-pam-stack-size-per-https-gitlab.c.patch
This increases the stack size for the need of pam_sssd.
> 0004-Make-path-to-ocserv-fw-script-conform-to-config-pref.patch
This is a Makefile change that lets OCSERV_FW_SCRIPT conform to
PREFIX. This is not absolutely necessary to make it build in trixie
but since it's trivial I still picked it.
> 0005-Allow-the-readlinkat-syscall-when-socket_wrapper-is-.patch
On arm64 the realpath function calls readlinkat instead of readlink so
that it needs to be allowed.
Thanks,
Aron
Reply to: