Re: A proposal

2014-03-30 Thread Joe Nosay
On Sat, Mar 29, 2014 at 12:14 PM, Allan Jude free...@allanjude.com wrote: On 2014-03-29 09:21, Joe Nosay wrote: On Sat, Mar 29, 2014 at 9:11 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: On Fri, Mar 28, 2014 at

Re: A proposal

2014-03-29 Thread KIRIYAMA Kazuhiko
Hi, Allan At Sat, 29 Mar 2014 01:43:11 -0400, Allan Jude wrote: On 2014-03-29 01:22, Joe Nosay wrote: I have noticed that options VPS, VIMAGE, and MROUTING are not standard for the kernel with a base install. Is there any way that these can be made a part of the normal kernel so that

Re: A proposal

2014-03-29 Thread Lars Engels
On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude free...@allanjude.com wrote: On 2014-03-29 01:22, Joe Nosay wrote: I have noticed that options VPS, VIMAGE, and MROUTING

Re: A proposal

2014-03-29 Thread Joe Nosay
On Sat, Mar 29, 2014 at 5:29 AM, Lars Engels lars.eng...@0x20.net wrote: On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude free...@allanjude.com wrote: On 2014-03-29

Re: A proposal

2014-03-29 Thread Steve Kargl
On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude free...@allanjude.com wrote: On 2014-03-29 01:22, Joe Nosay wrote:

Re: A proposal

2014-03-29 Thread Joe Nosay
On Sat, Mar 29, 2014 at 9:11 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014

Re: A proposal

2014-03-29 Thread Allan Jude
On 2014-03-29 09:21, Joe Nosay wrote: On Sat, Mar 29, 2014 at 9:11 AM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400,

Re: A proposal

2014-03-29 Thread Lars Engels
On Sat, Mar 29, 2014 at 06:11:10AM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude

Re: A proposal

2014-03-29 Thread Gary Palmer
On Sat, Mar 29, 2014 at 06:11:10AM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude

Re: A proposal

2014-03-29 Thread Julian Elischer
On 3/29/14, 4:52 PM, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude free...@allanjude.com wrote: On 2014-03-29 01:22, Joe Nosay wrote: I have noticed that options VPS, VIMAGE, and MROUTING are not standard for the

RE: A proposal

2014-03-29 Thread dteske
-Original Message- From: Julian Elischer [mailto:jul...@freebsd.org] Sent: Saturday, March 29, 2014 3:41 PM To: Steve Kargl; Joe Nosay Cc: freebsd-current Subject: Re: A proposal On 3/29/14, 4:52 PM, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote

Re: A proposal

2014-03-28 Thread Allan Jude
On 2014-03-29 01:22, Joe Nosay wrote: I have noticed that options VPS, VIMAGE, and MROUTING are not standard for the kernel with a base install. Is there any way that these can be made a part of the normal kernel so that jail(s) would get the full benefit without a kernel recompile?

Re: A proposal

2014-03-28 Thread Joe Nosay
On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude free...@allanjude.com wrote: On 2014-03-29 01:22, Joe Nosay wrote: I have noticed that options VPS, VIMAGE, and MROUTING are not standard for the kernel with a base install. Is there any way that these can be made a part of the normal kernel so

Re: A proposal

