From alex.gaynor at gmail.com Tue Feb 4 18:13:41 2014 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 4 Feb 2014 09:13:41 -0800 Subject: [Cryptography-dev] Starting to think about release 0.2 Message-ID: Hey all, David has conned me into volunteering to do our 0.2 release. Here are the things I see as high priority for this release: * RSA/DSA primitive APIs * New random engine for OpenSSL * Re-adding CAST5 * Making our release process include building wheels My hope is that this is about 1-2 weeks of work, but we'll see, the scope of the assymetric work is a bit variable depending on format loading and passwords and such, so we'll see. If you think someone is missing from this, please mention it, and if you can add it to the 0.2 milestone on github. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Tue Feb 4 18:20:05 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 4 Feb 2014 11:20:05 -0600 Subject: [Cryptography-dev] Starting to think about release 0.2 In-Reply-To: References: Message-ID: We?ve currently got the removal of asserts in the openssl backend tagged for 0.2. Do we want to move this back? There was also a fuzzer issue listed under the second release milestone that I moved to third. On Tuesday, February 4, 2014 at 11:13 AM, Alex Gaynor wrote: > Hey all, > > David has conned me into volunteering to do our 0.2 release. Here are the things I see as high priority for this release: > > * RSA/DSA primitive APIs > * New random engine for OpenSSL > * Re-adding CAST5 > * Making our release process include building wheels > > My hope is that this is about 1-2 weeks of work, but we'll see, the scope of the assymetric work is a bit variable depending on format loading and passwords and such, so we'll see. > > If you think someone is missing from this, please mention it, and if you can add it to the 0.2 milestone on github. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Sun Feb 9 18:39:58 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sun, 9 Feb 2014 11:39:58 -0600 Subject: [Cryptography-dev] HOTP/TOTP in Cryptography Message-ID: <80810AC8271B42B2A78DA7B9D76FEAA2@gmail.com> In short: do we want to add HOTP/TOTP support to cryptography? An issue was filed last night by a developer who would like to add HOTP/TOTP support to the project (tracking issue: https://github.com/pyca/cryptography/issues/588). This led to a discussion in IRC this morning where Donald raised some concerns about what criteria we should have for adding/maintaining constructions under our umbrella (see the link above for his full thoughts). I would argue that HOTP/TOTP meet the threshold (whatever it is) of noteworthiness for inclusion in the project because they are well-defined, simple protocols that won?t be a maintenance burden and benefit from being inside a well-tested (and trusted?) library. They are also in common use, so we don?t have to be concerned about including code no one would ever use. The counterargument is well summarized by Donald: "As far as I know HOTP/TOTP do not need anything backend specific and can be completely implemented using the standard library's hashlib. Is there a benefit to using our backends? Is there anything that we'd want to use the backends for at all? (Storing secrets in a HSM?).? Opinions welcome. :) -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Tue Feb 11 16:39:12 2014 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Tue, 11 Feb 2014 07:39:12 -0800 Subject: [Cryptography-dev] RSA key generation -- minimum key size? Message-ID: Hey all, The last major issue blocking landing RSA key generation is a discussion over whether or not to enforce a minimum key size for newly generated keys. I am advocating for requiring that key_size be >= 1024. Here is why: * Smaller keys are factorable (768 is known to be factored publicly, it's extremely likely even larger is factorable by nation states); there is basically no reason to use these keys. * PyCrypto enforces a 1024 minimum, which means there is no difficulty in porting applications; as there would be if we used a larger minimum * Loosening the check in the future is much easier, from a backwards compatibility perspective, then tightening it. Thus, 1024 seems like a reasonable balance of these concerns. How do other people feel? Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From terrycwk1994 at gmail.com Tue Feb 11 16:42:18 2014 From: terrycwk1994 at gmail.com (Terry Chia) Date: Tue, 11 Feb 2014 23:42:18 +0800 Subject: [Cryptography-dev] RSA key generation -- minimum key size? In-Reply-To: References: Message-ID: +1 on enforcing >=1024 bits. There is no sane reason to use smaller keys really. On Tuesday, February 11, 2014, Alex Gaynor wrote: > Hey all, > > The last major issue blocking landing RSA key generation is a discussion > over whether or not to enforce a minimum key size for newly generated keys. > > I am advocating for requiring that key_size be >= 1024. Here is why: > > * Smaller keys are factorable (768 is known to be factored publicly, it's > extremely likely even larger is factorable by nation states); there is > basically no reason to use these keys. > * PyCrypto enforces a 1024 minimum, which means there is no difficulty in > porting applications; as there would be if we used a larger minimum > * Loosening the check in the future is much easier, from a backwards > compatibility perspective, then tightening it. > > Thus, 1024 seems like a reasonable balance of these concerns. > > How do other people feel? > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarret.raim at RACKSPACE.COM Tue Feb 11 16:56:25 2014 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Tue, 11 Feb 2014 15:56:25 +0000 Subject: [Cryptography-dev] RSA key generation -- minimum key size? In-Reply-To: Message-ID: +1 on enforcing >= 1024 -- Jarret Raim @jarretraim From: Terry Chia Reply-To: "cryptography-dev at python.org" Date: Tuesday, February 11, 2014 at 9:42 AM To: "cryptography-dev at python.org" Subject: Re: [Cryptography-dev] RSA key generation -- minimum key size? +1 on enforcing >=1024 bits. There is no sane reason to use smaller keys really. On Tuesday, February 11, 2014, Alex Gaynor wrote: > Hey all, > > The last major issue blocking landing RSA key generation is a discussion over > whether or not to enforce a minimum key size for newly generated keys. > > I am advocating for requiring that key_size be >= 1024. Here is why: > > * Smaller keys are factorable (768 is known to be factored publicly, it's > extremely likely even larger is factorable by nation states); there is > basically no reason to use these keys. > * PyCrypto enforces a 1024 minimum, which means there is no difficulty in > porting applications; as there would be if we used a larger minimum > * Loosening the check in the future is much easier, from a backwards > compatibility perspective, then tightening it. > > Thus, 1024 seems like a reasonable balance of these concerns. > > How do other people feel? > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5611 bytes Desc: not available URL: From jean-paul at hybridcluster.com Tue Feb 11 16:52:02 2014 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Tue, 11 Feb 2014 10:52:02 -0500 Subject: [Cryptography-dev] RSA key generation -- minimum key size? In-Reply-To: References: Message-ID: <52FA4722.3020400@hybridcluster.com> On 02/11/2014 10:39 AM, Alex Gaynor wrote: > Hey all, > > The last major issue blocking landing RSA key generation is a > discussion over whether or not to enforce a minimum key size for newly > generated keys. > > I am advocating for requiring that key_size be >= 1024. Here is why: > > * Smaller keys are factorable (768 is known to be factored publicly, > it's extremely likely even larger is factorable by nation states); > there is basically no reason to use these keys. > * PyCrypto enforces a 1024 minimum, which means there is no difficulty > in porting applications; as there would be if we used a larger minimum > * Loosening the check in the future is much easier, from a backwards > compatibility perspective, then tightening it. > > Thus, 1024 seems like a reasonable balance of these concerns. > > How do other people feel? The pyOpenSSL test suite generates much smaller RSA keys (128, 384, 512, 576) because it's faster and the keys are never used for anything security related (they're just to verify key generation works). Of course pyOpenSSL doesn't use cryptography's RSA key generation APIs so this isn't a reason for cryptography not to enforce this limit. I wonder if anyone using cryptography will have any similar concerns about the performance of their test suite, though (on my laptop it takes 2ms to generate a 128 bit key and 35ms to generate a 1024 bit key). Regardless, this doesn't seem like a particularly awesome reason to allow small keys to be generated. I just thought it was worth mentioning so it could be explicitly disregarded. :) Jean-Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From _ at lvh.io Tue Feb 11 17:44:22 2014 From: _ at lvh.io (Laurens Van Houtven) Date: Tue, 11 Feb 2014 17:44:22 +0100 Subject: [Cryptography-dev] RSA key generation -- minimum key size? In-Reply-To: <52FA4722.3020400@hybridcluster.com> References: <52FA4722.3020400@hybridcluster.com> Message-ID: Hi, I don't think anyone disagrees that < 1024 bit keys are insecure. There's even a good chance 1024 bit keys are factorable if your adversary has enough dollars. It should definitely be hard to make such insecure keys. How about an "allow_insecure_key_sizes" flag; that's long and explicit and it means that people who really do want insecure RSA keys for whatever reason (good or bad) can get them. I'm +0 on making it impossible to do so; +1 on possible upon explicit request clearly marked as dangerous. hth lvh -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexs at prol.etari.at Tue Feb 11 17:20:16 2014 From: alexs at prol.etari.at (alexs) Date: Tue, 11 Feb 2014 16:20:16 +0000 Subject: [Cryptography-dev] =?utf-8?q?RSA_key_generation_--_minimum_key_si?= =?utf-8?b?emU/?= In-Reply-To: References: Message-ID: <8e9004cfc4d793bf5e8ed4ed84b665ff@prol.etari.at> I am fine with there being a lower bound, I just don't think 1024 is the right number. * 1024-bit is deprecated by every major standards body with an opinion on these things. * 1024-bit doesn't seem to actually provide the benefit you'd want from a lower bound of making it harder for users to end up with factorable keys. As Alex Gaynor points out, nation states can probably break 1024-bit keys anyway. * Smaller keys, in particular 768-bit (and even 512-bit until recently) signing keys are still in common usage in DKIM as they can be rotated frequently and the harm of an attack is much lower than in e.g. TLS. * Users coming from PyCrypto shouldn't be using 1024-bit keys. Is there an application we know about that having to use a higher minimum would actually cause problems? * This doesn't actually improve security much since we will still load much smaller keys from disk and also (presumably?) accept them when verifying signatures. * If this is about security, do we have to update this limit as research progresses? What happens to users relying on downstream packages in e.g. Debian? * This is hazmat, there are dinosaurs with laser guns in the documentation to warn you about this stuff. I think the limit should either be 512-bit because it's the smallest key size with any significant usage in the recent past so I doubt anyone would even notice it. Or it should be 2048-bit because that's what everyone actually recommends. 1024-bit seems to be the worst of both worlds. My preference is for 512-bit because I think this is the wrong place to be trying to improve security. The right place might be in something like a JSON Web Signatures or other higher level module where its more feasible to enable users to reject insecure keys at verification time. On 11.02.2014 15:39, Alex Gaynor wrote: > Hey all, > > The last major issue blocking landing RSA key generation is a discussion over whether or not to enforce a minimum key size for newly generated keys. > > I am advocating for requiring that key_size be >= 1024. Here is why: > > * Smaller keys are factorable (768 is known to be factored publicly, it's extremely likely even larger is factorable by nation states); there is basically no reason to use these keys. > * PyCrypto enforces a 1024 minimum, which means there is no difficulty in porting applications; as there would be if we used a larger minimum > * Loosening the check in the future is much easier, from a backwards compatibility perspective, then tightening it. > > Thus, 1024 seems like a reasonable balance of these concerns. > > How do other people feel? > Alex > > -- > > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Tue Feb 11 19:06:20 2014 From: donald at stufft.io (Donald Stufft) Date: Tue, 11 Feb 2014 13:06:20 -0500 Subject: [Cryptography-dev] RSA key generation -- minimum key size? In-Reply-To: <8e9004cfc4d793bf5e8ed4ed84b665ff@prol.etari.at> References: <8e9004cfc4d793bf5e8ed4ed84b665ff@prol.etari.at> Message-ID: <10BB1E27-664C-4D39-8C44-2196AC7D5B0B@stufft.io> On Feb 11, 2014, at 11:20 AM, alexs wrote: > I am fine with there being a lower bound, I just don't think 1024 is the right number. > > * 1024-bit is deprecated by every major standards body with an opinion on these things. > > * 1024-bit doesn't seem to actually provide the benefit you'd want from a lower bound of making it harder for users to end up with factorable keys. As Alex Gaynor points out, nation states can probably break 1024-bit keys anyway. > > * Smaller keys, in particular 768-bit (and even 512-bit until recently) signing keys are still in common usage in DKIM as they can be rotated frequently and the harm of an attack is much lower than in e.g. TLS. > > * Users coming from PyCrypto shouldn't be using 1024-bit keys. Is there an application we know about that having to use a higher minimum would actually cause problems? > > * This doesn't actually improve security much since we will still load much smaller keys from disk and also (presumably?) accept them when verifying signatures. > > * If this is about security, do we have to update this limit as research progresses? What happens to users relying on downstream packages in e.g. Debian? > > * This is hazmat, there are dinosaurs with laser guns in the documentation to warn you about this stuff. > > I think the limit should either be 512-bit because it's the smallest key size with any significant usage in the recent past so I doubt anyone would even notice it. Or it should be 2048-bit because that's what everyone actually recommends. 1024-bit seems to be the worst of both worlds. > > My preference is for 512-bit because I think this is the wrong place to be trying to improve security. The right place might be in something like a JSON Web Signatures or other higher level module where its more feasible to enable users to reject insecure keys at verification time. > > i also agree that this is the wrong level to be doing this in. High level API?s outside of the hazmat API can absolutely and should restrict key sizes. I don?t believe the low level APIs should. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From k at 77.fi Tue Feb 11 19:17:55 2014 From: k at 77.fi (Kimmo Parviainen-Jalanko) Date: Tue, 11 Feb 2014 20:17:55 +0200 Subject: [Cryptography-dev] RSA key generation -- minimum key size? In-Reply-To: <10BB1E27-664C-4D39-8C44-2196AC7D5B0B@stufft.io> References: <8e9004cfc4d793bf5e8ed4ed84b665ff@prol.etari.at> <10BB1E27-664C-4D39-8C44-2196AC7D5B0B@stufft.io> Message-ID: On Tuesday, February 11, 2014, Donald Stufft wrote: > > On Feb 11, 2014, at 11:20 AM, alexs > > wrote: > > I am fine with there being a lower bound, I just don't think 1024 is the > right number. > > * 1024-bit is deprecated by every major standards body with an opinion on > these things. > > * 1024-bit doesn't seem to actually provide the benefit you'd want from a > lower bound of making it harder for users to end up with factorable keys. > As Alex Gaynor points out, nation states can probably break 1024-bit keys > anyway. > > * Smaller keys, in particular 768-bit (and even 512-bit until recently) > signing keys are still in common usage in DKIM as they can be rotated > frequently and the harm of an attack is much lower than in e.g. TLS. > > * Users coming from PyCrypto shouldn't be using 1024-bit keys. Is there > an application we know about that having to use a higher minimum would > actually cause problems? > > * This doesn't actually improve security much since we will still load > much smaller keys from disk and also (presumably?) accept them when > verifying signatures. > > * If this is about security, do we have to update this limit as research > progresses? What happens to users relying on downstream packages in e.g. > Debian? > > * This is hazmat, there are dinosaurs with laser guns in the documentation > to warn you about this stuff. > > I think the limit should either be 512-bit because it's the smallest key > size with any significant usage in the recent past so I doubt anyone would > even notice it. Or it should be 2048-bit because that's what everyone > actually recommends. 1024-bit seems to be the worst of both worlds. > > My preference is for 512-bit because I think this is the wrong place to be > trying to improve security. The right place might be in something like a > JSON Web Signatures or other higher level module where its more feasible to > enable users to reject insecure keys at verification time. > > > i also agree that this is the wrong level to be doing this in. High level > API's outside of the hazmat API can absolutely and should restrict key > sizes. I don't believe the low level APIs should. > > Low level API shouldn't probably try to enforce hard limits on key sizes. However, I do think they should Raise a SecurityWarning (or smtg similar) or at least log/print a warning when using keys < 2048 bits. Also when generating keys, the default keysize should be 4k as it is the largest universally supported key size. Just my two cents (from a non-contributor for time being), << Kimvais > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dreid at dreid.org Tue Feb 11 19:42:36 2014 From: dreid at dreid.org (David Reid) Date: Tue, 11 Feb 2014 10:42:36 -0800 Subject: [Cryptography-dev] RSA key generation -- minimum key size? In-Reply-To: <8e9004cfc4d793bf5e8ed4ed84b665ff@prol.etari.at> References: <8e9004cfc4d793bf5e8ed4ed84b665ff@prol.etari.at> Message-ID: What some of the higher level recipe like things have to say about RSA key sizes: JWS[1]: "A 2048-bit or longer key length MUST be used with this algorithm." DKIM[2]: "Signers MUST use RSA keys of at least 1024 bits for long-lived keys." It then fails to define long-lived keys. But the basic idea is that you can rotate keys frequently to deal with weaknesses of smaller keys. OpenPGP[3]: "An implementation SHOULD NOT implement RSA keys of size less than 1024 bits." KeyCzar[4]: Smallest supported key size is 512 in C++ and Python implementations, with 2048 being the default. Smallest key size on Java is 1024 and default is 4096. That is just a quick survey, and is by no means comprehensive. But when we talk about enforcing key limits at a higher level these are the kinds of systems we're talking about implementing. Surprisingly, I don't find myself having a particularly strong opinion about limiting the key size at the hazmat layer. I do however find myself leaning slightly in favor of it because we don't have default values in hazmat, python's warnings are useless, and the cost of repainting the bike shed is so low. -David -- 1. http://tools.ietf.org/html/draft-jones-json-web-signature-04#section-6(Specifically 6.2) 2. http://tools.ietf.org/html/rfc6376#section-3.3.3 3. https://tools.ietf.org/html/rfc4880#section-13.5 4. https://code.google.com/p/keyczar/wiki/KeyczarSummary (this page is likely out of date.) On Tue, Feb 11, 2014 at 8:20 AM, alexs wrote: > I am fine with there being a lower bound, I just don't think 1024 is the > right number. > > * 1024-bit is deprecated by every major standards body with an opinion on > these things. > > * 1024-bit doesn't seem to actually provide the benefit you'd want from a > lower bound of making it harder for users to end up with factorable keys. > As Alex Gaynor points out, nation states can probably break 1024-bit keys > anyway. > > * Smaller keys, in particular 768-bit (and even 512-bit until recently) > signing keys are still in common usage in DKIM as they can be rotated > frequently and the harm of an attack is much lower than in e.g. TLS. > > * Users coming from PyCrypto shouldn't be using 1024-bit keys. Is there > an application we know about that having to use a higher minimum would > actually cause problems? > > * This doesn't actually improve security much since we will still load > much smaller keys from disk and also (presumably?) accept them when > verifying signatures. > > * If this is about security, do we have to update this limit as research > progresses? What happens to users relying on downstream packages in e.g. > Debian? > > * This is hazmat, there are dinosaurs with laser guns in the documentation > to warn you about this stuff. > > I think the limit should either be 512-bit because it's the smallest key > size with any significant usage in the recent past so I doubt anyone would > even notice it. Or it should be 2048-bit because that's what everyone > actually recommends. 1024-bit seems to be the worst of both worlds. > > My preference is for 512-bit because I think this is the wrong place to be > trying to improve security. The right place might be in something like a > JSON Web Signatures or other higher level module where its more feasible to > enable users to reject insecure keys at verification time. > > On 11.02.2014 15:39, Alex Gaynor wrote: > > Hey all, > > The last major issue blocking landing RSA key generation is a discussion > over whether or not to enforce a minimum key size for newly generated keys. > > I am advocating for requiring that key_size be >= 1024. Here is why: > > * Smaller keys are factorable (768 is known to be factored publicly, it's > extremely likely even larger is factorable by nation states); there is > basically no reason to use these keys. > * PyCrypto enforces a 1024 minimum, which means there is no difficulty in > porting applications; as there would be if we used a larger minimum > * Loosening the check in the future is much easier, from a backwards > compatibility perspective, then tightening it. > > Thus, 1024 seems like a reasonable balance of these concerns. > > How do other people feel? > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belchenko at gmail.com Tue Feb 18 15:13:42 2014 From: alexander.belchenko at gmail.com (Alexander Belchenko) Date: Tue, 18 Feb 2014 16:13:42 +0200 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 Message-ID: Hi, I started to write an email with request for help building cryptography on Windows for Python 3.3, but then I figured out how to get the desired result, so now I only want to share some knowledge and also provide you a build log in the case you're interested in compiler warnings. Also I'd like to know it built correctly, is there any easy-to-use unittest suite I can run? I see there tests package, but I'm not sure what is your method to run tests in your project? Obvioulsly `python3 -m unittest` does not work. My intent was to build cryptography library against static libs of OpenSSL because I had problems with running simple C code with OpenSSL dlls, I found on StackOverflow suggestion that only linking against static libraries would help. It does help for me. Here is openssl directories I've used: include: C:\OpenSSL-Win32\include lib: C:\OpenSSL-Win32\lib\VC\static My C code successfully linked against this set of libraries: 'libeay32MD', 'ssleay32MD', 'gdi32', 'user32', 'advapi32' So here is my steps similar to what you wrote on Installation page: https://cryptography.io/en/latest/installation/#on-windows "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 set LIB=C:\OpenSSL-Win32\lib\VC\static;%LIB% set INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE% C:\Python33\python setup.py install That wasn't enough because of set of libraries you need to link against. So I just changed settings in bindings.py: === modified file cryptography/hazmat/bindings/openssl/binding.py --- cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:18:03 +0000 +++ cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:54:26 +0000 @@ -92,7 +92,9 @@ if sys.platform != "win32": libraries = ["crypto", "ssl"] else: # pragma: no cover - libraries = ["libeay32", "ssleay32", "advapi32"] + libraries = ["libeay32MD", "ssleay32MD", + "gdi32", "user32", "advapi32", + "Ws2_32", "Crypt32"] cls.ffi, cls.lib = build_ffi(cls._module_prefix, cls._modules, _OSX_PRE_INCLUDE, _OSX_POST_INCLUDE, With the last change I was finally able to build cryptography python library. \o/ Attached is the build log in the case you want to see compiler errors. Some warnings catched my eye, like this: cryptography\hazmat\primitives\__pycache__\_cffi__xcd368b2dx4a8b9ec1.c(218) : warning C4244: '=' : conversion from 'unsigned __int64' to 'uint8_t', possible loss of data or cryptography\hazmat\bindings\__pycache__\_cffi__xabccc2b1x4bab9030.c(4386) : warning C4308: negative integral constant converted to unsigned type Probably you might know that everything is OK, I just wanted to test somehow my build is OK. Alexander. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.log Type: application/octet-stream Size: 15451 bytes Desc: not available URL: From paul.l.kehrer at gmail.com Tue Feb 18 15:24:35 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Tue, 18 Feb 2014 08:24:35 -0600 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 In-Reply-To: References: Message-ID: Thanks for the information, I don?t believe anyone has ever tried to do a static build on Windows before! Some of the codegen from cffi on the Windows side causes warnings that, to our knowledge, are not an issue. We definitely would like to be warning clean when compiling with cl.exe (as we are with clang/gcc on OS X and Linux). To run our test suite you should pip install -r dev-requirements.txt and then you can run py.test (or tox) to execute the tests. -Paul Kehrer On Tuesday, February 18, 2014 at 8:13 AM, Alexander Belchenko wrote: > Hi, > > I started to write an email with request for help building cryptography on Windows for Python 3.3, but then I figured out how to get the desired result, so now I only want to share some knowledge and also provide you a build log in the case you're interested in compiler warnings. > > Also I'd like to know it built correctly, is there any easy-to-use unittest suite I can run? I see there tests package, but I'm not sure what is your method to run tests in your project? Obvioulsly `python3 -m unittest` does not work. > > My intent was to build cryptography library against static libs of OpenSSL because I had problems with running simple C code with OpenSSL dlls, I found on StackOverflow suggestion that only linking against static libraries would help. It does help for me. > > Here is openssl directories I've used: > include: C:\OpenSSL-Win32\include > lib: C:\OpenSSL-Win32\lib\VC\static > > My C code successfully linked against this set of libraries: > 'libeay32MD', 'ssleay32MD', 'gdi32', 'user32', 'advapi32' > > So here is my steps similar to what you wrote on Installation page: > https://cryptography.io/en/latest/installation/#on-windows > > "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 > set LIB=C:\OpenSSL-Win32\lib\VC\static;%LIB% > set INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE% > C:\Python33\python setup.py install > > > That wasn't enough because of set of libraries you need to link against. So I just changed settings in bindings.py: > > > === modified file cryptography/hazmat/bindings/openssl/binding.py > > > --- cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:18:03 +0000 > > > +++ cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:54:26 +0000 > > > @@ -92,7 +92,9 @@ > > > if sys.platform != "win32": > > > libraries = ["crypto", "ssl"] > > > else: # pragma: no cover > > > - libraries = ["libeay32", "ssleay32", "advapi32"] > > > + libraries = ["libeay32MD", "ssleay32MD", > > > + "gdi32", "user32", "advapi32", > > > + "Ws2_32", "Crypt32"] > > > > > > cls.ffi, cls.lib = build_ffi(cls._module_prefix, cls._modules, > > > _OSX_PRE_INCLUDE, _OSX_POST_INCLUDE, > > > With the last change I was finally able to build cryptography python library. \o/ > > > > > > > > > Attached is the build log in the case you want to see compiler errors. > > Some warnings catched my eye, like this: > > cryptography\hazmat\primitives\__pycache__\_cffi__xcd368b2dx4a8b9ec1.c(218) : warning C4244: '=' : conversion from 'unsigned __int64' to 'uint8_t', possible loss of data > > or > > cryptography\hazmat\bindings\__pycache__\_cffi__xabccc2b1x4bab9030.c(4386) : warning C4308: negative integral constant converted to unsigned type > > Probably you might know that everything is OK, I just wanted to test somehow my build is OK. > > Alexander. > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > > Attachments: > - setup.log > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skeuomorf at gmail.com Wed Feb 19 09:39:59 2014 From: skeuomorf at gmail.com (skeuomorf) Date: Wed, 19 Feb 2014 10:39:59 +0200 Subject: [Cryptography-dev] DSA Message-ID: <53046DDF.60906@gmail.com> Concerning issue #230 "Add DSA", DSA has the following parameters: p: prime modulus of bit length L q: prime divisor of (p-1) of bit length N g: a generator of a subgroup of order q in the multiplicative group GF(P) where 1= strength(L,N) * Length of digital signature is 2q * Private signature key has a cryptoperiod of 1-3 years * "The security strength associated with the DSA digital signature process is no greater than the minimum of the security strength of the (L,N) pair and the security strength of the hash function that is employed." * "The same domain parameters (p, q, g) may be used for both digital signatures and key establishment. However, using different values for the generator g reduces the risk that key pairs generated for one purpose could be accidentally used (successfully) for another purpose." * A calculation of the inverse of k is required i.e. k^(-1) * (k, r, p, q, g) maybe pre computed What do you guys think cryptography's API should expose? Support for 0.9.8's validation process is non-negotiable as a user might validate a signature that was generated using the old standard. Should the users be allowed to generate the domain parameters? and the nonce? and store the private key and the nonce if it was precomputed?...etc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Wed Feb 19 18:30:03 2014 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Wed, 19 Feb 2014 09:30:03 -0800 Subject: [Cryptography-dev] 0.2 release Message-ID: Hi all, Unless there's any objection, it's my plan to do the 0.2 release tomorrow. This means that it looks like most of the RSA stuff will not land in time for the release. That's ok though, release early release often! My primary goal for this release is that pyOpenSSL's release will have everything it needs in the way of bindings and platform support and that we can get Windows wheels up. Given that, let's try to avoid landing any major things in the next day :-) Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Wed Feb 19 21:03:31 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Wed, 19 Feb 2014 14:03:31 -0600 Subject: [Cryptography-dev] 0.2 release In-Reply-To: References: Message-ID: +1 I?ve retargeted the RSA/DSA issues to third release for now, which leaves us with the FAQ PR left before we?ve closed out 0.2. On Wednesday, February 19, 2014 at 11:30 AM, Alex Gaynor wrote: > Hi all, > > Unless there's any objection, it's my plan to do the 0.2 release tomorrow. This means that it looks like most of the RSA stuff will not land in time for the release. > > That's ok though, release early release often! My primary goal for this release is that pyOpenSSL's release will have everything it needs in the way of bindings and platform support and that we can get Windows wheels up. > > Given that, let's try to avoid landing any major things in the next day :-) > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belchenko at gmail.com Thu Feb 20 09:15:29 2014 From: alexander.belchenko at gmail.com (Alexander Belchenko) Date: Thu, 20 Feb 2014 10:15:29 +0200 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 In-Reply-To: References: Message-ID: IMO, static build is more appropriate for Windows users. That means user doesn't need to additionally install openssl binaries. E.g. CPython itself (ssl standard library) has openssl linked statically AFAIK. I suspect this is also to avoid "dll hell". E.g. win64 binary installation of OpenSSL has dlls with the exactly same names as win32 installation: libeay32.dll and ssleay32.dll. I suspect there is no way to have both versions co-exists as system-wide dll libraries. I won't ask you to change your build scripts to use static libs on Windows, but I'd like to help with a patch to make this supported in some way. I'm going to try to build whl (wheel) file for cryptography with static openssl libs for both 32/64. I'm mostly interested in working pyOpenSSL library for my project, actually. But it depends on `cryptography`. Any hints on approach to provide support for static build for Windows? Probably some sort of config option needed? I'm not sure how it should work with pip and wheels. 2014-02-18 16:24 GMT+02:00 Paul Kehrer : > Thanks for the information, I don?t believe anyone has ever tried to do a > static build on Windows before! > > Some of the codegen from cffi on the Windows side causes warnings that, to > our knowledge, are not an issue. We definitely would like to be warning > clean when compiling with cl.exe (as we are with clang/gcc on OS X and > Linux). > > To run our test suite you should pip install -r dev-requirements.txt and > then you can run py.test (or tox) to execute the tests. > > -Paul Kehrer > > On Tuesday, February 18, 2014 at 8:13 AM, Alexander Belchenko wrote: > > Hi, > > I started to write an email with request for help building cryptography on > Windows for Python 3.3, but then I figured out how to get the desired > result, so now I only want to share some knowledge and also provide you a > build log in the case you're interested in compiler warnings. > > Also I'd like to know it built correctly, is there any easy-to-use > unittest suite I can run? I see there tests package, but I'm not sure what > is your method to run tests in your project? Obvioulsly `python3 -m > unittest` does not work. > > My intent was to build cryptography library against static libs of OpenSSL > because I had problems with running simple C code with OpenSSL dlls, I > found on StackOverflow suggestion that only linking against static > libraries would help. It does help for me. > > Here is openssl directories I've used: > include: C:\OpenSSL-Win32\include > lib: C:\OpenSSL-Win32\lib\VC\static > > My C code successfully linked against this set of libraries: > 'libeay32MD', 'ssleay32MD', 'gdi32', 'user32', 'advapi32' > > So here is my steps similar to what you wrote on Installation page: > https://cryptography.io/en/latest/installation/#on-windows > > "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 > set LIB=C:\OpenSSL-Win32\lib\VC\static;%LIB% > set INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE% > C:\Python33\python setup.py install > > That wasn't enough because of set of libraries you need to link against. > So I just changed settings in bindings.py: > > === modified file cryptography/hazmat/bindings/openssl/binding.py > > --- cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:18:03 > +0000 > > +++ cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:54:26 > +0000 > > @@ -92,7 +92,9 @@ > > if sys.platform != "win32": > > libraries = ["crypto", "ssl"] > > else: # pragma: no cover > > - libraries = ["libeay32", "ssleay32", "advapi32"] > > + libraries = ["libeay32MD", "ssleay32MD", > > + "gdi32", "user32", "advapi32", > > + "Ws2_32", "Crypt32"] > > cls.ffi, cls.lib = build_ffi(cls._module_prefix, cls._modules, > > _OSX_PRE_INCLUDE, _OSX_POST_INCLUDE, > > With the last change I was finally able to build cryptography python > library. \o/ > > > Attached is the build log in the case you want to see compiler errors. > > Some warnings catched my eye, like this: > > cryptography\hazmat\primitives\__pycache__\_cffi__xcd368b2dx4a8b9ec1.c(218) > : warning C4244: '=' : conversion from 'unsigned __int64' to 'uint8_t', > possible loss of data > > or > > cryptography\hazmat\bindings\__pycache__\_cffi__xabccc2b1x4bab9030.c(4386) > : warning C4308: negative integral constant converted to unsigned type > > Probably you might know that everything is OK, I just wanted to test > somehow my build is OK. > > Alexander. > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > Attachments: > - setup.log > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Thu Feb 20 16:30:30 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Thu, 20 Feb 2014 09:30:30 -0600 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 In-Reply-To: References: Message-ID: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> We will be offering wheels (32-bit) for the 0.2 release (forthcoming today), but as you noted they still require the installation of OpenSSL independently. This decision was originally made because we didn?t want to get in the business of feeling like we needed to rev cryptography whenever OpenSSL did a security release, but maybe we need to revisit that position. Everyone, time to express some opinions! -Paul On Thursday, February 20, 2014 at 2:15 AM, Alexander Belchenko wrote: > IMO, static build is more appropriate for Windows users. That means user doesn't need to additionally install openssl binaries. > > E.g. CPython itself (ssl standard library) has openssl linked statically AFAIK. I suspect this is also to avoid "dll hell". E.g. win64 binary installation of OpenSSL has dlls with the exactly same names as win32 installation: libeay32.dll and ssleay32.dll. I suspect there is no way to have both versions co-exists as system-wide dll libraries. > > I won't ask you to change your build scripts to use static libs on Windows, but I'd like to help with a patch to make this supported in some way. I'm going to try to build whl (wheel) file for cryptography with static openssl libs for both 32/64. I'm mostly interested in working pyOpenSSL library for my project, actually. But it depends on `cryptography`. > > Any hints on approach to provide support for static build for Windows? Probably some sort of config option needed? I'm not sure how it should work with pip and wheels. > > > 2014-02-18 16:24 GMT+02:00 Paul Kehrer : > > Thanks for the information, I don?t believe anyone has ever tried to do a static build on Windows before! > > > > Some of the codegen from cffi on the Windows side causes warnings that, to our knowledge, are not an issue. We definitely would like to be warning clean when compiling with cl.exe (as we are with clang/gcc on OS X and Linux). > > > > To run our test suite you should pip install -r dev-requirements.txt and then you can run py.test (or tox) to execute the tests. > > > > -Paul Kehrer > > > > On Tuesday, February 18, 2014 at 8:13 AM, Alexander Belchenko wrote: > > > > > > > > > Hi, > > > > > > I started to write an email with request for help building cryptography on Windows for Python 3.3, but then I figured out how to get the desired result, so now I only want to share some knowledge and also provide you a build log in the case you're interested in compiler warnings. > > > > > > Also I'd like to know it built correctly, is there any easy-to-use unittest suite I can run? I see there tests package, but I'm not sure what is your method to run tests in your project? Obvioulsly `python3 -m unittest` does not work. > > > > > > My intent was to build cryptography library against static libs of OpenSSL because I had problems with running simple C code with OpenSSL dlls, I found on StackOverflow suggestion that only linking against static libraries would help. It does help for me. > > > > > > Here is openssl directories I've used: > > > include: C:\OpenSSL-Win32\include > > > lib: C:\OpenSSL-Win32\lib\VC\static > > > > > > My C code successfully linked against this set of libraries: > > > 'libeay32MD', 'ssleay32MD', 'gdi32', 'user32', 'advapi32' > > > > > > So here is my steps similar to what you wrote on Installation page: > > > https://cryptography.io/en/latest/installation/#on-windows > > > > > > "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 > > > set LIB=C:\OpenSSL-Win32\lib\VC\static;%LIB% > > > set INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE% > > > C:\Python33\python setup.py install > > > > > > > > > That wasn't enough because of set of libraries you need to link against. So I just changed settings in bindings.py: > > > > > > > > > === modified file cryptography/hazmat/bindings/openssl/binding.py > > > > > > > > > --- cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:18:03 +0000 > > > > > > > > > +++ cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:54:26 +0000 > > > > > > > > > @@ -92,7 +92,9 @@ > > > > > > > > > if sys.platform != "win32": > > > > > > > > > libraries = ["crypto", "ssl"] > > > > > > > > > else: # pragma: no cover > > > > > > > > > - libraries = ["libeay32", "ssleay32", "advapi32"] > > > > > > > > > + libraries = ["libeay32MD", "ssleay32MD", > > > > > > > > > + "gdi32", "user32", "advapi32", > > > > > > > > > + "Ws2_32", "Crypt32"] > > > > > > > > > > > > > > > > > > cls.ffi, cls.lib = build_ffi(cls._module_prefix, cls._modules, > > > > > > > > > _OSX_PRE_INCLUDE, _OSX_POST_INCLUDE, > > > > > > > > > With the last change I was finally able to build cryptography python library. \o/ > > > > > > > > > > > > > > > > > > > > > > > > > > > Attached is the build log in the case you want to see compiler errors. > > > > > > Some warnings catched my eye, like this: > > > > > > cryptography\hazmat\primitives\__pycache__\_cffi__xcd368b2dx4a8b9ec1.c(218) : warning C4244: '=' : conversion from 'unsigned __int64' to 'uint8_t', possible loss of data > > > > > > or > > > > > > cryptography\hazmat\bindings\__pycache__\_cffi__xabccc2b1x4bab9030.c(4386) : warning C4308: negative integral constant converted to unsigned type > > > > > > Probably you might know that everything is OK, I just wanted to test somehow my build is OK. > > > > > > Alexander. > > > > > > _______________________________________________ > > > Cryptography-dev mailing list > > > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > > > > > > > > > > > > Attachments: > > > - setup.log > > > > > > > > > > > > > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belchenko at gmail.com Thu Feb 20 16:55:28 2014 From: alexander.belchenko at gmail.com (Alexander Belchenko) Date: Thu, 20 Feb 2014 17:55:28 +0200 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 In-Reply-To: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> References: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> Message-ID: I would be happy to just have some knob to be able to build binaries with static libs. 2014-02-20 17:30 GMT+02:00 Paul Kehrer : > We will be offering wheels (32-bit) for the 0.2 release (forthcoming > today), but as you noted they still require the installation of OpenSSL > independently. This decision was originally made because we didn?t want to > get in the business of feeling like we needed to rev cryptography whenever > OpenSSL did a security release, but maybe we need to revisit that position. > > Everyone, time to express some opinions! > > -Paul > > On Thursday, February 20, 2014 at 2:15 AM, Alexander Belchenko wrote: > > IMO, static build is more appropriate for Windows users. That means user > doesn't need to additionally install openssl binaries. > > E.g. CPython itself (ssl standard library) has openssl linked statically > AFAIK. I suspect this is also to avoid "dll hell". E.g. win64 binary > installation of OpenSSL has dlls with the exactly same names as win32 > installation: libeay32.dll and ssleay32.dll. I suspect there is no way to > have both versions co-exists as system-wide dll libraries. > > I won't ask you to change your build scripts to use static libs on > Windows, but I'd like to help with a patch to make this supported in some > way. I'm going to try to build whl (wheel) file for cryptography with > static openssl libs for both 32/64. I'm mostly interested in working > pyOpenSSL library for my project, actually. But it depends on > `cryptography`. > > Any hints on approach to provide support for static build for Windows? > Probably some sort of config option needed? I'm not sure how it should work > with pip and wheels. > > > 2014-02-18 16:24 GMT+02:00 Paul Kehrer : > > Thanks for the information, I don?t believe anyone has ever tried to do a > static build on Windows before! > > Some of the codegen from cffi on the Windows side causes warnings that, to > our knowledge, are not an issue. We definitely would like to be warning > clean when compiling with cl.exe (as we are with clang/gcc on OS X and > Linux). > > To run our test suite you should pip install -r dev-requirements.txt and > then you can run py.test (or tox) to execute the tests. > > -Paul Kehrer > > On Tuesday, February 18, 2014 at 8:13 AM, Alexander Belchenko wrote: > > Hi, > > I started to write an email with request for help building cryptography on > Windows for Python 3.3, but then I figured out how to get the desired > result, so now I only want to share some knowledge and also provide you a > build log in the case you're interested in compiler warnings. > > Also I'd like to know it built correctly, is there any easy-to-use > unittest suite I can run? I see there tests package, but I'm not sure what > is your method to run tests in your project? Obvioulsly `python3 -m > unittest` does not work. > > My intent was to build cryptography library against static libs of OpenSSL > because I had problems with running simple C code with OpenSSL dlls, I > found on StackOverflow suggestion that only linking against static > libraries would help. It does help for me. > > Here is openssl directories I've used: > include: C:\OpenSSL-Win32\include > lib: C:\OpenSSL-Win32\lib\VC\static > > My C code successfully linked against this set of libraries: > 'libeay32MD', 'ssleay32MD', 'gdi32', 'user32', 'advapi32' > > So here is my steps similar to what you wrote on Installation page: > https://cryptography.io/en/latest/installation/#on-windows > > "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 > set LIB=C:\OpenSSL-Win32\lib\VC\static;%LIB% > set INCLUDE=C:\OpenSSL-Win32\include;%INCLUDE% > C:\Python33\python setup.py install > > That wasn't enough because of set of libraries you need to link against. > So I just changed settings in bindings.py: > > === modified file cryptography/hazmat/bindings/openssl/binding.py > > --- cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:18:03 > +0000 > > +++ cryptography/hazmat/bindings/openssl/binding.py 2014-02-18 13:54:26 > +0000 > > @@ -92,7 +92,9 @@ > > if sys.platform != "win32": > > libraries = ["crypto", "ssl"] > > else: # pragma: no cover > > - libraries = ["libeay32", "ssleay32", "advapi32"] > > + libraries = ["libeay32MD", "ssleay32MD", > > + "gdi32", "user32", "advapi32", > > + "Ws2_32", "Crypt32"] > > cls.ffi, cls.lib = build_ffi(cls._module_prefix, cls._modules, > > _OSX_PRE_INCLUDE, _OSX_POST_INCLUDE, > > With the last change I was finally able to build cryptography python > library. \o/ > > > Attached is the build log in the case you want to see compiler errors. > > Some warnings catched my eye, like this: > > cryptography\hazmat\primitives\__pycache__\_cffi__xcd368b2dx4a8b9ec1.c(218) > : warning C4244: '=' : conversion from 'unsigned __int64' to 'uint8_t', > possible loss of data > > or > > cryptography\hazmat\bindings\__pycache__\_cffi__xabccc2b1x4bab9030.c(4386) > : warning C4308: negative integral constant converted to unsigned type > > Probably you might know that everything is OK, I just wanted to test > somehow my build is OK. > > Alexander. > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > Attachments: > - setup.log > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-paul at hybridcluster.com Thu Feb 20 16:45:20 2014 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Thu, 20 Feb 2014 10:45:20 -0500 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 In-Reply-To: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> References: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> Message-ID: <53062310.8010106@hybridcluster.com> On 02/20/2014 10:30 AM, Paul Kehrer wrote: > We will be offering wheels (32-bit) for the 0.2 release (forthcoming > today), but as you noted they still require the installation of > OpenSSL independently. This decision was originally made because we > didn't want to get in the business of feeling like we needed to rev > cryptography whenever OpenSSL did a security release, but maybe we > need to revisit that position. > > Everyone, time to express some opinions! The average end user will probably find this to be a significant road block. This is particularly true if the failure mode for OpenSSL not being installed is a random implementation-specific traceback (perhaps one that gets thrown away because the Windows GUI program has no console). One solution to this is for the application developer to bundle everything - Python, cryptography, OpenSSL, their own application, code, etc. For this solution, it doesn't really matter what cryptography does because cryptography's packaging efforts will mostly be ignored (maybe not completely? perhaps having incomplete binary wheels for Windows makes the packager's life easier - I'm not sure). The other solution is for the meager Python installation management tools (easy_install and pip) to actually work. This seems like the solution where wheels (or, sorry, eggs) are more relevant. If /pip install mycryptoapp/ actually produces a working application then *maybe* that's a tolerable experience for an average end user on Windows (considering it requires running commands in a console, I'm not so sure - but maybe pip will have a GUI someday). If /pip install mycryptoapp/ appears to succeed but produces a broken installation that fails with random tracebacks, there's basically no way any end users on Windows are going to benefit. Jean-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From alexander.belchenko at gmail.com Thu Feb 20 17:25:55 2014 From: alexander.belchenko at gmail.com (Alexander Belchenko) Date: Thu, 20 Feb 2014 18:25:55 +0200 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 In-Reply-To: <53062310.8010106@hybridcluster.com> References: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> <53062310.8010106@hybridcluster.com> Message-ID: I'd like to add some info about building/installing cryptograhy: I did not succeed initially to compile it with plain `python setup.py install` or `python setup.py build_ext`, probably because I did not put openssl dlls to system folder (there is corresponding choice during openssl binaries install). Maybe that was my mistake. 2014-02-20 17:45 GMT+02:00 Jean-Paul Calderone : > On 02/20/2014 10:30 AM, Paul Kehrer wrote: > > We will be offering wheels (32-bit) for the 0.2 release (forthcoming > today), but as you noted they still require the installation of OpenSSL > independently. This decision was originally made because we didn?t want to > get in the business of feeling like we needed to rev cryptography whenever > OpenSSL did a security release, but maybe we need to revisit that position. > > Everyone, time to express some opinions! > > > The average end user will probably find this to be a significant road > block. This is particularly true if the failure mode for OpenSSL not being > installed is a random implementation-specific traceback (perhaps one that > gets thrown away because the Windows GUI program has no console). > > One solution to this is for the application developer to bundle everything > - Python, cryptography, OpenSSL, their own application, code, etc. For > this solution, it doesn't really matter what cryptography does because > cryptography's packaging efforts will mostly be ignored (maybe not > completely? perhaps having incomplete binary wheels for Windows makes the > packager's life easier - I'm not sure). > > The other solution is for the meager Python installation management tools > (easy_install and pip) to actually work. This seems like the solution > where wheels (or, sorry, eggs) are more relevant. If *pip install > mycryptoapp* actually produces a working application then *maybe* that's > a tolerable experience for an average end user on Windows (considering it > requires running commands in a console, I'm not so sure - but maybe pip > will have a GUI someday). > > If *pip install mycryptoapp* appears to succeed but produces a broken > installation that fails with random tracebacks, there's basically no way > any end users on Windows are going to benefit. > > Jean-Paul > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khabkr at yahoo.com Thu Feb 20 17:43:43 2014 From: khabkr at yahoo.com (Khalid [KAB]) Date: Thu, 20 Feb 2014 08:43:43 -0800 (PST) Subject: [Cryptography-dev] Building on Windows 7, 64x Message-ID: <1392914623.54412.YahooMailNeo@web125704.mail.ne1.yahoo.com> Hello all. I sent this sometime ago, but I don't know why it is not showing in the mail archives. Seeing the discussion about building on Windows, I am re-sending this, maybe it helps someone. Congratulations on the first release. Given the nature of the package, I opted to build everything from source. I started with openssl-1.0.0l and once that was built and installed, I set? the include and lib environment variables for cryptography's build process to use. It turns out, however, that the openssl build creates two libraries: libeay32.lib and ssleay32.lib. This of course cause the build process of cryptography to fail since it cannot find crypto.lib and ssl.lib. But since I've come to know that libeay32.lib is crypto.lib and likewise ssleay32.lib is ssl.lib, I copied the original libraries (libeay32.lib and ssleay32.lib) to the same directory they were installed in by the openssl installation process and renamed them crypto.lib and ssl.lib respectively. This made cryptography's build complete successfully and the package was installed without problems. Here is the summary output of py.test: =================================== ERRORS ==================================== ____________________ ERROR collecting tests/test_fernet.py ____________________ tests\test_fernet.py:40: in >?? class TestFernet(object): tests\test_fernet.py:42: in TestFernet >?????????? ("secret", "now", "iv", "src", "token"), "generate.json", tests\test_fernet.py:32: in json_parametrize >?????? with open(path) as f: E?????????? IOError: [Errno 2] No such file or directory: 'J:\\projs\\cryptograp hy-0.1\\tests\\vectors\\fernet\\generate.json' =========== 15473 passed, 47261 skipped, 1 error in 291.69 seconds ============ I hope someone will find this useful. Khalid From glyph at twistedmatrix.com Fri Feb 21 02:50:40 2014 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Thu, 20 Feb 2014 17:50:40 -0800 Subject: [Cryptography-dev] Building cryptography on Windows for Python 3.3 In-Reply-To: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> References: <02AE2F5108BB429AA4B7A4F1657F6BAA@gmail.com> Message-ID: On Feb 20, 2014, at 7:30 AM, Paul Kehrer wrote: > Everyone, time to express some opinions! Getting OpenSSL installed on Windows is (A) a pain, and (B) highly unlikely even for expert users to manage to set up for automatic updates. (The fellow who kindly provides the binaries doesn't have auto-updates because OpenSSL's API, to say nothing of its ABI, is basically unstable, so they can't issue arbitrary updates.) I understand not wanting to rev builds for every new release of OpenSSL, but the solution to that should be eventually obviating the OpenSSL dependency entirely by building a backend that uses a platform-specific Windows backend, one that will get updated through normal platform updates. In the meanwhile, doing build revs occasionally is probably preferable, and even if the PyCA is not super diligent about doing this, it'll still, practically speaking, get updated more often than hand-installed OpenSSL on an end user's system. Users savvy enough to do their own updates can always still build from source themselves. -g -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4124 bytes Desc: not available URL: From alexander.belchenko at gmail.com Fri Feb 21 08:24:29 2014 From: alexander.belchenko at gmail.com (Alexander Belchenko) Date: Fri, 21 Feb 2014 09:24:29 +0200 Subject: [Cryptography-dev] Building on Windows 7, 64x In-Reply-To: <1392914623.54412.YahooMailNeo@web125704.mail.ne1.yahoo.com> References: <1392914623.54412.YahooMailNeo@web125704.mail.ne1.yahoo.com> Message-ID: Khalid, recent openssl bindings has that code: # OpenSSL goes by a different library name on different operating # systems. if sys.platform != "win32": libraries = ["crypto", "ssl"] else: # pragma: no cover libraries = ["libeay32", "ssleay32", "advapi32"] So your problem with different library naming is actually addressed. HTH 2014-02-20 18:43 GMT+02:00 Khalid [KAB] : > Hello all. > > I sent this sometime ago, but I don't know why it is not showing in the > mail archives. Seeing the discussion about building on Windows, I am > re-sending this, maybe it helps someone. > > > Congratulations on the first release. > > Given the nature of the package, I opted to build everything from source. > I started with openssl-1.0.0l and once that was built and installed, I set > the include and lib environment variables for cryptography's build process > to use. > > It turns out, however, that the openssl build creates two libraries: > libeay32.lib and ssleay32.lib. This of course cause the build process of > cryptography to fail since it cannot find crypto.lib and ssl.lib. > > But since I've come to know that libeay32.lib is crypto.lib and likewise > ssleay32.lib is ssl.lib, I copied the original libraries (libeay32.lib and > ssleay32.lib) to the same directory they were installed in by the openssl > installation process and renamed them crypto.lib and ssl.lib respectively. > > This made cryptography's build complete successfully and the package was > installed without problems. Here is the summary output of py.test: > > =================================== ERRORS > ==================================== > ____________________ ERROR collecting tests/test_fernet.py > ____________________ > tests\test_fernet.py:40: in > > class TestFernet(object): > tests\test_fernet.py:42: in TestFernet > > ("secret", "now", "iv", "src", "token"), "generate.json", > tests\test_fernet.py:32: in json_parametrize > > with open(path) as f: > E IOError: [Errno 2] No such file or directory: > 'J:\\projs\\cryptograp > hy-0.1\\tests\\vectors\\fernet\\generate.json' > =========== 15473 passed, 47261 skipped, 1 error in 291.69 seconds > ============ > > > I hope someone will find this useful. > > Khalid > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-paul at hybridcluster.com Sat Feb 22 18:34:18 2014 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Sat, 22 Feb 2014 12:34:18 -0500 Subject: [Cryptography-dev] Cryptography_add_osrandom_engine failure? Message-ID: <5308DF9A.80605@hybridcluster.com> Hi all, Does anyone know why cryptography.hazmat.bindings.openssl.binding.Binding has started to start failing on assert res == 1? This seems to indicate that Cryptography_add_osrandom_engine is failing. pyOpenSSL test suite on travis-ci has started failing because of this. For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 Jean-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From alex.gaynor at gmail.com Sat Feb 22 18:37:01 2014 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 22 Feb 2014 11:37:01 -0600 Subject: [Cryptography-dev] Cryptography_add_osrandom_engine failure? In-Reply-To: <5308DF9A.80605@hybridcluster.com> References: <5308DF9A.80605@hybridcluster.com> Message-ID: This is a bug in 0.2.0, it only affects users of `setup.py test` (not technically true, but ...). We've landed a fix on master, and we're looking at doing an 0.2.1 release shortly to resolve it. https://github.com/pyca/cryptography/commit/26084d8c15fe631febf5d58691eb2b7f1533460fis the commit that fixes it. Alex On Sat, Feb 22, 2014 at 11:34 AM, Jean-Paul Calderone < jean-paul at hybridcluster.com> wrote: > Hi all, > > Does anyone know why cryptography.hazmat.bindings.openssl.binding.Bindinghas started to start failing on assert > res == 1? This seems to indicate that Cryptography_add_osrandom_engineis failing. > > pyOpenSSL test suite on travis-ci has started failing because of this. > For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 > > Jean-Paul > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Sat Feb 22 18:38:05 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sat, 22 Feb 2014 11:38:05 -0600 Subject: [Cryptography-dev] Cryptography_add_osrandom_engine failure? In-Reply-To: <5308DF9A.80605@hybridcluster.com> References: <5308DF9A.80605@hybridcluster.com> Message-ID: This is caused by cryptography being imported twice via different paths when it is installed via setuptools in python setup.py test. This PR (https://github.com/pyca/cryptography/pull/660) fixed the problem in trunk, but we need to do a 0.2.1 release to resolve it for pip installs. The release has been held up a bit since this project has not had to do a release off anything but master to this point. The current proposal is to do the following: * Branch off v0.2 tag and push to pyca/cryptography * submit #660 as another PR against that tag, review it & merge it * release off the branch On Saturday, February 22, 2014 at 11:34 AM, Jean-Paul Calderone wrote: > Hi all, > > Does anyone know why cryptography.hazmat.bindings.openssl.binding.Binding has started to start failing on assert res == 1? This seems to indicate that Cryptography_add_osrandom_engine is failing. > > pyOpenSSL test suite on travis-ci has started failing because of this. For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 > > Jean-Paul > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.gaynor at gmail.com Sat Feb 22 18:43:11 2014 From: alex.gaynor at gmail.com (Alex Gaynor) Date: Sat, 22 Feb 2014 11:43:11 -0600 Subject: [Cryptography-dev] Cryptography_add_osrandom_engine failure? In-Reply-To: References: <5308DF9A.80605@hybridcluster.com> Message-ID: +1 on making an 0.2.x branch and doing a release off of that. Can I bribe you to run the release Paul? Alex On Feb 22, 2014 11:38 AM, "Paul Kehrer" wrote: > This is caused by cryptography being imported twice via different paths > when it is installed via setuptools in python setup.py test. This PR ( > https://github.com/pyca/cryptography/pull/660) fixed the problem in > trunk, but we need to do a 0.2.1 release to resolve it for pip installs. > > The release has been held up a bit since this project has not had to do a > release off anything but master to this point. The current proposal is to > do the following: > > * Branch off v0.2 tag and push to pyca/cryptography > * submit #660 as another PR against that tag, review it & merge it > * release off the branch > > On Saturday, February 22, 2014 at 11:34 AM, Jean-Paul Calderone wrote: > > Hi all, > > Does anyone know why cryptography.hazmat.bindings.openssl.binding.Bindinghas started to start failing on assert > res == 1? This seems to indicate that Cryptography_add_osrandom_engineis failing. > > pyOpenSSL test suite on travis-ci has started failing because of this. > For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 > > Jean-Paul > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.l.kehrer at gmail.com Sat Feb 22 18:45:14 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sat, 22 Feb 2014 11:45:14 -0600 Subject: [Cryptography-dev] Cryptography_add_osrandom_engine failure? In-Reply-To: References: <5308DF9A.80605@hybridcluster.com> Message-ID: <2A9123CDC156416BA15EFFB481E85BD1@gmail.com> Okay, I?ll start working on this now. On Saturday, February 22, 2014 at 11:43 AM, Alex Gaynor wrote: > +1 on making an 0.2.x branch and doing a release off of that. Can I bribe you to run the release Paul? > > Alex > On Feb 22, 2014 11:38 AM, "Paul Kehrer" wrote: > > This is caused by cryptography being imported twice via different paths when it is installed via setuptools in python setup.py test. This PR (https://github.com/pyca/cryptography/pull/660) fixed the problem in trunk, but we need to do a 0.2.1 release to resolve it for pip installs. > > > > The release has been held up a bit since this project has not had to do a release off anything but master to this point. The current proposal is to do the following: > > > > * Branch off v0.2 tag and push to pyca/cryptography > > * submit #660 as another PR against that tag, review it & merge it > > * release off the branch > > > > On Saturday, February 22, 2014 at 11:34 AM, Jean-Paul Calderone wrote: > > > > > Hi all, > > > > > > Does anyone know why cryptography.hazmat.bindings.openssl.binding.Binding has started to start failing on assert res == 1? This seems to indicate that Cryptography_add_osrandom_engine is failing. > > > > > > pyOpenSSL test suite on travis-ci has started failing because of this. For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 > > > > > > Jean-Paul > > > > > > _______________________________________________ > > > Cryptography-dev mailing list > > > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > > > > > > > > > > > > > > _______________________________________________ > > Cryptography-dev mailing list > > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-paul at hybridcluster.com Sat Feb 22 18:37:39 2014 From: jean-paul at hybridcluster.com (Jean-Paul Calderone) Date: Sat, 22 Feb 2014 12:37:39 -0500 Subject: [Cryptography-dev] Cryptography_add_osrandom_engine failure? In-Reply-To: References: <5308DF9A.80605@hybridcluster.com> Message-ID: <5308E063.3090707@hybridcluster.com> On 02/22/2014 12:37 PM, Alex Gaynor wrote: > This is a bug in 0.2.0, it only affects users of `setup.py test` (not > technically true, but ...). We've landed a fix on master, and we're > looking at doing an 0.2.1 release shortly to resolve it. > > https://github.com/pyca/cryptography/commit/26084d8c15fe631febf5d58691eb2b7f1533460f > is the commit that fixes it. > > Alex > Ah. Thanks. Jean-Paul > > On Sat, Feb 22, 2014 at 11:34 AM, Jean-Paul Calderone > > wrote: > > Hi all, > > Does anyone know why > cryptography.hazmat.bindings.openssl.binding.Binding has started > to start failing on assert res == 1? This seems to indicate that > Cryptography_add_osrandom_engine is failing. > > pyOpenSSL test suite on travis-ci has started failing because of > this. For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 > > Jean-Paul > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From paul.l.kehrer at gmail.com Sat Feb 22 23:00:06 2014 From: paul.l.kehrer at gmail.com (Paul Kehrer) Date: Sat, 22 Feb 2014 16:00:06 -0600 Subject: [Cryptography-dev] Cryptography_add_osrandom_engine failure? In-Reply-To: <5308E063.3090707@hybridcluster.com> References: <5308DF9A.80605@hybridcluster.com> <5308E063.3090707@hybridcluster.com> Message-ID: <31ABBB4B45344E5BACC14EA5BFDF0F3E@gmail.com> 0.2.1 has now been released. Jean-Paul, this should resolve your CI problems for PyOpenSSL. -Paul On Saturday, February 22, 2014 at 11:37 AM, Jean-Paul Calderone wrote: > On 02/22/2014 12:37 PM, Alex Gaynor wrote: > > This is a bug in 0.2.0, it only affects users of `setup.py test` (not technically true, but ...). We've landed a fix on master, and we're looking at doing an 0.2.1 release shortly to resolve it. > > > > https://github.com/pyca/cryptography/commit/26084d8c15fe631febf5d58691eb2b7f1533460f is the commit that fixes it. > > > > Alex > > > Ah. Thanks. > > Jean-Paul > > > > > On Sat, Feb 22, 2014 at 11:34 AM, Jean-Paul Calderone wrote: > > > Hi all, > > > > > > Does anyone know why cryptography.hazmat.bindings.openssl.binding.Binding has started to start failing on assert res == 1? This seems to indicate that Cryptography_add_osrandom_engine is failing. > > > > > > pyOpenSSL test suite on travis-ci has started failing because of this. For example, https://travis-ci.org/pyca/pyopenssl/jobs/19393936 > > > > > > Jean-Paul > > > > > > > > > _______________________________________________ > > > Cryptography-dev mailing list > > > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > > > https://mail.python.org/mailman/listinfo/cryptography-dev > > > > > > > > > > > -- > > "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > > "The people's good is the highest law." -- Cicero > > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > > > _______________________________________________ Cryptography-dev mailing list Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) https://mail.python.org/mailman/listinfo/cryptography-dev > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org (mailto:Cryptography-dev at python.org) > https://mail.python.org/mailman/listinfo/cryptography-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From exarkun at twistedmatrix.com Sun Feb 23 14:56:40 2014 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sun, 23 Feb 2014 13:56:40 -0000 Subject: [Cryptography-dev] [ANN] pyOpenSSL 0.14 Message-ID: <20140223135640.6218.615676796.divmod.xquotient.17@top> Greetings fellow Pythoneers, I'm happy to announce that pyOpenSSL 0.14 is now available. pyOpenSSL is a set of Python bindings for OpenSSL. It includes some low-level cryptography APIs but is primarily focused on providing an API for using the TLS protocol from Python. Check out the PyPI page () for downloads. This release of pyOpenSSL adds: * Support for TLSv1.1 and TLSv1.2 * First-class support for PyPy * New flags, such as MODE_RELEASE_BUFFERS and OP_NO_COMPRESSION * Some APIs to access to the SSL session cache * A variety of bug fixes for error handling cases Additionally, there are three major changes to the project: First, the documentation has been converted from LaTeX (CPython's previous documentation system) to Sphinx (CPython's "new" documentation system ;). You can find the new documentation on the PyPI documentation site () or ). Second, pyOpenSSL is no longer implemented in C as a collection of extension modules using the Python/C API. Instead, pyOpenSSL is now a pure-Python project with a dependency on a new project, cryptography (), which provides (among other things) a cffi-based interface to OpenSSL. This change means that pyOpenSSL development is now more accessible to Python programmers with little or no experience with C. This is also how pyOpenSSL is now able to support PyPy. Finally, the project's code hosting has moved from Launchpad to Github. Many branches remain only on Launchpad along with their associated bug reports. Over the coming releases I hope that the fixes and features in these branches will be ported to Python and incorporated into the pyOpenSSL master development branch. Bug tracking has been disabled on Launchpad so that the amount of useful information hosted there can gradually dwindle to nothing. Please use Github () for further development and bug reporting. Thanks and enjoy, Jean-Paul From abhishek.ram at me.com Mon Feb 24 07:38:34 2014 From: abhishek.ram at me.com (Abhishek Ram) Date: Mon, 24 Feb 2014 12:08:34 +0530 Subject: [Cryptography-dev] Loading RSA Certifcates Message-ID: <8F80E55D-68D1-487C-AC3C-2673139DF412@me.com> Hi Team, I am building an AS2 lib in python and I want to use your library for encryption and signing. I have tried various other libraries and they do not satisfy my requirement. I have gone through your documentation and found the necessity algorithms for signing and encryption, however the problem I am facing is that I don't see a way to load RSA keys in your library. Is there a way that I can load RSA public and private keys? Regards Abhishek Ram From alexs at prol.etari.at Mon Feb 24 14:40:30 2014 From: alexs at prol.etari.at (alexs) Date: Mon, 24 Feb 2014 13:40:30 +0000 Subject: [Cryptography-dev] Loading RSA Certifcates In-Reply-To: <8F80E55D-68D1-487C-AC3C-2673139DF412@me.com> References: <8F80E55D-68D1-487C-AC3C-2673139DF412@me.com> Message-ID: <954ae8a8dcde683f9a4485feb98a38e2@prol.etari.at> I am currently working on this and we should have at least OpenSSL traditional format and PKCS#8 private key loading in 0.3. There is a PR under review on GitHub here https://github.com/pyca/cryptography/pull/627 if you'd like to take a look at our proposed API :) On 24.02.2014 06:38, Abhishek Ram wrote: > Hi Team, > > I am building an AS2 lib in python and I want to use your library for > encryption and signing. I have tried various other libraries and they > do not satisfy my requirement. > I have gone through your documentation and found the necessity > algorithms for signing and encryption, however the problem I am > facing > is that I don't see a way to load RSA keys in your library. Is there > a > way that I can load RSA public and private keys? > > Regards > Abhishek Ram > > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev From abhishek8816 at gmail.com Mon Feb 24 18:06:23 2014 From: abhishek8816 at gmail.com (Abhishek Ram) Date: Mon, 24 Feb 2014 22:36:23 +0530 Subject: [Cryptography-dev] Loading RSA Certifcates In-Reply-To: <954ae8a8dcde683f9a4485feb98a38e2@prol.etari.at> References: <8F80E55D-68D1-487C-AC3C-2673139DF412@me.com> <954ae8a8dcde683f9a4485feb98a38e2@prol.etari.at> Message-ID: Thanks, I will be waiting for this :). On 24-Feb-2014, at 7:10 PM, alexs wrote: > I am currently working on this and we should have at least OpenSSL traditional format and PKCS#8 private key loading in 0.3. > > There is a PR under review on GitHub here https://github.com/pyca/cryptography/pull/627 if you'd like to take a look at our proposed API :) > > On 24.02.2014 06:38, Abhishek Ram wrote: >> Hi Team, >> >> I am building an AS2 lib in python and I want to use your library for >> encryption and signing. I have tried various other libraries and they >> do not satisfy my requirement. >> I have gone through your documentation and found the necessity >> algorithms for signing and encryption, however the problem I am facing >> is that I don't see a way to load RSA keys in your library. Is there a >> way that I can load RSA public and private keys? >> >> Regards >> Abhishek Ram >> >> >> _______________________________________________ >> Cryptography-dev mailing list >> Cryptography-dev at python.org >> https://mail.python.org/mailman/listinfo/cryptography-dev > > _______________________________________________ > Cryptography-dev mailing list > Cryptography-dev at python.org > https://mail.python.org/mailman/listinfo/cryptography-dev