> Date: Wed, 07 May 2025 11:24:41 -0700
> From: "Greg A. Woods"
>
> There is no _OPENBSD_SOURCE on OpenBSD. It is purely a NetBSD invention.
This serves to make it easier to port OpenBSD-specific code to NetBSD,
and mark the fact that it's OpenBSD-specific, without encouraging more
adoption of
59360
# HG changeset patch
# User Taylor R Campbell
# Date 1745702701 0
# Sat Apr 26 21:25:01 2025 +
# Branch trunk
# Node ID f673072924a94e661ab1235cc1911b82ec4d43ad
# Parent 13492505e6407eebf7935dde7c7d2668a01b2055
# EXP-Topic riastradh-pr59360-ldelfsorelr
ld.elf_so: Add a trivial test for R_
124: arc4random(3): first call in process races with concurrent fork
<https://gnats.NetBSD.org/59124>
- PR lib/59125: pthread_once(3) races with concurrent fork
<https://gnats.NetBSD.org/59125>
# HG changeset patch
# User Taylor R Campbell
# Date 1741201110 0
# Wed Mar 05 18:5
ven't measured -- but it seems prudent to
consider, at least, when the context is libc startup.)
# HG changeset patch
# User Taylor R Campbell
# Date 1743186173 0
# Fri Mar 28 18:22:53 2025 +
# Branch trunk
# Node ID bba63cf2ff04b904ef7f8bbb878d10265275c639
# Parent 1335f96e94bb06b331691
> Date: Mon, 17 Feb 2025 21:58:57 +0100
> From: Thomas Klausner
>
> I recently used software that wanted to use "sort --version-sort". I
> looked around and noticed that even though our sort(1) doesn't support
> this, both FreeBSD and OpenBSD's do.
>
> It seems that in 2009, FreeBSD sort was ma
akefile, rather
than manually maintaining build_install groups separated by .WAIT
barriers. I expect this is an opportunity to substantially improve
parallelism of the library build.
Thoughts?
# HG changeset patch
# User Taylor R Campbell
# Date 173212072
> Date: Sat, 4 Jan 2025 10:22:01 +
> From: David Holland
>
> On Sat, Jan 04, 2025 at 06:52:38AM +0000, Taylor R Campbell wrote:
> > The point here is to grant the callee access to the exec path
> > _without_ cooperation by the caller.
> >
> > That wa
> Date: Wed, 18 Dec 2024 19:26:50 +0100
> From: "Jean-Yves Migeon (NetBSD)"
>
> I welcome such an addition; I had to deal with a problem alike in a
> "portable" way (...), and that ended up in a painful and fragile way. I
> have some remarks though, low tier (not blocking/critical).
> 1 - As t
jor bump
even though that technically violates the rules.
On the third hand, I put this off until after 10.1, so maybe it's a
moot point and I should just bump the major (and recursively bump the
major of all dependent libraries).
Thoughts?
# HG changeset patch
# User Taylor R Campbell
# Date 173229
Thanks, I've filed PR lib/58910: regcomp explodes on signedness issues
(https://gnats.NetBSD.org/58910) to track this.
First step will be to add some test cases to the ATF tests under
src/tests/lib/libc/regex/ to make sure we're exercising all the
relevant paths (may require some tweaks to handle
PROPOSAL: New libc function
const char *getexecpath(void);
returns the pathname that was passed to execve(2), unmodified.
Thoughts?
DETAILS:
This will be implemented by a new ELF auxiliary vector entry
AT_EXECPATH (or maybe AT_NETBSD_EXECPATH). Programs can use this to
get files rela
> Date: Tue, 8 Oct 2024 08:50:00 -0400 (EDT)
> From: Mouse
>
> > [...], using the C standard guaranteed property that the address of
> > the first member is the address of the structure, allowing to cast
> > pointers in order to operate whether on the base structure or on the
> > derived structur
> Date: Tue, 8 Oct 2024 10:06:39 +0200
> From: tlaro...@kergis.com
>
> In the style file, for structures, the emphasis is put on alignment in
> order to not waste memory because of undue padding.
>
> Shouldn't an exception been mentionned concerning structures that may be
> derived from a base st
> Date: Thu, 26 Sep 2024 12:48:12 +0900
> From: Ryo ONODERA
>
> On NetBSD/amd64-current of today with new jemalloc,
> linking to jemalloc always returns undefined references.
> This problem causes build failures of pkgsrc/www/firefox
> and misc/libreoffice at least.
> [...]
> $ gcc test.c -ljemal
> Date: Thu, 19 Sep 2024 09:20:42 -0400
> From: Greg Troxel
>
> I have found a serious bug in reqmuo(3), and a fix in FreeBSD, validated
> by regression tests in proj and a hand-written test. The problem exists
> in current and 10, and surely in 9 but I haven't checked.
>
> We currently have no
> Date: Tue, 16 Apr 2024 00:59:31 +
> From: Emmanuel Dreyfus
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0xf4bde597 in tsd_fetch_impl (minimal=false, init=true)
> at
> /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/tsd.h:270
> 270 return tsd
> Date: Mon, 15 Apr 2024 00:21:32 +
> From: Emmanuel Dreyfus
>
> I cross-build i386 packages on an amd64 machine, using pkg_comp with
> CFLAHS-m32 in /etc/mk.conf.
>
> That worked well on NetBSD-9 but after upgradint to NetBSD-10.0, I get
> random SIGSEGV. Here are a few backtrace examples:
> Date: Sun, 14 Apr 2024 14:07:26 +0900
> From: PHO
>
> As I mentioned in
> http://mail-index.netbsd.org/netbsd-users/2024/04/12/msg030915.html,
> Firefox tab processes crash very frequently on NetBSD/aarch64 10.0.
> Building it with PKG_OPTIONS.firefox+=debug-info revealed that when it
> cra
> Date: Sun, 14 Apr 2024 05:15:31 +
> From: Emmanuel Dreyfus
>
> On Sun, Apr 14, 2024 at 02:07:26PM +0900, PHO wrote:
> > As I mentioned in
> > http://mail-index.netbsd.org/netbsd-users/2024/04/12/msg030915.html, Firefox
> > tab processes crash very frequently on NetBSD/aarch64 10.0. Building
> Date: Fri, 5 Apr 2024 07:36:42 -0400 (EDT)
> From: Mouse
>
> (4) Are there still incoherencies between mmap and read/write access?
> At one time there were, and I never got a good handle on what needed to
> be done to avoid them.
This bug was fixed nearly a quarter century ago, in November 200
or the SHA-512/224 and SHA-512/256 buffer overruns). We might
want to run a bulk build to see how it pans out.
Thoughts?
>From 7c2a554b476a0b17ff015646bdaaecb761acc097 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Fri, 15 Mar 2024 22:23:27 +
Subject: [PATCH] openssl: Just rename the sha2 symbo
804622f0b0dce Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Sat, 16 Mar 2024 21:53:41 +
Subject: [PATCH] bsd.lib.mk: Check expected vs actual symbols at build-time.
If, for LIB=foo, you create a file foo.expsym, bsd.lib.mk will list
the dynamic symbols and their versions with
nm --dyn
> Date: Sat, 24 Feb 2024 16:21:42 -0500
> From: Thor Lancelot Simon
>
> On Wed, Feb 21, 2024 at 09:20:55PM +0000, Taylor R Campbell wrote:
> > I think this is a bug, and it would be great if stat(2) just returned
> > the physical medium's size in st_size --
> Date: Wed, 21 Feb 2024 10:52:55 +
> From: Sad Clouds
>
> Hello, for most operating systems determining the size of a block
> device can be done with:
>
> lseek(fd, 0, SEEK_END);
>
> However, on NetBSD this does not seem to work.
Internally, this is happens for more or less the same reaso
ely on this change, your code won't work in any of the
deployed implementations of strtoi anyway.
Thoughts?
The attached patch implements the proposed change in libc and the
automatic tests.
>From a64349a5ac209d9967ba3c5d6a62aa243f44f603 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date:
> Date: Thu, 7 Dec 2023 13:00:40 -0800
> From: enh
>
> the malloc one was reported to Android (as
> https://android-review.googlesource.com/c/platform/bionic/+/2856549)
> by wuhaitao3 ; Chris Ferris
> then spotted the goto nospc one.
>
> the other function in the file looks fine.
Thanks, I fil
> Date: Thu, 2 Nov 2023 20:05:28 +0100
> From: Edgar Fuß
>
> Oh well.
>
> > It effectively does -- the calls to _malloc_prefork/postfork(_child)
> > are baked into fork in NetBSD's libc:
> It does in -current, but the problem shows up in -8.
> I'll try to back-port the changes.
>
> Am I right t
> Date: Thu, 2 Nov 2023 18:26:43 +0100
> From: Edgar Fuß
>
> I've a long-standing problem of a process eating cpu time without doing
> anything useful, which, most probably, goes like this:
>
> Of a multi-threaded process,
> one thread is in malloc() while another thread fork()s.
> (So the chil
> Date: Sat, 28 Oct 2023 21:29:47 -0400 (EDT)
> From: Mouse
>
> So there _is_ a POSIX spec for tarchives? Is the spec available, or is
> this yet another pay-to-play "standard"? I've gone looking for specs
> for tar before, but each time I have, I've been unable to find anything
> that isn't be
[trimming tech-userlevel and tech-kern from cc list to avoid
cross-posting the entire thread]
> Date: Thu, 7 Sep 2023 11:53:56 + (UTC)
> From: RVP
>
> On Thu, 7 Sep 2023, Taylor R Campbell wrote:
>
> > I think we should have these knobs on by default, but of course
Today I learned that you can create hard links to a file you don't own
and can't write to or even read from:
$ su -l root -c 'touch /tmp/foo && chmod 600 /tmp/foo'
$ ln /tmp/foo /tmp/bar
This strikes me as bonkers and a likely source of security issues.
POSIX says:
> The implementation may requ
> Date: Sun, 3 Sep 2023 12:21:23 -0700 (PDT)
> From: Paul Goyette
>
> If I migrate to this new world order (ie, I delete existing package
> and clean out the /etc/openssl/certs directory), what happens to any
> packages that currently depend on mozilla-rootcerts? Will they
> somehow magically no
> Date: Mon, 28 Aug 2023 10:41:32 +0200
> From: Manuel Bouyer
>
> Maybe postinstall should check the /etc/openssl/certs.conf existance,
> and fail the 'fix opensslcerts' asking for it to be manually created;
> as we do for e.g. uid/gid if some are missing ?
I split it into two postinstall items:
Can mtree(8) be made to fail, i.e., return a nonzero exit status
(preferably 2), if there are any missing or extra files in the
directory tree relative to the specification?
If not, I think we should provide a way to do this. What should the
option be called? We may be running low on letters wit
> Date: Mon, 28 Aug 2023 08:42:58 -0400
> From: Greg Troxel
>
> Taylor R Campbell writes:
>
> > How is using /etc/openssl/certs/.certctl as the token different from
> > using /etc/openssl/certs.conf as the token?
>
> Because normal updates merge etc in variou
> Date: Mon, 28 Aug 2023 06:30:05 -0400
> From: Greg Troxel
>
> Maybe this is too much, but perhaps certctl should look for a .certctl
> in /etc/openssl/certs and only if present rm/replace. Or really only
> limit the rm; adding to an empty dir is fine. Basically a token that
> says the dir is
> Date: Sat, 26 Aug 2023 19:15:01 +0200
> From: Manuel Bouyer
>
> On Sat, Aug 26, 2023 at 04:48:59PM +0000, Taylor R Campbell wrote:
> > [...]
> > If you currently use security/mozilla-rootcerts or
> > security/ca-certificates (or security/mozilla-rootcerts-openssl
> Date: Sat, 26 Aug 2023 08:20:50 -0700 (PDT)
> From: Paul Goyette
>
> OK, I tried to read and understand the thread, but not really sure I
> succeeded with the understanding part. (In fact, i'm pretty sure I
> failed that part, miserably.)
This is about enabling TLS clients -- like ftp(1), pkg
> Date: Sat, 26 Aug 2023 06:50:22 -0400
> From: Jason Thorpe
>
> > On Aug 26, 2023, at 1:59 AM, Taylor R Campbell wrote:
> >
> > postinstall(8): Add opensslcerts item to regen /etc/openssl/certs.
> >
> > Works only with destdir /, since it relies
> Date: Wed, 23 Aug 2023 16:29:21 -0400
> From: Thor Lancelot Simon
>
> I would like to be sure we will avoid any use of public CA's certificates
> to establish trust for upgrades of NetBSD itself, or of packages. Otherwise,
> we will find ourselves in a situation where we can never recover if a
> Date: Sun, 20 Aug 2023 22:32:38 +0100
> From: David Brownlee
>
> There was a previous thread that mooted the idea of using the project
> built mozilla-rootcerts packages (which are just tarfiles) as the
> source for some mechanism to populate on-system certificates, such as
> your proposed cert
> Date: Sun, 20 Aug 2023 10:38:01 -0400
> From: Greg Troxel
>
> I'd like to see three things handled (which might be already):
>
> 1)
>
> a way for a user to install a CA cert (as a trust anchor -- I think it
> would be good for docs to use pkix terminology) that is not part of
> the mozi
> Date: Sun, 20 Aug 2023 05:43:23 +0200
> From: Jan Danielsson
>
> My objection in the past has been along the line of: If an
> organization is not willing to keep a CA bundle up-to-date for a user,
> then it should not dump a CA bundle that may grow stale onto their
> system either. But
> Date: Sun, 13 Aug 2023 13:03:09 +0200
> From: Rhialto
>
> On Sat 12 Aug 2023 at 11:58:36 +0000, Taylor R Campbell wrote:
> > Cons:
> > - POSIX doesn't ask system(3) to work when SIGCHLD is set to SIG_IGN
> > or when it has SA_NOCLDWAIT set, so this code
> Date: Sat, 12 Aug 2023 19:21:06 -0400
> From: Christos Zoulas
>
> 2. Nobody has given an example of an application that breaks, or answered
> the question if we understand how the Illumos feature is breaking things,
> or even if the Illumos implementation is similar to ours. Theodore
>
> Date: Sat, 12 Aug 2023 22:48:05 -0400 (EDT)
> From: Mouse
>
> > If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to
> > SIG_IGN, [...]
>
> Check my understanding: this applies to wait(2), but not alternatives
> like waitpid(2) or wait4(2), right?
If you read all the way
What should system(3) do when the signal action for SIGCHLD is
SIG_IGN, or has SA_NOCLDWAIT set?
Setting SIGCHLD to SIG_IGN has the effect of reaping zombie children
automatically, so that calling wait(2) is unnecessary to reap them --
and, further, doesn't return _at all_ until the last child ha
> Date: Thu, 3 Aug 2023 12:41:53 +0200
> From: Hauke Fath
>
> IANA appears to have settled on submissions for port 465 (which,
> coincidentally, was assigned to 'urd' in the netbsd-5 version, and the
> NetBSD addition then declared the smtps alias). A web search for
> 'smtps' confirms widespre
> Date: Wed, 26 Jul 2023 17:32:03 +0200
> From: tlaro...@polynum.com
>
> If setting LC_CTYPE to this:
>
> $ export LC_CTYPE=fr_FR.ISO8859-15
>
> and then:
>
> $ echo "éé" | sed 's/é/\é/g'
> sed: 1: "s/é/\é/g": RE error: trailing backslash (\)
>
> Where does the program manage to find a backsla
> Date: Thu, 13 Jul 2023 11:35:50 +0200
> From: tlaro...@polynum.com
>
> Severing will be the first thing done. Whether I will be able, in this
> first stage, to allow, from this newly created branch, to still
> optionally use the current implementation of DRM/KMS is an open
> question, and this g
> Date: Tue, 4 Jul 2023 18:30:58 +
> From: Taylor R Campbell
>
> Other low-hanging fruit I see would be to split getenv out of the
> other environment variable operations, to get rid of locking and
> rbtree stuff. But it's diminishing returns at this point -- n
> Date: Fri, 30 Jun 2023 13:37:10 -0400 (EDT)
> From: Mouse
>
> sparc, my mutant 1.4T:
>
> textdatabss dec hex filename
> 12616 124 288 13028 32e4main
>
> amd64, my mutant 5.2:
>
>text data bss dec hex filename
> 152613 441
estigating further; if someone wants to investigate and make
sure this actually works, feel free to commit this patch.
>From 4c1ca44f21e0d12ad2eac22dc8c3acbf56cfe23b Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Mon, 3 Jul 2023 12:58:34 +
Subject: [PATCH] libbsdmalloc: Provide more
> Date: Sat, 1 Jul 2023 15:11:56 - (UTC)
> From: mlel...@serpens.de (Michael van Elst)
>
> crt0 pulls in
> - atexit
> - environment
> - static TLS
> - stack guard
>
> which all more or less pull in jemalloc, stdio and string functions.
>
> You need to replace these with dummies (compile with
> Date: Sat, 1 Jul 2023 06:57:40 -0700
> From: Jason Thorpe
>
> Oh look, the entirety of jemalloc seems to be included in the
> binary. WTF knows why that's happening, but apparently it is, and
> jemalloc pulls in a ton of additional stuff.
Comes in from at least two different things:
1. jemal
> Date: Mon, 5 Jun 2023 15:01:44 +
> From: Emmanuel Dreyfus
>
> I would like to understand why nss_ldap is slow. I rebuilt the module
> with -pg and made a simple program that calls getpwnam(), also built
> with -pg
Is it slow because it's eating CPU time (as shown by top(1)), or is it
slow
> Date: Sat, 3 Jun 2023 14:12:21 +0200
> From: tlaro...@polynum.com
>
> Le Sat, Jun 03, 2023 at 12:02:20PM +0000, Taylor R Campbell a écrit :
> > > Date: Sat, 3 Jun 2023 13:45:44 +0200
> > > From: tlaro...@polynum.com
> > >
> > > So I suggest to a
> Date: Sat, 3 Jun 2023 13:45:44 +0200
> From: tlaro...@polynum.com
>
> So I suggest to add a mention of sysexits(7) to style.
I don't think sysexits(7) is consistently used enough, or really
useful enough, to warrant being a part of the style guide. Very few
programs, even those in src, use it,
> Date: Mon, 29 May 2023 10:11:09 +0200
> From: tlaro...@polynum.com
>
> The question is what to do in case of a config file not found (this is
> the initial problem: the realpath() return status is not tested and a
> structure is inconditionnally added to a linked list with an unreachable
> confi
> Date: Mon, 29 May 2023 13:13:33 +0200
> From: tlaro...@polynum.com
>
> I'm for: exit on any error. If we provide a way to check, that's the
> responsability of the administrator to check his config before trying to
> run the thing.
Yes please. Should provide an option to check a configuration
> Date: Thu, 18 May 2023 07:53:55 +0930
> From: Brett Lymn
>
> For "reasons" I have been looking to build nss-pam-ldapd and found that
> there are there are some changes that have been made by FreeBSD to nss
> that make it easier to port linux based applications that use nsswitch.
>
> The first
> Date: Thu, 16 Mar 2023 01:58:48 +0900
> From: Izumi Tsutsui
>
> > Proposal: Forbid extern declarations in .c files.
> :
> > Pretty simple. Any objections?
>
> No objection, but I wonder how we can resolve this case:
>
> https://nxr.netbsd.org/xref/src/sys/arch/hp300/stand/common/if_le.c?r=
he .c file defining it and the .c
files using it.
Pretty simple. Any objections?
>From f3e8932d02d1c80582de05cc0869aa3693ec339c Mon Sep 17 00:00:00 2001
From: Taylor R Campbell
Date: Wed, 15 Mar 2023 10:47:47 +
Subject: [PATCH] style(5): Forbid extern in .c files.
---
share/misc/style | 6 +
tl;dr: I think we're in the clear with no further effort in src.
> Date: Tue, 7 Mar 2023 09:55:33 +0100
> From: Thomas Klausner
>
> "This paper describes a vulnerability in several implementations of
> the Secure Hash Algorithm 3 (SHA-3) that have been released by its
> designers. [...]"
https
In sh(1) pathname expansion, the pattern doesn't constrain ordering,
only inclusion criteria. It appears that NetBSD's sh(1) always sorts
lexicographically with strcmp(3), however.
1. Does POSIX sh guarantee strcmp(3) lexicographic ordering?
2. Does NetBSD sh(1) guarantee strcmp(3) lexicographic
> Date: Sun, 06 Nov 2022 17:22:22 +0700
> From: Robert Elz
>
> One thing to beware of though, is that there is not enough info in a
> struct tm to determine which timezone created it. It simply cannot
> (in general) be done. Changing struct tm (however appealing that
> might be - and believe
> Date: Sat, 05 Nov 2022 20:49:57 +0700
> From: Robert Elz
>
> That's a variation of strftime() where you can tell it which time zone
> you want to use, instead of local time, for the conversions, so if you
> were to do
>
> z = tzalloc("UTC");
> t = gmtime(&some_time_t_variable);
>
> Date: Fri, 4 Nov 2022 14:53:42 -0700
> From: enh
>
> errbuf is only required to be non-NULL if errbuf_size != 0.
Thanks, applied!
> Date: Wed, 2 Nov 2022 15:59:00 +0300
> From: Valery Ushakov
>
> In other words, class tm doesn't have a public constructor that
> provides a way to specify TZ info. There are other factory methods
> that allow one to obtain an instance of tm that has the TZ info (in
> its private parts). ...
> Date: Wed, 31 Aug 2022 17:36:56 +0700
> From: Robert Elz
>
> This might also be an appropriate time to fix the man page for
> reallocarr(3) so it actually says something more than giving one
> (mediocre) example.
Better now?
> Date: Tue, 30 Aug 2022 09:18:47 -0400 (EDT)
> From: Mouse
>
> >> Is there any particular reason why /root/.profile and /root/.cshrc
> >> (that have hard links in / too, for the single user mode i guess)
> >> are not writable?
> > Aside from applications like vi rm mv etc (probably more) which
>
> Date: Tue, 30 Aug 2022 08:38:02 +0700
> From: Robert Elz
>
> Date:Tue, 30 Aug 2022 02:27:33 +0300
> From:Valery Ushakov
> Message-ID:
>
> | Is there any particular reason why /root/.profile and /root/.cshrc
> | (that have hard links in / too, for the single u
to be shareable, but in principle `cgdconfig -G' could
be taught to do that by generating a shared clause in the existing
keygen block and then adding an appropriate `keygen storedkey' block
as it already does to make it work -- TBD.
>From e21179d60d2e884fc9b691bfa4aa13ac30696d75 Mon Sep
> Date: Sat, 6 Aug 2022 18:47:47 -0400
> From: Gabriel Rosenkoetter
>
> I mostly use macOS at home and Windows at work in that "desktop" context
> these days, so I threw up my hands a few years ago and wrote my own
> credential manager whose datastore is a USB mass storage device attached
> to
[bcc tech-crypto@ tech-security@, followups to tech-userlevel@]
I would like to import the fidocrypt(1) utility into base:
https://github.com/riastradh/fidocrypt/
fidocrypt(1) is a small program that lets you `store' a secret on
U2F/FIDO keys, with a little state on disk that enables you to
regi
Seems to me if /rescue/tar is going to run gzip as a subprocess, it
should have the full path /rescue/gzip (or gzcat or whatever) baked
in so its behaviour doesn't depend on PATH.
> Date: Fri, 15 Apr 2022 15:29:49 +
> From: nia
>
> -a etcupdate can automatically update files which have not
>been modified locally. The -a flag instructs etcupdate to
>store MD5 checksums in /var/etcupdate and use these
>checksum
> Date: Thu, 17 Mar 2022 08:32:40 -0400
> From: Greg Troxel
>
> Simon Burge writes:
>
> > 5. Move all local mounts to /etc/rc.d/mountcritlocal (ala
> > FreeBSD) and possibly rename this to /etc/rc.d/mountlocal .
>
> I think the only thing we lose with this is the ability to mount local
>
> Date: Mon, 14 Mar 2022 08:01:53 -0700 (PDT)
> From: Paul Goyette
>
> On Tue, 15 Mar 2022, Simon Burge wrote:
>
> > Do we have any valid need to have non-critical local filesystems?
>
> Well, I have a dedicated filesystem for builds, separate from my
> OS. The /build happens to be my nvme SSD
Discussion about a reasonable API is ongoing, but I'll give some
review comments anyway -- including some of my thoughts on why the
crypt_r API is not ideal -- in case they're helpful.
--- include/unistd.h 15 Oct 2021 22:32:28 - 1.162
+++ include/unistd.h 12 Feb 2022 12:47:04 -
> Date: Wed, 16 Feb 2022 10:27:08 -0500 (EST)
> From: Mouse
>
> > Thi is an essential hardening step against FPGA/custom ASIC
> > implementations.
>
> I can't help feeling that there should be better ways to do that. I
> like the idea of resistance to such things, but, for at least my
> purpose
> Date: Mon, 8 Nov 2021 13:33:27 +
> From: nia
>
> On Sat, Nov 06, 2021 at 09:42:04AM +0000, Taylor R Campbell wrote:
> > That said, since we already argon2 logic as part of libcrypt, does it
> > make sense to have another copy in cgdconfig?
> >
> > I g
> Date: Sat, 6 Nov 2021 00:20:58 +
> From: nia
>
> > Why dup what you just created? Why not kg->kg_key = bits_new(raw,
> > keylen)? This looks like a (minor) memory leak.
>
> This is what the existing code for pkcs5_pbkdf2/sha1 does. I believe
> that the returned pointer (raw) is immediate
> Date: Fri, 5 Nov 2021 16:25:05 +
> From: nia
>
> This patch adds an "argon2id" password-based key generation method
> to cgdconfig(8).
Cool, thanks for working on this!
(For future patches: please use the `-p' option with cvs diff!)
> +++ lib/Makefile 5 Nov 2021 15:41:41 -
> @@
> Date: Wed, 20 Oct 2021 14:37:41 -0700
> From: Alistair Crooks
>
> I think it's a good idea, BUT I'd be a lot happier if the argon2 support
> was in a regular release (I know it's just the default cipher going
> forward, but I suspect some people have got into the nasty habit of cloning
> some o
> Date: Tue, 19 Jan 2021 22:16:32 +
> From: Taylor R Campbell
>
>input: 72057594037927937 -> scanf: 72057594037927937.00
>frac: 0.50 0x8.08p-4 sexp: 57
>uexp: b9
>ufrac: 0080
>56 : 00ff
> Date: Tue, 19 Jan 2021 22:16:32 +
> From: Taylor R Campbell
>
> This is not an integer, so conversion to uint64_t rounds it to
> nearest, with ties to even, so you get ufrac = 0x80 =
> 36028797018963968 as shown in the result.
Oops -- one more correct
> Date: Tue, 19 Jan 2021 22:10:56 +0100
> From: Rhialto
>
> The loss of precision probably occurs at the line
>
> // The following big literal is 2 to the 56th power:
> ufrac = (uint64_t) (frac * 72057594037927936.0);
>
> where frac is in the range [ 0.5 , 1.0 >, so I would expect that
> Date: Sun, 17 Jan 2021 10:43:41 +0200
> From: Andreas Gustafsson
>
> For the Nth time: if the problem is solved at the system integration
> level, there will be no blocking and therefore no need for your
> proposed change.
But conversely, if the problem is solved at the system integration
leve
> Date: Sat, 16 Jan 2021 14:34:47 +0200
> From: Andreas Gustafsson
>
> Even if the unblocking criteria of Linux and FreeBSD are questionable,
> they still provide more security than your proposal which amounts to
> having extremely strict criteria but then completely ignoring.
This is not accura
> Date: Sat, 16 Jan 2021 13:21:21 +0100
> From: Kamil Rytarowski
>
> On 11.01.2021 02:25, Taylor R Campbell wrote:
> > Many of you have no doubt noticed that a lot more things hang waiting
> > for entropy than used to on machines without hardware random number
> > g
> Date: Fri, 15 Jan 2021 15:35:26 -0500 (EST)
> From: Mouse
>
> >Such an application, like a Python program in the middle of just
> >doing `import multiprocessing', [...]
>
> Seems to me the elephant in the room here is: why would Python "just
> doing `import multiprocessing'" need crypt
> Date: Fri, 15 Jan 2021 20:54:21 +0200
> From: Andreas Gustafsson
>
> Your proposal would mean that
> such an application would generate predictable keys on NetBSD when no
> entropy is available, even though it will not on Linux. To me, that's
> complete
> Date: Fri, 15 Jan 2021 20:41:25 +0100
> From: Reinoud Zandijk
>
> Well no, on install, open a tcp connection to a TNF hosted server...
We've discussed this before. Before continuing on the topic, please
review the prior discussion like I just asked:
https://mail-index.netbsd.org/tech-crypto/
Folks, this thread was to discuss a specific proposal about the
getrandom and getentropy C API:
With these in mind, I propose that we change getrandom(p,n,0) so that
it does not block -- under the premise that dealing with low entropy
is a system integration problem, not a problem that it
> Date: Thu, 14 Jan 2021 13:21:58 +0100
> From: Manuel Bouyer
>
> On Thu, Jan 14, 2021 at 10:15:41AM +, nia wrote:
> > I still think my idea to record a second of noise from /dev/audio on
> > machines that totally lack other strong sources is a good one. We did
> > already put together the co
> Date: Thu, 14 Jan 2021 10:15:41 +
> From: nia
>
> I still think my idea to record a second of noise from /dev/audio on
> machines that totally lack other strong sources is a good one. We did
> already put together the code and test it on a range of hardware and
> VMs.
I agree -- I think sy
> Date: Mon, 11 Jan 2021 12:23:46 +0100
> From: Martin Husemann
>
> On Mon, Jan 11, 2021 at 01:25:36AM +0000, Taylor R Campbell wrote:
> > We might also do something similar with the motd -- add a single line,
> > citing entropy(7) for more details, if there's no
[bcc tech-kern, tech-security, tech-crypto; followups to
tech-userlevel to keep discussion in one place]
Many of you have no doubt noticed that a lot more things hang waiting
for entropy than used to on machines without hardware random number
generators (even as we've added a bunch of new drivers
> Date: Mon, 31 Aug 2020 00:25:52 +
> From: m...@netbsd.org
>
> The following script fails to compile, it shouldn't.
>
> #!/bin/sh
>
> cat << EOF > test.c
> #include
> #include
>
> void f1(void)
> {
> puts("pushed first");
> fflush(stdout);
> }
>
> void f2(void)
> {
> puts(
1 - 100 of 147 matches
Mail list logo
