ap2021

Incidentally, this is how debugger shows the TByates value in the inspector, under Linux x64: {length = 256, [0] = 133 '#$85', [1] = 21 '#$15', [2] = 119 'w', [3] = 190 '#$be', [4] = 104 'h', [5] = 226 '#$e2', [6] = 237 '#$ed', [7] = 121 'y', [8] = 59 ';', [9] = 71 'G', [10] = 91 '[', [11] = 109 'm', [12] = 252 '#$fc', [13] = 29 '#$1d', [14] = 9 '#$09', [15] = 120 'x', [16] = 163 '#$a3', [17] = 229 '#$e5', [18] = 66 'B', [19] = 46 '.', [20] = 238 '#$ee', [21] = 3 '#$03', [22] = 84 'T', [23] = 236 '#$ec', [24] = 152 '#$98', [25] = 91 '[', [26] = 104 'h', [27] = 33 '!', [28] = 142 '#$8e', [29] = 4 '#$04', [30] = 72 'H', [31] = 180 '#$b4', [32] = 60 '<', [33] = 148 '#$94', [34] = 50 '2', [35] = 207 '#$cf', [36] = 102 'f', [37] = 233 '#$e9', [38] = 226 '#$e2', [39] = 97 'a', [40] = 227 '#$e3', [41] = 53 '5', [42] = 88 'X', [43] = 141 '#$8d', [44] = 32 ' ', [45] = 17 '#$11', [46] = 52 '4', [47] = 109 'm', [48] = 69 'E', [49] = 149 '#$95', [50] = 172 '#$ac', [51] = 45 '-', [52] = 100 'd', [53] = 0 '#$00', [54] = 161 '#$a1', [55] = 197 '#$c5', [56] = 147 '#$93', [57] = 179 '#$b3', [58] = 45 '-', [59] = 185 '#$b9', [60] = 141 '#$8d', [61] = 240 '#$f0', [62] = 119 'w', [63] = 107 'k', [64] = 111 'o', [65] = 35 '#', [66] = 27 '#$1b', [67] = 17 '#$11', [68] = 102 'f', [69] = 122 'z', [70] = 19 '#$13', [71] = 139 '#$8b', [72] = 233 '#$e9', [73] = 15 '#$0f', [74] = 56 '8', [75] = 33 '!', [76] = 105 'i', [77] = 183 '#$b7', [78] = 151 '#$97', [79] = 83 'S', [80] = 19 '#$13', [81] = 37 '%', [82] = 116 't', [83] = 81 'Q', [84] = 169 '#$a9', [85] = 149 '#$95', [86] = 208 '#$d0', [87] = 247 '#$f7', [88] = 211 '#$d3', [89] = 189 '#$bd', [90] = 59 ';', [91] = 51 '3', [92] = 35 '#', [93] = 61 '=', [94] = 227 '#$e3', [95] = 180 '#$b4', [96] = 42 '*', [97] = 105 'i', [98] = 249 '#$f9'} That's all, it cuts it at 99 bytes. I just hope it's only for display, because there are 256 chars there, or supposed to be (Ok, it actually says so in the 1st element of that JSON, if you believe that). Very hard to debug under Linux ;-( I also suspect that strings under Linux may be 0-based and ICS does a lot of "from i := 1 to ..."s all around...

Sorry, it was TBytes. And ICS casts it as PAnsiChar(OldDigest). I think mine has #0 @ 53rd position and I think EVP_DigestVerify only receives the 1st 52 chars as a result, hence this "wrong signature length" error. So it's not StringToTbytes, it's the other way around, but I think this is where the issue is...

Yep, been there, done that, and it's not it here. Looking at IcsAsymVerifyDigestTB function, I think under Linux, TBytes is somehow different (it's shown in the debugger as JSON, with Length as the first element) and PAnsiChar(OldDigest) does not work as intended. For instance, if I do: hash := PAnsiChar(OldDigest); // To AnsiString bhash := TEncoding.ANSI.GetBytes(hash); // To TBytes I end up with garbage, plus it's shorter than it was. Although it could be something else. Trying to figure out what to do about it now. Have you seen anything like this before?

Thanks for your help, I'm now directly at the stage where I'm trying to validate a JWT, but: Signature validation failed error:02000077:rsa routines::wrong signature length error:1C880004:Provider routines::RSA lib error:02000077:rsa routines::wrong signature length error:1C880004:Provider routines::RSA lib Unfortunately, your PemTest project has no comparable functionality to try the vanilla implementation. I'll try adding mine there next. I am using known certs and proven code (under Win64), but still not quite sure, since it's Linux...

I can see that this issue starts for me with OverbyteIcsSslJose, which includes Ics.Posix.PXMessages and there, it hangs on FreeAndNil(GlobalSync) in finalization. Even though GlobalSync was seemingly assigned when I debugged it. Adding try/except around does not change anything. You should be able to reproduce it in your PemTest project, if you add OverbyteIcsSslJose, maybe call something from there so the compiler does not remove it for you, and try closing the application after it starts - it happens on exit. Actually, that unit is not even used there, I could comment it out and see this issue disappear. Please remove Ics.Posix.PXMessages unit reference from OverbyteIcsSslJose. OverbyteIcsSslX509Certs unit also includes Ics.Posix.PXMessages, but probably only not for POSIX, because it does not seem to be causing this issue for me. PS: The RCDATA issue goes away, if the project has FMX defined. Looks like I'm past this issue for now 😉 Thanks for your help, much appreciated!

Just reporting my findings as I go along: I'm certainly on 9.3 now and that "multiple definitions" link error about RCDATA was gone for me for a while. But it's back now, I can't see how yet. I also figured that 1) the library actually loads Ok, with no errors, I could load it from my own test project, then map an exported field and read it - the loading app, when run in a debugger, would typically pick up any errors around missing dependencies and such, plus 2) Apache module is actually supposed to exit right after it starts, because TApacheApplication does not implement a Run method and parent's does nothing, so that's normal - my other module actually does the same, weird as it sounds. A few builds ago, when I had no "multiple definitions" error, I could also confirm that completely removing ICS HttpClient & related units did not fix the original Apache issue, it kept timing out with the same symptoms. So I'm now experimenting with different initialization units' clauses.

Ok, cool, many thanks. It works now 😉 But it turns out I do use ICS HttpClient, so for the original issue I had with Apache, it's still inconclusive: it still fails, whether due to HttpClient or not. I'll try replacing HttpClient with something else next...

That's always the catch, isn't it? I'm in the same boat. I can only spend so much time on these things and when I hit a wall, I soon give up and then maybe circle back a few months later, and so on. When ICS checks these functions, maybe you should skip those it doesn't use/need? Interesting how a seemingly "standard" SSL distro may be missing bits and pieces. Isn't that weird? It's the latest Oracle Linux OpenSSL update for v. 9.2 of Oracle Linux. Seems nobody creates common distros, so every vendor is shipping their own, just doing the best they can. Is there a way to programmatically ask ICS to be more lenient with that stuff? Or maybe you can start building a Linux distro of SSL yourself, like you do for Windows? Or maybe I'll bite the bullet and build one myself, like I do for Windows - safer than relying on others at any rate. I could give you remote access to this VM. Or ship you a 100G BD with a VDI disk (which Hyper-V may be able to import?..

Trying the PemTest project, got: But I do have the library: Although, the name in my case is .3.0.7, not just .3 But there's also a softlink .3 pointing to the right lib as well, so it should certainly be able to find the file. 3.0.7 is the latest available for this OS now. Does this error explain what's going on for you? Maybe I just need to dial the security level up or down to make it work?

I do have /lib64 listed and that does point to /usr/lib64, so that should good. It has v. 3.0 installed, but that should be Ok too, right?

Ok, I'll try, hold on... Where are the SSL libraries are, in your case? For me, they are under /usr/lib64 and I did not have this directory explicitly listed in any of my environment vars, so I can try that next...

Angus, it's "V9.3 beta" - as of maybe 2-3 days ago. I can re-test. I'm not using any protocols there: it's all WebBroker, I only need JOSE stuff - read certificates, sign, validate signature, etc. I could have extra units included, though. Delphi code seemingly works the same under either Ubuntu or RHEL. I'm actually still surprised so many developers default to Ubuntu, when most companies use RHEL, i.e.: who would they be developing for? But this issue is something else. I suspect it could be some init/finalization in some unit(s), but without direct debugging, I cannot see that far...

Andrew, Have you figured out how to read "Environment Variables" (which are really not) in this case? I'm just trying to get access to Apache REMOTE_USER variable now, but will also need access to Client SSL Certificate values later on...