On Wed, Jan 18, 2023 at 10:50:25AM +0300, Vitaliy Makkoveev wrote:
> On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote:
> > Hi,
> >
> > we have several drivers which have to parse the content of mbufs. This
> > diff suggest a central parsing function for this. Thus, we can reduce
> >
On Tue, Jan 17, 2023 at 11:09:17PM +0100, Jan Klemkow wrote:
> Hi,
>
> we have several drivers which have to parse the content of mbufs. This
> diff suggest a central parsing function for this. Thus, we can reduce
> redundant code.
>
> I just start with ix(4) and ixl(4) because it was easy to
Until a few minutes ago, the new validator checked policies by default.
The legacy validator and OpenSSL don't do so. Let's explicitly enable
policy checks for all these validators (X509_V_FLAG_EXPLICIT_POLICY is
not enough - our X509_VERIFY_PARAM_set_flags() manual even calls out
that trap).
On Mon, Jan 09, 2023 at 01:52:03PM +, Nicholas Marriott wrote:
>
> From a quick look it will happily fall back to carriage return and space
> if the capabilities it would prefer (el and hpa/RI) are not present, so
> probably anything would do.
>
> Or you could check if the terminfo entry
On Tue, Jan 17, 2023 at 11:02:07PM +0100, Theo Buehler wrote:
> > at least this tool works for me:
>
> Surely you have kern.allowkmem=1 set.
Yes, I do.
Hi,
we have several drivers which have to parse the content of mbufs. This
diff suggest a central parsing function for this. Thus, we can reduce
redundant code.
I just start with ix(4) and ixl(4) because it was easy to test for me.
But, this could also improve em(4), igc(4), ale(4) and oce(4).
> at least this tool works for me:
Surely you have kern.allowkmem=1 set.
On Tue, Jan 17, 2023 at 04:23:48PM -0500, Bryan Steele wrote:
> On Tue, Jan 17, 2023 at 09:37:24PM +0100, Jan Klemkow wrote:
> > Hi,
> >
> > This diff adjust the manpage of mem(4) to be more accurate. You can
> > open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
> >
> >
On Tue, Jan 17, 2023 at 09:37:24PM +0100, Jan Klemkow wrote:
> Hi,
>
> This diff adjust the manpage of mem(4) to be more accurate. You can
> open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
>
> kern/spec_vnops.c:
>
> if (ap->a_cred != FSCRED && (ap->a_mode & FWRITE)) {
17.01.2023 20:37, Jan Klemkow пишет:
> Hi,
>
> This diff adjust the manpage of mem(4) to be more accurate. You can
> open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
securelevel(7) still says
1 Secure mode
...
- /dev/mem and /dev/kmem cannot be
Hi @tech,
The bottom of this email contains a simplified strtonum implementation.
It should behave exactly the same way as the existing strtonum, but it
doesn't call strtoll, which means we can drop some unnecessary
complexity:
- No base conversion
- No need to save and restore errno (which is a
Hi,
This diff adjust the manpage of mem(4) to be more accurate. You can
open(2) mem(4) in securelevel 1 in readonly mode, but not writable.
kern/spec_vnops.c:
if (ap->a_cred != FSCRED && (ap->a_mode & FWRITE)) {
...
/*
* When running in
On Tue, Jan 17, 2023 at 02:14:20PM +0100, Sebastien Marie wrote:
> On Mon, Jan 16, 2023 at 12:00:30PM -0700, Theo de Raadt wrote:
> > For this xonly work, we are having to one-by-one find .S files that
> > are putting data tables into the .text segment
> >
> > I am hoping to find someone who can
Errata patches for X11 libXpm library have been released for OpenBSD
7.1 and 7.2.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata71.html
On Tue, Jan 17, 2023 at 04:48:06PM +0100, Theo Buehler wrote:
> On Tue, Jan 17, 2023 at 03:11:26PM +0100, Claudio Jeker wrote:
> > This diff adds all the plumbing to push the ASPA table from the RTR
> > process into the RDE. It is still missing important bits but the table
> > itself should load
On Tue, Jan 17, 2023 at 03:11:26PM +0100, Claudio Jeker wrote:
> This diff adds all the plumbing to push the ASPA table from the RTR
> process into the RDE. It is still missing important bits but the table
> itself should load and `bgpctl show sets` will show what was loaded.
>
> After that the
This diff adds all the plumbing to push the ASPA table from the RTR
process into the RDE. It is still missing important bits but the table
itself should load and `bgpctl show sets` will show what was loaded.
After that the reload logic needs to be added and the filters need to
be extended to
On Mon, Jan 16, 2023 at 12:00:30PM -0700, Theo de Raadt wrote:
> For this xonly work, we are having to one-by-one find .S files that
> are putting data tables into the .text segment
>
> I am hoping to find someone who can do c++ well enough, and maybe
> has some familiarity with the clang code,
yep, ok by me.
jmc
On 17 January 2023 12:03:58 GMT, Klemens Nanni wrote:
>17.01.2023 06:44, Jason McIntyre пишет:
>> seems correct. posix spec shows "..." too.
>
>Right, I didn't dig that up yet.
>
>In that case: OK?
>
17.01.2023 06:44, Jason McIntyre пишет:
> seems correct. posix spec shows "..." too.
Right, I didn't dig that up yet.
In that case: OK?
Since a few days rpki-client will not only output a roa-set but also
include an aspa-set in the output file. I don't think we need to
overcomplicate this and explain that the output has no duplicates and that
it is a roa-set and aspa-set.
Comments
--
:wq Claudio
Index: rpki-client.8
On Tue, Jan 17, 2023 at 06:47:29AM +, Jason McIntyre wrote:
> On Tue, Jan 17, 2023 at 04:12:10PM +1100, Jonathan Gray wrote:
> > AMD Elan SC520 (found on soekris net45xx) has a 486 class processor
> > We require at least a 586/pentium class processor
> >
>
> if you do, there's a little
22 matches
Mail list logo
