Sure - I should have spotted that.
Index: ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.100
diff -u -r1.100 ping.c
--- ping.c 24 Mar 2014 11:11:49 - 1.100
+++ ping.c 22 Apr 2014 06:55:03 -0
I don't think we want to do this yet. RAND_bytes and
RAND_pseudo_bytes will not be going away.
On Mon, Apr 21, 2014 at 9:24 PM, Jean-Philippe Ouellet
wrote:
> Here's another pass.
>
> This replaces RAND_{,pseudo_}bytes() calls with equivelant arc4random_buf(3)
> calls for apps/ and ssl/ (crypto/
On Tue, Apr 22, 2014 at 12:45:25AM -0400, Peter Malone wrote:
> Hi,
>
> malloc & memset can be replaced with calloc in ping.c. Please see below for
> patch details:
Better rework this to get rid of fdmasks.
-Otto
>
> Index: ping.c
>
Hi,
malloc & memset can be replaced with calloc in ping.c. Please see below
for patch details:
Index: ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.100
diff -u -p -u -r1.100 ping.c
--- ping.c24 Mar 201
Here's another pass.
This replaces RAND_{,pseudo_}bytes() calls with equivelant arc4random_buf(3)
calls for apps/ and ssl/ (crypto/ still has a bunch).
There was one that was commented out (in ssl/s3_pkt.c) which I wasn't sure
about, so I made the accoring transformation and left it commented out
Hi, Loganaden,
NetBSD really had these? I seem to recall that OpenBSD was the only BSD
variant with these (sensible) knobs.
Thanks,
Fernando
On 04/19/2014 08:04 AM, Loganaden Velvindron wrote:
> Hi All,
>
> I'm taking a short break from playing with pf statistics.
>
> There were 4 sysctls a
The following corrects the termination condition on the write
loop in copyfile.
Index: usr.sbin/vipw/vipw.c
===
RCS file: /cvsroot/OpenBSD/src/usr.sbin/vipw/vipw.c,v
retrieving revision 1.16
diff -u -p -r1.16 vipw.c
--- usr.sbin/vipw/
Hi,
Theo has been working on these patches over the past few days. I noticed
an issue with dso_lib.c and fixed it accordingly.
# cvs diff -u -r1.10 dso_lib.c
Index: dso_lib.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/dso/dso_li
Stuart Henderson writes:
> On 2014/04/21 20:36, Jérémie Courrèges-Anglas wrote:
>> Speaking of py-openssl, here's a diff to remove the EGD methods.
>
> OK, please go ahead.
>
>
>> There's one test that fails, I haven't investigated it.
>>
>> ==
On 21.04.14 19:01, Bob Beck wrote:
> Not quite, because now you avoid the potential double free and instead leak
> ret itself because of how ASN1_STRING_free works.. You need to
> do this slightly differently.
I disagree:
err:
if ((ret != NULL) && ((a == NULL) || (*a != ret)))
On Mon, Apr 21, 2014 at 09:01:52PM +0200, Henning Brauer wrote:
> so while so many here were so busy bikeshedding, wasting everyone's
> time and hindering progress, reyk and I found that several people,
> including me, had flaws in their testing. unfortunately have to go the
> vlan_output route. ro
On Sat, Apr 19, 2014 at 09:30:27PM +0200, Christian Weisgerber wrote:
> This removes a RX offload hack similar to the one just deleted from
> sk(4). These chips can only add 16-bit words starting from some
> offset, and so the driver gives them the likely start of the TCP/UDP
> payload and then tr
so while so many here were so busy bikeshedding, wasting everyone's
time and hindering progress, reyk and I found that several people,
including me, had flaws in their testing. unfortunately have to go the
vlan_output route. root cause "undo undo damage", don't make me explain
please...
new diff.
On 2014/04/21 20:36, Jérémie Courrèges-Anglas wrote:
> Speaking of py-openssl, here's a diff to remove the EGD methods.
OK, please go ahead.
> There's one test that fails, I haven't investigated it.
>
> ==
> FAIL: test_digest (
In list.openbsd.tech, you wrote:
> now it turns out it is trivial to have ether_output prepend the
> ether_vlan_header instead of the regular ethernet header, which makes
> the vlan tagging essentially free in most cases.
>
> you need a very current src tree to test this, relies on the code
> shuf
Not quite, because now you avoid the potential double free and instead leak
ret itself because of how ASN1_STRING_free works.. You need to
do this slightly differently.
On Sun, Apr 20, 2014 at 9:37 PM, Dirk Engling wrote:
> On 21.04.14 04:56, Ted Unangst wrote:
>
>> Also, can you include diffs in
Hi All,
As sftp resume upload has been implemented, here's a man page diff
to describe the feature.
Feedback welcomed.
Index: sftp.1
===
RCS file: /cvs/src/usr.bin/ssh/sftp.1,v
retrieving revision 1.97
diff -u -p -u -p -r1.97 sftp.1
Loganaden Velvindron writes:
> On Mon, Apr 21, 2014 at 04:20:03PM +0200, Fritjof Bornebusch wrote:
>> Hi tech@,
>>
>> here is a small diff, that checks if the ~/.ssh/id_ed25519 private
key has the right permissions.
>
> Th
Loganaden Velvindron writes:
> On Mon, Apr 21, 2014 at 04:20:03PM +0200, Fritjof Bornebusch wrote:
>> Hi tech@,
>>
>> here is a small diff, that checks if the ~/.ssh/id_ed25519 private key has
>> the right permissions.
>
> That's seems good to me.
But then the .ssh/id* entries aren't sorted an
On Mon, Apr 21, 2014 at 04:20:03PM +0200, Fritjof Bornebusch wrote:
> Hi tech@,
>
> here is a small diff, that checks if the ~/.ssh/id_ed25519 private key has
> the right permissions.
That's seems good to me.
>
> Fritjof
>
> Index: security
> =
Hi All,
Trivial fix for sftp.
Index: sftp.c
===
RCS file: /cvs/src/usr.bin/ssh/sftp.c,v
retrieving revision 1.159
diff -u -p -u -p -r1.159 sftp.c
--- sftp.c 21 Apr 2014 14:36:16 - 1.159
+++ sftp.c 21 Apr 2014 14:50
Hi tech@,
here is a small diff, that checks if the ~/.ssh/id_ed25519 private key has the
right permissions.
Fritjof
Index: security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.24
diff -u -p -r1.24 secur
> Henning Brauer bsws.de> writes:
>
> > > And lot of (possible) encapsulation subsystems in the middle: vlan,
> > > vlan-in-vlan, ipsec, you name it.
> >
> > VLAN IS NOT AN ENCAPSULATION.
>
> Well, vlan(4) says:
>
> vlan, svlan - IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device
>
> >
this bikeshedding is annoying as hell and only makes sure we're not
proceeding. makes me almost want to reconsider the open development
process using tech@ instead of a private list.
and I want to proceed here, so I am looking for oks unless someone has
real, non-bikeshedding issues. and certainly
Henning Brauer bsws.de> writes:
> > And lot of (possible) encapsulation subsystems in the middle: vlan,
> > vlan-in-vlan, ipsec, you name it.
>
> VLAN IS NOT AN ENCAPSULATION.
Well, vlan(4) says:
vlan, svlan - IEEE 802.1Q/1AD encapsulation/decapsulation pseudo-device
> > Given a number of sub
* Alexey Suslikov [2014-04-21 13:56]:
> Henning Brauer bsws.de> writes:
>
> > I must admit I am getting tired of all these "good proposals/ideas".
> > don't you think we've gone thru this before?
>
> Look, I haven't called them good or bad.
>
> > what you propose would require a custom vlan_ou
Henning Brauer bsws.de> writes:
> I must admit I am getting tired of all these "good proposals/ideas".
> don't you think we've gone thru this before?
Look, I haven't called them good or bad.
> what you propose would require a custom vlan_output function which
> does nothing but setting the flag
On 21/04/14(Mon) 11:14, Claudio Jeker wrote:
> [...]
>
> Would it make sense to put this into a vlan_encap function so that we can
> reduce the amount of layer violation here?
I think it makes sense.
> #if NVLAN > 0
> if (ifp->if_type == IFT_L2VLAN)
> return vlan_encap(ifp, m
* Alexey Suslikov [2014-04-21 13:13]:
> Henning Brauer bsws.de> writes:
> > congratulations, that is close to unauditable.
> > i put the vlan and the !vlan case next to each other ON PURPOSE. both
> > cases add an ethernet header, one with a few extra fields, one
> > without. Having that next to
Henning Brauer bsws.de> writes:
> congratulations, that is close to unauditable.
>
> i put the vlan and the !vlan case next to each other ON PURPOSE. both
> cases add an ethernet header, one with a few extra fields, one
> without. Having that next to each other makes it f***ing obvious both
> ca
Hi, would you like to add RLIMIT_NPROC setting to nginx.conf?
Because I do not want/need nginx child run any command/fork
so, I want set RLIMIT_NPROC=0 to nginx child process, but nginx ignore
/etc/login.conf setting.
Thank you.
Index: src/core/nginx.c
===
* Alexey Suslikov [2014-04-21 12:38]:
> Henning Brauer bsws.de> writes:
>
> > > #if NVLAN > 0
> > > if (ifp->if_type == IFT_L2VLAN)
> > > return vlan_encap(ifp, m);
> > > #endif
> >
> > I don't think so, really. We're talking about 25 lines of code, in a
> > function that either pre
Henning Brauer bsws.de> writes:
> > #if NVLAN > 0
> > if (ifp->if_type == IFT_L2VLAN)
> > return vlan_encap(ifp, m);
> > #endif
>
> I don't think so, really. We're talking about 25 lines of code, in a
> function that either prepends a regular ethernet header or a
> vlan-ethernet
* Claudio Jeker [2014-04-21 11:14]:
> __inline is dead long live inline.
oups, that crept back in.
> Would it make sense to put this into a vlan_encap function so that we can
> reduce the amount of layer violation here?
>
> #if NVLAN > 0
> if (ifp->if_type == IFT_L2VLAN)
> r
On Sun, Apr 20, 2014 at 06:45:46PM +0200, Henning Brauer wrote:
> so, on vlan, to insert the vlan tag, we right now:
> -copy (most of) the existing ethernet header into a ether_vlan_header
> on the stack
> -fill the extra fields (tag, inside ether type) in ether_vlan_header
> -set the ether type
>
On Sun, Apr 20, 2014 at 7:06 PM, Ben Cornett wrote:
> Clarify the return value of getenv.
Committed. Thanks!
36 matches
Mail list logo
