Re: Updating Flask to 3.x?
Hi Carsten, Am 17.12.23 um 10:06 schrieb Carsten Schoenert: Hi, the Flask team released Flask and the depending package Werkzeug 3.0.0 on 2023-09-30. Since Thomas Goirand did the last update of Flask to 2.2.x nearly one year ago in preparation for the Bookworm release I've talked with Thomas recently about updating Flask and depending packages again so we can get Flask 3.x into the archive. Thomas pointed out he will not have time to work on Flask 3 and some depending packages in the near future. I usual try to keep an eye on some Flask related packages as we use them on my day job. A few of them have now RC issues and are already kicked out of testing. Solving these bug reports are now mostly depending on a newer Flask version or at least it would be more useful to move over to a recent Flask version. Sure, broken packages are no good for anybody. ... Following a simple list of reverse deps for the resulting binary packages. Any help, suggestion or useful hint in maintaining this Flask update is really appreciated! Feel free to contact me if you need help! Best Michael
Re: Python 3.10 in bookworm
Hi Julian, Am 05.02.23 um 11:38 schrieb Julian Gilbey: Why is the current intention not to ship the python3.10 package in bookworm? Because it would amount to about double the work for all those involved. Besides, Python 3.11 has some points for it: - Real performance gains for real workloads - It will be supported one year longer (so EOL is expected to be around the time bookworm will be out of stable, too). I was trying to run some experiments in a virtual environment a few days ago, and it turns out that several of the Python packages I needed do not yet run on Python 3.11. I was saved by being able to run in a Python 3.10 venv and download all the required packages from PyPI. If bookworm shipped without python3.10, I would not have been able to do my work. Removing python3.10 from bookworm will seriously affect many of our users in a similar situation to me. ... P.S. We should also fix #1036268 if we do keep python3.10 in bookworm; I'm happy to do an NMU if needed. Maybe you could sponsor a "backport" of Python3.11? My 2 cents Michael
Re: upstream python concerns, python3-full package for bullseye
Hi all, Am 12.02.21 um 20:52 schrieb Stefano Rivera: > This package is a dependency package, which depends on the full > standard library of Python for Python developers. Including modules > used only at build-time, such as venv and distutils, and modules with > complex dependencies, such as tk and IDLE. Tk and Idle would belong into a hypothetical python3-extra, I guess. This is the first time they're mentioned here, at least as far as my searching skills show. Bye Michael OpenPGP_signature Description: OpenPGP digital signature
Re: upstream python concerns, python3-full package for bullseye
Hi all, Am 12.02.21 um 01:11 schrieb Thomas Goirand: > Hi Elana, > > Thanks for bringing this topic in the channel, and speaking with the > Python Steering Council, plus Mathias and Stefano. That's very much > appreciated. > > On 2/11/21 7:12 PM, Elana Hashman wrote: >> - When users install Python, it should be easy to install all required >> modules for what upstream considers core, including venv, distutils, >> and lib2to3. > > I understand that upstream python guys probably think the way to consume > python stuff is through venv, pip, and setuptools. I have a very > different view on this, and probably I'm not alone. > > We (Debian people) indeed prefer if our user can enjoy a packaged > versions of things if they are available (and that's not specific to > Python). In such a packaged environment, venv and distutils are useless, > as the distribution is taking care of all what these tools would do > without apt or dpkg. I do prefer my system to *not* have venv support, > for example. This seems to be in contrast to how Python gets used by many many people. I think it would be nice if up to date packages of all Python software would exist in Debian but that's clearly not feasible. Using virtualenvs is expected virtually everywhere where Python is mentioned. My 2 cents Michael OpenPGP_signature Description: OpenPGP digital signature
Re: FYI: Python 3 migration of distributuion
Hi Osamu, On 19.11.19 14:43, Osamu Aoki wrote: > FYI: I found this repo > https://gitlab.com/dkg/getmail/commits/python3 > I think this is better work than my local work. I like he's done a commit for each step instead of one big "Turn into Python3" commit. Best Michael signature.asc Description: OpenPGP digital signature
Re: python-urllib3 1.25.6 uploaded to experimental (closes CVE-2019-11236) but fails build tests
Hi all,
On 29.10.19 14:15, Jeremy Stanley wrote:
> On 2019-10-29 13:29:02 +0100 (+0100), Michael Kesper wrote:
>> On 27.10.19 17:27, Drew Parsons wrote:
>>> On 2019-10-27 23:13, Daniele Tricoli wrote:
> [...]
>>>> Not an expert here, but I think fallback is not done on
>>>> purpose due downgrade attacks:
>>>> https://en.wikipedia.org/wiki/Downgrade_attack
>>>
>>> I see. Still an odd kind of protection though. The attacker can
>>> just downgrade themselves.
>>
>> No. A sensible server will not talk to you if your requested SSL
>> version is too low. pub.orcid.org seems to use absolutely outdated
>> and insecure software versions.
>
> Well, downgrade attacks aren't usually a two-party scenario. The
> risk with a downgrade attack is when a victim client attempts
> communication with some server, and a third-party attacker tampers
> with the communication between the client and server sufficiently to
> cause protocol negotiation to fall back to an old enough version
> that the attacker can then exploit known flaws to decrypt and/or
> proxy ("man in the middle") that communication. Having both the
> client and the server be unwilling to use susceptible older protocol
> versions helps thwart this attack vector.
Ah, you're right.
So the right fix would be to remove this possibility from urllib3.
This, however, would break applications that need to use these insecure
connections.
At the least, I don't think build tests should fail if software
refuses to use deprecated and insecure connections.
Bye
Michael
signature.asc
Description: OpenPGP digital signature
Re: python-urllib3 1.25.6 uploaded to experimental (closes CVE-2019-11236) but fails build tests
Hi all,
On 27.10.19 17:27, Drew Parsons wrote:
> On 2019-10-27 23:13, Daniele Tricoli wrote:
>> On Sun, Oct 13, 2019 at 10:31:31PM +0800, Drew Parsons wrote:
>>> It conditionally works. Using curl, I found that TLSv1_0 or TLSv1_1 will
>>> support a successful connection, but only if the maximum SSL_VERSION is
>>> constrained to TLSv1_0 or TLSv1_1 (e.g. curl -v --tlsv1.1 --tls-max 1.1
>>> https://pub.orcid.org). Without the max, the connection fails:
>>> $ curl --tlsv1.1 https://pub.orcid.org
>>> curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
>>> failure
>>>
>>> The urllib3 failure was similar, but I do not know how to set tls-max with
>>> urllib3. I could only find the option with curl. I could set up a custom
>>> HTTPAdapter as suggested at
>>> https://requests.readthedocs.io/en/master/user/advanced/#example-specific-ssl-version
>>> to set ssl_version=ssl.PROTOCOL_TLSv1_1 but the ssl module doesn't have the
>>> SSLVERSION_MAX_TLSv1_1 value that curl has. I could solve it with pycurl
>>> using c.setopt(pycurl.SSLVERSION, pycurl.SSLVERSION_TLSv1_1 |
>>> pycurl.SSLVERSION_MAX_TLSv1_1)
>>
>> For sure I'm missing something, but why not just set TLS version?
>> I tried the following on both Python2 and Python3:
>>
>> >>> import ssl
>> >>> from urllib3.poolmanager import PoolManager
>> >>> http = PoolManager(ssl_version=ssl.PROTOCOL_TLSv1)
>> >>> r = http.request('GET', 'https://pub.orcid.org')
>> >>> r.status
>> 200
>
>
> That's a good tip, I missed that permutation. I was originally trying to
> access using the requests module, so didn't think to do it directly with
> urllib.PoolManager
>
>
>>
>>> Evidently the orcid server only supports TLSv1.0 and TLSv1.1 and no higher
>>> (why haven't they activated TLSv1.3 yet?!), while curl and urllib3 without
>>> tls-max first test TLSv1.3 and then quit without cascading downwards once
>>> they receive the TLSv1.3 handshake failure. Which is rather odd behaviour
>>> when I think about it. The whole point of supporting multiple protocol
>>> versions is to try the next available version if the first one doesn't work.
>>
>> Not an expert here, but I think fallback is not done on purpose due downgrade
>> attacks: https://en.wikipedia.org/wiki/Downgrade_attack
>
>
> I see. Still an odd kind of protection though. The attacker can just
> downgrade themselves.
No. A sensible server will not talk to you if your requested SSL version is too
low.
pub.orcid.org seems to use absolutely outdated and insecure software versions.
Bye
Michael
signature.asc
Description: OpenPGP digital signature
Re: Help needed for issue in test suite for Python3 (Was: Bug#937698: python-dendropy: Python2 removal in sid/bullseye)
Hi Andreas, On 08.10.19 09:28, Andreas Tille wrote: > Control: tags -1 help > > Hi, > > I have prepared a fix for this package in Git[1]. Unfortunately I'm > stumbling upon a test suite error which was discussed with upstream > previously. It happens only for Python3 and was ignored before but > this strategy seems to be inappropriate now after droping Python2. Have a look at the upstream Git repo. Some tests may be fixed there, e.g. https://github.com/jeetsukumaran/DendroPy/commit/732860830dd3540e43a9465f30df2448c3063d15#diff-76312737381b7c7b05611640b5c3992f Best wishes Michael signature.asc Description: OpenPGP digital signature
Re: dh-python does not stop if there is error during the byte-compiling
Hi Frederic, On 06.10.19 10:37, PICCA Frederic-Emmanuel wrote: > Hello, in one of my package (pymca), there is a syntax error like this. > > byte-compiling > /builds/science-team/pymca/debian/output/pymca-5.5.2+dfsg/debian/python-pymca5/usr/lib/python2.7/dist-packages/PyMca5/Object3D/Object3DPlugins/ChimeraStack.py > to ChimeraStack.pyc > File > "/usr/lib/python2.7/dist-packages/PyMca5/Object3D/Object3DPlugins/ChimeraStack.py", > line 72 > with h5py.File(filename, mode='r') as f > ^ > SyntaxError: invalid syntax > > byte-compiling /builds/science-team/pymca > > (missing ':' at the end of the line) but this does not stop the build process. As far as I understand the sourcecode from glancing at it, that is not intended (except for pypy3compile due to its freshness). So maybe it would be helpful to look at the options with which you called the whole process. Best wishes Michael signature.asc Description: OpenPGP digital signature
Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
Hi Andreas,
On 16.09.19 11:38, Andreas Tille wrote:
> Hi Peter,
>
> On Sun, Sep 15, 2019 at 02:47:50PM +0100, peter green wrote:
tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
>>>
>>> Thanks to this hint
>> This hint was *wrong*, it will introduce garbage into the string and the
>> "rotor" code is clearly designed to work with byte strings, not unicode
>> strings.
>>
>> Change it to
>>
>> "tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )"
Oops, got that backwards. Thanks for spotting this.
> Thanks a lot for your patience. Unfortunately this is not
> yet the final solution:
>
> ...
> Traceback (most recent call last):
> File "/usr/bin/cycle", line 83, in OnCloseWindow
> Save_Cycle(cycle.name, cycle.passwd, cycle.file)
> File "/usr/share/cycle/save_load.py", line 46, in Save_Cycle
> tmp=rt.encrypt( b'Cycle'+pickle.dumps(objSave) )
> File "/usr/share/cycle/p_rotor.py", line 63, in encrypt
> return self.cryptmore(buf, 0)
> File "/usr/share/cycle/p_rotor.py", line 88, in cryptmore
> c = rotors[i][c ^ pos[i]]
> TypeError: unsupported operand type(s) for ^: 'int' and 'float'
That code could be patched by using int() around potentially float
numbers. But honestly, it should better be ripped out and use
real encryption. The docstring tells so:
The rotor module has been removed from the Python 2.4
distribution because
the rotor module uses an insecure algorithm and is deprecated.
==
Best wishes
Michael
signature.asc
Description: OpenPGP digital signature
Re: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye
Hi,
On 12.09.19 16:09, Andreas Tille wrote:
> May be some final helping hint could be how to fix leaving the
> program that leads to:
>
>
> Traceback (most recent call last): File "/usr/bin/cycle", line 83,
> in OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file)
> File "/usr/share/cycle/save_load.py", line 27, in Save_Cycle
> m.update(passwd) TypeError: Unicode-objects must be encoded before
> hashing
>
>
> I tried
>
> m.update(passwd.encode())
>
> but this leads later to
>
> Traceback (most recent call last): File "cycle.py", line 83, in
> OnCloseWindow Save_Cycle(cycle.name, cycle.passwd, cycle.file) File
> "/home/andreas/debian-maintain/salsa/med-team/cycle/save_load.py",
> line 46, in Save_Cycle tmp=rt.encrypt( 'Cycle'+pickle.dumps(objSave)
> ) TypeError: can only concatenate str (not "bytes") to str
>
>
> Since I do not have much experience with hashlib I'd be happy if
> someone might be able to proof-read `def Save_Cycle` in
> save_load.py.
This does not have anything to do with hashlib per se.
It's just the usual mess of mixing bytestrings with strings.
You often don't notice in Python2, it just introduces subtle bugs.
Python3 is more strict here and doesn't allow it.
Try this:
tmp = rt.encrypt('Cycle{}'.format(pickle.dumps(objSave)))
As an explanation:
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> s = 'abc123üöß'
>>> objSave = pickle.dumps(s)
>>> objSave
b'\x80\x03X\x0c\x00\x00\x00abc123\xc3\xbc\xc3\xb6\xc3\x9fq\x00.'
>>> type(objSave)
>>> print('Cycle'+pickle.dumps(objSave))
Traceback (most recent call last):
File "", line 1, in
TypeError: can only concatenate str (not "bytes") to str
>>> print('Cycle{}'.format(pickle.dumps(objSave)))
Cycleb'\x80\x03C\x16\x80\x03X\x0c\x00\x00\x00abc123\xc3\xbc\xc3\xb6\xc3\x9fq\x00.q\x00.'
Best wishes
Michael
P.S.: The code is in a bad state regarding whitespace / indentation.
This is critical to get right in Python (e.g. after a for there _has to_
be an indentation added, Python normally uses four spaces, no tabs).
signature.asc
Description: OpenPGP digital signature
Re: 2to3 adds '.' in front dir of "from dir import ..." statements (Was: [MoM] lefse migration to python 3])
Hi all, On 12.09.19 08:30, Thomas Goirand wrote: > I wont comment on the relative import ambiguity problem, as Ghislain > replied correctly. However, I do want to comment on 2to3. > > I generally recommend against using it, in the favor of other tools. ... > > The advantage is that you'll get a source code that will work on both > Python 2 and 3. It's generally a way more easy to submit upstream, which > may not want to loose Python 2 compatibility. We should stop caring about that. Python2 will be EOL'ed at January 1, 2020 [0]. Python2 will vanish from next Debian release. Please convert into idiomatic Python3 code, that's the sane way going forward. Best regards Michael [0] https://github.com/python/devguide/pull/344 https://pythonclock.org/ signature.asc Description: OpenPGP digital signature
