From fnord@pentabarf.de Tue May 6 17:44:11 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Tue, 06 May 2008 18:44:11 +0200 Subject: [OTR-dev] OTR static strings and html stuff Message-ID: <1210092251.6154.14.camel@hegg> --=-sIUxd8D8baYHB0p3DbDf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi! As I'm currently actively working on getting OTR-encryption working for gajim (see [1]), I've stumbled upon some annoyances in current libotr. 1.) basically all strings used in OTR for user interfaces contain HTML. This is very bad because it breaks CLI clients or clients that don't send HTML over tags in XMPP (*wink* pidgin-otr) 2.) none of those strings are translatable! IMHO libotr should not use human-readable text at all but pass error codes which should be translated to human-readable text by the implementing application. This would integrate with all localisation methods as well as gives HTML-enabled clients the possibility to use HTML. Thoughts? Thanks, Kjell --=-sIUxd8D8baYHB0p3DbDf Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIIIrbNjvKGrx0tZgRAglyAJ92kQVefREAhe7+A5H1T1pGav5T7QCeJu3C wf4RewxuHUTp8ARHw/o98vE= =+e1c -----END PGP SIGNATURE----- --=-sIUxd8D8baYHB0p3DbDf-- From evan.s@dreskin.net Tue May 6 18:51:07 2008 From: evan.s@dreskin.net (Evan Schoenberg) Date: Tue, 6 May 2008 13:51:07 -0400 Subject: [OTR-dev] OTR static strings and html stuff In-Reply-To: <1210092251.6154.14.camel@hegg> References: <1210092251.6154.14.camel@hegg> Message-ID: <8C9BEDEB-5FB7-4D06-B9B4-67C5608968D0@dreskin.net> I agree on both points, Kjell! I'm not an OTR dev but I know the library fairly well and would be happy to help review a patch if you're volunteering to write it :) Cheers, Evan On May 6, 2008, at 12:44 PM, Kjell Braden wrote: > Hi! > > As I'm currently actively working on getting OTR-encryption working > for > gajim (see [1]), I've stumbled upon some annoyances in current libotr. > > 1.) basically all strings used in OTR for user interfaces contain > HTML. > This is very bad because it breaks CLI clients or clients that don't > send HTML over tags in XMPP (*wink* pidgin-otr) > 2.) none of those strings are translatable! IMHO libotr should not use > human-readable text at all but pass error codes which should be > translated to human-readable text by the implementing application. > This > would integrate with all localisation methods as well as gives > HTML-enabled clients the possibility to use HTML. > > Thoughts? > > Thanks, > Kjell From ian@cypherpunks.ca Tue May 6 22:46:10 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 6 May 2008 17:46:10 -0400 Subject: [OTR-dev] OTR static strings and html stuff In-Reply-To: <1210092251.6154.14.camel@hegg> References: <1210092251.6154.14.camel@hegg> Message-ID: <20080506214610.GS6425@yoink.cs.uwaterloo.ca> On Tue, May 06, 2008 at 06:44:11PM +0200, Kjell Braden wrote: > Hi! > > As I'm currently actively working on getting OTR-encryption working for > gajim (see [1]), I've stumbled upon some annoyances in current libotr. > > 1.) basically all strings used in OTR for user interfaces contain HTML. > This is very bad because it breaks CLI clients or clients that don't > send HTML over tags in XMPP (*wink* pidgin-otr) > 2.) none of those strings are translatable! IMHO libotr should not use > human-readable text at all but pass error codes which should be > translated to human-readable text by the implementing application. This > would integrate with all localisation methods as well as gives > HTML-enabled clients the possibility to use HTML. > > Thoughts? You're absolutely correct, and it's on the to-do list. I don't have a body actually working on it, though. The plan is to add a callback to the OtrlMessageAppOps which will take a code (it's used for more than just errors) and some other useful parameters, and it'll be up to the calling application to do something human-reasonable with it. - Ian From ian@cypherpunks.ca Tue May 13 14:22:19 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 13 May 2008 09:22:19 -0400 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> Message-ID: <20080513132219.GB7120@thunk.cs.uwaterloo.ca> There are a number of issues raised in this thread. Let me know if I miss any. I'll start with the simple ones. Scott> The other serious problem in my mind is the need for a 'i'm going Scott> offline now' message It's not mandatory. It didn't exist in the first version of the protocol. It's just a hint to the other side that you've gone away, and they're free to deallocate a few resources (and forget the remaining one or two keys). Or are you referring to something else? Jonathan> I also noticed that libotr returns HTML error messages, which Jonathan> we think is bad, they are not translatable and we have to Jonathan> strip HTML from them. We also think this is bad, bad, bad. libotr is divided into three parts: - the low-level packet format, encryption, keys, state, etc. - user authentication support (Socialist Millionaires' protocol in the current version) - the messaging support (otrl_message_sending, fragmentation, etc.) The messaging support is completely crufty. It contains hardcoded English HTML strings, among other nonsense. We're starting a project to revamp the libotr API now, particularly the messaging part. For reference, here are the OTR projects currently underway over the next 3-4 months: - New UI for user authentication, based on results of user study (which will be published in the Symposium On Usable Privacy and Security: SOUPS 2008). The code is pretty much done for this; it needs a congifuration checkbox and some revamped documentation. - Implementation of libotr in Java, hopefully leading to some OTR-on-smartphone action. - Addressing the user-logged-in-multiple-times problem. - libotr API cleanup, as above. Anyone who wants to volunteer to help with in particular the new API, now's the time. One of the big goals is exactly to make libotr have fewer pidgin idioms in it. To do this, we need people with experience with the internals of other IM clients to contribute their domain knowledge. Rüdiger> According to the OTR spec, the library is supposed to do Rüdiger> nothing more than replace the plain text with the encrypted Rüdiger> text. As such, the place for text/plain is supposed to contain Rüdiger> encryped text/plain, while the place for text/html is supposed Rüdiger> to contain encrypted text/html. OK, this is the big one. As was noted, it comes up from time to time. In this post, I'll try to clarify my thoughts on the matter. That's not quite what the spec says, as Scott (I think it was) points out. But let's put that aside. Let's talk about what the spec *should* say, not what it says now. The plaintext of an OTR message is a sequence of bytes. How do you interpret those bytes? In addition to the content-type issue (is it text/plain, text/html, text/xhtml, something else?), there's also the encoding issue, which no one seems to have raised. These two things actually go hand-in-hand. The AIM protocol, for example, specifies three choices for the encoding: 7 bit ASCII, UCS-2BE, and ISO-8859-1. Note that none of these is UTF-8 (though some clients may exploit the fact that 7-bit ASCII is a subset of UTF-8 and hope the other end doesn't barf on it). So who specifies the encoding and content-type for the plaintext sequence of bytes inside the OTR packet? There are three choices I see: 1. It's specified explicitly in the protocol. Everyone uses the same choice, and you have to convert between whatever you use natively and this choice before encrypting / after decrypting. Note that it's perfectly reasonable for libotr to provide some commonly used conversion routines to help you with this. 2. It's specified explicitly in the OTR Data packet (within the authenticated section). Different clients may make different choices, or make different choices for different messages (such as the text/plain and text/xhtml parts of a Jabber message). Clients will need to convert between the choice received and their native choice. libotr could again help here by providing common conversions, but now you potentially have an n^2 problem as all formats need to be converted to all other formats. 3. It's specified implicitly by context, probably by "inheriting" whatever encoding and content-type are being used to format the OTR ciphertext. This has the advantage of clients not having to convert anything, since they can just do "in-place" encryption/decryption, most of the time. Rüdiger is advocating 3; someone else on the list suggested 2. I'm going to suggest 1. Here are my reasons. My main issue with 3 is the potential security hole it opens up. Unlike 1 and 2, the method of interpretation of the plaintext bytes is not securely specified, and is in fact under the control of an adversary. For example, suppose there's a Jabber message sent (in model 3), where the body section contains an encryption of "to put something in bold, wrap around it" and the xhtml section contains an encryption of "to put something in bold, wrap <b></b> around it". Then an adversary replaces the OTR block in the xhtml section with the one from the body section. An end user with an xhtml-aware client will see "to put something in bold, wrap around it", and the attacker has successfully modified the message. The advantage of 1 over 2 is just that there's no chance someone will pick a bizarre format you don't know about; you just need to convert between whatever native format you use for your IM client/protocol and the fixed OTR format. So here's my proposal, which is of course open for debate. - Specify that OTR plaintext is UTF-8 text/xhtml. - Clarify in the section on encrypting/decrypting that you need to convert your plaintext to/from that format. - Have at least one version of the encrypt/decrypt API call take as a parameter the format (type and encoding) your plaintext should be in, and libotr will convert it for you (assuming it knows that format). So if this were implemented, Jabber clients would call otrl_message_sending/receiving with a parameter of UTF8_TEXT_PLAIN to encrypt/decrypt the body part, and UTF8_TEXT_XHTML to encrypt/decrypt the xhtml part. The fact that what you get when you apply AES-CTR to the OTR message body is in fact UTF-8 text/xhtml in either case should be totally transparent. Ideally, I could decide to standardize on "UCS-2BE text/rtf rot13" and you wouldn't even notice. [But of course, everyone would have to be using an OTR library that supported this.] There's a slightly related problem of what do you do if the encoded OTR string (the "?OTR:AAED...") isn't appropriate for your IM protocol. For example, AIM using UCS-2BE. I suppose libotr could translate that for you as well (to "\x00?\x00O\x00T\x00R\x00:\x00A\x00A\x00E\x00D..."), but that's a really rare case. I'll note that the outcome of the "fix the multiple login problem" work above will certainly lead to a rev of the OTR wire protocol. So that would be a great time to clarify this as well. I think that's long enough for now. ["I made this letter longer than usual because I lack the time to make it shorter." -- Blaise Pascal] Comments? - Ian From mail@scottellis.com.au Wed May 14 03:21:45 2008 From: mail@scottellis.com.au (Scott Ellis) Date: Wed, 14 May 2008 12:21:45 +1000 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <20080513132219.GB7120@thunk.cs.uwaterloo.ca> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> Message-ID: <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> ------=_Part_6327_26961160.1210731706244 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > Scott> The other serious problem in my mind is the need for a 'i'm going > Scott> offline now' message > > It's not mandatory. It didn't exist in the first version of the > protocol. It's just a hint to the other side that you've gone away, and > they're free to deallocate a few resources (and forget the remaining one > or two keys). In previous discussions about this (too long ago for me to remember who was involved, sorry), I commented that I'd tried to resolve the issue by watching user status. It was mentioned that this can be exploited in an attack if the user status can be spoofed, allowing sessions to be continuously reset, at least chewing resources and possibly reducing the level of security. I don't see any better options though in clients where an 'end of session' message isn't possible. Another problem with this method is that clients who do not end sessions due to an offline status expect to be able to continue the session with 'offline' contacts, causing at least renegotiation but usually requiring a whole new session. And that's not even considering offline messages and invisible users. I'm confused by some of your terminology (I am no cryptographer): "you have to convert between whatever you use natively and this choice before encrypting / after decrypting" - don't you mean after encrypting/before decrypting? You say 'plaintext of an OTR message' - which i would assume to be the decrypted version, and then talk about the 'plaintext byes in an OTR packet' - which I would assume to be the encrypted bytes...or are you talking about the parts of the OTR packet that are not the encrypted message? Nevertheless I think I understand most of what you meant. Below I'm using 'plaintext' to mean 'decoded/unencrypted'. With the encoding stuff, I think you are skirting the major point: for a lot of clients (maybe even most of them) it would be more convenient if the OTR plaintext followed the rules of the transport protocol - i.e. does not contain HTML when using a protocol for transport that does not allow HTML in messages. We're not just talking about ending up with HTML in the plaintext part of jabber stanzas - we're talking about getting HTML tags in decoded AIM messages, and other protocols that don't allow HTML at all. Jabber is atypical and shouldn't be the protocol you use when thinking about this stuff, imo. Also, it usually does not make sense to talk about what a 'jabber(/icq/gg/etc) client' would do (as opposed to what some other client might do) - in a plugin-based multi-protocol messenger, you are not going to have each protocol plugin including code for making calls to OTR - the architecture needs to allow for encryption plugins to get their hands on messages at the appropriate times, via callbacks or whatever. I haven't seen a callback mechanism that would allow for the tight coupling you've described. Protocols and encryption plugins need to be treated uniformly - this makes encryption plugins fundamentally different from protocol plugins. It is unusual for an encryption library to claim protocol status, and I think it just causes problems.. I think this is why the issue of encoding has not come up. People just expect to get out whatever they put in. There should be no need to pass in to OTR any content-type information. The plaintext bytes should be interpreted by the protocol as any other bunch of plaintext bytes are interpreted - the encryption should be transparent to the protocol. For clients that don't natively handle HTML in the interface, it creates a lot of complications if suddenly you have HTML in messages over protocols that would normally handle that themselves. With overly simple (niave?) callback mechanisms, the message is decoded after the protocol has received it but then continues on it's way to the UI without the usual processing that the protocol plugin would do to plaintext. At a minimum that means the decoded messages have to be passed back through any HTML stipping or translation code, and unfortunately that code is usually packaged within the protocol plugin and not exposed via an API. Extending this (and admittedly getting a little bit contrived), what if the protocol allows for embedded commands or configuration or 'customised smileys' or other similar things? The protocol needs to get the message off the network, decrypt it, and then get the decrypted message back to handle as it would any other. Trying to define OTR as a protocol means losing all of this protocol-specific functionality (which, in the case of configuration, may be essential to workings of the protocol) and potentially being forced to include copies of existing code. I don't think it makes much sense to talk about putting encoded HTML in the HTML part of a jabber message - I don't think you'll ever get agreement on the technicalities - i.e. whether it is still HTML when encoded. Imo, a solution that works for jabber is unlikely to work generically. I think the appropriate way to handle jabber would be to take both elements, perhaps even the whole iq stanza, and embed the encrypted version in a message as if it were text/plain data. That would prevent the kinds of attacks you mention, and perhaps make it possible to treat jabber more like other protocols. As it is a special case I think it would be justified if jabber clients and plugins did make their own specific calls to the OTR library, if that turned out to be necessary. I've never had to worry about the encoding used for encrypted OTR messages either - there ought to be encoding information passed from the protocol to OTR during decryption and encryption. E.g. the message being sent comes in to the protocol, is formatted for sending and passed to OTR along with information about it's encoding. It will be converted to UTF8, encoded by OTR, and the encrypted version converted back to the encoding used by the protocol. Scott ------=_Part_6327_26961160.1210731706244 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij5TY290dCZndDsgVGhl IG90aGVyIHNlcmlvdXMgcHJvYmxlbSBpbiBteSBtaW5kIGlzIHRoZSBuZWVkIGZvciBhICYjMzk7 aSYjMzk7bSBnb2luZzxicj4KClNjb3R0Jmd0OyBvZmZsaW5lIG5vdyYjMzk7IG1lc3NhZ2U8YnI+ Cjxicj4KSXQmIzM5O3Mgbm90IG1hbmRhdG9yeS4gJm5ic3A7SXQgZGlkbiYjMzk7dCBleGlzdCBp biB0aGUgZmlyc3QgdmVyc2lvbiBvZiB0aGU8YnI+CnByb3RvY29sLiAmbmJzcDtJdCYjMzk7cyBq dXN0IGEgaGludCB0byB0aGUgb3RoZXIgc2lkZSB0aGF0IHlvdSYjMzk7dmUgZ29uZSBhd2F5LCBh bmQ8YnI+CnRoZXkmIzM5O3JlIGZyZWUgdG8gZGVhbGxvY2F0ZSBhIGZldyByZXNvdXJjZXMgKGFu ZCBmb3JnZXQgdGhlIHJlbWFpbmluZyBvbmU8YnI+Cm9yIHR3byBrZXlzKS4gPC9ibG9ja3F1b3Rl PjxkaXY+PGJyPkluIHByZXZpb3VzIGRpc2N1c3Npb25zIGFib3V0IHRoaXMgKHRvbyBsb25nIGFn byBmb3IgbWUgdG8gcmVtZW1iZXIgd2hvIHdhcyBpbnZvbHZlZCwgc29ycnkpLCBJIGNvbW1lbnRl ZCB0aGF0IEkmIzM5O2QgdHJpZWQgdG8gcmVzb2x2ZSB0aGUgaXNzdWUgYnkgd2F0Y2hpbmcgdXNl ciBzdGF0dXMuIEl0IHdhcyBtZW50aW9uZWQgdGhhdCB0aGlzIGNhbiBiZSBleHBsb2l0ZWQgaW4g YW4gYXR0YWNrIGlmIHRoZSB1c2VyIHN0YXR1cyBjYW4gYmUgc3Bvb2ZlZCwgYWxsb3dpbmcgc2Vz c2lvbnMgdG8gYmUgY29udGludW91c2x5IHJlc2V0LCBhdCBsZWFzdCBjaGV3aW5nIHJlc291cmNl cyBhbmQgcG9zc2libHkgcmVkdWNpbmcgdGhlIGxldmVsIG9mIHNlY3VyaXR5LiBJIGRvbiYjMzk7 dCBzZWUgYW55IGJldHRlciBvcHRpb25zIHRob3VnaCBpbiBjbGllbnRzIHdoZXJlIGFuICYjMzk7 ZW5kIG9mIHNlc3Npb24mIzM5OyBtZXNzYWdlIGlzbiYjMzk7dCBwb3NzaWJsZS4gQW5vdGhlciBw cm9ibGVtIHdpdGggdGhpcyBtZXRob2QgaXMgdGhhdCBjbGllbnRzIHdobyBkbyBub3QgZW5kIHNl c3Npb25zIGR1ZSB0byBhbiBvZmZsaW5lIHN0YXR1cyBleHBlY3QgdG8gYmUgYWJsZSB0byBjb250 aW51ZSB0aGUgc2Vzc2lvbiB3aXRoICYjMzk7b2ZmbGluZSYjMzk7IGNvbnRhY3RzLCBjYXVzaW5n IGF0IGxlYXN0IHJlbmVnb3RpYXRpb24gYnV0IHVzdWFsbHkgcmVxdWlyaW5nIGEgd2hvbGUgbmV3 IHNlc3Npb24uIEFuZCB0aGF0JiMzOTtzIG5vdCBldmVuIGNvbnNpZGVyaW5nIG9mZmxpbmUgbWVz c2FnZXMgYW5kIGludmlzaWJsZSB1c2Vycy48YnI+Cjxicj5JJiMzOTttIGNvbmZ1c2VkIGJ5IHNv bWUgb2YgeW91ciB0ZXJtaW5vbG9neSAoSSBhbSBubyBjcnlwdG9ncmFwaGVyKTogJnF1b3Q7eW91 IGhhdmUgdG8gY29udmVydCBiZXR3ZWVuIHdoYXRldmVyIHlvdSB1c2UgbmF0aXZlbHkgYW5kIHRo aXMgY2hvaWNlIGJlZm9yZSBlbmNyeXB0aW5nIC8gYWZ0ZXIgZGVjcnlwdGluZyZxdW90OyAtIGRv biYjMzk7dCB5b3UgbWVhbiBhZnRlciBlbmNyeXB0aW5nL2JlZm9yZSBkZWNyeXB0aW5nPyBZb3Ug c2F5ICYjMzk7cGxhaW50ZXh0IG9mIGFuIE9UUiBtZXNzYWdlJiMzOTsgLSB3aGljaCBpIHdvdWxk IGFzc3VtZSB0byBiZSB0aGUgZGVjcnlwdGVkIHZlcnNpb24sIGFuZCB0aGVuIHRhbGsgYWJvdXQg dGhlICYjMzk7cGxhaW50ZXh0IGJ5ZXMgaW4gYW4gT1RSIHBhY2tldCYjMzk7IC0gd2hpY2ggSSB3 b3VsZCBhc3N1bWUgdG8gYmUgdGhlIGVuY3J5cHRlZCBieXRlcy4uLm9yIGFyZSB5b3UgdGFsa2lu ZyBhYm91dCB0aGUgcGFydHMgb2YgdGhlIE9UUiBwYWNrZXQgdGhhdCBhcmUgbm90IHRoZSBlbmNy eXB0ZWQgbWVzc2FnZT8gTmV2ZXJ0aGVsZXNzIEkgdGhpbmsgSSB1bmRlcnN0YW5kIG1vc3Qgb2Yg d2hhdCB5b3UgbWVhbnQuIEJlbG93IEkmIzM5O20gdXNpbmcgJiMzOTtwbGFpbnRleHQmIzM5OyB0 byBtZWFuICYjMzk7ZGVjb2RlZC91bmVuY3J5cHRlZCYjMzk7Ljxicj4KPGJyPldpdGggdGhlIGVu Y29kaW5nIHN0dWZmLCBJIHRoaW5rIHlvdSBhcmUgc2tpcnRpbmcgdGhlIG1ham9yIHBvaW50OiBm b3IgYSBsb3Qgb2YgY2xpZW50cyAobWF5YmUgZXZlbiBtb3N0IG9mIHRoZW0pIGl0IHdvdWxkIGJl IG1vcmUgY29udmVuaWVudCBpZiB0aGUgT1RSIHBsYWludGV4dCBmb2xsb3dlZCB0aGUgcnVsZXMg b2YgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCAtIGkuZS4gZG9lcyBub3QgY29udGFpbiBIVE1MIHdo ZW4gdXNpbmcgYSBwcm90b2NvbCBmb3IgdHJhbnNwb3J0IHRoYXQgZG9lcyBub3QgYWxsb3cgSFRN TCBpbiBtZXNzYWdlcy4gV2UmIzM5O3JlIG5vdCBqdXN0IHRhbGtpbmcgYWJvdXQgZW5kaW5nIHVw IHdpdGggSFRNTCBpbiB0aGUgcGxhaW50ZXh0IHBhcnQgb2YgamFiYmVyIHN0YW56YXMgLSB3ZSYj Mzk7cmUgdGFsa2luZyBhYm91dCBnZXR0aW5nIEhUTUwgdGFncyBpbiBkZWNvZGVkIEFJTSBtZXNz YWdlcywgYW5kIG90aGVyIHByb3RvY29scyB0aGF0IGRvbiYjMzk7dCBhbGxvdyBIVE1MIGF0IGFs bC4gSmFiYmVyIGlzIGF0eXBpY2FsIGFuZCBzaG91bGRuJiMzOTt0IGJlIHRoZSBwcm90b2NvbCB5 b3UgdXNlIHdoZW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBzdHVmZiwgaW1vLiBBbHNvLCBpdCB1c3Vh bGx5IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gdGFsayBhYm91dCB3aGF0IGEgJiMzOTtqYWJiZXIo L2ljcS9nZy9ldGMpIGNsaWVudCYjMzk7IHdvdWxkIGRvIChhcyBvcHBvc2VkIHRvIHdoYXQgc29t ZSBvdGhlciBjbGllbnQgbWlnaHQgZG8pIC0gaW4gYSBwbHVnaW4tYmFzZWQgbXVsdGktcHJvdG9j b2wgbWVzc2VuZ2VyLCB5b3UgYXJlIG5vdCBnb2luZyB0byBoYXZlIGVhY2ggcHJvdG9jb2wgcGx1 Z2luIGluY2x1ZGluZyBjb2RlIGZvciBtYWtpbmcgY2FsbHMgdG8gT1RSIC0gdGhlIGFyY2hpdGVj dHVyZSBuZWVkcyB0byBhbGxvdyBmb3IgZW5jcnlwdGlvbiBwbHVnaW5zIHRvIGdldCB0aGVpciBo YW5kcyBvbiBtZXNzYWdlcyBhdCB0aGUgYXBwcm9wcmlhdGUgdGltZXMsIHZpYSBjYWxsYmFja3Mg b3Igd2hhdGV2ZXIuIEkgaGF2ZW4mIzM5O3Qgc2VlbiBhIGNhbGxiYWNrIG1lY2hhbmlzbSB0aGF0 IHdvdWxkIGFsbG93IGZvciB0aGUgdGlnaHQgY291cGxpbmcgeW91JiMzOTt2ZSBkZXNjcmliZWQu IFByb3RvY29scyBhbmQgZW5jcnlwdGlvbiBwbHVnaW5zIG5lZWQgdG8gYmUgdHJlYXRlZCB1bmlm b3JtbHkgLSB0aGlzIG1ha2VzIGVuY3J5cHRpb24gcGx1Z2lucyBmdW5kYW1lbnRhbGx5IGRpZmZl cmVudCBmcm9tIHByb3RvY29sIHBsdWdpbnMuIEl0IGlzIHVudXN1YWwgZm9yIGFuIGVuY3J5cHRp b24gbGlicmFyeSB0byBjbGFpbSBwcm90b2NvbCBzdGF0dXMsIGFuZCBJIHRoaW5rIGl0IGp1c3Qg Y2F1c2VzIHByb2JsZW1zLi48YnI+Cjxicj5JIHRoaW5rIHRoaXMgaXMgd2h5IHRoZSBpc3N1ZSBv ZiBlbmNvZGluZyBoYXMgbm90IGNvbWUgdXAuIFBlb3BsZSBqdXN0IGV4cGVjdCB0byBnZXQgb3V0 IHdoYXRldmVyIHRoZXkgcHV0IGluLiBUaGVyZSBzaG91bGQgYmUgbm8gbmVlZCB0byBwYXNzIGlu IHRvIE9UUiBhbnkgY29udGVudC10eXBlIGluZm9ybWF0aW9uLiBUaGUgcGxhaW50ZXh0IGJ5dGVz IHNob3VsZCBiZSBpbnRlcnByZXRlZCBieSB0aGUgcHJvdG9jb2wgYXMgYW55IG90aGVyIGJ1bmNo IG9mIHBsYWludGV4dCBieXRlcyBhcmUgaW50ZXJwcmV0ZWQgLSB0aGUgZW5jcnlwdGlvbiBzaG91 bGQgYmUgdHJhbnNwYXJlbnQgdG8gdGhlIHByb3RvY29sLjxicj4KPGJyPkZvciBjbGllbnRzIHRo YXQgZG9uJiMzOTt0IG5hdGl2ZWx5IGhhbmRsZSBIVE1MIGluIHRoZSBpbnRlcmZhY2UsIGl0IGNy ZWF0ZXMgYSBsb3Qgb2YgY29tcGxpY2F0aW9ucyBpZiBzdWRkZW5seSB5b3UgaGF2ZSBIVE1MIGlu IG1lc3NhZ2VzIG92ZXIgcHJvdG9jb2xzIHRoYXQgd291bGQgbm9ybWFsbHkgaGFuZGxlIHRoYXQg dGhlbXNlbHZlcy4gV2l0aCBvdmVybHkgc2ltcGxlIChuaWF2ZT8pIGNhbGxiYWNrIG1lY2hhbmlz bXMsIHRoZSBtZXNzYWdlIGlzIGRlY29kZWQgYWZ0ZXIgdGhlIHByb3RvY29sIGhhcyByZWNlaXZl ZCBpdCBidXQgdGhlbiBjb250aW51ZXMgb24gaXQmIzM5O3Mgd2F5IHRvIHRoZSBVSSB3aXRob3V0 IHRoZSB1c3VhbCBwcm9jZXNzaW5nIHRoYXQgdGhlIHByb3RvY29sIHBsdWdpbiB3b3VsZCBkbyB0 byBwbGFpbnRleHQuIEF0IGEgbWluaW11bSB0aGF0IG1lYW5zIHRoZSBkZWNvZGVkIG1lc3NhZ2Vz IGhhdmUgdG8gYmUgcGFzc2VkIGJhY2sgdGhyb3VnaCBhbnkgSFRNTCBzdGlwcGluZyBvciB0cmFu c2xhdGlvbiBjb2RlLCBhbmQgdW5mb3J0dW5hdGVseSB0aGF0IGNvZGUgaXMgdXN1YWxseSBwYWNr YWdlZCB3aXRoaW4gdGhlIHByb3RvY29sIHBsdWdpbiBhbmQgbm90IGV4cG9zZWQgdmlhIGFuIEFQ SS4gRXh0ZW5kaW5nIHRoaXMgKGFuZCBhZG1pdHRlZGx5IGdldHRpbmcgYSBsaXR0bGUgYml0IGNv bnRyaXZlZCksIHdoYXQgaWYgdGhlIHByb3RvY29sIGFsbG93cyBmb3IgZW1iZWRkZWQgY29tbWFu ZHMgb3IKY29uZmlndXJhdGlvbiBvciAmIzM5O2N1c3RvbWlzZWQgc21pbGV5cyYjMzk7IG9yIG90 aGVyIHNpbWlsYXIgdGhpbmdzPyBUaGUgcHJvdG9jb2wgbmVlZHMgdG8gZ2V0IHRoZQptZXNzYWdl IG9mZiB0aGUgbmV0d29yaywgZGVjcnlwdCBpdCwgYW5kIHRoZW4gZ2V0IHRoZSBkZWNyeXB0ZWQg bWVzc2FnZQpiYWNrIHRvIGhhbmRsZSBhcyBpdCB3b3VsZCBhbnkgb3RoZXIuIFRyeWluZyB0byBk ZWZpbmUgT1RSIGFzIGEgcHJvdG9jb2wgbWVhbnMgbG9zaW5nIGFsbCBvZiB0aGlzIHByb3RvY29s LXNwZWNpZmljIGZ1bmN0aW9uYWxpdHkgKHdoaWNoLCBpbiB0aGUgY2FzZSBvZiBjb25maWd1cmF0 aW9uLCBtYXkgYmUgZXNzZW50aWFsIHRvIHdvcmtpbmdzIG9mIHRoZSBwcm90b2NvbCkgYW5kIHBv dGVudGlhbGx5IGJlaW5nIGZvcmNlZCB0byBpbmNsdWRlIGNvcGllcyBvZiBleGlzdGluZyBjb2Rl Ljxicj4KPGJyPkkgZG9uJiMzOTt0IHRoaW5rIGl0IG1ha2VzIG11Y2ggc2Vuc2UgdG8gdGFsayBh Ym91dCBwdXR0aW5nIGVuY29kZWQgSFRNTCBpbiB0aGUgSFRNTCBwYXJ0IG9mIGEgamFiYmVyIG1l c3NhZ2UgLSBJIGRvbiYjMzk7dCB0aGluayB5b3UmIzM5O2xsIGV2ZXIgZ2V0IGFncmVlbWVudCBv biB0aGUgdGVjaG5pY2FsaXRpZXMgLSBpLmUuIHdoZXRoZXIgaXQgaXMgc3RpbGwgSFRNTCB3aGVu IGVuY29kZWQuIEltbywgYSBzb2x1dGlvbiB0aGF0IHdvcmtzIGZvciBqYWJiZXIgaXMgdW5saWtl bHkgdG8gd29yayBnZW5lcmljYWxseS4gSSB0aGluayB0aGUgYXBwcm9wcmlhdGUgd2F5IHRvIGhh bmRsZSBqYWJiZXIgd291bGQgYmUgdG8gdGFrZSBib3RoIGVsZW1lbnRzLCBwZXJoYXBzIGV2ZW4g dGhlIHdob2xlIGlxIHN0YW56YSwgYW5kIGVtYmVkIHRoZSBlbmNyeXB0ZWQgdmVyc2lvbiBpbiBh IG1lc3NhZ2UgYXMgaWYgaXQgd2VyZSB0ZXh0L3BsYWluIGRhdGEuIFRoYXQgd291bGQgcHJldmVu dCB0aGUga2luZHMgb2YgYXR0YWNrcyB5b3UgbWVudGlvbiwgYW5kIHBlcmhhcHMgbWFrZSBpdCBw b3NzaWJsZSB0byB0cmVhdCBqYWJiZXIgbW9yZSBsaWtlIG90aGVyIHByb3RvY29scy4gQXMgaXQg aXMgYSBzcGVjaWFsIGNhc2UgSSB0aGluayBpdCB3b3VsZCBiZSBqdXN0aWZpZWQgaWYgamFiYmVy IGNsaWVudHMgYW5kIHBsdWdpbnMgZGlkIG1ha2UgdGhlaXIgb3duIHNwZWNpZmljIGNhbGxzIHRv IHRoZSBPVFIgbGlicmFyeSwgaWYgdGhhdCB0dXJuZWQgb3V0IHRvIGJlIG5lY2Vzc2FyeS48YnI+ Cjxicj5JJiMzOTt2ZSBuZXZlciBoYWQgdG8gd29ycnkgYWJvdXQgdGhlIGVuY29kaW5nIHVzZWQg Zm9yIGVuY3J5cHRlZCBPVFIgbWVzc2FnZXMgZWl0aGVyIC0gdGhlcmUgb3VnaHQgdG8gYmUgZW5j b2RpbmcgaW5mb3JtYXRpb24gcGFzc2VkIGZyb20gdGhlIHByb3RvY29sIHRvIE9UUiBkdXJpbmcg ZGVjcnlwdGlvbiBhbmQgZW5jcnlwdGlvbi4gRS5nLiB0aGUgbWVzc2FnZSBiZWluZyBzZW50IGNv bWVzIGluIHRvIHRoZSBwcm90b2NvbCwgaXMgZm9ybWF0dGVkIGZvciBzZW5kaW5nIGFuZCBwYXNz ZWQgdG8gT1RSIGFsb25nIHdpdGggaW5mb3JtYXRpb24gYWJvdXQgaXQmIzM5O3MgZW5jb2Rpbmcu IEl0IHdpbGwgYmUgY29udmVydGVkIHRvIFVURjgsIGVuY29kZWQgYnkgT1RSLCBhbmQgdGhlIGVu Y3J5cHRlZCB2ZXJzaW9uIGNvbnZlcnRlZCBiYWNrIHRvIHRoZSBlbmNvZGluZyB1c2VkIGJ5IHRo ZSBwcm90b2NvbC48YnI+Cjxicj5TY290dDxicj48L2Rpdj48L2Rpdj4K ------=_Part_6327_26961160.1210731706244-- From mail@scottellis.com.au Wed May 14 03:58:24 2008 From: mail@scottellis.com.au (Scott Ellis) Date: Wed, 14 May 2008 12:58:24 +1000 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: <96e269140805131958t222fcbcbtca339312de71f66d@mail.gmail.com> ------=_Part_6473_7753753.1210733904699 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline > We're not just talking about ending up with HTML in the plaintext part of > jabber stanzas - we're talking about getting HTML tags in decoded AIM > messages, and other protocols that don't allow HTML at all. > I think I need to clarify this one a bit - AIM does allow html tags. What I'm referring to is that in a non-html-aware interface the aim plugin will strip them when a message is received - but that can't be done if the protocol cannot access the decoded message. Same problem for protocols that don't allow HTML and would normally strip it before sending. ------=_Part_6473_7753753.1210733904699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
We're not just talking about ending up with HTML in the plaintext part of jabber stanzas - we're talking about getting HTML tags in decoded AIM messages, and other protocols that don't allow HTML at all.
I think I need to clarify this one a bit - AIM does allow html tags. What I'm referring to is that in a non-html-aware interface the aim plugin will strip them when a message is received - but that can't be done if the protocol cannot access the decoded message. Same problem for protocols that don't allow HTML and would normally strip it before sending.

