include 3.8.0rc1 #344
include 3.8.0rc1 #344
Conversation
|
Once again the build fails |
|
Link to the upstream issue: https://bugs.python.org/issue37967. |
|
Automatic key download is a bad idea. It basically means: "trust whatever public key signed this package." |
|
@trishankatdatadog thanks. I am not so good with gpg. Is the other solution the correct one? Where does the Context for those not following the cpython issue
```
It looks like you don't have Łukasz key and your GnuPG is not configured for automatic key download.
Automatic key download works for me: $ gpg --verify Python-3.8.0b4.tgz.asc You could also download the key from keybase: $ gpg --fetch-keys "https://keybase.io/ambv/pgp_keys.asc?fingerprint=e3ff2839c048b25c084debe9b26995e310250568" |
|
@mattip That may be fine as a temporary workaround, but I recommend that the official Python GPG public key list be updated before the final release of 3.8.0. |
|
It seems the resolution of bpo-37967 is to disallow using the pubkeys.txt and to remove it from the python.org website ASAP. A new solution is needed. Is there a gpg expert who can suggest how to fix this line ? Should it be like the other invocation of gpg a few lines above? |
|
@mattip I would not recommend removing pubkeys.txt. The problem is: how do you know what the authoritative keys are? If you trust the public key attached to a signature on a Python tarball, then it could have been signed by anybody. OTOH, this assumes that attackers can sign malicious Python tarballs, but not overwrite pubkeys.txt on the Python website. There needs to be a better long term solution from the Python developers. I personally cannot recommend skipping the proper checking of signatures. |
|
@trishankatdatadog please comment on the cpython issue https://bugs.python.org/issue37967. The decision has apparently already been made. There are recommendations on the downloads link https://www.python.org/downloads/ (in the section marked "OpenPGP Public Keys") to do one of:
Which of the last two is safe (or should we do both)? |
|
@mattip What a bad idea. Let me comment there directly. Thanks. |
|
Sorry to ask, but what is the current status of 3.8 builds for Manylinux? I think the first release candidate is planned for today (30 September)? https://www.python.org/dev/peps/pep-0569/#schedule |
|
The gpg verify stage is still failing. python.org no longer recommends using the pubkeys.txt file, and now lists the fingerprints of the release manager on the download page, and states "You can import a person's public keys from a public keyserver network server you trust by running a command like: |
|
I just did some futzing around. I think the idea is you check https://www.python.org/downloads/ - find the key id of the person, say Steve Dower, with key id "FC62 4643 4870 34E5" and then, assuming that https has protected you from deceit, do: Is that what you meant? |
|
@matthew-brett added that stanza in 4be5453, let's see if it works. |
|
The build succeeds. It would be nice to be able to try out some 3.8 builds before the final release. |
docker/build_scripts/build_env.sh
Outdated
| @@ -1,7 +1,7 @@ | |||
| # source me | |||
|
|
|||
| PYTHON_DOWNLOAD_URL=https://www.python.org/ftp/python | |||
| CPYTHON_VERSIONS="2.7.16 3.4.10 3.5.7 3.6.9 3.7.4" | |||
| CPYTHON_VERSIONS="2.7.16 3.4.10 3.5.7 3.6.9 3.7.4 3.8.0b4" | |||
There was a problem hiding this comment.
updated and changed the PR name appropriately
|
Yes please to having the RC1 for testing wheel builds. |
* include 3.8.0b4 * Add gpg key for 3.8 release manager * use 3.8.0rc1
Try to use
3.8.0b43.8.0rc1 in the manylinux buildscloses #314
closes #313
replaces #333