staging.inyokaproject.org

ChickenLipsRfun2eat schrieb:

Shakesbier schrieb:

Mit dem Speichern der Zugangsdaten bin ich immer noch unschlüssig…

Du kannst ja auch SimpleCrypt nehmen, das wäre dann ohne den Keyring in Eigenregie und natürlich keine starke Verschlüsselung. Dafür hast du nur eine weitere Klasse per copy&paste einzubinden.

Über diese Seite bin ich auch gestolpert; das wäre bezogen auf die Größe und Aufwand der Implementierung genau das richtige. Wenn ich es richtig verstehe, ist aber dann der verwendete Key zur Verschlüsselung das Problem. Da InyokaEdit Opensource ist, stünde der Key dann entweder offen im Quelltext oder ich müsste ihn bspw. beim ersten Start des Editors zufällig generieren aber dann auch irgendwo im Benutzerverzeichnis speichern. Ohne den Sicherheitsaspekt verharmlosen zu wollen, stellt sich auf der anderen Seite die Frage welcher "Hacker" es auf ubuntuusers.de Accounts abgesehen haben können sollte und sich auf einen Editor spezialisiert, der von weniger als 20 Leuten in der Welt benutzt wird 😛

Weniger als 20 Leute ist wahrscheinlich zu gering. 😉

Gleichzeitig müsste auch bei einer Klartextspeicheurng ja erstaml auf das Homeverzeichnis zugegriffen werden. Personen, die auf mein Homeverzeichnis zugreifen können, vertraue ich sowieso. Ich glaube eine Speicherung im Klartext wäre akut vielleicht am einfachsten. Es könnte ja auch eine Funktion sein, die erst aktiviert werden muss und per Default muss man halt immer weider sein Passwort eingeben. Nur so als Idee.

...Ohne den Sicherheitsaspekt verharmlosen zu wollen, stellt sich auf der anderen Seite die Frage welcher "Hacker" es auf ubuntuusers.de Accounts abgesehen haben können sollte und sich auf einen Editor spezialisiert, der von weniger als 20 Leuten in der Welt benutzt wird 😛

Hallo Shakesbier, sehe ich genau so!
Lass dich bitte nicht von den hiesigen "Sicherheitsfanatikern" verunsichern!

Dein Projekt, deine Software ist richig toll und Bedarf keinerlei Kritik, hinsichtlich der Sicherheitsaspekte!

Gruß
Bournless

Shakesbier schrieb:

Über diese Seite bin ich auch gestolpert…

Eine Frage mal dazu, da ich keine Ahnung von SSL habe: Du verwendest ja das Passwort aktuell als kurzlebige Variable, die für die Funktionsdauer lebt und verwendest diese dann im Request. Kann man den Request nicht mit einem schon verschlüsselten Passwort aufrufen oder wird das immer on the fly gemacht? Dann könnte man ggf. diesen Schlüssel speichern.

Wenn ich es richtig verstehe, ist aber dann der verwendete Key zur Verschlüsselung das Problem…

Das ist er immer, daher gibt es ja die Passwortspeicher oder alternativ ein Masterpasswort und ein verschlüsselter, gesalzener Speicher. Das funktioniert sehr gut mit QCryptographicHash, ist nur irreversibel, was in dem Fall das Problem darstellt. Wenn man ein Masterpasswort eingeben muss, dann kann man auch sein Inyoka-PW eingeben… Ich persönlich verwende gerade ein Klartextpasswort mit Pseudoverschlüsselung (also keiner). Lokal und für sich selbst kann man das verantworten. Eventuell kann man es ja auch wie das Proxy-PW (nutzt das jemand?) im Klartext speichern und davor warnen.
Aber die Entscheidung musst du schon selbst fällen 😉 Wenn ich sie fälle, wird es ein linux/bsd-only Projekt^^

…welcher "Hacker" es auf ubuntuusers.de Accounts abgesehen haben können sollte und sich auf einen Editor spezialisiert, der von weniger als 20 Leuten in der Welt benutzt wird 😛

Ich habe gehört, in China, auf Hawaii und in Hintertupfingen arbeiten sie schon gemeinsam an einem Botnetz, um InyokaEdit zu knacken… 😇

btw: Bin gerade über https://specifications.freedesktop.org/secret-service/latest/ gestolpert, der der Nachfolger von libgnome-keyring wird (oder ist? ich hab keine Ahnung von GNOME). API Dokumentation gibts hier: https://developer.gnome.org/libsecret/0.20/.

Ich möchte an dieser Stelle gerne betonen, dass das zwar eine schöne Funktion wäre, die aber in meinen Augen ziemlich "unwichtig" ist. Auch wenn ich durchaus verstehe, dass man sich auch an unwichtigen Sachen festbeißen kann. ☺

LG

tuxifreund

PS: Was habe ich hier bloß angestoßen?

tuxifreund schrieb:

…Was habe ich hier bloß angestoßen?

Nichts, was nicht jeder der mit Qt bastelt schonmal als Problem hatte. Für Sailfish OS bspw. hat das Mer-Projekt eine QML-Lösung beigesteuert, die man mittlerweile verwenden kann. Es fehlt aber was allgemeingültiges, was bestenfalls in Qt integriert ist. Soweit ich das gesehen habe, ist aber auch in Qt6 keine Entschlüsselungsmethode integriert, wenn man von Lösungen wie KWallet und dem erwähnten libqt5keychain1 mal absieht.

