1 Aug 2011 02:22
1 Aug 2011 06:13
Re: Apache Subversion 1.7.0-beta2 Released
Greg Stein <gstein <at> gmail.com>
2011-08-01 04:13:18 GMT
2011-08-01 04:13:18 GMT
On Sun, Jul 31, 2011 at 15:26, Barry Scott <barry <at> barrys-emacs.org> wrote: > > On 24 Jul 2011, at 03:38, Hyrum Wright wrote: > >> I'm happy to announce the release of Apache Subversion 1.7.0-beta2. >> Please choose the mirror closest to you by visiting: > > I have just finished running the pysvn test and they all passed. > > However I am seeing lines with "traced call". What do they mean? You configured with --enable-debug or --enable-maintainer-mode, which set the SVN_DEBUG flag. Those "tracing" lines represent additional "stack frames" in the error chain, which the developers use to help track down where errors come from. For production code, they will not exist. Cheers, -g
1 Aug 2011 12:09
Re: Students' Project seeks help
Jan Peters <peters.jan.r <at> googlemail.com>
2011-08-01 10:09:11 GMT
2011-08-01 10:09:11 GMT
Hi Everybody, thanks for all the quick repsonses. I myself wasn't able to answer until now since we wanted to discuss things in our group. We plan to integrate this so that a compromised server does not allow the attacker to read data, even if he has got access to the repositories, no matter how he got it. The "Professor" who gave this task to us, is willing to accept the loss in performance for the enhanced security. Tom Widmer, Peter Samuelson, Markus Schaber: We are allowed a loss in performance, and more explicitly the delta-functionality. But as Peter Samuelson pointed out delta transmission might still work on a block-basis with block-ciphers and this is what we hope for. Unfortunately this would require us to make sure that plain-text blocks' borders aren't moved, when data is inserted or removed. We know that, since we do not want attackers to analyze the data by assuming that the first x byte are some kind of constant header (pdf, html , etc) - thus having plain-text-cypher pairs - we do need to mask those parts. But this could be aranged by simply adding some random number to the plaintext (224 bit plaintext 32 random or something like that) which is only changed when the plaintext-block is changed. This way we wouldn't have full feedback encryption, which reduces security, because it is easier to find pairs, but we would still allow the delta handler to at least work on "blocks". Philip Martin(Continue reading)
1 Aug 2011 12:14
Re: 1.7 problems with repos in domain root
Philip Martin <philip.martin <at> wandisco.com>
2011-08-01 10:14:05 GMT
2011-08-01 10:14:05 GMT
Stefan Küng <tortoisesvn <at> gmail.com> writes: > Using a build from the latest 1.7.x branch, try this: > > svn info http://svn.freetz.org/tags/freetz-1.1.4 > > results in: > > --------------------------- > Microsoft Visual C++ Debug Library > --------------------------- > Debug Error! > Program: d:\Development\SVN\TortoiseSVN\bin\debug64\bin\svn.exe > R6010 > - abort() has been called r1152726 should have fixed libsvn_ra_neon. -- -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
1 Aug 2011 14:56
AW: Students' Project seeks help
Markus Schaber <m.schaber <at> 3s-software.com>
2011-08-01 12:56:30 GMT
2011-08-01 12:56:30 GMT
Hi, Jan, Von: Jan Peters [mailto:peters.jan.r <at> googlemail.com] > Markus Schaber > Concerning the RA solution: Our task is to integrate the client-side > encryption into Tortoise. But we figured that a general solution, which > worked on all clients would be the best way to handle this. Having an RA > solution for every RA solution currently in existence didn't seem > feasible. I did not mean a new RA backend for every existing RA backend, but one new RA backend which will proxy to any other existing RA backend (they all have a rather itentical interface hidden behind the ra library...). Best regards Markus Schaber ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.schaber <at> 3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com(Continue reading)
1 Aug 2011 15:04
Re: svn commit: r1152410 - in /subversion/trunk/subversion/libsvn_wc: wc-queries.sql wc_db.c
Neels J Hofmeyr <neels <at> elego.de>
2011-08-01 13:04:38 GMT
2011-08-01 13:04:38 GMT
On 07/30/2011 03:18 AM, stsp <at> apache.org wrote: > Author: stsp > Date: Sat Jul 30 01:18:20 2011 > New Revision: 1152410 > > URL: http://svn.apache.org/viewvc?rev=1152410&view=rev > Log: > Store moved-to relpaths in the BASE tree (op_depth = 0) instead of > nodes_current. All move operations are relative to the BASE, so having > moved-to information in op_depth layer 0 is semantically more correct. I've been thinking some more about this, and I'm quite 50/50 on which level is best suited for moved-to (op_depth == 0 vs. op_depth > 0). (If a BASE node was moved, there always is an op_depth > 0 node available.) I thought I'd jot some details of the choice down so others can have their opinions. When storing moved-to in op_depth == 0 (as this patch introduces), - the meaning of the column is more intuitively clear. The moved-to information tells you where the BASE was moved to locally. Straightforward. - but on moves and reverts, the op_depth==0 row needs to be updated. So - the op_depth==0 rows' moved-to columns can be corrupted by interrupted operations. Yet this is easily remedied by a revert, clearing that column. If moved-to is stored in op_depth > 0, - it's true to the idea that a full revert is simply wiping all op_depth > 0 nodes away (is that still true up to now?) - but the meaning of the column moved-to becomes more complex to explain and code. An op_depth>0 row's moved-to column does not refer to any new node(Continue reading)
1 Aug 2011 16:17
Re: svn commit: r1152410 - in /subversion/trunk/subversion/libsvn_wc: wc-queries.sql wc_db.c
Stefan Sperling <stsp <at> elego.de>
2011-08-01 14:17:28 GMT
2011-08-01 14:17:28 GMT
On Mon, Aug 01, 2011 at 03:04:38PM +0200, Neels J Hofmeyr wrote: > - but on moves and reverts, the op_depth==0 row needs to be updated. So > - the op_depth==0 rows' moved-to columns can be corrupted by interrupted > operations. Yet this is easily remedied by a revert, clearing that column. Not sure what you mean here. In what way could columns become corrupted? Interruptions only happen on a higher level than individual column updates. We wrap most (all?) operations that run multiple statements in sqlite transactions -- see the various *_txn() functions in wc_db.c. Either all SQL statements in such functions fail or they all succeed. So if an op_depth==0 row has a non-NULL moved-to relpath column the relpath was inserted by a successful operation. > > Also, clear moved-to relpaths from the BASE tree during 'revert' so > > we don't leave phantom moved-to information in the DB (are there any > > other places where we need to clear it?). > > ^ here would be the remedy to any interrupted operations involving moved-to. > And at the same time this update of op_depth==0 rows during revert was not > necessary before this patch. It wasn't necessary because it was cleared by the existing revert code. I.e. this part of the required maintenance happened to be performed by existing code. But that doesn't mean less maintenance. We need to maintain moved-to data either way. I think it is easier to manage it in op_depth==0. Because of the transactional nature of our DB operations there are only two kinds of inconsistencies we have to worry about, at a fairly(Continue reading)
1 Aug 2011 16:28
RE: Students' Project seeks help
Bob Archer <Bob.Archer <at> amsi.com>
2011-08-01 14:28:47 GMT
2011-08-01 14:28:47 GMT
> Hi Everybody, > thanks for all the quick repsonses. I myself wasn't able to answer > until > now since we wanted to discuss things in our group. > > We plan to integrate this so that a compromised server does not > allow > the attacker to read data, even if he has got access to the > repositories, no matter how he got it. The "Professor" who gave > this > task to us, is willing to accept the loss in performance for the > enhanced security. Is this just an academic exercise? I think putting the repository on a truecrypt drive would solve the above requirement. BOb > > Tom Widmer, Peter Samuelson, Markus Schaber: > We are allowed a loss in performance, and more explicitly the > delta-functionality. But as Peter Samuelson pointed out delta > transmission might still work on a block-basis with block-ciphers > and > this is what we hope for. Unfortunately this would require us to > make > sure that plain-text blocks' borders aren't moved, when data is > inserted > or removed. > > We know that, since we do not want attackers to analyze the data by(Continue reading)
1 Aug 2011 17:02
Re: Students' Project seeks help
Tom Widmer <tom.widmer <at> gmail.com>
2011-08-01 15:02:59 GMT
2011-08-01 15:02:59 GMT
On 01/08/2011 15:28, Bob Archer wrote: >> Hi Everybody, >> thanks for all the quick repsonses. I myself wasn't able to answer >> until >> now since we wanted to discuss things in our group. >> >> We plan to integrate this so that a compromised server does not >> allow >> the attacker to read data, even if he has got access to the >> repositories, no matter how he got it. The "Professor" who gave >> this >> task to us, is willing to accept the loss in performance for the >> enhanced security. > > Is this just an academic exercise? I think putting the repository on a truecrypt drive would solve the above requirement. Only if all clients can access the drive via the file: protocol (which is obviously not a scalable, safe or general purpose solution). If you access via http(s): or svn:, then obviously the server will need the decryption keys one way or another, which defeats the objective I think. Tom
1 Aug 2011 17:25
Re: Students' Project seeks help
Julian Foad <julian.foad <at> wandisco.com>
2011-08-01 15:25:18 GMT
2011-08-01 15:25:18 GMT
On Mon, 2011-07-25, Jan Peters wrote: > [...] Yet the code of the update functionality is by far harder to > comprehend. Hi Jan. I'll just reply to this part of your question about how the 'update' code works. > To me personally it looks like the svn_ra_do_update2 fetches the data > from the server (or whatever method is used here) but does not apply > changes to the working copy yet. Since we do not want to change > anything about the ra modules themselves we omitted this part when > checking. > > Concerning svn_wc_crawl_revisions5 and svn_wc_crawl_revisions2 it says > "After all revisions are reported, reporter->finish_report() is > called, which immediately causes the RA layer to update the working > copy. Thus the return value may very well reflect the result of the > update!" here > http://subversion.sourcearchive.com/lines/1.4.4dfsg1/svn__wc_8h_9aacdf613889a86c23af70544103132a.html#9aacdf613889a86c23af70544103132a. > I don't actually see where this is done. But I must assume that actual > changes to the local files and database are done here. If you look at the calling code, in subversion/libsvn_client/update.c update_internal(), you will see [1]: svn_wc_get_update_editor4(&update_editor, &update_edit_baton, ...); svn_ra_do_update2(..., &reporter, &report_baton, ..., update_editor, update_edit_baton, ...);(Continue reading)
RSS Feed