On 08/17/2012 02:35 PM, C. Michael Pilato wrote:
> I'm sitting at this spot right now: Unless we want hooks parsing literal
> capability strings such as "client-version-tsvn-1dot7dot0", we have to
> change the server. And if we have to change the server *at all* to make
> this all work, then we s
On 04/06/2012 01:44 PM, Justin Erenkrantz wrote:
> On Fri, Apr 6, 2012 at 8:09 AM, Greg Hudson wrote:
>> I also want to caution that PBKDF2 does not provide strong protection
>> against offline dictionary attacks. Most cryptographic methods provide
>> exponential protecti
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
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 (http://csrc.nist.gov/groups
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 b
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 h
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 /dev
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 s
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 o
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
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 mec
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=846955&r2=846954&pathrev=846955&diff_format=f
>
> kfogel on IRC recalls it having existed.
I remember svn (the command) livi
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 co
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'
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 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 normal
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 defau
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 op
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 stil
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.
Th
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 abbreviatio
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 sto
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 evaluatin
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 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 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 automatic
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 s
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 possibl
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-e
On Wed, 2010-08-11 at 06:04 -0400, Julian Foad wrote:
> Ah. An interesting point which I hadn't fully digested. I think the
> gist of Branko's point is that the delta format doesn't distinguish
> between
In the process of a blame operation, the server is already performing
binary deltas (which a
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 plaint
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 necessari
On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
> I'm doing some more thinking about repository-dictated configuration,
I get nervous when I see people talk about repository-dictated
configuration as an extension of the general configuration framework.
There are a lot of things a reposi
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 h
On Fri, 2010-07-09 at 12:45 -0400, Stefan Sperling wrote:
> It's the older Windows systems that will still have problems,
> and I don't think we should be ignoring them (as much as I'd love
> it if everyone just ditched Windows for good).
Is this really a concern on Windows systems? This is basic
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 branc
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 q
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 colli
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
I would guess that svnsync was designed under the assumption that it
would be run on the slave repository via a cron job or something. It's
a pull tool, not a push tool.
That said, your suggestion seems reasonable.
(When I've set up replicated repositories using push, I've used svnadmin
dump and
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
On Wed, 2010-03-24 at 16:45 -0400, Tim Starling wrote:
> But like I said, I'm happy with it being configurable. Do you want a
> patch for that too? It's a fair bit more complicated than the one I
> already did so I didn't want to try it without at least in-principle
> approval.
I haven't been acti
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 da
On Sun, 2010-01-10 at 14:13 -0500, Steinar Bang wrote:
> And then later, when I'm online, I do a an update against the
> repository, with virgin versions of the changed files, and then I copy
> in the copied-aside files, and do my checkins in stages.
FWIW, a lot of people seem to use git as a Subv
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
On Wed, 2010-01-06 at 11:16 -0500, Julian Foad wrote:
> > * No commitment to mixed-revision working copies.
>
> That sounds interesting, but I haven't got to grips with what it really
> means in terms of user work flows, and in what senses it is an important
> functional restriction versus an ad
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 o
On Thu, 2009-12-24 at 11:04 -0500, Julian Foad wrote:
> I think this feature is exactly the sort of thing that would make sense
> as a plug-in to Subversion, and not as part of the core product
It's possible that the entire keyword system would make more sense as a
plug-in to some version control
56 matches
Mail list logo
