On 04/06/2012 10:47 AM, Greg Stein wrote:
Correct. Still useful, but even if memory is compromised, the SHA1 is
not reversible. The original MP cannot be recovered for other uses.
Just as a reminder, SHA-1 is not recommended for use in new applications
at this time
On 04/06/2012 10:55 AM, Greg Stein wrote:
In other words, changing the master passphrase only requires decrypting
and re-encrypting one 256-bit encryption key, not the whole credentials
store.
PKBDF2 is in the current design to make dict attacks computationally
impossible. Assuming we keep
On 04/06/2012 01:44 PM, Justin Erenkrantz wrote:
On Fri, Apr 6, 2012 at 8:09 AM, Greg Hudson ghud...@mit.edu wrote:
I also want to caution that PBKDF2 does not provide strong protection
against offline dictionary attacks. Most cryptographic methods provide
exponential protection--I do
On 03/26/2012 09:00 AM, C. Michael Pilato wrote:
The on-disk cache will contain everything it does today where
plaintext caching is enabled, save that the password won't be
plaintext, and there will be a bit of known encrypted text (for
passphrase validation).
Is it important to be able to
On 02/04/2012 08:02 PM, Hyrum K Wright wrote:
I don't know if apr has a sha256 implementation, but it wouldn't be hard to
find one.
I'll point out that we're nearing the end of a selection process for
SHA-3, with a winner expected to be announced some time this year. The
winner may wind up
On 11/03/2011 01:44 AM, Jonathan Nieder wrote:
What do you think? Is forcing !APR_HAS_RANDOM and just using
apr_time_now() as Debian currently does safe, or does it expose users
to a security risk?
I suspect it makes the server vulnerable to a replay attack.
The right answer is to use
On 11/03/2011 05:10 PM, Jonathan Nieder wrote:
Why would that be? When someone dumps in 20 bits of data from a
strong, in-hardware, random number source, even if the PRNG is utterly
stupid, it can have an unguessable 20 bits of internal state. After
reading enough random numbers, I will have
On Fri, 2011-09-09 at 08:09 -0400, Greg Stein wrote:
Greg Hudson said this is more akin to git stash than branches. I
haven't used git's stashes to see how it actually differs from
branches. I guess it is simply that changing branches leaves local
mods, rather than stashing pseudo-reverts
On Thu, 2011-09-08 at 23:43 -0400, Greg Stein wrote:
I've had to use git lately, and our shelves could almost look like
git's branches. Swap around among them based on what you're doing at
the time.
I think this is closer to git's stash feature than git branches. In
fact, I was thinking of
On Wed, 2011-08-24 at 07:42 -0400, 1983-01...@gmx.net wrote:
Are you refering to sole Kerberos or are you just concerned about
transport encryption? Your statement somewhat irritates me.
Given that the HTTP traffic cannot be securely wrapped into the GSS
content and nor the SASL QOP can be set
On Wed, 2011-08-24 at 05:52 -0400, Bert Huijben wrote:
Then somebody added Kerberos support to neon, but the api wasn't
updated to allow different behavior for the specific implementations.
Kerberos via HTTP negotiate is also insecure when not used over HTTPS.
In HTTP negotiate, the GSSAPI
On Tue, 2011-08-16 at 14:14 -0400, Daniel Shahaf wrote:
r6881 implies that a ^/clients directory existed until r6880:
https://svn.apache.org/viewvc/subversion/README?r1=846955r2=846954pathrev=846955diff_format=f
kfogel on IRC recalls it having existed.
I remember svn (the command) living
On Mon, 2011-07-11 at 12:48 -0400, Mark Phippard wrote:
2. Subversion does not handle move/rename well (tree conflicts)
[...]
When this problem was first approached (before we came up
with tree conflicts) it hit a brick wall where it seemed a new
repository design was needed:
It's worth
On Wed, 2011-06-22 at 02:29 -0400, Daniel Shahaf wrote:
From looking at the code, svn_io_open_unique_file3() would force the
file to have a mode of 0600|umask() instead of just 0600
The umask removes file permissions from the mode argument to open(); it
doesn't add permissions. (Unless there's
On Wed, 2011-06-15 at 09:38 -0400, Johan Corveleyn wrote:
But I don't like the hand-waving discussion that it will always be
superior, period. That's just not true. And it would be a big mistake,
IMHO, to only support a heuristic diff.
If it's a big mistake to use a heuristic diff by default,
On Wed, 2011-06-15 at 11:30 -0400, Johan Corveleyn wrote:
Okay, I guess we should then also rip out --ignore-space-change and
--ignore-eol-style, and perhaps --show-c-function. Or, if it's
preferred that ignore-space-change and ignore-eol-style be used by
default (because humans are normally
On Wed, 2011-06-15 at 13:28 -0400, Philip Martin wrote:
Do they all support -s?
cmp -s is one of the most portable Unix command invocations in existence
(from general knowledge; I can't give a reference).
On Mon, 2011-06-13 at 07:00 -0400, Morten Kloster wrote:
I assume he has discussed this elsewhere in more detail? The link
you provided says very little about it (and the ONLY hit for implicit
cherrypicking on Google was your post :-).
Yes, but I'm not sure where any more, unfortunately.
My executive summary of your post is that you want diff3 to try to merge
related, but not identical, changes occuring between a pair of sync
points. I'm wary about this for two reasons.
First, the benefit appears to arise chiefly for what Bram Cohen calls
implicit cherrypicking use cases--that
On Wed, 2011-05-18 at 14:24 -0400, Stefan Küng wrote:
the not to all point... just doesn't sound right.
It's a split infinitive, which doesn't make it necessarily bad English
but can make it sound wrong. Not to point to the same repository
would be more concise and just as precise, in my
On Thu, 2011-04-14 at 14:25 -0400, Philip Martin wrote:
I believe it is a GNU standard. Debug symbols can be used with an
optimised build although it is obviously easier to debug without
optimisation
More specifically: stepping through a -g -O2 executable is pretty
painful, but you can still
On Mon, 2011-02-21 at 14:48 -0500, Keith Palmer Jr. wrote:
Nothing in what you just copy-pasted indicates whether it's *the
actual data stream* that's being encrypted, or just the
*authentication*. I need to know if the checked-out files that are
being transferred are encrypted or not.
The
On Tue, 2011-02-01 at 10:29 -0500, C. Michael Pilato wrote:
I can only really speak for the BDB side of things, but... what he said.
I'll elaborate a little bit. API issues aside, we're used to putting
artifacts from different versions in different places. More so in FSFS,
where it was baked
On Thu, 2011-01-27 at 21:46 -0500, Senthil Kumaran S wrote:
A NULL does mean '\0' or (void *) 0x. I also referred this -
http://en.wikipedia.org/wiki/Null_character which says the same when
referring to NULL termination of a string, except for one place where
it says 'NUL' is an abbreviation
On Mon, 2010-12-06 at 07:30 -0500, Daniel Shahaf wrote:
Ideally, Subversion won't know the PGP passphrase. (If it does, then
a malicious libsvn_subr can compromise a private key.)
I think you're trying to solve a different problem here. The goal is to
minimize typing of passwords without
On Sat, 2010-11-13 at 10:31 -0500, Daniel Shahaf wrote:
Sounds reasonable.
What changes to the source code would be required?
Do we just change
N_(three\n\nparagraphs\n\nhere\n)
to
N_(three\n) N_(paragraphs\n) N_(here\n)
No, that would just result in evaluating gettext on
On Tue, 2010-10-19 at 04:31 -0400, Greg Stein wrote:
The FSFS backend was dropped in as a fait d'accompli.
A minor correction: ra_svn was dropped in as a fait d'accompli. FSFS
was, as far as I remember, a pretty open process where I created a
design and Josh Pieper implemented it. You can look
On Mon, 2010-10-04 at 06:14 -0400, Julian Foad wrote:
The NULL macro is intended for use as a pointer.
Only when statically cast to the appropriate pointer type. This happens
automatically in many contexts, such as assignments or prototyped
function parameters. But it does not happen
On Mon, 2010-10-04 at 12:06 -0400, Julian Foad wrote:
The issue at hand is when NULL is defined as an unadorned '0' *and* is
passed to a variadic function such as apr_pstrcat. If that's not a
practical concern, that must be because the size and representation of
(int)0 is the same as (char
On Thu, 2010-08-26 at 05:57 -0400, anatoly techtonik wrote:
Don't you think it is time to design an extensible changeset format
for exchanging information about changesets between systems?
Mostly for your entertainment, see:
http://www.red-bean.com/pipermail/changesets/2003-April/thread.html
On Tue, 2010-08-17 at 09:26 -0400, Johan Corveleyn wrote:
Greg, could you explain a bit more what you mean with
edit-stream-style binary diffs, vs. the binary deltas we have now?
Could you perhaps give an example similar to Julian's? Wouldn't you
have the same problem with pieces of the source
On Thu, 2010-08-12 at 10:57 -0400, Julian Foad wrote:
I'm wary of embedding any client functionality in the server, but I
guess it's worth considering if it would be that useful. If so, let's
take great care to ensure it's only lightly coupled to the core server
logic.
Again, it's possible
On Wed, 2010-08-11 at 19:14 -0400, Johan Corveleyn wrote:
I naively thought that the server, upon being called get_file_revs2,
would just supply the deltas which it has already stored in the
repository. I.e. that the deltas are just the native format in which
the stuff is kept in the back-end
On Tue, 2010-08-10 at 14:24 -0400, C. Michael Pilato wrote:
The foremost bit of client configuration that CollabNet's Subversion
customers are demanding (besides auto-props, which I think we all agree on)
is a way for the server to set a policy which dictates that clients may not
use plaintext
On Sat, 2010-08-07 at 07:58 -0400, Daniel Shahaf wrote:
Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200:
On 07.08.2010 12:44, Daniel Shahaf wrote:
If corporations want to have configuration override, fine.
But I want a way to disable that completely. I don't necessarily want to
When I've mirrored repositories with the intent of keeping them in sync,
I've typically given them the same UUID. I don't know if that has much
impact in practice, since I think working copies tend to stick to one of
the mirrors (either the RW master or the RO slave).
The philosophical question
On Fri, 2010-07-09 at 11:44 -0400, Stefan Sperling wrote:
As far as I can tell there is little we can do to secure svnserve
against this attack on Windows systems other than Server 2003,
because APR won't let us set the SO_EXCLUSIVEADDR option.
That's okay, we don't want the SO_EXCLUSIVEADDR
On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote:
So therefor, what we would like to see is to be able to have a transparent
branch: One which fetches updates from both branch and trunk, without having
them listed as changes or triggering commits. In essence it's reading from
two
On Thu, 2010-07-01 at 08:56 -0400, michael.fe...@evonik.com wrote:
I better already start to run for it,
when I ever approve the use of the current implementation of the
representation cache.
Here's what this says to me: it doesn't matter what the real risks are;
it only matters that the
On Fri, 2010-06-25 at 08:45 -0400, michael.fe...@evonik.com wrote:
I am actually more interested in finding reliable solution
instead of discussing mathematics and probabilities.
The discussion of probabilities affects whether it would be justifiable
to change Subversion to address hash
On Thu, 2010-06-24 at 11:29 -0400, michael.fe...@evonik.com wrote:
We must ensure that the data in the repository is, without any concerns,
the data we have once measured or written.
You do realize that the probability of data corruption due to faulty
hardware is much, much more likely than
On Wed, 2010-05-12 at 13:44 -0400, Hyrum K. Wright wrote:
There may be other ways of caching this information, which would be great.
Maybe. Caches add complexity, and too many layers of caching (disk, OS,
application) can actually reduce performance in some scenarios.
I would suggest getting a
On Mon, 2010-03-29 at 12:07 -0400, Julian Foad wrote:
Some possible interpretations are
* Find the repository URL of './some/deep/file.c', and [...]
I'll mention a related interpretation, which is to use the repository
URL of the parent directory and append file.c to it.
This is a little
Although I've always been aware of the design intent behind empty hook
script environments, I'll echo Tim's complaint that it's sometimes
inconvenient. The problem most commonly crops up in svn+ssh:// or
file:// deployments where you want to run some action with user
credentials: updating a bug
On Fri, 2010-01-08 at 15:31 -0500, Paul Querna wrote:
Profile everything, be faster at everything
There are smart people who will disagree with me on this, but I'm not
sure the best tool for improving Subversion performance is a profiler.
Historically a lot of our performance issues have come
On Wed, 2010-01-06 at 21:26 -0500, Mark Mielke wrote:
There is a race between the pull
and push whereby somebody who pushes before I pull will cause my push to
fail, but we generally consider this a good thing as it allows us to
analyze the change and determine whether additional testing is
On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote:
To be a compelling replacement for git/Mercurial, perhaps?
That seems tough. The major architectural differences between
git/Mercurial/Bazaar and Subversion are:
* No commitment to mixed-revision working copies.
* Full history of
47 matches
Mail list logo
