staging.inyokaproject.org

+1 - siehe oben 😉

Wer machts?

ramnit schrieb:

Wer machts?

Ich nutze kein Pidgin 😛

Wollte es schon machen, aber mir ist kein gescheiter Text eingefallen 😬

Wer machts?

Ich nutze kein Pidgin 😛

Wollte es schon machen, aber mir ist kein gescheiter Text eingefallen 😬

Fragt doch einfach ob ich es machen kann. 😉

march schrieb:

Wer machts?

Ich nutze kein Pidgin 😛

Wollte es schon machen, aber mir ist kein gescheiter Text eingefallen 😬

Fragt doch einfach ob ich es machen kann. 😉

Erster. 😈

ramnit schrieb:

Bei der Diskussion um Kopete wandte kaputtnik folgendes ein:

Lieber generalisieren und einen extra-Artikel von der Liste aus Pidgin (Abschnitt „Konto“) machen. Dieser neue Artikel lässt sich dann in allen Instant Messengern verlinken und die Pflege wird erleichtert. Das man damit vllt nicht alle User glücklich macht, muss man in Kauf nehmen.

Was ist eigentlich aus der Idee geworden?

ramnit schrieb:

Was ist eigentlich aus der Idee geworden?

Das hat sich doch jetzt erledigt? Zumindest für XMPP ☺ Den Rest (MSN, Yahoo usw.) könnte man ja noch auslagern. Allerdings sollte man dann die Teile aus XMPP/Server wieder rausnehmen und dann im neuen Artikel unterbringen. Dann hat man alle Zugänge zusammen.

Nur: Ich wäre dagegen, weil kein direkter Bezug zu Ubuntu für einen solchen Artikel (zB Messenger Zugangsdaten) da wäre. Das ist meiner Meinung nach schon bei den ganzen XMPP-Artikeln an der Grenze zum Ubuntubezug. Ausserdem sind die anderen Protokolle AFAIK proprietär und sollten nicht unbedingt „beworben” werden.

Oder sehe ich das wieder zu eng 😬

Gruß
kaputtnik

Ist auf jeden Fall eine Grenzentscheidung. Wenn der Bezug zu Ubuntu fehlt, hat das aber auch im aktuellen Artikel keinen Bezug. Und wir haben damals in der Kopete Diskussion darauf verwiesen, dass das nicht zum Messenger gehört, weil es sonst zu starke Redunzen gibt, nicht weil es redundant wäre.

Wir sollten auf jeden Fall eine Entscheidung fällen, wie wir damit umgehen:

• entfernen, weil fehlender Bezug zu Ubuntu

• zentral erfasst, zur Vermeidung von Redundanzen

• so lassen, weil wir uneinig sind

• ...

Frag das doch mal intern nach ☺

Ich habe erst kürzlich entdeckt, dass Pidgin die Passwörter im Klartext speichert:

http://developer.pidgin.im/wiki/GSoC2008/MasterPassword

Vielleicht sollte man das als sicherheitsrelevanten Hinweist hinzufügen. Ich hätte das gerne früher gewusst und ich denke es ist auch für andere wichtig, die dort eventuell sensible Passwörter speichern.

-JCW- schrieb:

Ich habe erst kürzlich entdeckt, dass Pidgin die Passwörter im Klartext speichert:

http://developer.pidgin.im/wiki/GSoC2008/MasterPassword

Diese Quelle ist fast 4 Jahre alt - wie sieht es aktuell aus?

Hi,

die Passwörter werden noch immer im Klartext gespeichert. Als Abhilfe kann da das Gnome-Keyring-Plugin helfen.

Gruss Lasall

Lasall schrieb:

die Passwörter werden noch immer im Klartext gespeichert. Als Abhilfe kann da das Gnome-Keyring-Plugin helfen.

Oder eben Passwoerter nicht in Pidgin speichern...

-JCW- schrieb:

Vielleicht sollte man das als sicherheitsrelevanten Hinweist hinzufügen. Ich hätte das gerne früher gewusst und ich denke es ist auch für andere wichtig, die dort eventuell sensible Passwörter speichern.

Kuemmerst Du Dich darum?

Hab jetzt einen Satz dazu geschrieben. Ist das ok so?

Wie man evetuell Abhilfe schafft mit dem Plugin müsst ihr schreiben, damit kenne ich mich nicht so aus.

Das ist übrigens mein erster Beitrag zum Wiki! 😛

-JCW- schrieb:

Wie man evetuell Abhilfe schafft mit dem Plugin müsst ihr schreiben, damit kenne ich mich nicht so aus.

Sofern sich nichts geändert hat, steht das im Wiki. Ich habe das vor längerer Zeit eingetragen. 😉 Sehr genau hast du anscheinend nicht gelesen. 😉

Okay mittlerweile gibt es Debian-Pakete. Damit ist die Installation noch bequemer. ☺

Hallo in die Runde,

Pidgin hat immer die Datenübertragung abgebrochen. Siehe Anhang.

Der Fehler liegt in Avahi.

Begründung siehe hier.

Wie kann das ins Wiki eingebaut werden ❓

Erbitte Vorschläge. Es besteht die Gefahr, das die Seite bis zur Beseitigung des Fehlers nicht mehr aufgerufen werden kann.