Tedious: tls.createSecurePair ist zur Laufzeit veraltet

Erstellt am 26. Feb. 2017  ·  33Kommentare  ·  Quelle: tediousjs/tedious

Ref: https://github.com/nodejs/node/pull/11349

Benutzt in:

tedious-1.14.0.tgz/lib/message-io.js:117:      this.securePair = tls.createSecurePair(credentials);

Siehe auch #135.
Siehe z. B. https://github.com/sidorares/node-mysql2/pull/367 für ein Beispiel für die Feature-Erkennung.

Hilfreichster Kommentar

738 enthält eine Fehlerbehebung und wird zusammengeführt und freigegeben, sobald sie von jemandem aus dem @tediousjs/microsoft-contributors-Team überprüft wurde.

Alle 33 Kommentare

@ChALkeR Danke für den

@tvrprasad : @ChALkeR ist Teil des Node.js-Teams und dieser Beitrag ist hauptsächlich als tedious . 😄.

@ChALkeR : Ich kenne diese einiger Zeit, aber die Dokumentation zu dieser Einstellung ist wirklich spärlich. Die Beispiele, die ich bisher gesehen habe (wie der PR für node-mysql ) konzentrieren sich auf "einfache" TLS-Upgrades, bei denen die Verbindung einfach von Nicht-TLS auf TLS umgestellt wird.

Bei TDS ist das TLS-Upgrade viel aufwendiger, alle Handshake-Pakete müssen in TDS-Nachrichten verpackt werden, und sobald die Verbindung hergestellt ist, müssen alle weiteren TLS-Pakete nicht mehr verpackt werden. Die Implementierung über tls.createSecurePair war ziemlich einfach, aber das letzte Mal, als ich dies über TLSSocket versuchte, konnte ich es nicht zum Laufen bringen. 😞.

Ich werde es nochmal versuchen, wenn ich dazu komme, aber ich glaube nicht, dass sich viel geändert hat.

Ein weiteres Problem, auf das ich gestoßen bin, ist, dass das Umschließen eines Sockets aus dem readable-stream Paket in ein TLSSocket einen Segfault (!) des Node.js-Prozesses verursachen würde. Leider habe ich gerade keine Reproduktionsschritte zur Hand. 😞.

@arthurschreiber Danke für die Info :-)

aber das letzte Mal, als ich dies über TLSSocket versuchte, konnte ich es nicht zum Laufen bringen.

Wenn diese Arbeit auf github ist, senden Sie mir bitte einen Hinweis. Ich bin neugierig, es zu überprüfen.

@tvrprasad @arthurschreiber Hier finden Sie Informationen zum Ersetzen von tls.createSecurePair https://nodejs.org/dist/latest-v6.x/docs/api/tls.html#tls_class_securepair

Das gleiche Problem ist bei Node v8.0.1 aufgetreten. Meine App meldet folgenden Fehler, nachdem ich versucht habe, eine verschlüsselte Verbindung aufzubauen:

(node:6344) [DEP0064] DeprecationWarning: tls.createSecurePair() is deprecated. Please use tls.Socket instead.

Ich verwende patriksimek/node-mssql und den tedious Treiber (der Standardtreiber von node-mssql ), um auf unsere Microsoft SQL Server-Datenbank zuzugreifen.

Gleiches Problem wie bei @olange mit node-mssql mit mühsamem Treiber.

Listening on port 4000
(node:4402) [DEP0064] DeprecationWarning: tls.createSecurePair() is deprecated. Please use tls.Socket instead.

Bitte verstehen Sie mich nicht falsch und ich schätze Ihre Bemühungen, dieses Modul aufrechtzuerhalten, sehr zu schätzen, aber gibt es eine Vorhersage, wann es behoben wird?

Verwenden des Pakets 'mssql' und Verwenden von Optionen:
{
verschlüsseln: wahr
}

(node:13508) [DEP0064] DeprecationWarning: tls.createSecurePair() ist veraltet. Bitte verwenden Sie stattdessen tls.Socket.

Wenn das Node-Team so etwas ablehnt, wie sieht der Zeitrahmen für die Entfernung in Node aus? Nur neugierig.

Wird wahrscheinlich in Node 9 oder 10 entfernt. Die Funktion ist seit mindestens 4 Jahren veraltet. :-/ Dies ist eines der wenigen populären NPM-Pakete, die es noch verwenden.

Hat jemand von Mitbearbeitern einen Zeitplan, wann die Änderung veröffentlicht wird?

Habe dies heute bekommen, da ich gerade unsere Systeme auf Knoten 8.9.0 lts aktualisiert habe. Ich habe im Moment zwei schwere Projekte, aber wenn beide nachlassen, werde ich sehen, ob ich etwas Zeit für die Reparatur aufbringe.

