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 >
