MAINTAINER="`eval "echo '$1'"`"

tags 785441 -patch
thanks
--

Viktor,

This seems like a reasonable idea, however I do not see a patch attached to the bug.  If you have one could you please send it?

Thanks!

Stephen

Idézem/Quoting Stephen Gelman <ssgelm@debian.org>:

Hello Stephen!

I've lost the solution, and really the problem too.

I think the format "Stephen Gelman <ssgelm@debian.org>" causes a problem.
I hope you could eliminate *all* 'eval'-s.

All the best!


SZÉPE Viktor, webes alkalmazás üzemeltetés / Running your application
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
~~~
ügyelet/hotline: +36-20-4242498  sms@szepe.net  skype: szepe.viktor
Budapest, III. kerület

I think the patch _was_ the original bug report, specifically this:

MAINTAINER="`eval "echo '$1'"`"

As compared to what the checkinstall code does now:

MAINTAINER=`eval echo $1`

The suggested extra layer of quoting will help with many issues around the
standard maintainer name format, I think. If you have single quotes in the
argument values it will still have problems, but it's at least better than
the current state of affairs.

It's unclear to me why this extra layer of indirection is happening at all,
though, and why it can't just do:

MAINTAINER="$1"

I can only imagine that there's some desire to let you indirectly reference
variables set by earlier arguments, but I have also seen anti-patterns like
this before from folks that just have a brain fart and forget how bash
works.

// extra frustration: whomever wrote this clearly knew this was an issue,
// because the manpage says: "Be careful to correctly quote/escape the name,
// to prevent shell expansion", but fails to note that "correct" is not well
// defined and barely achievable here.

Great catch, I agree that does seem to be the problem.  I’ll try to patch this soon.

Stephen

