On Thu, Jan 11, 2018 at 08:25:26AM +0100, Matthieu Herrb wrote:
> On Thu, Jan 11, 2018 at 10:29:17AM +1000, David Gwynne wrote:
> > carp interfaces output using ether_output, so it is reasonable to
> > require that they only get configured on top of ethernet interfaces
> > rather than just !IFT_CAR
> On 11 Jan 2018, at 08:25, Matthieu Herrb wrote:
>
>> On Thu, Jan 11, 2018 at 10:29:17AM +1000, David Gwynne wrote:
>> carp interfaces output using ether_output, so it is reasonable to
>> require that they only get configured on top of ethernet interfaces
>> rather than just !IFT_CARP.
>>
> Hi
On Thu, Jan 11, 2018 at 10:29:17AM +1000, David Gwynne wrote:
> carp interfaces output using ether_output, so it is reasonable to
> require that they only get configured on top of ethernet interfaces
> rather than just !IFT_CARP.
>
Hi,
in this context are vlan interfaces also considered as IFT_ETH
Hello,
Revision 1.9 of tree.c (from 1999) added the disabled code and it
is still disabled. Would it be better to remove it?
- Michael
Index: tree.c
===
RCS file: /cvs/src/bin/ksh/tree.c,v
retrieving revision 1.30
diff -u -p -u -r1
Wed, 10 Jan 2018 20:34:44 -0700 "Theo de Raadt"
> > Another question raised by a SHA-3 import is whether this should
> > also be added to LibreSSL and if we want to continue with having
> > duplicate implementations of hash algorithms in libc and libcrypto.
>
> very good question.
>
> Who *cru
On Thu, Jan 11, 2018 at 01:27:56PM +1000, David Gwynne wrote:
> this avoids having to parse the gif packet before sending it to
> bpf. instead, we stash the address family in the mbuf and add it
> after bpf.
>
> however, a gif_encap error will not be propagated back to the sender.
> i dont think t
this silences the warnings when building dhclient.
according to guenther@, the c standard says ternary operators are
subject to type promotion rules, ie, it ends up being at least an
int. this adds explicit casts to the expected type, which makes
printf happier when you tell it that it's a %hu com
> Another question raised by a SHA-3 import is whether this should
> also be added to LibreSSL and if we want to continue with having
> duplicate implementations of hash algorithms in libc and libcrypto.
very good question.
Who *crucially* needs this
OpenBSD is intended to be a small operating s
> I also use the sha512 command on a regular basis, and notice a
> performance improvement (compared to sha256) with amd64 systems.
But is /bin the place to put a performance improving command?
No. That isn't the place for putting strange performance commands.
It is a place for putting *interope
this avoids having to parse the gif packet before sending it to
bpf. instead, we stash the address family in the mbuf and add it
after bpf.
however, a gif_encap error will not be propagated back to the sender.
i dont think this is a huge loss as the ip packet is usually
encapsulated itself after i
im sending this out more as a backup than a serious diff.
this tweaks bpf so it can be used by subsystems, not just interfaces.
this is done by making bpf store and use names (eg, "pf" and "em0")
instead of just interfaces. interfaces get some special handling
so you can't bpfwrite or enable ifpro
while we were working on making the various pseudo interfaces you
stack on top of ethernet mpsafe, we split their input processing
off so they could be attacked one by one. they're all mpsafe now,
so this separation is not strictly necessary anymore.
this moves carp and vlan input back into ether_
carp interfaces output using ether_output, so it is reasonable to
require that they only get configured on top of ethernet interfaces
rather than just !IFT_CARP.
there's some more simplification that can occur after this is done.
ok?
Index: ip_carp.c
=
I also use the sha512 command on a regular basis, and notice a
performance improvement (compared to sha256) with amd64 systems.
On Wed, 10 Jan 2018 17:10:40 + (GMT)
Tom Cosgrove wrote:
> >>> "Todd C. Miller" 10-Jan-18 16:28 >>>
> >
> > On Wed, 10 Jan 2018 15:59:30 +0100, Jeremie Courreges-
On Wed, Sep 13, 2017 at 05:51:27AM +0300, Artturi Alm wrote:
> Hi,
>
> even after having recently updated the phone to a newer version of android,
> i'm still spammed by urndis w/msg on subject.
>
> doesn't really matter to me what you do to silence it, but something like
> below does work for me
On 2018-01-09, Daniel Loebenberger wrote:
> enclosed you find a patch to add basic SHA3-/Keccak support to OpenBSD.
What do you want to use it for?
I've had something like this on my to-do list for some time and
eventually dropped it because I couldn't think of a compelling use
case.
"Maybe Sk
On Wed, Jan 10, 2018 at 02:00:57PM +, Stuart Henderson wrote:
> Currently we require either "kernel" or "disk", but there may be
> some viable use cases where just a CDROM image is given. This adjusts
> the check to avoid bailing in that case.
>
> OK?
>
sure
> Index: vmd.c
> ===
>>> "Todd C. Miller" 10-Jan-18 16:28 >>>
>
> On Wed, 10 Jan 2018 15:59:30 +0100, Jeremie Courreges-Anglas wrote:
>
> > Do we really want these? For SHA-2, sha256 and sha512 are enough IMHO.
>
> Does anyone actually use the sha512 command? I'd be fine with
> retiring the sha512 link and adding a s
On Wed, 10 Jan 2018 15:59:30 +0100, Jeremie Courreges-Anglas wrote:
> Do we really want these? For SHA-2, sha256 and sha512 are enough IMHO.
Does anyone actually use the sha512 command? I'd be fine with
retiring the sha512 link and adding a sha3-256 one.
- todd
> > LINKS= ${BINDIR}/md5 ${BINDIR}/sha1 \
> > + ${BINDIR}/md5 ${BINDIR}/sha224 \
> > ${BINDIR}/md5 ${BINDIR}/sha256 \
> > + ${BINDIR}/md5 ${BINDIR}/sha384 \
>
> Do we really want these? For SHA-2, sha256 and sha512 are enough IMHO.
>
> > ${BINDIR}/md5 ${BINDIR}/sha512 \
> > +
Hi,
On Wed, Jan 10 2018, Daniel Loebenberger wrote:
> Hi Todd,
>
> thank you for your comments!
>
> We have included all the necessary changes in the patch attached.
One thing caught my eye:
> Best regards,
> Daniel, Stefan and Alexander
>
> Index: bin/md5/Makefile
> ==
I don't think you compiled a ramdisk.
The ramdisk users distrib/special/md5 to build a binary with
fewer included components, otherwise it won't fit on the media.
At least this isn't right:
#endif /* !defined(SHA2_ONLY) */
SHA2_CTX sha2;
+ SHA3_CTX sha3;
You can inspect the Makef
On Wed, Jan 10, 2018 at 02:00:57PM +, Stuart Henderson wrote:
> Currently we require either "kernel" or "disk", but there may be
> some viable use cases where just a CDROM image is given. This adjusts
> the check to avoid bailing in that case.
>
> OK?
ok ccardenas
>
> Index: vmd.c
> ===
Hi Todd,
thank you for your comments!
We have included all the necessary changes in the patch attached.
Best regards,
Daniel, Stefan and Alexander
Index: bin/md5/Makefile
===
RCS file: /cvs/src/bin/md5/Makefile,v
retrieving revisio
Currently we require either "kernel" or "disk", but there may be
some viable use cases where just a CDROM image is given. This adjusts
the check to avoid bailing in that case.
OK?
Index: vmd.c
===
RCS file: /cvs/src/usr.sbin/vmd/vmd.
currently carp uses a struct carp_if to hold an srp list head, which
is accessed by both if_carp in struct ifnet, and via the if input
handlers list.
this gets rid of some indirection by making if_carp itself the list
head, and makes accessing the list consistent by only using if_carp
to get to it
26 matches
Mail list logo
