On Mon, Aug 09, 2021 at 07:20:31AM -0600, Theo de Raadt wrote:
> Ingo Schwarze wrote:
>
> > as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> > Fixing that without longjmp(3) requires making editline(3) better
> > behaved.
>
> If a library interface encourages use
Once initially defined engineid should be static, a lot of SNMP polling
applications use engineid as device identifier.
Consistency and uniqueness are both important. Some polling system will not
allow you to add another snmp device
If engineid is a duplicate.
Network devices usually derive
On Mon, 2021-08-09 at 21:58 +0100, Stuart Henderson wrote:
> On 2021/08/09 22:35, Martijn van Duren wrote:
> > Moving to tech@
> >
> > On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> > > On 2021/08/09 12:14, Martijn van Duren wrote:
> > > > CVSROOT:/cvs
> > > > Module name:
On 2021/08/09 22:35, Martijn van Duren wrote:
> Moving to tech@
>
> On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> > On 2021/08/09 12:14, Martijn van Duren wrote:
> > > CVSROOT:/cvs
> > > Module name:src
> > > Changes by: mart...@cvs.openbsd.org2021/08/09
Moving to tech@
On Mon, 2021-08-09 at 20:56 +0100, Stuart Henderson wrote:
> On 2021/08/09 12:14, Martijn van Duren wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: mart...@cvs.openbsd.org2021/08/09 12:14:53
> >
> > Modified files:
> > usr.sbin/snmpd :
On 2021/08/09 20:55, Martijn van Duren wrote:
> Updated diff after my engineid commit.
ok
> Index: snmpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
> retrieving revision 1.53
> diff -u -p -r1.53 snmpd.conf.5
>
On Tue, 2021-07-27 at 21:28 +0200, Martijn van Duren wrote:
> This diff allows sending traps in SNMPv3 messages.
> It defaults to the global seclevel, but it can be specified on a per
> rule basis.
>
> Diff requires both previous setting engineid and ober_dup diff.
>
> Tested with netsnmp's
Pardon my impatience -- I am a newbie and I don't really know what
should happen next (if anything?). I have skipped any introduction from
my original email, imitating the communication style in this list --
straight to the point and because it was already long.
Although this is my first patch to
On Mon, 2021-08-09 at 11:57 +0200, Martijn van Duren wrote:
> On Sun, 2021-08-08 at 14:44 +0100, Stuart Henderson wrote:
> > > This is probably is a bad example.
> > > Reading it like this: you're correct that we listen on all interfaces
> > > by default, but that's not listed in snmpd.conf(5). So
On 2021-08-09 09:56 -06, "Theo de Raadt" wrote:
> Using the word "security", you've got to be kidding.
>
> If a dhcp server on a L2 segment can be "rogue" about one thing, it can
> most certainly lie about any other answer, or act out in many other
> ways.
>
> The only way to avoid "rogue" DHCP
Using the word "security", you've got to be kidding.
If a dhcp server on a L2 segment can be "rogue" about one thing, it can
most certainly lie about any other answer, or act out in many other
ways.
The only way to avoid "rogue" DHCP servers on a segment is to not ask
DHCP questions on that
The Linux dhclient supports it and it's actually a nice to have
feature as it can increase the security by keeping out the rogue DHCP
servers from an entire LAN range. But probably you can achieve similar
functionality with the interface restriction.
On Mon, Aug 9, 2021 at 3:33 PM Stuart
On Mon, 2021-08-09 at 15:17 +0200, Ingo Schwarze wrote:
> Hi Martijn,
>
> Martijn van Duren wrote on Mon, Aug 09, 2021 at 02:15:42PM +0200:
>
> > If we're stripping down fixio to a single function, why not
> > inline the whole thing?
>
> I deliberately tried to:
>
> 1. Keep patches that
On 2021/08/09 15:03, Andras Vinter wrote:
> It's probably an overkill for first implementation, but in the future
> I think we should support subnet definitions in CIDR notation (e.x.:
> 192.168.0.0/24) and IP ranges for fine control (e.x.:
> 192.168.0.100-192.168.0.254).
dhclient never needed
Ingo Schwarze wrote:
> > So if we decide which of our interpretations should take precedence
> > it might be a good idea to put it into snaps for a while.
>
> I don't think so in this case. Let's not over-use the feature of
> putting stuff in snaps. I think that should be reserved for stuff
>
Ingo Schwarze wrote:
> as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> Fixing that without longjmp(3) requires making editline(3) better
> behaved.
If a library interface encourages use longjmp(), that library should be
thrown into the dustbin of history. Our src tree
Hi Martijn,
Martijn van Duren wrote on Mon, Aug 09, 2021 at 02:15:42PM +0200:
> If we're stripping down fixio to a single function, why not
> inline the whole thing?
I deliberately tried to:
1. Keep patches that change behaviour as small as possible to make
review as simple as possible
It's probably an overkill for first implementation, but in the future
I think we should support subnet definitions in CIDR notation (e.x.:
192.168.0.0/24) and IP ranges for fine control (e.x.:
192.168.0.100-192.168.0.254).
BRs
/Andras
On Mon, Aug 9, 2021 at 2:35 PM Florian Obser wrote:
>
> On
On 2021-08-08 12:14 -07, patrick keshishian wrote:
> On Sun, Aug 08, 2021 at 12:37:54PM +0200, Florian Obser wrote:
>> This implements ignoring of nameservers and / or routes in leases as
>> well as completely ignoring servers (you cannot block rogue DHCP servers
>> in pf because bpf sees packets
On 2021-08-08 11:52 +01, Jason McIntyre wrote:
> On Sun, Aug 08, 2021 at 12:37:54PM +0200, Florian Obser wrote:
>> This implements ignoring of nameservers and / or routes in leases as
>> well as completely ignoring servers (you cannot block rogue DHCP servers
>> in pf because bpf sees packets
On Mon, Aug 09, 2021 at 01:19:08PM +0200, Ingo Schwarze wrote:
> Hi,
>
> as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> Fixing that without longjmp(3) requires making editline(3) better
> behaved.
>
> Currently, when read(2) from the terminal gets interrupted by a
>
On Mon, 2021-08-09 at 14:15 +0200, Martijn van Duren wrote:
> On Mon, 2021-08-09 at 13:19 +0200, Ingo Schwarze wrote:
> > Hi,
> >
> > as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> > Fixing that without longjmp(3) requires making editline(3) better
> > behaved.
> >
> >
On Mon, 2021-08-09 at 13:19 +0200, Ingo Schwarze wrote:
> Hi,
>
> as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
> Fixing that without longjmp(3) requires making editline(3) better
> behaved.
>
> Currently, when read(2) from the terminal gets interrupted by a
> signal,
Hi,
as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C.
Fixing that without longjmp(3) requires making editline(3) better
behaved.
Currently, when read(2) from the terminal gets interrupted by a
signal, editline(3) ignores the (first) signal and unconditionally
calls read(2) a
On Fri, Aug 06, 2021 at 05:22:18PM +0200, Alexandr Nedvedicky wrote:
> > Although I did not obverve it, there seems to be the same problem
> > for snd_wl1 and rcv_up. For rcv_up I copied the comparison with
> > rcv_nxt from urgent processing to keep future urgent data.
Over the weekend I thought
This diff adds the bits needed to support add-path in MRT dumps.
The problem here is that MRT as a stateless protocol has no chance
to know what kind of encoding (add-path or not) is used for the NLRI in
message dumps. And for table dumps there is a need to add an extra field
to the dumps to show
On Sun, 2021-08-08 at 14:44 +0100, Stuart Henderson wrote:
> > This is probably is a bad example.
> > Reading it like this: you're correct that we listen on all interfaces
> > by default, but that's not listed in snmpd.conf(5). So that should
> > probably be fixed (including mentioning that
Hi Martijn,
Martijn van Duren wrote on Mon, Aug 09, 2021 at 11:04:35AM +0200:
> Btw, would there be any benefit to declare zero as const in this
> context?
I dont think so.
At least according to the ioctl(2) manual page, FIONBIO expects
an int * argument, not a const int *.
Yours,
Ingo
Btw, would there be any benefit to declare zero as const in this
context?
On Sun, 2021-08-08 at 13:42 +0200, Ingo Schwarze wrote:
> Hi,
>
> deraadt@ recently reported to me that the editline(3) library, while
> line editing is active - for example inside el_gets(3) - ignores
> the first SIGINT
On Fri, Aug 06, 2021 at 08:34:18PM +0200, Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.08.04 17:55:45 +0200:
> > On Fri, Jul 30, 2021 at 12:02:12PM +0200, Claudio Jeker wrote:
> > > This diff implements the bit to support the receive side of
> > > RFC7911 -
Hello Ingo,
thanks for looking into this.
On 8/6/21 8:13 PM, Ingo Schwarze wrote:
Hi Gerhard and Bryan,
Gerhard Roth wrote on Mon, Aug 02, 2021 at 10:36:05AM +0200:
Bryan Vyhmeister found a strange behavior in date(1):
# date -f %s -j 1627519989
Thu Jul 29 01:53:09 PDT 2021
31 matches
Mail list logo