2014-03-28 Thread Steve Kargl
On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude free...@allanjude.com wrote: On 2014-03-29 01:22, Joe Nosay wrote: I have noticed that options VPS, VIMAGE, and MROUTING are not standard for the kernel with a base install. Is there

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-08 Thread John-Mark Gurney
Warner Losh wrote this message on Fri, Mar 07, 2014 at 22:30 -0700: On Mar 7, 2014, at 10:22 PM, Allan Jude free...@allanjude.com wrote: Performance for default, sha512 w/ 5k rounds: AMD A10-5700 3.4GHz3.8ms AMD Opteron 4228 HE 2.8Ghz 5.4ms Intel(R) Xeon(R) X5650 2.67GHz

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-08 Thread Derek (freebsd lists)
Hi all, Thanks for your attention to the matter/threads. I have thought a bit about this, and I hope I can add some value to the current conversation, below: On 03/07/2014 07:36 PM, Xin Li wrote: On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: Xin Li wrote: On 03/07/14 13:52, A.J.

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread John Baldwin
On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security, not coupling it with an eventual expiration of non-migrated accounts

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Allan Jude
On 2014-03-07 09:13, John Baldwin wrote: On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security, not coupling it with an eventual

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Tom Evans
On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security,

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread A.J. Kehoe IV (Nanoman)
Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm (when combined with my other feature request). Updating my bcrypt hashes from $2a$04$ to $2b$12$ or something. Same applies for the default sha512, maybe I want to update to

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread RW
On Fri, 7 Mar 2014 09:13:30 -0500 John Baldwin wrote: I am assuming that an administrator wants the transparent upgrade (which I think is useful) because they are assuming that the hash algorithm is compromised or inferior. I'd expect it to be done well in advance of that to give plenty of

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread John Baldwin
On Friday, March 07, 2014 10:34:40 am Tom Evans wrote: On Fri, Mar 7, 2014 at 2:13 PM, John Baldwin j...@freebsd.org wrote: On Wednesday, March 05, 2014 3:09:30 pm Matthew Rezny wrote: Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Allan Jude
On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm (when combined with my other feature request). Updating my bcrypt hashes from $2a$04$ to $2b$12$ or something. Same applies

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread A.J. Kehoe IV (Nanoman)
Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm (when combined with my other feature request). Updating my bcrypt hashes from $2a$04$ to $2b$12$ or something.

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Allan Jude
On 2014-03-07 17:06, Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm (when combined

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread John-Mark Gurney
Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: On 2014-03-07 17:06, Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Xin Li
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 15:07, John-Mark Gurney wrote: Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: On 2014-03-07 17:06, Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13,

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread John-Mark Gurney
Xin Li wrote this message on Fri, Mar 07, 2014 at 16:43 -0800: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 15:07, John-Mark Gurney wrote: Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: On 2014-03-07 17:06, Xin Li wrote: Hi, On 03/07/14 13:52,

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread John-Mark Gurney
Xin Li wrote this message on Fri, Mar 07, 2014 at 16:36 -0800: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 14:50, A.J. Kehoe IV (Nanoman) wrote: Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread A.J. Kehoe IV (Nanoman)
Xin Li wrote: Hi, On 03/07/14 13:52, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: On 2014-03-07 11:13, A.J. Kehoe IV (Nanoman) wrote: Allan Jude wrote: [...] Honestly, my use case is just silently upgrading the strength of the hashing algorithm (when combined with my other feature

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Allan Jude
On 2014-03-07 21:15, John-Mark Gurney wrote: Xin Li wrote this message on Fri, Mar 07, 2014 at 16:43 -0800: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/07/14 15:07, John-Mark Gurney wrote: Allan Jude wrote this message on Fri, Mar 07, 2014 at 17:53 -0500: On 2014-03-07 17:06, Xin

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-07 Thread Warner Losh
On Mar 7, 2014, at 10:22 PM, Allan Jude free...@allanjude.com wrote: Performance for default, sha512 w/ 5k rounds: AMD A10-5700 3.4GHz 3.8ms AMD Opteron 4228 HE 2.8Ghz 5.4ms Intel(R) Xeon(R) X5650 2.67GHz 4.0ms these times are aprox as the timing varies quite a bit,

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-05 Thread Matthew Rezny
Password expiry is an orthogonal issue and should be up to administrator policy. Yes, but if you are moving to a different algorithm to improve security, not coupling it with an eventual expiration of non-migrated accounts gives a false sense of security. Any admin worth his/her salt is

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-03-03 Thread John Baldwin
On Friday, February 28, 2014 4:58:29 pm Eitan Adler wrote: On 27 February 2014 20:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-02-28 Thread Nick Hibma
On 28 Feb 2014, at 02:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-02-28 Thread Allan Jude
On 2014-02-28 10:07, Nick Hibma wrote: On 28 Feb 2014, at 02:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-02-28 Thread John Baldwin
On Friday, February 28, 2014 12:16:45 pm Allan Jude wrote: On 2014-02-28 10:07, Nick Hibma wrote: On 28 Feb 2014, at 02:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD

Re: Feature Proposal: Transparent upgrade of crypt() algorithms

2014-02-28 Thread Eitan Adler
On 27 February 2014 20:14, Allan Jude free...@allanjude.com wrote: With r262501 (http://svnweb.freebsd.org/base?view=revisionrevision=262501) importing the upgraded bcrypt from OpenBSD and eventually changing the default identifier for bcrypt to $2b$ it reminded me of a feature that is often

Re: Feature Proposal: 'rounds' tuneables for crypt() algorithms

2014-02-27 Thread John-Mark Gurney
Allan Jude wrote this message on Thu, Feb 27, 2014 at 20:28 -0500: Currently, you can change the password hashing algorithm used by crypt() with the passwd_format in /etc/login.conf However, as far as I could find, you cannot change the number of 'rounds', the dynamic adjustment factor using

Re: [patch] Proposal: move getmntopts(3) into libutil

2013-02-27 Thread Sergey Kandaurov
On 26 February 2013 16:20, Konstantin Belousov kostik...@gmail.com wrote: On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote: Hi. The functions from sbin/mount/getmntopts.c are used in a bunch of other stuff like mount_* utilities which have to suck them in as their own

Re: [patch] Proposal: move getmntopts(3) into libutil

2013-02-27 Thread Sergey Kandaurov
On 26 February 2013 23:11, Craig Rodrigues rodr...@crodrigues.org wrote: On Tue, Feb 26, 2013 at 3:39 AM, Sergey Kandaurov pluk...@gmail.com wrote: Hi. External mount-like utilities may also have difficulties with building to get getmntopts.c source as this requires /usr/src presence which

Re: [patch] Proposal: move getmntopts(3) into libutil

2013-02-27 Thread Konstantin Belousov
On Wed, Feb 27, 2013 at 07:08:35PM +0300, Sergey Kandaurov wrote: I have put it on freefall for convenience. http://people.freebsd.org/~pluknet/patches/getmntopts.2.patch Should the synopsis for getmntopts(3) use #include mntopts.h, instead of '', as well as the example ? For the mntopts.h

Re: [patch] Proposal: move getmntopts(3) into libutil

2013-02-26 Thread Konstantin Belousov
On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote: Hi. The functions from sbin/mount/getmntopts.c are used in a bunch of other stuff like mount_* utilities which have to suck them in as their own functions in quite a hackish way. getmntopts.c copies are compiled in to an

Re: [patch] Proposal: move getmntopts(3) into libutil

2013-02-26 Thread Alfred Perlstein
On 2/26/13 4:20 AM, Konstantin Belousov wrote: On Tue, Feb 26, 2013 at 02:39:26PM +0300, Sergey Kandaurov wrote: Hi. The functions from sbin/mount/getmntopts.c are used in a bunch of other stuff like mount_* utilities which have to suck them in as their own functions in quite a hackish way.

Re: [patch] Proposal: move getmntopts(3) into libutil

2013-02-26 Thread Craig Rodrigues
On Tue, Feb 26, 2013 at 3:39 AM, Sergey Kandaurov pluk...@gmail.com wrote: Hi. External mount-like utilities may also have difficulties with building to get getmntopts.c source as this requires /usr/src presence which is in sync with installed world. Look how mount_fusefs from ports

Re: NETGRAPH (proposal. FINAL)

2000-02-29 Thread Garrett Wollman
On Tue, 29 Feb 2000 18:59:50 +0100 (CET), Luigi Rizzo [EMAIL PROTECTED] said: can you clarify this ? Looong ago i used the '586 on a bridge and it did let me write the MAC header... The 82586 has a mode bit which selects one of two possibilities: 1) The transmit command specifies the

Re: NETGRAPH (proposal. FINAL)

2000-02-29 Thread Archie Cobbs
Julian Elischer writes: here is url: http://home.earthlink.net/~evmax/ng.tar.gz these are final patches for NETGRAPH. new features: - new hook ``divertin'' allows to put frame back to kernel stack. - new control message allows to set raw mode on ``divert'' hook. raw mode assumes

Re: NETGRAPH (proposal. FINAL)

2000-02-29 Thread Julian Elischer
Yevmenkin, Maksim N, CSCIO wrote: hello all, here is url: http://home.earthlink.net/~evmax/ng.tar.gz these are final patches for NETGRAPH. new features: - new hook ``divertin'' allows to put frame back to kernel stack. - new control message allows to set raw mode on ``divert'' hook.

RE: NETGRAPH (proposal. FINAL)

2000-02-29 Thread Yevmenkin, Maksim N, CSCIO
[...] This is good in theory, however the intel 82586 ethernet chip (and 596 in 586 mode) will overwrite anything you put there anyhow as it treats the header specially and fabricates it. (unless you are running in some mode that is not usually used). I don't know how many other chips

Re: NETGRAPH (proposal. FINAL)

2000-02-29 Thread Luigi Rizzo
This is good in theory, however the intel 82586 ethernet chip (and 596 in 586 mode) will overwrite anything you put there anyhow as it treats the header specially and fabricates it. (unless you are running in some mode that is not usually used). can you clarify this ? Looong ago i used the

Re: NETGRAPH (proposal. FINAL)

2000-02-29 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Julian Elischer writes: these are final patches for NETGRAPH. new features: - new hook ``divertin'' allows to put frame back to kernel stack. - new control message allows to set raw mode on ``divert'' hook. raw mode assumes that we have fully prepared frame