Hi,
This syncs lib/libcbor from our v0.5.0+patches to the released v0.7.0
AFAIK the changes are mostly inconsequential to the current uses
in-tree (there is a stack exhaustion fix that is worth having), but
being at an actual release rather than a frankenpatch will make future
updates a bit
Multiple rtables may exist in the default rdomain (0), that is their
corresponding rdomains/lo(4) interfaces do not have to exist.
This demonstrates it; first, nothing but default, so route(8) fails:
# netstat -R
Rdomain 0
Interfaces: lo0 vio0 enc0
Routing
On Wed, 29 Jul 2020 07:45:52 +0200
Marcus Glocker wrote:
> On Sat, 25 Jul 2020 18:27:45 +0100
> Laurence Tratt wrote:
>
> > On Sat, Jul 25, 2020 at 10:27:15AM -0600, Theo de Raadt wrote:
> >
> > Hello Theo,
> >
> > > My primary concern is about a user changing settings which then
> > >
On Wed, Jul 29, 2020 at 10:14:11PM +0200, Mark Kettenis wrote:
> > Date: Wed, 29 Jul 2020 13:03:43 -0700
> > From: Mike Larkin
> >
> > Hi,
> >
> > I'm seeing crashes on amd64 GENERIC.MP on a few VMs recently. This happens
> > on GENERIC.MP regardless of whether or not the VM has one cpu or more
On Wed, Jul 29, 2020 at 01:03:43PM -0700, Mike Larkin wrote:
> Hi,
>
> I'm seeing crashes on amd64 GENERIC.MP on a few VMs recently. This happens
> on GENERIC.MP regardless of whether or not the VM has one cpu or more than
> one. It does not happen on GENERIC kernels.
>
> The crash will happen
> Date: Wed, 29 Jul 2020 13:03:43 -0700
> From: Mike Larkin
>
> Hi,
>
> I'm seeing crashes on amd64 GENERIC.MP on a few VMs recently. This happens
> on GENERIC.MP regardless of whether or not the VM has one cpu or more than
> one. It does not happen on GENERIC kernels.
>
> The crash will
Hi,
I'm seeing crashes on amd64 GENERIC.MP on a few VMs recently. This happens
on GENERIC.MP regardless of whether or not the VM has one cpu or more than
one. It does not happen on GENERIC kernels.
The crash will happen fairly quickly after the kernel starts executing
processes. Sometimes it
Now pipex(4) is fully covered by NET_LOCK() and this is documented. But
we still have an issue with pipex(4) session itself and I guess it's
time to fix it.
We have `pipexinq' and `pipexoutq' mbuf(9) queues to store mbufs. Each
mbuf(9) passed to these queues stores the pointer to corresponding
On Tue, Jul 28, 2020 at 06:16:01PM -0700, Mike Larkin wrote:
> Someone (can't recall who) gave me an ER4. I found it while cleaning
> out my closet. Since I'm not active anymore, if any openbsd developer
> wants it, reach out to me privately and I'll see about sending it
> to you.
>
> Thanks.
>
>
Poking and testing around in brconfig.c for tpmr(4) stuff, I noticed a
lot of old code around strto*l(3).
Many pass unbounded `long' values into the `[u]int32_t' struct members
without limiting them to at least the type size the value is stored in,
some report wrong commands in error messages,
On Wed, Jul 29, 2020 at 05:42:16PM +0200, Florian Obser wrote:
> > First you mention fallback to DHCP-learned resolvers. Those you should
> > probably not trust indeed, but it looks like unwind(8) attempts to use
> > them to perform its own validation. So the value of the AD flag in
> >
On Wed, Jul 29 2020, Florian Obser wrote:
> On Wed, Jul 29, 2020 at 03:51:55PM +0200, Jeremie Courreges-Anglas wrote:
>> So I did a few tests and read some unwind(8) code, and it *appears* safe
>> to use unwind(8) along with "options trust-ad".
>
> Yes.
>
>>
>> First you mention fallback to
On Wed, Jul 29, 2020 at 03:51:55PM +0200, Jeremie Courreges-Anglas wrote:
> So I did a few tests and read some unwind(8) code, and it *appears* safe
> to use unwind(8) along with "options trust-ad".
Yes.
>
> First you mention fallback to DHCP-learned resolvers. Those you should
> probably not
Florian Obser wrote:
> On Wed, Jul 29, 2020 at 03:51:17PM +0200, Sebastian Benoit wrote:
> > If i remember correctly, the fallout was caused by EDNS but i might be
> > wrong. The unbound commit caused a developer some headscratching, because
> > his upstream internet did not work with such
On Wed, Jul 29, 2020 at 09:05:14AM -0600, Theo de Raadt wrote:
> Claudio Jeker wrote:
> > But:
> > $ route -T2 exec id -R
> > 2
> > $ route -T2 exec route -T0 exec id -R
> > route: setrtable: Operation not permitted
> >
> > Only root can change the rdomain if it is currently !=
On Wed, Jul 29, 2020 at 03:51:17PM +0200, Sebastian Benoit wrote:
> If i remember correctly, the fallout was caused by EDNS but i might be
> wrong. The unbound commit caused a developer some headscratching, because
> his upstream internet did not work with such packets, which led to immediate
>
Claudio Jeker wrote:
> On Wed, Jul 29, 2020 at 04:43:18PM +0200, Klemens Nanni wrote:
> > On Wed, Jul 29, 2020 at 05:33:14PM +0300, Kapetanakis Giannis wrote:
> > > Wouldn't this break those who already have
> > > !route -T2
> > >
> > > in their hostname.if files?
> > No,
> >
> > $ route
On 29/07/2020 17:43, Klemens Nanni wrote:
> On Wed, Jul 29, 2020 at 05:33:14PM +0300, Kapetanakis Giannis wrote:
>> Wouldn't this break those who already have
>> !route -T2
>>
>> in their hostname.if files?
> No,
>
> $ route -T1 exec id -R
> 1
> $ route -T0 exec route -T1 exec
On Wed, Jul 29, 2020 at 04:43:18PM +0200, Klemens Nanni wrote:
> On Wed, Jul 29, 2020 at 05:33:14PM +0300, Kapetanakis Giannis wrote:
> > Wouldn't this break those who already have
> > !route -T2
> >
> > in their hostname.if files?
> No,
>
> $ route -T1 exec id -R
> 1
> $
You were already able to execute a !command inside the rdomain, either
by specifying the rdomain (on commands which can do that) or by using
route -T manually.
But now, you can't easily execute commands *outside the rdomain*, and
there are some things folk might want to do.
Also, there is an
On Wed, Jul 29, 2020 at 05:33:14PM +0300, Kapetanakis Giannis wrote:
> Wouldn't this break those who already have
> !route -T2
>
> in their hostname.if files?
No,
$ route -T1 exec id -R
1
$ route -T0 exec route -T1 exec id -R
1
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.29 15:51:55 +0200:
> On Sun, Jul 26 2020, Jeremie Courreges-Anglas wrote:
> > On Sat, Jul 25 2020, Sebastian Benoit wrote:
>
> [...]
>
> >> If you enable trust-ad on a system that moves around, e.g. your laptop, you
> >> will experience
On 29/07/2020 12:54, Matthieu Herrb wrote:
> Hi,
>
> When I'm configuring an interface with a spécific rdomain, I'd assume
> that '!' commands (especially /sbin/route commands) are executed in
> the rdomain for this interface.
>
> I know that parsing this file is complex and somehow fragile but
On Wed, Jul 29, 2020 at 11:37:03AM +, Schreilechner, Dominik wrote:
> Hi,
>
> I noticed, that the description of vgone/vgonel in the manpage does not match
> the code.
> The manpage (https://man.openbsd.org/vgone) states:
> The difference between vgone() and vgonel() is that vgone() locks
On Sun, Jul 26 2020, Jeremie Courreges-Anglas wrote:
> On Sat, Jul 25 2020, Sebastian Benoit wrote:
[...]
>> If you enable trust-ad on a system that moves around, e.g. your laptop, you
>> will experience failures, which is why unwind tests for this and falls back
>> to non-trusting dhcp
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.26 22:52:47 +0200:
> On Sat, Jul 25 2020, Sebastian Benoit wrote:
> > Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2020.07.25 14:01:06 +0200:
> >> On Fri, Jul 17 2020, Jesper Wallin wrote:
> >> > Hi all,
> >> >
> >> > I recently decided to add
On Wed, Jul 29, 2020 at 11:54:17AM +0200, Matthieu Herrb wrote:
> When I'm configuring an interface with a spécific rdomain, I'd assume
> that '!' commands (especially /sbin/route commands) are executed in
> the rdomain for this interface.
I see where you're coming from, but the diff seems flawed.
On Wed, Jul 29, 2020 at 02:46:06PM +0200, Jeremie Courreges-Anglas wrote:
> On Mon, Jul 27 2020, Jesper Wallin wrote:
>
> [...]
>
> > I still think the RES_USE_AD option might be a useful though, for when
> > you want to decide on an application-level whether to trust AD or not?
>
>
On Mon, Jul 27 2020, Jesper Wallin wrote:
[...]
> I still think the RES_USE_AD option might be a useful though, for when
> you want to decide on an application-level whether to trust AD or not?
RES_TRUSTAD can also be used for this, but as the proposed documentation
points out it would be
This is to reduce duplicate code and pave the way for a single
bridge_status() that covers all bridge like interfaces: bridge(4),
switch(4) and tpmr(4).
Feedback? OK?
Index: brconfig.c
===
RCS file:
Hi,
I noticed, that the description of vgone/vgonel in the manpage does not match
the code.
The manpage (https://man.openbsd.org/vgone) states:
The difference between vgone() and vgonel() is that vgone() locks the vnode
interlock and then calls vgonel() while vgonel() expects the interlock to
On Wed, Jul 29, 2020 at 10:06:14AM +0200, Mark Kettenis wrote:
> > Date: Wed, 29 Jul 2020 10:38:55 +1000
> > From: Jonathan Matthew
> >
> > On Tue, Jul 28, 2020 at 07:30:36PM +0200, Mark Kettenis wrote:
> > > > Date: Tue, 28 Jul 2020 21:42:46 +1000
> > > > From: Jonathan Matthew
> > > >
> > >
Hi,
When I'm configuring an interface with a spécific rdomain, I'd assume
that '!' commands (especially /sbin/route commands) are executed in
the rdomain for this interface.
I know that parsing this file is complex and somehow fragile but still
I tried to write a patch.
What do you think ?
Of
> Date: Wed, 29 Jul 2020 10:38:55 +1000
> From: Jonathan Matthew
>
> On Tue, Jul 28, 2020 at 07:30:36PM +0200, Mark Kettenis wrote:
> > > Date: Tue, 28 Jul 2020 21:42:46 +1000
> > > From: Jonathan Matthew
> > >
> > > On Tue, Jul 28, 2020 at 11:12:21AM +0200, Mark Kettenis wrote:
> > > > >
34 matches
Mail list logo