We believe that the bug you reported is fixed in the latest version of
checkinstall, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 785441@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Stephen Gelman <ssgelm@debian.org> (supplier of updated checkinstall package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 06 Aug 2026 17:10:56 -0500
Source: checkinstall
Architecture: source
Version: 1.6.2+git20170426.d24a630-6
Distribution: unstable
Urgency: medium
Maintainer: Stephen Gelman <ssgelm@debian.org>
Changed-By: Stephen Gelman <ssgelm@debian.org>
Closes: 785441 892985 1033483 1051180 1085196 1107638 1116590
Changes:
 checkinstall (1.6.2+git20170426.d24a630-6) unstable; urgency=medium
 .
   * Bump standards version to 4.7.4
   * Add loong64 support (Closes: #1085196)
     Thanks wuruilong for the patch! loongarch64 has no __xstat() to
     intercept, so the patch wraps stat(), lstat(), fstatat() and mknod()
     directly.
   * Make filesystem translation work against a current glibc, which covers
     most of what has been reported over the years as --fstrans=yes being
     broken (Closes: #1051180, #1116590):
     - Intercept the stat family through the symbols glibc exports. glibc 2.33
       turned stat(), lstat(), fstatat() and mknod() into ordinary functions,
       so a library defining only __xstat() no longer sees the stat calls that
       binaries in the archive make, and every tool that stats a path before
       acting on it was told the file did not exist. The loong64 wrappers
       above are needed here too, so the condition guarding them is the glibc
       version rather than the architecture.
     - Intercept statx()
     - Perform linkat() on the translated paths. It linked the paths it was
       given, so the hard link was made against the real filesystem even with
       --fstrans=yes
     - Intercept __open_2(), __openat_2() and their LFS64 spellings, which
       _FORTIFY_SOURCE substitutes for open() and openat()
     - Intercept the mkstemp family, which opens its file through an internal
       call the open() wrapper never sees
   * Stop backups from destroying symlinked directories such as /lib on
     merged-/usr systems (Closes: #1107638):
     - Resolve symlinks in the parent directories of a path before mirroring
       it into installwatch's backup tree, so restoring that tree over / can
       no longer replace a symlink with a real directory
     - Don't back up files on a read-only access() call
     - Pass --keep-directory-symlink to tar when restoring a backup, as a
       safety net
   * Record installed files under their real parent directories, so that a
     package built from an install writing to e.g. /lib/systemd/system ships
     /usr/lib/systemd/system and drops the aliased paths
   * Take option values as given rather than re-evaluating them through the
     shell. Values holding shell metacharacters, such as
     --maintainer="Jane Doe <jane@example.org>" and
     --requires="libc6 (>= 2.28)", now reach the package intact where they
     used to be dropped without a word (Closes: #785441)
   * Keep installed files whose path merely contains the name of the build
     directory. The check that finds them anchors its pattern, the one that
     dropped them did not, so building in /myapp also excluded
     /usr/include/myapp from the package (Closes: #1033483)
   * Fix the ld.so.conf guard in the postinstall script written for
     --addso=yes. It used "&>", which /bin/sh reads as a background command
     plus a stray redirection, so the guard never held and the library
     directory was appended again on every install (Closes: #892985)
   * Look for the shared libraries under the build directory when --addso=yes
     is given. checkinstall asked file(1) about their final absolute path,
     where filesystem translation leaves nothing, so it recognised no
     libraries and wrote no postinstall script
   * Drop "install -o root -g root" from the upstream install target. It fails
     under dpkg 1.22.13 and later, where a package that leaves
     Rules-Requires-Root unset runs its binary targets without (fake)root
Checksums-Sha1:
 63d044cf91bd669b4bbb399c050438b810c55575 2208 checkinstall_1.6.2+git20170426.d24a630-6.dsc
 ec61c95eb8a0147114bb85f1f293b8c1c19de218 31388 checkinstall_1.6.2+git20170426.d24a630-6.debian.tar.xz
 899c93723bf25df46fbd6aea839c687d70c69a0b 6980 checkinstall_1.6.2+git20170426.d24a630-6_amd64.buildinfo
Checksums-Sha256:
 f2320afdb59f316d0052255ac95d63849d0e0eef35477aaad84798215b232a8f 2208 checkinstall_1.6.2+git20170426.d24a630-6.dsc
 e20c33f67fc951dbc470abdb75474b119d2b0b11cc5ce5ab842174574f965b8c 31388 checkinstall_1.6.2+git20170426.d24a630-6.debian.tar.xz
 a7ec26582a569932417d44ab0f0e52f6aaf0e318a9d5a41b4c6e45f201c64704 6980 checkinstall_1.6.2+git20170426.d24a630-6_amd64.buildinfo
Files:
 1f9888ed4840024f6054b47e6403ff91 2208 admin optional checkinstall_1.6.2+git20170426.d24a630-6.dsc
 0dd7a615738d5ee98abf0d1b6a5328a1 31388 admin optional checkinstall_1.6.2+git20170426.d24a630-6.debian.tar.xz
 5518ab2143351693f8991518067f94d1 6980 admin optional checkinstall_1.6.2+git20170426.d24a630-6_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJGBAEBCgAwFiEEC77u8GTpSr6EMli0dUHPqvw16s8FAmp1CoUSHHNzZ2VsbUBk
ZWJpYW4ub3JnAAoJEHVBz6r8NerPQSoQAJrzZrQ2bOeAHAjWV+d6bHxeejE3zk7X
BT8ODGkl9b0dv0V1fhJeA4wUgpha7jbS3PEnCwYdsPit+NzhYHbYDQ+eDDvGNjPJ
yCpOzdNgExRo9Zrgzx0k3A3w2GVymsEMXEYKqdL7Afts+ODFx7EDoh4dLm956t3f
E2HVD93qsiDwaZlStFhHPKzr6lU1RHQeEfThAGpBQSPASSsx9PbJ25gTkesbZB+l
xj3LoNMmrm9mR0ik73lgaYhqK+sf3/ioAM1p/+X7bQtNp36DEeEwllpHEcO7Vri3
284qcm0VaVJaZi7/Ix4pPqo8b7dgyZuQHQc4uzc1PxLv+rssF0NO35UYKJ0eugtC
lFpDv33D2yqc2m8sUT300DPMb3Z/d1jMeix1cmyYgYcYyiLbRtG20/sPxedo5uDn
gLPorLvxkS5bZfnoJWj6C7pJo+oowH3L/oKOw/eSjVj8Tzh9Jbn28Gw/YWAZkbEY
5lHBFUq6wMtvSnJdFwk407KbByQAfDbW9od8N9GYMnLTWbzwXS64+8TSJGvov9qa
6tfX2GIJH0FTZi1hSc1PlvM2xlqqoKCzc+OVD8jmUAcLHsHB5EBtE4ireF/erYM4
aFGDDZ36xI2YHVwXdClgNMm/60L6VR8SYFpqsENuvmRUZsRjn+8+hRURul+7Jv3I
SFci2N7T4hPu
=bwf8
-----END PGP SIGNATURE-----