On Mon, 28 Apr 2014, Ted Unangst wrote:
Hi there. I'm trying to find somebody who is actually using either
Kerberos or SRP support in libssl. I'm inclined to remove support for
them. While the bulk of the code sits off to the side, the integration
requires adding several additional cases to
The problem is still there with recent -current
$ dmesg | head -n1
OpenBSD 5.5-current (GENERIC.MP) #85: Sun Apr 27 09:24:33 MDT 2014
Should I send a bug-report with sendbug(1)?
2014-04-16 8:34 GMT+02:00 Markus Bergkvist mar...@familjenbergkvist.net:
2014-02-26 11:08 GMT+01:00 Markus Bergkvist
* Adam Thompson athom...@athompso.net [2014-04-29 04:37]:
On April 28, 2014 5:43:34 PM CDT, Kenneth Westerback kwesterb...@gmail.com
wrote:
On 28 April 2014 18:05, Simon Perreault si...@per.reau.lt wrote:
Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil
master plan:
make
On 2014/04/28 18:05, Simon Perreault wrote:
Tech,
Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil master plan:
make getaddrinfo() return IPv6 results first by default.
The diff below would be the end goal. I guess people will have valid
objections
to it. I'd like to
On 28/04/14(Mon) 22:57, Martin Pieuchot wrote:
On 28/04/14(Mon) 21:51, Stuart Henderson wrote:
On 2014/04/28 19:09, Martin Pieuchot wrote:
On 28/04/14(Mon) 17:53, Stuart Henderson wrote:
On 2014/04/28 18:39, Martin Pieuchot wrote:
On 28/04/14(Mon) 17:32, Stuart Henderson wrote:
Hi,
This patch for /usr/share/misc/getopt enforces the use of getprogname()
instead of __progname.
Is this desirable? If so I also have a patch for style(9).
Index: getopt
===
RCS file: /cvs/src/share/misc/getopt,v
retrieving
Date: Tue, 29 Apr 2014 11:31:48 +0200
From: Tristan Le Guern tlegu...@bouledef.eu
Hi,
This patch for /usr/share/misc/getopt enforces the use of getprogname()
instead of __progname.
Is this desirable? If so I also have a patch for style(9).
getprogname(3) isn't really more portable
Le 2014-04-28 18:53, Chris Cappuccio a écrit :
Why is the burden on everyone to provide 'valid' objections? Should
not the burden be on you to at least hint at a point to this change?
Given the miniscule IPv6 usage out there, why should IPv6 come first?
I like how IPv6 support turns primary
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear picture of what the issues are,
and whether there's anything I can do to
On 29 April 2014 08:57, Simon Perreault si...@per.reau.lt wrote:
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear picture
* Simon Perreault si...@per.reau.lt [2014-04-29 14:58]:
I don't see how usage is relevant. If IPv6 provided 1000% performance
improvement with no downsides, we would want to use it even if global
usage was low.
however, it provides far worse performance with shitloads of downsides...
--
Em 29-04-2014 04:51, Stuart Henderson escreveu:
Too soon I think. Wait a little longer and more major ISPs will turn
IPv4 into the second class citizen as they fumble with their cgnat
deployments then this will make a lot more sense. Now that akamai have
their /10 taking ARIN into the final /8
* Simon Perreault si...@per.reau.lt [2014-04-29 14:41]:
Le 2014-04-28 18:53, Chris Cappuccio a écrit :
Why is the burden on everyone to provide 'valid' objections? Should
not the burden be on you to at least hint at a point to this change?
Given the miniscule IPv6 usage out there, why
Le 2014-04-28 18:54, Todd T. Fries a écrit :
IPv6 is a 2nd class netizen in terms of reliability and user
experience.
Here's the relevant data I know of:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Le 2014-04-29 09:44, Kenneth Westerback a écrit :
Why would having the IPv6 addresses come first in the returned list be
required to 'use' them? Please explain.
Well I thought this would be obvious, but applications using
getaddrinfo() typically try connecting to each of the addresses returned
On Tue, Apr 29, 2014 at 08:57, Simon Perreault wrote:
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear picture of what
Le 2014-04-29 09:55, Henning Brauer a écrit :
Wouldn't it be better if libasr would run A and requests in
parallel? Whichever response arrives first wins.
no, since that gives extremely unpredictable results.
How about this then:
- Run both requests in parallel.
- When one response is
On Tue, Apr 29, 2014 at 08:57:57AM -0400, Simon Perreault wrote:
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear
* Simon Perreault si...@per.reau.lt [2014-04-29 16:05]:
Le 2014-04-29 09:55, Henning Brauer a écrit :
Wouldn't it be better if libasr would run A and requests in
parallel? Whichever response arrives first wins.
no, since that gives extremely unpredictable results.
How about this
Le 2014-04-29 09:52, Giancarlo Razzolini a écrit :
I disable ipv6 across all my linux desktops installations because some
daemons aren't smart enough to not try it first. Postfix is one that
comes from the top of my mind.
That's why we needed AI_ADDRCONFIG. The point is that getaddrinfo()
On Tue, Apr 29, 2014 at 10:04:35AM -0400, Simon Perreault wrote:
Le 2014-04-29 09:55, Henning Brauer a ?crit :
Wouldn't it be better if libasr would run A and requests in
parallel? Whichever response arrives first wins.
no, since that gives extremely unpredictable results.
How
On 2014/04/29 10:52, Giancarlo Razzolini wrote:
Em 29-04-2014 04:51, Stuart Henderson escreveu:
Too soon I think. Wait a little longer and more major ISPs will turn
IPv4 into the second class citizen as they fumble with their cgnat
deployments then this will make a lot more sense. Now that
On Tue, Apr 29, 2014 at 10:04, Simon Perreault wrote:
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results as usual.
- Otherwise, kill the second
On 29 April 2014 09:59, Simon Perreault si...@per.reau.lt wrote:
Le 2014-04-29 09:44, Kenneth Westerback a écrit :
Why would having the IPv6 addresses come first in the returned list be
required to 'use' them? Please explain.
Well I thought this would be obvious, but applications using
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results as usual.
- Otherwise, kill the second request and
Is it ok to zap .klogin?
cheers
David
Index: distrib/sets/lists/etc/mi
===
RCS file: /cvs/src/distrib/sets/lists/etc/mi,v
retrieving revision 1.162
diff -u -p -u -p -r1.162 mi
--- distrib/sets/lists/etc/mi 24 Apr 2014 21:07:37
So, I'm resending this diff since the previous bug has been fixed,
still looking for oks.
On 09/04/14(Wed) 11:22, Martin Pieuchot wrote:
When an IPv6 address is configured on a point-to-point interface, it
is associated to nd6_rtrequest(). This is because nd6_request()
contains a hack to
Not sure this is sensible as it encourages people to simply
update the table.
I was inclined to remove the code entirely but I am not sure
what broken systems might rely on this.
Only build tested.
Thoughts?
Index: b_sock.c
===
On 29 April 2014 10:42, Dimitris Papastamos s...@2f30.org wrote:
Not sure this is sensible as it encourages people to simply
update the table.
I was inclined to remove the code entirely but I am not sure
what broken systems might rely on this.
Only build tested.
Thoughts?
Index:
Penned by Kenneth Westerback on 20140429 8:44.16, we have:
| On 29 April 2014 08:57, Simon Perreault si...@per.reau.lt wrote:
| Le 2014-04-28 18:43, Kenneth Westerback a écrit :
| Why is the burden on everyone to provide 'valid' objections?
|
| I know that what I proposed cannot go
This seems to fix growfs on 4k-sector drives by doing the test write
to the last sector rather than the last 512-byte block, which can't be
accessed directly on 4k-sector drives.
Any other growfs users out there want to test on 'normal' drives?
Ken
Index: growfs.c
Penned by Otto Moerbeek on 20140429 9:07.54, we have:
| On Tue, Apr 29, 2014 at 10:04:35AM -0400, Simon Perreault wrote:
|
| Le 2014-04-29 09:55, Henning Brauer a ?crit :
| Wouldn't it be better if libasr would run A and requests in
| parallel? Whichever response arrives first wins
On 2014-04-29, Mark Kettenis mark.kette...@xs4all.nl wrote:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Isn't there a correlation between those countries and actual IPv6 usage?
According to
On 29 April 2014 12:57, Christian Weisgerber na...@mips.inka.de wrote:
On 2014-04-29, Mark Kettenis mark.kette...@xs4all.nl wrote:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Isn't there a
On Tue, Apr 29, 2014 at 04:57:28PM +, Christian Weisgerber wrote:
On 2014-04-29, Mark Kettenis mark.kette...@xs4all.nl wrote:
Google's data [1] shows a few third-world countries where what you say
is true, plus Japan because of a single particularly broken ISP [2].
Isn't there a
This changes getrnibble in malloc to getrbyte() for more potential
randomness.
The delayed chunk array can (should) be larger, but requires more than
a nibble of random to span it. Not changed yet, but with this diff it
can grow (or even shrink) in the future.
The bit offset in malloc_bytes
On Tue, Apr 29, 2014 at 10:52:06AM -0300, Giancarlo Razzolini wrote:
| Em 29-04-2014 04:51, Stuart Henderson escreveu:
| Too soon I think. Wait a little longer and more major ISPs will turn
| IPv4 into the second class citizen as they fumble with their cgnat
| deployments then this will make a
Em 29-04-2014 17:25, Paul de Weerd escreveu:
Disabling IPv6 should not be necessary: it shouldn't be enabled by
default, even link-local addresses.
Exactly my point. Even with only link local addresses, some daemons bind
to tcp6 wildcard sockets and I can detect delays when using a linux with
On Tue, Apr 29, 2014 at 2:25 PM, Paul de Weerd we...@weirdnet.nl wrote:
Why oh why can I bring up an interface and have attackers probe me
over IPv6 on a default OpenBSD install while they cannot do so over
IPv4? Why is IPv6 more enabled than IPv4? IPv4 takes configuration
before it will
Am Montag, 28. April 2014, 21:40:30 schrieb Ted Unangst:
Also note that I'm not really interested in rumors or whispers. You
don't need to tell me that it's possible somebody else uses
Kerberos. I know it's possible, that's why I'm asking. I'd like to
know who.
One data point: Apache HTTPD
On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote:
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results
On 2014/04/29 22:25, Paul de Weerd wrote:
Disabling IPv6 should not be necessary: it shouldn't be enabled by
default, even link-local addresses.
If doing this, then we need a way to enable link-local, like the opposite
of ifconfig $if -inet6. Current process to re-enable just the link-local
is
This diff attempts to unify volume keys; it makes pckbd and ukbd
volume keys behave like all other volume keys (acpithinkpad,
acpiasus, macppc/abtn and similar drivers): simply adjust the
hardware volume without passing keystroke events to upper layers
(i.e. consume the keystroke).
If your volume
this diff applies on top of the previous one; it adds the
hw.kbdvolume sysctl(1) entry to select how pckbd ukbd volume keys
are handled:
hw.kbdvolume=0
pass keystrokes to upper layer as we do for regular keys,
thus usable by X apps as hot-keys or whatever.
hw.kbdvolume=1
this diff applies on top of the previous one; it adds the
hw.kbdvolume sysctl(1) entry to select how pckbd ukbd volume keys
are handled:
hw.kbdvolume=0
pass keystrokes to upper layer as we do for regular keys,
thus usable by X apps as hot-keys or whatever.
hw.kbdvolume=1
On Tue, Apr 22, 2014 at 11:43:21PM +0200, Stefan Sperling wrote:
I think a better step forward for LC_TIME support would be to focus on
nl_langinfo() first and make it return locale-specific data for LC_TIME.
The functions you're looking at are icing on the cake. We should be
looking at adding
previously on this list Stuart Henderson contributed:
My thinking is that *if* someone has taken steps to enable v6,
then programs should try to use it for comms where possible.
family inet6 inet4 is too blunt and affects people who don't want
to touch v6.
I'm used to seeing NOINET6 in
On 04/30/14 00:12, Ted Unangst wrote:
On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote:
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer
On 04/30/14 01:45, Alexander Hall wrote:
However, doing the requests in parallel, each geting the same treatment
as if done in sequence (timing out if need be, etc), and then sort them
by the family directive as per resolv.conf could in theory cut the
lookup time in half...
Not that this has
Don't bother with diffs to b_sock.c. Instead, if you have code
which uses it, talk to krw.
There is a monster diff coming which rewrites it all.
And by the way, all that code disapears and is replaced by 2 lines.
Not sure this is sensible as it encourages people to simply
update the table.
I know that what I proposed cannot go in at the moment. It's my end
goal.
The goal is ridiculous.
If anything, it should be sorted by the best addresses first. Today
the best addresses are IPv4. There is no dynamic method to determine
best, but measurements all over the world show that IPv4
Someone has to take the first/next step, and that's a very
traditional role for OpenBSD.
Apply these kinds of changes to your entire production network,
and report back in 6 months if you are still running them.
The constant MFSNAMELEN as defined in:
lib/libc/sys/getfsstat.2:#define MFSNAMELEN 16
lib/libc/sys/statfs.2:#define MFSNAMELEN 16
sys/sys/mount.h: #define MFSNAMELEN 16
defines the fs type name and, according to comments, it includes nul
terminating character.
The following code
On Tue 29 Apr 2014 09:04:36 PM CDT, Theo de Raadt wrote:
I know that what I proposed cannot go in at the moment. It's my end
goal.
The goal is ridiculous.
If anything, it should be sorted by the best addresses first. Today
the best addresses are IPv4. There is no dynamic method to determine
However, based on available evidence, IPv4 is not better than IPv6 in
every respect for everyone.
You've written a long mail and completely missed the point.
This is not a conversation about your IPv6 connection.
It is about what the sensible default should be for everyone.
This is a new and improved patch to add dynamic address allocation support
to iked. Includes an update to the man page, and a simpler implementation
then my previous work.
- An address pool is globally defined as pool name cidr block, and
referenced from a policy with pool name. (If this patch
56 matches
Mail list logo
