Previously, a nonexistent interface would be converted to the invalid
interface index 0. This is now rejected by the kernel, but route(8) can
give a better error message by failing fast.
---
sbin/route/route.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git sbin/route/route.c
Both RTA_IFP and RTA_GATEWAY can use a sockaddr_dl struct. If either
specifies an explicit interface index, it must be honored. If both do,
and they are not equal, that is an error. It is also an error if RTA_IFP
specifies an index of 0.
Furthermore, if RTA_GATEWAY specifies a sockaddr_dl, it
If an RTM_ADD command on a routing socket includes an RTA_IFA sockaddr,
and that sockaddr is an exact match for one of the interfaces in the
relevant routing domain, any RTA_IFP sockaddr in the same message is
ignored. If there are multiple interfaces with the same IP address,
this can cause
On 2020-09-15 04:25, Florian Obser wrote:
> On Mon, Sep 14, 2020 at 04:26:20PM -0500, Rafael Possamai wrote:
>>> please dont drop the all buffer , or keep it with -vv ?
>>> example : warnx("%s: bad JSON object:%s", p->newaccount, c->buf.buf);
>>>
>>> i don't want to ktrace it to see why the new
On 2020-09-13 12:40, Claudio Jeker wrote:
> On Sun, Sep 13, 2020 at 11:28:11AM -0400, Demi M. Obenour wrote:
>> Resending without quoted-printable encoding, in case that helps.
>> ---
>> If an RTM_ADD command on a routing socket includes an RTA_IFA sockaddr,
>> and that
Resending without quoted-printable encoding, in case that helps.
---
If an RTM_ADD command on a routing socket includes an RTA_IFA sockaddr,
and that sockaddr is an exact match for one of the interfaces in the
relevant routing domain, any RTA_IFP sockaddr in the same message is
ignored. If there
If an RTM_ADD command on a routing socket includes an RTA_IFA sockaddr,
and that sockaddr is an exact match for one of the interfaces in the
relevant routing domain, any RTA_IFP sockaddr in the same message is
ignored. If there are multiple interfaces with the same IP address,
this can cause
On 2020-07-29 21:47, Andrew Hewus Fresh wrote:
> I am helping some folks with some OpenBSD stuff, including at some
> point being more proactive about updating, but they currently have an
> OpenBSD 5.9 machine that has been routing traffic happily for a while.
> Unfortunately, they can't currently
further.
Sincerely,
Demi M. Obenour
Index: usr.bin/ftp/main.c
===
RCS file: /cvs/src/usr.bin/ftp/main.c,v
retrieving revision 1.131
diff -u -p -u -p -r1.131 main.c
--- usr.bin/ftp/main.c 11 Feb 2020 18:41:39 - 1.131
+++ usr.bin
On 2020-05-03 12:18, Theo de Raadt wrote:
> Thanks Stuart.
>
>
> The lesson is clear. No pledge/unveil work unless you test *ALL PROGRAM
> BEHAVIOURS*. Doing less than the full testing is ... uhm, egotistical.
Sorry about that. Hopefully my next version will fix it.
> And it is completely
On 2020-05-03 12:13, Stuart Henderson wrote:
> On 2020/05/02 20:19, Demi M. Obenour wrote:
>> The following patch tightens the pledges for ftp(1).
>>
>> This guarantees that ftp(1) cannot spawn child processes when operating
>> in batch mode, which is a significant s
The following patch tightens the pledges for ftp(1).
This guarantees that ftp(1) cannot spawn child processes when operating
in batch mode, which is a significant security win.
Index: usr.bin/ftp/main.c
===
RCS file:
On 2020-05-02 17:04, Hiltjo Posthuma wrote:
> On Sat, May 02, 2020 at 04:48:38PM -0400, Qubes privileged user wrote:
>> The following patch tightens the pledges for ftp(1).
>>
>> This provides some additional guarantees, including that ftp(1) cannot
>> spawn child processes. This is a significant
I have found myself using OpenSSH for its forwarding abilities,
without actually using the remote shell feature. In these cases, the
connection itself is over Xen shared memory, so I have no need for any
of the cryptography.
While allowing unencrypted SSH connections is obviously a bad
idea, I
14 matches
Mail list logo
