|
Indy SSL DLLs woher nehmen wenn nicht stehlen?
Ahoi!
Beide  Downloadseiten die auf der Indy-Homepage angegeben werden, sind offline. Auch der bei Emba genannte Downloadlink (32-Bit- und 64-Bit-Windows > Option 2) geht nicht mehr.Wie war denn das, die originalen OpenSSL-DLLs funktionierten doch nicht mit Indy, weshalb es gepatchte Versionen gab. Oder hat sich daran was geändert? Grüße Cody |
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
OpenSSL for Win64, download funktioniert, reicht Dir das aus? (FreePascal Edition, ist die auch mit Delphi kompatibel?) |
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Zitat:
http://www.indyproject.org/Sockets/f...SSL-0_9_8g.zip) führt zu einer alten Version der OpenSSL DLLs, die mit aktuellen Indy-Versionen nicht kompatibel ist.Es wäre interessant zu erfahren, was aus der semi-offiziellen Downloadseite ( http://indy.fulgan.com/SSL/) geworden ist, auf der regelmäßig die aktualisierten OpenSSL DLL Versionen veröffentlicht wurden. Ob diese nur temporär offline ist, oder für längere Zeit. |
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Zitat:
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Nein, das siehst du richtig.
Und du hast gerade erkannt, das billig (hier kostenlos) ganz schön teuer werden kann. |
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Zitat:
p.s. Indy 10 ist mit den Standard-DLLs kompatibel. Die im Beitrag weiter oben angegebene Seite zeigt auf einen Download einer alten Version (0.x), Standard-OpenSSL DLLs waren nicht mit Indy 9 kompatibel. Das Problem ist also nicht akut, solange noch jemand den aktuellen Sourcecode der DLLs und einen Compiler besitzt, und Indy 10 verwendet :) Zitat:
https://www.codenewsfast.com/cnf/thr...hr-ng1921q6077 |
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Bei den Fulgan DLLs geht es um die Dependencies auf die Microsoft Runtime DLLs so ich mich recht erinnere.
Wenn du Apache unzippst, dann kommt der genauso wenig auf die Füße. Deswegen nimmt man den Installer. Dazu gleich später. --- Eine Anwendung ist ein eigenes Betriebssystem. Du kannst ruhig eine eigene Version Implementieren. Das mit den Abhängigkeiten hat damit zu tun, dass Delphi Anwendungen oft im UNIX Style verteilt werden. Der Installer kommt von geschlossenen Systemen. Die ursprünglichen geschlossenen Systeme kannten keine Workstation. Der Operator hat ein Band eingelegt das sich selbst installiert hat mehr oder weniger. Bei IBM Rechner hattest du je nach Ergebnis eine Zahl auf einem Display am Server (Return Code wenn man so will). Es gab nur einen Rechner. --- Eine Oracle wir ja nicht am Server installiert. Die wird auf einer Workstation installiert und dann vom Systemadministrator kopiert. Der Sysadmin weiß was installiert ist. (Dependency Management) Ein Teil der Installation das Linken der statischen Libraries oder der Stubs ... Die Schnittstelle nach außen ist gleich und die Implementierung im Kontext des OS eine andere. Denke an die Java Application Server. Jeder hat ein JBOSS installiert und dann wird wild herumkopiert. --- UNIX ist ein Peer to Peer Konzept. Die hatten Workstations. UNIX Style Deployment heißt, dass du lokal übersetzt und Sysadmin kopiert 'manuell'. Jetzt ist man immer wieder gefangen in der Welt zwischen Infrastruktur das vom OS bereitgestellt wird und dem Linken der Security relevanten Teile in die Applikation. Windows ist der Versuch von DEC auf dem sich verbreitenden Anachronismus dem PC Server ein geschlossenes System anzubieten (Windows NT). Was heute in die Cloud wandert entspringt der Logik der geschlossenen Systeme, spätestens beim Thema Security. Der Nachbau des IBM Mainframe mit Terminals sit die Web Applikation. Jetzt hast du auf einmal so die Idee, dass der Apache mit Scripting die Security des OS bemüht. Der Weg das nachzubilden ist die Shared Library (oder auch DLL unter Windows). In der UNIX Philosophie der frühen Tage ist der Server und Client dasselbe Programm. Wenn du die Library statisch linkst. Das entspräche in der Delphi Welt bspw. dem Linken von ELDOS SSL oder eine anderen Delphi SSL Implementierung. --- SSL sichert an sich ja nur den Client vor einem 'bösen' Server und in weiter Folge die Kommunikation. SSL sowie das im Moment im C/S Stil verwendet greift grad mal so weit wie die Anforderungen an einen Webshop. Two-sided SSL käme dem näher was der Benutzer so glaubt ... --- Eine nettes für eine echte Multi Tier Implementierung von Anwendungssecurity wird bei SecurBrige mitgliegert (SSH). --- An sich wird aus der Idee des geschlossenen Systems heraus bspw. ein Zertifikat oder die Anmeldung von der Infrastruktur verwaltet. Sonst musst du die dir selbst bauen. --- Ansonsten nehme ich einfach irgendwelche SSL dlls. Fulgan ist nicht Pflicht unter Indy 10. Warum Fulgan im Moment down ist weiß ich nicht. --- Am Netz sudern viel Leute die ein wenig Hudri Wudri unterwegs sind. Das ist typisch Windows Welt. Windows ist Peer To Peer einersteits und geschlossen auf der anderen. Auch sehr typisch für die Windows Welt ist, dass es extrem viel Funktionalität in den APIs gibt sich Security in seinem eigenen OS nämlich der Anwendung anzupassen. Da beginnt der Konflikt. Wenn man das unter Windows durchzieht müsste man fast auf die Funktionen bpsw. in JEDI Windows Security Code Library zurückgreifen. Mit SSL aktiv und der Tag ist gerettet machst du keine Meter. Ansonsten kann man nur wie .net oder auch Mono eine Certificate Storage machen usw... Du hast im Indy aber die Interceptoren. Auf dem Weg kannst du in eine bestehende Infrastruktur durchaus auch nicht praxisfern dich integrieren. --- Sobald die Server in der Cloud wo dann der Anachronismus PC Server verschwindet, dann ist man eher wieder sauberer in der geschlossen Welt. Ob das erstrebenswert ist sei dahingestellt. |
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
:wiejetzt: :spin2:
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Bei so langen Antworten habe ich immer den Eindruck, dass da ein Bot antwortet.
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Liste der Anhänge anzeigen (Anzahl: 1)
Manchmal ... |
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Aber ich schreibe so schnell. Manchmal drifte ich etwas in den lokalen Slang hier ab. HAK der 80er Jahre und 3mal in der Woche Steno und Schreibmaschine schreiben. Ich bin voll die Tippse.
asdf jklö asdf jklö fdsa ölkj ... und die ganzen Permutationen korrekt über eine zweistellige Anzahl von Seiten. Wir waren so in der Übergangszeit mit dem letzten PL/I Praktikum am IBM Host mit Ausdrucken über Nacht mit Compilierfehler am Ausdruck. Hoch gepriesen sei der PC. Auch wenn sich manche Beiträge ähnlich anhören die darunterliegende Thematik ist ähnlich. Delphi als Vertreter zwischen zwei Welten Peer 2 Peer (Desktop) und teils historisch gewachsen durch die Formularanwendungen die MS tunlichst hat versucht zu vermeiden haben wir teils the best und anderensfalls the worst of both worlds. Der PC Server ist ein IBM Mainframe genauso. Terminal Services. Bis diese Rechner mal verschwinden gibt es immer Zwischenschritte, wo andere die keine fertigen Komponenten nehmen 'Kompetenz' am Ende umsonst aufbauen, wenn sie zu tief ins Detail abgleiten. Du kannst nicht gleichzeitg zentralisieren und dezentralisieren. Entweder dominiert im Netz draußen, hinter dem Gateway der Zentralismus, dann wird das LAN eher Peer 2 Peer (UNIX und Windows bis 98 in Reinform) und sonst umgekehrt. Ich habe in keinem Unternehmen mit Delphi im Umfeld von KMU (neighborly help) troubles. Klarerweise sind die Anforderungen nicht groß. Ich bin mir schon bewusst, dass die meisten das alles klar ist. Aber sollte sich mal ein junger Entwickler hierher verirren, dann ist es nicht schlecht wenn man die Geschichte aufbereitet. Delphi hat mal keine kurze. Manche Diskussion, nicht unbedingt hier, drehen sie oft um Themen die für die keine Lösungserfordernis gegeben ist. Diesen Dialog basierten Anwendungen wohnt etwas die Vorstellung und auch dem Trend in Richtung 'Einmal auf das Knöpfchen gedrückt und das Tagewerk ist erledigt' inne. Das Modell ginge aber davon aus, dass bezüglich Security man selbst alles darf und alle anderen nichts. Es ist aber unterhaltsam über die Jahre wie Themen immer wieder aufpoppen und dann probiert wieder eine Generation mit IDE Extension die Produktivität hinauszudrehen. Im VS schon ein Weilchen sehr beliebt. btw. Fulgan funktioniert wieder. Zitat:
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Ich finde es ist nicht leicht deine Texte zu lesen und zu verstehen. Besonders wenn nicht ein einziges "SSL" drin enthalten ist.
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Zitat:
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Jetzt bin ich aber erst recht misstrauisch. Alle Downloads inkl. der Archive mit aktuellem Dateidatum?
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Ist wohl der Zeitpunkt, an dem die Dateien dort (neu) hochgeladen wurden.
|
AW: Indy SSL DLLs woher nehmen wenn nicht stehlen?
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 02:38 Uhr. |
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