I use Indy 10 build 5438 under Delphi 5 with OpenSSL 1.0.2m.
There is some problem with TLS v1.2 e-mail sending with some (not all) e-mail accounts, and I want to try to upgrade the OpenSSL DLL files for Indy 10, but I do not know which one is compatible.
Which is the latest(!) OpenSSL version that is compatible with Indy 10 build 5438?
I already tried to install the latest Indy 10 build 5519 under Delphi 5 with fulld_5.bat, but it failed:
IdIMAP4.pas(2958) Error: Undeclared identifier: 'LLTextBuf'
IdIMAP4.pas(2958) Error: Incompatible types
IdIMAP4.pas(3185)
IdIMAP4.pas(3697)
IdIMAP4.pas(4209)
IdIMAP4.pas(4721)
IdIMAP4.pas(5233)
IdIMAP4.pas(5745)
IdIMAP4.pas(6257)
IdIMAP4.pas(6769)
IdIMAP4.pas(7251)
IndyProtocols50.dpk(267) Fatal: Could not compile used unit 'IdIMAP4.pas'
Error!
Indy 10 uses standard OpenSSL DLLs. Any 1.0.2 version of OpenSSL is compatible with Indy (Indy does not support OpenSSL 1.1.x yet). However, pre-built versions of OpenSSL 1 (built without MS Visual C++ runtime dependencies) are available on Indy's Fulgan mirror:
https://indy.fulgan.com/SSL
1: At the time of this writing, the latest version available there is 1.0.2t.
As for the IdIMAP4.pas error, that was a typo in a recent code checkin. On line 2958, the reference to LLTextBuf needs to be changed to LTextBuf instead.
LUseNonSyncLiteral := LCanUseNonSyncLiteral and ((not LNonSyncLiteralIsLimited) or (Length({LLTextBuf}LTextBuf) <= 4096)); // <-- change LLTextBuf to LTextBuf
I have now fixed that in the official Indy code (SVN revision 5520).
Related
I have an application rpm which when installed is failing to get installed with error
error: Failed dependencies:
libc.so.6 is needed by testSam-4.7.x86_64
libc.so.6(GLIBC_2.0) is needed by testSam-4.7.x86_64
libc.so.6(GLIBC_2.1) is needed by testSam-4.7.x86_64
The system has RHEL 7.3 with glibc 2.17.
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)
# rpm -qf /lib64/libc.so.6
glibc-2.17-157.el7.x86_64
So the application built using older glibc(it needs glibc between 2.0 and 2.1) is failing to run on a system having newer glibc 2.17.
How to get rid of this issue and run the application on systems having newer glibc?
I guess there are some glibc backward compatibility packs which will help us run such applications on systems having newer glibc.
From where can I download such compatibility packs?
Despite the package name of testSam-4.7.x86_64 , there are probably some binaries in that rpm that are NOT 64 bit, but built as 32 bit. You might need to install the glibc.i686 package first
If there is a 32 bit executable or library in the package it will add a dependency on libc.so.6 , while 64 bit executables adds a dependency on libc.so.6(64bit)
I'm trying to install the Intel XDK for Linux under CentOS 7.3 (7.3.1611)
But I'm facing a problem witch I'm not able to solve:
Message:
GTK library is not installed or installed version is not compatible
The GTK library is not installed or installed version of the library is not compatible. The graphical user interface of the product requires gtk version 2.20 or higher. Contact your system administrator to install a compliant version of gtk for the INTEL64 architecture or install the product on a compliant system.
In my OS, I've already gtk+ 2.4 installed, but the installer of Intel XDK can't see the package.
I've these packages installed:
yum install gtk*:
Package gtk2-2.24.28-8.el7.x86_64 already installed and latest version
Package gtk2-devel-2.24.28-8.el7.x86_64 already installed and latest version
Package gtk2-devel-docs-2.24.28-8.el7.x86_64 already installed and latest version
Package gtk3-3.14.13-20.el7.x86_64 already installed and latest version
Package gtk3-devel-3.14.13-20.el7.x86_64 already installed and latest version
Is there a way to solve this problem ?
My OS X app uses the OpenSSL libraries, both the libssl and libcrypto libraries. The specific version of OpenSSL libraries it has been using is the one provided in OS X, namely /usr/lib/libssl.dylib and /usr/lib/libcrypto.dylib and currently at version OpenSSL 0.9.8zg, and my app has been working fine.
Since I want to use TLS 1.2 in my app, and the OpenSSL libraries provided in OS X, at version OpenSSL 0.9.8zg, do not support it, I want to use the OpenSSL libraries at version OpenSSL 1.0.2d, available in source at the OpenSSL site, in my app.
Toward the goal of upgrading the OpenSSL libraries in my app to version OpenSSL 1.0.2d, I built the OpenSSL libraries from source and compiled my app with them successfully. However, the resulting app didn't function properly, and I don't know why. Running the resulting app, SSL_connect() always returned an error, and the subsequent call to SSL_get_error() always returned SSL_ERROR_SSL. This was the case for the libraries being dynamic libraries or static libraries. More strangely, I got the same result when I used OpenSSL 0.9.8zg libraries built from the source in building my app.
Anyone have a solution or explanation to the problem I am facing?
It turned out that there was actually no problem in the OpenSSL libraries I built. The problem I encountered was caused by a cert. For some reason, the problem only occurred when the new version of OpenSSL was used. Replacing the cert removed the problem.
I'm having this issue when committing to SourceForge using TortoiseSVN:
https://sourceforge.net/p/forge/site-support/2636/
The feedback on that page recommends using SSH to get around the problem. So, I relocated my repository to this URL per the recommendation:
svn+ssh://mikh2161#svn.code.sf.net/p/datsville/code
My username is mikh2161 and the project is called "datsville". When I try to connect it asks me for my password, which I then enter. It seems to work okay. However, the actual commit fails with this error:
Commit failed (details follow):
Stream doesn't support this capability
Polling for available data on filestream failed: Bad file descriptor
Can anyone assist me? What am I doing wrong? Thanks!
I'm running Windows 7 Pro x64.
TortoiseSVN 1.9.0, Build 26652 - 64 Bit , 2015/08/03 19:33:09
Subversion 1.9.0, -release
apr 1.5.2
apr-util 1.5.4
serf 1.3.8
OpenSSL 1.0.2d 9 Jul 2015
zlib 1.2.8
SQLite 3.8.11.1
Looks like svn+ssh support is broken in 1.9.0.
I removed that, and used 1.8.11 instead, and it worked.
This problem is caused by the Subversion client libraries for Windows. It was introduced with version 1.9.0, and the fix will be released with 1.9.1 [1] [2] . So any windows client that is using it will not work with svn+ssh. TortoiseSVN is just one example, the same was observed with JavaHL/Subclipse, SmartSVN and the Subversion command line client itself.
Update: A downgrade to version 1.8.12 (which was released along with 1.9.0) helped in my case.[3]
[1] Subversion Dev: JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors
[2] fixed with r1696225 (there is obviously no bug filed yet)
[3] TortoiseSVN - Browse Files at SourceForge.net
I have set up CollabNet Subversion and now I am trying to check-out some repository from my Mac 10.8.2. I have checked-out the repository successfully from a Windows 7 using the exact same command on the same network:
svn co https://myserver.com/svn/repository repository --username=USERNAME
On Mac OS I get the error:
svn: OPTIONS of 'https://myserver.com/svn/repository': SSL handshake failed: SSL error code -1/1/336032856 (https://myserver.com)
BTW: I can access the repository from the Safari Browser with the same URL.
I could not find anything about the error code.
I am running on Mac OS 10.8.2
svn, version 1.6.18 (r1303927)
compiled Aug 4 2012, 19:46:53
OpenSSL 1.0.1c 10 May 2012
which all came with the XCode Developer Tools.
Has anybody an idea what is going on or can recommend any solutions?
The SubvesionEdge Server software version is: 3.2.2-3395.103 with Subversion version: 1.7.8-3395.103, OpenSSL on Server: 1.0.0j
Who was able get svn check-out working on Mac OS 10.8.2 and which version of svn, openssl and SubversionEdge did you use?
Thanks,
Nelson
That error code looks bogus (336032856 is 0xC84A8B70):
$ openssl errstr 0xC84A8B70
error:C84A8B70:lib(200):func(1192):reason(2928)
Usually you get a somewhat useful string, like the reason, the source file and line number.
OpenSSL on Server: 1.0.0j
That's a TLS 1.1 server.
OpenSSL 1.0.1c 10 May 2012
That's a TLS 1.2 client.
They should inter-operate OK.
Try dropping the --username=USERNAME, and let svn prompt you for it when needed.
Did you get prompted to trust the the certificate? Perhaps the SVN server is misconfigured.
Finally, Super User might be a better place for this. (I personally don't care, but there are folks who like to close questions and downvote for any reason. They hunt in packs).