Hello,
On Fri, Dec 16, 2022 at 01:53:42PM +1000, David Gwynne wrote:
> both struct pf_state_key and pf_state_item are kernel private data
> structures, and do not need to be visible to userland.
>
> i would like to move them to pfvar_priv.h to make it more obvious that
> they are and should
That sounds good to me. Your testing process sounds safe.
David Gwynne wrote:
> both struct pf_state_key and pf_state_item are kernel private data
> structures, and do not need to be visible to userland.
>
> i would like to move them to pfvar_priv.h to make it more obvious that
> they are
both struct pf_state_key and pf_state_item are kernel private data
structures, and do not need to be visible to userland.
i would like to move them to pfvar_priv.h to make it more obvious that
they are and should remain kernel private data structures, which in turn
will make it less scary to
On Thu, Dec 15, 2022 at 07:06:34PM -0800, Andrew Hewus Fresh wrote:
> On Thu, Dec 15, 2022 at 06:31:40AM +, Klemens Nanni wrote:
> > More context for this diff:
> > 138 if [[ $_if == ??:??:??:??:??:?? ]]; then
> > 139 if ! _line=$( ifconfig -M $_if ); then
> > 140 print
On Thu, Dec 15, 2022 at 06:31:40AM +, Klemens Nanni wrote:
> On Sun, Dec 11, 2022 at 01:05:13PM -0800, Andrew Hewus Fresh wrote:
> > This would be the diff to swap priority of name/lladdr as some folks
> > wanted to see. I still don't recommend having both as you can still
> > have surprising
On riscv64 LTO fails for some ports with this error:
ld: error: linking module flags 'SmallDataLimit': IDs have conflicting values
in '.o' and 'ld-temp.o'
This is because some objects files are built PIC and others with PIE or
no PIC at all, and the final link which creates ld-temp.o fails
I would appreciate some testing by people who actually use acme-client
with multiple SANs. The diff works for me and should not change any
important behavior.
When I learned about CVE-2021-44532 in node, I was horrified, but oh,
well, it was node. Little did I suspect that acme-client did
On Thu, 15 Dec 2022 18:16:11 +0100, Theo Buehler wrote:
> This should probably been part of my last diff, but I noticed it only
> on commit... acme-client contains the same mistake as rpki-client had:
> all times in certificates are expressed in GMT, so using the TZ dependent
> output of mktime()
On Thu, Dec 15, 2022 at 06:16:11PM +0100, Theo Buehler wrote:
> This should probably been part of my last diff, but I noticed it only
> on commit... acme-client contains the same mistake as rpki-client had:
> all times in certificates are expressed in GMT, so using the TZ dependent
> output of
Stuart Henderson wrote:
> On 2022/12/15 09:47, Theo de Raadt wrote:
> > Other than that, I still think MAC is the identifier we should give
> > priority to.
> > So I would like for this to be flipped, and then I think we can consider
> > this
> > work done.
>
> Do we want to give users a clue
This should probably been part of my last diff, but I noticed it only
on commit... acme-client contains the same mistake as rpki-client had:
all times in certificates are expressed in GMT, so using the TZ dependent
output of mktime() and mixing it with the output of time(NULL) is wrong.
I don't
On 2022/12/15 09:47, Theo de Raadt wrote:
> Other than that, I still think MAC is the identifier we should give priority
> to.
> So I would like for this to be flipped, and then I think we can consider this
> work done.
Do we want to give users a clue that this works (for hostname.vlanX
or
Stuart Henderson wrote:
> On 2022/12/15 05:19, Klemens Nanni wrote:
> > Yes, I agree with Theo here that lladdr is more specific and should win
> > present.
>
> That depends on the hardware ;)
So you are talking about hardware without an encoded MAC, where the kernel
supplies a random MAC to
Errata patches for acme-client(8) 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
iwm(4) can panic if the firmware image is missing or corrupt:
starting network
iwm1: firmware parse error 22, section type 0
iwm1: failed to load init firmware
ifconfig: SIOCSIFXFLAGS: Invalid argument
panic: kernel diagnostic assertion "sc->task_refs.r_refs == 0" failed: file "/u
Methods to convert ASN1_TIMEs to something else have long been available
in both LibreSSL and OpenSSL. The internals in libcrypto are safer, more
correct and better vetted than this (the actual conversion happens in
asn1_time_parse_cbs() in lib/libcrypto/asn1/a_time_tm.c).
Also, use
On 2022/12/15 05:19, Klemens Nanni wrote:
> Yes, I agree with Theo here that lladdr is more specific and should win
> present.
That depends on the hardware ;)
ping...
On 2022/11/22 11:53:35 +0100, Omar Polo wrote:
> anyone?
>
> On 2022/11/09 09:00:03 +0100, Omar Polo wrote:
> > bump
> >
> > On 2022/10/25 14:30:51 +0200, Omar Polo wrote:
> > > On 2022/10/13 12:25:00 +0200, Omar Polo wrote:
> > > > shell-command (M-!) and shell-command-on-region
18 matches
Mail list logo
