this removes all the kernel code. if we want it back we can look in the
attic.
ok? or is this too much too fast?
Index: conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.675
diff -u -p -r1.675 files
---
i disabled mobileip(4) with the idea that if noone complained, i'd
remove it. noone has complained, so im going to remove it.
starting at the edge, this removes the mobileip stuff from sysctl(8).
ok?
Index: sysctl.c
===
RCS file:
Hello,
When reviewing flex's config.h I think we could enable
HAVE_DECL___FUNC__. This allows the flex_die() macro
to include __func__ in its output. For example:
flex: fatal internal error at main.c:146 (flex_main): spooky error
Does this look OK?
- Michael
Index: config.h
On Mon, Oct 28, 2019 at 09:25:22PM GMT, Raf Czlonka wrote:
> On Mon, Oct 28, 2019 at 01:32:05PM GMT, Andre Stoebe wrote:
> >
> > - df -ikl
> > + df ${DFARGS-"-ikl"}
> >
>
> Hi Andre,
>
> Instead of ${DFARGS-"-ikl"}, you should most likely be using:
>
> ${DFARGS:-"-ikl"}
>
> Cheers,
On Mon, Oct 28, 2019 at 01:32:05PM GMT, Andre Stoebe wrote:
>
> - df -ikl
> + df ${DFARGS-"-ikl"}
>
Hi Andre,
Instead of ${DFARGS-"-ikl"}, you should most likely be using:
${DFARGS:-"-ikl"}
Cheers,
Raf
This diff adds a link to
https://www.openbsd.org/errata66.html
on
https://www.openbsd.org/security.html
I noticed this when reading the 6.6 announcement email.
Index: security.html
===
RCS file: /cvs/www/security.html,v
retrieving
On 2019/10/28 10:39, Theo de Raadt wrote:
> I also think this is getting out of hand.
>
> This script is supposed to be a simplistic subsystem providing the
> minimum. Intentionally.. Adding this option today, another option
> tomorrow, eventually this turns into a ${} scribble-fest. And
To be absolutely clear: this only changes the defaults and only means
that people using snmp(1) against appliances with crappy digest/cipher
need to specify the crappy parameters via -a and -x. They will continue
to keep working.
In a similar fashion people using clients that don't support AES or
> Date: Mon, 28 Oct 2019 19:28:29 +0100
> From: Stefan Sperling
>
> Newer iwm(4) firmware versions will require paging to host DRAM.
> This diff implements support for this. It was written by Imre Vadasz in 2017.
>
> I would like to get review by people with experience in the kernel memory
>
Newer iwm(4) firmware versions will require paging to host DRAM.
This diff implements support for this. It was written by Imre Vadasz in 2017.
I would like to get review by people with experience in the kernel memory
subsystem and DMA, to check that this diff isn't doing something stupid.
As it
I also think this is getting out of hand.
This script is supposed to be a simplistic subsystem providing the
minimum. Intentionally.. Adding this option today, another option
tomorrow, eventually this turns into a ${} scribble-fest. And somewhere
around the time the script doubles in size,
Hi Nick,
Nick Holland wrote on Sun, Oct 27, 2019 at 02:27:46PM -0400:
> In version 1.78 of /etc/daily, the -i flag was added to the df output.
> Apparently, some people run out of inodes.
>
> I only seem to run out of disk space, and too often, my eye skims
> the daily report from a machine,
On Mon, 28 Oct 2019 15:41:34 +0100 Patrick Wildt wrote:
> On Mon, Oct 28, 2019 at 03:14:22PM +1100, Damien Miller wrote:
> > On Mon, 28 Oct 2019, Damien Miller wrote:
> >
> > > BTW, the token still becomes unresponsive after the first transaction,
> > > but looking at a sniff (using an
On Mon, Oct 28, 2019 at 03:14:22PM +1100, Damien Miller wrote:
> On Mon, 28 Oct 2019, Damien Miller wrote:
>
> > BTW, the token still becomes unresponsive after the first transaction,
> > but looking at a sniff (using an OpenViszla), it seems we're getting the
> > DATA0/DATA1 flipping incorrect
On 2019/10/28 08:02, Martijn van Duren wrote:
> At the moment we are neither consistent nor really secure in what we
> offer by default for snmp. For snmp(1) we default to MD-5 and DES and
> for snmpd(8) we default to SHA-1 and DES. Both are horrendously out of
> date.
>
> Diff below updates
Hello Nick,
> Those of us that don't worry about running out of inodes, we can
> set DF_FLAGS in /etc/daily.local to be whatever we want, in my
> case, I like "-hl" (currently, it's "-ikl")
I really like the idea, because getting human-readable numbers in the
report without replicating
At the moment we are neither consistent nor really secure in what we
offer by default for snmp. For snmp(1) we default to MD-5 and DES and
for snmpd(8) we default to SHA-1 and DES. Both are horrendously out of
date.
Diff below updates both tools to use SHA-256 and AES by default.
SHA-256 should
tl;dr: Can anyone with Cisco equipment with AES-192 and AES-256 support
for snmp test the diff below as much -a variants as possible and report
back to me?
According to the archives there was once an initiative for AES-192 and
AES-256[0]. Unfortunately this was removed after draft 4.
Since
When originally writing snmp(1) I wanted to stay as close to netsnmp as
possible to make sure I didn't introduce anything I would regret.
Now that 6.6 is out the door and I'm feeling more comfortable with the
tool I want to start being a little more lenient. Here's a first step by
allowing the -C
19 matches
Mail list logo
