On Sun, May 20, 2012 at 8:14 PM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c Mon May 21 00:14:20 2012
>...
> + const char *path;
> + apr_ssize_t klen;
> + apr_hash_this(hi, (const void **)&path, &klen, NULL);
Historically, we have not
/home/neels/svnbench/20120521-002446
Started at Mon May 21 00:24:46 UTC 2012
*Disclaimer:* this tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.
Average
On 17/05/12 02:05, Philip Martin wrote:
Kenneth Miles writes:
On 04/05/12 20:09, Philip Martin wrote:
Kenneth Miles writes:
I'm not sure if a specific revision is causing the issue. But it
always fails replaying on a certain revision number as seen in the
stack trace.
Hi Bert,
In short: excellent work! With your latest changes,
all algorithmic issues have been resolved as already
confirmed on IRC. Two places in the server could
also be improved (r1340874-5).
Note to package builders: Sqlite 3.7.7 will not use
all available indexes while 3.7.12 does (an possib
And when you truly can't define an abuse case, but a third party has
insisted on allocating a cve, you should post a refutation to the dev list
asking to be shown otherwise and clearly stating your counterargument ...
and have security@ post a link to that post as the 'vendor response' to tha
> -Original Message-
> From: Stefan Fuhrmann [mailto:stefanfuhrm...@alice-dsl.de]
> Sent: zaterdag 19 mei 2012 20:34
> To: Subversion Development
> Subject: Working copy operations that are worse than O(change size)
>
> Hi Bert & interested parties,
>
> as promised, I ran the create_big
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/05/2012 15:13, Stefan Sperling wrote:
> A bug in the server that can be used by *authenticated* users to
> crash a server child process or thread which will immediately
> respawn is not as severe. While it does affect system reliability
> we do n
On Sun, May 20, 2012 at 4:37 AM, Stefan Fuhrmann
wrote:
> Directory deltification making wordpress.org
> go from 400+GB to 10GB *is* a reason.
> Without stable hashes, we would need special
> code for hash deltification.
Having a stable hash function sure doesn't seem like this would
account for
On Fri, May 18, 2012 at 11:52:27PM -0500, Hyrum K Wright wrote:
> I think the situation we've had in the past is that stuff we've
> decided is "oh, just a defect" downstream has decided is a real
> vulnerability. *They* request the CVE, and we're then backpedalling
> to ensure the information is p
Am 20.05.2012 12:14, schrieb Branko Čibej:
On 20.05.2012 03:33, Greg Stein wrote:
I thought the whole reason for variant results was to avoid O(N^2) attacks
against the hash table. You would be defeating that work.
I see no reason to use a stable hash. If outputs are supposed to stable,
then th
Greg Stein wrote:
I thought the whole reason for variant results was to avoid O(N^2)
attacks against the hash table. You would be defeating that work.
No. They (APR) did not solved the problem.
For instance, if all keys have the same length,
the new seed approach will simply rotate
the buck
On 20.05.2012 03:33, Greg Stein wrote:
> I thought the whole reason for variant results was to avoid O(N^2) attacks
> against the hash table. You would be defeating that work.
>
> I see no reason to use a stable hash. If outputs are supposed to stable,
> then the *presentation * layer should be sta
12 matches
Mail list logo
