Re: SVN repository("db") permissions has been reverted after performing the commit
You need to get off RHEL 6. The subversion there is now outrageously old, and cannot be gracefully upgraded to a supported release. I know because I tried, I used to publish the repoforge packages for subversion. That said I’d check your subversion for known bugs, the umask for the httpd user or svnserve daemon owner or svn+ssh access, and system problems like failing storage. Sent from my iPhone > On Jul 24, 2019, at 1:20 AM, ramesh penumalli wrote: > > Dear Team, > > We have installed scm-manager ( V1.6) on our RHEL6 server and configure > SVN repositories. When we tried to commit the code into any svn repository, > then permissions of the files "current" and "txn-current" under the folder > "db" of the repository are changing to 600 (-rw-.) from 774. > > Due to this permissions issue, the SVN repository is failing to connect > corresponding repository in Fisheye and then users are unable to see their > code reviews in Fisheye and Crucible servers. > > I would your quick help to find the root cause of the issue and the > resolution steps to resolve the query. > > Kindly let me know in case if you would need any information to resolve this > issue. > > Thanks and Regards, > Ramesh Penuballi
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Le sam. 20 juil. 2019 à 20:54, Daniel Shahaf a écrit : > > Stefan Sperling wrote on Sat, 20 Jul 2019 09:51 +00:00: > > But as a user I find it infuriating when software I use contains > > artificial restrictions like this. We should assume our users know > > what they are doing. Subversion is not a web browser. > > I'm not entirely sure I'm convinced by this logic. Let's take OpenSSH for > example: > > [[[ > % ed .ssh/known_hosts > g/^hermes/d > s/^[^ ]*/hermes.apache.org/ > w > q > % ssh hermes.apache.org > @@@ > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that a host key has just been changed. > The fingerprint for the ECDSA key sent by the remote host is > SHA256:gJUlDrKOTnUQ/lAx6eM4Ylq6z/5ere2tJoLEgrfM++A. > Please contact your system administrator. > Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this > message. > Offending ECDSA key in /home/daniel/.ssh/known_hosts:26 > remove with: > ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R hermes.apache.org > ECDSA host key for hermes.apache.org has changed and you have requested > strict checking. > Host key verification failed. > zsh: exit 255 ssh hermes.apache.org > ]]] > > The error message does not give a way to continue the operation, but it > does tell you what command to run if you would like to proceed anyway. > This way, the buck stops with the user, but the program makes it quite > clear that this is an abnormal situation and caution should be > exercised. > > Should we do something similar (but without the all-caps? That's why > I proposed writing a command that takes a certificate on stdin and marks > it as trusted. > > Daniel >From a user perspective, I would also appreciate to be able to take my responsibilities to accept unsafe operations. Having the choice to can accept permanently the certificate, and then getting a special warning message to confirm I really know what I do, because there is unknown errors reported, would definitively help to report the responsibilities on the users while let him/her chose to take (or not) the said responsibilities. Best Regards, Pierre.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Le sam. 20 juil. 2019 à 16:55, Nico Kadel-Garcia a écrit : > > On Fri, Jul 19, 2019 at 7:41 AM Pierre Fourès wrote: > > > > Hi all, > > > > I have a script accessing an old svn server whom SSL certificate have > > expired a long time ago. Up to now, I was permanently accepting the > > certificate on the first run of the script and then everything was > > sailling smooth. I reinstalled a couple of months ago a new box where > > this script was intented to run and the (p)ermanently option seems not > > provided anymore. > > Negotiating certificate trust can be fun. Can you sidestep the whole > issue by switching to svn+sh? Or get new, signed certificates? > > > Thankfully, I still have the "old" running box to double-check, and > > the (p)ermanently option is still present. Both boxes are Debian > > Buster (but was installed as unstable, before the official release). > > The (p)ermanently option was also present in svn on previous versions > > of Debian. > > > > I can notice that the versions of svn changed between my old and new > > box from 1.10.2 to 1.10.4. Nonetheless, I gave a look at the > > change-log [1] and it doesn't seem specified this option has been > > removed. I also gave a look on openssl version and it went upgraded > > from 1.1.0h to 1.1.1b, but I have no clue to evaluate if the removal > > of the (p)ermanently option is linked or not the openssl upgrade. > > > > If some of you have an hint and an half to explain how and why this > > option disapeared, that would be really nice. I wonder if it was meant > > or not, to see where I'm headed. > > > > More over, I would really appreciate if someone could share a solution > > to still permanently accept the certificate on the new box, as for > > now, I can't use this box and the old one should soon be > > decommissioned. > > Stefan has correctly pointed out ways to get your client, at run-time, > to accept failed certificates. But what is stopping you from replacing > the certificate? It's on the todo-list for quite a long time but never find it ways to get to prime time. We decided to migrate this server to a new infrastructure and it will benefits from automatically renewed Let's Encrypt certificates. That will eventually address all points. But as things works well and wouldn't add significant benefits, we didn't haven't scheduled the operation so far. The server is running smooth and used only for internal use, so by the time Let's Encrypt wasn't here, we didn't felt to spent some money on buying a certificate from a trusted authority. As self certificates (rightly) reported an error, we already had to « accept permanently » the certificate when we was re-configuring a new client instance. Then the certificate expired. This added one line in the warnings, but didn't really change a thing for us, so we didn't felt the urge to renew the certificate. We knew which it was and we trusted it. More over, the encountered problem seems that the self-signed certificate switched from being reported as "not trusted" to "unknown error". The cause then seems rooted in the self certification, so I'm not sure issuing a new self-signed certificate would solve the problem ? Best Regards, Pierre.
Re: Is Permanently Accept SSL Certificate gone in 1.10.4 ?
Le ven. 19 juil. 2019 à 20:44, Stefan Sperling a écrit : > > On Fri, Jul 19, 2019 at 08:38:57PM +0200, Stefan Sperling wrote: > > On Fri, Jul 19, 2019 at 01:40:52PM +0200, Pierre Fourčs wrote: > > > Hi all, > > > > > > I have a script accessing an old svn server whom SSL certificate have > > > expired a long time ago. Up to now, I was permanently accepting the > > > certificate on the first run of the script and then everything was > > > sailling smooth. I reinstalled a couple of months ago a new box where > > > this script was intented to run and the (p)ermanently option seems not > > > provided anymore. > > > > If you're scripting 'svn' you should be using the --non-interactive option. > > > > In which case your script can use the --trust-server-cert-failures > > option to accept a cert in pre-determined failure cases. > > > > 'svn help update', for example, displays the following information > > section about the --trust-server-cert-failures option: > > > > --trust-server-cert-failures ARG : with --non-interactive, accept SSL > > server > > certificates with failures; ARG is > > comma-separated > > list of 'unknown-ca' (Unknown Authority), > > 'cn-mismatch' (Hostname mismatch), 'expired' > > (Expired certificate), 'not-yet-valid' (Not yet > > valid certificate) and 'other' (all other not > > separately classified certificate errors). > > > > Once your script uses this option it should work out of the box against > > your problematic server and there should be no need to save the cert. > > Follow-up regarding your actual question: > > It looks like the interactive prompt omits an option to save the cert > if it sees a certificate failure of class 'other' from the above list. > I am not sure why this decision was made but that's what the current > code seems to do. So I suspect your SSL cert is failing for some reason > other than unknown-ca, cn-mismatch, expired, not-yet-valid. > > Additionally, the ability to save a cert is also disabled if the > --no-auth-cache option is used. Hi, Sorry for the delay and thanks a lot for the answers. In fact, I did read about the non-interactive option but this question [1] made me thought it wouldn't work. Having tried with --trust-server-cert and got errors, I thought this was it. I didn't saw there also was a --trust-server-cert-failures. I should have better read the docs and see one can specify the nature of the error to silent in order to consider the certificate as trustable ! I'm now able to proceed in non-interactive mode on the new instance accessing the svn-server. Thanks. However, I couldn't find a way to store the password. Of course, this is non-interactive mode. Nonetheless, could it be a way to store the credentials ? If so this would save me some time to tweak the scripts (and the need to export credentials variables before running the scripts). About the interactive prompt omitting the (p)ermanently save in case of 'other' errors, you're right on spot, the class 'other' appeared as reported errors in the instance running 1.10.4. I did a little more investigation now that I better understand the inner functioning of the certificate validation. What's really strange is that the error nature changed from svn 1.10.2 to 1.10.4 while accessing the same svn server, and thus, the same certificate. It's a self signed certificate, and is rightly considered so in 1.10.2, as not trustable, but is reported as an unknown certificate error in 1.10.4 (as the logs attests). This would clearly explain why the (p)ermanently option disappeared. Nonetheless, I wonder why « unknown authority error » is now reported as « other error » in 1.10.4. Was it meant or is it a regression ? pierre@edtv-01-pierre:~$ svn --version svn, version 1.10.2 (r1835932) compiled Aug 4 2018, 16:28:03 on x86_64-pc-linux-gnu pierre@edtv-01-pierre:~$ LANG=C svn co https://svn.---.fr/--- --- Error validating server certificate for 'https://svn.---.fr:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! - The certificate hostname does not match. - The certificate has expired. (R)eject, accept (t)emporarily or accept (p)ermanently? pierre@edtv-08-pierre:~$ svn --version svn, version 1.10.4 (r1850624) compiled Jan 23 2019, 03:41:34 on x86_64-pc-linux-gnu pierre@edtv-08-pierre:~$ LANG=C svn co https://svn.---.fr/--- --- Error validating server certificate for 'https://svn.---.fr:443': - The certificate hostname does not match. - The certificate has expired. - The certificate has an unknown error. Certificate information: (R)eject or accept (t)emporarily? Best Regards, Pierre. [1] https://unix.stackexchange.com/questions/318169/svn-automatically-accept-server-certificate
