Thanks. Fixed in CVS.
- Ian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Thu, Oct 26, 2006 at 06:23:03PM -0500, Rudy Godoy wrote:
Package: gaim-otr
Followup-For: Bug #394299
There needs to be another change in order to fix the following error:
gtk-dialog.c:33:22: error: gtkstock.h: No such file or directory
This need to be changed on line 33.
-#include
On Fri, Jan 04, 2008 at 03:16:57PM +0100, Simon Josefsson wrote:
There is also the problem if something other than gnutls has already
initialized libgcrypt. This could happen if exim links to some other
library that uses libgcrypt, for example, a LDAP or database library,
which gets
On Thu, May 26, 2005 at 04:10:01PM -0500, David Fries wrote:
Package: gaim-otr
Version: 2.0.1-1
Severity: normal
The OTR button on the conversation button bar vanishes if 'Show button
as:' Preferences Conversations option is changed. It will only be
visible when the button bar is shown
I just upgraded a bunch of packages in my debian sid box, and I'm seeing
this same behaviour in mythtv, as well.
According to the tracing I've done so far, myth is actually receiving
multiple KeyPressEvents from the qt3 main loop. Here's the bt:
#0 PlaybackBox::keyPressEvent (this=0xbf86da14,
I figured out how to do this on Linux. I have no idea how to do it on
other systems, or how to get libtool to do this on its own (possibly not
possible).
The problem, again: other gaim plugins, such as Jabber or ldap, use
libgcrypt (often in the guise of TLS). libgcrypt uses global variables,
On Sun, Feb 18, 2007 at 10:49:45AM +0100, Thibaut VARENE wrote:
This can't be a widespread problem, though, since we'd definitely have
heard about it by now. Is anyone else running Debian amd64 (x86_64)
that can test this?
Unfortunately, if gaim doesn't start at all because of the plugin,
On Mon, Feb 19, 2007 at 01:43:23AM -0800, Steve Langasek wrote:
What I'm saying is can we find someone else with a Debian amd64 to try
this (apt-get install gaim-otr, see if gaim still works) in order to see
if it's really a gaim-otr problem, or some weird side-effect of
something else.
likely that this is a
bug in gaim-otr or libotr, but I don't think it's one that should block the
package from being released; it is generally usable, just not in certain
system configurations.
Yeah, I do have a system configuration that you don't run across every day ;-)
Ian Goldberg
On Tue, May 08, 2007 at 01:36:29PM +0200, Philipp Sadleder wrote:
Package: gaim-otr
Severity: wishlist
Tags: patch
The successor of gaim named pidgin [1] is already packaged and entered
Debian unstable [2].
Based on an unofficial port to pidgin [3] I build a preliminary
pidgin-otr and
On Tue, May 08, 2007 at 02:15:56PM +0200, Thibaut VARENE wrote:
On 5/8/07, Ian Goldberg [EMAIL PROTECTED] wrote:
The current CVS has already been updated to pidgin-otr. The same
process that was used to build debs that worked with the gaim 2.0 beta
series will work with pidgin now. Let me
On Wed, Jul 09, 2008 at 01:13:55PM +0200, Thibaut VARENE wrote:
tags 489523 help moreinfo
thanks
Hi
I'm not sure this is an actual bug in pidgin-otr (nor libotr, for that
matter). AFAICT (but I don't know the code that much), it uses
libgcrypt's keygen procedures... I'm CC'ing OTR
On Wed, Jul 09, 2008 at 03:15:45PM +0200, Thibaut VARENE wrote:
reassign 489523 libgcrypt
tags 489523 - moreinfo help
thanks
On Wed, Jul 9, 2008 at 2:57 PM, Ian Goldberg [EMAIL PROTECTED] wrote:
I know. It's annoying. libgcrypt has no way I can see to specify the
source of randomness
On Thu, Jul 10, 2008 at 05:49:27PM +0200, Simon Josefsson wrote:
Do be careful about using that function though: its exact semantics are
not documented as far as I know. It may result in having long-term
private key based on no or little entropy.
The current library does the right thing;
On Thu, Jul 10, 2008 at 06:28:43PM -0400, Paul Wouters wrote:
On Thu, 10 Jul 2008, Ian Goldberg wrote:
The problem is that people run key generation with libgcrypt on machines
that gather very little entropy into /dev/random, and key generation can
literally take over an hour
This is fixed in the current version of pidgin-otr.
- Ian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This is fixed in the current version of pidgin-otr.
- Ian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This is fixed in the current version of pidgin-otr (and libotr).
- Ian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Tue, Feb 20, 2007 at 06:10:18AM -0500, Ian Goldberg wrote:
On Mon, Feb 19, 2007 at 08:34:21PM -0700, Berg, Michael wrote:
Steve Langasek wrote:
Well, this problem indeed doesn't seem to be reproducible on i386 or amd64
when not using nss_ldap. Given that users of other gnutls
Package: libwxgtk2.5-dev
Version: 2.5.3.2
Severity: important
libwxgtk2.5-dev provides the wx-config program to let you do
`wx-config --cxxflags`, etc. in your Makefile.
If you want to build a program with wxWidgets linked statically, you
use `wx-config --static --libs`, which outputs:
-pthread
This is a known problem; it occurs when you've got another plugin active
that also uses libgcrypt. libgcrypt keeps global state, and has no way
to gracefully handle being initialized and removed by two separate
shared objects. Over on the libgcrypt list, they were talking about how
to fix this a
On Wed, Oct 25, 2006 at 04:11:13PM +0200, Thibaut VARENE wrote:
Hi,
I'm forwarding this again, as I didn't hear back from Ian. Can
somebody tell me whether this is fixed in CVS or if a new release of
gaim-otr is scheduled soon?
I'd like to fix this bug ASAP to avoid removal of the plugin
On Fri, Aug 24, 2012 at 06:05:18PM +0200, Thibaut VARENE wrote:
In NEW queue. I'll see if I have time to deal with pidgin-otr later on.
Please do not package libotr 4 yet. The release candidate is not
working properly; see otr-dev.
Thanks,
- Ian
--
To UNSUBSCRIBE, email to
On Tue, Feb 26, 2013 at 07:24:38PM -0500, micah anderson wrote:
The patch has been merged into the upstream staging repository.
I've CC'd upstream on this issue, could one of you give the go ahead?
It is a bit of a chicken and egg thing because it would help a lot of
this could get more
On Wed, Oct 23, 2013 at 12:35:09AM +0200, Thibaut Varène wrote:
intrig...@debian.org wrote (08 Oct 2013 09:27:56 GMT) :
as you are surely aware of, it's been known [1] since 2006 that
clients supporting both OTRv1 and v2 (such as libotr 3.x) are subject
to protocol downgrade attacks
OTR developers (who happens to know quite
a bit about what a well-formed OTR message looks like, as you may
guess), it was rather caused by a buggy implementation of the OTRv3
protocol in Psi+:
Ian Goldberg wrote (28 Dec 2013 15:45:09 GMT) :
See
http://lists.cypherpunks.ca/pipermail/otr
On Fri, Jan 03, 2014 at 11:23:44PM +0100, intrig...@debian.org wrote:
Source: libotr
Version: 4.0.0-2.2
Severity: normal
Tags: patch
User: hardening-disc...@lists.alioth.debian.org
Usertags: goal-hardening
Hi,
the attached patch completes the set of hardening flags used for
libotr, by
See
http://lists.cypherpunks.ca/pipermail/otr-users/2013-November/002392.html
For some reason, psi+ (before the workaround that removes OTRv3 support)
was sending messages with a sender instance of 0. If someone could do a
trace in psi+ to see why that was happening, it would pinpoint the
On Tue, Oct 28, 2014 at 08:56:07PM -0400, Filipus Klutiero wrote:
I am not convinced this is a good thing, but for sure the current
phrasing is incorrect. According to the technical paper, OTR would
merely send the key to the other participant, so only him could forge
messages, unless someone
On Thu, Oct 30, 2014 at 11:05:20PM +0100, Niels Thykier wrote:
Control: severity 767230 serious
On 2014-10-29 17:09, intrigeri wrote:
Hi Sebastian, hi release team,
[...]
Hi,
Thanks for contacting us about this matter.
Anyway: it seems that I've actually started a
On Sat, Nov 01, 2014 at 06:19:16PM +0100, intrigeri wrote:
* Generate and maintain a symbols file.
Note that this is enough if, and only if, we don't reintroduce
upstream's runtime version check (which we're going to remove for
Jessie). If we reintroduce this check, reverse-deps compiled
ended here:
https://github.com/boxbackup/boxbackup/wiki/WeakSSLCertificates#replacing-certificates
This patch is against the version in Ubuntu 22.04.1:
oxbackup_0.13~~git20200326.g8e8b63c-1ubuntu2.dsc
--
Ian Goldberg
Canada Research Chair in Privacy Enhancing Technologies
Professor, Cheriton School o
On Wed, Aug 17, 2022 at 05:54:53PM +0300, Ileana Dumitrescu wrote:
> > I made the attached patch, which causes the package to build and run on
> both openssl 3.x and pre-3.x systems.
>
> Thank you for the patch! I will add it to the next debian upload.
>
> > Note, however, that on openssl 3.x
33 matches
Mail list logo
