> 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
> 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
>
> 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.
> 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
t 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 symbols.
Ditch all our other local changes related to them.
These symbols end up as private symbols in
: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 --dynamic --extern-only --defined-o
> 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 -- curre
> 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
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: Sat, 20 Jan 2024 18:17:27 +
Subject: [PATCH 1/2] st
> 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
> 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
> 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
> 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
[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 co
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
> 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
> 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
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
> 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
> 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),
> 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
> 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
> 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
> 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
> 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.
> 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 is n
> 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
> 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
> 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
> 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
> 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 -- not cl
> 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
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 allocator frontends.
- aligne
> 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
> 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.
> 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
> 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
>
> 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:
>
>
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. [...]"
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)
> 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(_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
`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 17 00:00:00 2001
From: Taylor R Campbell
Da
> 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
>
[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
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
>
> 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
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
>
> 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
> 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
> 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 corr
> 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
> 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
> 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
> 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
>
> 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:
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
> 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
> 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
> 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 not eno
[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)
> {
>
The reason we imported unbound/nsd in the first place was so that we
wouldn't be stuck with tracking bind. Why don't we just remove it
like we planned to do years ago?
The only reason we imported nsd, too, was to mitigate possible fallout
from losing any authoritative nameserver in base when we
[trimming cc list to tech-crypto]
> Date: Tue, 12 May 2020 11:45:58 -0400
> From: Thor Lancelot Simon
>
> 1) It's hard to understand how many bits of entropy to assign to a
>sample from one of these sources. [...]
>
>The delta estimator _was_ good for these things, particularly for
>
> Date: Mon, 11 May 2020 12:42:13 -0700 (PDT)
> From: Paul Goyette
>
> Why can't we allow the user to configure/enable estimation on a
> per-source basis? The default can certainly be "disabled", but
> why not override? Just like any other super-user thing, there's
> no reason not to enable
> Date: Mon, 11 May 2020 16:16:12 - (UTC)
> From: mlel...@serpens.de (Michael van Elst)
>
> Previously we could trust in random processes, whether the entropy
> estimation was scientific or not. We could also chose what source
> to trust.
Still can. NetBSD just doesn't do bogus
> Date: Sun, 10 May 2020 22:10:55 +
> From: m...@netbsd.org
>
> I still don't find the getrandom man page you provided to be good, it
> talks about "/dev/random behaviour" which is something you've changed to
> not have this behaviour.
Can you be specific?
The phrase `/dev/random behaviour'
> Date: Sun, 10 May 2020 14:24:00 +0300
> From: Andreas Gustafsson
>
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications
> Date: Sun, 10 May 2020 07:44:36 +0200
> From: Michael van Elst
>
> On Sun, May 10, 2020 at 05:23:37AM +0000, Taylor R Campbell wrote:
> > But how is this question relevant to the discussion at hand of whether
> > to adopt a de facto standard C API or which?
>
>
> Date: Sun, 10 May 2020 04:58:23 - (UTC)
> From: mlel...@serpens.de (Michael van Elst)
>
> riastr...@netbsd.org (Taylor R Campbell) writes:
>
> >(Obviously, it is possible to run a kernel with an /etc/rc script that
> >skips loading the seed from disk altogether
> Date: Sun, 10 May 2020 00:10:49 +
> From: m...@netbsd.org
>
> On Sat, May 09, 2020 at 10:56:51PM +0000, Taylor R Campbell wrote:
> > Given that, I think it is reasonable to implement getentropy(...) as
> > an alias for getrandom(..., GRND_INSECURE) == read from /d
> Date: Sun, 3 May 2020 21:43:15 +
> From: nia
>
> On Sun, May 03, 2020 at 09:28:37PM +0000, Taylor R Campbell wrote:
> > But on closer inspection, it's not clear there's a consensus on what
> > the semantics is supposed to be -- apparently _what_ everyone seems to
&
> Date: Sun, 3 May 2020 19:13:23 +
> From: nia
>
> Since most of the objections so far have been aimed at the design
> and implementation of getrandom, does anyone have anything bad to say
> about getentropy?
That's what I had in mind at the start of the thread after verifying
_that_ most
rough /dev/random and perhaps soon through
getrandom.
> Date: Sun, 3 May 2020 10:48:41 +0200
> From: Kurt Roeckx
>
> On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> > +Despite the name, this is secure as long as you only do it
> > +.Em afte
> Date: Sat, 2 May 2020 18:07:54 +0200
> From: Kurt Roeckx
>
> On Sat, May 02, 2020 at 03:38:43PM +0000, Taylor R Campbell wrote:
> > > Date: Sat, 2 May 2020 11:10:44 +0200
> > > From: Kurt Roeckx
> > >
> > > I hink we've previously talked
> Date: Sat, 2 May 2020 12:22:20 +
> From: m...@netbsd.org
>
> The getrandom interface intentionally traps people to make questionable
> design choices.
I agree that the getrandom interface is not perfect, and I found the
Linux documentation rather confusing, but after having reimplemented
> Date: Sat, 2 May 2020 11:10:44 +0200
> From: Kurt Roeckx
>
> On Fri, May 01, 2020 at 07:19:09PM +0000, Taylor R Campbell wrote:
> >
> > The alias getentropy(p,n) := getrandom(p,n,GRND_INSECURE)
>
> At several places in your document you imply this. But
1 - 100 of 121 matches
Mail list logo
