> Date: Sat, 12 Sep 2020 09:20:26 +0200
> From: Marcus Glocker
>
> On Fri, 11 Sep 2020 23:18:56 +0200 (CEST)
> Mark Kettenis wrote:
>
> > > Date: Fri, 11 Sep 2020 17:42:23 +0200
> > > From: Marcus Glocker
> > >
> > > On Thu, 10 Sep 2020 23:44:38 +0200
> > > Joerg Jung wrote:
> > >
> > >
On Sat, 12 Sep 2020 09:34:18 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Sat, 12 Sep 2020 09:20:26 +0200
> > From: Marcus Glocker
> >
> > On Fri, 11 Sep 2020 23:18:56 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > > Date: Fri, 11 Sep 2020 17:42:23 +0200
> > > > From: Marcus Glocker
> > >
On Thu, Sep 03, 2020 at 06:13:41PM +0200, Florian Obser wrote:
> The point of this excercise is to work out if it's worthwhile to
> implement RFC 8806 "Running a Root Server Local to a Resolver" in
> unwind(8).
>
> We are trading latency for bandwidth. Lower latency is almost always a
> win for
On 9/6/20 5:06 PM, Martijn van Duren wrote:
> EHLO,
>
> RFC8601 defines the authentication-results header which can be used to
> show the verification-results of DKIM, SPF, DMARC, and others.
>
I think it can be a good addition.
ok giovanni@
Cheers
Giovanni
> I can think of quite a few
These are the last free(buf, 0) occurences in if_pppoe.c and
if_spppsubr.c changing to non-zero sizes.
I've been running with this the last week without any issues.
Feedback? OK?
Index: if_spppsubr.c
===
RCS file:
> Date: Sat, 12 Sep 2020 12:48:48 +0200
> From: Marcus Glocker
> Cc: m...@umaxx.net, j...@jcs.org, tech@openbsd.org
> Content-Type: text/plain; charset=utf-8
>
> On Sat, 12 Sep 2020 10:28:23 +0200 (CEST)
> Mark Kettenis wrote:
>
> > > Date: Sat, 12 Sep 2020 10:00:13 +0200
> > > From: Marcus
> Date: Sat, 12 Sep 2020 10:00:13 +0200
> From: Marcus Glocker
>
> On Sat, 12 Sep 2020 09:34:18 +0200 (CEST)
> Mark Kettenis wrote:
>
> > > Date: Sat, 12 Sep 2020 09:20:26 +0200
> > > From: Marcus Glocker
> > >
> > > On Fri, 11 Sep 2020 23:18:56 +0200 (CEST)
> > > Mark Kettenis wrote:
> > >
On Sat, 12 Sep 2020 10:28:23 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Sat, 12 Sep 2020 10:00:13 +0200
> > From: Marcus Glocker
> >
> > On Sat, 12 Sep 2020 09:34:18 +0200 (CEST)
> > Mark Kettenis wrote:
> >
> > > > Date: Sat, 12 Sep 2020 09:20:26 +0200
> > > > From: Marcus Glocker
> > >
Any takers?
On Sun, 2020-09-06 at 17:06 +0200, Martijn van Duren wrote:
> EHLO,
>
> RFC8601 defines the authentication-results header which can be used to
> show the verification-results of DKIM, SPF, DMARC, and others.
>
> I can think of quite a few filters that could be build around this
>
On Fri, 11 Sep 2020 23:18:56 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Fri, 11 Sep 2020 17:42:23 +0200
> > From: Marcus Glocker
> >
> > On Thu, 10 Sep 2020 23:44:38 +0200
> > Joerg Jung wrote:
> >
> > > Don’t give up so quickly ;)
> > > let’s try to make the driver work on your iMac,
... say if you pull a usb stick.
OK?
diff --git frontend.c frontend.c
index 87141f81e8c..b92cde8226c 100644
--- frontend.c
+++ frontend.c
@@ -913,8 +913,21 @@ handle_route_message(struct rt_msghdr *rtm, struct
sockaddr **rti_info)
{
struct imsg_rdns_proposalrdns_proposal;
On 2020/09/12 19:13, Martin Pieuchot wrote:
> Another approach would be to always use array of AUTHMAXLEN, I'm not sure
> the size justifies two malloc(9).
it used to do that, changed in if_sppsubr.c 1.74
On Sat, Sep 12, 2020 at 05:11:00PM +0200, Klemens Nanni wrote:
> Bit hard to read, what about aligning like this?
>
> + if ((rdns_proposal->src == 0 ||
> + rdns_proposal->src == tmp->src) &&
> + (rdns_proposal->if_index == 0 ||
> +
Seems reasonable. OK
On Sat, Sep 12, 2020 at 05:49:52PM +0200, Klemens Nanni wrote:
> Unconfiguring a member interface from trunk(4) or simply destroying the
> trunk pulls the member down for no reason, both comment and code are
> there since import, but I see no justification for doing so.
>
>
On 12/09/20(Sat) 14:49, Klemens Nanni wrote:
> These are the last free(buf, 0) occurences in if_pppoe.c and
> if_spppsubr.c changing to non-zero sizes.
>
> I've been running with this the last week without any issues.
>
> Feedback? OK?
Maybe store `pwdlen' and `idlen' in "struct sppp" instead
On Sat, 12 Sep 2020 17:05:02 +0200, Christian Weisgerber wrote:
> A make build with the patch below succeeds, but gains some new
> warnings "passing 'const char *' to parameter of type 'char *'
> discards qualifiers".
>
> This is a portability trap. Code written on OpenBSD may not be
> prepared
On Sat, Sep 12, 2020 at 06:58:30PM +0200, Florian Obser wrote:
> On Sat, Sep 12, 2020 at 05:15:08PM +0200, Klemens Nanni wrote:
> > On Sat, Sep 12, 2020 at 05:11:00PM +0200, Klemens Nanni wrote:
> > > Bit hard to read, what about aligning like this?
> > >
> > > + if ((rdns_proposal->src
On Sat, Sep 12, 2020 at 04:36:28PM +0200, Florian Obser wrote:
> ... say if you pull a usb stick.
...or if you play with^W^Wrecreate your trunk0 { em0 athn0 } uplink
without checking unwind.
Without this diff, unwind cannot recover; with it, stuff just works for
me across destroy/create.
OK kn
Unconfiguring a member interface from trunk(4) or simply destroying the
trunk pulls the member down for no reason, both comment and code are
there since import, but I see no justification for doing so.
aggr(4) does not pull its member down upon removal either.
I came across this after
$
On Sat, Sep 12, 2020 at 05:15:08PM +0200, Klemens Nanni wrote:
> On Sat, Sep 12, 2020 at 05:11:00PM +0200, Klemens Nanni wrote:
> > Bit hard to read, what about aligning like this?
> >
> > + if ((rdns_proposal->src == 0 ||
> > +rdns_proposal->src == tmp->src) &&
> > +
On Sat, Sep 12, 2020 at 08:13:43PM +0300, Peter Pentchev wrote:
> On Sat, Sep 12, 2020 at 06:58:30PM +0200, Florian Obser wrote:
> > On Sat, Sep 12, 2020 at 05:15:08PM +0200, Klemens Nanni wrote:
> > > On Sat, Sep 12, 2020 at 05:11:00PM +0200, Klemens Nanni wrote:
> > > > Bit hard to read, what
OK bluhm@
On Sat, Sep 12, 2020 at 05:49:52PM +0200, Klemens Nanni wrote:
> Index: if_trunk.c
> ===
> RCS file: /cvs/src/sys/net/if_trunk.c,v
> retrieving revision 1.149
> diff -u -p -r1.149 if_trunk.c
> --- if_trunk.c28 Jul
Todd C. Miller:
> This is probably the right thing to do but we should fix the warnings
> it generates. In this new world order, passing a const char * to
> basename() or dirname() is unsafe.
FWIW, here's the list:
/usr/src/lib/libkvm/kvm.c:684:16: warning: passing 'const char *' to parameter
Our basename(3) and dirname(3) take a const argument:
char*basename(const char *);
char*dirname(const char *);
POSIX says otherwise...
char *basename(char *path);
char *dirname(char *path);
... and explicitly says the functions may modify the input string.
Our functions were
extern.h uses stuff from openssl/x509.h so put that include in there
and remove all the various other openssl includes in other files that
actually don't need x509 functions.
--
:wq Claudio
Index: as.c
===
RCS file:
ok beck@
On Sat, Sep 12, 2020 at 05:42:39PM +0200, Claudio Jeker wrote:
> extern.h uses stuff from openssl/x509.h so put that include in there
> and remove all the various other openssl includes in other files that
> actually don't need x509 functions.
>
> --
> :wq Claudio
>
> Index: as.c
>
26 matches
Mail list logo