Hallo zusammen,

habe mich nun für die einfachste Variante entschieden und die Option zum Speichern des Namens und/oder des (unverschlüsselten) Passworts eingebaut. Ab Version 0.26.0 kann jeder frei entscheiden, ob beides oder nur eins davon auf eigene Gefahr gespeichert werden soll.

Shakesbier schrieb:

habe mich nun für die einfachste Variante entschieden und die Option zum Speichern des Namens und/oder des (unverschlüsselten) Passworts eingebaut. Ab Version 0.26.0 kann jeder frei entscheiden, ob beides oder nur eins davon auf eigene Gefahr gespeichert werden soll.

👍

Was mir noch aufgefallen ist, in InyokaEdit kann man z.B. img Tags verwenden und es wird korrekt angezeigt.

Im UU Wiki/HowTo funktioniert das dann aber nicht.

Beispiel

<img src="https://example.de/img.png" width=600/>

Hallo Axel-Erfurt

Was mir noch aufgefallen ist, in InyokaEdit kann man z.B. img Tags verwenden und es wird korrekt angezeigt. Im UU Wiki/HowTo funktioniert das dann aber nicht.

Beispiel

<img src="https://example.de/img.png" width=600/>

Interessant, danke für den Hinweis! Auf die Idee bin ich noch gar nicht gekommen das zu Testen ☺ InyokaEdit übernimmt alles 1:1 in die HTML Vorschau, was kein Inyoka-Syntaxelement ist. Ich muss mal schauen, wie Inyoka das macht und ob es reicht generell die öffnenden/schließenden "< >" in der Vorschau zu maskieren. Hört sich zuerst einmal "leicht" an, kann aber tricky werden! Zur Nachverfolgung: #106

Durch Dein Beispiel bin ich auf eine andere fehlende Funktion gestoßen 😉 Scheinbar ersetzt Inyoka (seit Neustem ?) URLs automatisch in Links (wenn sie nicht im Codeblock auftauchen). Nachverfolgung: #107

Hej Shakesbier,

es scheint, als würden im Editor bestimmte Tabellenformatierungen nicht wirken:

• Ausrichtung "oben" → '^'

Beispiel im Sankasten

Gruß black tencate

Hi black_tentacle

danke für die Meldung des Problems! Ich konnte das Problem im Code lokalisieren. "Prinzipiell" kann InyokaEdit mit allen verfügbaren Tabellenformatierungen umgehen, aber die Kombination mehrerer Formate (bspw. <-2:^ cellstyle="border-style: none";>) macht Probleme und zusätzlich habe ich das im Editor sehr ungünstig/schlecht implementiert (hier muss ich nochmal versuchen nachzuvollziehen, ob ich das aus einem bestimmten Grund so gemacht habe). Damit es nicht vergessen geht #108

Hallo,

so wie es scheint, scheint InyokaEdit nicht mit Aufzählungen in Hinweisboxen klar zu kommen.

Beispiel-Code:

[[Vorlage(Hinweis, "Magst du am UWR [:LocoTeam/UWR/Mitmachen:mitmachen]?

 * Komplette Beiträge können gerne direkt ins [http://uwr.publishwith.me/1 Pad] eingetragen werden. Jeden ''Montagabend ab ca. 20:00 Uhr'' werden dort letzte Texte geschrieben und Korrektur gelesen.
 * Diskussionen und Vorschläge finden sich im [topic:sammelthread-moegliche-themen-fuer-den-uwr:Forum].")]]

Die richtige Darstellung findet man im Sandkasten und das was der Editor drauß macht im Anhang.

Liebe Grüße und danke für den Editor!!

tuxifreund

Hi tuxifreund,

vielen Dank für die Info; zur Nachverfolgung: #109. Mir ist schon zu lange bewusst, das mein extrem zusammengeschustertes "Parserkonzept" bei vielen (Spezial-)Anwendungsfällen an seine Grenzen kommt. Das Herzstück des Editors ist leider von Anfang an sehr unstrukturiert implementiert worden. Ohne eine grundlegende Neustrukturierung oder besser komplette Neuerstellung des Parsers werde ich den Fehler nicht korrigieren können.

Die Entwicklung von InyokaEdit startete vor bald 10 Jahren und die "Programmier- und Designfehler" der Vergangenheit lassen sich wenn überhaupt nur schwer beheben. Ich bin noch unentschlossen in welche Richtung es mit dem Editor weitergeht (keine Angst, ich habe derzeit nicht vor das Projekt aufzugeben 😉), aber egal was kommen möge, es wird viel Arbeit und Zeit benötigen.

InyokaEdit 0.26.0 wurde veröffentlicht. Für den Anwender interessante Änderungen:

• Syntaxfehler werden als Tooltip angezeigt anstatt eines Dialogfensters

• Optionale Möglichkeit zum Speichern der ubuntuusers Zugangsdaten (benötigt für Up-/Download eines Artikels)

• Support für Qt 6

• Urls im Fließtext werden in Links konvertiert

• Ein paar kleine Fehlerkorrekturen (Syntaxüberprüfung; Behandlung von Weiterleitungen)

• Komplette List der Änderungen: Versionsvergleich 🇬🇧

• Seit dieser Version gibt es InyokaEdit auch als AppImage und für Windows-Nutzer gibt es neben dem ZIP-Archiv nun auch einen Installer: Downloadseite ⮷