@Iiridayn Das wäre toll!
Ich habe es mir angesehen, konnte aber nicht herausfinden, wie man das Handshake-Paket von TLSSocket erhält, das an derselben Stelle wie https://github.com/tediousjs/tedious/issues/515#issuecomment -283191248 :confused:
Würde gerne hören, wenn Sie Ideen dazu haben.

Gibt es diesbezüglich Fortschritte? Ich habe das gleiche Problem beim Versuch, eine Verbindung mit Azure herzustellen, nur wenn es hilft.
Ich wäre dankbar, wenn mir jemand schnell erklärt, was die Folge davon ist, eine App auszuführen, während dies veraltet ist, die von mir angeforderten SQL-Abfragen werden nicht ausgeführt und ich muss wissen, ob dies die Ursache ist, aber die Texte dazu ich' Ich habe gelesen, sind nicht sehr eloquent.

Vielen Dank im Voraus.

@Jorgeee1 Dies ist nur eine Warnung, es ist unwahrscheinlich, dass dies der Grund für Ihre Probleme ist. Ich verwende auch mühsam, um eine Verbindung zu Azure DB herzustellen, und es funktioniert einwandfrei.

Ich habe einen schnellen Proof of Concept geschrieben, um createSecurePair durch TLSSocket + einen TCP-Server zu ersetzen, um die rohen Handshake-Daten zu erhalten. Sie können es sich hier anschauen . Die Integrationstests, die ich durchführen konnte, haben bestanden.

Dies ist offensichtlich keine wirkliche Lösung für das vorliegende Problem (es sei denn, es ist in Ordnung, zusätzliche Steckdosen usw. zu essen). Das ist eher ein Diskussionsstarter. Es wäre gut, aktuelle Vorschläge und Diskussionen auf https://github.com/nodejs/help/issues/1010 zu haben.

@joux3 das ist klasse 😃 Kannst du eine PR erstellen? Dort ist es einfacher zu überprüfen und zu diskutieren.

Schwere Projekte wurden nicht nachgelassen, ein drittes wurde hinzugefügt, und wir sind ebenfalls auf MySQL umgestiegen. Tut mir leid, dass ich das nicht reparieren kann - viel Glück für dich :).

Bitte beheben Sie es, es ist ein wichtiges Problem

Hallo alle,

Gestatten Sie mir hier ein kurzes Update zum aktuellen Stand. Ich verstehe, dass die Einstellungsnachricht ein Ärgernis sein kann, aber es ist nicht wirklich ein Problem. tls.createSecurePair mag veraltet sein, aber kurz- und mittelfristig wird es nirgendwo hingehen. Laut https://github.com/nodejs/node/pull/17882 wird es nicht bald entfernt.

Außerdem schlägt https://github.com/nodejs/node/pull/17882 eine Neuimplementierung von tls.createSecurePair in Bezug auf die öffentliche node.js-API vor und führt (vorerst) ein internes DuplexSocket Klasse. Die Grundlagen dieser Implementierung sind genau das, was wir brauchen, um mühsam von tls.createSecurePair wegzukommen, ohne auf interessante 😁 aber nicht wirklich praktikable Hacks zurückzugreifen, wie von @joux3 vorgeschlagen. Wir werden wohl vorerst unsere eigene DuplexSocket Version erstellen müssen, aber zumindest habe ich jetzt eine gute Idee, wie man das mühsam lösen kann, sobald klar ist, wann tls.createSecurePair tatsächlich entfernt wird .

Bitte teilen Sie uns Ihre Meinung mit! 😄.

@arthurschreiber Fwiw, ich habe diese DuplexPair Implementierung auch gerade unter https://www.npmjs.com/package/duplexpair veröffentlicht. Ich schätze, Sie könnten einen Wrapper darum bauen, um ziemlich einfach einen tls.createSecurePair() Lookalike zu haben?

@addaleax Süß! ❤️ Das ist großartig und ich werde sehen, ob ich das anschließen kann und uns eher früher als später von tls.createSecurePair wegbewegen kann! Ich danke dir sehr! 🙇.

@arthurschreiber Ich denke ein Patch dafür könnte so einfach aussehen:

diff --git a/package.json b/package.json
index bca5b266849d..8cc0ed957577 100644
--- a/package.json
+++ b/package.json
@@ -43,6 +43,7 @@
     "babel-runtime": "^6.26.0",
     "big-number": "0.3.1",
     "bl": "^1.2.0",
+    "duplexpair": "^1.0.1",
     "iconv-lite": "^0.4.11",
     "readable-stream": "^2.2.6",
     "sprintf": "0.1.5"
diff --git a/src/message-io.js b/src/message-io.js
index 6c2a15c32a9f..a1de3a1e91c0 100644
--- a/src/message-io.js
+++ b/src/message-io.js
@@ -1,7 +1,9 @@
+'use strict';
 const tls = require('tls');
 const crypto = require('crypto');
 const EventEmitter = require('events').EventEmitter;
 const Transform = require('readable-stream').Transform;
