neels | 1 Aug 02:22 2011
Picon

[svnbench] Failed to build Revision: 1152668.

Failed to build Revision: 1152668.

Greg Stein | 1 Aug 06:13 2011
Picon

Re: Apache Subversion 1.7.0-beta2 Released

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

Jan Peters | 1 Aug 12:09 2011

Re: Students' Project seeks help

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)

Philip Martin | 1 Aug 12:14 2011

Re: 1.7 problems with repos in domain root

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

Markus Schaber | 1 Aug 14:56 2011

AW: Students' Project seeks help

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)

Neels J Hofmeyr | 1 Aug 15:04 2011
Picon

Re: svn commit: r1152410 - in /subversion/trunk/subversion/libsvn_wc: wc-queries.sql wc_db.c

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)

Stefan Sperling | 1 Aug 16:17 2011
Picon

Re: svn commit: r1152410 - in /subversion/trunk/subversion/libsvn_wc: wc-queries.sql wc_db.c

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)

Bob Archer | 1 Aug 16:28 2011

RE: Students' Project seeks help

> 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)

Tom Widmer | 1 Aug 17:02 2011
Picon

Re: Students' Project seeks help

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

Julian Foad | 1 Aug 17:25 2011

Re: Students' Project seeks help

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)


Gmane