Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

bitecode.dev

Post reply on HN
Print view View original

91–100 of 123 posts

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#91

Post by ssl232 »

appplication wrote: post #20
nerdponx wrote: post #4

Earlier quoted context omitted.

Unlikely: https://discuss.python.org/t/enhance-logging-api-with-pep-8-...

It is interesting to see just how conservative the core devs are against even the most benign way forward (including more consistent aliases without immediate deprecation). Indeed, not a hill worth dying on either way but it’s a little wild the counter argument is “increased support costs” when, let’s be real, there is no significant increased support beyond the initial scope of work. If core Python ever plans on con…

The time to have done it was the first release of Python 3 when everything else was breaking anyway. The ship has sailed.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#92

Post by eesmith »

Kwpolska wrote: post #88
eesmith wrote: post #87

Earlier quoted context omitted.

I think it's odd that PyPI doesn't list any desktop programs, like KeepassXC, at https://pypi.org/help/#twofa , only mobile ones. That makes it seem like 2FA is mobile-only. I expect some people don't want to mix work accounts on their personal phone ("keep your life private"), and because smart phones are still not yet universal, even among developers.

Many people seem to believe that keeping your 2FA keys in an un-backupable mobile app and away from your computer is safer than keeping it in your backupable and multi-device password manager.

Unless you think PyPI is guided by that belief, that doesn't explain why they don't list desktop solutions.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#93

Post by Kwpolska »

fbdab103 wrote: post #62
xorcist wrote: post #59

Earlier quoted context omitted.

And for no particularly good reason! Sure, it's not great, but lots of things aren't. It's at worst a possible footgun, otherwise mostly cosmetic. It should never be acceptable to break working software for anything else than critical security problems.

Not sure I would go that far. APIs need to be able to be deprecated as better forms are identified. That being said, the churn had better be worth it. This datetime change does not qualify, and feels like it is going to cause more immediate pain than it solves.

It is absolutely fine to deprecate badly designed APIs. It is fine if my 5-year-old program is full of deprecation warnings. It is not okay to delete APIs, breaking many programs, unless the APIs are well-known to be totally broken, infeasible to fix/maintain, and barely used.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#94

Post by mrweasel »

motiejus wrote: post #23

OK, a Django update from me. I heavily used Django since version 0.96 (2007) until 1.5 (2014) (with Python 3)! Then came a long break with lower-level infrastructure work: linux kernel, perf tuning, some C, some Go and zig. Last week I picked up Django again. After 10 years (!!!) of not even looking at it. It felt like meeting a good old friend: they are the same, but older and more mature. Conversations are the same…

Same experience from me. I stopped working with Django around 2016 and then picked up a project last year where we picked Django as the framework and it was like I never left. They added new features, improved documentation and all that, but it was so amazingly easy to come to.

It probably does help that we stick to Django 3.X as that's what's currently in Debian.

I do like the smaller frameworks like Flask or Bottle, but if I need a database or anything remotely more complex than answering a few API calls, then I don't see a reason to not pick Django.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#95

Post by Kwpolska »

appplication wrote: post #20
nerdponx wrote: post #4

Earlier quoted context omitted.

Unlikely: https://discuss.python.org/t/enhance-logging-api-with-pep-8-...

It is interesting to see just how conservative the core devs are against even the most benign way forward (including more consistent aliases without immediate deprecation). Indeed, not a hill worth dying on either way but it’s a little wild the counter argument is “increased support costs” when, let’s be real, there is no significant increased support beyond the initial scope of work. If core Python ever plans on con…

Adding new aliases to be consistent with Python's prevalent coding style? Increased support costs, not worth it.

Deprecating often-used APIs like datetime.datetime.utcnow() because they're ugly? Sure, we'll do that, that won't cause anyone problems unless their code is wrong. (At least they didn't set the removal date to be +2 releases = +2 years, as they usually do.)

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#96

Post by globular-toast »

ath0 wrote: post #5

If you read nothing else, the commit message adding JIT support is worth your time: https://github.com/python/cpython/pull/113465

400+ commits with a ton of them being "catch up to main"? Wow, I guess even good programmers don't know how to rebase/use git properly.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#97

Post by globular-toast »

Kwpolska wrote: post #89
samus wrote: post #86

Earlier quoted context omitted.

`git rebase -i develop` is arcane? An editor opens where you put an 'r' in front of every commit that needs rewording. Save and close, and Git will successively open an editor for every commit message. Force Push and you're done. If you're not willing to bother with command line: the Git client in Jetbrains also lets you edit commit messages in a very straightforward way.

Force push can be scary to some. Some nitpickers may also ask you to squash/reorder/split commits to satisfy their OCD.

Those nitpickers are probably people who have tried to track a regression in a big codebase before. It's not OCD, it's just useful version control.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#98

Post by mkesper »

Kwpolska wrote: post #90
legends2k wrote: post #78

Earlier quoted context omitted.

If someone who made the changes can't explain things clearly, I'd even wager that they didn't understand what they're changing properly. A good commit message is needed as the author might be gone but software is maintained for decades. Productivity is easy, writing a good message isn't, as the latter seems to be hard for many and it's telling of their understanding of systems they change.

Many teams will just use squash merges to avoid wasting time on commit messages and end up with just one commit to the main branch and cleaner history.

That's like returning to publishing tarballs instead of having single, revertable commits.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#99

Post by prox »

djha-skin wrote: post #77
jurassic wrote: post #36

While I'm not against security and 2FA in general, making PyPI 2FA mandatory ahead of any kind of org support is a major pain for big projects with more than one maintainer. This week I was forced to link my company's pypi account to a personal device to unblock our latest release and now none of the dozen other maintainers I work with can get access. Things will get spicy if someone in my position were to die, leave…

You were not forced to do that because TOTP is manageable via password manager. TOTP and yubikey are excellent technologies that way. They allow two-factor authentication without breaking privacy. Everyone within the sound of my voice: get a password manager. It sounds like a hassle but it makes your life infinitely better. It allows you to keep your life private and more secure than it was while providing more conve…

So KeepassXC can do TOTP like authy? Cause I would love to switch from that app if I can.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#100

Post by IshKebab »

woodruffw wrote: post #19
IshKebab wrote: post #17

2FA but still no namespaces? Dependency confusion attacks are still trivial on PyPI.

Namespacing does not prevent (or even significantly complicate) dependency confusion, unless we think that there's some difference in confusability between these two errors: requestss and requestss/requests (I think namespacing is a good idea in general, but dependency confusion is mostly a disjoint namespaces problem, not a depth problem. Python could solve the former by doing what Go does and make the source reposi…

I think you have the wrong idea of what dependency confusion is. Here's the scenario:

1. Company develops package `company_secret_project_stuff` and publishes version 1 on their internal private PyPI instance.

2. They tell their employees to install it via `python3 -m pip install --extra-index-url https://pypi.intranet.company.com company_secret_project_stuff`

3. pip dutifully goes and installs the hacker's version of `company_secret_project_stuff` (version 999999) from the global PyPI index.

I know for a fact that my company is vulnerable to this. The only solution currently is for the company to also register `company_secret_project_stuff` on the global PyPI. But you can guess how happy they were about exposing internal package names. They opted to remain vulnerable instead (yes; stupid decision but I can kind of see their point).

Namespaces trivially fix this. You just register the `@company` namespace on the global PyPI index and then make sure all your private packages are in that namespace. Attackers can't publish packages with the same name as yours, and you don't need to make them all public.

Post reply on HN