swab.3: Use Fn consistently
Index: swab.3 === RCS file: /cvs/src/lib/libc/string/swab.3,v retrieving revision 1.9 diff -u -p -r1.9 swab.3 --- swab.3 12 Dec 2014 20:06:13 - 1.9 +++ swab.3 27 Sep 2022 22:09:45 - @@ -42,9 +42,9 @@ .Fa "ssize_t len" .Fc .Sh DESCRIPTION -The function +The .Fn swab -copies +function copies .Fa len bytes from the location referenced by .Fa src @@ -55,7 +55,7 @@ swapping adjacent bytes. If .Fa len is zero or less, -.Nm +.Fn swab does nothing. If it is odd, what happens to the last byte is unspecified. If @@ -68,7 +68,7 @@ overlap, behaviour is undefined. .Xr memset 3 .Sh STANDARDS The -.Nm +.Fn swab function is compliant with the X/Open System Interfaces option of the .St -p1003.1-2008 specification.
readpassphrase(3) in glibc, and agetpass() (Was: Is getpass(3) really obsolete?)
Hi Zack,
On 10/29/21 16:53, Zack Weinberg via Libc-alpha wrote:
On Fri, Oct 29, 2021, at 9:55 AM, Theo de Raadt wrote:
wrote:
On October 29, 2021 7:29 AM, Alejandro Colomar wrote:
On 10/29/21 13:15, Alejandro Colomar wrote:
Hi,
As the manual pages says, SUSv2 marked it as LEGACY, and POSIX doesn't
have it at all. The manual page goes further and says "This function
is obsolete. Do not use it." in its first lines.
...
The community finally had the balls to get rid of gets(3).
getpass(3) shares the same flaw, that the buffer size isn't passed.
This has been an issue in the past
I was about to post exactly the same thing. getpass(3) is not deprecated
because there's a better replacement, it's deprecated because it's _unsafe_.
The glibc implementation wraps getline(3) and therefore doesn't truncate the
passphrase or overflow a fixed-size buffer, no matter how long the input is,
but portable code cannot rely on that. And come to think of it, using
getline(3) means that prefixes of the passphrase may be left lying around in
malloc's free lists.
(getpass also cannot be made thread safe, due to recycling of a static buffer,
but a program in which multiple threads are racing to prompt the user for
passwords would be a UX disaster anyway, so I don't think that's a critical
flaw the way it is for e.g. strtok(3).)
The Linux manpage project's documentation is, as I understand it, for Linux
with glibc _first_, but not _only_; it should not describe this function as
not-deprecated just because glibc has patched its worst problems and doesn't
offer any better API.
readpassphrase(3) has a few too many features/extensions for my taste, but
at least it is harder to abuse.
I am inclined to agree that readpassphrase has too many knobs, and I can't
think of any legitimate present-day use for several of them, which is not a
good property for an API handling security-critical data. Also, it relies on
the caller to size the buffer for the passphrase, and therefore risks
truncating people's passphrases.
With my libxcrypt hat on I've thought a bit about replacements for getpass.
The conclusion I came to is that the easy changes are all putting lipstick on a
pig, and if I was going to work on this at all I was going to design a
privilege-separated authentication service that could be asked to take over a
tty, read a passphrase, check it, and return just success or failure to the
caller. Neither the passphrase itself, nor any strings derived from it, would
ever be in the caller's address space. But this is obviously well out of scope
for the C library.
zw
I happen to be working on replacing getpass(3) in shadow-utils. As
there is no replacement in glibc, I'm making the code depend on libbsd
on GNU systems.
I developed a function similar to getpass(3), but which allocates a
buffer (similar to asprintf(3)). I only allocate once, and bail out if
the password exceeds PASS_MAX, so no leaks in allocated memory (modulo
bugs that I may have not noticed).
I also enforce both clearing and freeing the memory, by requiring a
specific clean-up function.
The prototypes for the function and the clean-up are:
```
void erase_pass(char *p);
[[gnu::malloc(erase_pass)]] char *shdw_getpass(const char *prompt);
```
And the implementation is:
```
#include "prototypes.h"
#include
#include
#include
#include
#if !defined(PASS_MAX)
#define PASS_MAX BUFSIZ
#endif
char *
agetpass(const char *prompt)
{
char*p;
size_t len;
p = malloc(PASS_MAX);
if (p == NULL)
return NULL;
if (readpassphrase(prompt, p, PASS_MAX, 0) == NULL)
goto fail;
len = strlen(p);
if (len == 0)
return p;
if (p[len - 1] != '\n')
goto truncated;
p[len - 1] = '\0';
return p;
truncated:
memzero(p, PASS_MAX);
fail:
free(p);
return NULL;
}
void
erase_pass(char *p)
{
if (p != NULL)
memzero(p, PASS_MAX);
free(p);
}
```
Would you mind implementing readpassphrase(3) in glibc so that it's
easier to use something safe and portable without resorting to
compatibility libraries? Also, I'd like some review of this function,
if you think the API could be improved. Maybe agetpass() would be a
simple almost-drop-in replacement for getpass(3), so if you like it for
glibc, let's discuss it.
I chose a predefined buffer size to not have to pass a buffer size all
the time, which could be error-prone. I also allocated the buffer
internally, to make it easier to replace getpass(3). It may be
desirable to use existing buffers, and pass them through a pointer, but
for shadow-utils, it was simpler to keep the getpass(3) API.
I don't know what was the practice with PASS_MAX regarding the NUL byte,
but to avoid creating a buffer of a power of two plus one, I decided
that the NUL byte would be within PASS_MAX.
setvbuf.c: fix 32-bit-ism
The existing test is wrong for LP64, where size_t has twice as many relevant bits as int, not just one. (Found by inspection by rprichard.) diff --git a/lib/libc/stdio/setvbuf.c b/lib/libc/stdio/setvbuf.c index 9a08d133f5f..9909dbb8ecd 100644 --- a/lib/libc/stdio/setvbuf.c +++ b/lib/libc/stdio/setvbuf.c @@ -31,6 +31,7 @@ * SUCH DAMAGE. */ +#include #include #include #include "local.h" @@ -52,7 +53,7 @@ setvbuf(FILE *fp, char *buf, int mode, size_t size) * when setting _IONBF. */ if (mode != _IONBF) - if ((mode != _IOFBF && mode != _IOLBF) || (int)size < 0) + if ((mode != _IOFBF && mode != _IOLBF) || size > INT_MAX) return (EOF); /*
Re: install.sub: Replace temporary file with variable
On Tue, 27 Sep 2022 11:28:59 -0400, Josiah Frentsos wrote: > From ksh(1): > > [[ expression ]] > Similar to the test and [ ... ] commands (described later), with > the following exceptions: > > o Field splitting and file name generation are not > performed on arguments. Ah, right. I don't always remember the rules for those new-fangled double-bracket expressions ;-) - todd
Re: install.sub: Replace temporary file with variable
On Tue, Sep 27, 2022 at 09:09:45AM -0600, Todd C. Miller wrote: > On Tue, 27 Sep 2022 13:49:10 -, Klemens Nanni wrote: > > > The double quotes retain the newlines; without them column(1) would > > print a single line (possibly longer than 80 chars). > > Don't you also need double quotes around $_CKPATCH: > > if [[ -n $_CKPATCH ]]; then > > in case it contains multiple words? >From ksh(1): [[ expression ]] Similar to the test and [ ... ] commands (described later), with the following exceptions: o Field splitting and file name generation are not performed on arguments.
Re: install.sub: Replace temporary file with variable
On Tue, 27 Sep 2022 13:49:10 -, Klemens Nanni wrote: > The double quotes retain the newlines; without them column(1) would > print a single line (possibly longer than 80 chars). Don't you also need double quotes around $_CKPATCH: if [[ -n $_CKPATCH ]]; then in case it contains multiple words? - todd
Re: Request for testing malloc and multi-threaded applications
On Tue, Sep 27, 2022 at 03:31:12PM +0200, Renaud Allard wrote: > On 1/16/19 19:09, Otto Moerbeek wrote: > > On Wed, Jan 16, 2019 at 01:25:25PM +, Stuart Henderson wrote: > > > > > On 2019/01/04 08:09, Otto Moerbeek wrote: > > > > On Thu, Dec 27, 2018 at 09:39:56AM +0100, Otto Moerbeek wrote: > > > > > > > > > > > > > > Very little feedback so far. This diff can only give me valid feedback > > > > > if the coverage of systems and use cases is wide. If I do not get > > > > > more feedback, I have to base my decisions on my own testing, which > > > > > will benefit my systems and use cases, but might harm yours. > > > > > > > > > > So, ladies and gentlemen, start your tests! > > > > > > > > Another reminder. I like to make progress on this. That means I need > > > > tests for various use-cases. > > > > > > I have a map based website I use that is quite good at stressing things > > > (high spin% cpu) and have been timing from opening chromium (I'm using > > > this for the test because it typically performs less well than firefox). > > > Time is real time from starting the browser set to 'start with previously > > > opened windows' and the page open, until when the page reports that it's > > > finished loading (i.e. fetching data from the server and rendering it). > > > > > > It's not a perfect test - depends on network/server conditions etc - and > > > it's a visualisation of conditions in a game so may change slightly from > > > run to run but there shouldn't be huge changes between the times I've > > > run it - but is a bit more repeatable than a subjective "does the browser > > > feel slow". > > > > > > 4x "real" cores, Xeon E3-1225v3, 16GB ram (not going into swap). > > > > > > I've mixed up the test orders so it's not 3x +++, 2x ++, 3x + etc in > > > order, > > > more like +++, -, '', -, ++ etc. > > > > > > +++ 90 98 68 > > > ++ 85 82 > > > + 87 56 71 > > > '' 76 60 69 88 > > > - 77 74 85 > > > -- 48 86 77 67 > > > > > > So while it's not very consistent, the fastest times I've seen are on > > > runs with fewer pools, and the slowest times on runs with more pools, > > > with '' possibly seeming a bit more consistent from run to run. But > > > there's not enough consistency with any of it to be able to make any > > > clear conclusion (and I get the impression it would be hard to > > > tell without some automated test that can be repeated many times > > > and carrying out a statistical analysis on results). > > > > > > > Thanks for testing. To be clear: this is with the diff I posted and not the > > committed code, right? (There is a small change in the committed code > > to change the default to what 1 plus was with the diff). > > > > -Otto > > > > Hello, > > Given that code is in base for about 4 years, shouldn't be the man page > modified to add an explanation for those ++--? Or is there a reason why it's > not documented? > > Best Regards > No, this is for internal/development use only and might be removed any time. It's undocumented on purpose. -Otto
Re: Remove some unnecessary setproctitle(3) format strings
Right.
This is called "idiomatic programming".
Sometimes it looks a bit idiotic (haha), but as the years go by, we've
learned that stylistic reminders that a rarely used function's parameter
is a variadic format string, helps us avoid introduction of new mistakes
during future development.
Stuart Henderson wrote:
> These programs seem OK as-is, they are following the advice in
> https://man.openbsd.org/setproctitle.3#CAVEATS
>
> On 2022/09/26 18:06, Josiah Frentsos wrote:
> > Index: sbin/dhcpleased/engine.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> > retrieving revision 1.38
> > diff -u -p -r1.38 engine.c
> > --- sbin/dhcpleased/engine.c5 May 2022 14:44:59 - 1.38
> > +++ sbin/dhcpleased/engine.c26 Sep 2022 21:43:28 -
> > @@ -197,7 +197,7 @@ engine(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "engine");
> > + setproctitle("engine");
> > log_procinit("engine");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/dhcpleased/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> > retrieving revision 1.30
> > diff -u -p -r1.30 frontend.c
> > --- sbin/dhcpleased/frontend.c 14 Jul 2022 15:23:09 - 1.30
> > +++ sbin/dhcpleased/frontend.c 26 Sep 2022 21:43:29 -
> > @@ -151,7 +151,7 @@ frontend(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "frontend");
> > + setproctitle("frontend");
> > log_procinit("frontend");
> >
> > if ((ioctlsock = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> > Index: sbin/slaacd/engine.c
> > ===
> > RCS file: /cvs/src/sbin/slaacd/engine.c,v
> > retrieving revision 1.84
> > diff -u -p -r1.84 engine.c
> > --- sbin/slaacd/engine.c26 Aug 2022 00:02:08 - 1.84
> > +++ sbin/slaacd/engine.c26 Sep 2022 21:43:29 -
> > @@ -372,7 +372,7 @@ engine(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "engine");
> > + setproctitle("engine");
> > log_procinit("engine");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/slaacd/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/slaacd/frontend.c,v
> > retrieving revision 1.64
> > diff -u -p -r1.64 frontend.c
> > --- sbin/slaacd/frontend.c 12 Jul 2022 16:54:59 - 1.64
> > +++ sbin/slaacd/frontend.c 26 Sep 2022 21:43:29 -
> > @@ -153,7 +153,7 @@ frontend(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "frontend");
> > + setproctitle("frontend");
> > log_procinit("frontend");
> >
> > if ((ioctlsock = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> > Index: sbin/unwind/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/unwind/frontend.c,v
> > retrieving revision 1.73
> > diff -u -p -r1.73 frontend.c
> > --- sbin/unwind/frontend.c 13 Mar 2022 15:14:01 - 1.73
> > +++ sbin/unwind/frontend.c 26 Sep 2022 21:43:30 -
> > @@ -207,7 +207,7 @@ frontend(int debug, int verbose)
> > if (chdir("/") == -1)
> > fatal("chdir(\"/\")");
> >
> > - setproctitle("%s", "frontend");
> > + setproctitle("frontend");
> > log_procinit("frontend");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/unwind/resolver.c
> > ===
> > RCS file: /cvs/src/sbin/unwind/resolver.c,v
> > retrieving revision 1.155
> > diff -u -p -r1.155 resolver.c
> > --- sbin/unwind/resolver.c 12 Mar 2022 14:35:29 - 1.155
> > +++ sbin/unwind/resolver.c 26 Sep 2022 21:43:30 -
> > @@ -368,7 +368,7 @@ resolver(int debug, int verbose)
> > if ((pw = getpwnam(UNWIND_USER)) == NULL)
> > fatal("getpwnam");
> >
> > - setproctitle("%s", "resolver");
> > + setproctitle("resolver");
> > log_procinit("resolver");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: usr.bin/ssh/sshd.c
> > ===
> > RCS file: /cvs/src/usr.bin/ssh/sshd.c,v
> > retrieving revision 1.591
> > diff -u -p -r1.591 sshd.c
> > --- usr.bin/ssh/sshd.c 17 Sep 2022 10:34:29 - 1.591
> > +++ usr.bin/ssh/sshd.c 26 Sep 2022 21:43:34 -
> > @@ -492,7 +492,7 @@ privsep_preauth(struct ssh *ssh)
> > set_log_handler(mm_log_handler, pmonitor);
> >
> > privsep_preauth_child();
> > - setproctitle("%s", "[net]");
> > + setproctitle("[net]");
> > if (box != NULL)
> >
install.sub: Replace temporary file with variable
On supported -release systems, syspatch(8) -c is run from rc.firsttime(8)
and the list of patches it pretty-printed if non-empty.
-c output fits into a shell variable, not needing a temporary file, which
is also what usr.sbin/syspatch/syspatch.sh does internally.
Here's what the patch would do on a fresh -release install:
rel71# _CKPATCH=$(syspatch -c)
rel71# echo "$_CKPATCH" | column -xc 80
001_wifi002_ipsec 003_kqueue 004_asn1
005_pppoe
007_cron008_bgpd009_zlib010_expat
011_smtpd
The double quotes retain the newlines; without them column(1) would
print a single line (possibly longer than 80 chars).
Feedback? OK?
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1207
diff -u -p -r1.1207 install.sub
--- install.sub 27 Sep 2022 12:28:25 - 1.1207
+++ install.sub 27 Sep 2022 13:37:58 -
@@ -2905,15 +2905,13 @@ finish_up() {
isin "$ARCH" $_syspatch_archs && cat <<'__EOT' >>/mnt/etc/rc.firsttime
set -A _KERNV -- $(sysctl -n kern.version |
sed 's/^OpenBSD \([1-9][0-9]*\.[0-9]\)\([^ ]*\).*/\1 \2/;q')
-if ((${#_KERNV[*]} == 1)) && [[ -s /etc/installurl ]] &&
-_CKPATCH=$(mktemp /tmp/_ckpatch.XX); then
+if ((${#_KERNV[*]} == 1)) && [[ -s /etc/installurl ]]; then
echo "Checking for available binary patches..."
- syspatch -c > $_CKPATCH
- if [[ -s $_CKPATCH ]]; then
+ _CKPATCH=$(syspatch -c)
+ if [[ -n $_CKPATCH ]]; then
echo "Run syspatch(8) to install:"
- column -xc 80 $_CKPATCH
+ echo "$_CKPATCH" | column -xc 80
fi
- rm -f $_CKPATCH
fi
__EOT
Re: Request for testing malloc and multi-threaded applications
On 1/16/19 19:09, Otto Moerbeek wrote: On Wed, Jan 16, 2019 at 01:25:25PM +, Stuart Henderson wrote: On 2019/01/04 08:09, Otto Moerbeek wrote: On Thu, Dec 27, 2018 at 09:39:56AM +0100, Otto Moerbeek wrote: Very little feedback so far. This diff can only give me valid feedback if the coverage of systems and use cases is wide. If I do not get more feedback, I have to base my decisions on my own testing, which will benefit my systems and use cases, but might harm yours. So, ladies and gentlemen, start your tests! Another reminder. I like to make progress on this. That means I need tests for various use-cases. I have a map based website I use that is quite good at stressing things (high spin% cpu) and have been timing from opening chromium (I'm using this for the test because it typically performs less well than firefox). Time is real time from starting the browser set to 'start with previously opened windows' and the page open, until when the page reports that it's finished loading (i.e. fetching data from the server and rendering it). It's not a perfect test - depends on network/server conditions etc - and it's a visualisation of conditions in a game so may change slightly from run to run but there shouldn't be huge changes between the times I've run it - but is a bit more repeatable than a subjective "does the browser feel slow". 4x "real" cores, Xeon E3-1225v3, 16GB ram (not going into swap). I've mixed up the test orders so it's not 3x +++, 2x ++, 3x + etc in order, more like +++, -, '', -, ++ etc. +++ 90 98 68 ++85 82 + 87 56 71 ''76 60 69 88 - 77 74 85 --48 86 77 67 So while it's not very consistent, the fastest times I've seen are on runs with fewer pools, and the slowest times on runs with more pools, with '' possibly seeming a bit more consistent from run to run. But there's not enough consistency with any of it to be able to make any clear conclusion (and I get the impression it would be hard to tell without some automated test that can be repeated many times and carrying out a statistical analysis on results). Thanks for testing. To be clear: this is with the diff I posted and not the committed code, right? (There is a small change in the committed code to change the default to what 1 plus was with the diff). -Otto Hello, Given that code is in base for about 4 years, shouldn't be the man page modified to add an explanation for those ++--? Or is there a reason why it's not documented? Best Regards smime.p7s Description: S/MIME Cryptographic Signature
Re: Remove some unnecessary setproctitle(3) format strings
On Tue, 2022-09-27 at 11:23 +0200, Florian Obser wrote:
> On 2022-09-27 09:26 +02, Martijn van Duren wrote:
> > The caveats section talks about "user-supplied data". These string are
> > constant and don't contain any '%'. Most other daemons in base use the
> > setproctitle("title"); format as well.
>
> It's not that clear cut, snmpd(8), a daemon you might be familiar with,
> uses
> setproctitle("%s", p->p_title);
>
> while p->p_title is not user supplied ;)
True, but proc.c doesn't know how p_title is filled :-)
>
> The diff is probably not wrong (I only glanced at it), but I don't think
> it solves a problem. It then comes down to style and I prefer things the
> way they are.
I only made the remark in regards to the caveat argument. If it's
personal preference, that's a good enough reason for me to keep it as
is. Especially for daemons that I don't work on. I addressed the
argument, not the conclusion.
>
> >
> > On Tue, 2022-09-27 at 08:07 +0100, Stuart Henderson wrote:
> > > These programs seem OK as-is, they are following the advice in
> > > https://man.openbsd.org/setproctitle.3#CAVEATS
>
Re: Remove some unnecessary setproctitle(3) format strings
On 2022-09-27 09:26 +02, Martijn van Duren wrote:
> The caveats section talks about "user-supplied data". These string are
> constant and don't contain any '%'. Most other daemons in base use the
> setproctitle("title"); format as well.
It's not that clear cut, snmpd(8), a daemon you might be familiar with,
uses
setproctitle("%s", p->p_title);
while p->p_title is not user supplied ;)
The diff is probably not wrong (I only glanced at it), but I don't think
it solves a problem. It then comes down to style and I prefer things the
way they are.
>
> On Tue, 2022-09-27 at 08:07 +0100, Stuart Henderson wrote:
>> These programs seem OK as-is, they are following the advice in
>> https://man.openbsd.org/setproctitle.3#CAVEATS
--
I'm not entirely sure you are real.
Re: Remove some unnecessary setproctitle(3) format strings
The caveats section talks about "user-supplied data". These string are
constant and don't contain any '%'. Most other daemons in base use the
setproctitle("title"); format as well.
On Tue, 2022-09-27 at 08:07 +0100, Stuart Henderson wrote:
> These programs seem OK as-is, they are following the advice in
> https://man.openbsd.org/setproctitle.3#CAVEATS
>
> On 2022/09/26 18:06, Josiah Frentsos wrote:
> > Index: sbin/dhcpleased/engine.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> > retrieving revision 1.38
> > diff -u -p -r1.38 engine.c
> > --- sbin/dhcpleased/engine.c5 May 2022 14:44:59 - 1.38
> > +++ sbin/dhcpleased/engine.c26 Sep 2022 21:43:28 -
> > @@ -197,7 +197,7 @@ engine(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "engine");
> > + setproctitle("engine");
> > log_procinit("engine");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/dhcpleased/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> > retrieving revision 1.30
> > diff -u -p -r1.30 frontend.c
> > --- sbin/dhcpleased/frontend.c 14 Jul 2022 15:23:09 - 1.30
> > +++ sbin/dhcpleased/frontend.c 26 Sep 2022 21:43:29 -
> > @@ -151,7 +151,7 @@ frontend(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "frontend");
> > + setproctitle("frontend");
> > log_procinit("frontend");
> >
> > if ((ioctlsock = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> > Index: sbin/slaacd/engine.c
> > ===
> > RCS file: /cvs/src/sbin/slaacd/engine.c,v
> > retrieving revision 1.84
> > diff -u -p -r1.84 engine.c
> > --- sbin/slaacd/engine.c26 Aug 2022 00:02:08 - 1.84
> > +++ sbin/slaacd/engine.c26 Sep 2022 21:43:29 -
> > @@ -372,7 +372,7 @@ engine(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "engine");
> > + setproctitle("engine");
> > log_procinit("engine");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/slaacd/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/slaacd/frontend.c,v
> > retrieving revision 1.64
> > diff -u -p -r1.64 frontend.c
> > --- sbin/slaacd/frontend.c 12 Jul 2022 16:54:59 - 1.64
> > +++ sbin/slaacd/frontend.c 26 Sep 2022 21:43:29 -
> > @@ -153,7 +153,7 @@ frontend(int debug, int verbose)
> > if (unveil(NULL, NULL) == -1)
> > fatal("unveil");
> >
> > - setproctitle("%s", "frontend");
> > + setproctitle("frontend");
> > log_procinit("frontend");
> >
> > if ((ioctlsock = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> > Index: sbin/unwind/frontend.c
> > ===
> > RCS file: /cvs/src/sbin/unwind/frontend.c,v
> > retrieving revision 1.73
> > diff -u -p -r1.73 frontend.c
> > --- sbin/unwind/frontend.c 13 Mar 2022 15:14:01 - 1.73
> > +++ sbin/unwind/frontend.c 26 Sep 2022 21:43:30 -
> > @@ -207,7 +207,7 @@ frontend(int debug, int verbose)
> > if (chdir("/") == -1)
> > fatal("chdir(\"/\")");
> >
> > - setproctitle("%s", "frontend");
> > + setproctitle("frontend");
> > log_procinit("frontend");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: sbin/unwind/resolver.c
> > ===
> > RCS file: /cvs/src/sbin/unwind/resolver.c,v
> > retrieving revision 1.155
> > diff -u -p -r1.155 resolver.c
> > --- sbin/unwind/resolver.c 12 Mar 2022 14:35:29 - 1.155
> > +++ sbin/unwind/resolver.c 26 Sep 2022 21:43:30 -
> > @@ -368,7 +368,7 @@ resolver(int debug, int verbose)
> > if ((pw = getpwnam(UNWIND_USER)) == NULL)
> > fatal("getpwnam");
> >
> > - setproctitle("%s", "resolver");
> > + setproctitle("resolver");
> > log_procinit("resolver");
> >
> > if (setgroups(1, >pw_gid) ||
> > Index: usr.bin/ssh/sshd.c
> > ===
> > RCS file: /cvs/src/usr.bin/ssh/sshd.c,v
> > retrieving revision 1.591
> > diff -u -p -r1.591 sshd.c
> > --- usr.bin/ssh/sshd.c 17 Sep 2022 10:34:29 - 1.591
> > +++ usr.bin/ssh/sshd.c 26 Sep 2022 21:43:34 -
> > @@ -492,7 +492,7 @@ privsep_preauth(struct ssh *ssh)
> > set_log_handler(mm_log_handler, pmonitor);
> >
> > privsep_preauth_child();
> > - setproctitle("%s", "[net]");
> > + setproctitle("[net]");
> > if (box != NULL)
> > ssh_sandbox_child(box);
> >
> > @@ -1627,7 +1627,7 @@
Re: Remove some unnecessary setproctitle(3) format strings
These programs seem OK as-is, they are following the advice in
https://man.openbsd.org/setproctitle.3#CAVEATS
On 2022/09/26 18:06, Josiah Frentsos wrote:
> Index: sbin/dhcpleased/engine.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 engine.c
> --- sbin/dhcpleased/engine.c 5 May 2022 14:44:59 - 1.38
> +++ sbin/dhcpleased/engine.c 26 Sep 2022 21:43:28 -
> @@ -197,7 +197,7 @@ engine(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "engine");
> + setproctitle("engine");
> log_procinit("engine");
>
> if (setgroups(1, >pw_gid) ||
> Index: sbin/dhcpleased/frontend.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 frontend.c
> --- sbin/dhcpleased/frontend.c14 Jul 2022 15:23:09 - 1.30
> +++ sbin/dhcpleased/frontend.c26 Sep 2022 21:43:29 -
> @@ -151,7 +151,7 @@ frontend(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
> log_procinit("frontend");
>
> if ((ioctlsock = socket(AF_INET, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> Index: sbin/slaacd/engine.c
> ===
> RCS file: /cvs/src/sbin/slaacd/engine.c,v
> retrieving revision 1.84
> diff -u -p -r1.84 engine.c
> --- sbin/slaacd/engine.c 26 Aug 2022 00:02:08 - 1.84
> +++ sbin/slaacd/engine.c 26 Sep 2022 21:43:29 -
> @@ -372,7 +372,7 @@ engine(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "engine");
> + setproctitle("engine");
> log_procinit("engine");
>
> if (setgroups(1, >pw_gid) ||
> Index: sbin/slaacd/frontend.c
> ===
> RCS file: /cvs/src/sbin/slaacd/frontend.c,v
> retrieving revision 1.64
> diff -u -p -r1.64 frontend.c
> --- sbin/slaacd/frontend.c12 Jul 2022 16:54:59 - 1.64
> +++ sbin/slaacd/frontend.c26 Sep 2022 21:43:29 -
> @@ -153,7 +153,7 @@ frontend(int debug, int verbose)
> if (unveil(NULL, NULL) == -1)
> fatal("unveil");
>
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
> log_procinit("frontend");
>
> if ((ioctlsock = socket(AF_INET6, SOCK_DGRAM | SOCK_CLOEXEC, 0)) == -1)
> Index: sbin/unwind/frontend.c
> ===
> RCS file: /cvs/src/sbin/unwind/frontend.c,v
> retrieving revision 1.73
> diff -u -p -r1.73 frontend.c
> --- sbin/unwind/frontend.c13 Mar 2022 15:14:01 - 1.73
> +++ sbin/unwind/frontend.c26 Sep 2022 21:43:30 -
> @@ -207,7 +207,7 @@ frontend(int debug, int verbose)
> if (chdir("/") == -1)
> fatal("chdir(\"/\")");
>
> - setproctitle("%s", "frontend");
> + setproctitle("frontend");
> log_procinit("frontend");
>
> if (setgroups(1, >pw_gid) ||
> Index: sbin/unwind/resolver.c
> ===
> RCS file: /cvs/src/sbin/unwind/resolver.c,v
> retrieving revision 1.155
> diff -u -p -r1.155 resolver.c
> --- sbin/unwind/resolver.c12 Mar 2022 14:35:29 - 1.155
> +++ sbin/unwind/resolver.c26 Sep 2022 21:43:30 -
> @@ -368,7 +368,7 @@ resolver(int debug, int verbose)
> if ((pw = getpwnam(UNWIND_USER)) == NULL)
> fatal("getpwnam");
>
> - setproctitle("%s", "resolver");
> + setproctitle("resolver");
> log_procinit("resolver");
>
> if (setgroups(1, >pw_gid) ||
> Index: usr.bin/ssh/sshd.c
> ===
> RCS file: /cvs/src/usr.bin/ssh/sshd.c,v
> retrieving revision 1.591
> diff -u -p -r1.591 sshd.c
> --- usr.bin/ssh/sshd.c17 Sep 2022 10:34:29 - 1.591
> +++ usr.bin/ssh/sshd.c26 Sep 2022 21:43:34 -
> @@ -492,7 +492,7 @@ privsep_preauth(struct ssh *ssh)
> set_log_handler(mm_log_handler, pmonitor);
>
> privsep_preauth_child();
> - setproctitle("%s", "[net]");
> + setproctitle("[net]");
> if (box != NULL)
> ssh_sandbox_child(box);
>
> @@ -1627,7 +1627,7 @@ main(int ac, char **av)
> if ((cfg = sshbuf_new()) == NULL)
> fatal_f("sshbuf_new failed");
> if (rexeced_flag) {
> - setproctitle("%s", "[rexeced]");
> + setproctitle("[rexeced]");
> recv_rexec_state(REEXEC_CONFIG_PASS_FD, cfg);
> if (!debug_flag) {
> startup_pipe =
