On 11/6/22 09:29, Job Snijders wrote:
> Dear all,
>
> Support for using Ed25519 for server and user authentication was
> introduced in 2014. I like the compactness of Ed25519 public keys.
>
> Perhaps now is a good time to make Ed25519 the default key type when
> invoking ssh-keygen(1) without arg
> I'm sorry I cannot communicate any longer with you because you won't> give
> assurances that your company doesn't have really terrible> practices.> > Or,
> maybe you are just speaking dishonestly.I am literally laughing my ass of,
> you haven't changed a bit sinceback in 1996 with the FreeBSD
Should we have a small window where the key is generated, but not yet
the default?
Or should we use the snapshot period to create some pain, and see which
clouds react (we will allow them to self-publish their hate for the choices
of their customers), but then when release time comes, we can make
I think it's time; RFC 8709 has been a thing for a couple of years
now and a bit of gentle pressure is good.
ok djm, but cc openssh@ so others can chime in
-d
On Sun, 6 Nov 2022, Job Snijders wrote:
> Dear all,
>
> Support for using Ed25519 for server and user authentication was
> introduced i
On Sun, Nov 06, 2022 at 11:54:13AM +0100, Martin Pieuchot wrote:
> These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> will reduce contention a lot. I'd be happy to hear from test reports
> on many architectures and possible workloads.
>
> Do not forget to run "make syscalls" be
i...@tutanota.com wrote:
> Nov 6, 2022, 21:14 by dera...@openbsd.org:
>
> > I suspect your company forces children to make shoes, and your bosses
> > kick dogs and cats. Can you provide evidence that is not true?
> >
> > that is what your messages come off like.
> >
> > Grow up.
> >
> I am
Nov 6, 2022, 21:14 by dera...@openbsd.org:
> I suspect your company forces children to make shoes, and your bosses
> kick dogs and cats. Can you provide evidence that is not true?
>
> that is what your messages come off like.
>
> Grow up.
>
I am sorry that you read it this way, but that was
IIO7
It would be best that you Check out the commit logs and look at marc.info
(archives of mailing lists) ...( at the historical discussions on features
/ issues of interest to you .. )
it would be better that you do that rather than diverting developers
resources from what they do best...
yo
i...@tutanota.com wrote:
> Nov 6, 2022, 21:00 by dera...@openbsd.org:
>
> > Everything is provided with no warranty and you cannot insist on us
> > telling you what our processes are.
> >
> > You are out of line.
> >
> I am not insisting on anything, I am simply asking.
>
> We have supported th
Nov 6, 2022, 21:00 by dera...@openbsd.org:
> Everything is provided with no warranty and you cannot insist on us
> telling you what our processes are.
>
> You are out of line.
>
I am not insisting on anything, I am simply asking.
We have supported the project for many years and even know we ve
i...@tutanota.com wrote:
> Nov 6, 2022, 20:16 by dera...@openbsd.org:
>
> > Mr iio7,
> >
> > Your persistant questions as to our processes are pointless.
> >
> > You are asking these questions in this way to interfere.
> >
> > That is a dickhead move.
> >
> > Everyone can see it.
> >
> Well, then
Greg Steuck writes:
> My router has become unstable since upgrading from 7.1-stable to
> 7.2. After several days of uptime the machine gets into a state where
> some applications (unbound & dhcpd) report ENOBUFS (No buffer space
> available). At that time the machine is pingable over all the
> in
Nov 6, 2022, 20:16 by dera...@openbsd.org:
> Mr iio7,
>
> Your persistant questions as to our processes are pointless.
>
> You are asking these questions in this way to interfere.
>
> That is a dickhead move.
>
> Everyone can see it.
>
Well, then everyone needs glasses because I am NOT asking to
i
Yeah sure why not.
Klemens Nanni wrote:
> Upgrades are noiser on macppc (and loongson and octeon) than on other
> architectures because boot firmware changes and/or tips to complete an
> OpenBSD installation are always printed, even though they are not needed
> after an upgrade:
>
> INSTA
i...@tutanota.com wrote:
> >>> That is not your responsibility. It is mine.
> >>>
> >>> You can stop asking.
>
> I replied of list (by mistake by pressing reply rather than reply to all):
>
> >> Why do you keep wasting your precious time with these completely
> >> useless comments?
>
> To which
>>> That is not your responsibility. It is mine.
>>>
>>> You can stop asking.
I replied of list (by mistake by pressing reply rather than reply to all):
>> Why do you keep wasting your precious time with these completely
>> useless comments?
To which Theo answered back:
> Hi Mr. Dickhead.
>
> D
This patch switches sparc64 to clockintr(9).
mlarkin@ has tested it in an LDOM on the T4-1 in his garage. It
survived a parallel release build and an upgrade from the resulting
bsd.rd.
This needs more testing.
Testing on a machine without %SYS_TICK or %SYS_TICK_COMPARE
(UltraSPARC I?) would be
This patch switches landisk to clockintr(9).
We have no direct control over the interrupt clock on these machines
so the patch is relatively simple.
miod@ has been testing it. He reports it has survived a release build
and an upgrade from the resulting bsd.rd.
It could use additional testing, t
This patch switches riscv64 to clockintr(9).
jca@ has been testing it (on a SiFive board?). It has survived two
parallel release builds and upgrades from the resulting bsd.rd.
It could use testing on another machine. Are there other practical
machines aside from SiFive?
Index: sys/arch/riscv64
This patch switches powerpc64 to clockintr(9).
gkoehler@ has been testing it, I assume on some kind of Raptor
Computing Power9. It has survived two parallel release builds and
upgrades from the resulting bsd.rd.
Testing on an additional powerpc64 machine would help.
Notes:
- There are no longe
This patch switches macppc to clockintr(9).
It has survived two or three parallel release builds on my G4 MDD
(PowerMac7,3) and upgrades from the resulting bsd.rd. The machine
does not have a working IDE drive at the moment, so I booted and built
over USB 1.1 on an external drive.
It needs testi
This patch switches loongson and octeon to clockintr(9).
It has survived several release builds and upgrades from the resulting
bsd.rd images on my ER-4. The ER-4 doesn't have enough RAM to crunch a
parallel release build. It chokes on some of the larger LLVM modules.
visa@ reports it survived
On Mon, Oct 31, 2022 at 11:11:22AM +, Klemens Nanni wrote:
> On Sun, Oct 16, 2022 at 05:22:57AM +, Klemens Nanni wrote:
> > On Sat, Oct 08, 2022 at 07:25:26PM +, Klemens Nanni wrote:
> > > If /usr is mounted read-only, kernel relinking fails silently without
> > > any log trace.
> > >
This patch switches luna88k to clockintr(9).
We have no control over the interrupt clock on luna88k so the patch
is pretty simple.
aoyama@ has built a release and upgraded from the resulting bsd.rd on
his LUNA-88K2.
A test on a different machine might help. Not sure how many there
are.
Index:
This patch switches i386 to clockintr(9).
I have tested this on my Lenovo X1 Carbon 6th and Dell Optiplex 7070
running in 32-bit compatibility mode. It has survived ~20 parallel
release builds and upgrades from the resulting bsd.rd.
mlarkin@ has tested this in an ESXi VM and reports that ACPI hi
This patch switches hppa to clockintr(9).
kettenis@ has tested it on his B2000, which is not MP.
It probably needs testing on an MP hppa machine. I am uncertain how
common these things are.
Notes:
- hppa machines now have a randomized statclock().
- Rename cpu_hardclock() to itmr_intr() keep
This patch switches arm64 to clockintr(9).
This has survived about a dozen parallel kernel builds, parallel
release builds, and bsd.rd upgrades on my RPi4b.
kettenis@ said he tried it on one of his M1 machines, too.
It could use more testing, particularly on arm64 machines that aren't
a Raspberr
This patch switches amd64 to clockintr(9).
It needs as much testing as you can give it.
I have tested it for months on two different machines: a Lenovo X1
Carbon 6th, and a Dell Optiplex 7070. The patch has survived dozens
of parallel kernel builds, parallel release builds, and upgrades from
the
This patch switches alpha to clockintr(9).
We have no direct control over the interrupt clock, so the patch is
relatively straightforward.
claudio@ tested this on his DS-20. It compiled and booted. It may
have survived a `make build`, too. claudio's machine is weird though.
Apparently RPCC is
On Sat, Oct 22, 2022 at 06:16:34PM +, Klemens Nanni wrote:
> Logging the presence of a keydisk the same way offline data chunks are
> reported seems unjustified.
>
> Noting offline chunks serves as warning, so the user can bring them
> online and update bootblocks.
>
> Keydisks, however, are
Hello,
diff below is the first step to make pfioctl() _without_ NET_LOCK().
Currently pf_if.c seems to be the only blocker which prevents us
from removing all NET_LOCK()/NET_UNLOCK() calls we have in pf(4).
diff below passed very basic smoke test. OK to commit?
thanks and
regards
sashan
--
On Sun, Nov 06, 2022 at 04:48:11PM +, Klemens Nanni wrote:
> On Sun, Nov 06, 2022 at 05:43:15PM +0100, Alexandr Nedvedicky wrote:
> > On Sun, Nov 06, 2022 at 01:06:02PM +, Klemens Nanni wrote:
> > > Just like bpf(4)... except bpf actually also creates bpf0 still.
> > >
> > > $ ls -1 /dev
On Sun, Nov 06, 2022 at 05:43:15PM +0100, Alexandr Nedvedicky wrote:
> On Sun, Nov 06, 2022 at 01:06:02PM +, Klemens Nanni wrote:
> > Just like bpf(4)... except bpf actually also creates bpf0 still.
> >
> > $ ls -1 /dev/{b,}pf*
> > /dev/bpf
> > /dev/bpf0
> > /dev/pf
> >
> > OK
On Sun, Nov 06, 2022 at 01:06:02PM +, Klemens Nanni wrote:
> Just like bpf(4)... except bpf actually also creates bpf0 still.
>
> $ ls -1 /dev/{b,}pf*
> /dev/bpf
> /dev/bpf0
> /dev/pf
>
> OK?
looks ok to me, I think no on one expects to create /dev/pf0, /dev/pf1 .
On Sun, Nov 06, 2022 at 04:29:59PM +0100, Solène Rapenne wrote:
> Le Sun, 6 Nov 2022 14:29:52 +,
> Job Snijders a écrit :
>
> > Dear all,
> >
> > Support for using Ed25519 for server and user authentication was
> > introduced in 2014. I like the compactness of Ed25519 public keys.
> >
> > P
Le Sun, 6 Nov 2022 14:29:52 +,
Job Snijders a écrit :
> Dear all,
>
> Support for using Ed25519 for server and user authentication was
> introduced in 2014. I like the compactness of Ed25519 public keys.
>
> Perhaps now is a good time to make Ed25519 the default key type when
> invoking ssh
On Sun, 6 Nov 2022 at 18:31, Job Snijders wrote:
>
> Dear all,
>
> Support for using Ed25519 for server and user authentication was
> introduced in 2014. I like the compactness of Ed25519 public keys.
>
> Perhaps now is a good time to make Ed25519 the default key type when
> invoking ssh-keygen(1)
Dear all,
Support for using Ed25519 for server and user authentication was
introduced in 2014. I like the compactness of Ed25519 public keys.
Perhaps now is a good time to make Ed25519 the default key type when
invoking ssh-keygen(1) without arguments?
Kind regards,
Job
Index: ssh-keygen.1
===
Hello,
>
> claudio had some questions about numbers used by the diff. some of the
> maths here is set up so that every pf state purge run is guaranteed to
> do a MINUMUM amount of work. by default pf is configured with a purge
> interfval of 10 seconds, bu the pf state purge processing runs ever
On Tue, Jun 07, 2022 at 04:58:24PM +1000, David Gwynne wrote:
> the main change here is to move pf_purge out from under the kernel lock.
>
> another part of the change is to limit the amount of work the state
> purging does to avoid hogging a cpu too much, and to also avoid holding
> NET_LOCK for
Just like bpf(4)... except bpf actually also creates bpf0 still.
$ ls -1 /dev/{b,}pf*
/dev/bpf
/dev/bpf0
/dev/pf
OK?
Index: MAKEDEV.common
===
RCS file: /cvs/src/etc/MAKEDEV.common,v
retrieving revisi
On Sun, Nov 06, 2022 at 10:42:49PM +1000, David Gwynne wrote:
> this is a small chunk to help sashan@ out with some of the pf ioctl work
> he is doing.
>
> he is looking at allocating config over multiple ioctls, and would like
> to be able to throw it away in situations like if the userland progr
this is a small chunk to help sashan@ out with some of the pf ioctl work
he is doing.
he is looking at allocating config over multiple ioctls, and would like
to be able to throw it away in situations like if the userland program
creating the state goes away. with the current vnode and device speci
These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
will reduce contention a lot. I'd be happy to hear from test reports
on many architectures and possible workloads.
Do not forget to run "make syscalls" before building the kernel.
Index: syscalls.master
44 matches
Mail list logo
