Menu
▾
▴
pyopenssl-list
|
From: Phil M. <p.m...@im...> - 2009-07-09 12:16:09
|
All, I've written a little CLI-based micro CA in pyOpenSSL, but I needed CRL support since Vista insists on the CRL be in place for certain types of certs (e.g. SSL) I had to forward-port the existing CRL/PKCS12 patch, which was not hard but not huge fun... What can I do to help get this patch in mainline? I understand development is now Launchpad/bzr-based; this is unfortunate since I apparently have a cognitive block that causes me to fail utterly in driving both tools - but I'm quite capable of coding, including (I hope) writing the unit tests and so forth. If someone can give me a quick pointer as to what is desired, I'll have a crack at it. |
|
From: Jean-Paul C. <ex...@di...> - 2009-07-09 13:54:37
|
On Thu, 09 Jul 2009 12:39:48 +0100, Phil Mayers <p.m...@im...> wrote: >All, > >I've written a little CLI-based micro CA in pyOpenSSL, but I needed CRL >support since Vista insists on the CRL be in place for certain types of >certs (e.g. SSL) > >I had to forward-port the existing CRL/PKCS12 patch, which was not hard >but not huge fun... > >What can I do to help get this patch in mainline? Hi Phil, Thanks for volunteering. I don't know when I would have gotten to this. Probably not soon. :) >I understand development is now Launchpad/bzr-based; this is unfortunate >since I apparently have a cognitive block that causes me to fail utterly >in driving both tools - but I'm quite capable of coding, including (I >hope) writing the unit tests and so forth. > >If someone can give me a quick pointer as to what is desired, I'll have >a crack at it. > Looking at <https://code.launchpad.net/pyopenssl>, I see that there are presently four different branches related to either CRL or PKCS12. lp:~exarkun/pyopenssl/pkcs12-crl lp:~arnaud-desmons/pyopenssl/pkcs12 lp:~rick-fdd/pyopenssl/pkcs12_mod_and_export lp:~sebvieira/pyopenssl/pkcs12-crl-0.8 This is a rather unfortunate state. Which patch did you port forward, and what did you port it forward to? Of the above branches, I only really know about the first - it's a branch I created a long time ago and only applied Arnaud Desmons' patch to. There are a few things beyond what the original patch did which you can do to help get it landed in trunk: * File a ticket! Right now it's not really clear what the goal of all this work is. It has something to do with "CRL" and "PKCS12" clearly, but writing down something more specific than that will make it possible to figure out what's going on, how the branches that exist related to it, and whether or not the goal has been achieved. * Review the APIs for sensibleness and general-purposeness. Do they expose the underlying OpenSSL APIs in a way that's generally useful, with introduced arbitrary limitations? As someone who knows a bit about CRLs and PKCS12 (I assume - since you wrote a CA ;), hopefully this should be easy for you. * Add unit tests for *all* new code and for any old code which is being modified and is not already tested. * Add documentation for the new APIs (doc/pyOpenSSL.tex is the doc source, the rest of the files in doc/ are generated). As far as bzr and launchpad go, it's pretty easy (but I sympathize with your position - it's too bad we have to know how to use 3 or 4 or more different version control systems these days). Maybe I can help a bit. To start, to get some code to start modifying, you want to create a branch of something in launchpad. If you want to try to apply your updated patch to trunk (which would be ideal), then you want to do bzr branch lp:pyopenssl This will create a "pyopenssl" directory with the checkout in it. Then apply your patch, do your hacking, whatever. At some point you'll want to put your changes into version control. Somewhere under that "pyopenssl" directory, do bzr commit -m "<message>" Or you can leave off the -m to get an editor to write your commit message in. Repeat edit/commit as many times as you need. When you think you're done and you want someone else to take a look, push the branch back to launchpad. Somewhere beneath that "pyopenssl" directory do bzr push lp:~username/pyopenssl/branchname Replace "username" with your Launchpad username. Replace "branchname" with the name you want to associate with this branch. If you haven't previously told bzr about your launchpad credentials, you'll need to do bzr launchpad-login first. And if you'd rather just send patches around, I don't have a problem with that. Thanks, Jean-Paul |
|
From: Phil M. <p.m...@im...> - 2009-07-13 22:06:17
|
> Looking at <https://code.launchpad.net/pyopenssl>, I see that there are > presently four different branches related to either CRL or PKCS12. > > lp:~exarkun/pyopenssl/pkcs12-crl > lp:~arnaud-desmons/pyopenssl/pkcs12 > lp:~rick-fdd/pyopenssl/pkcs12_mod_and_export > lp:~sebvieira/pyopenssl/pkcs12-crl-0.8 I believe at least 3 of those are actually the same patch; numbers 1 & 2, and 3 is a forward-port to 0.8 My work was just a quick port (again) of the 0.8 branch to the 0.9 release code. > * File a ticket! Right now it's not really clear what the goal of all > this work is. It has something to do with "CRL" and "PKCS12" clearly, > but writing down something more specific than that will make it possible > to figure out what's going on, how the branches that exist related to it, > and whether or not the goal has been achieved. Well, to be honest I'm much less interested in pkcs12 (though I can see it's useful) but I'll have a crack at two tickets. > > * Review the APIs for sensibleness and general-purposeness. Do they > expose the underlying OpenSSL APIs in a way that's generally useful, > with introduced arbitrary limitations? As someone who knows a bit > about CRLs and PKCS12 (I assume - since you wrote a CA ;), hopefully > this should be easy for you. Hmm. To be honest, having spent several hours today fooling with BIO* and similar, I intensely dislike most of the OpenSSL APIs, so the less they reflect them... ;o) But I take the point - a sensible, pythonic api. > > * Add unit tests for *all* new code and for any old code which is being > modified and is not already tested. > > * Add documentation for the new APIs (doc/pyOpenSSL.tex is the doc source, > the rest of the files in doc/ are generated). Ack. Tex... I've had a first go at the code; I've added a single test for the CRL. https://code.launchpad.net/~phil-mayers/pyopenssl/crl+morepkcs12 I'm pretty sure it's not the best API layout, but I had a couple of hours free and wanted to get something basic working tonight; I'll try and write a ticket and think about the API tomorrow. Do you have C indent preferences? |
|
From: Jean-Paul C. <ex...@di...> - 2009-07-18 01:55:33
|
On Mon, 13 Jul 2009 23:06:04 +0100, Phil Mayers <p.m...@im...> wrote: >> Looking at <https://code.launchpad.net/pyopenssl>, I see that there are >> presently four different branches related to either CRL or PKCS12. >> >> lp:~exarkun/pyopenssl/pkcs12-crl >> lp:~arnaud-desmons/pyopenssl/pkcs12 >> lp:~rick-fdd/pyopenssl/pkcs12_mod_and_export >> lp:~sebvieira/pyopenssl/pkcs12-crl-0.8 > >I believe at least 3 of those are actually the same patch; numbers 1 & >2, and 3 is a forward-port to 0.8 > >My work was just a quick port (again) of the 0.8 branch to the 0.9 >release code. Hm, if I'd had my head on straight, I would have pinged Rick (owner of branch number 3) and made sure he coordinated with you in this effort. Instead, I only just now realized that you and he have some PKCS12 overlap in the work you're doing. Looking at his branch (not the one above though, he has since created a newer one with a "2" on the end) and yours, I think his PKCS12 code is more complete overall. However, it could still benefit from some of the things your version does (you have better type checking code, I think). I'm going to point him at your work along with my other feedback. Once the PKCS12 stuff is out of the way, I'll dig into the CRL parts of your branch more (I've still only just skimmed them). There is currently a PKCS12 ticket, I see: https://bugs.launchpad.net/pyopenssl/+bug/349304 I also now see that there is a ticket which talks about CRLs! The summary didn't make this obvious so I missed/forget about it. It has a patch attached which I haven't looked at at all yet. The ticket is https://bugs.launchpad.net/pyopenssl/+bug/385178 And to keep things interesting, it sounds like it mixes in a bunch of PKCS7 changes. > [snip] > >Do you have C indent preferences? > I wish I did. I think I'm leaning towards 4 space indents. However, if you're modifying existing code, go with the local prevailing convention. I'm trying to keep things consistent, but I'm sure I'm failing at that in places. Apologies again for not pointing out those two tickets in my previous message. Jean-Paul |
|
From: Sebastian V. <seb...@gm...> - 2009-10-18 13:46:10
|
Hi, Is there any progress on this? I mean, will the CRL functionality be in the next pyOpenSSL release and if so, when will that be? I'm trying to get a python app into Fedora but while a part of its functionality is based on a custom patched pyOpenSSL it will probably not be accepted. Apart from that, it's of course a great feature for pyOpenSSL that will benefit everyone :) thanks, S. On Sat, Jul 18, 2009 at 3:55 AM, Jean-Paul Calderone <ex...@di...>wrote: > On Mon, 13 Jul 2009 23:06:04 +0100, Phil Mayers <p.m...@im...> > wrote: > >> Looking at <https://code.launchpad.net/pyopenssl>, I see that there are > >> presently four different branches related to either CRL or PKCS12. > >> > >> lp:~exarkun/pyopenssl/pkcs12-crl > >> lp:~arnaud-desmons/pyopenssl/pkcs12 > >> lp:~rick-fdd/pyopenssl/pkcs12_mod_and_export > >> lp:~sebvieira/pyopenssl/pkcs12-crl-0.8 > > > >I believe at least 3 of those are actually the same patch; numbers 1 & > >2, and 3 is a forward-port to 0.8 > > > >My work was just a quick port (again) of the 0.8 branch to the 0.9 > >release code. > > Hm, if I'd had my head on straight, I would have pinged Rick (owner of > branch number 3) and made sure he coordinated with you in this effort. > Instead, I only just now realized that you and he have some PKCS12 > overlap in the work you're doing. > > Looking at his branch (not the one above though, he has since created > a newer one with a "2" on the end) and yours, I think his PKCS12 code > is more complete overall. However, it could still benefit from some of > the things your version does (you have better type checking code, I > think). > > I'm going to point him at your work along with my other feedback. > > Once the PKCS12 stuff is out of the way, I'll dig into the CRL parts > of your branch more (I've still only just skimmed them). > > There is currently a PKCS12 ticket, I see: > > https://bugs.launchpad.net/pyopenssl/+bug/349304 > > I also now see that there is a ticket which talks about CRLs! The summary > didn't make this obvious so I missed/forget about it. It has a patch > attached which I haven't looked at at all yet. The ticket is > > https://bugs.launchpad.net/pyopenssl/+bug/385178 > > And to keep things interesting, it sounds like it mixes in a bunch of PKCS7 > changes. > > > [snip] > > > >Do you have C indent preferences? > > > > I wish I did. I think I'm leaning towards 4 space indents. However, if > you're modifying existing code, go with the local prevailing convention. > I'm trying to keep things consistent, but I'm sure I'm failing at that in > places. > > Apologies again for not pointing out those two tickets in my previous > message. > > Jean-Paul > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > pyopenssl-list mailing list > pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyopenssl-list > |
|
From: Sebastian V. <seb...@gm...> - 2009-10-19 19:37:31
|
Replied only to Rick, but this concerns others as well, i think: ---------- Forwarded message ---------- From: Sebastian Vieira <seb...@gm...> Date: Mon, Oct 19, 2009 at 9:35 PM Subject: Re: [pyOpenSSL] CRL & PKCS12 patch To: Rick Dean <ri...@fd...> Hi Rick, On Mon, Oct 19, 2009 at 4:06 AM, Rick Dean <ri...@fd...> wrote: > > Yeah, I wrote it before JP merged the modifiable PKCS12 stuff. > The merge to the tip of trunk was pretty easy and is now posted > to the bug report. It passes all the unit tests. > > FWIW, the patch included updates to the documentation, and several CRL > automated test cases make good examples (test/test_crypto.py). > > -- > Rick > > Works fine here! I especially like the load_crl() function as this was something the original patch from Arnaud Desmons lacked. Great help were the unit tests, so i didn't have to figure out how to 'migrate' my app to this style of CRL handling. Great work, and with the unit tests and documentation i think JP will like it as well :) regards, Sebastian |
|
From: <ex...@tw...> - 2009-10-18 16:05:36
|
On 01:45 pm, seb...@gm... wrote: >Hi, > >Is there any progress on this? I mean, will the CRL functionality be in >the >next pyOpenSSL release and if so, when will that be? I'm trying to get >a >python app into Fedora but while a part of its functionality is based >on a >custom patched pyOpenSSL it will probably not be accepted. > >Apart from that, it's of course a great feature for pyOpenSSL that will >benefit everyone :) > >thanks, Hi, So far, no progress on CRLs in pyOpenSSL. I just took a quick look at the patch attached to https://bugs.launchpad.net/pyopenssl/+bug/385178 - just thoroughly enough to see that it is a long way from being ready to include in trunk. Here's a semi-complete list of what I'd like to see changes about it: * It makes unexplained changes to test_crypto.py; these have nothing to do with CRLs and, if important, should be split out into a separate patch/branch associated with a new ticket that explains their significance. * It makes a memory management change to x509.c which is similarly unexplained and also untested. This should have a unit test and possibly also be split off onto a separate ticket. * It adds get_extension, get_extensions, check_privatekey, verify, repr, and str methods to the X509 type. Also apparently unrelated to CRLs. Also untested. Aside from str and repr these seem valuable and should be added elsewhere, with tests. Maybe str and repr are good too, but I need to be convinced. * It adds str and repr methods to the X509Name type. Also untested and unrelated. * Likewise for X509Req. * There's a bunch of new code in crypto.c about "crypto_ui" and engines which looks like it might be neat, but has nothing to do with crls (and has no tests). * For the new code that's actually x509 crl related: * the whitespace is totally crazy and should be cleaned up * there are no unit tests. I am trying to raise pyOpenSSL to 100% line coverage. That means all new code has to have unit tests. * the function docstrings all use the weird old style which is more aimed at C programmers than Python programmers. They should be updated to be Python programmer friendly. * there's code for dealing with asn1 times copied from another pyOpenSSL source file; this should be factored into a common file that can be re-used, instead of duplicated. A lot of these things are easy to remedy. Just delete some of the patch. However, adding the CRL unit tests is probably real work. Someone who's familiar with the CRL APIs can probably make a significant dent in this without too much trouble. If someone can do that, I'll make time to re-review the new submission and accept it or provide further feedback. Jean-Paul |
|
From: Rick D. <ri...@fd...> - 2009-10-18 20:13:06
|
Sebastian, Did you look at the patch for CRL that I wrote? https://bugs.launchpad.net/pyopenssl/+bug/404436 Would it meet your needs? -- Rick On Sun, Oct 18, 2009 at 04:05:14PM -0000, ex...@tw... wrote: > On 01:45 pm, seb...@gm... wrote: > >Hi, > > > >Is there any progress on this? I mean, will the CRL functionality be in > >the > >next pyOpenSSL release and if so, when will that be? I'm trying to get > >a > >python app into Fedora but while a part of its functionality is based > >on a > >custom patched pyOpenSSL it will probably not be accepted. > > > >Apart from that, it's of course a great feature for pyOpenSSL that will > >benefit everyone :) > > > >thanks, > > Hi, > > So far, no progress on CRLs in pyOpenSSL. I just took a quick look at > the patch attached to https://bugs.launchpad.net/pyopenssl/+bug/385178 - > just thoroughly enough to see that it is a long way from being ready to > include in trunk. Here's a semi-complete list of what I'd like to see > changes about it: > > * It makes unexplained changes to test_crypto.py; these have nothing to > do with CRLs and, if important, should be split out into a separate > patch/branch associated with a new ticket that explains their > significance. > > * It makes a memory management change to x509.c which is similarly > unexplained and also untested. This should have a unit test and > possibly also be split off onto a separate ticket. > > * It adds get_extension, get_extensions, check_privatekey, verify, > repr, and str methods to the X509 type. Also apparently unrelated to > CRLs. Also untested. Aside from str and repr these seem valuable and > should be added elsewhere, with tests. Maybe str and repr are good too, > but I need to be convinced. > > * It adds str and repr methods to the X509Name type. Also untested and > unrelated. > > * Likewise for X509Req. > > * There's a bunch of new code in crypto.c about "crypto_ui" and engines > which looks like it might be neat, but has nothing to do with crls (and > has no tests). > > * For the new code that's actually x509 crl related: > > * the whitespace is totally crazy and should be cleaned up > > * there are no unit tests. I am trying to raise pyOpenSSL to 100% > line coverage. That means all new code has to have unit tests. > > * the function docstrings all use the weird old style which is more > aimed at C programmers than Python programmers. They should be updated > to be Python programmer friendly. > > * there's code for dealing with asn1 times copied from another > pyOpenSSL source file; this should be factored into a common file that > can be re-used, instead of duplicated. > > > A lot of these things are easy to remedy. Just delete some of the > patch. However, adding the CRL unit tests is probably real work. > Someone who's familiar with the CRL APIs can probably make a significant > dent in this without too much trouble. If someone can do that, I'll > make time to re-review the new submission and accept it or provide > further feedback. > > Jean-Paul > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > pyopenssl-list mailing list > pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyopenssl-list -- Rick |
|
From: Phil M. <p.m...@im...> - 2009-10-20 09:55:43
|
> Works fine here! I especially like the load_crl() function as this was > something the original patch from Arnaud Desmons lacked. Great help were > the unit tests, so i didn't have to figure out how to 'migrate' my app > to this style of CRL handling. > > Great work, and with the unit tests and documentation i think JP will > like it as well :) That looks good for me too; I like the API and it works fine in my micro-CA application. |
|
From: Rick D. <ri...@fd...> - 2009-10-21 02:06:29
|
Thanks. -- Rick :-) On Tue, Oct 20, 2009 at 10:55:31AM +0100, Phil Mayers wrote: > > Works fine here! I especially like the load_crl() function as this was > > something the original patch from Arnaud Desmons lacked. Great help were > > the unit tests, so i didn't have to figure out how to 'migrate' my app > > to this style of CRL handling. > > > > Great work, and with the unit tests and documentation i think JP will > > like it as well :) > > That looks good for me too; I like the API and it works fine in my > micro-CA application. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > pyopenssl-list mailing list > pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyopenssl-list |
|
From: Sebastian V. <seb...@gm...> - 2010-01-22 06:25:04
|
Okay, let's try it again ... Could Rick's patch please be included in main? It works great, has test units and applies cleanly. S. On Wed, Oct 21, 2009 at 2:43 AM, Rick Dean <ri...@fd...> wrote: > > Thanks. > > -- > Rick :-) > > On Tue, Oct 20, 2009 at 10:55:31AM +0100, Phil Mayers wrote: > > > Works fine here! I especially like the load_crl() function as this was > > > something the original patch from Arnaud Desmons lacked. Great help > were > > > the unit tests, so i didn't have to figure out how to 'migrate' my app > > > to this style of CRL handling. > > > > > > Great work, and with the unit tests and documentation i think JP will > > > like it as well :) > > > > That looks good for me too; I like the API and it works fine in my > > micro-CA application. > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > pyopenssl-list mailing list > > pyo...@li... > > https://lists.sourceforge.net/lists/listinfo/pyopenssl-list > > |
|
From: <ex...@tw...> - 2010-01-25 21:36:39
|
On 22 Jan, 06:24 am, seb...@gm... wrote: >Okay, let's try it again ... > >Could Rick's patch please be included in main? It works great, has test >units and applies cleanly. Can you remind me where this patch is? I think the PKCS12 changes this thread refers to did land in trunk (in August). I don't remember any CRL changes making it in, though. And looking at the open bugs on Launchpad, none of them seem to be related. Jean-Paul |
|
From: <ex...@tw...> - 2010-01-25 22:01:44
|
On 09:36 pm, ex...@tw... wrote: >On 22 Jan, 06:24 am, seb...@gm... wrote: >>Okay, let's try it again ... >> >>Could Rick's patch please be included in main? It works great, has >>test >>units and applies cleanly. > >Can you remind me where this patch is? I think the PKCS12 changes this >thread refers to did land in trunk (in August). I don't remember any >CRL changes making it in, though. And looking at the open bugs on >Launchpad, none of them seem to be related. Oops. No need for a reminder. This is <https://bugs.launchpad.net/pyopenssl/+bug/385178> right? I forgot how to use Launchpad for a minute. Jean-Paul |
|
From: <ex...@tw...> - 2010-01-25 22:19:49
|
On 10:01 pm, ex...@tw... wrote: >On 09:36 pm, ex...@tw... wrote: >>On 22 Jan, 06:24 am, seb...@gm... wrote: >>>Okay, let's try it again ... >>> >>>Could Rick's patch please be included in main? It works great, has >>>test >>>units and applies cleanly. >> >>Can you remind me where this patch is? I think the PKCS12 changes >>this >>thread refers to did land in trunk (in August). I don't remember any >>CRL changes making it in, though. And looking at the open bugs on >>Launchpad, none of them seem to be related. > >Oops. No need for a reminder. This is ><https://bugs.launchpad.net/pyopenssl/+bug/385178> right? I forgot how >to use Launchpad for a minute. Blech. I meant <https://bugs.launchpad.net/pyopenssl/+bug/404436> of course. Jean-Paul |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X