greetz,
Here's the latest version with all required changes
nbupgrade.tar.gz
Description: Binary data
Here is an updated version based on the feedback received so far -
thanks for the attention and fixes.
nbupgrade.tar.gz
Description: Binary data
On Thu, May 02, 2024 at 04:50:21PM +0300, Valery Ushakov wrote:
> On Thu, May 02, 2024 at 06:52:13 +0000, nia wrote:
>
> > hey, I wrote this script to replace sysupgrade (but maintainable and
> > not using a weird shell library), would be nice to import it.
>
> Just a
# nbupgrade -pc -s "base32 base64"
Fetch the sets from the stable branch netbsd-11:
# nbupgrade -r netbsd-11 -f
Install a CURRENT kernel:
# nbupgrade -r head -k
SEE ALSO
nbupgrade.conf(5), etcupdate(8), postinstall(8), sysinst(8)
AUTHORS
On Thu, Apr 25, 2024 at 12:06:07AM +0200, Thomas Klausner wrote:
> On Wed, Apr 24, 2024 at 03:46:20PM +0000, Nia Alarie wrote:
> > Module Name:src
> > Committed By: nia
> > Date: Wed Apr 24 15:46:20 UTC 2024
> >
> > Modified Files:
>
On Mon, Aug 14, 2023 at 07:39:11AM -0400, Greg Troxel wrote:
> Jonathan Perkin writes:
>
> > * On 2023-08-13 at 18:10 BST, Tobias Nygren wrote:
> >
> >>On Sat, 12 Aug 2023 19:21:06 -0400
> >>Christos Zoulas wrote:
> >>
> >>> I really want to understand what's going on here (why do we think that
On Fri, Aug 11, 2023 at 06:52:41PM -, Christos Zoulas wrote:
> I see that you removed with without further discussion which is not the
> way we do things on NetBSD. Do you have an example where the epoll emulation
> breaks, because either forking matters or the implementation is
> incorrect/dif
On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote:
> Anyway, like I said, I think the best way forward is to make it possible for
> kq descriptors to be inherited… it’s a little tricky because of some of the
> wacky stuff kqueue can track, but I think NetBSD can lead on this and define
On Mon, Jul 31, 2023 at 04:27:32AM -0700, Jason Thorpe wrote:
>
> > On Jul 31, 2023, at 1:38 AM, nia wrote:
> >
> > Hey, I regret that epoll was committed without further discussion with
> > pkgsrc developers. We have a lot of experience with this already
>
On Mon, Jul 31, 2023 at 11:27:37AM +0200, Tobias Nygren wrote:
> On Mon, 31 Jul 2023 08:38:31 +
> nia wrote:
>
> > Hey, I regret that epoll was committed without further discussion with
> > pkgsrc developers. We have a lot of experience with this already
> >
Hey, I regret that epoll was committed without further discussion with
pkgsrc developers. We have a lot of experience with this already
(illumos/SmartOS exposes a compatibility epoll) and the situation is
not entirely great and requires lots of workarounds.
Mostly, the situation of having epoll fr
On Tue, Oct 04, 2022 at 12:21:08AM +0200, Joerg Sonnenberger wrote:
> On Mon, Oct 03, 2022 at 12:31:42PM +0000, nia wrote:
> > I'd argue that providing alloca(3) as anything except a compiler
> > builtin is a bug, and that kind of thing should never be used.
>
> Well
On Mon, Oct 03, 2022 at 08:45:33AM -0400, Mouse wrote:
> > I'd argue that providing alloca(3) as anything except a compiler
> > builtin is a bug, and that kind of thing should never be used.
>
> I'd argue that alloca should never be used and actually should never
> have existed. As far as I can s
On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> Is there any reason we don't simplify this in the headers -
> __builtin_alloca(size) seems to work with every compiler?
I forgot to add: __builtin_alloca works with -std=c99,
with GCC and clang.
This TODO item has been in libc's shlib_version file for ages:
"remove alloca fallback and expect compiler to provide a builtin version."
On various architectures (powerpc, aarch64), pkgsrc bulk build reports
are filled with the following error:
"undefined reference to `alloca'"
On other archit
On Sun, Aug 14, 2022 at 09:58:46AM +0200, Martin Husemann wrote:
> On Sun, Aug 14, 2022 at 07:36:17AM +0000, nia wrote:
> > Display managers do not create login shells, and xdm was used.
>
> Adapt the default /etc/X11/xdm/Xsession instead? Maybe make it extract
> PA
On Sun, Aug 14, 2022 at 12:33:39AM +0200, Joerg Sonnenberger wrote:
> On Sat, Aug 13, 2022 at 08:59:07PM +0000, nia wrote:
> > A problem many new NetBSD users encounter is that a default shell
> > without an initialized home directory containing a ~/.profile
> > does not inc
On Sat, Aug 13, 2022 at 10:41:14PM +, Jeremy C. Reed wrote:
> On Sat, 13 Aug 2022, nia wrote:
>
> > A problem many new NetBSD users encounter is that a default shell
> > without an initialized home directory containing a ~/.profile
> > does not include some system
A problem many new NetBSD users encounter is that a default shell
without an initialized home directory containing a ~/.profile
does not include some system PATH entries that would otherwise be
provided from /etc/skel/.profile.
This came up during the recent El Reg "review" of NetBSD 9.3.
This pa
I've heard some reports that the HPN-SSH patches to sshd are
not quite working as well as expected, with some users getting
mildly worse results. They're apparently supposed to improve
performance:
https://www.psc.edu/hpn-ssh-home/
With "HPNDisabled" in sshd_config I notice no particular differe
On Tue, Apr 12, 2022 at 07:19:59AM +0700, Robert Elz wrote:
> Once again you are making assumptions about the way it is used.
> mkstr is only used for particular programs which are designed to
> be used with it, not simply any random source code. Those were ones
> (and one in particular) that wer
On Fri, Apr 15, 2022 at 01:20:04PM -0400, Greg Troxel wrote:
> Use of RCS IDs seems fragile/unsound in that you can't conclude from
> matching IDs that the files match, or really the other way around, given
> people storing sources in !cvs with local modes, local builds, etc.
> (Not saying doing lo
On Fri, Apr 15, 2022 at 08:05:54AM -0400, Greg Troxel wrote:
> To me, the right behavior is to know if each file in etc has been put
> there as a copy of a file that appeared in etc.tgz, and to change it to
> the new version without prompting if so, and if not, to note to the user
> that it might n
On Fri, Apr 15, 2022 at 10:56:00AM +0200, Martin Husemann wrote:
> On Fri, Apr 15, 2022 at 08:21:00AM +0000, nia wrote:
> > There's been a few discussions over the years about the need for a
> > usable-over-ssh binary upgrade tool for NetBSD, but they haven't gone
> >
There's been a few discussions over the years about the need for a
usable-over-ssh binary upgrade tool for NetBSD, but they haven't gone
very far. Users ask fairly frequently, and other than sysupgrade, the
best method is to implement sysupgrade manually with ftp and tar (and
this is required for
=
RCS file: sbin/cgdconfig/argon2_utils.c
diff -N sbin/cgdconfig/argon2_utils.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sbin/cgdconfig/argon2_utils.c 8 Nov 2021 13:26:03 -
@@ -0,0 +1,171 @@
+/* $NetBSD$ */
+/*-
+ * Copyright (c) 2021 The NetBSD Foundation, Inc.
RCS file: sbin/cgdconfig/argon2_utils.c
diff -N sbin/cgdconfig/argon2_utils.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sbin/cgdconfig/argon2_utils.c 6 Nov 2021 00:17:48 -
@@ -0,0 +1,168 @@
+/* $NetBSD$ */
+/*-
+ * Copyright (c) 2021 The NetBSD Foundation, Inc.
+ * All
right (c) 2021 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to The NetBSD Foundation
+ * by Nia Alarie.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the fo
On Sun, Oct 31, 2021 at 04:45:59PM -0700, Alistair Crooks wrote:
> Or is the intent to discuss this in retrospect?
Is the concern primarily with it not being in a release?
I'm not really certain how I could address it, other than a prerequisite
waiting a few years. It's true that existing passwor
I want to change the default cipher in passwd.conf to
Argon2id, for these reasons:
- Argon2id is resistant to GPU-based password cracking attacks.
- Argon2id is resistant to side channel attacks.
- It allows us to dynamically scale the CPU time and memory required
to compute a password hash, mak
On Sat, Oct 09, 2021 at 07:59:24AM +0100, Iain Hibbert wrote:
> you didn't make libargon2_pic.a first? can't link without dependency
> already built..
Figures.
> not sure how you are getting to the stage "when libcrypt builds", and my
> sources are older but I see that lib/Makefile has libcryp
I'm trying to make the MKARGON2 stuff work properly with a release
build.
Since libuv was made into a private library for BIND, I thought it
would be a good model to follow.
However, when libcrypt builds, I get the following:
nbmake[7]: nbmake[7]: don't know how to make
/home/nia/ob
There are likely problems mixing different OpenSSL shared object
versions in pkgsrc, no?
If NetBSD 10 is to have OpenSSL 1.1 I think it's critical we
establish a flow for maintaining it in the long term (whether
it's by pulling patches from Red Hat, etc), so it doesn't rot
like netbsd-8.
On Fri, Jun 11, 2021 at 09:41:39PM +, RVP wrote:
> 1. Is `hwloc_thread_t' the same as `pthread_t' when hwloc is compiled
>on NetBSD?
>
> 2. Does a `make check' of hwloc on NetBSD pass?
>
> -RVP
Yes to both. Martin pointed out on IRC that the problem is the main
reference executable (as o
On Fri, Jun 11, 2021 at 06:48:57PM +0200, Martin Husemann wrote:
> On Fri, Jun 11, 2021 at 04:41:51PM +0000, nia wrote:
> > However, this value comes from the return value of pthread_self():
>
> You did not link with -pthread (so you get the libc stub of pthread_self()).
&
For some trivia/background, I am working on OpenCL support (some parallel
computing standard that someone mentioned wanting) in pkgsrc.
I've ported a "portable" CPU-based OpenCL implementation (parallel/pocl)
to NetBSD.
However, currently all reference OpenCL programs linked with -lOpenCL
fail, s
On Wed, May 19, 2021 at 08:58:42PM +0200, Joerg Sonnenberger wrote:
> On Wed, May 19, 2021 at 09:56:23AM +0000, nia wrote:
> > The current situation in pkgsrc (where lots of software using alloca
> > needs to be BUILDLINK_TRANSFORMED to use the -std=gnu... variant, or
> >
I think there's several points of view:
1) Everything using alloca() is broken (valid, it's a nasty function)
2) Everything using extensions should properly declare it does so
(using eg. -std=gnu99 and so on), and not use standards mode.
2) Software that makes certain assumptions about almos
I made some adjustments to the scrolling code so it should
be more robust with a "git pull". Please test :)
On Thu, May 06, 2021 at 07:55:34PM +0200, Tobias Nygren wrote:
> On Thu, 6 May 2021 13:44:47 +
> nia wrote:
>
> > Review and comments welcome, of course.
>
> Hi,
>
> This looks useful, I support importing it into src.
> Found some minor bugs though:
>
>
For those unfamiliar, aiomixer is my name for my graphical
(curses-based) frontend to NetBSD mixer devices.
It has similar functionality to mixerctl, but is designed to be more
user-friendly for interactive use. For example, hold the arrow keys,
the system's volume changes, you get instant visual
On Sat, Apr 17, 2021 at 07:18:31AM +0700, Robert Elz wrote:
> Is it practical to use audiocfg that way, as the likely commands
> (most likely only reasonable commands) to use in /etc/audio.conf
> are "set" and "default", and both of those control a device
> specified by a numeric index, which seems
\"
+.\" Copyright (c) 2021 The NetBSD Foundation, Inc.
+.\" All rights reserved.
+.\"
+.\" This code is derived from software contributed to The NetBSD Foundation
+.\" by Nia Alarie.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\
On Thu, Mar 18, 2021 at 09:01:47AM +0100, Roland Illig wrote:
> Another thing is to check for GNU-specific C features such as
> __FUNCTION__ (which is easy to avoid in C99), ({...}), array
> initialization with [a...b], and so on. I don't think even GCC can
> reliably detect these.
Doesn't lint c
I noticed some odd behaviour when I tried to use patch(1) without
creating backup files (-V none). It seems this option is ignored,
and backup files are created anyway. The PATCH_VERSION_CONTROL
environment variable can also override -V none, which is the
opposite of the behaviour stated in the man
On Tue, Feb 02, 2021 at 08:53:05PM +0100, Jaromr Dole?ek wrote:
> Hallo,
>
> what would be involved?
IIRC,
For the Intel vulkan driver, we need Linux-compatible futexes.
For the AMD vulkan driver, we need amdgpu DRMKMS.
For the software driver there's a load of Mesa patches I am slowly
upstrea
On Fri, Jan 15, 2021 at 02:01:45PM +1030, Brett Lymn wrote:
> If we have network of some sort can we leverage packet timing jitter somehow?
We do. In current it gets fed into the pool, but no longer increases the
entropy counter because it's deemed to be manipulable by hostile
parties. NetBSD 9 an
On Thu, Jan 14, 2021 at 09:43:44PM +, RVP wrote:
> Is this OK (or, it is hopelessly insecure)?:
If you have the same secure randomness as everyone else you don't have
secure randomness.
If you do have unique secure randomness, you only need 256 bits of it
to continue generating it forever.
>
On Mon, Jan 11, 2021 at 12:23:46PM +0100, Martin Husemann wrote:
> I still think that this should be dealt with (once and for all) at
> installation time (as we did for a short period, for some machines and
> install methods) - but apparently it is impossible to reach consensus
> on the wording and
While trying to accurately replicate NetBSD's struct addrinfo for
crystal[0], I noticed this pattern occurs twice in netdb.h...
#if defined(__alpha__) || (defined(__i386__) && defined(_LP64))
int __ai_pad0; /* ABI compatibility */
#endif
This was added in 2004 in response
On Tue, May 12, 2020 at 11:18:02AM -0400, Terry Moore wrote:
> A useful definition requires that third-party code will not have surprising
> security defects compared to their operation on other operating systems.
There are other concerns for whether third party code works well..
I'll just copy w
On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote:
> This unfortunate situation should be addressed by providing more
> entropy sources, not by burying our heads in the sand and pretending
> we have entropy when we don't. Adding more sources could mean
> reintroducing some timing
On Mon, May 11, 2020 at 04:28:51PM +0300, Andreas Gustafsson wrote:
> For the OpenBSD strategy to work, the system needs to actually refuse
> to run if the seed can't be loaded (or full entropy achieved in some
> other way). NetBSD doesn't do that. As long as there is any way
> userland can start
On Mon, May 11, 2020 at 09:53:31AM +0300, Andreas Gustafsson wrote:
> OpenBSD guarantees that there is an entropy seed from the boot loader,
> which is very different from NetBSD's "best effort". Was this not
> already the case when the getentropy API was introduced?
We do the same, on supported
On Sun, May 10, 2020 at 02:24:00PM +0300, Andreas Gustafsson wrote:
> 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 do i
On Sat, May 09, 2020 at 01:13:44PM +, nia wrote:
> Right, yes, the CPUID stuff wasn't being defined when builing EVP which
> meant the dumb asm implementation was being used instead of HW/VP/BSAES.
>
> That's fixed now. Everything else appears to still be slightly slo
Right, yes, the CPUID stuff wasn't being defined when builing EVP which
meant the dumb asm implementation was being used instead of HW/VP/BSAES.
That's fixed now. Everything else appears to still be slightly slower,
but that's less critical than the AES implementation.
It almost seems like the asm implementations aren't being enabled
properly. Algorithms with no x86_64 asm (like blowfish) don't
shown a significant difference, whereas with AES and sha512
the difference is huge.
What's going on?
r[nia]$ /usr/pkg/bin/openssl speed -evp aes-256-gc
On Sun, May 03, 2020 at 09:28:37PM +, Taylor R Campbell wrote:
> > 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 b
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?
If not, I'll commit it.
> nia@ wrote the getentropy patch (probably needs a set list update too,
> and could use an automatic test); I wrote the getrandom patch.
> Feedback welcome!
My arguments for getentropy can be roughly summarized:
- It's just providing access to functionality already exposed to
61 matches
Mail list logo
