Fragen? Antworten! Siehe auch: Alternativlos
Auf der einen Seite ist das natürlich erstmal eine gute Nachricht. Auf der anderen Seite muss man halt immer auch auf das Preisschild gucken. In diesem Fall ist das Preisschild, dass er sich als Ersatz für Chiasmus (proprietärer Geheim-Cipher der deutschen Behörden) an die staatliche Zitze begeben hat, und jetzt existenziell vom Wohlwollen des deutschen Staates abhängig ist. Also genau derer, vor denen uns GnuPG schützen sollte. Die, die gerne Krypto umgehen wollen. Die Backdoors in Endgeräten einbauen wollen, damit sie besser abhören können.
Konkret:
In particular, our now smooth integration into Active Directory makes working with OpenPGP under Windows really nice. We were also able to partner with Rohde & Schwarz Cybersecurity GmbH for a smooth integration of GnuPG VS-Desktop with their smartcard administration system.Rohde & Schwarz sind Deutschlands bekanntester Geheimdienst-Lieferant, die auch die ganzen IMSI-Catcher gebaut und geliefert haben.Den Kunden noch einen Grund zu geben, nicht von Active Directory wegzumigrieren, würde ich auch als ethisch fragwürdig bezeichnen.
Abgesehen davon trübt der Kontext meinen Blick etwas. Es wird mir immer schwer fallen, positive Aspekte bei GnuPG zu finden, solange Werner Koch das in Geiselhaft hat. Und jetzt, wo er offen mit Geheimdienst-Zulieferern kollaboriert, wird das noch schwieriger.
Update: Einen positiven Aspekt hat das aber auf jeden Fall: Für Unterhaltung ist gesorgt.
A minor drawback is that for a quick start and easy migration from Chiasmus, many sites will use symmetric-only encryption (i.e. based on "gpg -c").
Richtig gelesen! Die verwenden da den symmetrischen Modus! HAHAHAHAHA OMG. Die 1970er haben angerufen! Public Key Krypto ist erfunden worden!
Kurzfassung: GnuPG benutzt als Kryptolibrary aus religiösen, äh, Lizenzgründen nicht OpenSSL oder etwas anderes existierendes, sondern "libgcrypt", eine eigene Krypto-Library, die im Allgemeinen langsamer als andere ist und deren API noch übler ist als die von OpenSSL. Ich kenne kein Argument dafür, die gegenüber einer Alternative zu bevorzugen.
Da ist kürzlich eine neue Version released worden, 1.9, in der Assembler-Optimierungen für einige Funktionen neu dazu kamen. Unter anderem für Hashing-Verfahren. Hashing ist eine der wichtigsten Funktionen in einer Krypto-Library und spielt z.B. eine Rolle beim Validieren von Signaturen in GnuPG.
Wenn man Daten hasht, gibt es normalerweise drei Schritte. Man hat einen "Kontext", d.h. eine Datenstruktur mit dem internen Status, die initialisiert man (Funktion 1), dann ruft man so oft man es braucht "hash mal auch diese Daten hier" auf (Funktion 2), und am Ende holt man sich den Hashwert über alle bisherigen Daten (Funktion 3). Je nach Hashfunktion, für die man das macht, beinhaltet das Finalisieren noch ein mehr oder weniger abstoßendes Padding-Verfahren, denn die Hashes arbeiten normalerweise auf Blöcken von Bytes, nicht auf einzelnen Bytes.
Bei libgcrypt heißt der letzte Schritt "finalize". Der Assembler-Code nahm an, dass niemand so blöd sein würde, nach einem finalize nochmal weitere Daten hashen zu wollen, weil das nie gültige Ergebnisse liefern kann, denn da ist ja schon Padding reingeflossen.
Stellt sich raus: GnuPG macht genau das. Das sollte wohl ein halbherziger Versuch sein, einen Timing-Seitenkanal zu schließen.
Da hätte wohl der Autor von GnuPG mal mit dem Autor von libgcrypt reden sollen, denkt ihr euch jetzt vielleicht? Das ist dieselbe Person. Werner Koch.
Was heißt das? Anscheinend reicht das Öffnen einer verschlüsselten Mail mit GnuPG, um Speicherkorruption herbeizuführen und damit eventuell Remote Code Execution.
Ich habe den Bug nicht analysiert, aber wenn das stimmt, ist das auf der Krassheitsskala ungefähr so weit oben wie Heartbleed bei OpenSSL war, denn GnuPG hat keine Privilege Separation und kein Sandboxing. Die gute Nachricht ist: Das betrifft euch nur, wenn euer GnuPG so neu ist, dass er schon gegen die neue libgcrypt linkt, die vor ner Woche oder so erst rauskam.
Kann man diese Art von Bug verhindern?
Ja, kann man.
Diese Art von Bug wäre aufgefallen, wenn GnuPG eine Testsuite hätte, die z.B. mit valgrind oder dem Address Sanitizer automatisch durchläuft, bevor er eine Version released. Noch beunruhigender als dass das offensichtlich nicht stattfindet, finde ich Werner Kochs Reaktion, als Hanno Böck genau das vorschlägt. Er schließt den Bug als "invalid". Das ist selbst für Werners Verhältnisse ausgesprochen unprofessionell, aber leider nicht überraschend.
Hey, Werner, wenn du keinen Bock auf die Verantwortung hast, die der Maintainer von GnuPG tragen muss, dann übergib das Projekt doch am besten der Apache Software Foundation oder so. Jetzt wäre jedenfalls der richtige Zeitpunkt für zerknirscht Besserung geloben gewesen, nicht für close as invalid.
Ich muss dann wohl doch mal meinen OpenPGP-Code fertig machen. So geht das jedenfalls nicht weiter.
Update: Ich hatte meinen OpenPGP-Code prokrastiniert, weil ich dachte, fürs reine Signatur-Prüfen ist mein Ansatz mit der Prozessisolation vielleicht nicht nötig. Wer verkackt denn schon eine Hashfunktion, dachte ich mir.
Update: Leserbrief von Hanno Böck:
libgcrypt hat eine testsuite, und die hat den bug nicht gefunden. Müsste man jetzt genauer analysieren warum und ob das ein mangel bei der testabdeckung ist und sie den bug hätte finden sollen.
Der Punkt den ich aber kritisiert hab: Es gibt einen anderen bug in libgcrypt 1.9.0 in der testsuite, der durch asan gefunden wird. Es ist "nur" eine selbsttestfunktion, insofern ist der bug nicht so relevant, aber daraus kann man halt schließen: libgcrypt wird offenbar nicht regelmäßig vor einem release (oder via CI)mit asan getestet, sonst hätte das ja merken müssen.
Und achso, noch was: Valgrind hätte diesen Bug (also den in der testsuite) nicht gefunden. Das ist ein buffer overread in einem predefinierten array, sowas kann valgrind nicht. Siehe beispiel im Anhang.
Ich predige seit jahren dass die leute asan nutzen sollen und nicht glauben valgrind sei ein vergleichbar mächtiges tool. Ist es nicht.
Also so langsam hab ich echt keinen Bock mehr auf diese ständige Terrorpanikmache bei Securitybugs. Heise besteht ja gefühlt auch nur noch aus Spectre-Geraune. Kommt mal bitte alle wieder runter. Unglaublich.
Das sollte mal jemand Joan Daemen und Vincent Rijmen mitteilen, den Erfindern von AES. Oh, und den Leuten hinter SHA-3. Und Werner Koch. Und Tatu Ylönen.
Auf einer gewissen Ebene hat er natürlich Recht. Auf der anderen Seite hat Snowden seinen Scheiß halt nicht mit Moxies Scheiß vor der NSA gerettet sondern mit GPG. Und am Ende kommt er dann mit:
GPG isn’t the thing that’s going to take us to ubiquitous end to end encryption, and if it were, it’d be kind of a shame to finally get there with 1990’s cryptography.Damit wären wir wieder bei den Ansprüchen. GPG hat nicht den Anspruch, universelle Ende-zu-Ende-Verschlüsselung zu machen. GPG ist für Email. Nicht für Webseiten, nicht für Chat (obwohl man es in XMPP verwenden kann), nicht für Telefonieverschlüsselung. Die Kritik ist unwürdig.Ich will da jetzt nicht groß ins Detail gehen, aber so richtig vollständig überzeugend ist auch Moxies Software bisher nicht. Die andere Sache, die sich durchgesetzt hat, ist OTR. Auch das ist nicht von Moxie. Ich finde das nicht angemessen, wenn er sich da so aus dem Fenster lehnt. GPG ist nicht schlecht, weil es alt ist. OTR nicht gut, weil es neue Krypto benutzt. Moxie macht sich das hier viel zu einfach.
Ich will dem mal entgegen halten, dass praktisch alle Linux-Distributionen, die überhaupt Krypto zum Validieren der Paketintegrität einsetzen, dafür GPG benutzen. Das muss man erst mal schaffen, so eine Marktdurchdringung.
It's encouraging to see the GnuPG project benefitting from similar largess. But it also raises the question: how is the money best spent? Matt Green, a professor specializing in cryptography at Johns Hopkins University, said he has looked at the GnuPG source code and found it in such rough shape that he regularly assigns chunks of it to his students for review."At the end I ask how they felt about it and they all basically say: 'God, please I never want to do something like this again,'" Green told Ars.
Soweit würde ich jetzt nicht gehen. Immerhin benutzt Werner Koch seit Jahren size_t für Längen und Offsets. Ich habe schon viel schlimmeren Code gelesen. Ich glaube ja, die Jugend von heute ist verweichlicht. Was sollen die denn erst sagen, wenn sie mal OpenSSL erben und warten sollen eines Tages?Übrigens, einen noch:
Given the ramshackle state of massive GnuPG code base, it's not clear what's the best path forward. A code audit is one possibility, but such reviews typically cost a minimum of $100,000 for complex crypto programs, and it's not unheard of for the price to be double that.Stimmt. Oder man hat halt Glück und der Fefe macht das kostenlos in seiner Freizeit. Und dann schmeißt Werner Koch Das liegt daran, dass Werner Koch das Problem ist, nicht die Lösung. Werner Koch macht mit dem Code keine Wartung, eher eine Geiselnahme. Denn wer will schon gnupg forken. Wir kriegen ja schon ohne Fork die Leute nicht in signifikanter Größenordnung dazu, das zu benutzen. Das wäre noch übler, wenn es da auch noch Marktfragmentierung gäbe. Deshalb hat noch niemand gnupg geforkt. Nötig gewesen wäre es seit Jahren. Ich persönlich hoffe seit Jahren, dass Werner endlich hinwirft, und dann jemand die Wartung übernehmen kann, der auch ein Interesse daran hat, daraus ein ordentliches Projekt zu machen. Aber das wird ja jetzt nicht mehr stattfinden. Jetzt wo nicht mehr nur sein Ego sondern auch sein Lebensunterhalt direkt davon abhängt, dass er weiterhin Diktator von gnupg bleibt.
Übrigens hat Werner seine BSI-Kohle über die Jahre nicht gekriegt, weil er dafür gearbeitet hätte, sondern weil Leute mit Beziehungen beim BSI Klinken geputzt haben. Diese Leute haben zwar gesehen, dass Werner Koch das Problem ist, aber sie haben sich gedacht, wenn man dem Geld gibt, vielleicht wird das dann besser. Wurde es leider nicht. Ein bisschen Mitleid war glaube ich auch dabei. Und ein bisschen "das ist das eine erwähnenswerte Kryptoprojekt aus Deutschland, das sollte gefördert werden, um ein Signal zu setzen".
Weil mir schon die ersten Twitter-Experten Neid vorwerfen: Ich habe den Aufwand für den Patch geleistet, weil ich vorher eine Finanzierung für meine Zeit klargemacht hatte. Ich brauche keine Spenden, schon gar nicht von Facebook. Das werde ich zu vermeiden wissen, dass Facebook sich mit einer Spende für eines meiner Projekte, die ich dann aus einer Notlage heraus annehmen muss, gutes Karma kauft. Das Geld, das ich bei Kunden für ehrliche Arbeit nehme, ist Bezahlung, keine Spende. Damit finanziere ich zwar meine Open Source Arbeit, aber keiner meiner Kunden kann damit Werbung machen, über mich Open Source finanziert zu haben. Außer der Kunde hat mich explizit für die Entwicklung von Open-Source-Software bezahlt, versteht sich. Das hat es auch mal gegeben.
Ich finde übrigens nach wie vor, am besten wäre es, wenn wir einfach ein bedingungsloses Grundeinkommen hätten. Dann hätten wir das Finanzierungsproblem für Kunst und Open-Source-Softwareentwicklung gelöst und niemand müsste so entwürdigende Winselnummern bringen. Wir hätten aber immer noch das Code-Geiselnahme-Problem. Dafür kenne ich auch keine gute Lösung.
Update: Ich sollte der Sicherheit halber dazu sagen, dass das nicht bloß meine Eintschätzung ist, dass Werner Koch das Problem ist, sondern ziemlich breiter Konsens. Ich habe diverse Mails von anderen Leuten gekriegt, die mit Werner vergeblich zu kooperieren versucht haben. Ich werde die hier aber nicht zitieren. Das sind die Geschichten der jeweiligen Leute, nicht meine. Sollen die sie erzählen. Mir persönlich war das 8 Jahre lang egal. Ich hatte meinen Patch. Mein persönlicher Moment, ab dem ich der Meinung war, dass da jetzt mal was geschehen muss, war als ich auf dem 31C3 Citizen Four sah.
Sorry, aber so läuft das nicht. Richard Stallman hat auch sein Leben der guten Sache gewidmet. Linus Torvalds auch. Was ist mit den OpenBSD-Leuten? Den OpenSSL-Leuten?
Wer sein Produkt kostenlos verteilt, der kann nicht nachher herumheulen, dass sich nicht aus magischen Quellen Geld auf seinem Tisch manifestiert hat. Das muss man vorher durchfinanziert haben, dass man die Entwicklung durchführen kann. Sonst sucht man sich einen Mäzen oder einen Sponsor oder macht Crowdfunding, vielleicht ein Regierungsprojekt. Man kann gucken, ob man eine Gemeinnützigkeit anerkannt kriegt. Ist das mit Aufwand verbunden? Klar! Wer das nicht macht, hat mein Mitleid nicht verdient, sorry.
Ich schreibe auch seit 20 Jahren freie Software. Sieht mich jemand herumheulen, dass ich mir kein Abendbrot leisten kann? Nein. So läuft das nicht.
Werner Koch ist im Übrigen in der ausgesprochen privilegierten Position, dass er sogar mehrfach von der Bundesregierung Förderkohle eingesackt hat. Und dann hat er auch noch ein erfolgreiches Crowdfunding durchgezogen. Was sollen denn bitte die ganzen anderen Leute sagen?! Die, denen die Regierung keine Kohle nachwirft? Die, deren Crowdfunding in der Obskurität verlischt?
Sorry, Werner. Du schläfst in dem Bett, das du dir gebettet hast. Wenn du da jahrzehntelang dein Lebens-Management verkackst, dann stelle dich bitte nicht am Ende hin und winsel herum, dass dir die Welt ein bedingungsloses Grundeinkommen schuldet. Sowas kriegt man nicht durch geduldig Warten.
Ich persönlich bin ein Freund des bedingungslosen Grundeinkommens, unter anderem gerade damit auch Leute wie Werner Koch Software wie gnupg schreiben können, ohne sich Sorgen um ihre Abendbrot machen zu müssen. Aber soweit sind wir noch nicht. Die Realität geht nicht weg, wenn wir sie lange genug leugnen.
Im Übrigen, aber das ist nicht mein Hauptpunkt hier, finde ich die Wartung von gnupg auch keinen Vollzeitjob. Sorry, nein, ist es nicht. Seit wann macht er das jetzt? 20 Jahre? Gelegentlich kommt mal ein Feature dazu, das will ich nicht leugnen. Features, die 90% der gnupg-Benutzer nicht betrifft, sowas wie Smartcards. Aktuell wohl auch elliptische Kurven, das betrifft schon eher jemanden. Aber elliptische Kurven haben die finanziell noch schlechter aufgestellten OpenSSL-Leute ganz ohne murren mal eben nachgerüstet.
Liebe Geeks. Wir haben hier ein strukturelles Problem. Freie Software finanziert sich nicht von selbst. Auf göttliche Intervention warten ist keine Lösung. Sucht euch einen Job, der euch Spaß macht. Am besten nichts, was mit Softwareentwicklung zu tun hat. Sonst habt ihr nämlich abends nach der Arbeit auch keinen Bock mehr auf Softwareentwicklung.
Und dann entwickelt ihr in eurer Freizeit freie Software. Und dann geht ihr in eurem Bett schlafen, unter dem Dach, das ihr euch mit dem anderen Job finanziert habt. So wird ein Schuh draus.
Noch was: Geschenken wirft man keinen Guilt Trip hinterher. Entweder es ist ein Geschenk, dann erwartet man nichts dafür, oder es ist kein Geschenk. Freie Software ist ein Geschenk. Klar darf man sich über Spenden freuen. Aber meckern, wenn sie ausbleiben, darf man nicht.
Update: Oh und einen Punkt möchte ich noch machen. Es wird häufig geheult, dass so viel Open Source Software angeblich in so einem schlechten Zustand ist, angeblich weil die Leute das nicht als Vollzeitjob machen. Das stimmt so nicht. Ich zum Beispiel schreibe Software nicht als Selbstzweck, sondern weil ich was lernen will. Aspekte, bei denen ich nichts lerne, oder die mich nicht interessieren, mache ich dann auch nicht. Die Ausgabe von Fließkommazahlen im printf der dietlibc ist seit Tag 1 kaputt. Dass das nicht gefixt wird, liegt nicht daran, dass ich nen Job habe, der mich ablenkt. Sondern das liegt daran, dass mir andere Sachen wichtiger sind. Das ist eine Frage der Prioritäten, nicht der Ressourcen. Jeder von uns hat genug Freizeit um alles zu schaffen, was er wirklich schaffen will.
Update: Oder aber natürlich man macht das zum Beruf. Gründet eine Firma, die Open Source macht. In einigen Fällen hat das sogar funktioniert. Wenn das gelingt, ist es natürlich der heilige Gral. Aber ich habe zwei Befürchtungen. Erstens ist es nicht mehr das Gleiche, wenn man dafür bezahlt wird. Es macht irgendwann weniger Spaß, wenn es ein Beruf ist und nicht etwas, das man aus freien Stücken tut. Zweitens muss man ja trotzdem irgendwoher Einnahmen generieren. Support für das Produkt ist hier eine populäre Option, aber das kann man nur bringen, wenn das Open-Source-Produkt soweit fertig und stabil ist und eine wichtige Sache löst und breit eingesetzt wird. Das ist eine verschwindende Minderheit der Projekte. Und dann ist die Arbeit, die man tut, auch eher Wartung als Entwicklung. Die Frage also, wie man die Entwicklung von freier Software finanziert kriegt, ist damit weiterhin nicht geklärt.
Als letzte Option bezahlen auch manche große Firmen wie IBM oder Oracle oder Linux-Distributoren ein paar Leute für ihre Arbeit an Open Source-Projekten. Das halte ich für nicht realistisch genug, um das generell als Lebensmodell zu empfehlen. Ein paar Leute können sich das so drehen. Der Rest — fast alle! — nicht.
Update: Es haben sich $50k/Jahr-Sponsoren gefunden. Und genau die Art von Leuten, von denen man Geld annehmen möchte!1!! Na seht ihr, ist doch noch alles gut ausgegangen. Wenn ihr Werner Koch wäret, wäret ihr jetzt zufrieden?
Update: Oh und die Linux Foundation wirft auch nochmal $60k hinterher.
Update: Ich mache mir Sorgen, dass jetzt lauter Kids glauben, das könnte für sie auch funktionieren. Leute, niemand von euch hat den Hauch einer Chance, das als Finanzierungsmodell für das Leben zu replizieren. Das ist wie auf einen Lottogewinn zu hoffen. Holt euch lieber einen richtigen Job und entwickelt nebenher freie Software. Das ist das realistische Modell. Ich finde nach wie vor, dass man Leute, die sich wie Werner ohne Fallschirm aus dem Flugzeug stürzen, nicht auffangen sollte. Sonst validiert man damit das Modell, dass man so seinen Lebensunterhalt verdienen kann. Und dann machen lauter Andere das nach.
Here, we describe a new acoustic cryptanalysis key extraction attack, applicable to GnuPG's current implementation of RSA. The attack can extract full 4096-bit RSA decryption keys from laptop computers (of various models), within an hour, using the sound generated by the computer during the decryption of some chosen ciphertexts.Das ist doch alles zum Mäusemelken.Update: Werner Koch hat Version 1.4.16 veröffentlicht, die das Problem beheben soll. (Danke, Sven)
Über die Jahre habe ich dann beim Anpassen von meinem diff auf neuere Versionen von gnupg gesehen, dass inzwischen knapp die Hälfte der Bugs in meinem Patch insgeheim upstream gefixt wurden. Es bleiben natürlich immer Restzweifel, aber die Bugs, die relativ sicher zu Problemen hätten führen können, sind in der Zwischenzeit verschwunden. Meine Ansage von damals, dass gnupg ein unsicherer Haufen Mist ist, gilt daher heute nicht mehr. Hintertüren habe ich damals übrigens keine gefunden, das sah alles aus wie ganz normale Schludrigkeit und Inkompetenz. Restzweifel bestehen natürlich immer. Und ich kann natürlich auch was übersehen haben. Insofern: Im Zweifelsfall selber nochmal gucken.
Update: Ich sollte dazu sagen, dass ich von den Sourcen von gnupg selbst rede, und auch nur von der 1.x-Version. Den ganzen Smartcard-Kram und etwaige Frontends habe ich nicht geprüft und habe es auch nicht vor. Und in den verwendeten Libraries können natürlich auch noch Fehler sein. Von "ist sicher" kann ja eh nie die Rede sein, so auch nicht in diesem Fall. Aber ich für schätze für mich das Risiko überschaubar genug ein, von einem Einsatz nicht mehr pauschal abzuraten.
Was tut man in solchen Fällen? Man spricht den Autor an. Habe ich gemacht. Erst mal als Testballon eine Frage zu seinem ASN.1-Code, den Funktionsnamen ins Subject.
Schreibt er mir zurück, ich müsse schon sagen, wo ich diese Codefragmente genau gefunden hätte. Ich schreib also zurück, äh, Funktionsname == Subject. Gut, übersehen, danke ich mir, kann schon mal vorkommen. Was kommt zurück?
Wenn Du nicht in der Lage bist halbwegs anständige Informationen zu liefern, kann ich Dich wohl kaum unterstützen.Diese komplette Fehleinschätzung der Dinge ist mir bisher nur einmal unter gekommen: bei Jörg Schilling. Leute, wenn ich in eurem Code Bugs finde und euch das mitteile, dann bin ICH der Unterstützende, und zwar unterstütze ich euch. Nicht umgekehrt. Wer da der Illusion erliegt, daß er als Autor mir Support zukommen läßt, der vertreibt seine einzige Chance auf kostenloses Bugfinden, und — er hat es auch nicht anders verdient. Aber wartet, geht noch weiter.
Was glaubst Du wohl, wie oft ich so eine Funktion hier rumfliegen habe.Ich habe geguckt. Einmal in gnupg 1.4.6 und einmal in gnupg 2.0.1, und zwar der identische Code, cut&paste. Soviel dazu, Werner. Was soll ich sagen, auf solche Spirenzchen habe ich überhaupt gar keinen Bock. Dann kann gnupg halt von mir aus schlecht bleiben. Ich habe mal ein paar Vorträge auf Sicherheitskonferenzen angemeldet, "Auditing GnuPG", da werde ich dann halt die Details erzählen, und demnächst taucht dann hier ein Patch auf, den könnt ihr dann alle haben. Das war jedenfalls mit Sicherheit das letzte Mal, daß ich ihm zu helfen versucht habe.Im Übrigen fände ich das alles nur halb so erbärmlich, wenn Werner nicht öffentliche Förderkohle abgegriffen hätte, um seine Softwareentwicklung zu finanzieren. Damit ist er jetzt bei mir persönlich auf einer Ansehensstufe mit Steuerhinterziehern.
2002-03-12 Werner Koch <wk@gnupg.org&bt;Seit dem gab es da noch andere Probleme, allerdings sieht der Code völlig anders aus in gnupg. Das scheint tatsächlich von zlib 1.1.4 zu sein. GRUSEL!!!Merged changes from zlib 1.1.4.
Das wird offenbar nur reingelinkt, wenn es im System keine zlib gibt. Noch mal Schwein gehabt.
/* Without this kludge some example certs can't be parsed. */Lustigerweise ist das in totem Code (habe jedenfalls niemanden gesehen, der das aufruft). Der ASN.1-Parser in dieser Routine ist auch ansonsten eher kaputt. Mal gucken, was Werner Koch dazu sagt.
if (*r_class == CLASS_UNIVERSAL && !*r_tag)
*r_length = 0;