Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Indy OpenSSL Sicherheitsupdates (https://www.delphipraxis.net/114945-indy-openssl-sicherheitsupdates.html)

KodeZwerg 3. Jul 2020 13:56

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von NoGAD (Beitrag 1468811)
Vielleicht liegt es an der ICS - Version.

Dann mal über wiki.openssl.org probieren. Dort sind verschiendene vorkompilierte über externe Links zu bekommen.
Bei slproweb.com (gleich das erste der wiki links) auch per MSI Installer.
Die Unterschiede kenne ich leider nicht gegenüber der relativ kleinen Overbyte zip Datei.

Ich hoffe eine der Anbieter hat das was Du benötigst um weiter glücklich sein zu können, "offiziell" halt immer über "https://indy.fulgan.com/SSL/", was lange nicht aktualisiert wurde.

MAXON 28. Aug 2020 13:28

AW: Indy OpenSSL Sicherheitsupdates
 
Leider ist das Indy Package corrupt auf indy.fulgan.com
Sieht seit August sehr gerupft aus die FTP Site...

Wohl den Spass verloren...

Codehunter 28. Aug 2020 16:32

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von MAXON (Beitrag 1472545)
Leider ist das Indy Package corrupt auf indy.fulgan.com
Sieht seit August sehr gerupft aus die FTP Site...

Wohl den Spass verloren...

Soweit ich weiß ist Fulgan schon länger nicht mehr Sponsor von Indy. Der richtige Link lautet https://www.indyproject.org/download/

HolgerX 29. Aug 2020 08:05

AW: Indy OpenSSL Sicherheitsupdates
 
Hmm..

Zitat:

Zitat von Codehunter (Beitrag 1472561)
Zitat:

Zitat von MAXON (Beitrag 1472545)
Leider ist das Indy Package corrupt auf indy.fulgan.com
Sieht seit August sehr gerupft aus die FTP Site...

Wohl den Spass verloren...

Soweit ich weiß ist Fulgan schon länger nicht mehr Sponsor von Indy. Der richtige Link lautet https://www.indyproject.org/download/

Wenn ich versuche über indyproject.org einen Download (zip) zu machen, werde ich aber unweigerlich nach indy.fulgan.com verwiesen.
Alle Links für Developer Snapshots landen auf nicht mehr vorhandenen Seiten. Einzig 'https://github.com/IndySockets/Indy' ist nach langem suchen zu finden.
Also ist die Seite auch nicht wirklich Zielführend....

Codehunter 29. Aug 2020 14:03

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von HolgerX (Beitrag 1472580)
Wenn ich versuche über indyproject.org einen Download (zip) zu machen, werde ich aber unweigerlich nach indy.fulgan.com verwiesen.

Stimmt nicht. Link siehe oben. Dann Other Downloads -> SSL Libraries -> SSL DLL Download -> Archive on Github

HolgerX 31. Aug 2020 17:46

AW: Indy OpenSSL Sicherheitsupdates
 
Hmm..

Zitat:

Zitat von Codehunter (Beitrag 1472600)
Zitat:

Zitat von HolgerX (Beitrag 1472580)
Wenn ich versuche über indyproject.org einen Download (zip) zu machen, werde ich aber unweigerlich nach indy.fulgan.com verwiesen.

Stimmt nicht. Link siehe oben. Dann Other Downloads -> SSL Libraries -> SSL DLL Download -> Archive on Github

Dass mag zwar für die DLLs gelten, jedoch die 'Developer Snapshots' als Zip gehen nicht mehr und deren Links laufen ins Leere..

Codehunter 31. Aug 2020 18:08

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von HolgerX (Beitrag 1472687)
Dass mag zwar für die DLLs gelten, jedoch die 'Developer Snapshots' als Zip gehen nicht mehr und deren Links laufen ins Leere..

Das ist doch nun wirklich nicht schwer... https://github.com/IndySockets/Indy

ioster 21. Jun 2021 22:05

AW: Indy OpenSSL Sicherheitsupdates
 
Moin,

ich benötige für eine Programmfunktion eine HTTPS-Verbindung zu einem Datenserver, die ich gerne mit IdHTTP-Komponente aus Indy10 (Delphi 10.3) umsetzen würde.

Ich dachte, die Abfrage relativ schnell umsetzen zu können, doch ich habe nicht mit den Unzulänglichkeiten der IDE gerechnet. Man sollte meinen, dass HTTPS heute als Standard angesehen wird.

Als die Meldung "SSL-Bibliothek konnte nicht geladen werden." auf dem Bildschirm erschien, suchte ich zunächst vergeblich in den Eigentschaften der Komponente nach der Lösung. Google sagte mir dann, man müsse die libeay32.dll und ssleay32.dll in sein Programmverzeichnis kopieren, um das Protokoll nutzen zu können.

Die Vorgehensweise wird u.a. in einem Tutorial auf dieser Forenseite beschrieben. Nur dumm, dass die Links zu den DLLs überall veraltet sind. Indy Project verweist aua urheberrechtlichen Gründen auf GitHub als Downloadseite.

Nur was soll man hier nun auswählen? Ist das der letzte Stand und wie erfährt man von möglichen Updates?

Ich wäre für aktuelle Infos mehr als dankbar. Der Zeitaufwand für die bisherige Recherche, die in vielen toten Links endete, war nicht ohne.

Danke im Voraus.
Ingo

Codehunter 21. Jun 2021 23:01

AW: Indy OpenSSL Sicherheitsupdates
 
Das kann ich gut verstehen. Die Situation mit den Win32-Binaries für OpenSSL ist wirklich nicht schön. Darüber habe ich mich auch schon oft geärgert. Also ich verwende die 1.0.2s mit Indy 10. Die letzte Minor-Version aus dem 1.0.2-Zweig ist die "u". Dabei jeweils auf 32- und 64 Bit achten, je nach Bedarf. Da musst du auch aufpassen wenn du dein Programm auslieferst, weil die Dateinamen der DLLs bei 32 und 64 Bit identisch sind.

Soweit ich weiß braucht Indy 10 keine speziellen OpenSSL-DLLs mehr, wie es noch bei Indy 9 der Fall war. Man könnte sie also aus den offiziellen Quellen selbst kompilieren. Was ich aber noch nie gemacht habe mangels tieferes Wissen über C++.

Wirklich ein Problem ist aber, dass Indy so weit hinten dran ist mit der Unterstützung für OpenSSL 1.1.1. Schließlich ist der 1.0.2-Zweig schon seit zwei Jahren aus dem aktiven Support raus. Es gibt inzwischen lauffähige Entwicklersnapshots, aber stabil ist das IMHO noch nicht.

ioster 22. Jun 2021 07:03

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von Codehunter (Beitrag 1491347)
Das kann ich gut verstehen. Die Situation mit den Win32-Binaries für OpenSSL ist wirklich nicht schön. Darüber habe ich mich auch schon oft geärgert. Also ich verwende die 1.0.2s mit Indy 10. Die letzte Minor-Version aus dem 1.0.2-Zweig ist die "u". Dabei jeweils auf 32- und 64 Bit achten, je nach Bedarf. Da musst du auch aufpassen wenn du dein Programm auslieferst, weil die Dateinamen der DLLs bei 32 und 64 Bit identisch sind.

Soweit ich weiß braucht Indy 10 keine speziellen OpenSSL-DLLs mehr, wie es noch bei Indy 9 der Fall war. Man könnte sie also aus den offiziellen Quellen selbst kompilieren. Was ich aber noch nie gemacht habe mangels tieferes Wissen über C++.

Wirklich ein Problem ist aber, dass Indy so weit hinten dran ist mit der Unterstützung für OpenSSL 1.1.1. Schließlich ist der 1.0.2-Zweig schon seit zwei Jahren aus dem aktiven Support raus. Es gibt inzwischen lauffähige Entwicklersnapshots, aber stabil ist das IMHO noch nicht.

Moin Codehunter,

vielen Dank für Deine Ausführungen, die für mich ein wenig Licht ins Dunkel bringen. Ich werde es mit den 1.0.2u einfach ausprobieren. Sollte es nicht funktionieren, muss ich die Anforderung vorerst zurückstellen.

Viele Grüße
Ingo

mezen 22. Jun 2021 07:09

AW: Indy OpenSSL Sicherheitsupdates
 
@ioster:
TLS ist kein leichtes Protokoll und bringt einige Eigenschaften mit sich, TLS ist schwierig "mal eben" zu begreifen und entsprechend dem Verständnis sinnhaft und zielgerichtet einzusetzen.

Aktuelle Infos kurzgefasst:
  • Indy nutzt OpenSSL
  • Indy 9 brauchte spezielle OpenSSL Binaries, welche für Indy angepasst waren. Indy 10 braucht das nicht mehr und es reichen unveränderte aus
  • Mitgeliefertes Indy kann nur maximal OpenSSL 1.0.2 (und daher TLS 1.2)
  • OpenSSL 1.0.2 ist Ende 2019 aus dem Support gefallen und wird nicht mehr mit Sicherheitsupdates versorgt
  • Aktuell neuste und stabile Version ist OpenSSL 1.1.1, Vorgänger war OpenSSL 1.1.0, dessen Vorgänger OpenSSL 1.0.2 war
  • Nachfolger OpenSSL 3 ist aktuell frisch in der Beta, nach etwas über 1 Jahr in der Alpha
  • Bisher genutzten OpenSSL Binaries wurden von https://opendec.wordpress.com/ erstellt, welcher seine Build Umgebung nicht mehr auf Versionen nach 1.0.2 umgestellt hat
  • OpenSSL Version 1.1.0 hat API Änderungen gegenüber OpenSSL 1.0.2, was auch Änderungen in Indy selber benötigt

So weit, so schlecht die Infos.
Aber es gibt weiterhin Hoffnung: Es gibt bereits Anpassungen für Indy, damit Indy auch OpenSSL 1.1.1 nutzen kann: https://www.delphipraxis.net/204185-...tls-1-3-a.html. Dies befindet sich noch im GitHub PR und wartet darauf, dass es nach Indy gemergt wird. Die Änderung läuft auch stabil, ist bei unseren Kunden bereits dauerhaft aktiv und viel genutzt.

@ioster:
Du willst dir vllt als Alternative THttpClient von Emba angucken. Dies ist ein Versuch mittels System APIs, und nicht mit Indy, HTTP nutzbar zu machen. Und das sogar plattformübergreifend (was Indy ja auch bereits kann). Auf Windows wird dafür auf die WinAPIs für WinHTTP zurück gegriffen. Somit brauchst du keine OpenSSL DLLs, da Windows das eigene SChannel nutzt.

@Codehunter:
Danke für deinen Bump bei meinem MR. Aktuell laufen die Änderungen gut, wie ich schrieb, auch schon bei unseren Kunden im Einsatz. Ich muss nur halt warten bis Remy mit dem Review fertig ist. Da er aber nur rein den Code anguckt, und das doch ein paar viele Zeilen beinhaltet, dauert das leider. Mehr kann ich leider nicht tun.

philipp.hofmann 22. Jun 2021 07:09

AW: Indy OpenSSL Sicherheitsupdates
 
Und falls es nicht unbedingt Indy sein muss: bei der Implementierung mit TNetHTTPClient (und TNetHTTPRequest) wird automatisch https über die vorhandenen OS-Komponenten gelöst. Das ist deutlich zukunftssicherer, geht aber nicht für alle Anwendungsfälle.

ioster 22. Jun 2021 07:17

AW: Indy OpenSSL Sicherheitsupdates
 
Moin,

ich muss nochmal stören. Die DLLs aus dem 1.0.2u-Paket haben schon ein wenig gefruchtet. Allerdings bekomme ich nun die Meldung, dass ich meine Anfrage mit der falschen Protokollversion sende.

Die Meldung lautet:

Fehler beim Verbinden mit SSL.
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
protocol version.

Laut Dienstanbieter sollen die Anfragen mit TLS 1.2 erfolgen sollen. Hat jemand sich damit schon auseinandergesetzt?

Danke
Ingo

mezen 22. Jun 2021 08:40

AW: Indy OpenSSL Sicherheitsupdates
 
TIdHTTP erstellt sich einen eigenen TIdSSLIOHandlerSocketOpenSSL, sofern man nicht selber einen IOHandler zuweist. Dieser selbsterstellte hat aber nur die Default Eigenschaften was TLS 1.0 entspricht.
Erzeuge einen eigenen TIdSSLIOHandlerSocketOpenSSL und setze dort SSLOptions.SSLVersions := [sslvTLSv1_2] (SSLOptions.Method ist deprecated und Überbleibsel aus Indy 9)

ioster 22. Jun 2021 09:08

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von mezen (Beitrag 1491361)
TIdHTTP erstellt sich einen eigenen TIdSSLIOHandlerSocketOpenSSL, sofern man nicht selber einen IOHandler zuweist. Dieser selbsterstellte hat aber nur die Default Eigenschaften was TLS 1.0 entspricht.
Erzeuge einen eigenen TIdSSLIOHandlerSocketOpenSSL und setze dort SSLOptions.SSLVersions := [sslvTLSv1_2] (SSLOptions.Method ist deprecated und Überbleibsel aus Indy 9)

Hallo mezen,

vielen Dank. Das hat mir weitergeholfen. Parallel dazu habe ich in einem anderen Forum eine Quellcode gefunden, der die Erstellung eines IOHandlers beschreibt.

Die Abfrage funktioniert jetzt bestens, aber wie soll es auch anders sein - es baut sich das nächste Hindernis auf, das Parsen des XML-Rückgabewerts. Es ist faszinierend, wie man sich in dem Thread "XML parsen, aber wie" über das Für und Wider eines XML-Parsers streitet, doch letztlich hat man auf der 3. Seite wieder einen Cliffhanger.

Viele Grüße
Ingo

Codehunter 22. Jun 2021 09:36

AW: Indy OpenSSL Sicherheitsupdates
 
@mezen: So wie ich die Kommentare bei Github verstanden habe ist das aktuell größte Problem, dass es Remy den Rechner zerledert hat. Deshalb stagniert da alles. Das offenbart wieder einmal das Problem kleiner Open-Source-Projekte: Es gibt nur wenige (einen?) Maintainer. Fällt da jemand aus, kann alles über die Wupper gehen. Mir sind die Indy-Eingeweide allerdings zu kompliziert, als dass ich mich da einbringen könnte. Mir hats schon gereicht damals den Byteshift-Bug zu finden :pale:

@ioster: Nein, du willst dir nicht THttpClient als Alternative anschauen :-D Ich habs versucht, wirklich viel Zeit in eine Portierung weg von Indy gesteckt und am Ende nur Ärger gehabt. Womit? TLS natürlich! Warum? Microsoft hatte mal wieder buggy Updates rausgegeben, die defekte Stromchiffren enthielten. Und schon glühte bei uns die Hotline weil die Kunden nicht mehr auf ihre Cloudserver kamen. Dann doch lieber Indy mit veraltetem aber funktionierendem OpenSSL.

Bei den XML-Parsern ist das ganz einfach: Es gibt so viele verschiedene, weil sie alle unterschiedliche Anforderungen erfüllen. Es gibt "fette" Parser mit unheimlichen vielen Features, die aber langsam sind. Und es gibt "schlanke" schnelle Parser, wo man aber viel Aufwand hat, Daten auszulesen. Kommt also darauf an, wie groß deine XML-Dokumente sind. Bei kleiner 1 MB kannst du nehmen was du willst. Darüber sollte man ausgiebig testen welcher Parser geeignet ist. Denn da gibts kein Patentrezept.

ioster 22. Jun 2021 09:49

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von Codehunter (Beitrag 1491367)
@mezen: So wie ich die Kommentare bei Github verstanden habe ist das aktuell größte Problem, dass es Remy den Rechner zerledert hat. Deshalb stagniert da alles. Das offenbart wieder einmal das Problem kleiner Open-Source-Projekte: Es gibt nur wenige (einen?) Maintainer. Fällt da jemand aus, kann alles über die Wupper gehen. Mir sind die Indy-Eingeweide allerdings zu kompliziert, als dass ich mich da einbringen könnte. Mir hats schon gereicht damals den Byteshift-Bug zu finden :pale:

@ioster: Nein, du willst dir nicht THttpClient als Alternative anschauen :-D Ich habs versucht, wirklich viel Zeit in eine Portierung weg von Indy gesteckt und am Ende nur Ärger gehabt. Womit? TLS natürlich! Warum? Microsoft hatte mal wieder buggy Updates rausgegeben, die defekte Stromchiffren enthielten. Und schon glühte bei uns die Hotline weil die Kunden nicht mehr auf ihre Cloudserver kamen. Dann doch lieber Indy mit veraltetem aber funktionierendem OpenSSL.

Bei den XML-Parsern ist das ganz einfach: Es gibt so viele verschiedene, weil sie alle unterschiedliche Anforderungen erfüllen. Es gibt "fette" Parser mit unheimlichen vielen Features, die aber langsam sind. Und es gibt "schlanke" schnelle Parser, wo man aber viel Aufwand hat, Daten auszulesen. Kommt also darauf an, wie groß deine XML-Dokumente sind. Bei kleiner 1 MB kannst du nehmen was du willst. Darüber sollte man ausgiebig testen welcher Parser geeignet ist. Denn da gibts kein Patentrezept.

Moin Codehunter,

ich möchte eigentlich so gut und schnell wie möglich zum Ziel kommen und stoße selbst mit zusätzlich erworbenen VCL-Komponenten leider immer wieder an (meine?) Grenzen, weil die Dokumentationen dürftig sind und Support nur bedingt geleistet wird. Es gibt solche und solche Anbieter. Ich möchte mich auf die Entwicklung einer Anwendung konzentrieren können und mich nicht unbedingt in tiefschürfende Dokumente über XML oder Ähnliches einlesen müssen.

Indy ist im Augenblick für HTTP erste Wahl, weil es zum Delphi-Paket gehört und weit verbreitet ist. Für den Mailversand habe ich mir schon EasyMAPI gegönnt, da die Komponenten eher die Kundenanforderungen erfüllten.

Jetzt steht für mich eben XML parsen auf der ToDo-Liste, wobei ich genau dieselbe Quelle des Bundeszentralamtes für Steuern anzapfen möchte, die im benannten Thread untersucht wird. Hier vielleicht offTopic, aber über mit welcher Methode komme ich an einen bestimmten Parameter in einem solchen XML-Dokument? Ich möchte eben nicht über String-Funktionen wie Pos oder PosEx nach den Schlüsselbegriffen suchen müssen, wenn ich schon ein XMLDocument vor mir habe.

Viele Grüße
Ingo

Codehunter 22. Jun 2021 09:56

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von ioster (Beitrag 1491368)
Jetzt steht für mich eben XML parsen auf der ToDo-Liste, wobei ich genau dieselbe Quelle des Bundeszentralamtes für Steuern anzapfen möchte, die im benannten Thread untersucht wird. Hier vielleicht offTopic, aber über mit welcher Methode komme ich an einen bestimmten Parameter in einem solchen XML-Dokument? Ich möchte eben nicht über String-Funktionen wie Pos oder PosEx nach den Schlüsselbegriffen suchen müssen, wenn ich schon ein XMLDocument vor mir habe.

Dafür solltest du einen extra Thread aufmachen. Oder dir ggf. mal vom Gockel bzw. der DP-Suche was über IXMLDocument und XPath erzählen lassen. Für einfache XML-Dokumente ist das der schnellste Weg. Ich habe mir vor einiger Zeit einen Klassenaufsatz für TXmlDocument geschrieben, mit dem ich per XPath auch Attribute und Namespaces verarbeiten kann. Aber das würde hier zu weit führen.

zeras 22. Jun 2021 17:29

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von ioster (Beitrag 1491368)
Jetzt steht für mich eben XML parsen auf der ToDo-Liste, wobei ich genau dieselbe Quelle des Bundeszentralamtes für Steuern anzapfen möchte, die im benannten Thread untersucht wird. Hier vielleicht offTopic, aber über mit welcher Methode komme ich an einen bestimmten Parameter in einem solchen XML-Dokument? Ich möchte eben nicht über String-Funktionen wie Pos oder PosEx nach den Schlüsselbegriffen suchen müssen, wenn ich schon ein XMLDocument vor mir habe.

Viele Grüße
Ingo

Hast du schon versucht, dir über Delphi eine Klasse zusammenbauen zu lassen? Du musst nur eine gültige XML Datei haben und da baut dir Delphi das Gerüst rundherum.
Aber vielleicht kennst du das ja alles schon.
Ich habe das für verschiedene Projekte schon genutzt.

TiGü 23. Jun 2021 08:32

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von zeras (Beitrag 1491399)
Hast du schon versucht, dir über Delphi eine Klasse zusammenbauen zu lassen? Du musst nur eine gültige XML Datei haben und da baut dir Delphi das Gerüst rundherum.
Aber vielleicht kennst du das ja alles schon.
Ich habe das für verschiedene Projekte schon genutzt.

Die Möglichkeit ist erst seit gestern bekannt:
https://www.delphipraxis.net/192207-...ber-wie-4.html

DeddyH 23. Jun 2021 09:20

AW: Indy OpenSSL Sicherheitsupdates
 
Das ist jetzt aber nicht mehr Thema dieses Threads :wink:

Carsten Hölscher 23. Sep 2021 17:18

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von Codehunter (Beitrag 1491347)
Das kann ich gut verstehen. Die Situation mit den Win32-Binaries für OpenSSL ist wirklich nicht schön. Darüber habe ich mich auch schon oft geärgert. Also ich verwende die 1.0.2s mit Indy 10. Die letzte Minor-Version aus dem 1.0.2-Zweig ist die "u". Dabei jeweils auf 32- und 64 Bit achten, je nach Bedarf. Da musst du auch aufpassen wenn du dein Programm auslieferst, weil die Dateinamen der DLLs bei 32 und 64 Bit identisch sind.

Also sehe ich das richtig, dass für 32- und 64-bit Versionen meiner exe in beiden Fälln der Dateiname ssleay32.dll und libeay32.dll lautet?

Also mal im Gesamtzusammenhang, folgender Download: https://indy.fulgan.com/SSL/

32 bit Windows: 32 bit Anwendung: dlls aus openssl-1.0.2q-i386-win32.zip
32 bit Windows: 64 bit Anwendung: geht nicht
64 bit Windows: 32 bit Anwendung: dlls aus openssl-1.0.2q-i386-win32.zip
64 bit Windows: 64 bit Anwendung: dlls aus openssl-1.0.2q-x64_86-win64.zip

Korrekt verstanden? Wenn ja halte ich das für eine etwas ungewöhnliche und verwirrende Benennung, oder gibt es einen Grund, die nicht unterschiedlich zu nennen?

Carsten

Codehunter 23. Sep 2021 18:48

AW: Indy OpenSSL Sicherheitsupdates
 
Ich muss zugeben, jetzt bin ich verwirrt. Seit wann mischt Fulgan wieder aktiv mit und baut Dailybuilds von den OpenSSL-DLLs?

Wie dem auch sei, nicht die "q" sondern die "u" ist die aktuellste soweit ich weiß. Davon abgesehen stimmt der Rest. Die Dateinamen der DLLs sind historisch bedingt. Das kann man auf Wikipedia nachlesen.

Codehunter 24. Sep 2021 13:42

AW: Indy OpenSSL Sicherheitsupdates
 
Ich bin da jetzt doch etwas misstrauisch geworden, dass Fulgan anscheinend neuere Builds der OpenSSL-DLLs vorhält. Laut Remy Lebeau ist Fulgan nicht mehr involviert.

Demnach ist https://github.com/IndySockets/OpenSSL-Binaries nach wie vor die sichere Quelle. Das Dateidatum aus 2019 erscheint mir auch passender, denn seitdem ist OpenSSL 1.0.2 auch aus dem Support gefallen.

Was mich im Moment echt nervt: Jetzt haben die Indy-Macher so viel Arbeit in die Integration von OpenSSL 1.1 gesteckt, sowohl für Indy 11 als auch in den Backport für Indy 10. Und kaum dass das fertig wird, ist OpenSSL 1.1 schon wieder outdated und wechselt neben der Lizenz und der Major-Version (jetzt 3.0) auch schon wieder das API. Also alles wieder auf Anfang und nochmal neu anfangen bei Indy? Also mal ehrlich, wem tun die OpenSSL-Macher damit eigentlich einen Gefallen?

AScomp 19. Dez 2021 17:57

AW: Indy OpenSSL Sicherheitsupdates
 
Hallo zusammen,

ich versuche gerade vergeblich, Indy 10.6.2 für Delphi XE zu finden. Auf der indyproject-Seite führt der Download-Link ins Leere und das Github-Repository scheint mir keine fertigen Packages für Delphi XE zu enthalten. Kann mir da jemand weiterhelfen?

Zwischenzeitlich hatte ich es mal mit Indy von sgc probiert, allerdings sind da keine Quellcodes dabei und installieren ließ es sich auch nicht, weil angeblich die originalen BPLs noch als Basis geladen waren, obwohl ich alle Steps der Beschreibung von https://stackoverflow.com/questions/...in-delphi-2009 befolgt und sämtliche alte BPLs und DCUs gelöscht habe. :shock:

mjustin 19. Dez 2021 18:09

AW: Indy OpenSSL Sicherheitsupdates
 
Zitat:

Zitat von AScomp (Beitrag 1499343)
das Github-Repository scheint mir keine fertigen Packages für Delphi XE zu enthalten.

https://github.com/IndySockets/Indy/tree/master/Lib enthält Fullc_XE.bat, mit der die Packages erstellt werden könnten.

AScomp 19. Dez 2021 18:45

AW: Indy OpenSSL Sicherheitsupdates
 
Super, danke - das hatte ich wohl übersehen!

EDIT: Zu früh gefreut, das Package lässt sich nur für C++-Builder erstellen. Für Delphi XE kann man anscheinend keine Packages mehr erstellen, stattdessen lädt man die .dpks in der IDE.

slemke76 19. Dez 2021 22:15

AW: Indy OpenSSL Sicherheitsupdates
 
Guten Abend,

Zitat:

Zitat von AScomp (Beitrag 1499346)
EDIT: Zu früh gefreut, das Package lässt sich nur für C++-Builder erstellen. Für Delphi XE kann man anscheinend keine Packages mehr erstellen, stattdessen lädt man die .dpks in der IDE.

Warum sich mit den dpks rumärgern? Ich lege schon seit Jahren den Source in einen Pfad, den ich unter Projekt/Optionen/Suchpfad eintrage. Dann wird mein Projekt gehen die aktuelle Version compiliert. Natürlich stehen mir dann nicht die aktuellsten Komponenten in der IDE für den Entwurf zur Verfügung, aber ich erzeuge die Objekte ohnehin alle dynamisch zur Laufzeit. Im Entwurf schaue ich bestenfalls mal Parameter und Optionen nach. Das erspart jede Menge Zeit, Ärger und Stress. Einfach update-bar ist das auch.

Edit:
Zitat:

Zitat von AScomp (Beitrag 1499343)
allerdings sind da keine Quellcodes dabei und installieren ließ es sich auch nicht

Sorry, zu spät gesehen :-/ Kannst du nicht über https://github.com/IndySockets/Indy/commits/master die passende Version ziehen?


lg
Sebastian


Alle Zeitangaben in WEZ +1. Es ist jetzt 03:53 Uhr.
Seite 3 von 3     123   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz