RE: Windows Cryptography API - Public Key Authentication extensions

["Murphy, Gearoid P" <gearoid.murphy@xxxxxx>]

Hi Aris

Thanks for your detailed reply. This information will be very useful to me when submitting my proposal to HPs internal open source review board. I will contact again when I know more.

Thanks
 - Gearoid
________________________________________
From: Aris Adamantiadis [aris@xxxxxxxxxxxx]
Sent: 10 June 2011 16:33
To: libssh@xxxxxxxxxx
Subject: Re: Windows Cryptography API - Public Key Authentication extensions

Hi Gearoid,

First thank you for going into the process of publishing changes
upstream, we really appreciate it. Token support is also very
appreciated, since it's a hot topic right now. We are working to
implement PKCS#11 tokens, and having support for native windows API is
complementary.

We do not have very strict guidelines or rules on the code inclusion, we
can say that empirically they are the following:

- Copyright is kept by the committer, at least for nontrivial (more than
a few lines) changes. Here it would be HP or yourself, depending on your
guidelines
- We'd prefer to keep the license homogeneous, with LGPL, but if you
choose to publish under a license compatible with LGPL and more liberal,
this shouldn't be a problem (3-clause BSD or MIT license for instance).
Stronger or incompatible licenses are not desirable because they impact
the project as a whole.
-Code quality is a concern. The new code should follow the syntaxical
and naming conventions of the existing codebase, should be of good
general quality and not introduce security problems. If possible, avoid
a mess and maze of #ifdef that we are currently removing, especially in
the crypto code that's shared between libgcrypt and openssl.
- Dependance on external libraries or environment should be avoided if
possible. If your patch depends on a specific functionality (like
windows crypto services), steps should be taken so libssh compiles
cleanly without it (with CMAKE for instance).
- If the patch introduces new functionalities, a minimum of
documentation (in doxygen) on the way to use it and the most common
problems is really welcome, since this means our support work will go up
with the new functionalities).

On the patch itself, we prefer using the distributed features of git to
retrieve your work and comment it, but a .patch file is good too. Of
course, this is an iterative process, we can start by looking at the
diff and suggesting changes.

Thanks for all,

Aris

Le 10/06/11 17:13, Murphy, Gearoid P a écrit :
> Hello
>
> I'm a HP network engineer. I recently modified my local build of libssh (v0.48) with public key authentication a la Windows Cryptography service for use with x509 certificate public keys. HP support engineers depend heavily on usb tokens with x509 certs for authentication across our network infrastructure.
>
> I would like to submit a patch containing the modifications. HP has very specific guidelines on such submissions, so before I commit anything, I'd appreciate any advice you can give me on the process of submitting a patch for approval to your project?
>
> Thank you.
>
> - Gearoid
>