gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] Fixing OpenPGP keyring import


From: Timo Schulz
Subject: Re: [gnutls-dev] Fixing OpenPGP keyring import
Date: Wed, 18 Apr 2007 19:49:43 +0200
User-agent: Icedove 1.5.0.10 (X11/20070329)

Simon Josefsson wrote:

>> We decided that opencdk base64 decodes the CDK_DBTYPE_DATA object,
>> right?
> 
> Yeah, I think so. (Ludovic, correct me if I'm wrong.)

OK, I will post the patch then.


> I think it may better not to back-port this stuff to the nmav branch.
> Let's aim for GnuTLS changing to use OpenCDK HEAD instead.

That's exactly my position. This avoids to double mantain two branches
and it probably fixes other problems.


> Sure, although please don't change any API/ABI without discussing it
> first.  Since we are talking about a big API/ABI break with moving to
> OpenCDK HEAD, I think an addition API/ABI break is a no-no, but it

I agree with it. All patches I would commit were just bug fixes and
wouldn't change any existing interface. That's why I want to discuss
the migration. Then we know what functions are missing or need to be
changed and we can do the migration and new code in a row.


> Sounds good...  since 1.7.8 was just released, if your changes are
> relatively safe you could install your fixes to GnuTLS on HEAD right

At least the CDK_DBTYPE_DATA patch is safe.


> now, and we can aim for 1.7.9 to mostly just do the OpenCDK upgrade.
> I do want to have HEAD in a buildable stage for most of the time, so
> if you think you'll need more than a few days of time to finish the
> migration, let's create a branch for it.  What do you think?

Hmm, first I need to check how much code I would need to change and how
fast I can test the changes. But I don't think it will take longer than
2-3 days. I actually hope <= 2 days but I need to check the code first.


        Timo

p.s.
I attached the patch, but if we do the upgrade now (or better soon as
possible), it is not needed because the OpenCDK HEAD fixes the problem.

--- /tmp/keydb.c        2007-04-18 19:40:43.000000000 +0200
+++ keydb.c     2007-04-18 19:42:31.000000000 +0200
@@ -263,6 +263,8 @@
             cdk_free( hd );
             return CDK_Out_Of_Core;
         }
+       if( cdk_armor_filter_use( hd->buf ) )
+           cdk_stream_set_armor_flag( hd->buf, 0 );    
         break;
 
     default:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]