Re: [Nmh-workers] OpenBSD added to the buildbot cluster
On Thu, 12 Dec 2013 19:52:54 -0500, David Levine wrote: > Lyndon wrote: > > > I have added an OpenBSD 5.4 (amd64) buildbot slave to the mix. > > > > Their auto{conf,make}s require some environment variables be set to > > pick which version of the tools to run under the hood. For now I > > have wired a hack into autogen.sh, but a better solution is > > required. > > Cool! > > test-manpages fails because of a slew of these: > > man8/post.8:1: warning: unbalanced .el request > > Any ideas? To me, this looks like it could be caused by a local patch to an-old.tmac that's applied in the OpenBSD groff port. CC'ing Ingo Schwarze, our roff guru. :) > Also, any ideas on how to squelch these: > > warning: strcpy() is almost always misused, please use strlcpy() > > Based on a very quick web search, it looks like they're from the > linker and there's no easy way. We could filter them out of the > linker output. Well, the proper way to get rid of them is to not use unsafe APIs ... But of course, that's a major development decision and would require lots of care to do properly. > David > > ___ > Nmh-workers mailing list > Nmh-workers@nongnu.org > https://lists.nongnu.org/mailman/listinfo/nmh-workers > > ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] OpenBSD added to the buildbot cluster
On Fri, 13 Dec 2013 18:17:49 -0500, David Levine wrote: > Pascal wrote: > > > On Thu, 12 Dec 2013 19:52:54 -0500, David Levine wrote: > > > test-manpages fails because of a slew of these: > > > > > > man8/post.8:1: warning: unbalanced .el request > > > > > > Any ideas? > > > > To me, this looks like it could be caused by a local patch to > > an-old.tmac that's applied in the OpenBSD groff port. CC'ing Ingo > > Schwarze, our roff guru. :) > > Thanks. Adding -Wel to our groff invocation (this is in a test) > shut them up. > > > > Also, any ideas on how to squelch these: > > > > > > warning: strcpy() is almost always misused, please use strlcpy() > > > > > > Based on a very quick web search, it looks like they're from the > > > linker and there's no easy way. We could filter them out of the > > > linker output. > > > > Well, the proper way to get rid of them is to not use unsafe APIs ... > > Not everyone agrees, reportedly including the glibc maintainers: > http://lwn.net/Articles/507319/ Yeah, but you have to admit that someone seriously suggesting *((char *) mempcpy (dst, src, n)) = '\0'; as strlcpy replacement is pretty ... delusional, to put it nicely. And completely unable to read a manual page. > > But of course, that's a major development decision and would require > > lots of care to do properly. > > Right. I'll trust that the approx. 150 occurrences in nmh are > safe and just filter out the warnings. I wouldn't. But that's your decision ... > David > > ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
[Nmh-workers] Use arc4random_buf() if available
rand()/srand() are not cryptographically secure PRNGs. Some systems have the much better suited arc4random() family of functions; there's no reason to not use it if it is available. Make m_rand() just a wrapper around arc4random_buf() in that case. (There's no need to ever seed it manually.) As a bonus, silences some warnings on OpenBSD. diff --git a/configure.ac b/configure.ac index ce4b46d..5f6b556 100644 --- a/configure.ac +++ b/configure.ac @@ -363,7 +363,7 @@ AC_CHECK_HEADER([sys/ptem.h], AC_DEFINE(WINSIZE_IN_PTEM,1, dnl --- dnl CHECK FUNCTIONS dnl --- -AC_CHECK_FUNCS([wcwidth mbtowc writev lstat nl_langinfo getutxent]) +AC_CHECK_FUNCS([wcwidth mbtowc writev lstat nl_langinfo getutxent arc4random]) dnl Check for multibyte character set support AS_IF([test "x$ac_cv_header_wchar_h" = "xyes" -a \ diff --git a/sbr/m_rand.c b/sbr/m_rand.c index 4d24888..8544cfb 100644 --- a/sbr/m_rand.c +++ b/sbr/m_rand.c @@ -6,16 +6,21 @@ * complete copyright information. */ -#include /* for abs(), srand(), rand() */ +#include /* for abs(), srand(), rand(), arc4random() */ #include/* for fopen(), fread(), fclose() */ #include /* for getpid() */ #include /* for time() */ +#include + +#if !HAVE_ARC4RANDOM static int seeded = 0; +#endif int m_rand (unsigned char *buf, size_t n) { +#if !HAVE_ARC4RANDOM if (! seeded) { FILE *devurandom; unsigned int seed; @@ -46,6 +51,9 @@ m_rand (unsigned char *buf, size_t n) { *buf++ = *rndp++; } } +#else + arc4random_buf(buf, n); +#endif return 0; } ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: Plans for distribution updates
On Sun, 01 Jan 2023 12:05:58 -0500, Ken Hornstein wrote: > Everyone, > > So now that we've started the release cycle process (thanks, David!) I > am wondering what the plans are for getting 1.8 packages into various > distributions. I did the Homebrew formula for MacOS X and I'm glad > to do it for 1.8. But I am wondering what other operating systems we > should target. Ones that come to mind are: > > - Various RPM-based distributions (Fedora, RedHat, CentOS, Rocky, and I am > sure others) > - Debian (and anything else that uses .deb files) > - FreeBSD/NetBSD/OpenBSD 'ports' systems As usual, I'll handle OpenBSD. > I am sure there are others. I guess I am wondering what needs to be done > to "turn the crank" so 1.8 makes it into the packaging distributions. > I know for Homebrew once the pull request is accepted all Homebrew users > should get the new version relatively quickly, and I think the ports systems > are similar but I don't know what needs to happen for the others. > > --Ken >
Re: 1.8RC2?
On Sat, 28 Jan 2023 06:17:09 -0800, David Levine wrote: > How does 1.8RC2 look? BSD users, have any of you tried it? I have been using it (and previously rc1) on OpenBSD since it came out. No issues so far. > For RedHat and Fedora users, you can install or upgrade using one of: > sudo dnf install nmh --enablerepo=3Dupdates-testing > sudo dnf upgrade nmh --enablerepo=3Dupdates-testing > > David >