[Open-collaboration-services] [REQUEST] Extend API to support gpg signature

[Frederik Gladhorn]

On Monday 26 July 2010 13:40:42 Diego Casella ([Po]lentino) wrote:
> 2010/7/26 Frank Karlitschek <karlitschek at kde.org>
> 
> > Hi Diego,
> > 
> > thats a great idea. We can add a signature extension to the API as you
> > suggested,
> > Do you have a specification or a more detailed description how this
> > system should work?
> 
> This is my use-case for plasmoid authentication, but it will most likely be
> extended for any type of package, let it be a theme, a wallpaper plugin or
> whatever else.
> Case #1: download scenario:
> * The user opens the KHNS widget;
> * the widget retrieves the packages infos, along with its signature field
> in an ascii-armored format (if any);
> * the widget start checking the signatures, displaying for each item the
> corresponding level of trust(good/bad/invalid sig etc..);
> * the user decides whether downloading the package or not.
> 
> Case #2: upload scenario:
> * the developers want to upload its cool new package, and confirm the
> authenticity of its product;
> * he signs the package with its private gpg key, and then opens the KHNS
> Upload dialog;
> * he selects the package and the signature to upload, and then sends them
> to the service provider.
> 
> As you can see, the most of the work is being done from the client-side.
> What I need is simply a the possibility to have an extra field called
> "signature" used to send it along with the package, that's all :) Then, the
> client app will take care of authenticating it.
> What's your opinion about it? Does it makes sense?

Sounds pretty good to me. Signatures are about 200 byte if I'm not mistaken. I 
would almost favor to inline them in the content/get request, so we don't need 
to make a separate call. Any reason not to?

For those as gpg-ignorant as I am:
Create a signature with 
gpg -ab attica.tbz2
And get a file attica.tbz2.asc out of that.
That is the signature, ascii-armored.
gpg --verify attica.tbz2.asc checks the signature.
For knewstuff we'll instead use lib...something.

Signature looks like this:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAkxN6ewACgkQcZKJUyELiPfZlwCgipEZJjUgf9z3HembEYpVtX9h
pfwAn39WOGGcVBYCBaM92xDRStffL7zY
=Hudq
-----END PGP SIGNATURE-----

Just to say it again: I'm happy to see this happening :D

Greetings
Frederik



> 
> Cheers,
> 
> Diego.
> 
> > I can help you with a testserver as soon as we agree on the
> > specification.
> > 
> > 
> > Cheers
> > Frank
> > 
> > On 26.07.2010, at 11:56, Diego Casella ([Po]lentino) wrote:
> > > Hello guys,
> > > 
> > > as you should know, this summer I'm working on the authentication of
> > 
> > downloaded plasmoids by verifying their signatures with the keys in the
> > user keyring, and show their "TrustLevel" in the Download Plasmoid
> > dialog. However, to make it work correctly, I need the server to be
> > extended in order to handle sending and receiving detached,
> > ascii-armored, signatures. Besides, talking with Frederik, he wants this
> > feature more general and not restricted to plasmoids-only, in order to
> > give the user a level of trust about what he/she is going to download
> > from the web. For these reasons, gpg signature support would a great
> > improvement to the existing api.
> > 
> > > What do you think about it ?
> > > Regards,
> > > 
> > > Diego.
> > > 
> > > --
> > > H: Who is Watson without Sherlock Holmes?
> > > G: Watson was a genius in his own right.
> > > _______________________________________________
> > > Open-collaboration-services mailing list
> > > Open-collaboration-services at kde.org
> > > https://mail.kde.org/mailman/listinfo/open-collaboration-services
> > 
> > --
> > Frank Karlitschek
> > karlitschek at kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/open-collaboration-services/attachments/20100726/87be22ea/attachment.sig