PyCA cryptography 41.0.7 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+,
PyCA cryptography 41.0.4 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.7+,
Yesterday, PyCA cryptography 38.0.2 was released to PyPI. Today, we
yanked the release from PyPI due to regressions in OpenSSL that led
the OpenSSL team to withdraw OpenSSL 3.0.6 (which PyCA cryptography's
wheels include). We expect to issue a follow up release once the
OpenSSL team has released
PyCA cryptography 37.0.4 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X509, key derivation functions, and much
more. We support Python 3.6+,
Yesterday, PyCA cryptography 37.0.3 was released to PyPI. Today, we
yanked the release from PyPI due to a regression in OpenSSL that was
producing heap corruption for users.
cryptography includes both high level recipes and low level interfaces
to common cryptographic algorithms such as symmetric
Alex Gaynor added the comment:
It seems to no longer be crashing with alpha5. Hopefully it's actually fixed
and not merely having a more subtle failure mode.
--
___
Python tracker
<https://bugs.python.org/issue46
Alex Gaynor added the comment:
Sticking with 100k is not scientific though ;-) Empiricism is science!
I'm probably the person responsible for Django's process, which is to increase
by some % (10% or 20% IIRC) every release.
As you point out, the exact value one should use is a function
Change by Alex Gaynor :
--
components: +Interpreter Core
nosy: +Mark.Shannon, alex
___
Python tracker
<https://bugs.python.org/issue46159>
___
___
Python-bug
Alex Gaynor added the comment:
I am someone who is interested in having this, but FWIW my motivation is
slightly more narrow, I only really need abi3-friendly buffer support with
contiguous 1d buffers. Not sure if there'd be interest in doing a smaller
version before figuring out the entire
Change by Alex Gaynor :
--
nosy: +alex
___
Python tracker
<https://bugs.python.org/issue42486>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Alex Gaynor :
--
versions: +Python 3.10
___
Python tracker
<https://bugs.python.org/issue42415>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Alex Gaynor :
--
components: +C API
___
Python tracker
<https://bugs.python.org/issue42415>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alex Gaynor added the comment:
This looks like a bug to me. While
https://github.com/python/cpython/commit/2ff58a24e8a1c7e290d025d69ebaea0bbead3b8c
added it to the header, it did not add it to
https://github.com/python/cpython/blob/master/PC/python3dll.c which is required
New submission from Alex Gaynor :
Currently PyObject_GenericSetDict is part of the stable API, but
PyObject_GenericGetDict is not. I noticed this while working on
https://github.com/PyO3/pyo3/pull/1207
Because of the symmetry here, it seems appropriate to promote Get.
--
components
Alex Gaynor added the comment:
It's a big project I think :-) Py_Buffer is allocated on the stack, so either
we'd have to agree to never change it's ABI (size, alignment, etc.) or we'd
need to completely change the interface.
--
___
Python
Alex Gaynor added the comment:
Py_buffer is not part of the limited API at all, so I don't think it's usable
for this.
--
___
Python tracker
<https://bugs.python.org/issue41
Alex Gaynor added the comment:
I think less is more, one API is plenty :-)
It looks to me like the API is already supported on PyPy, so I think it's fine
from that perspective:
https://foss.heptapod.net/pypy/pypy/-/blob/branch/py3.7/pypy/module/cpyext/unicodeobject.py#L493
Change by Alex Gaynor :
--
keywords: +patch
pull_requests: +21307
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22252
___
Python tracker
<https://bugs.python.org/issu
Change by Alex Gaynor :
--
assignee: -> alex
___
Python tracker
<https://bugs.python.org/issue41784>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Alex Gaynor :
This function is incredibly useful for efficient interoperability between
Python and other languages with UTF-8 based strings (e.g. Rust). Right now it's
not possible to do interop without several copies/allocations if you're trying
to build an abi3 wheel
Alex Gaynor added the comment:
Here's my suggestion:
End of line reached without finding the end of string literal. Are you missing
a closing quote?
--
nosy: +alex
___
Python tracker
<https://bugs.python.org/issue40
Change by Alex Gaynor :
--
keywords: +security_issue
nosy: +alex
___
Python tracker
<https://bugs.python.org/issue39421>
___
___
Python-bugs-list mailin
Change by Alex Gaynor :
--
nosy: +alex
___
Python tracker
<https://bugs.python.org/issue37461>
___
___
Python-bugs-list mailing list
Unsubscribe:
PyCA cryptography 2.5 has been released to PyPI. cryptography includes both
high level recipes and low level interfaces to common cryptographic
algorithms such as symmetric ciphers, asymmetric algorithms, message
digests, X509, key derivation functions, and much more. We support Python
2.7, Python
Alex Gaynor added the comment:
All libraries that are linked against, including libc, need to be compiled with
MSAN. MSAN is not for the faint of heart.
--
___
Python tracker
<https://bugs.python.org/issue35
Change by Alex Gaynor :
--
nosy: +alex
___
Python tracker
<https://bugs.python.org/issue35214>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +orsenthil
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33661>
___
_
Alex Gaynor <alex.gay...@gmail.com> added the comment:
None of the above :-) I'd expect the last one, but with quoting.
You should not be able to set fields in a cookie by injection.
--
___
Python tracker <rep...@bugs.python.or
Alex Gaynor <alex.gay...@gmail.com> added the comment:
Berker your patch looks good to me.
Convert it to a PR and then merge?
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.
Alex Gaynor <alex.gay...@gmail.com> added the comment:
Good catch.
--
versions: +Python 3.8 -Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Alex Gaynor <alex.gay...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Alex Gaynor <alex.gay...@gmail.com> added the comment:
New changeset c87eb09d2e3783b0b5dc0d7cb304050cbcc86ad3 by Alex Gaynor in branch
'master':
bpo-29613: Added support for SameSite cookies (GH-6413)
https://github.com/python/cpython/commit/c87eb09d2e3783b0b5dc0d7cb304050cbc
Change by Alex Gaynor <alex.gay...@gmail.com>:
--
keywords: +patch
pull_requests: +6118
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Alex Gaynor <alex.gay...@gmail.com> added the comment:
(Didn't mean to update status)
--
status: open -> pending
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Alex Gaynor <alex.gay...@gmail.com> added the comment:
Can confirm, no browsers do partial (or multiple) wildcards and the CABF rules
don't allow public CAs to issue them.
--
status: pending -> open
___
Python tracker <rep...@bugs.python
Alex Gaynor <alex.gay...@gmail.com> added the comment:
If anyone has needed a workaround in the past 9 years and hasn't yet found one:
https://github.com/pyca/cryptography/pull/3968/commits/3b585f803891e750d0ca5861b5a29e16b779bc16
--
nosy:
Alex Gaynor <agay...@mozilla.com> added the comment:
I'd be in favor of backporting this to the 2.x - encouraging reliance on the
nonsense behaviour of putting IPAddresses in DNS Names or relying on CN over
SAN is bad, and we shouldn't encourage it.
--
nosy: +Alex
Alex Gaynor added the comment:
What operating system are you on?
--
nosy: +Alex Gaynor
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Alex Gaynor added the comment:
For the use case of "I want to trust this CA, but I don't want to trust any of
it's sub CAs" I think there's a simpler solution than expanding our API:
Create your own cross-sign of the root you want, and add a pathLenConstraint: 0
to the basicC
Alex Gaynor added the comment:
Mmmm, my understanding is that ignoring TCP-FIN/RST-without-TLS-closenotify is
pretty common for a lot of different clients.
We should probably survey the landscape, see what both browsers and non-browse
clients (e.g. curl) do before making a decision
Alex Gaynor added the comment:
An additional problem in (2) is that a cert for *.google _is_ legal if the CA
can prove that a single organization controls the entire TLD:
https://crt.sh/?id=7668286
--
nosy: +Alex Gaynor
___
Python tracker <
Alex Gaynor added the comment:
+1 on making sure we have a concrete use case before expanding the API
--
nosy: +Alex Gaynor
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
+1 Christian, we should not be expanding our usage of CNs at all.
--
status: pending -> open
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +dstufft, janssen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28414>
___
Alex Gaynor added the comment:
This came up on m.d.s.p. today:
https://groups.google.com/d/msg/mozilla.dev.security.policy/K3sk5ZMv2DE/fx6c3WWFBgAJ
I haven't dug in deeply, but it sounds like we handle IDNs in CNs and SANs
differently?
I think we should look for a way to solve that specific
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30879>
___
__
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: -alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30319>
___
__
New submission from Alex Gaynor:
CT (https://www.certificate-transparency.org/) is starting to become a thing!
It'd be great if we exposed SCTs (whether from TLS extensions, OCSP, or
embedded in the certificate) for TLS connections. This would allow higher level
protocols to begin acting
Alex Gaynor added the comment:
Ugh, except via |register_archive_format|. |register_archive_format| could wrap
callables passed to it to maintain the current behavior.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
None of those functions are a public API, so changing them shouldn't be a
problem IMO.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Alex Gaynor:
Currently shutil.make_archive uses os.chdir, however there's no need for that.
Everything that's done could be equally accomplished with path manipulation:
https://github.com/python/cpython/blob/master/Lib/shutil.py#L773-L779
We should switch to using path
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
pull_requests: +1781
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30420>
___
Alex Gaynor added the comment:
Just discussed with Christian, and we're both in favor of adding AIA chasing
support to the stdlib ssl.
--
nosy: +alex, janssen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
Sounds good to me!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29810>
___
___
Python-bugs-list
Alex Gaynor added the comment:
Ah, so instead of PROTOCOL_SSLv23 using PROTOCOL_TLS_CLIENT and deprecating the
Purpose bits entirely? That sounds good to me!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +christian.heimes, dstufft, janssen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Alex Gaynor:
The names are super misleading. First, they're written in a way that's the
opposite of how people think about these things (CLIENT_AUTH -> server socket;
SERVER_AUTH -> client socket). Second, they're misleading, you can have TLS
which is *mu
Alex Gaynor added the comment:
Yeah, this got me (happy to explain what I was trying to do in more detail, if
it'd be helpful), took me longer to understand why my tests passed on
{26,27,33,34} but failed on 35 since the public "what's changed" docs page is
where I went to.
Ul
Alex Gaynor added the comment:
An FYI for the future, it would have been very helpful if this had been
documented in the whats-changed file for 3.5.
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29505>
___
__
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: -alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11549>
___
__
Alex Gaynor added the comment:
We can easily just add `TLS13:...` at the from of our ciphersuite list and
it'll be ok though right? (Note to self, do the same in urllib3, twisted,
requests, god only knows what else)
--
nosy: +alex
___
Python
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +alex, dstufft, janssen
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +nadeem.vawda
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28275>
___
_
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
keywords: +security_issue
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Alex Gaynor:
https://www.openssl.org/news/secadv/20160922.txt
--
assignee: christian.heimes
components: Library (Lib), SSL
keywords: security_issue
messages: 277226
nosy: alex, christian.heimes, dstufft, janssen, ned.deily, paul.moore,
ronaldoussoren, steve.dower
Alex Gaynor added the comment:
OpenSSL supports scrypt
On Sep 7, 2016 12:28 PM, "Benjamin Peterson" <rep...@bugs.python.org> wrote:
>
> Benjamin Peterson added the comment:
>
> Why are we adding scrypt and not argon2 anyway?
>
> On Wed, Sep 7, 2016
Alex Gaynor added the comment:
PEP466 includes hashlib.pbkdf2_hmac(). Any reasoning that includes that surely
is applicable to scrypt as well.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
Bug in the error message "n must be a multiple of 2." it should say "n must be
a power of 2."
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<http
Alex Gaynor added the comment:
- The 2.7 patch contains numerous references to 3.6, these should be rewritten
to 2.7.x
-
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/i
Alex Gaynor added the comment:
+! from me, removing 3DES is a totally sane default, people who need IE8+XP
compat can change the default.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
In this case, performance is security. Both AES-GCM and ChaCha20-Poly1305 are
secure. Modulo one thing: GCM in software is hard to implement in
constant-time, so it's strongly preferable to use it only when there's a
hardware implementation. It works out nicely
Alex Gaynor added the comment:
Exposing it in some way would be good, but we can make that a seperate issue.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
Simply doing AES-GCM before ChaCha20 is probably the simplest thing to start
with, can always get fancier later.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
So, for servers really what we care about is if the _client_ has
PCLMULQDQ/AESNI, not whether the server itself does. Unfortunately, there's no
sane way to do this.
Haven't reviewed this patch in terribly much detail, but conceptually fine.
Cory, we should make
Alex Gaynor added the comment:
I'm opposed to adding FIPS knobs to Python's SSL module for a few reasons:
- FIPS is a bad standard (which I'm happy to talk at length about)
- OpenSSL is regularly on the verge of dropping FIPS support
(https://www.openssl.org/blog/blog/2016/07/20/fips
Alex Gaynor added the comment:
Colm -- how is that situation not addressed by fixing the hash seed generation
specifically, rather than patching all consumers of os.urandom?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27249>
___
__
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27250>
___
__
Alex Gaynor added the comment:
Repeating what a few other folks have said: the of os.urandom's callers
shouldn't have to pay for the hash seed implementation. If Python internally is
ok with suboptimal entropy, it should use a different function. Or early-boot
Python users should set
Alex Gaynor added the comment:
This doesn't look correct to me. Despite what the Linux maintainers insist,
it's a _bug_ that /dev/urandom will return immediately if the system's entropy
pool has never been seeded; one of the whole points of the getrandom syscall is
that it has the correct
New submission from Alex Gaynor:
https://www.openssl.org/news/secadv/20160503.txt
--
keywords: security_issue
messages: 264731
nosy: alex, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden,
zach.ware
priority: normal
severity: normal
status: open
title: Upgrade installers
Alex Gaynor added the comment:
Right now all the hashlib algorithms are backed by OpenSSL. OpenSSL 1.1.0 will
have blake2, so perhaps the right move is just to wait for that to drop in a
few weeks?
Sadly many users with old OpenSSL's still won't have blake2, but pretty quickly
Windows and OS
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Alex Gaynor:
https://openssl.org/news/secadv/20160301.txt
--
keywords: security_issue
messages: 261052
nosy: alex, paul.moore, steve.dower, tim.golden, zach.ware
priority: critical
severity: normal
status: open
title: Upgrade OpenSSL shipped with python installers
New submission from Alex Gaynor:
https://hg.python.org/cpython/file/default/Doc/library/importlib.rst#l1124
the spacing is wrong, it should be:
.. versionchanged:: 3.5
--
assignee: docs@python
components: Documentation
messages: 259263
nosy: alex, docs@python, eric.araujo
New submission from Alex Gaynor:
https://docs.python.org/2/library/crypto.html
https://docs.python.org/3/library/crypto.html
This language has a number of issues:
- Crypto isn't just for "Hardcore cypherpunks" anymore, it's a necessary
component of a great many software projects
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
title: Language on the "Cryptographic Services" is out of date -> Language on
the "Cryptographic Services" documentation page is out of date
___
Python tracker &
Alex Gaynor added the comment:
I agree the tests shouldn't rely on a legacy domain like svn.python.org
In the mean time Ernest is working on getting a valid cert set up.
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
Alex Gaynor added the comment:
There's good news and bad news, which do you want first?
Good news, great!
svn.python.org now has a certificate that's not expired, and it's even trusted
by major trust stores.
Bad news?
The tests rely on the cert for svn.python.org specifically be a cacert
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +benjamin.peterson
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25578>
___
Alex Gaynor added the comment:
fixed
--
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25569>
___
___
P
Alex Gaynor added the comment:
Does this issue still occur on default?
https://hg.python.org/cpython/rev/d80954d941c7
--
nosy: +alex
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Alex Gaynor:
Test.
Put this certificate in a file:
-BEGIN CERTIFICATE-
MIICjTCCAXWgAwIBAgIBADANBgkqhkiG9w0BAQsFADAAMB4XDTE1MTEwNzE1MTAw
NVoXDTE1MTEwNzE1MTAwNVowADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKiZ3rzOM1m6toThRtkwgZzjuVVdapwU63yoXmp91f14pfO1z5XIkVAP1Sz
Alex Gaynor added the comment:
Tests pass and the original script runs without a leak using this patch. It
could probably be shorter if we converted from local returns to `goto fail` or
something, but I don't really have an opinion.
--
___
Python
New submission from Alex Gaynor:
Run the following code:
import socket
import ssl
import sys
def main():
ctx = ssl.create_default_context()
s = socket.create_connection(('www.bing.com', 443))
s = ctx.wrap_socket(s, server_hostname='www.bing.com')
while True
Changes by Alex Gaynor <alex.gay...@gmail.com>:
--
nosy: +christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Alex Gaynor added the comment:
A probably source of the leak is here:
https://github.com/python/cpython/blob/master/Modules/_ssl.c#L1073-L1076 `dps`
is never freed. (This is with OpenSSL 0.9.8zg)
--
___
Python tracker <rep...@bugs.python.org>
Alex Gaynor added the comment:
I think you want sk_DIST_POINT_free actually.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Alex Gaynor added the comment:
Oops, there were a few failing tests on that patch. New one is green
--
Added file: http://bugs.python.org/file40927/sslv3.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
1 - 100 of 471 matches
Mail list logo
