Hi guys! I've been reading about HTTP Desync Attacks lately so I took a
look to relayd's source code to check if it's likely to be exploited.
I wasn't able to do a POC (I don't have a OBSD installation at the moment)
but I think it is.
I'm going to install a OpenBSD as soon as I can in order to
Hi tech,
Use `if (retval == -1)' instead of 'if (retval < 0)' when check the
return value of system call.
How about it?
RCS file: /cvs/src/lib/libedit/readline.c,v
retrieving revision 1.28
diff -u -p -u -r1.28 readline.c
--- readline.c 28 Jun 2019 13:32:42 - 1.28
+++ readline.c 14
With this patch, pms recognizes all elantech-v4 touchpads (see
https://marc.info/?l=openbsd-tech=156554256223597=2 ). Some
models may have external hardware buttons, they are identified by
checking a flag in the firmware version number.
OK?
Index: dev/pckbc/pms.c
Theo Buehler wrote:
> On Tue, Aug 13, 2019 at 09:59:28PM +0200, Christian Weisgerber wrote:
> > * Remove syspatch files from the installed system and not the ramdisk.
> > * Use extended globs and generally adopt to the style of this script.
> >
> > ok?
>
> I'm ok with your patch. One
On Tue, Aug 13, 2019 at 09:59:28PM +0200, Christian Weisgerber wrote:
> * Remove syspatch files from the installed system and not the ramdisk.
> * Use extended globs and generally adopt to the style of this script.
>
> ok?
I'm ok with your patch. One suggestion:
> if [[ -f
Hi, (cc'ed to bugs@ as well)
On Tue, Aug 13, 2019 at 02:58:05PM +0200, Stefan Sperling wrote:
> On Tue, Aug 13, 2019 at 09:40:22AM -0300, Martin Pieuchot wrote:
> >
> > How does the stack crashes?
>
> Jesper only sent me a screen shot and no public bug report :(
>
I've had a really busy week
* Remove syspatch files from the installed system and not the ramdisk.
* Use extended globs and generally adopt to the style of this script.
ok?
I'm not very happy with the way the clang version is determined.
If we ever were to move to 10.0.0, this would remove the wrong
directory. I
Right now if we receive a malformed reply (apart from potentially
crashing[0]) we return a rather unsightly and uninformative error
message:
$ LD_PRELOAD=/usr/src/lib/libutil/obj/libutil.so.13.1 snmp getnext -v2c
-cpublic 127.0.0.1 ifInDiscards.0
snmp: getnext: Undefined error: 0
This diff
I found two issues related to this diff.
1) I posted a fix[0] for this one.
2) We can skip a NULL-ber on ')' and '}' since we replace it with a
parent ber.
There's only regress tests for ldapd and snmpd, so those are all I
tested.
martijn@
[0]
The traphandler currently relies on some false assumptions.
1) A pdu has 3 leading elements to the varbind list, not 4.
2) The first element of a trap varbind as 2 elements, not 3
3) The varbind list is optional.
The final point also causes "trap handle" in snmpd to print the
trap oid twice if
> Is suspend-resume not working on the lemote anymore?
It works (or used to work) on the Yeeloong, not on the Gdium (different
battery controller chip).
There seems to be an annoying bug in iked NAT traversal which leads to an iked
falsely seeing a NAT when the "local" IP is not explicitly set in the config,
as a result two ikeds will switch from port 500 to 4500 with the first
CREATE_CHILD_SA exchange.
The diff adds a new flag to the message and
Update: Having the use_transport_mode flag attached to the SA is
not the best idea, so now it is given down to the child SA as soon as
possible and then only looked up from there (and cleared in the parent).
A simple setup looks as follows:
For A (/etc/iked.conf):
ikev2 "test" active transport
mps_get{,next}req makes the false assumption that root is empty, but if
o_get fails there might be data in there. The following diff fixes the
issue reported earlier today for the failing mib.
.iso.org.dod.internet.mgmt.mib_2.interfaces.ifTable.ifEntry.ifInDiscards
Changes the snmp(1) output
On 13/08/19(Tue) 14:58, Stefan Sperling wrote:
> On Tue, Aug 13, 2019 at 09:40:22AM -0300, Martin Pieuchot wrote:
> > On 13/08/19(Tue) 13:52, Stefan Sperling wrote:
> > > This should hopefully prevent a crash reported to me by Jesper Wallin,
> > > where net80211 crashes when it attempts to decrypt
On Tue, Aug 13, 2019 at 03:27:17PM +0200, Martijn van Duren wrote:
> I managed to make snmp(1) crash, when I sent a malformed snmp packet.
> Specifically when I have a varbind with an oid, but no value.
>
> I test for this case via ber_scanf_elements("{oS}", which presumably
> would crap out if
I managed to make snmp(1) crash, when I sent a malformed snmp packet.
Specifically when I have a varbind with an oid, but no value.
I test for this case via ber_scanf_elements("{oS}", which presumably
would crap out if my skip doesn't have an element. Unfortunately reality
is that the be_next is
On Tue, Aug 13, 2019 at 09:40:22AM -0300, Martin Pieuchot wrote:
> On 13/08/19(Tue) 13:52, Stefan Sperling wrote:
> > This should hopefully prevent a crash reported to me by Jesper Wallin,
> > where net80211 crashes when it attempts to decrypt a CCMP-encrypted
> > frame which iwm passed up without
On 13/08/19(Tue) 13:52, Stefan Sperling wrote:
> This should hopefully prevent a crash reported to me by Jesper Wallin,
> where net80211 crashes when it attempts to decrypt a CCMP-encrypted
> frame which iwm passed up without decrypting it first.
How does the stack crashes? Shouldn't we drop
This should hopefully prevent a crash reported to me by Jesper Wallin,
where net80211 crashes when it attempts to decrypt a CCMP-encrypted
frame which iwm passed up without decrypting it first.
By code inspection I have determined that this problem could happen
in case a CCMP frame is received
When finding an peer id for a new templated host getpeerbyip() uses a
rather dumb lookup loop which is super inefficent. Instead it is much
better to just use getpeerbyid() and check its return.
Also while there don't use the global conf for the peer list but instead
use the argument c in all RB
When adding the filterstate to rde_filter I also passed a struct prefix
pointer to rde_filter instead of passing the 4 values. This resulted in
some ugly hacks because in some cases there was no prefix handy to pass
in and while working on RIB pipelines I noticed that this is hurting me
again. So
On Fri, Aug 09, 2019 at 05:42:30PM +0200, Reyk Floeter wrote:
> Hi,
>
> I agree that __func__ should be removed from anything except log_debug()
> messages.
>
> I think you should prepend the term sa or spi to explain what the hex numbers
> mean.
>
> otherwise OK reyk
Thanks! Added with
23 matches
Mail list logo
