Re: importing sam leffler's libstatfoo into -HEAd
Adrian Chadd writes: > http://people.freebsd.org/~adrian/patches/20140304-libbsdstatfoo.diff Why did you rename it? The whole point of PRIVATELIB is to avoid having to rename libraries. 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: importing sam leffler's libstatfoo into -HEAd
On Friday, March 07, 2014 5:51:27 am Dag-Erling Smørgrav wrote: > Adrian Chadd writes: > > http://people.freebsd.org/~adrian/patches/20140304-libbsdstatfoo.diff > > 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?) -- John Baldwin ___ 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
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 gives a > > false sense of security. Any admin worth his/her salt is going to want the > > option of enforcing that sort of policy along with the transparent update. > > They should really be implemented together is all. > > Account expiration and password expiration are already present. There is > absolutely no reason that password algorithm upgrade should be tied in any > way > to expiration. A transparent algorithm upgrade as proposed is *far* better > than the forced password change method that is commonly employed. If the > administrator wants to force all accounts to migrate by a set deadline, we > already have the expiration facilities in place to accomplish that. Expiring > accounts that have not been used in a long time, regardless of algorithm > changes, should be part of general housekeeping and may be covered by > existing > policy. Password expiration serves no purpose, EVER. Password expiration > encourages users to choose bad passwords because they are throwaway items. > > Bruce states it well enough I need not elaborate further > https://www.schneier.com/blog/archives/2010/11/changing_passwo.html > > Anyone who fails to understand the above should NOT be an administrator. I think you failed to understand my point. 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. To that end, they may wish to limit the time window for which they accept hashes generated using the suspect algorithm. This is separate (I believe) from the issue Bruce raises above. For example, in this case, the administrator is perfectly happy for the actual plaintext to remain the same, the administrator simply wants to enforce the new hash. As far as I can tell, there is nothing in /etc/login.conf to allow for automatic account expiration if an account is idle for more than N days. OTOH, even that is probably not sufficient for the original case since a user might login with a different authentication method (e.g. ssh key) that would reset the idle timer without updating the hash. I suppose if you really were paranoid about the hash what you would want is an ability to set an expiration time on the hash algo itself where authentication using that hash always fails after the expiration time. This doesn't necessarily expire the entire account (e.g. ssh key auth would still work), though it might be a bit surprising to the user to find that the next time they attempt to use password authentication it doesn't work. (You would at least want a warning about the hash being expired on login via another mechanism.) -- John Baldwin ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 12:30 AM, David Xu wrote: > When I am using mercurial to initialize a freebsd repository, it prints > "warning: filename ends with '.', which is not allowed on Windows: > 'tools/test/sort/bigtest/q-1.024.003.' > > 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. There are other problems as well. We have some directories that have mixed case and lower case versions of the same file. This trips up OS unless you specifically format your disk to be case sensitive… Warner ___ 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
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 expiration of non-migrated accounts gives a >>> false sense of security. Any admin worth his/her salt is going to want the >>> option of enforcing that sort of policy along with the transparent update. >>> They should really be implemented together is all. >> >> Account expiration and password expiration are already present. There is >> absolutely no reason that password algorithm upgrade should be tied in any >> way >> to expiration. A transparent algorithm upgrade as proposed is *far* better >> than the forced password change method that is commonly employed. If the >> administrator wants to force all accounts to migrate by a set deadline, we >> already have the expiration facilities in place to accomplish that. Expiring >> accounts that have not been used in a long time, regardless of algorithm >> changes, should be part of general housekeeping and may be covered by >> existing >> policy. Password expiration serves no purpose, EVER. Password expiration >> encourages users to choose bad passwords because they are throwaway items. >> >> Bruce states it well enough I need not elaborate further >> https://www.schneier.com/blog/archives/2010/11/changing_passwo.html >> >> Anyone who fails to understand the above should NOT be an administrator. > > I think you failed to understand my point. 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. To that end, > they may wish to limit the time window for which they accept hashes generated > using the suspect algorithm. This is separate (I believe) from the issue > Bruce > raises above. For example, in this case, the administrator is perfectly happy > for the actual plaintext to remain the same, the administrator simply wants to > enforce the new hash. > > As far as I can tell, there is nothing in /etc/login.conf to allow for > automatic > account expiration if an account is idle for more than N days. > > OTOH, even that is probably not sufficient for the original case since a user > might > login with a different authentication method (e.g. ssh key) that would reset > the > idle timer without updating the hash. > > I suppose if you really were paranoid about the hash what you would want is an > ability to set an expiration time on the hash algo itself where authentication > using that hash always fails after the expiration time. This doesn't > necessarily > expire the entire account (e.g. ssh key auth would still work), though it > might > be a bit surprising to the user to find that the next time they attempt to use > password authentication it doesn't work. (You would at least want a warning > about the hash being expired on login via another mechanism.) > 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 -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Fri, Mar 7, 2014 at 2:13 PM, 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 expiration of non-migrated accounts gives a >> > false sense of security. Any admin worth his/her salt is going to want the >> > option of enforcing that sort of policy along with the transparent update. >> > They should really be implemented together is all. >> >> Account expiration and password expiration are already present. There is >> absolutely no reason that password algorithm upgrade should be tied in any >> way >> to expiration. A transparent algorithm upgrade as proposed is *far* better >> than the forced password change method that is commonly employed. If the >> administrator wants to force all accounts to migrate by a set deadline, we >> already have the expiration facilities in place to accomplish that. Expiring >> accounts that have not been used in a long time, regardless of algorithm >> changes, should be part of general housekeeping and may be covered by >> existing >> policy. Password expiration serves no purpose, EVER. Password expiration >> encourages users to choose bad passwords because they are throwaway items. >> >> Bruce states it well enough I need not elaborate further >> https://www.schneier.com/blog/archives/2010/11/changing_passwo.html >> >> Anyone who fails to understand the above should NOT be an administrator. > > I think you failed to understand my point. 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. To that end, > they may wish to limit the time window for which they accept hashes generated > using the suspect algorithm. This is separate (I believe) from the issue > Bruce > raises above. For example, in this case, the administrator is perfectly happy > for the actual plaintext to remain the same, the administrator simply wants to > enforce the new hash. > > As far as I can tell, there is nothing in /etc/login.conf to allow for > automatic > account expiration if an account is idle for more than N days. > > OTOH, even that is probably not sufficient for the original case since a user > might > login with a different authentication method (e.g. ssh key) that would reset > the > idle timer without updating the hash. > > I suppose if you really were paranoid about the hash what you would want is an > ability to set an expiration time on the hash algo itself where authentication > using that hash always fails after the expiration time. This doesn't > necessarily > expire the entire account (e.g. ssh key auth would still work), though it > might > be a bit surprising to the user to find that the next time they attempt to use > password authentication it doesn't work. (You would at least want a warning > about the hash being expired on login via another mechanism.) > All of this is orthogonal to adding a way to upgrade hashes. Yes, all of the points you mentioned are relevant to general password security, but doesn't explain why a feature that provides transparent hash upgrades cannot be added without first adding the features you are asking for. It's like trying to prevent people from shooting themselves in the foot by only giving them rocks to throw. Cheers Tom ___ 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
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 -- A.J. Kehoe IV (Nanoman) | /"\ ASCII Ribbon Campaign Nanoman's Company | \ / - No HTML/RTF in E-mail E-mail: nano...@nanoman.ca | X- No proprietary attachments WWW: http://www.nanoman.ca/ | / \ - Respect for open standards smime.p7s Description: S/MIME cryptographic signature
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 6 Mar 2014, at 23:30, David Xu 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. -- Rui Paulo ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 March 2014 11:41, Rui Paulo wrote: > On 6 Mar 2014, at 23:30, David Xu 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? Yes. > 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. Has anyone enumerated the problematic files for FreeBSD ? > We don't support that yet, though. However, being able to checkout out the source code is a prerequisite to building out other platforms. > The file in question can be easily renamed, I think. -- Eitan Adler ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 9:47 AM, Eitan Adler wrote: > On 7 March 2014 11:41, Rui Paulo wrote: >> On 6 Mar 2014, at 23:30, David Xu 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? > > Yes. > >> 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. > > Has anyone enumerated the problematic files for FreeBSD ? Last time I looked there were only a handful. I’ll conduct a census and get a concrete enumeration of the problem… Warner >> We don't support that yet, though. > > However, being able to checkout out the source code is a prerequisite > to building out other platforms. > >> The file in question can be easily renamed, I think. > > -- > Eitan Adler > ___ > 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" ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Fri, 2014-03-07 at 10:19 -0700, Warner Losh wrote: > On Mar 7, 2014, at 9:47 AM, Eitan Adler wrote: > > > On 7 March 2014 11:41, Rui Paulo wrote: > >> On 6 Mar 2014, at 23:30, David Xu 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? > > > > Yes. > > > >> 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. > > > > Has anyone enumerated the problematic files for FreeBSD ? > > Last time I looked there were only a handful. I’ll conduct a census and get a > concrete enumeration of the problem… Last time I noticed (early last year) there were 3 files ending in a dot and no case conflicts. Mercurial now finds just the one file ending in a dot and no case conflicts (doing "hg init;hg add -q" at /usr/src). -- Ian ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 10:22 AM, Ian Lepore wrote: > On Fri, 2014-03-07 at 10:19 -0700, Warner Losh wrote: >> On Mar 7, 2014, at 9:47 AM, Eitan Adler wrote: >> >>> On 7 March 2014 11:41, Rui Paulo wrote: On 6 Mar 2014, at 23:30, David Xu 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? >>> >>> Yes. >>> 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. >>> >>> Has anyone enumerated the problematic files for FreeBSD ? >> >> Last time I looked there were only a handful. I’ll conduct a census and get >> a concrete enumeration of the problem… > > Last time I noticed (early last year) there were 3 files ending in a dot > and no case conflicts. Mercurial now finds just the one file ending in > a dot and no case conflicts (doing "hg init;hg add -q" at /usr/src). Confirmed via regex, almost… Now there’s only one ending in dot: ./tools/test/sort/bigtest/q-1.024.003. Warner ___ 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
what he said. -a On 7 March 2014 05:37, John Baldwin wrote: > On Friday, March 07, 2014 5:51:27 am Dag-Erling Smørgrav wrote: >> Adrian Chadd writes: >> > http://people.freebsd.org/~adrian/patches/20140304-libbsdstatfoo.diff >> >> 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?) > > -- > John Baldwin ___ 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"
failed to complie webkit-gtk2: Cannot allocate memory
hi all: i am trying to compile webkit-gtk2 and stuck on error: === ar: warning: can't mmap file: libWebCore_la-SVGFEDisplacementMapElement.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-SVGFEDropShadowElement.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-SVGFEFloodElement.o: Cannot allocate memory [...] ar: warning: can't mmap file: libWebCore_la-JSNamedNodeMap.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-JSNavigator.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-JSNavigatorUserMediaError.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-JSNavigatorUserMediaErrorCallback.o: Cannot allocate memory [...] ar: warning: can't mmap file: libWebCore_la-JSWebSocket.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-glslang.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-glslang_tab.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-JSRequestAnimationFrameCallback.o: Cannot allocate memory ar: warning: can't mmap file: libWebCore_la-JSHTMLShadowElement.o: Cannot allocate memory ranlib: fatal: realloc failed: Cannot allocate memory gmake[1]: *** [libWebCore.la] Error 70 gmake[1]: Leaving directory `/usr/ports/www/webkit-gtk2/work/webkit-1.8.3' gmake: *** [all] Error 2 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** [do-build] Error code 1 Stop in /usr/ports/www/webkit-gtk2. *** [build] Error code 1 Stop in /usr/ports/www/webkit-gtk2. === i checked my kernel shared memory and it seem to be pretty big by default: root@giraffe:/usr/ports # sysctl -a | grep -E "shmmax|shmall" kern.ipc.shmall: 131072 kern.ipc.shmmax: 536870912 thanks help. ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 Mar 2014, at 16:41, Rui Paulo wrote: > On 6 Mar 2014, at 23:30, David Xu 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? Yes, definitely. Building FreeBSD on other platforms is one of the requests we get very often from embedded systems vendors. Cheap virtualisation has made it less urgent (they can just stick a FreeBSD VirtualBox VM on their workstations), but it's definitely something we'd like eventually. To my knowledge, no one is working on it, but we should aim to make life easy for whoever does... David ___ 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
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 time for the transition. We are talking about brute force attacks and GPU development is relatively predicable. And lets not lose sight of the fact that we are only talking about limited mitigation after an attacker has gained root access, not front-line security. > I suppose if you really were paranoid about the hash what you would > want is an ability to set an expiration time on the hash algo itself > where authentication using that hash always fails after the > expiration time. Whenever I've been required to change passwords it's always been imposed immediately after a login. Just locking-out an account sounds very heavy-handed to me. It seems like it would be trivial to extract a list of accounts using the old-style hashes from master.passwd - at least that way you can send them an email. ___ 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
On Friday, March 07, 2014 10:34:40 am Tom Evans wrote: > On Fri, Mar 7, 2014 at 2:13 PM, 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 expiration of non-migrated accounts gives a > >> > false sense of security. Any admin worth his/her salt is going to want > >> > the > >> > option of enforcing that sort of policy along with the transparent > >> > update. > >> > They should really be implemented together is all. > >> > >> Account expiration and password expiration are already present. There is > >> absolutely no reason that password algorithm upgrade should be tied in any > >> way > >> to expiration. A transparent algorithm upgrade as proposed is *far* better > >> than the forced password change method that is commonly employed. If the > >> administrator wants to force all accounts to migrate by a set deadline, we > >> already have the expiration facilities in place to accomplish that. > >> Expiring > >> accounts that have not been used in a long time, regardless of algorithm > >> changes, should be part of general housekeeping and may be covered by > >> existing > >> policy. Password expiration serves no purpose, EVER. Password expiration > >> encourages users to choose bad passwords because they are throwaway items. > >> > >> Bruce states it well enough I need not elaborate further > >> https://www.schneier.com/blog/archives/2010/11/changing_passwo.html > >> > >> Anyone who fails to understand the above should NOT be an administrator. > > > > I think you failed to understand my point. 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. To that end, > > they may wish to limit the time window for which they accept hashes > > generated > > using the suspect algorithm. This is separate (I believe) from the issue > > Bruce > > raises above. For example, in this case, the administrator is perfectly > > happy > > for the actual plaintext to remain the same, the administrator simply wants > > to > > enforce the new hash. > > > > As far as I can tell, there is nothing in /etc/login.conf to allow for > > automatic > > account expiration if an account is idle for more than N days. > > > > OTOH, even that is probably not sufficient for the original case since a > > user might > > login with a different authentication method (e.g. ssh key) that would > > reset the > > idle timer without updating the hash. > > > > I suppose if you really were paranoid about the hash what you would want is > > an > > ability to set an expiration time on the hash algo itself where > > authentication > > using that hash always fails after the expiration time. This doesn't > > necessarily > > expire the entire account (e.g. ssh key auth would still work), though it > > might > > be a bit surprising to the user to find that the next time they attempt to > > use > > password authentication it doesn't work. (You would at least want a warning > > about the hash being expired on login via another mechanism.) > > > > All of this is orthogonal to adding a way to upgrade hashes. Yes, all > of the points you mentioned are relevant to general password security, > but doesn't explain why a feature that provides transparent hash > upgrades cannot be added without first adding the features you are > asking for. What I didn't say is that I think adding hash expirations is much more of an edge case and not very useful generically, so probably not worth the hassle. Also, I had originally suggested expiring accounts, but expiring accounts isn't really a good proxy for expiring hashes. Anyway, I think the original idea is good so long as it is optional. -- John Baldwin ___ 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"
ipfw: fetch doesn't reach ftp://fttp.sites.foo
Recently I swaitched from pf to ipfw on some CURRENT boxes and for convenience I used the "workstation" predefinition of FreeBSD. But with that change, all access of ports via fetch located at ftp-sites stopped passing the filter. Even switching to "open" doesn't help and this is confusing me. The CURRENT box in question is passing its traffic within a LAN through a gateway running also FreeBSD CURRENT, but with pf. The gateway is performing NAT. As long as the failing client behind the gateway system is using pf as the filter, the traffic for ftp seems to pass through. On the gateway with pf as the default filter, the ports fetching via ftp-site their sources perform without problems. What is up with IPFW? Is their a solution? I tried to search google for "freebsd ipfw ftp" but I didn't find anything suitable targeting my problem or any problem of that kind. Thanks in adavance, Oliver signature.asc Description: PGP signature
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 Mar 2014, at 10:38, David Chisnall wrote: > On 7 Mar 2014, at 16:41, Rui Paulo wrote: > >> On 6 Mar 2014, at 23:30, David Xu 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? > > Yes, definitely. Building FreeBSD on other platforms is one of the requests > we get very often from embedded systems vendors. Cheap virtualisation has > made it less urgent (they can just stick a FreeBSD VirtualBox VM on their > workstations), but it's definitely something we'd like eventually. To my > knowledge, no one is working on it, but we should aim to make life easy for > whoever does... I guess I should clarify: I wasn’t talking about cross building in general, but specifically on Windows. It’s far easier to setup a case-sensitive file system on OS X and cross build FreeBSD from there than it is on Windows. I’m not even sure NetBSD builds on Windows with Cygwin anymore. Warner was working on building FreeBSD from OS X, IIRC. -- Rui Paulo ___ 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
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 > This looks like what we wanted. In the feedback you talked about some changes to your patch required to make it work, is there any progress on those? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ipfw: fetch doesn't reach ftp://fttp.sites.foo
On 2014-03-07 13:57, O. Hartmann wrote: > > Recently I swaitched from pf to ipfw on some CURRENT boxes and for > convenience I used the > "workstation" predefinition of FreeBSD. But with that change, all access of > ports via > fetch located at ftp-sites stopped passing the filter. > > Even switching to "open" doesn't help and this is confusing me. > > The CURRENT box in question is passing its traffic within a LAN through a > gateway running > also FreeBSD CURRENT, but with pf. The gateway is performing NAT. As long as > the failing > client behind the gateway system is using pf as the filter, the traffic for > ftp seems to > pass through. On the gateway with pf as the default filter, the ports > fetching via > ftp-site their sources perform without problems. > > What is up with IPFW? > > Is their a solution? I tried to search google for "freebsd ipfw ftp" but I > didn't find > anything suitable targeting my problem or any problem of that kind. > > > Thanks in adavance, > > Oliver > What error does fetch give? Is it having problems with DNS, connection to the FTP site, or just making the FTP DATA connection? Have you tried with 'passive' mode on/off? -- Allan Jude signature.asc Description: OpenPGP digital signature
bsnmp lm75 module
Hello,
I've written a bsnmp module to export the lm75 sensor's temperature
(and some other data) over SNMP.
With this module it is simple and easy to monitor the temperature of
rooms and other devices over the network with help of a RPi, a BBB or
others.
This is my first module for bsnmp, so i would appreciate if someone
more clueful about it could take a look (can i just pick any free MIB
?)
The lm75 kernel driver is the same published on
http://lists.freebsd.org/pipermail/freebsd-embedded/2013-November/002195.html
I'll publish an updated version soon (for the lm75 kernel driver)
which include a man page and support for non FDT systems.
The SNMP data usually looks like: http://pastebin.com/cHYYBY1R
It includes the number of sensors on system, the driver name, the
compat string, the i2c bus and address and, sure, the sensor
temperature.
Cheers,
Luiz
Index: etc/snmpd.config
===
--- etc/snmpd.config(revision 262860)
+++ etc/snmpd.config(working copy)
@@ -296,6 +296,12 @@
#begemotSnmpdModulePath."bridge" = "/usr/lib/snmp_bridge.so"
#
+# LM75 Sensor module
+# This requires the mibII module.
+#
+#begemotSnmpdModulePath."lm75" = "/usr/lib/snmp_lm75.so"
+
+#
# Wireless module
# This requires the mibII module.
#
Index: usr.sbin/bsnmpd/modules/Makefile
===
--- usr.sbin/bsnmpd/modules/Makefile(revision 262860)
+++ usr.sbin/bsnmpd/modules/Makefile(working copy)
@@ -12,6 +12,7 @@
snmp_bridge \
snmp_hast \
snmp_hostres \
+ snmp_lm75 \
snmp_mibII \
snmp_target \
snmp_usm \
Index: usr.sbin/bsnmpd/modules/snmp_lm75/BEGEMOT-LM75-MIB.txt
===
--- usr.sbin/bsnmpd/modules/snmp_lm75/BEGEMOT-LM75-MIB.txt (revision 0)
+++ usr.sbin/bsnmpd/modules/snmp_lm75/BEGEMOT-LM75-MIB.txt (working copy)
@@ -0,0 +1,160 @@
+--
+-- Copyright (c) 2014 Luiz Otavio O Souza
+-- All rights reserved.
+--
+-- Redistribution and use in source and binary forms, with or without
+-- modification, are permitted provided that the following conditions
+-- are met:
+-- 1. Redistributions of source code must retain the above copyright
+--notice, this list of conditions and the following disclaimer.
+-- 2. Redistributions in binary form must reproduce the above copyright
+--notice, this list of conditions and the following disclaimer in the
+--documentation and/or other materials provided with the distribution.
+--
+-- THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+-- ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+-- SUCH DAMAGE.
+--
+-- $FreeBSD$
+--
+
+BEGEMOT-LM75-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+Counter64, Integer32
+ FROM SNMPv2-SMI
+TEXTUAL-CONVENTION, RowStatus
+ FROM SNMPv2-TC
+begemot
+ FROM BEGEMOT-MIB;
+
+begemotLoos MODULE-IDENTITY
+LAST-UPDATED "20140224Z"
+ORGANIZATION "FreeBSD"
+CONTACT-INFO
+ " Luiz Otavio O Souza
+
+Postal:N/A
+
+Fax: N/A
+
+E-Mail:l...@freebsd.org"
+DESCRIPTION
+ "The Begemot MIB for reading lm75 sensors data."
+REVISION "20140224Z"
+DESCRIPTION
+ "Initial revision."
+::= { begemot 400 }
+
+begemotLm75Objects OBJECT IDENTIFIER ::= { begemotLm75 1 }
+
+-- -- --
+-- Configuration parameters
+-- -- --
+
+lm75Sensor OBJECT IDENTIFIER ::= { begemotlm75Objects 1 }
+
+lm75SensorsOBJECT-TYPE
+SYNTAX Integer32
+MAX-ACCESS read-only
+STATUS current
+DESCRIPTION
+ "Number of LM75 sensors in the system."
+::= { lm75Sensors 1 }
+
+-- -- --
+-- TempSensor Table
+-- -- --
+lm75SensorTable OBJECT-TYPE
+SYNTAX SEQUENCE OF Lm75SensorEntry
+MAX-ACCESS not-accessible
+STATUS current
+DESCRIPTION
+ "A table containing information about all temperature sensors."
+::= { begemotLm75Object
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 11:50 AM, Rui Paulo wrote: > On 7 Mar 2014, at 10:38, David Chisnall wrote: > >> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >> >>> On 6 Mar 2014, at 23:30, David Xu 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? >> >> Yes, definitely. Building FreeBSD on other platforms is one of the requests >> we get very often from embedded systems vendors. Cheap virtualisation has >> made it less urgent (they can just stick a FreeBSD VirtualBox VM on their >> workstations), but it's definitely something we'd like eventually. To my >> knowledge, no one is working on it, but we should aim to make life easy for >> whoever does... > > I guess I should clarify: I wasn’t talking about cross building in general, > but specifically on Windows. It’s far easier to setup a case-sensitive file > system on OS X and cross build FreeBSD from there than it is on Windows. I’m > not even sure NetBSD builds on Windows with Cygwin anymore. > > Warner was working on building FreeBSD from OS X, IIRC. When I worked at Cisco in 2008, yes. That work went approximately no-where when I hit a huge snag in building gdb using static configurations for FreeBSD, but on a OS X host and the differences between them mattering. Warner ___ 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: ipfw: fetch doesn't reach ftp://fttp.sites.foo
On Fri, 07 Mar 2014 15:33:39 -0500 Allan Jude wrote: > On 2014-03-07 13:57, O. Hartmann wrote: > > > > Recently I swaitched from pf to ipfw on some CURRENT boxes and for > > convenience I used > > the "workstation" predefinition of FreeBSD. But with that change, all > > access of ports > > via fetch located at ftp-sites stopped passing the filter. > > > > Even switching to "open" doesn't help and this is confusing me. > > > > The CURRENT box in question is passing its traffic within a LAN through a > > gateway > > running also FreeBSD CURRENT, but with pf. The gateway is performing NAT. > > As long as > > the failing client behind the gateway system is using pf as the filter, the > > traffic > > for ftp seems to pass through. On the gateway with pf as the default > > filter, the > > ports fetching via ftp-site their sources perform without problems. > > > > What is up with IPFW? > > > > Is their a solution? I tried to search google for "freebsd ipfw ftp" but I > > didn't find > > anything suitable targeting my problem or any problem of that kind. > > > > > > Thanks in adavance, > > > > Oliver > > > > What error does fetch give? Is it having problems with DNS, connection > to the FTP site, or just making the FTP DATA connection? Have you tried > with 'passive' mode on/off? > The box doesn't have problems contacting any DNS. Fetch gives the shown "errors" or simple timeouts. Either manually or via portmaster to update ports like the one shown below. The very same port has no problems on the system having pf instead of ipfw. I will switch back to pf on the box in question to check whether the choice of firewall really makes the difference. This is what I get when seeting passive mode (it doesn't change anything from "active" mode): root@thor: [pciids] setenv FTP_PASSIVE_MODE YES root@thor: [pciids] make fetch ===> License BSD3CLAUSE GPLv2 GPLv3 accepted by the user ===> pciids-20140301 depends on file: /usr/local/sbin/pkg - found => pciids-20140301.tar.xz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz fetch: http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: Not Found => Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: No route to host => Attempting to fetch ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz fetch: ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: No route to host => Attempting to fetch ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz fetch: ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: No route to host => Attempting to fetch ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz fetch: transfer timed out signature.asc Description: PGP signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 This looks like what we wanted. In the feedback you talked about some changes to your patch required to make it work, is there any progress on those? Derek's patches worked perfectly for our needs, but we're the sort of people who use vipw and our own utilities for user management. It wasn't until later that we discovered at least one other file would need patching to satisfy everyone. We didn't want to employ the same copy-pasta method, so we asked for feedback about our proposed alternative. secteam@, do you have any comments? Before we put any more work into this, we want to be sure that our proposal is an acceptable one. -- A.J. Kehoe IV (Nanoman) | /"\ ASCII Ribbon Campaign Nanoman's Company | \ / - No HTML/RTF in E-mail E-mail: nano...@nanoman.ca | X- No proprietary attachments WWW: http://www.nanoman.ca/ | / \ - Respect for open standards smime.p7s Description: S/MIME cryptographic signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
-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 (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 >>> >> >> This looks like what we wanted. In the feedback you talked about >> some changes to your patch required to make it work, is there any >> progress on those? > > Derek's patches worked perfectly for our needs, but we're the sort > of people who use vipw and our own utilities for user management. > It wasn't until later that we discovered at least one other file > would need patching to satisfy everyone. We didn't want to employ > the same copy-pasta method, so we asked for feedback about our > proposed alternative. > > secteam@, do you have any comments? Before we put any more work > into this, we want to be sure that our proposal is an acceptable > one. > Did you mean adding rounds capability, or transparent upgrade of crypt() algorithms, or both? I need some time to digest the whole transparent upgrade idea but in general I think it's good. 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. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTGkLzAAoJEJW2GBstM+nsaVoP/017iARGzd++lCsfqyFDozGk nXJjatlrIcRjrbCmVRT0lsHiK/hoYJ4zZPeOu8EXU1Qs0/wggGHYePX7+zEVob2S YCxhqUOdG/jqrHnH8bljzWE/OtI7Y4PvFOLpsWkOE/uulssQfGDMSy8WJzFriqzv GXjAEyFrGXCT29gW6ozTRfDfPSOfd4MhwewbMYAUykSqucMfkG4FaDAgLxv/XdRi YmLQZuxxTzEqMYanZGq/0e5CvOwOuncd0aVxncJC8ZRcsHs5cqbzcyDkkRwvw/YU g1OsLXiO08zej0rOz1E4pud8O6q3unG5dNcz9Y96oNo0fJONMrk9IetCUCHBsR8N eyWJQyHL7wwwNlC5k8U9cOnsL3zxBv54N6bfWuWNNDpJmNrvgMr9LdPso+AX0gLD y4RhVJeLCQbLrkQawoM1+Ki5N0mQibk9BBGXH/ZPScP1pNqVt9tqXp94N5ZPLV54 Uu4cn/2uKjtTjl76YFlCTvfwwiuWgds1k6CnKZIW8luOp4cG5XOoOSztONqWr6S/ yd7SLDV4f8PC7Fi1iSkSuVW5MYz1I7RRVR1Z27oV3e3UwXwIgqRjHJawNZqIgVe1 4lk84+fm75ULLfiA6bgkMCjylyWHCzrdOQt/Zx+0vyZOer5x2p4gZmnYAyV2EQIP TM611j1UES6OUGFkfbWa =4Qur -END PGP SIGNATURE- ___ 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: ipfw: fetch doesn't reach ftp://fttp.sites.foo
On 2014-03-07 16:55, O. Hartmann wrote: > On Fri, 07 Mar 2014 15:33:39 -0500 > Allan Jude wrote: > >> On 2014-03-07 13:57, O. Hartmann wrote: >>> >>> Recently I swaitched from pf to ipfw on some CURRENT boxes and for >>> convenience I used >>> the "workstation" predefinition of FreeBSD. But with that change, all >>> access of ports >>> via fetch located at ftp-sites stopped passing the filter. >>> >>> Even switching to "open" doesn't help and this is confusing me. >>> >>> The CURRENT box in question is passing its traffic within a LAN through a >>> gateway >>> running also FreeBSD CURRENT, but with pf. The gateway is performing NAT. >>> As long as >>> the failing client behind the gateway system is using pf as the filter, the >>> traffic >>> for ftp seems to pass through. On the gateway with pf as the default >>> filter, the >>> ports fetching via ftp-site their sources perform without problems. >>> >>> What is up with IPFW? >>> >>> Is their a solution? I tried to search google for "freebsd ipfw ftp" but I >>> didn't find >>> anything suitable targeting my problem or any problem of that kind. >>> >>> >>> Thanks in adavance, >>> >>> Oliver >>> >> >> What error does fetch give? Is it having problems with DNS, connection >> to the FTP site, or just making the FTP DATA connection? Have you tried >> with 'passive' mode on/off? >> > The box doesn't have problems contacting any DNS. > > Fetch gives the shown "errors" or simple timeouts. Either manually or via > portmaster to > update ports like the one shown below. > > The very same port has no problems on the system having pf instead of ipfw. > > I will switch back to pf on the box in question to check whether the choice > of firewall > really makes the difference. > > This is what I get when seeting passive mode (it doesn't change anything from > "active" > mode): > > root@thor: [pciids] setenv FTP_PASSIVE_MODE YES > > root@thor: [pciids] make fetch > ===> License BSD3CLAUSE GPLv2 GPLv3 accepted by the user > ===> pciids-20140301 depends on file: /usr/local/sbin/pkg - found > => pciids-20140301.tar.xz doesn't seem to exist in /usr/ports/distfiles/. > => Attempting to fetch > http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz > fetch: > http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: > Not Found => Attempting to fetch > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz > fetch: > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: > No route to host => Attempting to fetch > ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz > fetch: > ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: > No route to host => Attempting to fetch > ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz > fetch: > ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz: > No route to host => Attempting to fetch > ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz > fetch: transfer timed out > 'no route to host' suggests it might be trying to do ipv6 -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 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 >>> >>> This looks like what we wanted. In the feedback you talked about >>> some changes to your patch required to make it work, is there any >>> progress on those? > >> Derek's patches worked perfectly for our needs, but we're the sort >> of people who use vipw and our own utilities for user management. >> It wasn't until later that we discovered at least one other file >> would need patching to satisfy everyone. We didn't want to employ >> the same copy-pasta method, so we asked for feedback about our >> proposed alternative. > >> secteam@, do you have any comments? Before we put any more work >> into this, we want to be sure that our proposal is an acceptable >> one. > > > Did you mean adding rounds capability, or transparent upgrade of > crypt() algorithms, or both? There are 2 separate but related threads 1) specify rounds for crypt() 2) transparent upgrade of crypt() algo (or more likely just number of rounds) > > I need some time to digest the whole transparent upgrade idea but in > general I think it's good. > > 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. > > Cheers, > -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 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 > > >>> > >>> This looks like what we wanted. In the feedback you talked about > >>> some changes to your patch required to make it work, is there any > >>> progress on those? > > > >> Derek's patches worked perfectly for our needs, but we're the sort > >> of people who use vipw and our own utilities for user management. > >> It wasn't until later that we discovered at least one other file > >> would need patching to satisfy everyone. We didn't want to employ > >> the same copy-pasta method, so we asked for feedback about our > >> proposed alternative. > > > >> secteam@, do you have any comments? Before we put any more work > >> into this, we want to be sure that our proposal is an acceptable > >> one. > > > > > > Did you mean adding rounds capability, or transparent upgrade of > > crypt() algorithms, or both? > > There are 2 separate but related threads > > 1) specify rounds for crypt() > > 2) transparent upgrade of crypt() algo (or more likely just number of > rounds) Can't the two be merged... where 2 becomes a flag in login.conf instead of an algo fetch, and then if it's true, it does the algo fetch from 1? I really would like us to get 1 in, and then on boot dynamicly adjust the number of rounds depending upon CPU usage... obviously, a flag will adjust how long/many rounds the admin wants, but it would allow an automatic increase in security as faster CPUs are used... Anyways, how many people are still using passwords instead of ssh keys? Setting the time to be something like 100ms may seem long, but considering few people should be using passwords these days, it's less of an issue... Xin Li, if you need help reviewing, testing, let me know... > > I need some time to digest the whole transparent upgrade idea but in > > general I think it's good. > > > > 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. -- 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"
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 March 2014 13:50, Rui Paulo wrote: > On 7 Mar 2014, at 10:38, David Chisnall wrote: > >> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >> >>> On 6 Mar 2014, at 23:30, David Xu 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? >> >> Yes, definitely. Building FreeBSD on other platforms is one of the requests >> we get very often from embedded systems vendors. Cheap virtualisation has >> made it less urgent (they can just stick a FreeBSD VirtualBox VM on their >> workstations), but it's definitely something we'd like eventually. To my >> knowledge, no one is working on it, but we should aim to make life easy for >> whoever does... > > I guess I should clarify: I wasn’t talking about cross building in general, > but specifically on Windows. It’s far easier to setup a case-sensitive file > system on OS X and cross build FreeBSD from there than it is on Windows. Over 50% of the people that come to FreeBSD.org run windows. If it is possible to support building on windows, we should try. -- Eitan Adler ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 2014-03-07 18:12, Eitan Adler wrote: > On 7 March 2014 13:50, Rui Paulo wrote: >> On 7 Mar 2014, at 10:38, David Chisnall wrote: >> >>> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >>> On 6 Mar 2014, at 23:30, David Xu 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? >>> >>> Yes, definitely. Building FreeBSD on other platforms is one of the >>> requests we get very often from embedded systems vendors. Cheap >>> virtualisation has made it less urgent (they can just stick a FreeBSD >>> VirtualBox VM on their workstations), but it's definitely something we'd >>> like eventually. To my knowledge, no one is working on it, but we should >>> aim to make life easy for whoever does... >> >> I guess I should clarify: I wasn’t talking about cross building in general, >> but specifically on Windows. It’s far easier to setup a case-sensitive file >> system on OS X and cross build FreeBSD from there than it is on Windows. > > Over 50% of the people that come to FreeBSD.org run windows. If it is > possible to support building on windows, we should try. > Even well shy of 'building' on windows, I do most of my docs work on windows. I even wrote most of the new code for bsdinstall on a windows machine. Being able to checkout the svn tree and work on it on my existing work station is nice. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 4:12 PM, Eitan Adler wrote: > On 7 March 2014 13:50, Rui Paulo wrote: >> On 7 Mar 2014, at 10:38, David Chisnall wrote: >> >>> On 7 Mar 2014, at 16:41, Rui Paulo wrote: >>> On 6 Mar 2014, at 23:30, David Xu 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? >>> >>> Yes, definitely. Building FreeBSD on other platforms is one of the >>> requests we get very often from embedded systems vendors. Cheap >>> virtualisation has made it less urgent (they can just stick a FreeBSD >>> VirtualBox VM on their workstations), but it's definitely something we'd >>> like eventually. To my knowledge, no one is working on it, but we should >>> aim to make life easy for whoever does... >> >> I guess I should clarify: I wasn’t talking about cross building in general, >> but specifically on Windows. It’s far easier to setup a case-sensitive file >> system on OS X and cross build FreeBSD from there than it is on Windows. > > Over 50% of the people that come to FreeBSD.org run windows. If it is > possible to support building on windows, we should try. The big issue isn’t case sensitivity or file names ending in dot. The real issue is that our build just isn’t setup for this at the moment and it would be a big lift to make it work at all. Sure, go ahead and fix this minor flea-bite of an issue, but there are several large elephant-sized issues before we could have even a tiny chance of doing this... Warner ___ 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
-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 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. My suggestion is that we either have: a) passwd_format and passwd_round (so that they don't conflict), or 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. > 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. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTGmYMAAoJEJW2GBstM+nsDJ8QAJ+SM9WuRCXo1KYERj+/NJsC VoP8psjZDZ7+hGOnG7iSwREYTLpxSEAw+sPnIhMgEy1Tg5jCcPvnIhCN/n+XPvaR HG0o0TdTXL5ZVU4HyKuhNH6JGF9sWWua7Ki/jFguqE+1rdmivcbhrHMZNqOy8Djc N/dnoCD/eN8K2/FiwP+KjTsYeSyisKFMyiGimQNcuPA7boF4ZBgJmmJqPASHzO9M DVccoVPrDUip/6BdM+CNx/rNTry1sW3lMFSAuJkx+LENgulbhFz5R0aRGglzwGnJ LocXVCZlTv0QB37qp9VIHCtTO5n8GxOx43dEtgjWF1cjDs+s+iKjEylX8NguUi0x SjYu5WOw8xXNdE48QtqpT0N5aHSw9+CCwbrocGaOVYy11voGzo+r3C7jXprhQl8a pgeiXH5pyBpo9Eh7+/aZdN3WcBjpaOVDnX8We7A9my1lVjxyuLXFyhC3q2OqUjvl dX4ywKIjiFHSOz0ivzi+uQPx6PD05UuyrWUDING2PvMD/oMtg/hHbR5IxOHdmgPq j7brHNOk7gxu1f/NFft/yfJAKem6JXjlX68z6/9jMrwxZ8jwTWWAtHrVBjo9/u2i 7ShSZlsEi62GewoIKRRVKvKmdX7Xl+Of/p/DZMTNGCJ9K5NnhEnLKWSp+I5VF0LN fVQkTqpRaXglMVa/iRkG =xSx1 -END PGP SIGNATURE- ___ 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
-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, 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 >> > > >> This looks like what we wanted. In the feedback you talked about > some changes to your patch required to make it work, is > there any progress on those? >>> Derek's patches worked perfectly for our needs, but we're the sort of people who use vipw and our own utilities for user management. It wasn't until later that we discovered at least one other file would need patching to satisfy everyone. We didn't want to employ the same copy-pasta method, so we asked for feedback about our proposed alternative. >>> secteam@, do you have any comments? Before we put any more work into this, we want to be sure that our proposal is an acceptable one. >>> >>> >>> Did you mean adding rounds capability, or transparent upgrade >>> of crypt() algorithms, or both? >> >> There are 2 separate but related threads >> >> 1) specify rounds for crypt() >> >> 2) transparent upgrade of crypt() algo (or more likely just >> number of rounds) > > Can't the two be merged... where 2 becomes a flag in login.conf > instead of an algo fetch, and then if it's true, it does the algo > fetch from 1? > > I really would like us to get 1 in, and then on boot dynamicly > adjust the number of rounds depending upon CPU usage... obviously, > a flag will adjust how long/many rounds the admin wants, but it > would allow an automatic increase in security as faster CPUs are > used... Or by the installer/a tool that gets run when doing mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster after installation, and we can probably just write in the configuration anyway? Personally I'm not a big fan of making it something that changes over time: the attacker may do offline attacker than doing it on the victim system that revealed the salted hashes, so how fast the system CPU runs doesn't really matter, except for how long a system administrator is willing to have the user to wait. > Anyways, how many people are still using passwords instead of ssh > keys? Setting the time to be something like 100ms may seem long, > but considering few people should be using passwords these days, > it's less of an issue... I'm currently using SSH key plus Google Authenticator for my systems but all remote login via password is disabled. I am aware of, however, many people who refuse to use SSH key authentication because they don't want to carry their keys, which is a bad idea but they do it anyways. > Xin Li, if you need help reviewing, testing, let me know... Will do and thanks for the offer! Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBCgAGBQJTGme0AAoJEJW2GBstM+nsXnkQAIYplCr5wMtENLYMQCDSrOFJ 7oxKbW2Iy1qPbbrjAb6mG0TY4ugJu2T6Sg6Wp1B+um2sWqWkNMr+8auHokwuB8+1 8NpnbcZarFvmA5tgVEsh+JcAJF1qZRFQDku+DbL9f/ZXFn/4CtmLkw5NS/kIKf/0 TIeXykNie5nFCS8ifT5Ai7vEHImOTwS4OEVzXoTQSdFGuLnHrToCnV7LpOK2ceIo ssZ/0Go49tSzW8y3u2a0TZYTqMnh+0EzQFusWkulyCIam0NYjYON/3UY0/TpRgZd ik2QLqKXaMZBPmi4EsmgpQr97MS0PRag4lahZZad2CckZmhiwWrHLyECf0Xk5i1W +ACqSfJAzq+NeyDBW05y31qALeyUhm7+ALolSMDFkQMj5B7ra8qnQsbXVyG+DLmg itpCWfXUpKPxclkvirnDQx89BE1MOYGYBbw69IR5NWcvF3f4EF177xplwAMjHhn5 EXUVIeTwjHYoYgMiZKX8aFgyNR2EX/g6JvZS8236HUbskLQl5AAKM0RA4aQkAFGW 206DYokJW3TnXNArm8kKJCZrYAJb17XyzN6HcY89N+GA0oEkehy2qyQiBVqtpjgh 6WsslScxAnQM3LG84un98cdipOWwQerTwfeji1yqfmik5oNuCm4D/Jlt6rvJBFLb S5fUd1BQv+0woAKndGhb =rCdB -END PGP SIGNATURE- ___ 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: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On 7 March 2014 15:25, Warner Losh wrote: > > On Mar 7, 2014, at 4:12 PM, Eitan Adler wrote: > >> On 7 March 2014 13:50, Rui Paulo wrote: >>> On 7 Mar 2014, at 10:38, David Chisnall wrote: >>> On 7 Mar 2014, at 16:41, Rui Paulo wrote: > On 6 Mar 2014, at 23:30, David Xu 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? Yes, definitely. Building FreeBSD on other platforms is one of the requests we get very often from embedded systems vendors. Cheap virtualisation has made it less urgent (they can just stick a FreeBSD VirtualBox VM on their workstations), but it's definitely something we'd like eventually. To my knowledge, no one is working on it, but we should aim to make life easy for whoever does... >>> >>> I guess I should clarify: I wasn't talking about cross building in general, >>> but specifically on Windows. It's far easier to setup a case-sensitive >>> file system on OS X and cross build FreeBSD from there than it is on >>> Windows. >> >> Over 50% of the people that come to FreeBSD.org run windows. If it is >> possible to support building on windows, we should try. > > The big issue isn't case sensitivity or file names ending in dot. The real > issue is that our build just isn't setup for this at the moment and it would > be a big lift to make it work at all. Sure, go ahead and fix this minor > flea-bite of an issue, but there are several large elephant-sized issues > before we could have even a tiny chance of doing this... > are those issues documented anywhere? :) -a ___ 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
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, 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 > >> > > > > > >> > This looks like what we wanted. In the feedback you talked about > > some changes to your patch required to make it work, is > > there any progress on those? > >>> > Derek's patches worked perfectly for our needs, but we're the > sort of people who use vipw and our own utilities for user > management. It wasn't until later that we discovered at least > one other file would need patching to satisfy everyone. We > didn't want to employ the same copy-pasta method, so we asked > for feedback about our proposed alternative. > >>> > secteam@, do you have any comments? Before we put any more > work into this, we want to be sure that our proposal is an > acceptable one. > >>> > >>> > >>> Did you mean adding rounds capability, or transparent upgrade > >>> of crypt() algorithms, or both? > >> > >> There are 2 separate but related threads > >> > >> 1) specify rounds for crypt() > >> > >> 2) transparent upgrade of crypt() algo (or more likely just > >> number of rounds) > > > > Can't the two be merged... where 2 becomes a flag in login.conf > > instead of an algo fetch, and then if it's true, it does the algo > > fetch from 1? > > > > I really would like us to get 1 in, and then on boot dynamicly > > adjust the number of rounds depending upon CPU usage... obviously, > > a flag will adjust how long/many rounds the admin wants, but it > > would allow an automatic increase in security as faster CPUs are > > used... > > Or by the installer/a tool that gets run when doing > mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster > after installation, and we can probably just write in the > configuration anyway? It's just easier to throw something into /etc/rc.d w/ an enable/disable switch than it is to update one/all of those tools to do it... If you update only one, then the users of the other tools won't get the benefit.. Or someone forgets to update the other tool... or we could detect that the CPU is the same, and keep the previous results... > Personally I'm not a big fan of making it something that changes over > time: the attacker may do offline attacker than doing it on the victim > system that revealed the salted hashes, so how fast the system CPU > runs doesn't really matter, except for how long a system administrator > is willing to have the user to wait. This is my point, there is currently the default number of rounds which provides basic security, but if the sysadmin wants to provide additional security, they can do so, either by fixing the number of rounds to something larger, or by providing a time they are willing to spend to do the work... I'm tired of default security parameters not being ideal, or secure enough... Most sysadmins won't go and increase the number of rounds since they don't know enough to (or couldn't before the other patch was even presented), but they will continue to install FreeBSD on ever faster machines, yet our only response so far is to switch algorithms, instead of including more rounds, etc... This feature would allow us to provide better security out of the box, and continue to scale our security as time goes on... 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, ~+/-10%... code available at: https://www.funkthat.com/~jmg/testcrypt.c Most people won't notice a 50ms delay on login, yet it'll give us a 10x security benefit... Just for fun, compare how long it takes to run sleep .005 and sleep .05 from the command line... Heck I think most people would be fine w/ 100ms delay.. try it.. :) and if they don't mind something similar to how geli does it, it could be as long as 2 seconds, giving a 500x benefit! :) and with the auto recrypt path, we could automatically "
Re: warning: filename ends with '.', which is not allowed on Windows: 'tools/test/sort/bigtest/q-1.024.003.'
On Mar 7, 2014, at 6:30 PM, Adrian Chadd wrote: > On 7 March 2014 15:25, Warner Losh wrote: >> >> On Mar 7, 2014, at 4:12 PM, Eitan Adler wrote: >> >>> On 7 March 2014 13:50, Rui Paulo wrote: On 7 Mar 2014, at 10:38, David Chisnall wrote: > On 7 Mar 2014, at 16:41, Rui Paulo wrote: > >> On 6 Mar 2014, at 23:30, David Xu 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? > > Yes, definitely. Building FreeBSD on other platforms is one of the > requests we get very often from embedded systems vendors. Cheap > virtualisation has made it less urgent (they can just stick a FreeBSD > VirtualBox VM on their workstations), but it's definitely something we'd > like eventually. To my knowledge, no one is working on it, but we should > aim to make life easy for whoever does... I guess I should clarify: I wasn't talking about cross building in general, but specifically on Windows. It's far easier to setup a case-sensitive file system on OS X and cross build FreeBSD from there than it is on Windows. >>> >>> Over 50% of the people that come to FreeBSD.org run windows. If it is >>> possible to support building on windows, we should try. >> >> The big issue isn't case sensitivity or file names ending in dot. The real >> issue is that our build just isn't setup for this at the moment and it would >> be a big lift to make it work at all. Sure, go ahead and fix this minor >> flea-bite of an issue, but there are several large elephant-sized issues >> before we could have even a tiny chance of doing this... >> > > are those issues documented anywhere? :) I believe I talked to some notes at a developer’s summit 5 years ago or so on what I found. The hardest part is bootstrapping the tools needed in the build. Warner ___ 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
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 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. > > My suggestion is that we either have: > > a) passwd_format and passwd_round (so that they don't conflict), or > > b) extend passwd_format in a compatible manner to allow specifying a > round, or, Couldn't we merge passwd_format and passwd_modular into one, being either the name, or the begining salt string? since the salt string always begins w/ $, they wouldn't conflict, and could be properly resolved... > c) make passwd_format and passwd_modular conflict so we don't silently > accept it and instead bail out when doing pwd_mkdb. > > > 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. So, the current code in pam_unix is: login_setcryptfmt which calls crypt_set_format as necessary makesalt crypt So, we could expand crypt_set_format to understand the two, and keep a copy of the rounds data, or we could expose makesalt into maybe crypt_makesalt (this would be nice) w/ an optional arg that provides either the name or the beging salt string w/ rounds, i.e. what passwd_format would contain... and update pam_unix and friends to use this... This last method would make login_setcryptfmt unnecessary, so I'm not sure how good/bad that is.. -- 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"
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 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. 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? -- A.J. Kehoe IV (Nanoman) | /"\ ASCII Ribbon Campaign Nanoman's Company | \ / - No HTML/RTF in E-mail E-mail: nano...@nanoman.ca | X- No proprietary attachments WWW: http://www.nanoman.ca/ | / \ - Respect for open standards smime.p7s Description: S/MIME cryptographic signature
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
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 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 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 >>> >>> >> This looks like what we wanted. In the feedback you talked about >>> some changes to your patch required to make it work, is >>> there any progress on those? > >> Derek's patches worked perfectly for our needs, but we're the >> sort of people who use vipw and our own utilities for user >> management. It wasn't until later that we discovered at least >> one other file would need patching to satisfy everyone. We >> didn't want to employ the same copy-pasta method, so we asked >> for feedback about our proposed alternative. > >> secteam@, do you have any comments? Before we put any more >> work into this, we want to be sure that our proposal is an >> acceptable one. > > > Did you mean adding rounds capability, or transparent upgrade > of crypt() algorithms, or both? There are 2 separate but related threads 1) specify rounds for crypt() 2) transparent upgrade of crypt() algo (or more likely just number of rounds) >>> >>> Can't the two be merged... where 2 becomes a flag in login.conf >>> instead of an algo fetch, and then if it's true, it does the algo >>> fetch from 1? >>> >>> I really would like us to get 1 in, and then on boot dynamicly >>> adjust the number of rounds depending upon CPU usage... obviously, >>> a flag will adjust how long/many rounds the admin wants, but it >>> would allow an automatic increase in security as faster CPUs are >>> used... >> >> Or by the installer/a tool that gets run when doing >> mergemaster/etcupdate/freebsd-update: it's rare that CPU gets faster >> after installation, and we can probably just write in the >> configuration anyway? > > It's just easier to throw something into /etc/rc.d w/ an enable/disable > switch than it is to update one/all of those tools to do it... If you > update only one, then the users of the other tools won't get the benefit.. > Or someone forgets to update the other tool... or we could detect that > the CPU is the same, and keep the previous results... > >> Personally I'm not a big fan of making it something that changes over >> time: the attacker may do offline attacker than doing it on the victim >> system that revealed the salted hashes, so how fast the system CPU >> runs doesn't really matter, except for how long a system administrator >> is willing to have the user to wait. > > This is my point, there is currently the default number of rounds which > provides basic security, but if the sysadmin wants to provide > additional security, they can do so, either by fixing the number of > rounds to something larger, or by providing a time they are willing > to spend to do the work... > > I'm tired of default security parameters not being ideal, or secure > enough... Most sysadmins won't go and increase the number of rounds > since they don't know enough to (or couldn't before the other patch > was even presented), but they will continue to install FreeBSD on ever > faster machines, yet our only response so far is to switch algorithms, > instead of including more rounds, etc... This feature would allow us > to provide better security out of the box, and continue to scale our > security as time goes on... > > Performance for default, sha512 w/ 5k rounds: > AMD A10-5700 3.4GHz 3.8ms > AMD Opteron 4228 HE 2.8Ghz5.4ms > Intel(R) Xeon(R) X5650 2.67GHz4.0ms > > these times are aprox as the timing varies quite a bit, ~+/-10%... > > code available at: https://www.funkthat.com/~jmg/testcrypt.c > > Most people won't notice a 50ms delay on login, yet it'll give us a > 10x security benefit... Just for fun, compare how long it takes to > run sleep .005 and sleep .05 from the command line... Heck I think > most people would be fine w/ 100ms delay.. try it.. :) > > and if they don't mind something similar to how geli does
Re: Feature Proposal: Transparent upgrade of crypt() algorithms
On Mar 7, 2014, at 10:22 PM, Allan Jude 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, ~+/-10%… And what would that be on a RPi or other embedded device? And do the extra route have a peer-reviewed paper showing the increased strength? > 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. I’m not sure that’s a good idea. Warner ___ 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"
