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 >
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: [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 stdlib.h /* for abs(), srand(), rand() */
+#include stdlib.h /* for abs(), srand(), rand(), arc4random() */
#include stdio.h /* for fopen(), fread(), fclose() */
#include unistd.h /* for getpid() */
#include time.h/* for time() */
+#include config.h
+
+#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
