Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
donaldstufft
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
by
donaldstufft
3y ago
GPG/PGP is worse than nothing, because it provides an illusion of security in the majority of use cases unless you build significant infrastructure around it to the point that you're really just using it for access to it's
32.
▲
by
donaldstufft
3y ago
Because the existing tool does a bad job at all of them, and those tools do reasonably good jobs at each of their respective tasks. Fundamentally the things you want from a secure crypto system differ depending on the context in which you&#
33.
▲
by
donaldstufft
3y ago
gpg signatures are not, and have never been a meaningful "best practice". The only secure package signing schemes that have ever used gpg signatures, uses gpg as a mechanism to access crypto primitives and has built their own secu
34.
▲
by
donaldstufft
3y ago
If people want checksums, it seems like it would be better for everyone around to just use checksums? If you just want to make sure that some file hasn't changed, that's a much better primitive for that then signatures. To me the
35.
▲
by
donaldstufft
3y ago
How is checking for null any different than checking for the right type in general in TOML?
36.
▲
by
donaldstufft
3y ago
There's not a singular thing at fault. Though there is nothing inherently free or decentralized about "PKI", and given your conflation of those concepts I suspect that you're not actually aware of where the lines are dra
37.
▲
by
donaldstufft
3y ago
Debian is basically the reason we didn't delete PGP signature support in 2018, because in theory some handful of Debian packages might be better off with this support. In practice I think the handful of packages that this happens on is
38.
▲
by
donaldstufft
3y ago
> A bullet proof HOWTO can fix all of this You cannot document your way out of a usability nightmare.
39.
▲
by
donaldstufft
3y ago
To my knowledge, everything in the Python packaging ecosystem that supports PGP signatures, does so by shelling out to the `gpg` command. Presumably gpg should be implementing the spec properly.
40.
▲
by
donaldstufft
4y ago
Not really, none of those things are things he is suggesting PyPI should do, but rather social expectations that come from being a maintainer of a large project.
41.
▲
by
donaldstufft
4y ago
- https://python-security.readthedocs.io/pypi-vuln/index-2022-... - https://www.mend.io/resources/blog/npm-package-javascript-li...
42.
▲
by
donaldstufft
4y ago
PyPI doesn't currently prevent deletions at all, so a maintainer can just flat out delete their stuff if they want. Though we are discussing if we want to tighten that up at all. I would say that in the > 10 years of time I've
43.
▲
by
donaldstufft
4y ago
All major repositories editorialize to some extent, they would be awful if they did not. For instance, PyPI will take down your software if we determine it to be malicious in some way, which is extending editorial control over what's o
44.
▲
by
donaldstufft
8y ago
Honestly, this is kind of FUDish and assumes the worst case scenario for upstream developers, and the best case scenario for the distro maintainers. Another way of phrasing what this extra layer of maintainers provides, is a second group of
45.
▲
by
donaldstufft
9y ago
> This is the weakest argument. Are Python devs somehow dumber than Java devs? Are they dumber than Android devs? Are they dumber than iOS devs? Everyone knows how to sign a dependency/app/project except python devs? I don'
46.
▲
by
donaldstufft
9y ago
> Herd immunity. Someone is out there reviewing it. More likely everyone assumes someone else is reviewing it, and nobody actually does.
47.
▲
by
donaldstufft
9y ago
> Key X is on the company approved key list, key y is not. Your argument just fell apart. A minuscule amount of people are going to bother to do something like approve keys. Security for the minority can already be achieved by those comp
48.
▲
by
donaldstufft
9y ago
Package signing doesn't achieve anything without a trust model behind it, which is exactly what that post states. Too many people go "we need to add some crypto to this thing!" without developing a threat model and that ends
49.
▲
by
donaldstufft
10y ago
It's a few things. One of the simplest reasons is as you identified, it's easier to get smaller donations from multiple people than it is to get one large donation from a single company (although we do have large donations too ran
50.
▲
A Year of PyPI Downloads
(caremad.io)
6 points
by
donaldstufft
11y ago
|
4 comments
51.
▲
by
donaldstufft
12y ago
That already exists, setuptools has supported it for years and years. Nobody uses it though and they prefer to use virtualenv instead. That may be because setuptools itself wasn't that great, or it may be that people just didn't p
52.
▲
by
donaldstufft
12y ago
Oh, and to be clear. When I argued for PEP 453 I was very explicitly against doing anything that meant pip wasn't upgradeable on it's own outside of the standard library release cycle.
53.
▲
by
donaldstufft
12y ago
distutils being built into the stdlib means that it's not very easy to improve the tooling by improving that module, since it's tied to the Python release and people can't depend on a new python release for many years. setupt
54.
▲
by
donaldstufft
12y ago
With Python 3.3 the venv module is now part of the standard library and the interpreter itself has been modified to support the isolation that the virtualenv had to use hacks to make happen. In Python 3.4 the venv module installs pip by def
55.
▲
by
donaldstufft
13y ago
Assuming we've released a newer version of pip when 3.4.1 is released :)
56.
▲
by
donaldstufft
13y ago
Both kind of! Added to the stdlib was "ensurepip", which is a simple installer for pip. The ensurepip module includes inside of it a copy of pip that it will install from (in other words, ensurepip doesn't hit the network). T
57.
▲
by
donaldstufft
13y ago
You can't document your way out of a usability problem.
58.
▲
by
donaldstufft
13y ago
It's midnight without a date, however if there is a timezone attached to the time then it's midnight utc unless the utc offset of the time is a negative value, then it's never.
59.
▲
by
donaldstufft
13y ago
To take it from the same James Coglan -> "You can't add midnight to 3-o'clock in the same way you can't add London to Chicago."
60.
▲
by
donaldstufft
13y ago
The entire site is Open Source. If you rely on obscurity for security then you've done it wrong. VPN and the like would be nice but not hardly required.
More ›