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

Re: [sup-devel] [PATCH] Converted crypto to use the gpgme gem



Excerpts from Hamish D's message of Die Nov 16 15:20:03 +0100 2010:
> > The "+" character is right in front of the string "Good signature from
> > ...". If you move the cursor to that line and press enter it changes
> > to a "-" character, but no additional text is shown. The gpg command
> > output used to show up there when pressing enter.
> >
> > I expect there to be some additional output about the signature
> > validation like keyid, signature date, trust level, ...
> 
> Right, now I know what you are referring to. It is a CryptoNotice
> object. That didn't work in the first version of the patch, but I
> fixed it in the patch I submitted the second time.
> 
> So with the patches submitted in the message with time stamp "8
> November 2010 22:32" there will be lines when you expand, telling you
> the key ID, the timestamp of the signature and all names and email
> addresses associated with that key.

This does not work for me when running the foobacca/gpgme tree (commit
7b9a1eeeaaa25931963e2de49410d7cb0c7e6772). The CryptoNotice is empty.
I'm using the following packages from Debians testing distribution:
- ruby1.8 1.8.7.302-2
- libgpgme-ruby1.8 1.0.8-3
- libgpgme11 1.2.0-1.2
- libgpg-error0 1.6-1

Please tell me if you need further information to debug the problem.

> 
> I am also working on having extra information generated when the key
> is not trusted, but this is not done yet. And I am also working on a
> hook where you can generate as much information as you want from the
> signature for the CryptoNotice. Hopefully be ready to submit before
> the weekend.

This sounds nice. Thanks for your work!

> 
> While doing this I'm wondering about the preferred way of submitting
> patches that represent quite a bit of work. Should I use git rebase -i
> to just have a single patch with all changes, or is it preferred to
> have a series of smaller changes?

Dunno about the official policy. I'd say break it if the pieces are
usefull on their own (but may depend on each other), otherwise make
them one patch.

Gaudenz
--
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel