Re: [Cryptography-dev] pyca/cryptography python 3.2 support

[Glyph]

Is there a way to answer this question as a query against PyPI metadata?  It 
seems like the information ought to be there, in some form...

-g

> On Apr 14, 2015, at 11:22, Alex Gaynor  wrote:
> 
> Have we confirmed that all important downstreams (pyOpenSSL, Twisted, 
> eventually Fabric/Paramiko, urllib3/requests) have dropped 3.2?
> 
> Alex
> 
> On Tue, Apr 14, 2015 at 10:49 AM, Laurens Van Houtven <_...@lvh.io 
> > wrote:
> I for one support any and all efforts that reduce the number of supported 
> Python 3.x versions ;-)
> 
> On Tue, Apr 14, 2015 at 10:27 AM, Terry Chia  > wrote:
> FWIW I'm fully in support of this as it doesn't seem like we'll be dropping 
> support for any major platforms and 3.2 use is basically nil at this point. 
> On Tue, 14 Apr 2015 at 10:23 pm Paul Kehrer  > wrote:
> Recently we've had several situations where our project's Python 3.2 support 
> blocks us from using libraries we'd like to consume (idna, characteristic, 
> etc). Donald opened an issue 
> (https://github.com/pyca/cryptography/issues/1809 
> ) with some evidence that 
> we're performing significant contortions to support a version no one uses. I 
> propose that we drop support for Python 3.2 in the next release and move 
> forward with Python 2.6 (deprecated but no timeline for removal), Python 2.7, 
> and 3.3+ support.
> 
> I've put in a PR (https://github.com/pyca/cryptography/pull/1846 
> ) to note this in the 
> changelog and update our travis configuration. If there are no substantial 
> objections in the next few days we can merge and then update jenkins to 
> reflect this as well.
> 
> -Paul Kehrer
> 
> 
> ___
> Cryptography-dev mailing list
> Cryptography-dev@python.org 
> https://mail.python.org/mailman/listinfo/cryptography-dev 
> 
> 
> ___
> Cryptography-dev mailing list
> Cryptography-dev@python.org 
> https://mail.python.org/mailman/listinfo/cryptography-dev 
> 
> 
> 
> 
> ___
> Cryptography-dev mailing list
> Cryptography-dev@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@python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] [ANN] pyOpenSSL 0.15

[Glyph]

Thank you very much to Jean-Paul and Hynek for getting out this most recent 
release! (And thanks to Hynek for my opportunity to contribute my first patch 
to pyOpenSSL ;-)).

-glyph

> On Apr 15, 2015, at 14:10, Alex Gaynor  wrote:
> 
> Thank you for your years of maintenance of pyOpenSSL!
> 
> Alex
> 
> On Wed, Apr 15, 2015 at 2:02 PM, Jean-Paul Calderone  <mailto:jean-p...@clusterhq.com>> wrote:
> On Tue, Apr 14, 2015 at 12:54 PM, Hynek Schlawack  <mailto:h...@ox.cx>> wrote:
> Greetings fellow Pythoneers,
> 
> I'm happy to announce that pyOpenSSL 0.15 is now available.
> 
> 
> Congrats on getting the release out, Hynek.  Thanks once again for stepping 
> in to take over the lead role on the pyOpenSSL project.  Thanks also to all 
> of the PyCA folks at the PyCon sprints on Monday to prepare for this release.
> 
> Jean-Paul
> 
> 
> ___
> Cryptography-dev mailing list
> Cryptography-dev@python.org <mailto:Cryptography-dev@python.org>
> https://mail.python.org/mailman/listinfo/cryptography-dev 
> <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@python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] PyCA cryptography 1.0.1 released

[Glyph]