+const DuplexPair = require('duplexpair');

 const Packet = require('./packet').Packet;
 const TYPE = require('./packet').TYPE;
@@ -84,10 +86,14 @@ module.exports = class MessageIO extends EventEmitter {
   startTls(credentialsDetails, hostname, trustServerCertificate) {
     const credentials = tls.createSecureContext ? tls.createSecureContext(credentialsDetails) : crypto.createCredentials(credentialsDetails);

-    this.securePair = tls.createSecurePair(credentials);
+    const duplexpair = new DuplexPair();
+    this.securePair = {
+      cleartext: new tls.TLSSocket(duplexpair.socket1),
+      encrypted: duplexpair.socket2
+    };
     this.tlsNegotiationComplete = false;

-    this.securePair.on('secure', () => {
+    this.securePair.cleartext.on('secure', () => {
       const cipher = this.securePair.cleartext.getCipher();

       if (!trustServerCertificate) {

Aber dies scheint nicht als Teil der regulären Testsuite getestet zu werden, daher bin ich mir nicht sicher, wie ich das anstellen soll…

Ich habe einen weiteren Versuch unternommen, SecurePair zu ersetzen. Die Integrationstests scheinen in Ordnung zu sein, getestet auf Node 9. https://github.com/joux3/tedious/commit/6d255fbdaa2f9afd388617e6e34815cae95292a0

Ich habe jedoch einige Beobachtungen (aber vielleicht ist der Patch gut genug für eine PR, um die Probleme zu diskutieren?):

  • Node.js 6 scheint bei Assertion failed: (uv__stream_fd(stream) >= 0), function uv_read_start, file ../deps/uv/src/unix/stream.c, line 1517. totally völlig abzustürzen
  • Ich musste das Timer-Fake aus dem Retry-Timeout-Test entfernen, der gefälschte Timer scheint DuplexPair intern zu unterbrechen
  • Unverschlüsselte Verbindungen habe ich nicht getestet. Diese könnten von den Änderungen des Logikflusses betroffen sein (Signale schienen sich nicht richtig durch Pipes auszubreiten, daher gibt es einen manuellen close Handler auf dem Socket)'

Vielen Dank an

@joux3 ist Ihr Fork bereit für die Verwendung mit Node 8 - der aktuellen LTS-Version? und ist es möglich, einen Pull-Request zu öffnen? Ich würde gerne sehen, ob es ein Problem behebt, das ich in Verbindung mit https://github.com/patriksimek/node-mssql/ habe, danke!

Ich musste das Timer-Fake aus dem Retry-Timeout-Test entfernen, der gefälschte Timer scheint DuplexPair intern zu unterbrechen

@joux3 Welcher Test wäre das? (Entschuldigung, ich bin mit dieser Codebasis nicht besonders vertraut, über das hinaus, was ich für dieses Problem untersucht habe.)

@addaleax , der fehlgeschlagene Test ist https://github.com/tediousjs/tedious/blob/f5a0f95a5a522ad6a312170201b829e70c866976/test/integration/connection-retry-test.js#L73 -L104
Deaktivieren Sie den Timer hier: https://github.com/tediousjs/tedious/pull/689/files#diff -ed1dc3ba8a10a8fb4b18a528b35bad00.
Bearbeiten: Ich habe das Timer-Fake wiederhergestellt, indem ich nur setTimeout gefälscht habe https://github.com/tediousjs/tedious/pull/689/commits/ff5d5eb1a3603db05266306a823fa49a98b50209.

@jimmont , ich habe eine Pull-Anfrage unter https://github.com/tediousjs/tedious/pull/689 geöffnet ( scheint so , als ob der Verweis auf die Issue-ID im PR-Namen nicht ausreicht ...). Integrationstests bestehen auf Node 8, aber es gibt noch einiges zu tun.

👍 Um dies so schnell wie möglich zu beheben!

Gibt es diesbezüglich Fortschritte? Es wäre gut, wenn wir ein Update zu diesem Thema bekommen.

Verlinkung von PR #689 zum Tracking.

In einer Welt, in der Warnungen an stderr statt an stdout gesendet werden. <fail/>

irgendein Update?

738 enthält eine Fehlerbehebung und wird zusammengeführt und freigegeben, sobald sie von jemandem aus dem @tediousjs/microsoft-contributors-Team überprüft wurde.

Nach langem hin und her wurde dies nun endlich (und richtig) über https://github.com/tediousjs/tedious/pull/738 behoben [email protected] ist jetzt auf npm verfügbar. Es ist derzeit als next markiert und ich werde sicherstellen, dass es bald als latest markiert wird.

Vielen Dank an alle für Ihre Geduld und Hilfe bei der Behebung dieses Problems! 🙇.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen