I tried registering today and accidentally found that the password requirement validator on Broadcom's registration form has EVEN MORE "quirks" than you already presented. Apparently, the "Should not have three or more consecutive characters that match any portion of the user email address" requirement on their website is checked by generating a regex without escaping user input and validating with that. The form disappears as soon as you start inputting a password...
@pganssle that's alright but you can just install the pip package then since you do need it. It's just that generally, it doesn't seem to me like it should really be a part of the base package.
@pganssle system pip makes some amount of sense for --user maybe (but why not venv for libs or pipx for apps?) but if you're not using that then you're dealing with packages that are externally managed by dnf so is there really a point? IMO, the more important thing is whether it ships venv/ensurepip or not. Debian/Ubuntu cripples Python like that and that's a bit too much. Not having system Python also makes using `pip` instead of `python -m pip` safer since you can't accidentally run it using system pip then.
@hynek @nedbat @zzzeek it all depends on the type of code you write I suppose because I would say that mypy is the lowest common denominator as pyright covers typing more fully than mypy. It doesn't have plugins which is the downside when neither can support some construct and *someone* develops a mypy plugin for it but not many do.
Hey so, I’m not a lawyer, but I think this important enough to toot.
If you’re like me and you’re not legally married, and you don’t have much blood family or you’re estranged or your family is found, have a will, and put specific funeral and burial arrangements in it. Even if you’re 30. Even if your partner or found family has complete legal and medical power of attorney already. Be explicit in legally binding writing.
In my state and probably others, POA is basically useless upon death. Unless there is an immediate blood relative there, the state takes over a bunch of funeral decisions and power of attorney means about diddly squat. Just please, do it.
@bstacey I agree with what you're arguing for but I'm not sure I find the arguments convincing. As a counter, "Using search engine" *is* most definitely an important skill yet I wouldn't say it has a reproducible behavior (there are certain practices that help get good results but they don't guarantee it) or that it's built to be right since it all depends on its index that constantly changes and external websites that are largely unconfirmed sources or sometimes even babble.
@doughellmann any of the backends mentioned here, really (or poetry if you're into its opinionated workflow):
https://packaging.python.org/en/latest/tutorials/packaging-projects/#creating-pyproject-toml
It's perhaps important to note that if you're using setuptools, there's nothing wrong with that, you might just need to update how you use it to not use deprecated stuff (unless you actually *want to* be adventurous and try out something new). It's hard to suggest anything specific without knowing what deprecation you're running into.
@adamchainz hi, I never received that email so I just want to make sure that it wasn't lost in transit and you just haven't sent it yet.
@hynek are you sure about the 2fa part? I've been using environment for a long while and I don't recall ever being asked for the second factor when approving the environment to run.
@treyhunner I wish that the built-in vars worked with classes that don't have a `__dict__` (slotted classes). The best you can do is manually iterate through slots and use getattr with all of them but that's a hassle.
@adamchainz me (at) jacken.men, you can also find it listed on my GitHub profile.
@adamchainz welp, I was wrong, this was implemented a week ago! Now I can use `LESS_LINES=-2` to put 2 lines of bottom margin in `less` which makes it work better on exit with my 3-line prompt. I'm told the performance may be suboptimal but so far I'm happy with it.
@cocoaphony @b0rk@social.jvns.ca I'm a strict chronological (sic! I scroll up, not down because no app offers such order) Twitter/Mastodon user however I do see value in algorithm-driven replies because I generally don't (and realistically can't) read through all replies to a post and that gives an unfair advantage to people that posted earlier. The downside is that an engagement-based algorithm can tend to put more heated debates at the top and can put you on a downward spiral.
@willmcgugan not to say that discerning between objects requires id specifically but what's the alternative that would universally work in a default repr? I'm first to change default repr since I don't find it all too useful but I have to know what aspects of a specific type are useful to be able to provide a better custom repr. Having id in repr is certainly better than if it just said `<ClassName object>`
@willmcgugan I consider being able to discern between two objects part of repr's usefulness during debugging. I expect repr to tell me enough about the object so that I don't have to look through its attributes (or id()) to learn basic things about it.
@willmcgugan would be great if one could still look at two objects and know whether they're the same or different objects. Custom repr typically shows enough information to at least know whether they represent equivalent information, but how would a default repr ensure that?
I recently wrote a post detailing the recent #LastPass breach from a #password cracker's perspective, and for the most part it was well-received and widely boosted. However, a good number of people questioned why I recommend ditching LastPass and expressed concern with me recommending people jump ship simply because they suffered a breach. Even more are questioning why I recommend #Bitwarden and #1Password, what advantages they hold over LastPass, and why would I dare recommend yet another cloud-based password manager (because obviously the problem is the entire #cloud, not a particular company.)
So, here are my responses to all of these concerns!
Let me start by saying I used to support LastPass. I recommended it for years and defended it publicly in the media. If you search Google for "jeremi gosney" + "lastpass" you'll find hundreds of articles where I've defended and/or pimped LastPass (including in Consumer Reports magazine). I defended it even in the face of vulnerabilities and breaches, because it had superior UX and still seemed like the best option for the masses despite its glaring flaws. And it still has a somewhat special place in my heart, being the password manager that actually turned me on to password managers. It set the bar for what I required from a password manager, and for a while it was unrivaled.
But things change, and in recent years I found myself unable to defend LastPass. I can't recall if there was a particular straw that broke the camel's back, but I do know that I stopped recommending it in 2017 and fully migrated away from it in 2019. Below is an unordered list of the reasons why I lost all faith in LastPass:
- LastPass's claim of "zero knowledge" is a bald-faced lie. They have about as much knowledge as a password manager can possibly get away with. Every time you login to a site, an event is generated and sent to LastPass for the sole purpose of tracking what sites you are logging into. You can disable telemetry, except disabling it doesn't do anything - it still phones home to LastPass every time you authenticate somewhere. Moreover, nearly everything in your LastPass vault is unencrypted. I think most people envision their vault as a sort of encrypted database where the entire file is protected, but no -- with LastPass, your vault is a plaintext file and only a few select fields are encrypted. The only thing that would be worse is if...
- LastPass uses shit #encryption (or "encraption", as @sc00bz calls it). Padding oracle vulnerabilities, use of ECB mode (leaks information about password length and which passwords in the vault are similar/the same. recently switched to unauthenticated CBC, which isn't much better, plus old entries will still be encrypted with ECB mode), vault key uses AES256 but key is derived from only 128 bits of entropy, encryption key leaked through webui, silent KDF downgrade, KDF hash leaked in log files, they even roll their own version of AES - they essentially commit every "crypto 101" sin. All of these are trivial to identify (and fix!) by anyone with even basic familiarity with cryptography, and it's frankly appalling that an alleged security company whose product hinges on cryptography would have such glaring errors. The only thing that would be worse is if...
- LastPass has terrible secrets management. Your vault encryption key always resident in memory and never wiped, and not only that, but the entire vault is decrypted once and stored entirely in memory. If that wasn't enough, the vault recovery key and dOTP are stored on each device in plain text and can be read without root/admin access, rendering the master password rather useless. The only thing that would be worse is if...
- LastPass's browser extensions are garbage. Just pure, unadulterated garbage. Tavis Ormandy went on a hunting spree a few years back and found just about every possible bug -- including credential theft and RCE -- present in LastPass's browser extensions. They also render your browser's sandbox mostly ineffective. Again, for an alleged security company, the sheer amount of high and critical severity bugs was beyond unconscionable. All easy to identify, all easy to fix. Their presence can only be explained by apathy and negligence. The only thing that would be worse is if...
- LastPass's API is also garbage. Server-can-attack-client vulns (server can request encryption key from the client, server can instruct client to inject any javascript it wants on every web page, including code to steal plaintext credentials), JWT issues, HTTP verb confusion, account recovery links can be easily forged, the list goes on. Most of these are possibly low-risk, except in the event that LastPass loses control of its servers. The only thing that would be worse is if...
- LastPass has suffered 7 major #security breaches (malicious actors active on the internal network) in the last 10 years. I don't know what the threshold of "number of major breaches users should tolerate before they lose all faith in the service" is, but surely it's less than 7. So all those "this is only an issue if LastPass loses control of its servers" vulns are actually pretty damn plausible. The only thing that would be worse is if...
- LastPass has a history of ignoring security researchers and vuln reports, and does not participate in the infosec community nor the password cracking community. Vuln reports go unacknowledged and unresolved for months, if not years, if not ever. For a while, they even had an incorrect contact listed for their security team. Bugcrowd fields vulns for them now, and most if not all vuln reports are handled directly by Bugcrowd and not by LastPass. If you try to report a vulnerability to LastPass support, they will pretend they do not understand and will not escalate your ticket to the security team. Now, Tavis Ormandy has praised LastPass for their rapid response to vuln reports, but I have a feeling this is simply because it's Tavis / Project Zero reporting them as this is not the experience that most researchers have had.
You see, I'm not simply recommending that users bail on LastPass because of this latest breach. I'm recommending you run as far way as possible from LastPass due to its long history of incompetence, apathy, and negligence. It's abundantly clear that they do not care about their own security, and much less about your security.
So, why do I recommend Bitwarden and 1Password? It's quite simple:
- I personally know the people who architect 1Password and I can attest that not only are they extremely competent and very talented, but they also actively engage with the password cracking community and have a deep, *deep* desire to do everything in the most correct manner possible. Do they still get some things wrong? Sure. But they strive for continuous improvement and sincerely care about security. Also, their secret key feature ensures that if anyone does obtain a copy of your vault, they simply cannot access it with the master password alone, making it uncrackable.
- Bitwarden is 100% open source. I have not done a thorough code review, but I have taken a fairly long glance at the code and I am mostly pleased with what I've seen. I'm less thrilled about it being written in a garbage collected language and there are some tradeoffs that are made there, but overall Bitwarden is a solid product. I also prefer Bitwarden's UX. I've also considered crowdfunding a formal audit of Bitwarden, much in the way the Open Crypto Audit Project raised the funds to properly audit TrueCrypt. The community would greatly benefit from this.
Is the cloud the problem? No. The vast majority of issues LastPass has had have nothing to do with the fact that it is a cloud-based solution. Further, consider the fact that the threat model for a cloud-based password management solution should *start* with the vault being compromised. In fact, if password management is done correctly, I should be able to host my vault anywhere, even openly downloadable (open S3 bucket, unauthenticated HTTPS, etc.) without concern. I wouldn't do that, of course, but the point is the vault should be just that -- a vault, not a lockbox.
I hope this clarifies things! As always, if you found this useful, please boost for reach and give me a follow for more password insights!
@pradyunsg Additionally, building from sdist allows you to specify a more detailed error message than the generic one you would get from a failure caused by either lack of binary wheels or pip refusing to install from sdist. I feel like I also have seen some cool examples of using setup.py for something that isn't actually building a package but I don't have any concrete examples for that so I might be making that up.
I will say that the safety aspect of disallowing sdist installation by default is tempting though. Won't help if I'll just have to tell users to use the flag (due to a dependency, not me directly) but still, it is a tempting picture. Personally I am most interested about the aspect of me making typos though - I have made typos in package names and forgot `-r` flag way too often... I would love to have pip ask me (probably with a timeout by default for back-compat reasons), prompts me for confirmation before installing the package.
Python packaging
@pradyunsg I like that the way it currently works is more forgiving to maintainers who may not have the time to set up a CI for building wheels and doing any changes that may be required by it.
For x86_64 you can nowadays generally expect wheel to be present, but in case of any other arch it's generally not as good.
macOS arm64 is new enough that there's probably still some packages that don't support it.
manylinux aarch64 is generally built using an emulation (not many free CI platforms that have aarch64) which is both slow and not necessarily identical to real hardware (psutil seems to have this problem).
manylinux armhf doesn't even exist and running Raspberry Pi OS with piwheels.org only works with the Python version distributed by the system.
Coverage of other architectures (ppc64le, s390x) and non-glibc (musllinux) in most packages on PyPI is mostly non-existent. I don't use them but I think it would be a shame to add another bump on the road for those users. Any new architecture that may become popular in the future will also suffer the same problem.
Python packaging
So... I'm thinking that it'd be good for pip to stop installing from source distributions by default. It's a large and disruptive change though, and I'm trying to figure out what that disruption will look like.
Thoughts?
Also, that's a fun content warning and boosts would be appreciated coz I don't have followers. :)
Python OSS contributor, maintainer of Red-DiscordBot (http://discord.red)