> On Sep 5, 2015, at 22:05, Paul Kehrer  wrote:
> 
> PyCA cryptography (https://github.com/pyca/cryptography 
> <https://github.com/pyca/cryptography>) 1.0.1 has been released! cryptography 
> is a package which provides cryptographic recipes and primitives to Python 
> developers. Our goal is for it to be your "cryptographic standard library". 
> We support Python 2.6-2.7, Python 3.3+, and PyPy 2.6+.
> 
> Changelog (https://cryptography.io/en/latest/changelog/ 
> <https://cryptography.io/en/latest/changelog/>)
> 
> * We now ship OS X wheels that statically link OpenSSL by default. When 
> installing a wheel on OS X 10.10+ (and using a Python compiled against the 
> 10.10 SDK) users will no longer need to compile.

This is very exciting, and should really reduce the number of problems people 
have getting bootstrapped with cryptography, and speed up `pip install 
twisted[tls]´ on OS X.  Thanks for making this happen, Paul!

-glyph


___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] pyOpenSSL: non-blocking socket support

[Glyph]

> On Jun 27, 2016, at 22:23, Vladimir Didenko  
> wrote:
> 
> Resume: you can use nonblocking ssl socket with standard ssl module and 
> PyOpenSSL. Though it requires some work from you (but it is not hard!).

The better way to use pyOpenSSL (and more recent stdlib ssl modules) is to use 
Memory BIOs, though.  Twisted migrated many years back from letting OpenSSL do 
the socket I/O to doing the socket I/O itself and the result has been much more 
portable, testable, and reliable.

-glyph___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] New OpenSSH key format

[Glyph]

Twisted trunk@HEAD can do this, via cryptography, although this functionality 
is not yet present in a release:

https://github.com/twisted/twisted/pull/1193 
<https://github.com/twisted/twisted/pull/1193>

I saw your question and remembered doing the code review for this :-).

I would guess we'll have a new release fairly soon (I know the goal is to have 
one out before April).

-glyph

> On Mar 2, 2020, at 10:36 PM, Ron Frederick  wrote:
> 
> You might want to see if AsyncSSH (https://asyncssh.readthedocs.io 
> <https://asyncssh.readthedocs.io/>) can do what you’re looking for. While its 
> main purpose is to provide an asyncio-compatible SSH client and server, it 
> also had a very complete set of key management functions for reading and 
> writing private/public keys and certificates, reading and writing them in a 
> wide variety of formats and providing functions such as signing and 
> verification with them. You don’t even need to be using asyncio to take 
> advantage of these functions.
> 
> On Mar 2, 2020, at 10:30 PM, Alex Gaynor  <mailto:alex.gay...@gmail.com>> wrote:
>> No, cryptography does not support OpenSSH format private keys. This is not 
>> currently planned.
>> 
>> Alex
>> 
>> On Tue, Mar 3, 2020 at 1:28 AM Lalit Kumar > <mailto:lalit.hilma...@gmail.com>> wrote:
>> Can we retrieve the public key from private key in the new OpenSSH format 
>> like below:
>> 
>> -BEGIN OPENSSH PRIVATE KEY-
>> b3BlbnNzaC1rZXktdjEABG5vbmUEbm9uZQABAAABFwdzc2gtcn
>> NhAwEAAQAAAQEA2MTxUgEE1y0Mx+nA0SBDRhK2DnNQU4ACS1g8qWwanIJ81q4u1n/8
>> XUdagRSctNyzsMVsGKrPez/T+11rTlc+AKfqrJacz0SxpPi/PAszLQ6ARYESbpAGXlwwjb
>> a0iYXR512mIArg/xNVWZtGHVvGDQEATIWIxOoI4hmGcE9bqHW/me8PvA/cggDKxICa0CLx
>> i+7drR2exNwhYVlw//RTw1raZorVtD1rNyh4YXeX9JfX1E9RXRDaP1zonVwjH3E64hyw4y
>> ARRSSnvaaQPNEmkrZMv37NQNbN/XIj9pdbXq/rBJ0yOIFQrGSYIr+yMThiloD5n/LZeAFr
>> 1rCZsChawQAAA8h+4JwsfuCcLAdzc2gtcnNhAAABAQDYxPFSAQTXLQzH6cDRIENGEr
>> YOc1BTgAJLWDypbBqcgnzWri7Wf/xdR1qBFJy03LOwxWwYqs97P9P7XWtOVz4Ap+qslpzP
>> RLGk+L88CzMtDoBFgRJukAZeXDCNtrSJhdHnXaYgCuD/E1VZm0YdW8YNAQBMhYjE6gjiGY
>> ZwT1uodb+Z7w+8D9yCAMrEgJrQIvGL7t2tHZ7E3CFhWXD/9FPDWtpmitW0PWs3KHhhd5f0
>> l9fUT1FdENo/XOidXCMfcTriHLDjIBFFJKe9ppA80SaStky/fs1A1s39ciP2l1ter+sEnT
>> I4gVCsZJgiv7IxOGKWgPmf8tl4AWvWsJmwKFrBAwEAAQAAAQAi3Kmi8p8ArDIeBK4J
>> 9BJdtqyo7krA4xl7XJmE9enhueqx7BmETdkcd1lK4THCtKwBhf64iOANhlplVsTnOIi0Ok
>> 03rJFTlEytp4O5+GMmn+ppQzTfqzIbAuCcKgInC+qSNzF8fcNpwoY7fwlrt1LGzJ5rsB4q
>> 7Si4lDpW3ax0Dw/n514DgqVXJi3KcMy37FeNgzDREK1P8lZjUGcIySQNn5/pd1zZiAZ4mX
>> HwyE4q1XsqBU8WfOYObH4J7BEjrHKrCjW+K+XrOVxdIfwLg7KA6VWBld77AZSt7Dy1xAm4
>> fbpJp3YtmAeNnnuuNjr1HyyzF5hTcMiQ4ibseliTeSZxgAw+0F/ZmyYWrv2mDTzeO1
>> yhOwq/sEFyY7OeG1I1dsk8d36vWO3vVYmb9mk7b4Ud/M4C4wSuL2d64HB6wIg3nxo3M0I3
>> e0BlL/S3zzEM9H8rBd1WJpK3nQYrv+H1vLXMq96/Ph3ZY1TmOaxcdk8zKyLSQQ7quxi3ZR
>> 0ZUAX70Sc/gQD8uch+1NBy4u65KOsqtx6tf3oXaKCfPl026oaosb3WnaNqNLJzlB95
>> mQaBUqIU4zkL2Z1O2ICQO7Zvv9FEoS5SPo79WO0S2CgnIsSPuvfVsggwH6wQd0K8IpvdDL
>> Cyi7/eGT+tRoN+iCcSFgDNVyA0I8NvLfAQRpzcANa8KUC0+wAAAIEA25PnE/2sl7nMrZ8d
>> khV+TbgPYvhhcibO0REiALkT4bs+cdHgAI+5rl9GuYFrvLNuY9e1Yh87jtDG6QTviwtjG1
>> 2U3ycQBC3amxFBkpcI30pKRrfV1SbVEr3EC5ns48iOPxDS+3J44wGaqZdWbOICX/EIdd9I
>> J0tdLs/k0W+LynMPbGFsaXQua3VtYXJATWFjAQIDBA==
>> -END OPENSSH PRIVATE KEY-
>> 
>> This is an RSA key in the new format. Does cryptography 2.8 support this? If 
>> not is it planned for next release?
>> 
>> -- 
>> Regards,
>> Lalit
> 
> -- 
> Ron Frederick
> r...@timeheart.net <mailto:r...@timeheart.net>
> 
> 
> 
> ___
> Cryptography-dev mailing list
> Cryptography-dev@python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] Cryptographic recipes

[Glyph]

> On Jun 30, 2024, at 10:45 AM, Ben Portner via Cryptography-dev 
>  wrote:
> 
> I am thinking: Isn't this exactly where you come in and show *the one* 
> configuration of the options and knobs that is safe to use? I mean, you are 
> spelling it out right there. Many people (me included) have no idea what they 
> are doing when they implement encryption themselves. That is the reason why 
> cybersecurity and privacy are a mess in most tools and services today. But 
> what choice do devs like me have when there are no tested free and open 
> source recipes out there that we can use? I thought this is exactly the 
> problem that pyca is trying to solve.
> 

The difficulty of implementing something like PGP is that once PGP is 
implemented, there is pressure to actually implement all the parts of it. PGP 
is only configurable on the sending side; on the recipient side, you have to 
accept whatever terrible cipher suite and weak hashing algorithm that the 
sender has selected, or you just have to fail the operation.  If the 
implementation failed most of the time (as it should, most PGP messages are 
malformed in some way), users would be constantly unhappy, generating a huge 
support burden for this list.

In other words, it's not really possible to provide a full, interoperable, 
correct OpenPGP implementation that is also secure.

I agree that I really want cryptography to include some asymmetric messaging 
recipes, the short list of "X509" and "Fernet" is a little anemic, but the 
engineering effort to construct a standardized, secure one is a huge challenge 
beyond the scope of the Cryptography project itself.  Sort of like how 
Wikipedia has a "no original research" project, because an encyclopedia is 
already a big enough project, Cryptography's mandate is to provide high-quality 
implementations, not to design entire new protocols.

-g

___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] Cryptographic recipes

[Glyph]

> On Jul 10, 2024, at 2:45 PM, Benjamin W. Portner via Cryptography-dev 
>  wrote:
> 
> Hi Glyph,
> 
> thanks for chiming in and for the interesting insights from the 
> implementation side. I wasn't aware of the difficulties involved in providing 
> the recipient side of OpenPGP. It totally makes sense though.
> 
> Personally, I am kind of happy with your recipe short list. The only thing 
> that is missing for my personal use case is how to encapsulate the parameters 
> that were used for the key derivation alogirhtm together with the cipher text 
> so that they can be recovered by the recipient. The only reason why I 
> suggested OpenPGP is because I assume that the standard prescribes a way to 
> do that. Is there any chance that you will add steps for this in the Fernet 
> recipe?

I am just a Cryptography user who happens to know the maintainers reasonably 
well, so it's unlikely that I will do this :).  I don't think I understand your 
request though.  Fernet is an implementation of a standard, it doesn't have a 
facility for storing KDF parameters.  You can read about it here: 
<https://github.com/fernet/spec/blob/master/Spec.md>.  Their repo also has an 
issues list, so you could file the request, if you thought it was useful.

What would you do with metadata about KDF parameters, if you had them?

-g___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] Cryptographic recipes

[Glyph]

> On Jul 10, 2024, at 2:45 PM, Benjamin W. Portner via Cryptography-dev 
>  wrote:
> 
> Hi Glyph,
> 
> thanks for chiming in and for the interesting insights from the 
> implementation side. I wasn't aware of the difficulties involved in providing 
> the recipient side of OpenPGP. It totally makes sense though.
> 
> Personally, I am kind of happy with your recipe short list. The only thing 
> that is missing for my personal use case is how to encapsulate the parameters 
> that were used for the key derivation alogirhtm together with the cipher text 
> so that they can be recovered by the recipient. The only reason why I 
> suggested OpenPGP is because I assume that the standard prescribes a way to 
> do that. Is there any chance that you will add steps for this in the Fernet 
> recipe?

I am just a Cryptography user who happens to know the maintainers reasonably 
well, so it's unlikely that I will do this :).  I don't think I understand your 
request though.  Fernet is an implementation of a standard, it doesn't have a 
facility for storing KDF parameters.  You can read about it here: 
<https://github.com/fernet/spec/blob/master/Spec.md>.  Their repo also has an 
issues list, so you could file the request, if you thought it was useful.

What would you do with metadata about KDF parameters, if you had them?

-g___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] Cryptographic recipes

[Glyph]

> On Jul 15, 2024, at 11:23 AM, Ben Portner via Cryptography-dev 
>  wrote:
> 
>> "What would you do with metadata about KDF parameters, if you had them?"
> 
> Correct me if I'm wrong. I believe those parameters (initial vector, number 
> of rounds...) are required to restore the AES key from the user-provided 
> password. Without those parameters one cannot restore the AES key and thus 
> not decrypt the cipher text.

Ah, so you want something where you can exchange a "password protected file" 
and then somehow communicate the human-entered password out of band as text, 
rather than as an AES key, then have the file be otherwise self-contained?

-g___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] Extracting pub key from a csr

[Glyph]

You will note that 
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ed25519/#cryptography.hazmat.primitives.asymmetric.ed25519.Ed25519PrivateKey.public_key
 has parentheses after it in its description.  That's it.  You just forgot the 
parens.  i.e., try:

public_bytes = csr.public_key().public_bytes(
 encoding=serialization.Encoding.Raw,
 format=serialization.PublicFormat.Raw,
)

Hope that helps,

-g

> On Aug 29, 2024, at 8:59 PM, Robert Moskowitz  wrote:
> 
> I may know a lot about x.509 objects (and use openssl command line a lot), 
> but I am a serious hack at anything python, so I am missing your point wrt 
> what I need to do after reading in the csr to get a var that contains the 
> public key in bytes I can use.
> 
> So, please, be a little understanding and convey some understanding to me.  I 
> have spent a lot of hours trying to grok
> 
> https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ed25519
> 
> And still come up short.
> 
> thanks
> 
> On 8/29/24 23:38, Paul Kehrer wrote:
>> public_key is a method on your csr object that returns the public_key,
>> not an attribute.
>> 
>> -Paul
>> 
>> On Thu, Aug 29, 2024 at 8:36 PM Robert Moskowitz  
>> wrote:
>>> I tried that and:
>>> 
>>> public_bytes = public_key.public_bytes(
>>>  encoding=serialization.Encoding.Raw,
>>>  format=serialization.PublicFormat.Raw)
>>> 
>>>  public_bytes = public_key.public_bytes(
>>> ^^
>>> NameError: name 'public_key' is not defined
>>> 
>>> so I tried
>>> 
>>> public_bytes = csr.public_key.public_bytes(
>>>  encoding=serialization.Encoding.Raw,
>>>  format=serialization.PublicFormat.Raw)
>>> 
>>>  public_bytes = csr.public_key.public_bytes(
>>> ^^^
>>> AttributeError: 'builtin_function_or_method' object has no attribute
>>> 'public_bytes'
>>> 
>>> then
>>> 
>>> public_bytes = csr.public_bytes(
>>>  encoding=serialization.Encoding.DER)
>>> 
>>> b'0\x81\x8f0C\x02\x01\x000\x101\x0e0\x0c\x06\x03U\x04\x05\x13\x05x12240*0\x05\x06\x03+ep\x03!\x00*,\xeb\xfb\xde\x01|8\xc4\xfdv\xf5\xc8j-\x07;<\xa8OI\x16\x93\x0c\xe2\xb8\xf3\x9b\x9d\xbf\x8fm\xa0\x000\x05\x06\x03+ep\x03A\x00\xc6\xe4~\xbd\xf8\xe0\x01\x9b\xd8\xd1\xcc$\xe9;\x85Gd\x9eb\x98\xdds\xab\x00\xa2\x13-\xb14_\x93bK\x17\xecg\xca/,n\x12\x9eb\x04\x13\xce\xad\xe6\x95\x9fh\xf0\x05\x84\x9f-\xfa3\x06%L\xd0^\x03'
>>> 
>>> Which looks more like the whole csr, being to large to be 32 bytes.
>>> 
>>> 
>>> 
>>> 
>>> On 8/29/24 23:15, Alex Gaynor wrote:
 All of our public key types have a public_bytes() method that can be
 used to serialize the key as you wish:
 https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ed25519/#cryptography.hazmat.primitives.asymmetric.ed25519.Ed25519PublicKey.public_bytes
 
 Alex
 
 On Thu, Aug 29, 2024 at 11:12 PM Robert Moskowitz  
 wrote:
> I want a variable that is the bits of the public key so that if I print
> it, I get something like:
> 
> 0xf32938f7ff6918d5bbdc52483f31e3725875456a9aeb83f915461a5ea629acda
> 
> or whatever type that I can then change to what I need elsewhere.
> 
> On 8/29/24 23:02, Alex Gaynor wrote:
>> You're getting back the public key object for that CSR. When you say
>> you want the "public key itself" what do you mean?
>> 
>> Alex
>> 
>> On Thu, Aug 29, 2024 at 10:54 PM Robert Moskowitz  
>> wrote:
>>> I have a csr with an eddsa25519 key:
>>> 
>>> -BEGIN CERTIFICATE REQUEST-
>>> MIGPMEMCAQAwEDEOMAwGA1UEBRMFeDEyMjQwKjAFBgMrZXADIQAqLOv73gF8OMT9
>>> dvXIai0HOzyoT0kWkwziuPObnb+PbaAAMAUGAytlcANBAMbkfr344AGb2NHMJOk7
>>> hUdknmKY3XOrAKITLbE0X5NiSxfsZ8ovLG4SnmIEE86t5pWfaPAFhJ8t+jMGJUzQ
>>> XgM=
>>> -END CERTIFICATE REQUEST-
>>> 
>>> I want the Pbkey of
>>> 
>>>Subject Public Key Info:
>>>Public Key Algorithm: ED25519
>>>ED25519 Public-Key:
>>>pub:
>>>e7:3f:5c:a1:b7:78:8a:75:e4:7b:91:4c:0c:1c:48:
>>>d7:f8:06:c1:f1:9d:58:b0:4d:c9:48:7f:3d:1d:bc:
>>>ac:16
>>> 
>>> I am following
>>> 
>>> https://cryptography.io/en/3.4.7/x509/reference.html#loading-certificate-signing-requests
>>> and
>>> https://cryptography.io/en/3.4.7/x509/reference.html#x-509-csr-certificate-signing-request-builder-object
>>> 
>>> I tried the following to get the key:
>>> 
>>> from cryptography.hazmat.primitives import serialization
>>> from cryptography.hazmat.primitives.asymmetric import ed25519
>>> from cryptography import x509
>>> from cryptography.x509.oid import NameOID
>>> from cryptography.hazmat.primitives.serialization import 
>>> load_pem_private_key
>>> 
>>> with open(uacsr, "rb") as f:
>>>pem_req_data = f.read()
>>>   

Re: [Cryptography-dev] Extended Key Usage of keyCertSign

[Glyph]

> On Sep 11, 2024, at 6:27 AM, Robert Moskowitz  wrote:
> 
>> This is a fairly elementary Python mistake. Our documents and
>> resources are generally oriented towards people who have an existing
>> familiarity with Python. I'd strongly encourage you to develop a
>> greater comfort with Python in general.

> WIP.  Much better than 2 weeks ago.

I think that what Alex was trying to say here is that you would be better 
served by a support channel that is oriented towards helping people learn 
Python than helping people with Cryptography.  For example, the #python-help 
channel on https://www.pythondiscord.com/ .  You clearly have some experience 
with cryptographic concepts and haven't needed much in the way of help with 
them or the library specifically, and are just tripping over issues of syntax 
and runtime error interpretation, which the folks over there can help you with.

-g___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] PyCA cryptography 1.0.2 released

[Glyph Lefkowitz]

If running under -O[O] is a supported configuration for Cryptography now, is 
there a plan to migrate to something other than py.test so that the test suite 
can meaningfully execute in that environment as well?  My usual assumption is 
that any Python with 'assert's in its test suite implicitly assumes this option 
will never be used.

If running the test suite is impossible in such an interpreter, then perhaps it 
would be better to detect this configuration and fail hard, rather than 
piecemeal supporting bits of it, especially if bugs like this potentially cause 
security issues.

-glyph

> On Sep 27, 2015, at 7:07 AM, Paul Kehrer  wrote:
> 
> PyCA cryptography 1.0.2 has been released. This release contains a security 
> fix that affects anyone running python with -O.
> 
> Changelog:
> 
> * SECURITY ISSUE: The OpenSSL backend prior to 1.0.2 made extensive use of 
> assertions to check response codes where our tests could not trigger a 
> failure. However, when Python is run with -O these asserts are optimized 
> away. If a user ran Python with this flag and got an invalid response code 
> this could result in undefined behavior or worse. Accordingly, all response 
> checks from the OpenSSL backend have been converted from assert to a true 
> function call. Credit Emilia Käsper (Google Security Team) for the report.
> 
> -Paul Kehrer (reaperhulk)
> ___
> Cryptography-dev mailing list
> Cryptography-dev@python.org <mailto:Cryptography-dev@python.org>
> https://mail.python.org/mailman/listinfo/cryptography-dev 
> <https://mail.python.org/mailman/listinfo/cryptography-dev>
___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL

[Glyph Lefkowitz]

> On Dec 28, 2015, at 1:51 AM, Cory Benfield  <mailto:c...@lukasa.co.uk>> wrote:
> 
> 
>> On 28 Dec 2015, at 09:35, Hynek Schlawack mailto:h...@ox.cx>> 
>> wrote:
>> 
>> Hi,
>> 
>> we have quite a bit of pull requests on pyOpenSSL that revolve around 
>> improving the state of x509 objects in general as far as I understand it.
>> 
>> Since I already got reprimanded by Alex G for merging one because 
>> cryptography has routines for that, I wonder if we should close them all as 
>> WONTFIX and instead add methods akin to `PKey.from_cryptography()`, 
>> `key_instance.to_cryptography()`.
>> 
>> I welcome any feedback.  The current pyOpenSSL situation which is mostly a 
>> swamp of guilt is becoming unbearable to me.  When I took over 
>> maintainership I made it clear that I see myself mostly as a repo janitor 
>> and Bad Ideas Deflector™.  Sadly that’s not working out at all.  Getting rid 
>> of the burden of actually moving forward a whole sub-system might alleviate 
>> that a bit I guess (this is not meant as an ultimatum, I have no idea if 
>> it’d help).
> 
> As official “sometimes helps Hynek when he feels sad” person, I’m strongly in 
> favour of deprecating whatever we can from PyOpenSSL if there is a good 
> alternative available (i.e. cryptography). It’s frustrating and perplexing 
> that installing PyOpenSSL gives you two interfaces for working with X509 
> certs, and where the top layer is arguably *less* helpful (and definitely 
> more surprising) than the layer it uses to do the real work.
> 
> To make this kind of deprecation work I think we definitely need a to/from 
> cryptography method to have been in place for a while, so I’m in favour of 
> this plan. Long term, however, I want PyOpenSSL stripped down to be only what 
> cryptography itself does not do.

Long term, shouldn't pyOpenSSL be removed entirely, and Cryptography just does 
everything?

In the meanwhile though, I think that from_cryptography/to_cryptography are a 
good idea, and should contain a clear explanation of this plan: in other words, 
everyone using pyOpenSSL should start rewriting their applications to use the 
'cryptography' objects as much as possible.

Right now, things are in a bit of a muddled state; pyOpenSSL is still the only 
package available to do many things (in particular: TLS) but pull requests are 
being refused on the grounds that Cryptography has superseded it, when there 
still isn't a clear interop strategy.  These methods (especially if properly 
documented) could really improve this situation.

-glyph

___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL

[Glyph Lefkowitz]

> On Jan 4, 2016, at 5:59 AM, Hynek Schlawack  wrote:
> 
> AFAIK, there hasn’t been a PR refused for this reason so far but there have 
> always been awkward nudges in that direction.

Sorry, I probably contributed to some confusion there. I thought I saw earlier 
in the thread that PRs had been refused; I am not familiar with any specific 
ones myself.

This sounds like a good direction though, happy that you're working on it!

-g___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev

Re: [Cryptography-dev] use of poor implementations of algorithms

[Glyph Lefkowitz]

> On Jun 29, 2016, at 23:09, Jay Gupta  wrote:
> 
> could you provide concrete examples of your criticism of other Python 
> cryptographic packages, especially about poor algorithm interpretations?

What specific criticism are you referring to?  Cryptography developers have 
been critical of other packages (and their own!) in a variety of contexts.

-glyph___
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev