Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 3/7/14 8:41 AM, Rui Paulo wrote: On 6 Mar 2014, at 23:30, David Xu davi...@freebsd.org wrote: it seems filename ended with a dot is illegal on Windows, if someone wants to check out freebsd source code on Windows, it will be a problem. Is this something we want to support? NetBSD made some invasive changes on their source tree to be able to support case-insensitive filesystems (like renaming 'cvs' to 'xcvs' to avoid clashing with the 'CVS' metadata directory), but they support building NetBSD on many different platforms. We don't support that yet, though. The file in question can be easily renamed, I think. We definitely want to support untaring/zipping the code on Windows. Even if not for cross compiling, just for convenience of use. -- Alfred Perlstein ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 4.0ms
these times are aprox as the timing varies quite a bit, ~+/-10%?
And what would that be on a RPi or other embedded device?
Ok, here you go, IXP425 533MHz is ~1465ms.. This is a fast AVILA
board, I have a slower 266MHz AVILA board next to me... Yes, that is
1.5 seconds at the default number of rounds for sha512 which is now the
default for passwords...
For comparision, md5 is 44.5ms and sha256 is 405ms on the AVILA...
So, by making sha512, we just killed the performance of embedded
systems... This is also with the default of 5000 rounds...
So, the autoscaling could either help on embedded because we let the
number of rounds drop below the default of 5k, or it stays the same, so,
no hit on embedded...
And do the extra route have a peer-reviewed paper showing the increased
strength?
Well, if it doesn't increase the strength, then we might as well drop
the rounds down to 1000 (the min per spec)... since clearly if
increasing rounds pass 5k doesn't increase strength, then the same can
be said for 1k...
As for papers, I don't think anyone wrote a peer-reviewed paper saying
that crypt-sha{256,512} is secure...
Plus, they clearly thought that changing the rounds would be helpful,
so, they added it as an option, well, actually, Drepper just copied
Sun for making rounds an option...
Per Drepper:
The more rounds are performed the higher the CPU
requirements are. This is a safety mechanism which might help
countering brute-force attacks in the face of increasing computing
power.
Notice the might...
http://www.akkadia.org/drepper/SHA-crypt.txt
One possible solution would be just setting the default login.conf
number of rounds, based on a test in the installer. Although this won't
help for systems that are deployed by imaging, or VM images (like EC2
images) etc.
Does CPU time measuring work properly on VM's? i.e. if I do a cpu
intesive task and measure it with getrusage, do I get how much I really
ran for? By my understanding, you can't, since often the VM isn't aware
of the parent, so doesn't know when to stop the clock when it isn't
running...
Unless I'm missing something, you really can't do any cpu or profiling
on a VM and trust the results...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Call for FreeBSD 2014Q1 (January-March) Status Reports
Dear FreeBSD Community, Please note that the next submission date for the January to March Quarterly Status Reports is April 7th, 2014, about a month away. They do not have to be very long -- basically they may be about anything that lets people know what is going on around the FreeBSD Project. Submission of reports is not restricted to committers: Anyone who is doing anything interesting and FreeBSD-related can (and therefore encouraged to) write one! The preferred and easiest submission method is to use the XML generator [1] with the result emailed as an attachment to us, that is, mont...@freebsd.org [2]. There is also an XML template [3] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status reports [4]. If you are still unsure what constitutes a good status report, check out the last issue [5]. To enable compilation and publication of the quarterly report as soon as possible for the April 7th deadline, please be prompt with any report submissions you may have. We are looking forward to all of your 2014Q1 reports! Thanks, Gabor [1] http://www.freebsd.org/cgi/monthly.cgi [2] mailto:mont...@freebsd.org [3] http://www.freebsd.org/news/status/report-sample.xml [4] http://www.freebsd.org/news/status/howto.html [5] http://www.freebsd.org/news/status/report-2013-10-2013-12.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: importing sam leffler's libstatfoo into -HEAd
John Baldwin j...@freebsd.org writes: Dag-Erling Smørgrav d...@des.no writes: Why did you rename it? The whole point of PRIVATELIB is to avoid having to rename libraries. Because 'statfoo' is a pretty silly name? (This is detailed in another subthread, did you not read that?) The original patch renamed it to bsdstatfoo, did you not read that? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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. 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 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 rounds=15000 Like this? http://www.freebsd.org/cgi/query-pr.cgi?pr=182518 Request for comments: http://docs.freebsd.org/cgi/mid.cgi?20140106205156.GD4903 [...] Speaking for adding rounds, the only problem that needs to be fixed is that the proposed patch makes it possible to create conflicting configuration (passwd_format and passwd_modular can use different hashing algorithms) and need to be fixed and polished. I like the idea of making it possible to use more rounds though. This was deliberate for backward compatibility. passwd_format will be used by default if passwd_modular isn't defined. If passwd_modular is defined as disabled, then passwd_format will be used. Well, my point is that the two shouldn't be allowed to exist together if they can mean something conflicting. Allowing passwd_format=sha512 AND passwd_modular=$2a$08$ in the same configuration creates confusion and it's not good. Agreed. My original intention was to create a patch that didn't touch a lot of code. My reasons for this were first to see if there was any interest from a committer to take this further. Much more likely to have a 15 or so line patch looked at, than one that touches stuff all over the place - I think. We are now at least having a conversation about it. It seemed to be a lot of work to specify rounds via login_setcryptfmt, with a bunch of changes also required in libcrypt. I don't have the resources to test for regressions in libcrypt, beyond the scope of whether login.conf works as expected (specifically, the ports tree, yp, ldap, or any other areas that I don't know about). If other developers were willing to work together on the api/abi changes, I would feel a lot better about spending my time there and doing it right. Without support from other, more knowledgeable people (as far as what will break if we do XYZ), who will eventually merge productive changes, I would be wasting my time. I don't want to be the libcrypt api changing pixie, scattering patches into /dev/null. :) My suggestion is that we either have: a) passwd_format and passwd_round (so that they don't conflict), or I recommend against this. By example, based on current scrypt modular crypt RFCs, there are multiple tunable parameters. It's conceivable that other future algorithms will have different functional and named parameters. Additionally, I think having all the parsing code for this scattered about actually makes things less clear. For example, $2a$08$ means a lot more to people (across different *nix backgrounds) than blf, is concise, and is/already should be well documented in crypt(3). Likewise with sha512. Looking at login.conf, you can't tell exactly what it means. Modular crypt is something that developers are working to stay compatible with (e.g. $5$, $6$, $2y$, etc), is understood outside of the context of FreeBSD system administration, and would be understood by people who are knowledgeable enough to seek to change this aspect of their system. b) extend passwd_format in a compatible manner to allow specifying a round, or, c) make passwd_format and passwd_modular conflict so we don't silently accept it and instead bail out when doing pwd_mkdb. As jmg suggested, by supplying the modular format for passwd_format, we eliminate this conflict, and make it obvious. I definitely support this notion. That means touching login_setcryptfmt and friends, I think. What do you think of the idea of putting this into libcrypt instead of pam_unix.c, and then patching pam_unix.c and pw_user.c to reference libcrypt? Which part of the idea? I think it's a bad idea to make libcrypt to depend on libutil (for login_cap(3)) but we should probably provide new wrappers in login_cap(3) to do the common things when requested for various password manipulating tools to reduce duplicated code. Specifically: The makesalt aspect can/should be put into libcrypt, refined appropriately, and exposed publicly. It is a terrible little piece of code as it is now, twice (or more!), and it could be cleaned up considerably. This could be a nice little api. Secondly, since the digests are used externally, I think it would be good to push the custom base64 code out to a library somewhere, so there is the