------=_Part_6473_7753753.1210733904699-- From paul@cypherpunks.ca Fri May 16 16:33:34 2008 From: paul@cypherpunks.ca (Paul Wouters) Date: Fri, 16 May 2008 11:33:34 -0400 (EDT) Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: On Wed, 14 May 2008, Scott Ellis wrote: > > It's not mandatory. It didn't exist in the first version of the > > protocol. It's just a hint to the other side that you've gone away, and > > they're free to deallocate a few resources (and forget the remaining one > > or two keys). > > > In previous discussions about this (too long ago for me to remember who was > involved, sorry), I commented that I'd tried to resolve the issue by > watching user status. Which OTR messed up as it is, because automatic replies to OTR requests make it appear the user is no longer idle, while in fact, the user still is. Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From evan.s@dreskin.net Fri May 16 16:53:05 2008 From: evan.s@dreskin.net (Evan Schoenberg) Date: Fri, 16 May 2008 11:53:05 -0400 Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: On May 16, 2008, at 11:33 AM, Paul Wouters wrote: > On Wed, 14 May 2008, Scott Ellis wrote: > >>> It's not mandatory. It didn't exist in the first version of the >>> protocol. It's just a hint to the other side that you've gone >>> away, and >>> they're free to deallocate a few resources (and forget the >>> remaining one >>> or two keys). >> >> >> In previous discussions about this (too long ago for me to remember >> who was >> involved, sorry), I commented that I'd tried to resolve the issue by >> watching user status. > > Which OTR messed up as it is, because automatic replies to OTR > requests make > it appear the user is no longer idle, while in fact, the user still > is. That certainly isnt how Adium behaves - user activity, not network or automated activity, determines idleness. On what client did you see that behavior? In any case, contact online/offline status is the important bit, I think, not idleness/awayness. -Evan > > > Paul > -- > Building and integrating Virtual Private Networks with Openswan: > http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From tg@mirbsd.de Sun May 18 17:08:13 2008 From: tg@mirbsd.de (Thorsten Glaser) Date: Sun, 18 May 2008 16:08:13 +0000 (UTC) Subject: [OTR-dev] solution for slow key generation Message-ID: Hi! Jonathan complained that OTR key generation took about an hour on his NetBSD computer (he’ll probably provide specs if desired). I dug into the code and found out that this is because libgcrypt (sucky code…) uses /dev/srandom¹ for key generation entropy, which uses blocking reads. While it didn’t take that long for me on MirOS – less than one minute – I’ve written a tool intended to be used as a contributed script, not to replace the code inside of libotr. This script² uses openssl for key generation, so Debian users should take care ☺ as not even using -rand helps with the bug they had. Other dependencies are mksh³, chmod, cat, and of course the openssl command-line tool. Add some suitable entropy source (can optionally be given as command line argument) or pull 32 (additional) bytes from meâ´ (this is a slow box on a slow ADSL connection, but it has good entropy qualityâµ). Like I said, I don’t want to replace or criticise anything (maybe except the decision to not use libcrypto/libssl in the first place ☺), but I’d be glad if you people would look over that script and maybe include it as “contrib†in the next libotr distribution. â‘  may be named different on your OS – http://www.mirbsd.org/man/srandom.4 â‘¡ http://www.mirbsd.org/cvs.cgi/contrib/code/Snippets/otr-genkey.sh â‘¢ http://mirbsd.de/mksh – part of many distributions, ports trees, etc. â‘£ https://herc.mirbsd.org/rb.cgi?from_otr-dev_ml ⑤ https://www.cacert.at/cgi-bin/rngresults – scroll down to the bottom bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs From gdt@ir.bbn.com Tue May 20 12:45:49 2008 From: gdt@ir.bbn.com (Greg Troxel) Date: Tue, 20 May 2008 07:45:49 -0400 Subject: [OTR-dev] solution for slow key generation In-Reply-To: (Thorsten Glaser's message of "Sun, 18 May 2008 16:08:13 +0000 (UTC)") References: Message-ID: Thorsten Glaser writes: > Jonathan complained that OTR key generation took about an hour on his NetBSD > computer (he’ll probably provide specs if desired). I dug into the code and > found out that this is because libgcrypt (sucky code…) uses /dev/srandom¹ for > key generation entropy, which uses blocking reads. Do you really mean srandom? NetBSD provides /dev/random (bits with actual entropy, will block until available) /dev/urandom (bits with entropy if available, and keep hashing if not available) > While it didn’t take that long for me on MirOS – less than one minute – I’ve > written a tool intended to be used as a contributed script, not to replace > the code inside of libotr. This script² uses openssl for key generation, so > Debian users should take care ☺ as not even using -rand helps with the bug > they had. Other dependencies are mksh³, chmod, cat, and of course the openssl > command-line tool. Add some suitable entropy source (can optionally be given > as command line argument) or pull 32 (additional) bytes from meâ´ (this is a > slow box on a slow ADSL connection, but it has good entropy qualityâµ). I'm not sure this is a good idea. openssl ought to be using /dev/random too. If one wants to take bits that might not have adequate entropy, one can just use /dev/urandom. What I do is kick off a 'du /' to get lots of disk activity, which replenishes the pool. It really depends on whether you want to wait for good quality key bits, or to get lesser quality bits faster. RND(4) NetBSD Kernel Interfaces Manual RND(4) NAME rnd -- in kernel entropy collection and random number generation SYNOPSIS pseudo-device rnd DESCRIPTION The rnd pseudo-device uses event timing information collected from many devices, and mixes this into an entropy pool. This pool is stirred with a cryptographically strong hash function when data is extracted from the pool. INTERNAL ENTROPY POOL MANAGEMENT When a hardware event occurs (such as completion of a hard drive transfer or an interrupt from a network device) a timestamp is generated. This timestamp is compared to the previous timestamp recorded for the device, and the first, second, and third order differentials are calculated. If any of these differentials is zero, no entropy is assumed to have been gathered. If all are non-zero, one bit is assumed. Next, data is mixed into the entropy pool using an LFSR (linear feedback shift register). To extract data from the entropy pool, a cryptographically strong hash function is used. The output of this hash is mixed back into the pool using the LFSR, and then folded in half before being returned to the caller. Mixing the actual hash into the pool causes the next extraction to return a different value, even if no timing events were added to the pool. Folding the data in half prevents the caller to derive the actual hash of the pool, preventing some attacks. USER ACCESS User code can obtain random values from the kernel in two ways. Reading from /dev/random will only return values while sufficient entropy exists in the internal pool. When sufficient entropy does not exist, EAGAIN is returned for non-blocking reads, or the read will block for blocking reads. Reading from /dev/urandom will return as many values as requested, even when the entropy pool is empty. This data is not as good as reading from /dev/random since when the pool is empty, data is still returned, degen- erating to a pseudo-random generator. Writing to either device will mix the data written into the pool using the LFSR as above, without modifying the entropy estimation for the pool. RANDOM SOURCE STRUCTURE Each source has a state structure which the kernel uses to hold the tim- ing information and other state for that source. typedef struct { char name[16]; uint32_t last_time; uint32_t last_delta; uint32_t last_delta2; uint32_t total; uint32_t type; uint32_t flags; } rndsource_t; This structure holds the internal representation of a device's timing state. The name field holes the device name, as known to the kernel. The last_time entry is the timestamp of the last time this device gener- ated an event. It is for internal use only, and not in any specific rep- resentation. The last_delta and last_delta2 fields hold the last first- and second-order deltas. The total field holds a count of how many bits this device has potentially generated. This is not the same as how many bits were used from it. The type field holds the device type. Currently, these types are defined: RND_TYPE_DISK The device is a physical hard drive. RND_TYPE_NET The device is a network interface. By default, timing information is collected from this source type, but entropy is not estimated. RND_TYPE_TAPE The device is a tape device. RND_TYPE_TTY The device is a terminal, mouse, or other user input device. RND_TYPE_RNG The device is a random number generator. flags is a bitfield. RND_FLAG_NO_ESTIMATE Do not assume any entropy is in the timing informa- tion. RND_FLAG_NO_COLLECT Do not even add timing information to the pool. IOCTL Various ioctl(2) functions are available to control device behavior, gather statistics, and add data to the entropy pool. These are all defined in the file, along with the data types and constants. RNDGETENTCNT (uint32_t) Return the current entropy count (in bits). RNDGETSRCNUM (rndstat_t) typedef struct { uint32_t start; uint32_t count; rndsource_t source[RND_MAXSTATCOUNT]; } rndstat_t; Return data for sources, starting at start and returning at most count sources. The values returned are actual in-kernel snapshots of the entropy status for devices. Leaking the internal timing information will weaken security. RNDGETSRCNAME (rndstat_name_t) typedef struct { char name[16]; rndsource_t source; } rndstat_name_t; Return the device state for a named device. RNDCTL (rndctl_t) typedef struct { char name[16]; uint32_t type; uint32_t flags; uint32_t mask; } rndctl_t; Change bits in the device state information. If type is 0xff, only the device name stored in name is used. If it is any other value, all devices of type type are altered. This allows all network interfaces to be disabled for entropy collection with one call, for example. The flags and mask work together to change flag bits. The mask field specifies which bits in flags are to be set or cleared. RNDADDDATA (rnddata_t) typedef struct { uint32_t len; uint32_t entropy; u_char data[RND_POOLWORDS * 4]; } rnddata_t; FILES /dev/random Returns ``good'' values only /dev/urandom Always returns data, degenerates to a pseudo-random gener- ator SEE ALSO rndctl(8), rnd(9) HISTORY The random device was first made available in NetBSD 1.3. AUTHORS This implementation was written by Michael Graff using ideas and algorithms gathered from many sources, including the driver written by Ted Ts'o. NetBSD 4.0_RC1 October 12, 1997 NetBSD 4.0_RC1 From tg@mirbsd.de Tue May 20 13:55:54 2008 From: tg@mirbsd.de (Thorsten Glaser) Date: Tue, 20 May 2008 12:55:54 +0000 (UTC) Subject: [OTR-dev] solution for slow key generation In-Reply-To: References: Message-ID: Greg Troxel dixit: >Do you really mean srandom? NetBSD provides Did you not see my reference to the MirBSD srandom(4) manual page further below? ;-) I used this term because the actual names of the random devices differ from platform to platform, so I used the one I’m at home on and put in a link to the explanation. I know for sure it’s /dev/random on Leenocks. >I'm not sure this is a good idea. openssl ought to be using /dev/random Actually, /dev/arandom has better quality on MirBSD (and, possibly, Open- BSD), even though, strongly mathematically spoken, its entropy _level_ is not as high (but the numerical quality of the output is better). >It really depends on whether you want to wait for good quality key bits, >or to get lesser quality bits faster. Considering the fact that you can mix a few bytes from srandom (let me use this name just to avoid confusion with “random†which might be used as a placeholder for all random devices) with some (as many as needed) bytes from urandom and still have a high-quality output (that’s what pools are for after all), _and_ use the -rand option to openssl (-r in my script) to provide additional entropy, this is a no-issue. Paranoid people will of course want to continue using srandom exclusively, but other people won’t want to wait an hour or more on their headless ser- ver for generation of an OTR key for their backup account. Let me phrase it like this: “We sell rope.†(This is actually a quote from a NetBSD developer.) Whether you use that rope to hang yourself or do some- thing clueful with it is up to the user. My script is intended for people who know what they do (and do not run Debian ;-). For reference, again: http://www.mirbsd.org/man/srandom.4 ☺ bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs From paul@cypherpunks.ca Tue May 20 17:36:26 2008 From: paul@cypherpunks.ca (Paul Wouters) Date: Tue, 20 May 2008 12:36:26 -0400 (EDT) Subject: [OTR-dev] Re: Pidgin plugin sends and parses HTML In-Reply-To: References: <20080511172542.181da3f6@webkeks.org> <20080511154815.GA5693@msgids.ruediger-kuhlmann.de> <20080511180406.538e0610@webkeks.org> <20080511163037.GB5693@msgids.ruediger-kuhlmann.de> <96e269140805112020k6ea60e9jaa2a0814cee3ca55@mail.gmail.com> <20080512121737.GA5688@msgids.ruediger-kuhlmann.de> <96e269140805120801s5aa23cc9p37c200bedb59ba95@mail.gmail.com> <20080513132219.GB7120@thunk.cs.uwaterloo.ca> <96e269140805131921y72ef3d4hbc0d7c46f8c2a1d6@mail.gmail.com> Message-ID: On Fri, 16 May 2008, Evan Schoenberg wrote: > >Which OTR messed up as it is, because automatic replies to OTR requests make > >it appear the user is no longer idle, while in fact, the user still is. > > That certainly isnt how Adium behaves - user activity, not network or > automated activity, determines idleness. On what client did you see that > behavior? pidgin. Paul > In any case, contact online/offline status is the important bit, I think, not > idleness/awayness. I never set online/offline, I go by the automatic idle/not idle. Paul From hcat@gmx.net Mon May 26 11:25:56 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Mon, 26 May 2008 12:25:56 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look Message-ID: <20080526102556.10050@gmx.net> Hi everyone. I have been interested in OTR in the past but back then missing support in various widely used clients prevented me from using it. But now the situation seems to be better, with Pidgin, Kopete, Miranda Trillian and Gajim supporting OTR. Personally I use Pidgin, so I'm testing with the 3.1.0 plugin ATM. I'm wondering if there has been any development on the Pidgin plugin since the last release (and I did not find any public SVN etc). I'm mostly wondering about the integration into Pidgin's GUI and the user interaction. For example, the OTR "button" is drawn for any protocol I use ATM. For protocols where I do not have generated a key, it should probably not be shown. Also, this "button" takes a lot of space and I'm wondering if it could be made more compact or even be moved to the chat toolbar? Finally I'm wondering about the icons. The current set of icons is based on the old Gaim icon and does not really fit the style of Pidgin (which uses Tango icons). What icons do other clients use for the OTR states? IMHO it would be important to have the same metaphor for those states on different clients. Each client would then implement the official metaphor in it's own art style (e.g. Tango look for Pidgin). Cheers, Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From fnord@pentabarf.de Mon May 26 13:03:40 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Mon, 26 May 2008 14:03:40 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526102556.10050@gmx.net> References: <20080526102556.10050@gmx.net> Message-ID: <1211803420.6265.5.camel@hegg> --=-pDr/TFacYaepZRmhVYZe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Montag, den 26.05.2008, 12:25 +0200 schrieb hcat@gmx.net: > Hi everyone. >=20 > I have been interested in OTR in the past but back then missing support i= n various widely used clients prevented me from using it. But now the situa= tion seems to be better, with Pidgin, Kopete, Miranda Trillian and Gajim su= pporting OTR. >=20 > Personally I use Pidgin, so I'm testing with the 3.1.0 plugin ATM. I'm wo= ndering if there has been any development on the Pidgin plugin since the la= st release (and I did not find any public SVN etc). I'm mostly wondering ab= out the integration into Pidgin's GUI and the user interaction. >=20 > For example, the OTR "button" is drawn for any protocol I use ATM. For pr= otocols where I do not have generated a key, it should probably not be show= n. Also, this "button" takes a lot of space and I'm wondering if it could b= e made more compact or even be moved to the chat toolbar? >=20 > Finally I'm wondering about the icons. The current set of icons is based = on the old Gaim icon and does not really fit the style of Pidgin (which use= s Tango icons). What icons do other clients use for the OTR states? IMHO it= would be important to have the same metaphor for those states on different= clients. Each client would then implement the official metaphor in it's ow= n art style (e.g. Tango look for Pidgin). >=20 > Cheers, > Michael=20 Just FYI: gajim-svn currently uses the gtk-dialog-authentication stock icon to use the same UI as the esession (jabber-specific OTR-like encryption) uses. --=-pDr/TFacYaepZRmhVYZe Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIOqccNjvKGrx0tZgRApJIAJ9d9xCTENikXUYjdvWm0zzrZCP2gwCgoQhk BDJ90ZSu+JAV7HK8b2Lh72g= =pGNF -----END PGP SIGNATURE----- --=-pDr/TFacYaepZRmhVYZe-- From ian@cypherpunks.ca Mon May 26 13:20:45 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 08:20:45 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526102556.10050@gmx.net> References: <20080526102556.10050@gmx.net> Message-ID: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> On Mon, May 26, 2008 at 12:25:56PM +0200, hcat@gmx.net wrote: > Hi everyone. > > I have been interested in OTR in the past but back then missing > support in various widely used clients prevented me from using it. But > now the situation seems to be better, with Pidgin, Kopete, Miranda > Trillian and Gajim supporting OTR. > > Personally I use Pidgin, so I'm testing with the 3.1.0 plugin ATM. I'm > wondering if there has been any development on the Pidgin plugin since > the last release (and I did not find any public SVN etc). I'm mostly > wondering about the integration into Pidgin's GUI and the user > interaction. > > For example, the OTR "button" is drawn for any protocol I use ATM. For > protocols where I do not have generated a key, it should probably not > be shown. Also, this "button" takes a lot of space and I'm wondering > if it could be made more compact or even be moved to the chat toolbar? > > Finally I'm wondering about the icons. The current set of icons is > based on the old Gaim icon and does not really fit the style of Pidgin > (which uses Tango icons). What icons do other clients use for the OTR > states? IMHO it would be important to have the same metaphor for those > states on different clients. Each client would then implement the > official metaphor in it's own art style (e.g. Tango look for Pidgin). Funny you should ask. ;-) We're just in the final stages of putting a 3.2.0 preview out. The main user interface changes include moving the OTR button to the menu bar (though the button remains an option), support for multiple buddies merged into a single contact / conversation window, improved authentication user interface (based on the user study we did, to appear in SOUPS 2008), and the icons being changed to Tango-based ones. My goal is to get it all into a state where it can be put in the public CVS on sourceforge sometime this week. Then we'll wait a bit for some feedback, and for the various translators to supply translations for the new UI strings, and we'll send it out. - Ian From js-otrim@webkeks.org Mon May 26 15:00:50 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 16:00:50 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526160050.756b19b8@webkeks.org> --Sig_/=XSdsRC3DQYeYWGzn13n_pM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ian Goldberg wrote: > We're just in the final stages of putting a 3.2.0 preview out.=20 Will that mean that libotr 3.2.0 with a fixed and finally usable API will also come soon? --=20 Jonathan --Sig_/=XSdsRC3DQYeYWGzn13n_pM Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIOsKWAAoJEMtRg9d5cXHk7xsP/joo609qo4jHo09kPJRqsYjp soE9C4bqrsOqs8+ZRv/GUr0TB6SL9xLd+g+HOO2vgzDnu5YbvDgNMoeJczWj9toK 95c4RZ2ST/lnNZe01csw9EDNj1iOnAmlzvQe0z0ruPSCg8X7YoJdsRoKTEII7JaC ulpFjKxSXAvoQiw7IPlDMBr4GHIgA736gPElm8Khpc39HDgXq0Loex6QZWJc3Ugx F7BCmYxga68jxNWsIiwmieM3HOFGhNx3RN+N3iFAIhMgnMDwrY70GbZM0hzDUiKV vCNTlFiB3AogAF2mMWikFcLDLdcXO3Vez/oZZpugBRXhURJjJl2svKJafiBbdzS3 Iy08CjH6X6Ut4n2YcXmsl5KhPUm5eqmcYvUkjB8RRngsww2e8wXaYYiNRqujeLf1 iT/TEu+UAhlmPGlXGHHGhy+U+EyFt0sBmUogXQ9RpiRFRNrfHDMax34xW6yKMJZZ 0QxMpFxXYB/itCng3nXBn9sXQLr1cvwxAasZYZlX678FEmEG9PHYBXHnSAFQhige CKcdhbP0yjp0vrdWrmv0OF46j2xBIXIG/y4RpecJfc7My85fYTDO7Nn9k5FuMV8q dTGDDAmE8v/k+KhaX7mt++/0RSrt/6HQlo9W1PJUoG8DqdpftXH8cQHgsOimusn+ eORmREL47ic5nbwHYNhq =tWAK -----END PGP SIGNATURE----- --Sig_/=XSdsRC3DQYeYWGzn13n_pM-- From hcat@gmx.net Mon May 26 15:50:25 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Mon, 26 May 2008 16:50:25 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526145025.270810@gmx.net> > Funny you should ask. ;-) > > We're just in the final stages of putting a 3.2.0 preview out. The > main user interface changes include moving the OTR button to the menu > bar (though the button remains an option), support for multiple > buddies merged into a single contact / conversation window, improved > authentication user interface (based on the user study we did, to appear > in SOUPS 2008), and the icons being changed to Tango-based ones. > > My goal is to get it all into a state where it can be put in the public > CVS on sourceforge sometime this week. Then we'll wait a bit for some > feedback, and for the various translators to supply translations for the > new UI strings, and we'll send it out. Thanks Ian, that's great news! -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From ian@cypherpunks.ca Mon May 26 18:28:08 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 13:28:08 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> On Mon, 26 May 2008 16:00:50 +0200, Jonathan Schleifer wrote: > Will that mean that libotr 3.2.0 with a fixed and finally usable API > will also come soon? As I mentioned, we'll be working on the fixed and usable API over the next few months, and we're still looking for input on what you'd like to see in the API. This will definitely be a non-backwards-compatible API change, so that version should be 4.0.0. But libotr 3.2.0 will in fact be coming out shortly (along with pidgin-otr 3.2.0), with support for the updated authentication mechanism. - Ian From js-otrim@webkeks.org Mon May 26 18:51:14 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 19:51:14 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526195114.41633f72@webkeks.org> --Sig_/d/iH1ml_/lef=Hv=BN=pcD_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ian Goldberg wrote: > and we're still looking for input on what you'd like > to see in the API. This will definitely be a > non-backwards-compatible API change, so that version should be 4.0.0. That API should *never* return strings, but instead return error codes. We're that pissed of about the current API of libotr that we have thought about dropping OTR support completely in Gajim several times. We lose messages etc. because libotr just gives us an event with HTML included, which we only show as a status in the chat windows, which thus won't be shown if the window is closed and will be lost. And with the current API, we can't fix that. So the next release will be definitely without any OTR support as we can't provide it in a usable way with the current API. We will, however, keep the code in trunk so we can update our code once libotr is fixed and usable, but before, it will never be enabled for a release. --=20 Jonathan --Sig_/d/iH1ml_/lef=Hv=BN=pcD_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIOvieAAoJEMtRg9d5cXHki38P/ix6XDf75kZY/vv1x7CoF9rk IFsz2v+lXr6u5GGFofWOXT/7oXTOlw2dekN1glIAxQNoaCcqnvfVXpw0XCbwze8Y 8x5l76TEoG72ugyTKkrcPdrSemgfB713UKY3z8ZjgXhcTIs0EKrQxM8QNWvinj+o sxImx6gEfm+/SJnzboY/RMZOKPVRE0xzRH73epo2W9ggMbqPHquiBb3ggOFYsa/j YnkozWE90mCmOablhXpstlkrh2w0Fh/EG0FfGrd/wphyP+vs/5GktmdpGku2dSfJ QqX1op5b3Z32PqcXMq4X1jHeSkj6z6XjUQ6aCoxueXy+b7cmimz1Yba2Pw2Krm7E s9AwLhQgq1F3wiLOf6gHOCxpWPNLpxgA4X/1DIGy3FMEYry+r6maPK86suwEhB7d 5oQZ1oOr7iGiiw//K4qXXey0h9s5PEX2kj8XvM4ODubRgTsIQRzKc9yP9yQ1KkQF KfOXF0cqn7W5QZzzA1yzNFKkk4zwBkCLYsiN1UVPmsT/RR6SsU6QZI/j3aSijLkj WeVGlIHQUqxkfDhFYJacg0wX92/6wbvY7mGPy7r+8dN7iUxtmvjdQjmFbS0qcIb9 tih5jtPp1oACHUV1l9xCtfJluBkor/i7fWIeeqtuut++JBpIITCfcMEAY+i11r/Z Ikg9xP2BM9nikDjT+omw =C5xe -----END PGP SIGNATURE----- --Sig_/d/iH1ml_/lef=Hv=BN=pcD_-- From js-otrim@webkeks.org Mon May 26 18:53:53 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 19:53:53 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526195353.4890432d@webkeks.org> --Sig_/NJekXMIUgpg7nfA2Z/CLY2t Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Oh, forgot to mention: We're definitely not going to try to match the strings since that's dangerous. And since every OTR event looks to us the same since we don't match for anything, we can't know for example if it's an unencrypted message or not and thus can't know if we should trigger a message event. This really makes libotr unusable for us. --=20 Jonathan --Sig_/NJekXMIUgpg7nfA2Z/CLY2t Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIOvk1AAoJEMtRg9d5cXHkN8kQALRR+3G9Lt2Qk8XFOZKjgHIp nUZoX9o2LgQHNXLWOJCIORgmuIdRrFwQq7YEbdGJhzHnWekKkfZtsddx78Oo3GpP wnq9wtKhgPZIbJth4KUXHfA9x/wdFggY0577P8DpTWbU3Rzzb9YQqSC1g9fSSklb brsRIXumxul1EEtqswk2s/MVPaGoeSNWLbKa+9bub++4utRmv/oGjgWnqlJIXtXR CRXD7DVxJ1E8CVuFo8OyO0dkP1qNSYyDjxi40kkjUooxR6ewD/sY5CavDKA1t2mu 4eBp4yXhWMdQMnSNKtzpmUxVFcneSutIZTYZilg6/3+fni8g1VeB5qNZC8INidTK VMNSC5CwE7XnjC7LXA7YLlVDs82cCwMH4Zg6YvmtAyTu46j9EGVYhmoPc73OhlET lPSh+//C5abehyxlj09eKHEVYOo0bysAvgi/YA4x+bYoPLZgY5Hmu+jkRYLHSptJ X0UoZK0UIxhqmMWTKrfq716EbHNWhY17v9E/TB907U6hnexIWlfrkKOF6GKannDP wo0Wyl+r/cPaaUO/tkKDJEK7XIwWS7vomKjDAkOQwIl1r/MWaHmTmY2wyBR7C873 ghpL9+o1PVBOteD4TwT54Aj2VB9em6RTPhZ59fC4+npJJdNhR93ymJVqz1VdkUcS JcO8zyqtCDEVOJHekraL =pSOF -----END PGP SIGNATURE----- --Sig_/NJekXMIUgpg7nfA2Z/CLY2t-- From ian@cypherpunks.ca Mon May 26 20:56:18 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 15:56:18 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> On Mon, 26 May 2008 19:51:14 +0200, Jonathan Schleifer wrote: > That API should *never* return strings, but instead return error > codes. Yes, that's one of the main things we'll be changing; the way it works now is completely silly (not to mention i18n-unfriendly). I've signed up someone who will be working on this API redesign. He should be contacting the various IM client implementors soon (either via this list, or by direct email, not sure yet) to start gathering requirements for the v4 API. - Ian From js-otrim@webkeks.org Mon May 26 21:08:19 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Mon, 26 May 2008 22:08:19 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> Message-ID: <20080526220819.1b190450@webkeks.org> --Sig_/mO1XObYTWFlmFJ.VON=yjsb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ian Goldberg wrote: > Yes, that's one of the main things we'll be changing; the way it works > now is completely silly (not to mention i18n-unfriendly). I've signed > up someone who will be working on this API redesign. He should be > contacting the various IM client implementors soon (either via this > list, or by direct email, not sure yet) to start gathering > requirements for the v4 API. Can you give any ETA so we can plan for our next release? We try to release 0.12 ASAP, but it will still take a few months and I'd like to know if there's a possibility we can support OTR in the 0.12 release. It would be enough to know when the biggest part of the API change is done so we can base on that. Doesn't matter if libotr 4.0 gets released after Gajim 0.12 then, at least, we have working support in it then :). --=20 Jonathan --Sig_/mO1XObYTWFlmFJ.VON=yjsb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIOxi8AAoJEMtRg9d5cXHkEucQAIlZjynIhOMBu0E6jJWhU302 k0aq3hzyBtnUQoVojQS/YOW7Xvo4X7a1gRfilKaoDumH4VoiQwuziDGoPuf9rj4T KcUinOFsY1bnhrYAD5f1rX3MbaMxsveZ7JXC4g6983adzVxV4Vc++rSK88yvM4Ps 7MJw+tTpCBVB/m7RU4jj04u25ToSMEy4mU4rd3bLUDUltxpgVGtUP8ETa7xgs7Kj M4jsGch342F1267WIwa2qNS1LDMWMyqrrrE3I5np9U7ATMYlDTC/qInXfxtIWqdy NxKE00XPacrYFKql8a1eG6bGlPps75o70xeezP3b4Hk2S60n0eD/UOTU6ubvckuf yf2I8TZiFp9bHVLNTD9G6xtkRp/SUBsEfRSuhDrb+OmAtoIi6CwYTMvkDR6l0o6T FZHfeUaNegXRJfroB4vSX6jkTZH6YoPIG+lQdsnzLdGMrS8q1Y1Sm1Lp9pRQL9Qa X/VBxPfl+YdlS3sJzXhQPYNUpuHaeqT6dxnZTCdvDs656PMOC3h4cQ1MnXoQXh2s FCTq2JK01A+ZL9UMpPhmGTauGnzZFZPjNVRaHPqE8tG0EeawFUYq9l98POL/RbJq a6Fzt88FfwDAP59d9uzLJy/pwN4bSf9WVqzAErRvithtYQ2gFQ+KM/xiCs+Ei4J7 CE5h10RGO6Vj+IFGyTw9 =NLwR -----END PGP SIGNATURE----- --Sig_/mO1XObYTWFlmFJ.VON=yjsb-- From ian@cypherpunks.ca Mon May 26 22:59:40 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Mon, 26 May 2008 17:59:40 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526220819.1b190450@webkeks.org> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> <20080526220819.1b190450@webkeks.org> Message-ID: <20080526215940.GF30190@yoink.cs.uwaterloo.ca> On Mon, May 26, 2008 at 10:08:19PM +0200, Jonathan Schleifer wrote: > Ian Goldberg wrote: > > > Yes, that's one of the main things we'll be changing; the way it works > > now is completely silly (not to mention i18n-unfriendly). I've signed > > up someone who will be working on this API redesign. He should be > > contacting the various IM client implementors soon (either via this > > list, or by direct email, not sure yet) to start gathering > > requirements for the v4 API. > > Can you give any ETA so we can plan for our next release? We try to > release 0.12 ASAP, but it will still take a few months and I'd like to > know if there's a possibility we can support OTR in the 0.12 release. > It would be enough to know when the biggest part of the API change is > done so we can base on that. Doesn't matter if libotr 4.0 gets released > after Gajim 0.12 then, at least, we have working support in it then :). Assuming Willy gets good feedback from the IM developers pretty quickly about what they (you) want in the API, we hope to have the requirements spec'd out and the API designed by August. Depending on the scope of the changes, the actual implementation of the new API may take longer. - Ian From ian@cypherpunks.ca Tue May 27 14:52:41 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 09:52:41 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> Message-ID: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> On Mon, May 26, 2008 at 08:20:45AM -0400, Ian Goldberg wrote: > Funny you should ask. ;-) > > We're just in the final stages of putting a 3.2.0 preview out. The > main user interface changes include moving the OTR button to the menu > bar (though the button remains an option), support for multiple > buddies merged into a single contact / conversation window, improved > authentication user interface (based on the user study we did, to appear > in SOUPS 2008), and the icons being changed to Tango-based ones. > > My goal is to get it all into a state where it can be put in the public > CVS on sourceforge sometime this week. Then we'll wait a bit for some > feedback, and for the various translators to supply translations for the > new UI strings, and we'll send it out. The current code is now up on the sourceforge cvs. http://sourceforge.net/cvs/?group_id=128860 Translators: Can you update your translations file to include the new text from the new version? See po/README for super-brief instructions, or email me if you're having trouble. Here are the languages (and most recent translators) I currently know about (and are checked in): Arabic: Ahmad Gharbeia أحمد غربية German: Thorsten Mühlfelder Spanish: Enrique Martinez Cardenas French: Joel Reardon Dutch: Paul Wouters Russian: Sergei Smirnov Slovak: Milan Plzik If you think you've sent me a translation not listed above, send it again, since I must have misplaced it. (But be sure to update it for 3.2.0 first). Others: Please try out the new code and tell me if something goes horribly wrong (doesn't compile on your platform, doesn't work in some weird case, etc.). My aim is to release 3.2.0 next week or thereabouts. The documentation in the README file, as well as the web-based documentation, still needs to be updated. [If someone wants to help with that, let me know that as well.] Thanks, - Ian The new part of the NEWS file: 28 May 2008: - The functionality of the OTR button has now moved to a menu. There's an "OTR" menu, as well as an icon showing the current OTR state of each active conversation in the window. - New OTR icons from - OTR icons show up inline in the conversation window when the OTR status changes. - Buddy authentication has been revamped, based on the user study published in SOUPS 2008. The default is now to choose a question and an answer only you and the buddy should know. The question is displayed to the buddy, who is prompted for the answer. The "shared secret" and "fingerprint" authentication methods are still available. - Translations for Arabic, German, Russian From fnord@pentabarf.de Tue May 27 15:38:25 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Tue, 27 May 2008 16:38:25 +0200 Subject: Backwards compatability (was: Re: [OTR-dev] Pidgin plugin development and GUI look) In-Reply-To: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> Message-ID: <1211899105.6268.7.camel@hegg> --=-bXaJQMnwNkFFzNRq6eFX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Others: >=20 > Please try out the new code and tell me if something goes horribly > wrong (doesn't compile on your platform, doesn't work in some > weird > case, etc.). >=20 >=20 Hi Ian, I've not yet tested your code but had a look at the handling of the SMP1Q tlv. If I read the source code in the svn correctly, does this mean that a 3.1.0 user who receives an SMP1Q TLV sees nothing, as he doesn't know it yet? If so, I think it would be more sensible to just re-use the old SMP1 TLV and add the data section question there, which would result in the same thing for two 3.2.0 users, but 3.1.0 would not see the question (but they would still see the initial SMP request!). Thanks, Kjell --=-bXaJQMnwNkFFzNRq6eFX Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIPBzhNjvKGrx0tZgRAhQdAJ9wb2DvW54yh7JLQzmqB53F98jgxwCeIHqr rYezDNusuESNlKH0mjVKhn0= =6rXw -----END PGP SIGNATURE----- --=-bXaJQMnwNkFFzNRq6eFX-- From js-otrim@webkeks.org Tue May 27 15:42:33 2008 From: js-otrim@webkeks.org (Jonathan Schleifer) Date: Tue, 27 May 2008 16:42:33 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080526215940.GF30190@yoink.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080526172808.GJ1433@thunk.cs.uwaterloo.ca> <20080526195618.GQ1433@thunk.cs.uwaterloo.ca> <20080526220819.1b190450@webkeks.org> <20080526215940.GF30190@yoink.cs.uwaterloo.ca> Message-ID: <20080527164233.76df34c6@webkeks.org> --Sig_/iukMlrhwdqb68CdZySFq+UY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ok, thanks for the information. We will plan a 0.12 release without OTR then, but keep it in trunk so it's easy to upgrade to the new API once the new libotr is released. --=20 Jonathan --Sig_/iukMlrhwdqb68CdZySFq+UY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- iQIcBAEBAwAGBQJIPB3cAAoJEMtRg9d5cXHkYLIQAIa4j6mQoFLdTDfkm0I8z8Bc xxFCOwR8I/lHcvShR2AhdGdd9N20zAPgdTNvcV0hjg9iXvaR5mhBfwrWohJe4yUq IR/X8dU6uOtWKAIRsXUkkO3YJcSZDFNoCSrQbCa0cuLg5cjMSRxP4/rXzhpqQVKB o6FID4XNwBDw6njPK8UX5eLI9if5LwvKamonoQQUIlPl40Nl6fYCDzrg275v2kOj tBCvpEl51C5QlDBCPNAlCZoqORf6ESkcu4IY9hkteC8MpVQvoNVw8fdk3hYCQM5Z I8lBEAbz/leOpHpKm5HYWMblnGmIdcwCfUo4R+qzThE6UGVUNfEHXoXU/AjbSwbu 7GNLD7jjkYwCLOPGMIJ0BafZ5OBlGbD2BdfjTkc/Ry0kmS4uLrj61hZ5mYczsQ2m bvClGWGTYgyPMHo/nrLPdNKbzs3+j+WNwkYp/OBILCkX1tfjlm6sn+0uVQeiHWVm B3uGeYx2QfMlU7LRcxrSqrHSTa3oM+85xkeknXzHR7JFBw5FQMjKUkUtt1Ks8GnA cu7zqwcwgQZCE59E7nUBEbKdoK0YTpgpv4V9h1MrBVzMOguGz3R8su3kgXAxmE+l 3iPPz6lsS5HNvnE7RXZCavcMOj8Y0qfP6cS2TdfnP7jw0tco92mMsi4NxF458MoH CVjzSJlZi0kY3ZW2Yuku =ldJG -----END PGP SIGNATURE----- --Sig_/iukMlrhwdqb68CdZySFq+UY-- From ian@cypherpunks.ca Tue May 27 15:53:54 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 10:53:54 -0400 Subject: [OTR-dev] Re: Backwards compatability In-Reply-To: <1211899105.6268.7.camel@hegg> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <1211899105.6268.7.camel@hegg> Message-ID: <20080527145354.GD6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 04:38:25PM +0200, Kjell Braden wrote: > > Others: > > > > Please try out the new code and tell me if something goes horribly > > wrong (doesn't compile on your platform, doesn't work in some > > weird > > case, etc.). > > > > > Hi Ian, > > I've not yet tested your code but had a look at the handling of the > SMP1Q tlv. If I read the source code in the svn correctly, does this > mean that a 3.1.0 user who receives an SMP1Q TLV sees nothing, as he > doesn't know it yet? If so, I think it would be more sensible to just > re-use the old SMP1 TLV and add the data section question there, which > would result in the same thing for two 3.2.0 users, but 3.1.0 would not > see the question (but they would still see the initial SMP request!). SMP1Q has slightly different semantics from SMP1, so we intentionally made it a different TLV type. If you pose a question to your buddy Bob (who answers it correctly), you will authenticate Bob, but Bob will not automatically authenticate you. If Bob is running 3.1.0, which assumes a preshared secret (which does indeed imply mutual authentication), we don't want his code to "fall back" to authenticating you when it shouldn't, and also, he won't see the question, which will be a subtler problem more likely to be overlooked than the authentication window not coming up at all. - Ian From hcat@gmx.net Tue May 27 16:58:05 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Tue, 27 May 2008 17:58:05 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527144401.GC6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527155805.152350@gmx.net> > > configure.ac:30: required file `libotr.pc.in' not found > > Oops; fixed. ;-) Thanks, I'm able to compile libotr now. However the gaim/pidgin plugin is still missing a file: config.status: error: cannot find input file: po/Makefile.in.in -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From ian@cypherpunks.ca Tue May 27 17:12:49 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 12:12:49 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527155805.152350@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> Message-ID: <20080527161249.GH6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 05:58:05PM +0200, hcat@gmx.net wrote: > > > > configure.ac:30: required file `libotr.pc.in' not found > > > > Oops; fixed. ;-) > > Thanks, I'm able to compile libotr now. However the gaim/pidgin plugin is still missing a file: > > config.status: error: cannot find input file: po/Makefile.in.in You forgot to run "intltoolize --force --copy" before autoreconf. - Ian From fnord@pentabarf.de Tue May 27 17:46:06 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Tue, 27 May 2008 18:46:06 +0200 Subject: [OTR-dev] Re: Backwards compatability In-Reply-To: <20080527145354.GD6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <1211899105.6268.7.camel@hegg> <20080527145354.GD6988@thunk.cs.uwaterloo.ca> Message-ID: <1211906766.6268.13.camel@hegg> --=-iZJf60Y8YWp9m93MGXfQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >=20 > SMP1Q has slightly different semantics from SMP1, so we intentionally > made it a different TLV type. If you pose a question to your buddy Bob > (who answers it correctly), you will authenticate Bob, but Bob will not > automatically authenticate you. If Bob is running 3.1.0, which assumes > a preshared secret (which does indeed imply mutual authentication), we > don't want his code to "fall back" to authenticating you when it > shouldn't, and also, he won't see the question, which will be a subtler > problem more likely to be overlooked than the authentication window not > coming up at all. >=20 > - Ian I see, I missed the part that the authentication will not be mutual in SMP1Q, so your way makes perfectly sense now. --=-iZJf60Y8YWp9m93MGXfQ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIPDrONjvKGrx0tZgRAmcfAKCvXN36h0nMBSdpE/+mqC9wnGcAAQCfVEfV /7fo/XYRmutTct8QLKlfx8E= =+tnu -----END PGP SIGNATURE----- --=-iZJf60Y8YWp9m93MGXfQ-- From hcat@gmx.net Tue May 27 18:09:25 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Tue, 27 May 2008 19:09:25 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527161249.GH6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527170925.216970@gmx.net> > You forgot to run "intltoolize --force --copy" before autoreconf. > Right. Thanks, works now. I tested the pidgin plugin for a while, it seems to work well. I have however a few notes regarding the UI: 1.) Auth dialog: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-auth.png A) The space seems to be one line to big. B) The nested expanders look bad. IMHO one would be enough (showing 2 paragraphs of text) or even better: a help button which would open a help webpage. C) Window title should be "Authenticate _B_uddy" (not _b_uddy) as per HIG D) Why "other"? I don't see any other options, so just "Authentication Options" would be enough IMHO E) The smiley is nice but it does not really serve a propose. Why not use the GTK stock icon gtk-dialog-authentication? 2.) Chat window: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-chat.png A) The background of the user icon should be transparent, not white. It looks a bit broken this way. B) Why is the chat partner's account listed here? Clicking it does nothing... IMHO this is confusing and should be removed... or does it serve a purpose I don't get ATM? C) This seems to show the status again (duplication, as it is also shown in the menu header). Clicking it opens the webpage, I wonder if a "What is OTR?" or "What does this all mean?" menu entry would not be better. Generally I like how the icon is integrated now, but I don't like the way the same menu opens when pressing "OTR" or the icon behind. It should be possible to combine both to only one menu (with text and icon). Perhaps also add the status as a text there? I have done a mockup for this: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-1.png Also, I have the feeling that having the OTR indicator closer to the text box would be better. The same menu could be integrated into the toolbar (as a 3rd option?): http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-2.png Cheers, -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx From xx.0mmg@gmail.com Tue May 27 20:21:48 2008 From: xx.0mmg@gmail.com (Patrik Willard) Date: Tue, 27 May 2008 21:21:48 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527170925.216970@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> Message-ID: <483C5F4C.6050808@gmail.com> hcat@gmx.net wrote: > Also, I have the feeling that having the OTR indicator closer to the text box would be better. The same menu could be integrated into the toolbar (as a 3rd option?): http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-2.png > > Cheers, > -Michael A friend of mine experimented with just this, and the result was pretty good. He wrote a blog-post about it ( http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/ ) Cheers, -Patrik From ian@cypherpunks.ca Tue May 27 20:34:17 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 15:34:17 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527170925.216970@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> Message-ID: <20080527193417.GI6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 07:09:25PM +0200, hcat@gmx.net wrote: > > You forgot to run "intltoolize --force --copy" before autoreconf. > > > > Right. Thanks, works now. > > I tested the pidgin plugin for a while, it seems to work well. I have however a few notes regarding the UI: > > 1.) Auth dialog: > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-auth.png > A) The space seems to be one line to big. There's no explicit whitespace being added; I'm not sure where it's coming from. Any ideas? The stuff underneath is in a notebook page; maybe that's it? > B) The nested expanders look bad. IMHO one would be enough (showing 2 > paragraphs of text) or even better: a help button which would open a > help webpage. I wanted at least some help text that doesn't entail going to the web. You're suggesting just having "What's this?" open the HTML widget directly, with the current first-level text as its first paragraph? > C) Window title should be "Authenticate _B_uddy" (not _b_uddy) as per > HIG Fair enough. Fixed. > D) Why "other"? I don't see any other options, so just "Authentication > Options" would be enough IMHO Also fixed. > E) The smiley is nice but it does not really serve a propose. Why not > use the GTK stock icon gtk-dialog-authentication? It's the stock INFO icon. The stock authentication icon is a lock, and a lock just really doesn't convey what's going on here, in my opinion. > 2.) Chat window: > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-chat.png > A) The background of the user icon should be transparent, not white. > It looks a bit broken this way. Hmm. The original pngs *do* have a transparent background. The background in your image isn't in fact white; it's the background colour of the menu bar. Might this be a bug in how GTK handles menus labelled by icons (an admittedly unusual case)? > B) Why is the chat partner's account listed here? Clicking it does > nothing... IMHO this is confusing and should be removed... or does it > serve a purpose I don't get ATM? Ah, it's because you can group buddies into contacts, and all buddies from a single contact show up in the same conversation window. So we need some way to show that there are multiple conversations going on at the same time, and they may have different OTR statuses. Try picking different things from your "Send To" menu; you'll see the single OTR menu (representing the "current" conversation), but multiple icons (representing all conversations, labelled by who you're talking to). Indeed, it's unfortunate that clicking it does nothing. If anyone knows a way to make that menu item not highlight at all, I'd love to do that. [But making it inactive causes it to grey out so much that I found it unreadable.] > C) This seems to show the status again (duplication, as it is also > shown in the menu header). Except it's shown in the menu header just as an icon; the added text may be useful for people new to OTR. > Clicking it opens the webpage, I wonder if a "What is OTR?" or "What > does this all mean?" menu entry would not be better. Good call. Fixed. > Generally I like how the icon is integrated now, but I don't like the > way the same menu opens when pressing "OTR" or the icon behind. It > should be possible to combine both to only one menu (with text and > icon). Perhaps also add the status as a text there? I have done a > mockup for this: > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-1.png As above, this is because there can be multiple icons for multiple conversations in the same window. > Also, I have the feeling that having the OTR indicator closer to the > text box would be better. The same menu could be integrated into the > toolbar (as a 3rd option?): > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-2.png We left the button available for people who want something like this. Do you think this is vitally important? (Do most people leave that toolbar visible at all?) Thanks so much for your feedback! I'm checking in the above changes now. - Ian From hcat@gmx.net Tue May 27 20:34:18 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Tue, 27 May 2008 21:34:18 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <483C5F4C.6050808@gmail.com> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> Message-ID: <20080527193418.56680@gmx.net> > A friend of mine experimented with just this, and the result was pretty > good. > He wrote a blog-post about it ( > http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/ ) I really like that, even better to put it aligned to the right edge of the toolbar instead of as the next "button" on the toolbar. I also feel that having the colored text works very well and is a lot better than even the nicer icons we have right now. -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx From ian@cypherpunks.ca Tue May 27 20:44:58 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 15:44:58 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527193418.56680@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> Message-ID: <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 09:34:18PM +0200, hcat@gmx.net wrote: > > A friend of mine experimented with just this, and the result was pretty > > good. > > He wrote a blog-post about it ( > > http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/ ) > > I really like that, even better to put it aligned to the right edge of > the toolbar instead of as the next "button" on the toolbar. I also > feel that having the colored text works very well and is a lot better > than even the nicer icons we have right now. One of the issues identified in the user study is that people couldn't figure out how to get to the "Authenticate buddy" menu item. With the button, you needed to right-click on the button to bring up the context menu, which stymied a number of people. They suggested to move it to a menu (for which (left-)clicking is the obvious way to pull down a menu), so that's what we did. We'd also have to think about how to handle the multiple-conversations-in-one-window case. - Ian From hcat@gmx.net Tue May 27 21:02:48 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Tue, 27 May 2008 22:02:48 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527200248.56650@gmx.net> [sending again to the list... webmail sucks for mailing lists :(] > One of the issues identified in the user study is that people couldn't > figure out how to get to the "Authenticate buddy" menu item. With the > button, you needed to right-click on the button to bring up the context > menu, which stymied a number of people. They suggested to move it to a > menu (for which (left-)clicking is the obvious way to pull down a menu), > so that's what we did. Why the right click? (Left-)Clicking the "OTR: " like Patrik linked would just display a small menu just like the formatting and insert "toolbar buttons" do. Well, the OTR menu item could even stay in the menu bar (minus the icon, which looks a bit alien there anyway) and the "OTR: " could just display the status down in the toolbar. From fnord@pentabarf.de Tue May 27 21:11:22 2008 From: fnord@pentabarf.de (Kjell Braden) Date: Tue, 27 May 2008 22:11:22 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527200248.56650@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> Message-ID: <1211919082.7542.2.camel@hegg> --=-NF7P3Cs/UVi5FA3Wg2bd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Dienstag, den 27.05.2008, 22:02 +0200 schrieb hcat@gmx.net: > [sending again to the list... webmail sucks for mailing lists :(] >=20 > > One of the issues identified in the user study is that people > couldn't > > figure out how to get to the "Authenticate buddy" menu item. With > the > > button, you needed to right-click on the button to bring up the > context > > menu, which stymied a number of people. They suggested to move it > to a > > menu (for which (left-)clicking is the obvious way to pull down a > menu), > > so that's what we did. >=20 > Why the right click? (Left-)Clicking the "OTR: " like Patrik > linked would just display a small menu just like the formatting and > insert "toolbar buttons" do. > Well, the OTR menu item could even stay in the menu bar (minus the > icon, which looks a bit alien there anyway) and the "OTR: " > could just display the status down in the toolbar. I'd love this toolbar approach. Not sure if that's what hcat just suggested, but I'd suggest using the "OTR: " thing in the toolbar as a menu, with the contents from what is in the menu on the top. --=-NF7P3Cs/UVi5FA3Wg2bd Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBIPGrqNjvKGrx0tZgRApihAJ49JvQ/bzEa/G3hS7FmMELgoGeksACgrpD+ e7Zpjt9Fw0tx0q6ucPXkJt4= =r9zF -----END PGP SIGNATURE----- --=-NF7P3Cs/UVi5FA3Wg2bd-- From ian@cypherpunks.ca Tue May 27 21:13:56 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:13:56 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527200248.56650@gmx.net> References: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> Message-ID: <20080527201356.GO6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 10:01:08PM +0200, hcat@gmx.net wrote: > > One of the issues identified in the user study is that people > > couldn't figure out how to get to the "Authenticate buddy" menu > > item. With the button, you needed to right-click on the button to > > bring up the context menu, which stymied a number of people. They > > suggested to move it to a menu (for which (left-)clicking is the > > obvious way to pull down a menu), so that's what we did. > > Why the right click? (Left-)Clicking the "OTR: " like Patrik > linked would just display a small menu just like the formatting and > insert "toolbar buttons" do. Yes, it could, but that's not what the linked-to patch does, is all I'm saying. > Well, the OTR menu item could even stay in the menu bar (minus the > icon, which looks a bit alien there anyway) and the "OTR: " > could just display the status down in the toolbar. How would you show multiple conversations? If we could figure this out, someone could try to add it at least as an option. - Ian From hcat@gmx.net Tue May 27 21:14:38 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Tue, 27 May 2008 22:14:38 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527193417.GI6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527201438.56660@gmx.net> > I wanted at least some help text that doesn't entail going to the web. > You're suggesting just having "What's this?" open the HTML widget > directly, with the current first-level text as its first paragraph? I didn't realize that it embeds a HTML widget. I just don't see the need for two expanders here, if a user really wants some help text he/she will most likely open the second expander as well, just to see what's written there. > It's the stock INFO icon. The stock authentication icon is a lock, and > a lock just really doesn't convey what's going on here, in my opinion. Ah... yeah that's theme dependent. GTK uses a lock, GNOME icon theme uses some kind of a keyring. "Info" hmm... > Hmm. The original pngs *do* have a transparent background. The > background in your image isn't in fact white; it's the background colour > of the menu bar. Might this be a bug in how GTK handles menus labelled > by icons (an admittedly unusual case)? I just ran a few more tests with different GTK themes and engines and it looks like most are affected. Only the very basic ones display "correctly"... Not sure if this is a GTK or engine bug though. > Ah, it's because you can group buddies into contacts, and all buddies > from a single contact show up in the same conversation window. So we > need some way to show that there are multiple conversations going on at > the same time, and they may have different OTR statuses. Try picking > different things from your "Send To" menu; you'll see the single OTR > menu (representing the "current" conversation), but multiple icons > (representing all conversations, labelled by who you're talking to). > Indeed, it's unfortunate that clicking it does nothing. If anyone knows > a way to make that menu item not highlight at all, I'd love to do that. > [But making it inactive causes it to grey out so much that I found it > unreadable.] I understand this now, but I take it for a bad sign that I was not able to get the meaning myself. But indeed not easy to solve... > We left the button available for people who want something like this. > Do you think this is vitally important? (Do most people leave that > toolbar visible at all?) I didn't know the toolbar can be disabled... IMHO the old button takes a way too much space. Integrating the OTR status into the toolbar (like http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/) doesn't change the pidgin UI too much but still shows the OTR status very nicely. Cheers, -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx From ian@cypherpunks.ca Tue May 27 21:24:11 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:24:11 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527201438.56660@gmx.net> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> Message-ID: <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 10:14:38PM +0200, hcat@gmx.net wrote: > > I wanted at least some help text that doesn't entail going to the web. > > You're suggesting just having "What's this?" open the HTML widget > > directly, with the current first-level text as its first paragraph? > > I didn't realize that it embeds a HTML widget. I just don't see the > need for two expanders here, if a user really wants some help text > he/she will most likely open the second expander as well, just to see > what's written there. I can see about making this change. Not today, though. > I just ran a few more tests with different GTK themes and engines and > it looks like most are affected. Only the very basic ones display > "correctly"... Not sure if this is a GTK or engine bug though. In any event, I'm pretty sure it's nothing we can fix. > I understand this now, but I take it for a bad sign that I was not > able to get the meaning myself. But indeed not easy to solve... But even if you don't understand why it's there, it's at worst a bit redundant. > > We left the button available for people who want something like this. > > Do you think this is vitally important? (Do most people leave that > > toolbar visible at all?) > I didn't know the toolbar can be disabled... IMHO the old button takes > a way too much space. Integrating the OTR status into the toolbar > (like http://blog.pesa.se/2007/09/25/goodbye-big-bloated-otr-button/) > doesn't change the pidgin UI too much but still shows the OTR status > very nicely. Yes, I totally agree. We just need (a) to find a way to do it that still allows for multiple conversations, and (b) someone to actually do it once we figure out what ought to be done. - Ian From hcat@gmx.net Tue May 27 21:35:41 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Tue, 27 May 2008 22:35:41 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527201356.GO6988@thunk.cs.uwaterloo.ca> References: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527203541.56660@gmx.net> Wow this is one fast mailing list ;) > How would you show multiple conversations? If we could figure this out, > someone could try to add it at least as an option. Btw are we talking about "multiple conversations" like a) having multiple conversations to multiple persons in the same window using tabs or b) chatting with a meta contact using more than one account at a time (e.g. XMPP and ICQ)? For a), showing the status icon in the menu bar is a bit confusing IMHO. The menu is relative to the selected tab, but the user could also interpret it as relative to all of the tabs. For b) this would be the same in the toolbar as what is now in the menu bar. Without clicking, "OTR: " would be relative to what you currently use. I'm not sure about this but if you write to someone using XMPP and he replies using ICQ, will your reply go out using ICQ? If this is the case, the stauts should change to the new active protocol. The popup would have status information for all accounts, similar to what is currently in the menu (which I think can still be improved to make it more obvious). Cheers, -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx From ian@cypherpunks.ca Tue May 27 21:50:39 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:50:39 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> References: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527205039.GR6988@thunk.cs.uwaterloo.ca> --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 27, 2008 at 04:24:11PM -0400, Ian Goldberg wrote: > On Tue, May 27, 2008 at 10:14:38PM +0200, hcat@gmx.net wrote: > > > I wanted at least some help text that doesn't entail going to the web. > > > You're suggesting just having "What's this?" open the HTML widget > > > directly, with the current first-level text as its first paragraph? > > > > I didn't realize that it embeds a HTML widget. I just don't see the > > need for two expanders here, if a user really wants some help text > > he/she will most likely open the second expander as well, just to see > > what's written there. > > I can see about making this change. Not today, though. Maybe I'm wrong. I'm not going to check this in right now, but apply this patch and tell me what you think. - Ian --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="whatsthis.diff" Index: gtk-dialog.c =================================================================== RCS file: /cvsroot/otr/gaim-otr/gtk-dialog.c,v retrieving revision 1.18 diff -u -r1.18 gtk-dialog.c --- gtk-dialog.c 27 May 2008 19:54:06 -0000 1.18 +++ gtk-dialog.c 27 May 2008 20:48:05 -0000 @@ -423,33 +423,21 @@ const char *moremarkup) { GtkWidget *expander; - GtkWidget *ebox; - GtkWidget *whatsthis; - GtkWidget *more; - GtkWidget *frame; GtkWidget *scrl; GtkWidget *imh; GdkFont *font; + char *alltext; expander = gtk_expander_new_with_mnemonic(_("_What's this?")); gtk_box_pack_start(GTK_BOX(vbox), expander, FALSE, FALSE, 0); - frame = gtk_frame_new(NULL); - gtk_container_add(GTK_CONTAINER(expander), frame); - ebox = gtk_vbox_new(FALSE, 10); - gtk_container_add(GTK_CONTAINER(frame), ebox); - whatsthis = gtk_label_new(NULL); - gtk_label_set_line_wrap(GTK_LABEL(whatsthis), TRUE); - gtk_label_set_markup(GTK_LABEL(whatsthis), whatsthismarkup); - - gtk_box_pack_start(GTK_BOX(ebox), whatsthis, FALSE, FALSE, 0); - more = gtk_expander_new_with_mnemonic(_("_More...")); - gtk_box_pack_start(GTK_BOX(ebox), more, FALSE, FALSE, 0); scrl = gtk_scrolled_window_new(NULL, NULL); - gtk_container_add(GTK_CONTAINER(more), scrl); + gtk_container_add(GTK_CONTAINER(expander), scrl); imh = gtk_imhtml_new(NULL, NULL); pidgin_setup_imhtml(imh); - gtk_imhtml_append_text(GTK_IMHTML(imh), moremarkup, GTK_IMHTML_NO_SCROLL); + alltext = g_strdup_printf("%s\n\n%s", whatsthismarkup, moremarkup); + gtk_imhtml_append_text(GTK_IMHTML(imh), alltext, GTK_IMHTML_NO_SCROLL); + g_free(alltext); gtk_container_add(GTK_CONTAINER(scrl), imh); gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(scrl), @@ -459,7 +447,7 @@ * is (a) complicated, and (b) not fully supported by older versions * of libpango, which some people may have. */ font = gtk_style_get_font(imh->style); - gtk_widget_set_size_request(scrl, -1, 6 * (font->ascent + font->descent)); + gtk_widget_set_size_request(scrl, -1, 10 * (font->ascent + font->descent)); } --UugvWAfsgieZRqgk-- From ian@cypherpunks.ca Tue May 27 21:53:41 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 16:53:41 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527203541.56660@gmx.net> References: <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> Message-ID: <20080527205341.GS6988@thunk.cs.uwaterloo.ca> On Tue, May 27, 2008 at 10:35:41PM +0200, hcat@gmx.net wrote: > Wow this is one fast mailing list ;) > > > How would you show multiple conversations? If we could figure this out, > > someone could try to add it at least as an option. > > Btw are we talking about "multiple conversations" like a) having > multiple conversations to multiple persons in the same window using > tabs or b) chatting with a meta contact using more than one account at > a time (e.g. XMPP and ICQ)? We're talking about b. When the user switches tabs, the status in the menu bar changes appropriately. > For a), showing the status icon in the menu bar is a bit confusing > IMHO. The menu is relative to the selected tab, but the user could > also interpret it as relative to all of the tabs. It is indeed relative to the selected tab. > For b) this would be the same in the toolbar as what is now in the > menu bar. Without clicking, "OTR: " would be relative to what > you currently use. I'm not sure about this but if you write to someone > using XMPP and he replies using ICQ, will your reply go out using ICQ? > If this is the case, the stauts should change to the new active > protocol. The popup would have status information for all accounts, > similar to what is currently in the menu (which I think can still be > improved to make it more obvious). But we'd like it obvious at a glance that there are multiple conversations of differing security happening at once. Try it out with the currently checked-in code to see how it works now. - Ian From hcat@gmx.net Tue May 27 22:46:16 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Tue, 27 May 2008 23:46:16 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527205039.GR6988@thunk.cs.uwaterloo.ca> References: <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527214616.167040@gmx.net> > Maybe I'm wrong. I'm not going to check this in right now, but apply > this patch and tell me what you think. I think it looks cleaner than before. I think I would also move the expander to the left (aligned with the other expander. -Michael -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx From hcat@gmx.net Tue May 27 23:41:08 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Wed, 28 May 2008 00:41:08 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527205341.GS6988@thunk.cs.uwaterloo.ca> References: <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> <20080527205341.GS6988@thunk.cs.uwaterloo.ca> Message-ID: <20080527224108.167060@gmx.net> To the list... > But we'd like it obvious at a glance that there are multiple > conversations of differing security happening at once. Try it out with > the currently checked-in code to see how it works now. Another quick mockup from me that tries to address the multi conversations problem: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-3.png This is using the details bar to display all active accounts and their OTR status. Normally they are flat tiles, hovering them would give the same button feedback as hovering the toolbar does, pressing either (left) would pop up a menu similar to the current menu popup (shown at the bottom of the mockup). Alternatively the tiles could show the OTR status icon instead of the protocol icon. Either way, the currently inactive icon(s) should be displayed with about 30% transparency (mockup uses 50% but this is not enough I think). Grayscaling is not a good idea as it would look disabled and for example the "not private" icon is already gray. IMHO this would be another nice option with the advantage that the different account states belong to the active tab. Still having a simple "OTR: " or "OTR: " or "OTR: " on the right side of the toolbar would be nice because: a) you mostly care about what you will get on the next send. If you type and look at the text box, you will notice a "not private" icon or red text there, but probably not notice those when they are only displyed at the top of the window. b) I don't think multi-account chats are *that* common. I have quite a few meta contacts with people who have 2-5 different accounts, but it rarely happens that accounts get changed during conversations. Cheers, -Michael -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger From ian@cypherpunks.ca Wed May 28 01:19:01 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 27 May 2008 20:19:01 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527214616.167040@gmx.net> References: <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> Message-ID: <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> On Tue, May 27, 2008 at 11:46:16PM +0200, hcat@gmx.net wrote: > > Maybe I'm wrong. I'm not going to check this in right now, but apply > > this patch and tell me what you think. > > I think it looks cleaner than before. I think I would also move the > expander to the left (aligned with the other expander. Except that that expander is part of the notebook pane; there are separate instructions for each authentication option. - Ian From hcat@gmx.net Wed May 28 11:25:11 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Wed, 28 May 2008 12:25:11 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> References: <20080527142454.325680@gmx.net> <20080527144401.GC6988@thunk.cs.uwaterloo.ca> <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> Message-ID: <20080528102511.22440@gmx.net> > Except that that expander is part of the notebook pane; > there are separate instructions for each authentication > option. Another thing which I did not notice right away! Ok, let's restart this. The main problem of the dialog as I see it is that the workflow is backward or upside-down :) Dialogs should work from top to bottom. In this case, if you want to change the auth method, you have to use the last control first, which then changes the (hidden) help text and the input fields above that. The last thing you actually do is input secret and/or question at the top of the dialog. I have redesigned the whole dialog to work around these problems: http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-4.png - The "Authenticate " line stays but "again" appended to show that you already authenticated the user once (instead of the string that was shown below... is this enough?) - Below the line the first part of the help text is drawn. This is short and catchy and guides the user through the dialog, so I don't need the use of hiding it first. Also, this place is definitely better than below the input fields. - Next I put the auth method selection, as a combo box instead of a radio. IMHO this is easier to the eyes and takes away less space. Again, no real need to hide this by default IMHO. - The next parts will change if the combo selection changes. - Following is the second part of the help text. This is drawn using a slightly smaller italic font. We do the same in the preferences menu of Banshee btw. - Last, we have the actual input boxes for the secrets/questions etc. - I also changed the "OK" button to read "Send Request", as the HIG discourages the use of generic button labels like "OK"; instead the button should always say what it does. How do you like this? I have to say I'm really happy with this design. Cheers, -Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From ian@cypherpunks.ca Wed May 28 13:10:41 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 08:10:41 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528102511.22440@gmx.net> References: <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> Message-ID: <20080528121041.GA24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 12:25:11PM +0200, hcat@gmx.net wrote: > > Except that that expander is part of the notebook pane; > > there are separate instructions for each authentication > > option. > > Another thing which I did not notice right away! > > Ok, let's restart this. The main problem of the dialog as I see it is that the workflow is backward or upside-down :) > > Dialogs should work from top to bottom. In this case, if you want to change the auth method, you have to use the last control first, which then changes the (hidden) help text and the input fields above that. The last thing you actually do is input secret and/or question at the top of the dialog. > > I have redesigned the whole dialog to work around these problems: > > http://userp.uni-koblenz.de/~monreal/tmp/otr/otr-mock-4.png I like the concept, but have a few questions about the details. > - The "Authenticate " line stays but "again" appended to show > that you already authenticated the user once (instead of the string > that was shown below... is this enough?) I don't think it's enough. The appearance of "again" is *way* too subtle, I think. > - Below the line the first part of the help text is drawn. This is > short and catchy and guides the user through the dialog, so I don't > need the use of hiding it first. Also, this place is definitely better > than below the input fields. The rest of the help text is now entirely absent, including the link to the web-based help pages. > - Next I put the auth method selection, as a combo box instead of a > radio. IMHO this is easier to the eyes and takes away less space. > Again, no real need to hide this by default IMHO. I'm just worried about putting so much text into a combo box. Especially in some other languages, this would make the box really, really wide, no? > - The next parts will change if the combo selection changes. > > - Following is the second part of the help text. This is drawn using a slightly smaller italic font. We do the same in the preferences menu of Banshee btw. > > - Last, we have the actual input boxes for the secrets/questions etc. > > - I also changed the "OK" button to read "Send Request", as the HIG > discourages the use of generic button labels like "OK"; instead the > button should always say what it does. I don't think "Send request" is the right thing to say here, though. The word "request" appears nowhere else in the dialog. - Ian From ian@cypherpunks.ca Wed May 28 13:59:18 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 08:59:18 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527224108.167060@gmx.net> References: <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> <20080527205341.GS6988@thunk.cs.uwaterloo.ca> <20080527224108.167060@gmx.net> Message-ID: <20080528125918.GB24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 12:41:08AM +0200, hcat@gmx.net wrote: > Still having a simple "OTR: " or "OTR: " or > "OTR: " on the right side of the toolbar > would be nice because: > > a) you mostly care about what you will get on the next send. If you > type and look at the text box, you will notice a "not private" icon or > red text there, but probably not notice those when they are only > displyed at the top of the window. > b) I don't think multi-account chats are *that* common. I have quite a > few meta contacts with people who have 2-5 different accounts, but it > rarely happens that accounts get changed during conversations. I've checked in a change to move the OTR button to the toolbar (but keeping the menus). You'll have to enable "Show OTR button" in the plugin config (the default should now be "yes", but if you've run the CVS code already, you'll have it set to "no"). Tell me what you think. In any event, I'd change the menu to look like the ones in the menu bar. - Ian From mail@code.mmsources.de Wed May 28 14:26:49 2008 From: mail@code.mmsources.de (Michael Meier) Date: Wed, 28 May 2008 15:26:49 +0200 Subject: [OTR-dev] German translation for Pidgin-otr 3.2.0 Message-ID: <483D5D99.7090609@code.mmsources.de> This is a multi-part message in MIME format. --------------000305080405010605030602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Ian, thank you for informing me about the upcoming release of pidgin-otr 3.2.0, so i could update the translation accordingly. However, i found one inconsistency. The text box for entering the secret/answer included the hint "Enter secret here" in pidgin-otr 3.1.0. Now it's just supposed to be left as an empty text box but because of these two gettext macros, the po header dummy entry is pulled in as replacement instead: gtk-dialog.c: 649 gtk_entry_set_text(GTK_ENTRY(entry), _("")); gtk-dialog.c: 557 gtk_entry_set_text(GTK_ENTRY(entry), _("")); http://data.mmsources.de/pidgin-otr3.2-localization.png Also, these two entries are not yet localized by gettext: gtk-dialog.c: 638 label_text = g_strdup_printf("Enter secret here:"); gtk-dialog.c: 500 label_text = g_strdup_printf("Enter question here:"); Please inform me when you changed this and if you change any more strings before release, so i can keep the translation up-to-date . I'm also subscribed to this mailing list. Regards, Michael --------------000305080405010605030602 Content-Type: text/plain; name="de.po" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="de.po" IyBPZmYtdGhlLVJlY29yZCBNZXNzYWdpbmcgcGx1Z2luIGZvciBwaWRnaW4uCiMgQ29weXJp Z2h0IChDKSBZRUFSIFRIRSBQQUNLQUdFJ1MgQ09QWVJJR0hUIEhPTERFUgojIFRoaXMgZmls ZSBpcyBkaXN0cmlidXRlZCB1bmRlciB0aGUgc2FtZSBsaWNlbnNlIGFzIHRoZSBwaWRnaW4t b3RyIHBhY2thZ2UuCiMgTWljaGFlbCBNZWllciA8bWljaGFlbC5tZWllckBtbXNvdXJjZXMu ZGU+LCAyMDA4LgojCiM6IC4uL2d0ay1kaWFsb2cuYzo1NTcgLi4vZ3RrLWRpYWxvZy5jOjY0 OQptc2dpZCAiIgptc2dzdHIgIiIKIlByb2plY3QtSWQtVmVyc2lvbjogcGlkZ2luLW90ciAz LjEuMC1kZVxuIgoiUmVwb3J0LU1zZ2lkLUJ1Z3MtVG86IFxuIgoiUE9ULUNyZWF0aW9uLURh dGU6IDIwMDctMDgtMjkgMTc6NDYrMDIwMFxuIgoiUE8tUmV2aXNpb24tRGF0ZTogMjAwOC0w NS0yOCAwOToxMiswMjAwXG4iCiJMYXN0LVRyYW5zbGF0b3I6IE1pY2hhZWwgTWVpZXIgPG1p Y2hhZWwubWVpZXJAbW1zb3VyY2VzLmRlPlxuIgoiTGFuZ3VhZ2UtVGVhbTogTWljaGFlbCBN ZWllciA8bWljaGFlbC5tZWllckBtbXNvdXJjZXMuZGU+XG4iCiJNSU1FLVZlcnNpb246IDEu MFxuIgoiQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04XG4iCiJDb250 ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0XG4iCgojOiAuLi9ndGstZGlhbG9nLmM6NDM0 IC4uL2d0ay1kaWFsb2cuYzoyMDIzIC4uL2d0ay1kaWFsb2cuYzoyNDgzCm1zZ2lkICJfV2hh dCdzIHRoaXM/Igptc2dzdHIgIl9XYXMgaXN0IGRhcz8iCgojOiAuLi9ndGstZGlhbG9nLmM6 NDQ1Cm1zZ2lkICJfTW9yZS4uLiIKbXNnc3RyICJfTWVoci4uLiIKCiM6IC4uL2d0ay1kaWFs b2cuYzo0NzkKIywgYy1mb3JtYXQKbXNnaWQgIiIKIiVzIHdpc2hlcyB0byBhdXRoZW50aWNh dGUgeW91LiBZb3VyIGJ1ZGR5IGhhcyBjaG9zZW4gYSBxdWVzdGlvbiBmb3IgeW91IHRvICIK ImFuc3dlci5cbiIKbXNnc3RyICIiCiIlcyB3w7xuc2NodCwgc2llIHp1IGF1dGhlbnRpZml6 aWVyZW4uIElociBCdWRkeSBoYXQgZm9sZ2VuZGUgRnJhZ2UgenVyICIKIkJlYW50d29ydHVu ZyBnZXfDpGhsdC5cbiIKCiM6IC4uL2d0ay1kaWFsb2cuYzo0ODIKIywgYy1mb3JtYXQKbXNn aWQgIkVudGVyIGEgcXVlc3Rpb24gb25seSAlcyBhbmQgeW91cnNlbGYgY2FuIGFuc3dlci5c biIKbXNnc3RyICJHZWJlbiBTaWUgZWluZSBGcmFnZSBlaW4sIGRpZSBudXIgU2llIHVuZCAl cyBiZWFudHdvcnRlbiBrw7ZubmVuLlxuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjQ5Nwptc2dp ZCAiVGhpcyBpcyB0aGUgcXVlc3Rpb24gYXNrZWQgYnkgeW91ciBidWRkeToiCm1zZ3N0ciAi RGllc2UgRnJhZ2Ugd3VyZGUgdm9uIElocmVtIEJ1ZGR5IGdlc3RlbGx0OiIKCiM6IC4uL2d0 ay1kaWFsb2cuYzo1MzEgLi4vZ3RrLWRpYWxvZy5jOjY1NQptc2dpZCAiVGhpcyBidWRkeSBp cyBhbHJlYWR5IGF1dGhlbnRpY2F0ZWQuIgptc2dzdHIgIkRpZXNlciBCdWRkeSB3dXJkZSBi ZXJlaXRzIGF1dGhlbnRpZml6aWVydC4iCgojOiAuLi9ndGstZGlhbG9nLmM6NTQzCm1zZ2lk ICJFbnRlciBzZWNyZXQgYW5zd2VyIGhlcmUgKGNhc2Ugc2Vuc2l0aXZlKToiCm1zZ3N0ciAi R2VoZWltZSBBbnR3b3J0IGhpZXIgZWluZ2ViZW46IChHcm/Dny0vS2xlaW5zY2hyZWlidW5n IHJlbGV2YW50KSIKCiM6IC4uL2d0ay1kaWFsb2cuYzo1NzgKbXNnaWQgIiIKIllvdXIgYnVk ZHkgaXMgYXR0ZW1wdGluZyB0byBkZXRlcm1pbmUgaWYgaGUgb3Igc2hlIGlzIHJlYWxseSB0 YWxraW5nIHRvIHlvdSwgIgoib3IgaWYgaXQncyBzb21lb25lIHByZXRlbmRpbmcgdG8gYmUg eW91LiAgWW91ciBidWRkeSBoYXMgYXNrZWQgYSBxdWVzdGlvbiwgIgoiaW5kaWNhdGVkIGFi b3ZlLiAgVG8gYXV0aGVudGljYXRlIHRvIHlvdXIgYnVkZHksIGVudGVyIHRoZSBhbnN3ZXIg YW5kIGNsaWNrICIKIk9LLiIKbXNnc3RyICIiCiJJaHIgQnVkZHkgdmVyc3VjaHQgZmVzdHp1 c3RlbGxlbiwgb2IgZXIgd2lya2xpY2ggbWl0IElobmVuIHNwcmljaHQgb2RlciAiCiJqZW1h bmRlbSwgZGVyIHNpY2ggYWxzIFNpZSBhdXNnaWJ0LiBFciBoYXQgZGF6dSBkaWUgb2JlbiBh bmdlZ2ViZW5lIEZyYWdlICIKImdlc3RlbGx0LiBVbSBJaHJlbiBCdWRkeSB6dSBhdXRoZW50 aWZpemllcmVuLCBnZWJlbiBTaWUgZGllIEFudHdvcnQgZWluIHVuZCAiCiJrbGlja2VuIFNp ZSBPSy4iCgojOiAuLi9ndGstZGlhbG9nLmM6NTgzIC4uL2d0ay1kaWFsb2cuYzo1OTkgLi4v Z3RrLWRpYWxvZy5jOjY3OQptc2dpZCAiIgoiSWYgeW91ciBidWRkeSB1c2VzIG11bHRpcGxl IElNIGFjY291bnRzIG9yIG11bHRpcGxlIGNvbXB1dGVycywgeW91IG1heSBoYXZlICIKInRv IGF1dGhlbnRpY2F0ZSBtdWx0aXBsZSB0aW1lcy4gIEhvd2V2ZXIsIGFzIGxvbmcgYXMgaGUg b3Igc2hlIHVzZXMgYW4gIgoiYWNjb3VudCBhbmQgY29tcHV0ZXIgdGhhdCB5b3UndmUgc2Vl biBiZWZvcmUsIHlvdSBkb24ndCBuZWVkIHRvIGF1dGhlbnRpY2F0ZSAiCiJlYWNoIGluZGl2 aWR1YWwgY29udmVyc2F0aW9uLiIKbXNnc3RyICIiCiJTb2xsdGUgSWhyIEJ1ZGR5IHZlcnNj aGllZGVuZSBJTS1Lb250ZW4gb2RlciB2ZXJzY2hpZWRlbmUgQ29tcHV0ZXIgIgoidmVyd2Vu ZGVuLCBtw7xzc2VuIFNpZSBkaWUgQXV0aGVudGlmaXppZXJ1bmcgbcO2Z2xpY2hlcndlaXNl IG1laHJtYWxzICIKImR1cmNoZsO8aHJlbi4gQW5zb25zdGVuIGlzdCBlcyBuaWNodCBlcmZv cmRlcmxpY2gsIGRpZSBBdXRoZW50aWZpemllcnVuZyBmw7xyICIKImplZGUgZWluemVsbmUg VW50ZXJoYWx0dW5nIGR1cmNoenVmw7xocmVuLiIKCiMuIFRoZSBVTlZFUklGSUVEX0hFTFBV UkwgYWN0dWFsbHkgY29udGFpbnMgaGVscCBpbmZvIGZvciBhbGwgc3RhdHVzZXMKIzogLi4v Z3RrLWRpYWxvZy5jOjU4OCAuLi9ndGstZGlhbG9nLmM6NjA0IC4uL2d0ay1kaWFsb2cuYzo2 ODQKIzogLi4vZ3RrLWRpYWxvZy5jOjExODggLi4vZ3RrLWRpYWxvZy5jOjExOTIgLi4vZ3Rr LWRpYWxvZy5jOjEzMTYKIzogLi4vZ3RrLWRpYWxvZy5jOjE0ODQgLi4vZ3RrLWRpYWxvZy5j OjE2NTYgLi4vZ3RrLWRpYWxvZy5jOjE3NTkKIzogLi4vZ3RrLWRpYWxvZy5jOjE4NTAgLi4v Z3RrLWRpYWxvZy5jOjIyOTMKbXNnaWQgIj9sYW5nPWVuIgptc2dzdHIgIj9sYW5nPWRlIgoK IzogLi4vZ3RrLWRpYWxvZy5jOjU4OSAuLi9ndGstZGlhbG9nLmM6NjA1IC4uL2d0ay1kaWFs b2cuYzo2ODUKbXNnaWQgIkNsaWNrIGhlcmUgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg YXV0aGVudGljYXRpb24gaW4gT1RSLiIKbXNnc3RyICJIaWVyIGtsaWNrZW4sIHVtIG1laHIg SW5mb3JtYXRpb25lbiDDvGJlciBBdXRoZW50aWZpemllcnVuZyBpbiBPVFIgenUgIgoiZXJo YWx0ZW4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjU5NAptc2dpZCAiIgoiVG8gYXV0aGVudGlj YXRlIHVzaW5nIGEgcXVlc3Rpb24sIHBpY2sgYSBxdWVzdGlvbiB3aG9zZSBhbnN3ZXIgaXMg a25vd24gb25seSAiCiJ0byB5b3UgYW5kIHlvdXIgYnVkZHkuICBFbnRlciB0aGlzIHF1ZXN0 aW9uIGFuZCB0aGlzIGFuc3dlciwgdGhlbiB3YWl0IGZvciAiCiJ5b3VyIGJ1ZGR5IHRvIGVu dGVyIHRoZSBhbnN3ZXIgdG9vLiAgSWYgdGhlIGFuc3dlcnMgZG9uJ3QgbWF0Y2gsIHRoZW4g eW91ICIKIm1heSBiZSB0YWxraW5nIHRvIGFuIGltcG9zdGVyLiIKbXNnc3RyICIiCiJXw6Ro bGVuIFNpZSB6dXIgQXV0aGVudGlmaXppZXJ1bmcgZWluZSBGcmFnZSBlaW4sIGRlcmVuIEFu dHdvcnQgbnVyIElobmVuIHVuZCAiCiJJaHJlbSBCdWRkeSBiZWthbm50IGlzdC4gR2ViZW4g U2llIGRpZSBGcmFnZSB1bmQgQW50d29ydCBlaW4gdW5kIHdhcnRlbiBTaWUgIgoiZGFubiBk YXJhdWYsIGRhc3MgSWhyIEJ1ZGR5IGRpZXNlIEFudHdvcnQgZWJlbmZhbGxzIGVpbmdpYnQu IFNvbGx0ZW4gZGllICIKIkFudHdvcnRlbiBuaWNodCDDvGJlcmVpbnN0aW1tZW4sIGhhYmVu IFNpZSBlcyBtw7ZnbGljaGVyd2Vpc2UgbWl0IGVpbmVtICIKIkhvY2hzdGFwbGVyIHp1IHR1 bi4iCgojOiAuLi9ndGstZGlhbG9nLmM6NjEwIC4uL2d0ay1kaWFsb2cuYzo2ODkKbXNnaWQg IiIKIkF1dGhlbnRpY2F0aW5nIGEgYnVkZHkgaGVscHMgZW5zdXJlIHRoYXQgdGhlIHBlcnNv biB5b3UgYXJlIHRhbGtpbmcgdG8gaXMgIgoid2hvIGhlIG9yIHNoZSBjbGFpbXMgdG8gYmUu Igptc2dzdHIgIiIKIkVpbmVuIEJ1ZGR5IHp1IGF1dGhlbnRpZml6aWVyZW4gaGlsZnQgc2lj aGVyenVzdGVsbGVuLCBkYXNzIGRpZSBQZXJzb24sIG1pdCAiCiJkZXIgU2llIHNwcmVjaGVu IGRpZSBpc3QsIGRpZSBzaWUgenUgc2VpbiBiZWhhdXB0ZXQuIgoKIzogLi4vZ3RrLWRpYWxv Zy5jOjYyNgojLCBjLWZvcm1hdAptc2dpZCAiRW50ZXIgYSBzZWNyZXQga25vd24gb25seSB0 byAlcyBhbmQgeW91cnNlbGYuXG4iCm1zZ3N0ciAiR2ViZW4gU2llIGVpbmUgUGFzc3BocmFz ZSBlaW4sIGRpZSBudXIgJXMgdW5kIElobmVuIGJla2FubnQgaXN0LlxuIgoKIzogLi4vZ3Rr LWRpYWxvZy5jOjY3NQptc2dpZCAiIgoiVG8gYXV0aGVudGljYXRlLCBwaWNrIGEgc2VjcmV0 IGtub3duIG9ubHkgdG8geW91IGFuZCB5b3VyIGJ1ZGR5LiAgRW50ZXIgdGhpcyAiCiJzZWNy ZXQsIHRoZW4gd2FpdCBmb3IgeW91ciBidWRkeSB0byBlbnRlciBpdCB0b28uICBJZiB0aGUg c2VjcmV0cyBkb24ndCAiCiJtYXRjaCwgdGhlbiB5b3UgbWF5IGJlIHRhbGtpbmcgdG8gYW4g aW1wb3N0ZXIuIgptc2dzdHIgIiIKIlfDpGhsZW4gU2llIHp1ciBBdXRoZW50aWZpemllcnVu ZyBlaW5lIFBhc3NwaHJhc2UsIGRpZSBudXIgSWhuZW4gdW5kIElocmVtICIKIkJ1ZGR5IGJl a2FubnQgaXN0LiBHZWJlbiBTaWUgZGllc2UgUGFzc3BocmFzZSBlaW4sIHdhcnRlbiBTaWUg ZGFubiBkYXJhdWYsICIKImRhc3MgSWhyIEJ1ZGR5IGRpZXNlIFBhc3NwaHJhc2UgZWJlbmZh bGxzIGVpbmdpYnQuIFdlbm4gZGllIFBhc3NwaHJhc2VuICIKIm5pY2h0IMO8YmVyZWluc3Rp bW1lbiwgaGFiZW4gU2llIGVzIG3DtmdsaWNoZXJ3ZWlzZSBtaXQgZWluZW0gSG9jaHN0YXBs ZXIgenUgIgoidHVuLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzo3MTMgLi4vZ3RrLWRpYWxvZy5j OjE1MTQKbXNnaWQgIltub25lXSIKbXNnc3RyICJba2VpbmVyXSIKCiM6IC4uL2d0ay1kaWFs b2cuYzo3MjAgLi4vZ3RrLWRpYWxvZy5jOjEwNzYgLi4vZ3RrLWRpYWxvZy5jOjE1MjEKIzog Li4vZ3RrLWRpYWxvZy5jOjE1NjQgLi4vZ3RrLXVpLmM6MTgxIC4uL290ci1wbHVnaW4uYzox MTYKIzogLi4vb3RyLXBsdWdpbi5jOjIxMyAuLi91aS5jOjExMQptc2dpZCAiVW5rbm93biIK bXNnc3RyICJVbmJla2FubnQiCgojOiAuLi9ndGstZGlhbG9nLmM6NzIxIC4uL2d0ay1kaWFs b2cuYzoxNTIyCiMsIGMtZm9ybWF0Cm1zZ2lkICIiCiJGaW5nZXJwcmludCBmb3IgeW91LCAl cyAoJXMpOlxuIgoiJXNcbiIKIlxuIgoiUHVycG9ydGVkIGZpbmdlcnByaW50IGZvciAlczpc biIKIiVzXG4iCm1zZ3N0ciAiIgoiRmluZ2VycHJpbnQgZsO8ciBTaWUsICVzICglcyk6XG4i CiIlc1xuIgoiXG4iCiJBbmdlZ2ViZW5lciBGaW5nZXJwcmludCBmw7xyICVzOlxuIgoiJXNc biIKCiM6IC4uL2d0ay1kaWFsb2cuYzo3NjkKbXNnaWQgIkF1dGhlbnRpY2F0aW9uIE9wdGlv bnMiCm1zZ3N0ciAiQXV0aGVudGlmaXppZXJ1bmdzb3B0aW9uZW4iCgojOiAuLi9ndGstZGlh bG9nLmM6NzgxCm1zZ2lkICJBdXRoZW50aWNhdGUgYnkgcG9zaW5nIGEgcXVlc3Rpb24gb25s eSB5b3VyIGJ1ZGR5IHdpbGwga25vdyIKbXNnc3RyICJBdXRoZW50aWZpemllcnVuZyDDvGJl ciBlaW5lIEZyYWdlLCBkZXJlbiBBbnR3b3J0IG51ciBJaHIgQnVkZHkga2VubnQiCgojOiAu Li9ndGstZGlhbG9nLmM6NzgzCm1zZ2lkICJBdXRoZW50aWNhdGUgZWFjaCBvdGhlciB1c2lu ZyBhIHByZWRldGVybWluZWQgc2hhcmVkIHNlY3JldCBwaHJhc2UiCm1zZ3N0ciAiQXV0aGVu dGlmaXppZXJ1bmcgw7xiZXIgZWluZSB2b3JoZXIgYWJnZXNwcm9jaGVuZSBnZWhlaW1lIFBh c3NwaHJhc2UiCgojOiAuLi9ndGstZGlhbG9nLmM6Nzg1Cm1zZ2lkICJBdXRoZW50aWNhdGUg YnkgdmVyaWZ5aW5nIHlvdXIgYnVkZHkncyBmaW5nZXJwcmludCAoQWR2YW5jZWQpIgptc2dz dHIgIkF1dGhlbnRpZml6aWVydW5nIMO8YmVyIGRlbiBGaW5nZXJwcmludCBJaHJlcyBCdWRk eXMgKEZvcnRnZXNjaHJpdHRlbikiCgojOiAuLi9ndGstZGlhbG9nLmM6OTc0Cm1zZ2lkICJB dXRoZW50aWNhdGluZyB0byBCdWRkeSIKbXNnc3RyICJBdXRoZW50aWZpemllcmUgZ2VnZW7D vGJlciBCdWRkeSIKCiM6IC4uL2d0ay1kaWFsb2cuYzo5NzUKbXNnaWQgIkF1dGhlbnRpY2F0 aW5nIEJ1ZGR5Igptc2dzdHIgIkF1dGhlbnRpZml6aWVyZSBCdWRkeSIKCiM6IC4uL2d0ay1k aWFsb2cuYzoxMDAyCm1zZ2lkICJBdXRoZW50aWNhdGluZyB0byIKbXNnc3RyICJBdXRoZW50 aWZpemllcmUgZ2VnZW7DvGJlciIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxMDAzCm1zZ2lkICJB dXRoZW50aWNhdGluZyIKbXNnc3RyICJBdXRoZW50aWZpemllcmUiCgojOiAuLi9ndGstZGlh bG9nLmM6MTAzNAptc2dpZCAiV2FpdGluZyBmb3IgYnVkZHkuLi4iCm1zZ3N0ciAiV2FydGUg YXVmIEJ1ZGR5Li4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEwNjcKbXNnaWQgIkdlbmVyYXRp bmcgcHJpdmF0ZSBrZXkiCm1zZ3N0ciAiR2VuZXJpZXJlIHByaXZhdGVuIFNjaGzDvHNzZWwi CgojOiAuLi9ndGstZGlhbG9nLmM6MTA2OAptc2dpZCAiUGxlYXNlIHdhaXQiCm1zZ3N0ciAi Qml0dGUgd2FydGVuIgoKIy4gQ3JlYXRlIHRoZSBQbGVhc2UgV2FpdC4uLiBkaWFsb2cKIzog Li4vZ3RrLWRpYWxvZy5jOjEwNzkKIywgYy1mb3JtYXQKbXNnaWQgIkdlbmVyYXRpbmcgcHJp dmF0ZSBrZXkgZm9yICVzICglcykuLi4iCm1zZ3N0ciAiR2VuZXJpZXJlIHByaXZhdGVuIFNj aGzDvHNzZWwgZsO8ciAlcyAoJXMpLi4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjExMjQKIywg Yy1mb3JtYXQKbXNnaWQgIiVzIERvbmUuIgptc2dzdHIgIiVzIEZlcnRpZy4iCgojOiAuLi9n dGstZGlhbG9nLmM6MTE4NgojLCBjLWZvcm1hdAptc2dpZCAiIgoiJXMgaXMgY29udGFjdGlu ZyB5b3UgZnJvbSBhbiB1bnJlY29nbml6ZWQgY29tcHV0ZXIuICBZb3Ugc2hvdWxkIDxhIGhy ZWY9XCIlcyUiCiJzXCI+YXV0aGVudGljYXRlPC9hPiB0aGlzIGJ1ZGR5LiIKbXNnc3RyICIi CiIlcyBrb250YWt0aWVydCBTaWUgdm9uIGVpbmVtIHVuYmVrYW5udGVuIENvbXB1dGVyIGF1 cy4gU2llIHNvbGx0ZW4gZGllc2VuICIKIkJ1ZGR5IDxhIGhyZWY9XCIlcyVzXCI+YXV0aGVu dGlmaXppZXJlbjwvYT4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjExOTAKIywgYy1mb3JtYXQK bXNnaWQgIiIKIiVzIGhhcyBub3QgYmVlbiBhdXRoZW50aWNhdGVkIHlldC4gIFlvdSBzaG91 bGQgPGEgaHJlZj1cIiVzJXMiCiJcIj5hdXRoZW50aWNhdGU8L2E+IHRoaXMgYnVkZHkuIgpt c2dzdHIgIiIKIiVzIHd1cmRlIG5vY2ggbmljaHQgYXV0aGVudGlmaXppZXJ0LiBTaWUgc29s bHRlbiBkaWVzZW4gQnVkZHkgPGEgaHJlZj1cIiVzJXMiCiJcIj5hdXRoZW50aWZpemllcmVu PC9hPi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTIzNyAuLi9ndGstZGlhbG9nLmM6MjAwOCAu Li9ndGstZGlhbG9nLmM6MjI4OAojOiAuLi9ndGstdWkuYzo4Mgptc2dpZCAiRmluaXNoZWQi Cm1zZ3N0ciAiQmVlbmRldCIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxMjM4IC4uL2d0ay1kaWFs b2cuYzoyMDA1IC4uL2d0ay1kaWFsb2cuYzoyMjg1CiM6IC4uL2d0ay11aS5jOjgxCm1zZ2lk ICJQcml2YXRlIgptc2dzdHIgIlByaXZhdCIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxMjM5IC4u L2d0ay1kaWFsb2cuYzoyMDAyIC4uL2d0ay1kaWFsb2cuYzoyMjgyCiM6IC4uL2d0ay11aS5j OjgwCm1zZ2lkICJVbnZlcmlmaWVkIgptc2dzdHIgIlVudmVyaWZpemllcnQiCgojOiAuLi9n dGstZGlhbG9nLmM6MTI0MCAuLi9ndGstdWkuYzo3OQptc2dpZCAiTm90IHByaXZhdGUiCm1z Z3N0ciAiTmljaHQgcHJpdmF0IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyNDMKbXNnaWQgIlN0 YXJ0IGEgcHJpdmF0ZSBjb252ZXJzYXRpb24iCm1zZ3N0ciAiUHJpdmF0ZSBVbnRlcmhhbHR1 bmcgc3RhcnRlbiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxMjQ0Cm1zZ2lkICJSZWZyZXNoIHRo ZSBwcml2YXRlIGNvbnZlcnNhdGlvbiIKbXNnc3RyICJQcml2YXRlIFVudGVyaGFsdHVuZyBh a3R1YWxpc2llcmVuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjEyNDkgLi4vZ3RrLWRpYWxvZy5j OjE5NTQgLi4vZ3RrLWRpYWxvZy5jOjIwNTMKbXNnaWQgIlN0YXJ0IF9wcml2YXRlIGNvbnZl cnNhdGlvbiIKbXNnc3RyICJfUHJpdmF0ZSBVbnRlcmhhbHR1bmcgc3RhcnRlbiIKCiM6IC4u L2d0ay1kaWFsb2cuYzoxMjUwIC4uL2d0ay1kaWFsb2cuYzoxOTU1Cm1zZ2lkICJSZWZyZXNo IF9wcml2YXRlIGNvbnZlcnNhdGlvbiIKbXNnc3RyICJfUHJpdmF0ZSBVbnRlcmhhbHR1bmcg YWt0dWFsaXNpZXJlbiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNDQ5Cm1zZ2lkICJJIGhhdmUg bm90Igptc2dzdHIgIkljaCBoYWJlIG5pY2h0IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE0NTAK bXNnaWQgIkkgaGF2ZSIKbXNnc3RyICJJY2ggaGFiZSIKCiM6IC4uL2d0ay1kaWFsb2cuYzox NDUyCm1zZ2lkICIgdmVyaWZpZWQgdGhhdCB0aGlzIGlzIGluIGZhY3QgdGhlIGNvcnJlY3Qi Cm1zZ3N0ciAiIMO8YmVycHLDvGZ0LCBkYXNzIGRpZXMgdGF0c8OkY2hsaWNoIGRlciByaWNo dGlnZSIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNDYxCiMsIGMtZm9ybWF0Cm1zZ2lkICJmaW5n ZXJwcmludCBmb3IgJXMuIgptc2dzdHIgIkZpbmdlcnByaW50IGbDvHIgJXMgaXN0LiIKCiM6 IC4uL2d0ay1kaWFsb2cuYzoxNDczCm1zZ2lkICIiCiJUbyB2ZXJpZnkgdGhlIGZpbmdlcnBy aW50LCBjb250YWN0IHlvdXIgYnVkZHkgdmlhIHNvbWUgPGk+b3RoZXI8L2k+ICIKImF1dGhl bnRpY2F0ZWQgY2hhbm5lbCwgc3VjaCBhcyB0aGUgdGVsZXBob25lIG9yIEdQRy1zaWduZWQg ZW1haWwuICBFYWNoIG9mICIKInlvdSBzaG91bGQgdGVsbCB5b3VyIGZpbmdlcnByaW50IHRv IHRoZSBvdGhlci4iCm1zZ3N0ciAiIgoiVW0gZGVuIEZpbmdlcnByaW50IHp1IHZlcmlmaXpp ZXJlbiwga29udGFrdGllcmVuIFNpZSBJaHJlbiBCdWRkeSDDvGJlciBlaW5lbiAiCiI8aT5h bmRlcmVuPC9pPiBzaWNoZXJlbiBLYW5hbCwgenVtIEJlaXNwaWVsIHBlcnPDtm5saWNoLCBw ZXIgR1BHLSIKInZlcnNjaGzDvHNzZWx0ZXIgRS1NYWlsIG9kZXIgdGVsZWZvbmlzY2guIFNp ZSBzb2xsdGVuIFNpY2ggZ2VnZW5zZWl0aWcgSWhyZSAiCiJGaW5nZXJwcmludHMgbWl0dGVp bGVuLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNDc3Cm1zZ2lkICIiCiJJZiBldmVyeXRoaW5n IG1hdGNoZXMgdXAsIHlvdSBzaG91bGQgaW5kaWNhdGUgaW4gdGhlIGFib3ZlIGRpYWxvZyB0 aGF0IHlvdSAiCiI8Yj5oYXZlPC9iPiB2ZXJpZmllZCB0aGUgZmluZ2VycHJpbnQuIgptc2dz dHIgIiIKIldlbm4gYWxsZXMgw7xiZXJlaW5zdGltbXQsIHNvbGx0ZW4gU2llIGltIG9iaWdl biBEaWFsb2cgYW5nZWJlbiwgZGFzcyBTaWUgZGVuICIKIkZpbmdlcnByaW50IDwvYj50YXRz w6RjaGxpY2g8L2I+IHZlcmlmaXppZXJ0IGhhYmVuLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzox NDc5Cm1zZ2lkICIiCiJJZiB5b3VyIGJ1ZGR5IGhhcyBtb3JlIHRoYW4gb25lIElNIGFjY291 bnQsIG9yIHVzZXMgbW9yZSB0aGFuIG9uZSBjb21wdXRlciwgIgoiaGUgbWF5IGhhdmUgbXVs dGlwbGUgZmluZ2VycHJpbnRzLiIKbXNnc3RyICIiCiJTb2xsdGUgSWhyIEJ1ZGR5IG1laHIg YWxzIGVpbiBJTS1Lb250byBvZGVyIG1laHJlcmUgQ29tcHV0ZXIgdmVyd2VuZGVuLCBrYW5u ICIKImVyIG1laHIgYWxzIGVpbmVuIEZpbmdlcnByaW50IGhhYmVuLiIKCiM6IC4uL2d0ay1k aWFsb2cuYzoxNDgxCm1zZ2lkICIiCiJIb3dldmVyLCB0aGUgb25seSB3YXkgYW4gaW1wb3N0 ZXIgY291bGQgZHVwbGljYXRlIG9uZSBvZiB5b3VyIGJ1ZGR5J3MgIgoiZmluZ2VycHJpbnRz IGlzIGJ5IHN0ZWFsaW5nIGluZm9ybWF0aW9uIGZyb20gaGVyL2hpcyBjb21wdXRlci4iCm1z Z3N0ciAiIgoiRGllIGVpbnppZ2UgTcO2Z2xpY2hrZWl0IGbDvHIgZWluZW4gSG9jaHN0YXBs ZXIsIGRpZSBGaW5nZXJwcmludHMgSWhyZXMgQnVkZHlzICIKInp1IGtvcGllcmVuIGlzdCBk YXMgU3RlaGxlbiBkZXIgSW5mb3JtYXRpb25lbiB2b24gc2VpbmVtL2locmVtIENvbXB1dGVy LiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNDg1Cm1zZ2lkICJDbGljayBoZXJlIGZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IGZpbmdlcnByaW50cy4iCm1zZ3N0ciAiS2xpY2tlbiBTaWUg aGllciBmw7xyIHp1c8OkdHpsaWNoZSBJbmZvcm1hdGlvbmVuIMO8YmVyIEZpbmdlcnByaW50 cy4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTQ4OAptc2dpZCAiIgoiQSA8Yj5maW5nZXJwcmlu dDwvYj4gaXMgYSB1bmlxdWUgaWRlbnRpZmllciB0aGF0IHlvdSBzaG91bGQgdXNlIHRvICIK ImF1dGhlbnRpY2F0ZSB5b3VyIGJ1ZGR5LiIKbXNnc3RyICIiCiJFaW4gPGI+RmluZ2VycHJp bnQ8L2I+IGlzdCBlaW4gZWlubWFsaWdlcyBJZGVudGlmaXppZXJ1bmdzbWVya21hbCwgZGFz IFNpZSAiCiJ2ZXJ3ZW5kZW4gc29sbHRlbiwgdW0gSWhyZW4gQnVkZHkgenUgYXV0aGVudGlm aXppZXJlbi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTUxMAojLCBjLWZvcm1hdAptc2dpZCAi VmVyaWZ5IGZpbmdlcnByaW50IGZvciAlcyIKbXNnc3RyICJGaW5nZXJwcmludCBmw7xyICVz IHZlcmlmaXppZXJlbi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTUyNyAuLi9ndGstdWkuYzo3 NzMKbXNnaWQgIlZlcmlmeSBmaW5nZXJwcmludCIKbXNnc3RyICJGaW5nZXJwcmludCB2ZXJp Zml6aWVyZW4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTU1NAojLCBjLWZvcm1hdAptc2dpZCAi QXV0aGVudGljYXRpb24gZnJvbSAlcyIKbXNnc3RyICJBdXRoZW50aWZpemllcnVuZyB2b24g JXMiCgojOiAuLi9ndGstZGlhbG9nLmM6MTU1NwojLCBjLWZvcm1hdAptc2dpZCAiQXV0aGVu dGljYXRlICVzIgptc2dzdHIgIiVzIGF1dGhlbnRpZml6aWVyZW4iCgojOiAuLi9ndGstZGlh bG9nLmM6MTU2Nwptc2dpZCAiQXV0aGVudGljYXRlIEJ1ZGR5Igptc2dzdHIgIkJ1ZGR5IGF1 dGhlbnRpZml6aWVyZW4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTU5OAptc2dpZCAiQW4gZXJy b3Igb2NjdXJyZWQgZHVyaW5nIGF1dGhlbnRpY2F0aW9uLiIKbXNnc3RyICJFaW4gRmVobGVy IGlzdCBiZWkgZGVyIEF1dGhlbnRpZml6aWVydW5nIGF1ZmdldHJldGVuLiIKCiM6IC4uL2d0 ay1kaWFsb2cuYzoxNjEzCm1zZ2lkICJBdXRoZW50aWNhdGlvbiBzdWNjZXNzZnVsLiIKbXNn c3RyICJBdXRoZW50aWZpemllcnVuZyBlcmZvbGdyZWljaC4iCgojOiAuLi9ndGstZGlhbG9n LmM6MTYxNgptc2dpZCAiIgoiWW91ciBidWRkeSBoYXMgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRp Y2F0ZWQgeW91LiAgWW91IG1heSB3YW50IHRvIGF1dGhlbnRpY2F0ZSAiCiJ5b3VyIGJ1ZGR5 IGFzIHdlbGwgYnkgYXNraW5nIHlvdXIgb3duIHF1ZXN0aW9uLiIKbXNnc3RyICIiCiJJaHIg QnVkZHkgaGF0IFNpZSBlcmZvbGdyZWljaCBhdXRoZW50aWZpemllcnQuIFVudGVyIFVtc3TD pG5kZW4gbcO2Y2h0ZW4gU2llICIKImViZW5mYWxscyBlaW5lIEZyYWdlIHN0ZWxsZW4gdW0g SWhyZW4gQnVkZHkgenUgYXV0aGVudGlmaXppZXJlbi4iCgojOiAuLi9ndGstZGlhbG9nLmM6 MTYyMgptc2dpZCAiQXV0aGVudGljYXRpb24gZmFpbGVkLiIKbXNnc3RyICJBdXRoZW50aWZp emllcnVuZyBmZWhsZ2VzY2hsYWdlbi4iCgojOiAuLi9ndGstZGlhbG9nLmM6MTY1MAojLCBj LWZvcm1hdAptc2dpZCAiUHJpdmF0ZSBjb252ZXJzYXRpb24gd2l0aCAlcyBzdGFydGVkLiVz Igptc2dzdHIgIlByaXZhdGUgVW50ZXJoYWx0dW5nIG1pdCAlcyBiZWdvbm5lbi4lcyIKCiM6 IC4uL2d0ay1kaWFsb2cuYzoxNjU0CiMsIGMtZm9ybWF0Cm1zZ2lkICI8YSBocmVmPVwiJXMl c1wiPlVudmVyaWZpZWQ8L2E+IGNvbnZlcnNhdGlvbiB3aXRoICUlcyBzdGFydGVkLiUlcyIK bXNnc3RyICIiCiJOaWNodCA8YSBocmVmPVwiJXMlc1wiPnZlcmlmaXppZXJ0ZTwvYT4gVW50 ZXJoYWx0dW5nIG1pdCAlJXMgYmVnb25uZW4uJSVzIgoKIy4gVGhpcyBsYXN0IGNhc2Ugc2hv dWxkIG5ldmVyIGhhcHBlbiwgc2luY2Ugd2Uga25vdwojLiAqIHdlJ3JlIGluIEVOQ1JZUFRF RC4KIzogLi4vZ3RrLWRpYWxvZy5jOjE2NjIKIywgYy1mb3JtYXQKbXNnaWQgIk5vdCBwcml2 YXRlIGNvbnZlcnNhdGlvbiB3aXRoICVzIHN0YXJ0ZWQuJXMiCm1zZ3N0ciAiTmljaHQgcHJp dmF0ZSBVbnRlcmhhbHR1bmcgbWl0ICVzIGJlZ29ubmVuLiVzIgoKIzogLi4vZ3RrLWRpYWxv Zy5jOjE2NjggLi4vZ3RrLWRpYWxvZy5jOjE3NzIKbXNnaWQgIiAgV2FybmluZzogdXNpbmcg b2xkIHByb3RvY29sIHZlcnNpb24gMS4iCm1zZ3N0ciAiICBXYXJudW5nOiBWZXJ3ZW5kZSB2 ZXJhbHRldGUgUHJvdG9rb2xsdmVyc2lvbiAxLiIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNjg4 CiMsIGMtZm9ybWF0Cm1zZ2lkICJQcml2YXRlIGNvbnZlcnNhdGlvbiB3aXRoICVzIGxvc3Qu Igptc2dzdHIgIlByaXZhdGUgVW50ZXJoYWx0dW5nIG1pdCAlcyBhYmdlYnJvY2hlbi4iCgoj OiAuLi9ndGstZGlhbG9nLmM6MTcyNQojLCBjLWZvcm1hdAptc2dpZCAiIgoiJXMgaGFzIGVu ZGVkIGhpcy9oZXIgcHJpdmF0ZSBjb252ZXJzYXRpb24gd2l0aCB5b3U7IHlvdSBzaG91bGQg ZG8gdGhlIHNhbWUuIgptc2dzdHIgIiIKIiVzIGhhdCBzZWluZS9paHJlIHByaXZhdGUgVW50 ZXJoYWx0dW5nIG1pdCBJaG5lbiBiZWVuZGV0LiBTaWUgc29sbHRlbiAiCiJkYXNzZWxiZSB0 dW4uIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjE3NTEKIywgYy1mb3JtYXQKbXNnaWQgIlN1Y2Nl c3NmdWxseSByZWZyZXNoZWQgdGhlIHByaXZhdGUgY29udmVyc2F0aW9uIHdpdGggJXMuJXMi Cm1zZ3N0ciAiUHJpdmF0ZSBVbnRlcmhhbHR1bmcgbWl0ICVzIGVyZm9sZ3JlaWNoIGFrdHVh bGlzaWVydC4lcyIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNzU2CiMsIGMtZm9ybWF0Cm1zZ2lk ICIiCiJTdWNjZXNzZnVsbHkgcmVmcmVzaGVkIHRoZSA8YSBocmVmPVwiJXMlc1wiPnVudmVy aWZpZWQ8L2E+IGNvbnZlcnNhdGlvbiB3aXRoICIKIiUlcy4lJXMiCm1zZ3N0ciAiIgoiTmlj aHQgPGEgaHJlZj1cIiVzJXNcIj52ZXJpZml6aWVydGU8L2E+IFVudGVyaGFsdHVuZyBtaXQg JSVzIGVyZm9sZ3JlaWNoICIKImFrdHVhbGlzaWVydC4lJXMiCgojLiBUaGlzIGxhc3QgY2Fz ZSBzaG91bGQgbmV2ZXIgaGFwcGVuLCBzaW5jZSB3ZSBrbm93CiMuICogd2UncmUgaW4gRU5D UllQVEVELgojOiAuLi9ndGstZGlhbG9nLmM6MTc2NQojLCBjLWZvcm1hdAptc2dpZCAiU3Vj Y2Vzc2Z1bGx5IHJlZnJlc2hlZCB0aGUgbm90IHByaXZhdGUgY29udmVyc2F0aW9uIHdpdGgg JXMuJXMiCm1zZ3N0ciAiTmljaHQgcHJpdmF0ZSBVbnRlcmhhbHR1bmcgbWl0ICVzIGVyZm9s Z3JlaWNoIGFrdHVhbGlzaWVydC4lcyIKCiM6IC4uL2d0ay1kaWFsb2cuYzoxNzk3CiMsIGMt Zm9ybWF0Cm1zZ2lkICJBdHRlbXB0aW5nIHRvIHJlZnJlc2ggdGhlIHByaXZhdGUgY29udmVy c2F0aW9uIHdpdGggJXMuLi4iCm1zZ3N0ciAiVmVyc3VjaGUsIGRpZSBwcml2YXRlIFVudGVy aGFsdHVuZyBtaXQgJXMgenUgYWt0dWFsaXNpZXJlbi4uLiIKCiM6IC4uL2d0ay1kaWFsb2cu YzoxNzk5CiMsIGMtZm9ybWF0Cm1zZ2lkICJBdHRlbXB0aW5nIHRvIHN0YXJ0IGEgcHJpdmF0 ZSBjb252ZXJzYXRpb24gd2l0aCAlcy4uLiIKbXNnc3RyICJWZXJzdWNoZSwgZWluZSBwcml2 YXRlIFVudGVyaGFsdHVuZyBtaXQgJXMgenUgYmVnaW5uZW4uLi4iCgojOiAuLi9ndGstZGlh bG9nLmM6MTk5OSAuLi9ndGstZGlhbG9nLmM6MjI3OQptc2dpZCAiTm90IFByaXZhdGUiCm1z Z3N0ciAiTmljaHQgcHJpdmF0IgoKIzogLi4vZ3RrLWRpYWxvZy5jOjIwNTQgLi4vZ3RrLWRp YWxvZy5jOjI0NDgKbXNnaWQgIl9FbmQgcHJpdmF0ZSBjb252ZXJzYXRpb24iCm1zZ3N0ciAi UHJpdmF0ZSBVbnRlcmhhbHR1bmcgYmVfZW5kZW4iCgojLgojLiAqIERvbid0IHNob3cgdGhl IFZlcmlmeSBmaW5nZXJwcmludCBtZW51IG9wdGlvbiBhbnkgbW9yZS4gIFlvdSBjYW4KIy4g KiBzdGlsbCBnZXQgdG8gdGhlIGRpYWxvZyB0aHJvdWdoIEF1dGhlbnRpY2F0ZSBjb25uZWN0 aW9uIC0+CiMuICogQWR2YW5jZWQuLi4KIy4gKgojLiBtZW51dmVyZiA9IGd0a19tZW51X2l0 ZW1fbmV3X3dpdGhfbW5lbW9uaWMoXygiX1ZlcmlmeSBmaW5nZXJwcmludCIpKTsKIy4gZ3Rr X21lbnVfc2hlbGxfYXBwZW5kKEdUS19NRU5VX1NIRUxMKG1lbnUpLCBtZW51dmVyZik7CiMu IGd0a193aWRnZXRfc2hvdyhtZW51dmVyZik7CiMuCiM6IC4uL2d0ay1kaWFsb2cuYzoyMDU1 IC4uL2d0ay1kaWFsb2cuYzoyNDY2Cm1zZ2lkICJfQXV0aGVudGljYXRlIGJ1ZGR5Igptc2dz dHIgIkJ1ZGR5IF9hdXRoZW50aWZpemllcmVuIgoKIzogLi4vZ3RrLWRpYWxvZy5jOjIyNzUK IywgYy1mb3JtYXQKbXNnaWQgIiIKIlRoZSBwcml2YWN5IHN0YXR1cyBvZiB0aGUgY3VycmVu dCBjb252ZXJzYXRpb24gaXMgbm93OiA8YSBocmVmPVwiJXMlc1wiPiVzPC8iCiJhPiIKbXNn c3RyICIiCiJEZXIgU3RhdHVzIGRlciBha3R1ZWxsZW4gVW50ZXJoYWx0dW5nIGlzdCBqZXR6 dDogPGEgaHJlZj1cIiVzJXNcIj4lczwvYT4iCgojOiAuLi9ndGstZGlhbG9nLmM6MjQzMApt c2dpZCAiT1RSOiIKbXNnc3RyICIiCgojOiAuLi9ndGstZGlhbG9nLmM6MjQ0Mgptc2dpZCAi T1RSIE1lc3NhZ2luZyIKbXNnc3RyICIiCgojOiAuLi9ndGstdWkuYzoxMDIKIywgYy1mb3Jt YXQKbXNnaWQgIkZpbmdlcnByaW50OiAlLjgwcyIKbXNnc3RyICJGaW5nZXJwcmludDogJS44 MHMiCgojOiAuLi9ndGstdWkuYzoxMDYKIywgYy1mb3JtYXQKbXNnaWQgIk5vIGtleSBwcmVz ZW50Igptc2dzdHIgIktlaW4gU2NobMO8c3NlbCB2b3JoYW5kZW4iCgojOiAuLi9ndGstdWku YzoxMTEKIywgYy1mb3JtYXQKbXNnaWQgIk5vIGFjY291bnQgYXZhaWxhYmxlIgptc2dzdHIg IktlaW5lIEtvbnRlbiB2ZXJmw7xnYmFyIgoKIzogLi4vZ3RrLXVpLmM6MTcxCm1zZ2lkICJV bnVzZWQiCm1zZ3N0ciAiVW5iZW51dHp0IgoKIzogLi4vZ3RrLXVpLmM6MTc3Cm1zZ2lkICJZ ZXMiCm1zZ3N0ciAiSmEiCgojOiAuLi9ndGstdWkuYzoxNzcKbXNnaWQgIk5vIgptc2dzdHIg Ik5laW4iCgojOiAuLi9ndGstdWkuYzo0MDMKbXNnaWQgIkVuYWJsZSBwcml2YXRlIG1lc3Nh Z2luZyIKbXNnc3RyICJQcml2YXRlbiBOYWNocmljaHRlbnZlcnNhbmQgYWt0aXZpZXJlbiIK CiM6IC4uL2d0ay11aS5jOjQwNQptc2dpZCAiQXV0b21hdGljYWxseSBpbml0aWF0ZSBwcml2 YXRlIG1lc3NhZ2luZyIKbXNnc3RyICJQcml2YXRlbiBOYWNocmljaHRlbnZlcnNhbmQgYXV0 b21hdGlzY2ggYWt0aXZpZXJlbiIKCiM6IC4uL2d0ay11aS5jOjQwNwptc2dpZCAiUmVxdWly ZSBwcml2YXRlIG1lc3NhZ2luZyIKbXNnc3RyICJQcml2YXRlbiBOYWNocmljaHRlbnZlcnNh bmQgZXJ6d2luZ2VuIgoKIzogLi4vZ3RrLXVpLmM6NDEwCm1zZ2lkICJEb24ndCBsb2cgT1RS IGNvbnZlcnNhdGlvbnMiCm1zZ3N0ciAiT1RSLVVudGVyaGFsdHVuZ2VuIG5pY2h0IHNwZWlj aGVybiIKCiM6IC4uL2d0ay11aS5jOjQ1Mwptc2dpZCAiU2hvdyBPVFIgYnV0dG9uIgptc2dz dHIgIk9UUi1CdXR0b24gYW56ZWlnZW4iCgojOiAuLi9ndGstdWkuYzo1OTIKbXNnaWQgIk15 IHByaXZhdGUga2V5cyIKbXNnc3RyICJNZWluZSBwcml2YXRlbiBTY2hsw7xzc2VsIgoKIzog Li4vZ3RrLXVpLmM6NjAxCm1zZ2lkICJLZXkgZm9yIGFjY291bnQ6Igptc2dzdHIgIlNjaGzD vHNzZWwgZsO8ciBLb250bzoiCgojOiAuLi9ndGstdWkuYzo2MjYKbXNnaWQgIkdlbmVyYXRl Igptc2dzdHIgIkdlbmVyaWVyZW4iCgojOiAuLi9ndGstdWkuYzo2NjcKbXNnaWQgIkRlZmF1 bHQgT1RSIFNldHRpbmdzIgptc2dzdHIgIlN0YW5kYXJkIE9UUi1FaW5zdGVsbHVuZ2VuIgoK IzogLi4vZ3RrLXVpLmM6Njk0Cm1zZ2lkICJPVFIgVUkgT3B0aW9ucyIKbXNnc3RyICJPVFIt RXJzY2hlaW51bmdzYmlsZCIKCiM6IC4uL2d0ay11aS5jOjcxNwptc2dpZCAiU2NyZWVubmFt ZSIKbXNnc3RyICJTcGl0em5hbWUiCgojOiAuLi9ndGstdWkuYzo3MTgKbXNnaWQgIlN0YXR1 cyIKbXNnc3RyICJTdGF0dXMiCgojOiAuLi9ndGstdWkuYzo3MTkKbXNnaWQgIlZlcmlmaWVk Igptc2dzdHIgIlZlcmlmaXppZXJ0IgoKIzogLi4vZ3RrLXVpLmM6NzIwCm1zZ2lkICJGaW5n ZXJwcmludCIKbXNnc3RyICJGaW5nZXJwcmludCIKCiM6IC4uL2d0ay11aS5jOjcyMQptc2dp ZCAiQWNjb3VudCIKbXNnc3RyICJLb250byIKCiM6IC4uL2d0ay11aS5jOjc1Nwptc2dpZCAi U3RhcnQgcHJpdmF0ZSBjb25uZWN0aW9uIgptc2dzdHIgIlByaXZhdGUgVW50ZXJoYWx0dW5n IHN0YXJ0ZW4iCgojOiAuLi9ndGstdWkuYzo3NjUKbXNnaWQgIkVuZCBwcml2YXRlIGNvbm5l Y3Rpb24iCm1zZ3N0ciAiUHJpdmF0ZSBVbnRlcmhhbHR1bmcgYmVlbmRlbiIKCiM6IC4uL2d0 ay11aS5jOjc4MQptc2dpZCAiRm9yZ2V0IGZpbmdlcnByaW50Igptc2dzdHIgIkZpbmdlcnBy aW50IHZlcmdlc3NlbiIKCiM6IC4uL2d0ay11aS5jOjgzMgptc2dpZCAiQ29uZmlnIgptc2dz dHIgIktvbmZpZ3VyYXRpb24iCgojOiAuLi9ndGstdWkuYzo4MzQKbXNnaWQgIktub3duIGZp bmdlcnByaW50cyIKbXNnc3RyICJCZWthbm50ZSBGaW5nZXJwcmludHMiCgojOiAuLi9ndGst dWkuYzo5MzIgLi4vb3RyLXBsdWdpbi5jOjYwNgptc2dpZCAiT1RSIFNldHRpbmdzIgptc2dz dHIgIk9UUi1FaW5zdGVsbHVuZ2VuIgoKIy4gU2V0IHRoZSB0aXRsZQojOiAuLi9ndGstdWku Yzo5NTAKIywgYy1mb3JtYXQKbXNnaWQgIk9UUiBTZXR0aW5ncyBmb3IgJXMiCm1zZ3N0ciAi T1RSLUVpbnN0ZWxsdW5nZW4gZsO8ciAlcyIKCiMuIE1ha2UgdGhlIGNhc2NhZGVkIGNoZWNr Ym94ZXMKIzogLi4vZ3RrLXVpLmM6OTY3Cm1zZ2lkICJVc2UgZGVmYXVsdCBPVFIgc2V0dGlu Z3MgZm9yIHRoaXMgYnVkZHkiCm1zZ3N0ciAiU3RhbmRhcmQgT1RSLUVpbnN0ZWxsdW5nZW4g ZsO8ciBkaWVzZW4gQnVkZHkgdmVyd2VuZGVuIgoKIzogLi4vb3RyLXBsdWdpbi5jOjExNAoj LCBjLWZvcm1hdAptc2dpZCAiWW91IGFyZSBub3QgY3VycmVudGx5IGNvbm5lY3RlZCB0byBh Y2NvdW50ICVzICglcykuIgptc2dzdHIgIlNpZSBzaW5kIG1vbWVudGFuIG5pY2h0IG1pdCBL b250byAlcyB2ZXJidW5kZW4oJXMpLiIKCiM6IC4uL290ci1wbHVnaW4uYzoxMTgKbXNnaWQg Ik5vdCBjb25uZWN0ZWQiCm1zZ3N0ciAiTmljaHQgdmVyYnVuZGVuIgoKIzogLi4vb3RyLXBs dWdpbi5jOjE2MgojLCBjLWZvcm1hdAptc2dpZCAiT3V0IG9mIG1lbW9yeSBidWlsZGluZyBm aWxlbmFtZXMhXG4iCm1zZ3N0ciAiS2VpbiBTcGVpY2hlciB6dW0gRXJzdGVsbGVuIHZvbiBE YXRlaW5hbWVuIVxuIgoKIzogLi4vb3RyLXBsdWdpbi5jOjE2OAojLCBjLWZvcm1hdAptc2dp ZCAiQ291bGQgbm90IHdyaXRlIHByaXZhdGUga2V5IGZpbGVcbiIKbXNnc3RyICJLb25udGUg bmljaHQgaW4gZGllIFByaXZhdGUtU2NobMO8c3NlbC1EYXRlaSBzY2hyZWliZW5cbiIKCiM6 IC4uL290ci1wbHVnaW4uYzoyMTEKIywgYy1mb3JtYXQKbXNnaWQgIlVua25vd24gYWNjb3Vu dCAlcyAoJXMpLiIKbXNnc3RyICJVbmJla2FubnRlcyBLb250byAlcyAoJXMpLiIKCiM6IC4u L290ci1wbHVnaW4uYzoyMTUKbXNnaWQgIlVua25vd24gYWNjb3VudCIKbXNnc3RyICJVbmJl a2FubnRlcyBLb250byIKCiM6IC4uL290ci1wbHVnaW4uYzo5ODMKbXNnaWQgIk9mZi10aGUt UmVjb3JkIE1lc3NhZ2luZyIKbXNnc3RyICIiCgojOiAuLi9vdHItcGx1Z2luLmM6OTg0Cm1z Z2lkICJQcm92aWRlcyBwcml2YXRlIGFuZCBzZWN1cmUgY29udmVyc2F0aW9ucyIKbXNnc3Ry ICJFcm3DtmdsaWNodCBwcml2YXRlIHVuZCBzaWNoZXJlIFVudGVyaGFsdHVuZ2VuIgoKIzog Li4vb3RyLXBsdWdpbi5jOjk4NQptc2dpZCAiIgoiUHJlc2VydmVzIHRoZSBwcml2YWN5IG9m IElNIGNvbW11bmljYXRpb25zIGJ5IHByb3ZpZGluZyBlbmNyeXB0aW9uLCAiCiJhdXRoZW50 aWNhdGlvbiwgZGVuaWFiaWxpdHksIGFuZCBwZXJmZWN0IGZvcndhcmQgc2VjcmVjeS4iCm1z Z3N0ciAiIgoiQmV3YWhydCBkaWUgVmVydHJhdWxpY2hrZWl0IHZvbiBJTS1VbnRlcmhhbHR1 bmdlbiBkdXJjaCBWZXJzY2hsw7xzc2VsdW5nLCAiCiJBdXRoZW50aWZpemllcnVuZywgR2xh dWJoYWZ0ZSBCZXN0cmVpdGJhcmtlaXQgdW5kIFBlcmZlY3QgRm9yd2FyZCBTZWNyZWN5LiIK CiM6IC4uL3VpLmM6MTA5CiMsIGMtZm9ybWF0Cm1zZ2lkICJBY2NvdW50ICVzICglcykgY291 bGQgbm90IGJlIGZvdW5kIgptc2dzdHIgIktvbnRvICVzICglcykga29ubnRlIG5pY2h0IGdl ZnVuZGVuIHdlcmRlbiIKCiM6IC4uL3VpLmM6MTEzCm1zZ2lkICJBY2NvdW50IG5vdCBmb3Vu ZCIKbXNnc3RyICJLb250byBuaWNodCBnZWZ1bmRlbiIKCiN+IG1zZ2lkICJBZHZhbmNlZC4u LiIKI34gbXNnc3RyICJFcndlaXRlcnQuLi4iCgojfiBtc2dpZCAiRW50ZXIgc2VjcmV0IGhl cmUiCiN+IG1zZ3N0ciAiR2VoZWltZSBQYXNzcGhyYXNlIGhpZXIgZWluZ2ViZW4iCg== --------------000305080405010605030602-- From ian@cypherpunks.ca Wed May 28 16:07:24 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 11:07:24 -0400 Subject: [OTR-dev] German translation for Pidgin-otr 3.2.0 In-Reply-To: <483D5D99.7090609@code.mmsources.de> References: <483D5D99.7090609@code.mmsources.de> Message-ID: <20080528150724.GE24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 03:26:49PM +0200, Michael Meier wrote: > Hello Ian, > > thank you for informing me about the upcoming release of pidgin-otr > 3.2.0, so i could update the translation accordingly. > > However, i found one inconsistency. The text box for entering the > secret/answer included the hint "Enter secret here" in pidgin-otr 3.1.0. > Now it's just supposed to be left as an empty text box but because of > these two gettext macros, the po header dummy entry is pulled in as > replacement instead: > > gtk-dialog.c: 649 > gtk_entry_set_text(GTK_ENTRY(entry), _("")); > > gtk-dialog.c: 557 > gtk_entry_set_text(GTK_ENTRY(entry), _("")); > > http://data.mmsources.de/pidgin-otr3.2-localization.png > > > Also, these two entries are not yet localized by gettext: > > > gtk-dialog.c: 638 > label_text = g_strdup_printf("Enter secret here:"); > > gtk-dialog.c: 500 > label_text = g_strdup_printf("Enter question here:"); Fixed, thanks! > Please inform me when you changed this and if you change any more > strings before release, so i can keep the translation up-to-date . I'm > also subscribed to this mailing list. The ongoing discussions about the authentication dialog will almost certainly produce some new strings to be translated, so keep an eye on this list. - Ian From hcat@gmx.net Wed May 28 17:23:35 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Wed, 28 May 2008 18:23:35 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528121041.GA24571@thunk.cs.uwaterloo.ca> References: <20080527155805.152350@gmx.net> <20080527161249.GH6988@thunk.cs.uwaterloo.ca> <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> Message-ID: <20080528162335.301970@gmx.net> > I like the concept, but have a few questions about the details. Sure! > I don't think it's enough. The appearance of "again" is *way* too > subtle, I think. Yeah I was thinking about this, too. There could be a "Note: This buddy is already autheticated." between the first text and the combo box. > The rest of the help text is now entirely absent, including the link to > the web-based help pages. Where is this link to be found in the original dialog? Anyway, why not add a normal [Help] button to the bottom left of the dialog for this? > I'm just worried about putting so much text into a combo box. > Especially in some other languages, this would make the box really, > really wide, no? This is a valid concern but I think we can get away with less text because of the detailed description below the combo box. Perhaps as simple as: - Question and Answer - Shared Secret - Fingerprint This should do for the combo box IMHO. Especially if you know what you are looking for, having to read less text for the various choices is nice. The details would be explained by the text below the combo as well as the input area below (which changes accordingly to the selected method). > I don't think "Send request" is the right thing to say here, though. > The word "request" appears nowhere else in the dialog. Well I was first thinking about a simple "Authenticate". Perhaps anyone else has a better idea. The "OK" button (while certainly not what the HIG wants) is not the biggest concern here, though. -Michael -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From ian@cypherpunks.ca Wed May 28 18:15:50 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 28 May 2008 13:15:50 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528162335.301970@gmx.net> References: <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> Message-ID: <20080528171550.GI24571@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 06:23:35PM +0200, hcat@gmx.net wrote: > > The rest of the help text is now entirely absent, including the link to > > the web-based help pages. > Where is this link to be found in the original dialog? Anyway, why not > add a normal [Help] button to the bottom left of the dialog for this? It's in the scrollable help text. We could easily add a help button, but you'd still be missing a lot of the text that's there now. I agree with pretty much everything else you've written, though. But it would be really, really useful if someone other than me actually wrote the code; I could do it, but probably not for a little while. Thanks! - Ian From hcat@gmx.net Wed May 28 20:40:05 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Wed, 28 May 2008 21:40:05 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528171550.GI24571@thunk.cs.uwaterloo.ca> References: <20080527170925.216970@gmx.net> <20080527193417.GI6988@thunk.cs.uwaterloo.ca> <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> <20080528171550.GI24571@thunk.cs.uwaterloo.ca> Message-ID: <20080528194005.115490@gmx.net> > It's in the scrollable help text. We could easily add a help button, > but you'd still be missing a lot of the text that's there now. I would just describe the selected auth method in 2-3 lines in the dialog and then link to a webpage with in-depths information and examples. Security is not a trivial matter and users should at least have a basic understanding of what they are doing, which is best done reading some introduction document but not fitting tons of information for 1st time users in every dialog etc. [This is re your other mail about the toolbar button:] > Tell me what you think. In any event, I'd change the menu to look like > the ones in the menu bar. I like it. It would be nice to be able to disable the menu integration optionally. Cheers, -Michael -- Super-Aktion nur in der GMX Spieleflat: 10 Tage für 1 Euro. Über 180 Spiele downloaden: http://flat.games.gmx.de From ian@cypherpunks.ca Thu May 29 15:00:18 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 29 May 2008 10:00:18 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528125918.GB24571@thunk.cs.uwaterloo.ca> References: <20080527170925.216970@gmx.net> <483C5F4C.6050808@gmail.com> <20080527193418.56680@gmx.net> <20080527194458.GJ6988@thunk.cs.uwaterloo.ca> <20080527200248.56650@gmx.net> <20080527201356.GO6988@thunk.cs.uwaterloo.ca> <20080527203541.56660@gmx.net> <20080527205341.GS6988@thunk.cs.uwaterloo.ca> <20080527224108.167060@gmx.net> <20080528125918.GB24571@thunk.cs.uwaterloo.ca> Message-ID: <20080529140018.GC25808@thunk.cs.uwaterloo.ca> On Wed, May 28, 2008 at 08:59:18AM -0400, Ian Goldberg wrote: > I've checked in a change to move the OTR button to the toolbar (but > keeping the menus). You'll have to enable "Show OTR button" in the > plugin config (the default should now be "yes", but if you've run the > CVS code already, you'll have it set to "no"). > > Tell me what you think. In any event, I'd change the menu to look like > the ones in the menu bar. I've changed the menu on the toolbar button to match those in the menu bar. I also figured out how to make the informational items (buddy name and OTR status) non-selectable. Perhaps I'll give a quick go at reformatting the authenticate buddy dialog later this afternoon. - Ian From ian@cypherpunks.ca Thu May 29 22:21:56 2008 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 29 May 2008 17:21:56 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080528194005.115490@gmx.net> References: <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> <20080528171550.GI24571@thunk.cs.uwaterloo.ca> <20080528194005.115490@gmx.net> Message-ID: <20080529212156.GP30190@yoink.cs.uwaterloo.ca> On Wed, May 28, 2008 at 09:40:05PM +0200, hcat@gmx.net wrote: > > It's in the scrollable help text. We could easily add a help button, > > but you'd still be missing a lot of the text that's there now. > I would just describe the selected auth method in 2-3 lines in the > dialog and then link to a webpage with in-depths information and > examples. Security is not a trivial matter and users should at least > have a basic understanding of what they are doing, which is best done > reading some introduction document but not fitting tons of information > for 1st time users in every dialog etc. > > [This is re your other mail about the toolbar button:] > > > Tell me what you think. In any event, I'd change the menu to look like > > the ones in the menu bar. > I like it. It would be nice to be able to disable the menu integration > optionally. OK, give it a try now. I've done both the button-in-the-toolbar and the updated authentication dialog (based on your mockup). Anyone else have any changes to suggest before letting the translators go at it? Thanks, - Ian From ldm@gmx.at Fri May 30 06:05:23 2008 From: ldm@gmx.at (Markus Krainz) Date: Fri, 30 May 2008 07:05:23 +0200 Subject: [OTR-dev] OTR third-party miranda plugin Message-ID: <200805300705.m4U75Z8h002072@paip.net> Hi! I testeted the miranda plugin and concluded that it has several serve bugs. Even closing and opening the message window confuses the otr session and leads in error messages and unsent messages that are so annoying that I found the program unusable. That is unfortunate, because a lot of my friends use Miranda and I think the deniability and the opportunistic encryption features render otr the best, if not the only usable im encryption. To cut a long story short, is there a new plugin version coming out soon? With regards, Markus From hcat@gmx.net Sat May 31 16:49:59 2008 From: hcat@gmx.net (hcat@gmx.net) Date: Sat, 31 May 2008 17:49:59 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080529212156.GP30190@yoink.cs.uwaterloo.ca> References: <20080527201438.56660@gmx.net> <20080527202411.GQ6988@thunk.cs.uwaterloo.ca> <20080527205039.GR6988@thunk.cs.uwaterloo.ca> <20080527214616.167040@gmx.net> <20080528001901.GJ30190@yoink.cs.uwaterloo.ca> <20080528102511.22440@gmx.net> <20080528121041.GA24571@thunk.cs.uwaterloo.ca> <20080528162335.301970@gmx.net> <20080528171550.GI24571@thunk.cs.uwaterloo.ca> <20080528194005.115490@gmx.net> <20080529212156.GP30190@yoink.cs.uwaterloo.ca> Message-ID: <20080531154959.250700@gmx.net> > OK, give it a try now. I've done both the button-in-the-toolbar and > the updated authentication dialog (based on your mockup). Nice! I really like it. > Anyone else have any changes to suggest A few random: - Would it be able to make the menu integration in chats default but optional? - Would it be possible to mark the fingerprints inside the auth dialog as selectable (to easily copy them)? - Perhaps resize the auth dialog according to the space needed (e.g. question&answer takes less space than fingerprint so the dialog could be smaller) Also, I tried to test some stuff while a buddy was offline and it seems he got a message about me trying to initiate a private connection with him or something. I also noticed that the status stays "Private" even after the buddy went offline. Does this make sense? I suppose supporting invisible mode for some protocols would be an issue but how about dropping "Private" when the buddy goes offline and if the user tries to establish another private chat, warn him that this will fail if the buddy is really offline (and not just invisible). Though maybe I'm overlooking something here. Cheers, -Michael -- Super-Aktion nur in der GMX Spieleflat: 10 Tage für 1 Euro. Über 180 Spiele downloaden: http://flat.games.gmx.de