From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 487 invoked by alias); 3 Feb 2014 18:04:31 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 440 invoked by uid 48); 3 Feb 2014 18:04:27 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/16522] On sha* password generation, select hash rounds to achieve given computation time based on hash computation speed Date: Mon, 03 Feb 2014 18:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.18 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00018.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D16522 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carlos at redhat dot com --- Comment #1 from Carlos O'Donell --- (In reply to David Ja=C5=A1a from comment #0) > In other words cryptsetup/LUKS with default settings gives about 30x bett= er > protection to user password than glibc with default settings. While glibc > must take into account DoS scenarios that do not apply to cryptsetup (such > as attacker trying to log in over as many ssh connections as possible), > these considerations should result in shorter computation time (my guess: > 500 ms instead of 1000) instead of choosing fixed rounds count that actua= lly > provides constantly decreasing security level. Agreed. Do you have a patch to make this work? --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-21042-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Feb 04 02:45:44 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 28917 invoked by alias); 4 Feb 2014 02:45:39 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 28872 invoked by uid 48); 4 Feb 2014 02:45:34 -0000 From: "alvarezp at alvarezp dot ods.org" To: glibc-bugs@sourceware.org Subject: [Bug network/16421] IN6_IS_ADDR_UNSPECIFIED can use undefined s6_addr32 Date: Tue, 04 Feb 2014 02:45:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: network X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: alvarezp at alvarezp dot ods.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-02/txt/msg00019.txt.bz2 Content-length: 1305 https://sourceware.org/bugzilla/show_bug.cgi?id=16421 Octavio Alvarez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alvarezp at alvarezp dot ods.org --- Comment #4 from Octavio Alvarez --- Knowing: 1. Although POSIX only requires s6_addr it doesn't prohibit s6_addr32. But considering: 1. glibc already contains alternate implementations independent of s6_addr32 or other s6_addrNN, 2. it is useful to have _POSIX_C_SOURCE *not* to define s6_addrNN macros as that actually aids in making sure the programs are portable, 3. s6_addr32, although a very good attempt and already used by Linux and BSD, POSIX may take that name in the future, I sent a patch to the ML at: https://sourceware.org/ml/libc-alpha/2014-01/msg00471.html ... a commit based on the patch presented by Sebastien Vincent on April 2013. Currently we #undef the offending macros and redefine them again with the fixed #ifdef condition in a custom header. We are able to make the program compile within the defines of _POSIX_C_SOURCE. -- You are receiving this mail because: You are on the CC list for the bug.