Re: my messages get queued
On Fri, May 9, 2014 at 2:46 PM, Helmut Tessarek tessa...@evermeet.cxwrote: Hello, My messages get queued, but never really processed: May 9 20:26:54 atvie01s sendmail[25243]: s49IQQtF025239: to=dev@apr.apache.org, delay=00:00:26, xdelay=00:00:26, mailer=esmtp, pri=152179, relay=mx1.eu.apache.org. [192.87.106.230], dsn=2.0.0, stat=Sent (Queued! 536d1dd2.9030...@evermeet.cx (Queue-Id: DAD7981B542)) Any idea what is going on? I haven't seen a notice of problems from infrastructure, but I have seen terrible mailing list delays over the last week. For example, just now I saw a commit message from 8 days ago. Normally I might see a delay of up to a few hours. I don't know whether or not this addresses your exact problem. Cheers, Helmut -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: documentation for module crypto missing
On Wednesday 07 May 2014 17:32:51, Helmut Tessarek wrote: Hello, The page at http://apr.apache.org/docs/apr-util/1.5/group___a_p_r___util___crypt o.html is empty. Good question. When I generate the docs locally, it has content. Also, where can I find information on when a function was added? That info seems to be missing in the docs, unfortunately. Looking up in the CHANGES or in the svn history seems to be the only way. More to the point: which apr-util release added the apr_bcrypt_encode or the bcrypt code? Changes with APR-util 1.5.0 ... *) apr_password_validate, apr_bcrypt_encode: Add support for bcrypt encoded passwords. The bcrypt implementation uses code from crypt_blowfish written by Solar Designer solar openwall com. apr_bcrypt_encode creates hashes with $2y$ prefix, but apr_password_validate also accepts the old prefix $2a$. PR 49288. [Stefan Fritsch]
Re: my messages get queued
I haven't seen a notice of problems from infrastructure, but I have seen terrible mailing list delays over the last week. For example, just now I saw a commit message from 8 days ago. Normally I might see a delay of up to a few hours. I don't know whether or not this addresses your exact problem. I have seen some ASF-wide emails on it. Mail is all over the floor for more than a week.
Re: my messages get queued
On 15.05.14 8:55 , Jeff Trawick wrote: I haven't seen a notice of problems from infrastructure, but I have seen terrible mailing list delays over the last week. For example, just now I saw a commit message from 8 days ago. Normally I might see a delay of up to a few hours. I don't know whether or not this addresses your exact problem. Yes, there has been a rather long delay these days. Maybe someone could check the server and figure out why that is. So long (pun intended), Helmut -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: documentation for module crypto missing
On 15.05.14 17:57 , Stefan Fritsch wrote: That info seems to be missing in the docs, unfortunately. Looking up in the CHANGES or in the svn history seems to be the only way. Yep, that was my next approach, but it is a little bit tedious and error prone (not all functions might be mentioned in the CHANGES file). I expected that information next to the function call or in the API reference (e.g. as in the PHP documentation). Cheers, Helmut -- regards Helmut K. C. Tessarek lookup http://sks.pkqs.net for KeyID 0xC11F128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
Re: digest functions and validation - part 2
On Fri, May 9, 2014 at 3:53 PM, Helmut Tessarek tessa...@evermeet.cx wrote: The sha*crypt functions are basically a standard, are they not? Thus it would make sense to include them in APR. I think there's some disconnect about the role of APR. But setting that aside, what's missing is someone doing the actual work, not some principle keeping it out.
Re: svn commit: r1593614 - in /apr/apr/trunk: CHANGES configure.in memory/unix/apr_pools.c
s...@apache.org wrote:
Author: sf
Date: Fri May 9 20:14:01 2014
New Revision: 1593614
URL: http://svn.apache.org/r1593614
Log:
Option to detect concurrent accesses to pools
Enabled by new configure option --enable-pool-concurrency-check.
Compared to pool-owner-debugging, this only detects cases where there is
actual
contention between accesses. The advantage is that runtime costs should be
relatively low.
The diagnostic messages could still use some improvement.
Modified:
apr/apr/trunk/CHANGES
apr/apr/trunk/configure.in
apr/apr/trunk/memory/unix/apr_pools.c
Modified: apr/apr/trunk/memory/unix/apr_pools.c
URL:
http://svn.apache.org/viewvc/apr/apr/trunk/memory/unix/apr_pools.c?rev=1593614r1=1593613r2=1593614view=diff
==
--- apr/apr/trunk/memory/unix/apr_pools.c (original)
+++ apr/apr/trunk/memory/unix/apr_pools.c Fri May 9 20:14:01 2014
@@ -673,6 +682,65 @@ APR_DECLARE(void) apr_pool_terminate(voi
#define node_free_space(node_) ((apr_size_t)(node_-endp -
node_-first_avail))
/*
+ * Helpers to mark pool as in-use/free. Used for finding thread-unsafe
+ * concurrent accesses from different threads.
+ */
+#if APR_POOL_CONCURRENCY_CHECK
+static void pool_concurrency_abort(apr_pool_t *pool, const char *func,
apr_uint32_t old)
+{
+fprintf(stderr, %s: previous state %d in_use_by/cur %lx/%lx pool
%p(%s)\n,
+func, old,
+(unsigned long)pool-in_use_by,
+(unsigned long)apr_os_thread_current(),
+pool, pool-tag);
+abort();
+}
+
+static APR_INLINE void pool_concurrency_set_used(apr_pool_t *pool)
+{
+apr_uint32_t old;
+
+old = apr_atomic_cas32(pool-in_use, 1, 0);
+
+if (old == 2 pool-in_use_by == apr_os_thread_current()) {
How can old ever be 2?
+/* cleanups may use the pool */
+return;
+}
+
+if (old != 0)
+pool_concurrency_abort(pool, __func__, old);
Isn't __func__ C99?
Regards
Rüdiger
Re: digest functions and validation - part 2
Am Freitag, 9. Mai 2014, 14:26:26 schrieb Helmut Tessarek: Thanks for the answer. On 09.05.14 3:22 , Stefan Fritsch wrote: No. But which password hashing algorithmis are used/supported by apr_password_validate() is rather unrelated to which digest functions are made available with a public interface. For password hashing, apr-util has been supporting bcrypt since version 1.5. It's great to have bcrypt available, but I hoped that Ulrich Drepper's sha256 and sha512 implementations would be part as well. His code is public domain, so it shouldn't be a license issue. At the moment, bcrypt is the only safe choice really. Doesn't this seem a bit strange to you? IMO Ulrich's functions are standard these days and APR should include them, just my 2 cents. bcrypt has a smaller speed-up from normal CPUs to GPUs than sha256crypt/sha512crypt. This means if you tune the rounds to make bcrypt give you the same level of security as sha*crypt, bcrypt is faster. For the normal login on a server, this is not really relevant (100ms or 500ms, who cares). But in a web server, speed is very relevant. You may need to do 1s of password checks per second. You cannot increase the number of rounds arbitrarily. Therefore bcrypt is more secure than sha*crypt for web servers. I don't see any reason to add a less secure algorithm. And I didn't choose scrypt because I felt it was still rather new when I included bcrypt support in apr. However, there is a contest for password hashing alorithms [1]. If there is some winner, and after the winner has seen some scrunity from cryptoanalysts, it may make sense to include that into apr. [1] https://password-hashing.net/ What is missing is the support in httpd 2.2's htpasswd to generate hashes with bcrypt. And even in 2.4, bcrypt is not yet used by default. Both things should be changed, but are entirely unrelated to apr. Yes, the httpd project seems stangely slow at times. It almost reminds me of IBM, where I worked for 17 years. (You have a great idea, which takes you half a day to implement (which you do), but then it takes 2 years (and a lot of administrative processes) to get it into a product - if at all.) It's more like openssl. Considering the huge userbase of httpd and its importance for the internet's infrastructure, there are very little developer ressources available.
