Re: Bug: JavaHL does not transmie post-commit error messages to caller (was: Fwd: Re: JavaHL bindings - post-commit error messages)
Hello Hyrum,
Am Dienstag, den 23.08.2011, 09:23 -0500 schrieb Hyrum K Wright:
> Martin,
> After discussion with some other devs on IRC (#svn-dev on Freenode,
> come and join us!),
unfortunately no way, got only browser access to the internet during
working hours
> I committed r1160705 which should expose the post
> commit error as part of the CommitInfo class in JavaHL. I've
> nominated r1160705 for 1.7.x.
Sounds great.
> Could you test it if you get the chance?
Seems to be working. A patch containing a new test with a failing
post-commit script is attached (apply with -p0 in the bindings/javahl/
dir).
Should work (at least) on win and un*xoids - I'm not sure how to create
a reliably failing cross-platform post-commit script (at least not one
with some sensible output to test against).
> -Hyrum
Thanks for the really quick fix,
Martin
--- tests/org/apache/subversion/javahl/BasicTests.java.orig 2011-08-24 19:02:28.0 +0200
+++ tests/org/apache/subversion/javahl/BasicTests.java 2011-08-25 21:56:09.0 +0200
@@ -659,6 +659,47 @@
}
/**
+ * Test handling of post-commit error messages on commit
+ * @throws Throwable
+ */
+public void testBasicCommitWithPostCommitError() throws Throwable
+{
+// build the test setup
+OneTest thisTest = new OneTest();
+
+String postCommitErrorMessage = thisTest.createFailingPostCommit();
+
+// modify file A/mu
+File mu = new File(thisTest.getWorkingCopy(), "A/mu");
+PrintWriter muWriter = new PrintWriter(new FileOutputStream(mu, true));
+muWriter.print("appended mu text");
+muWriter.close();
+thisTest.getWc().setItemWorkingCopyRevision("A/mu", 2);
+thisTest.getWc().setItemContent("A/mu",
+thisTest.getWc().getItemContent("A/mu") + "appended mu text");
+addExpectedCommitItem(thisTest.getWCPath(),
+thisTest.getUrl().toString(), "A/mu",NodeKind.file,
+CommitItemStateFlags.TextMods);
+
+MyCommitCallback callback = new MyCommitCallback();
+
+client.commit(thisTest.getWCPathSet(), Depth.infinity,
+ false, false, null, null,
+ new ConstMsg("log msg"), callback);
+
+System.out.println(callback.info.postCommitError);
+
+assertNotNull(callback.info.postCommitError);
+// contains (potentially localized) "(exit code 1)"
+assertTrue(callback.info.postCommitError.contains("1)"));
+// the message prolog may be localized, and there's a extra newline appended
+assertTrue(callback.info.postCommitError.endsWith(postCommitErrorMessage + "\n"));
+
+// check the status of the working copy
+thisTest.checkStatus();
+}
+
+/**
* Test the basic property setting/getting functionality.
* @throws Throwable
*/
--- tests/org/apache/subversion/javahl/SVNTests.java.orig 2011-08-24 19:02:28.0 +0200
+++ tests/org/apache/subversion/javahl/SVNTests.java 2011-08-25 21:55:38.0 +0200
@@ -29,6 +29,7 @@
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
+import java.io.PrintWriter;
import java.net.URI;
import java.net.URISyntaxException;
import java.util.Set;
@@ -784,6 +785,42 @@
{
return this.testName;
}
+
+/**
+ * Create failing post-commit scripts in the current repository
+ * @return The content of the scripts' STDERR output for testing against
+ */
+ public String createFailingPostCommit() {
+ String error = "PostCommit Error";
+
+ try {
+String path = this.repository.getAbsolutePath() + "/hooks/post-commit";
+File postCommit = new File(path);
+postCommit.createNewFile();
+postCommit.setExecutable(true);
+PrintWriter out = new PrintWriter(postCommit);
+out.println("#!/bin/sh");
+out.print("echo \"");
+out.print(error);
+out.println("\" 1>&2");
+out.println("exit 1");
+out.close();
+
+String winPath = this.repository.getAbsolutePath() + "/hooks/post-commit.bat";
+File winPostCommit = new File(winPath);
+winPostCommit.setExecutable(true);
+winPostCommit.createNewFile();
+PrintWriter winOut = new PrintWriter(winPostCommit);
+winOut.print("echo \"");
+winOut.print(error);
+winOut.println("\" 1>&2");
+winOut.println("exit 1");
+winOut.close();
+ } catch (IOException e) {
+throw new RuntimeException("Cannot create post-commit hook");
+ }
+ return error;
+ }
}
/**
Re: [PATCH] get-location-segments.py would work on self-signed ssl servers too
On Monday 22 August 2011 09:37 AM, Prabhu Gnana Sundar wrote:
On Thursday 18 August 2011 06:46 PM, Daniel Shahaf wrote:
I tried your patch against
https://svn.eu.apache.org/repos/asf/subversion/README
(which uses a non-self-signed cert, but rather one for which the cert's
hostname differs from the URI's hostname), and it didn't seem to work:
[[[
./tools/examples/get-location-segments.py
https://svn.eu.apache.org/repos/asf/subversion/README
Untrusted cert details are as follows:
--
Issuer : 07969287, http://certificates.godaddy.com/repository,
GoDaddy.com, Inc., Scottsdale, Arizona, US
Hostname : svn.apache.org
ValidFrom : Thu, 13 Nov 2008 18:56:12 GMT
ValidUpto : Thu, 26 Jan 2012 14:18:55 GMT
Fingerprint: cc:54:a4:a9:ec:3a:9b:1c:23:ac:2d:57:c6:96:9f:5f:4a:1d:2d:86
accept (t)temporarily (p)permanently: t
Traceback (most recent call last):
File "./tools/examples/get-location-segments.py", line 147,
in
main()
File "./tools/examples/get-location-segments.py", line 142, in main
ra_session = ra.open(url, ra_callbacks, None, ctx.config)
File "/usr/lib/pymodules/python2.6/libsvn/ra.py", line 534, in
svn_ra_open
return _ra.svn_ra_open(*args)
svn.core.SubversionException: ("OPTIONS of
'https://svn.eu.apache.org/repos/asf/subversion/README': Server
certificate verification failed: certificate issued for a different
hostname (https://svn.eu.apache.org)", 175002)
zsh: exit 1 ./tools/examples/get-location-segments.py
]]]
What am I missing?
Something interesting... It is failing for me only with neon, but
working fine with serf, seeing some inconsistencies here...
I built neon with "OPENSSL_NO_TLSEXT "; then, it worked for me.:-)
You may want to look at here.
From neon/src/ne_socket.c: ne_sock_connect_ssl()
#ifdef SSL_set_tlsext_host_name
if (ctx->hostname) {
/* Try to enable SNI, but ignore failure (should only fail for
* >255 char hostnames, which are probably not legal
* anyway). */
if (SSL_set_tlsext_host_name(ssl, ctx->hostname) != 1) {
ERR_clear_error();
}
}
#endif
Thanks & Regards,
Vijayaguru
Re: diff --summarize
I discovered today that the network traffic generated by my rewrite of "diff --summarize" is ridiculously heavy - like apparently 100 times what it was, in a simple real-world test. I have an obvious patch which I'll apply soon which eliminates the requests for content of deleted files, and that reduces it by a factor of ten, but I haven't yet figured out where the other 10x is happening. I'll figure it out or else I'll have to revert it all, of course. Neels J Hofmeyr wrote: > On 08/24/2011 05:38 PM, Julian Foad wrote: > > Even from a practical POV, the orthogonality is useful. I have a script > > [...] > > heh yeah, you actually gave me that script back in the days, and with lesser > tweaks, I use that code all the time to semi-auto-generate my log messages > [...] I really like it, thank you very much indeed. I'm very glad. I still use it all the time too. > Oh, have you by any chance made it act super precise by now? That would be a > treat. In terms of "--show-c-function" correctly identifying +/* New doc */ -/* old doc */ void foo(void); as a change belonging to "foo"? No, haven't done that. > But, I don't really understand, why do you want to semi-auto-generate a log > message for already committed revisions? I don't really want that, but there might come a time when I would want that. I'm only fooling around with hypothetical use cases. - Julian
Re: FSFS revprop packing: use cases
Hyrum K Wright wrote on Thu, Aug 25, 2011 at 09:55:53 -0500: > Does something stop working for you if the branch is reintergrated? > No.
Re: FSFS revprop packing: use cases
On Thu, Aug 25, 2011 at 8:44 AM, Daniel Shahaf wrote: > Hyrum K Wright wrote on Thu, Aug 25, 2011 at 08:29:59 -0500: >> On Thu, Aug 25, 2011 at 3:09 AM, Daniel Shahaf >> wrote: >> > Paul Querna --- who wrote the initial revprop packing patch (the f5 one, >> > which has been reverted) --- mentions that his use case for revprop >> > packing has vanished due to hardware upgrades (acquiring SSD l2arc >> > disks). >> >> Not everybody has an SSD. >> >> > With that in mind, what's the fate of the (flat files -based) >> > 'revprop-packing' branch? Will anyone need it by the time 1.8.0 is >> > released? If not, we may forget about the branch and avoid finishing >> > and reintegrating it for 1.8.0. >> >> I'd still like to get the branch reintegrated back to trunk. The code >> is written, is there a compelling reason (other than status quo bias) >> *not* to get it back to trunk? > > Works for me. That would be the "status quo bias" I was talking about. :) Does something stop working for you if the branch is reintergrated? -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: FSFS revprop packing: use cases
Hyrum K Wright wrote on Thu, Aug 25, 2011 at 08:29:59 -0500: > On Thu, Aug 25, 2011 at 3:09 AM, Daniel Shahaf > wrote: > > Paul Querna --- who wrote the initial revprop packing patch (the f5 one, > > which has been reverted) --- mentions that his use case for revprop > > packing has vanished due to hardware upgrades (acquiring SSD l2arc > > disks). > > Not everybody has an SSD. > > > With that in mind, what's the fate of the (flat files -based) > > 'revprop-packing' branch? Will anyone need it by the time 1.8.0 is > > released? If not, we may forget about the branch and avoid finishing > > and reintegrating it for 1.8.0. > > I'd still like to get the branch reintegrated back to trunk. The code > is written, is there a compelling reason (other than status quo bias) > *not* to get it back to trunk? Works for me.
Re: FSFS revprop packing: use cases
On 08/25/2011 09:29 AM, Hyrum K Wright wrote: > On Thu, Aug 25, 2011 at 3:09 AM, Daniel Shahaf > wrote: >> Paul Querna --- who wrote the initial revprop packing patch (the f5 one, >> which has been reverted) --- mentions that his use case for revprop >> packing has vanished due to hardware upgrades (acquiring SSD l2arc >> disks). > > Not everybody has an SSD. > >> With that in mind, what's the fate of the (flat files -based) >> 'revprop-packing' branch? Will anyone need it by the time 1.8.0 is >> released? If not, we may forget about the branch and avoid finishing >> and reintegrating it for 1.8.0. > > I'd still like to get the branch reintegrated back to trunk. The code > is written, is there a compelling reason (other than status quo bias) > *not* to get it back to trunk? . o O ( Because danielsh and stsp don't want to think about successor-id packing? :-) ) -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: FSFS revprop packing: use cases
On Thu, Aug 25, 2011 at 3:09 AM, Daniel Shahaf wrote: > Paul Querna --- who wrote the initial revprop packing patch (the f5 one, > which has been reverted) --- mentions that his use case for revprop > packing has vanished due to hardware upgrades (acquiring SSD l2arc > disks). Not everybody has an SSD. > With that in mind, what's the fate of the (flat files -based) > 'revprop-packing' branch? Will anyone need it by the time 1.8.0 is > released? If not, we may forget about the branch and avoid finishing > and reintegrating it for 1.8.0. I'd still like to get the branch reintegrated back to trunk. The code is written, is there a compelling reason (other than status quo bias) *not* to get it back to trunk? -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
Re: svn:ignore-on-commit changelist -- was: dump svn:hold, long live file externals?? (and discussing recursive hold)
On 08/24/2011 04:36 PM, Daniel Shahaf wrote: > Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 22:04:11 +0200: >> On 08/24/2011 04:01 PM, Daniel Shahaf wrote: >>> Neels J Hofmeyr wrote on Wed, Aug 24, 2011 at 15:32:20 +0200: Changelists have been *designed* in the flipped-over wrong-way-round: they *include*, not exclude selected items. We'd have to implement this against its basic design. (Like using switch for externals, remember?) >>> >>> Changelists were designed to group files. What's fundamentally flawed in >>> >>> % svn cl foo A/mu ./iota >>> % svn commit --depth=empty A/mu ./iota --except-cl=foo >> >> Usually the code goes like "if there is a changelist, act on the node only >> when it is part of the changelist." ...well, it's just what I remember >> faintly, admittedly. Is that true? >> > > My recollection is that 'svn $subcommand foo --changelist bar' applies > to one of: > > - the subset of descendants of that are in changelist 'bar'; > - both to foo and to members of 'bar' > > where some subcommands behave differently than others. There should be no difference in behavior between subcommands. The documented behavior of changelists is to operate as filters only. So, 'svn $subcommand foo --changelist bar' operates on the subset of would-be targets were --changelist not specified which are members of the specific changelist. This means, for example, that 'svn info --changelist foo' will show nothing because 'svn info' is depth-zero by default and directories can't be in changelists, rather than showing all children of $CWD which are in the 'foo' changelist. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: RE: Proxy authentication with Negotiate uses wrong host
> 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 (like for LDAP), I would > > neglect that and still say TLS is not of your concern but of mine or > > the users in general. > > Any authentication-only mechanism used over an insecure channel is > vulnerable to MITM attacks which preserve the authentication and change > the data. Of course, this applies to HTTP basic and digest over raw > HTTP just as much as it does to negotiate, so perhaps it doesn't make > sense to restrict negotiate auth to HTTPS only on this basis alone. > > A further concern with HTTP negotiate is that it is scoped to the TCP > connection and not to a single HTTP request. Ignorant proxies may > combine TCP connections for multiple users' requests and inadvertently > authenticate one users' requests with anothers' credentials. I may be > wrong, but I believe this is the concern which leads implementations to > restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not > mitigate this concern at all. If there are other vulnerabilities in > NTLM which don't presuppose an MITM attack, perhaps I'm wrong. Greg, thanks for the insight. I will file a bug that the sole negotiate/kerberos and SSL restriction should be removed because it is not enforced on basic and digest either. Mike -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
FSFS revprop packing: use cases
Paul Querna --- who wrote the initial revprop packing patch (the f5 one, which has been reverted) --- mentions that his use case for revprop packing has vanished due to hardware upgrades (acquiring SSD l2arc disks). With that in mind, what's the fate of the (flat files -based) 'revprop-packing' branch? Will anyone need it by the time 1.8.0 is released? If not, we may forget about the branch and avoid finishing and reintegrating it for 1.8.0.
Re: RE: Proxy authentication with Negotiate uses wrong host
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 (like for LDAP), I would > neglect that and still say TLS is not of your concern but of mine or > the users in general. Any authentication-only mechanism used over an insecure channel is vulnerable to MITM attacks which preserve the authentication and change the data. Of course, this applies to HTTP basic and digest over raw HTTP just as much as it does to negotiate, so perhaps it doesn't make sense to restrict negotiate auth to HTTPS only on this basis alone. A further concern with HTTP negotiate is that it is scoped to the TCP connection and not to a single HTTP request. Ignorant proxies may combine TCP connections for multiple users' requests and inadvertently authenticate one users' requests with anothers' credentials. I may be wrong, but I believe this is the concern which leads implementations to restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not mitigate this concern at all. If there are other vulnerabilities in NTLM which don't presuppose an MITM attack, perhaps I'm wrong.
