2 ms·

> I also don't think the "we're just a poor bunch of small-time package maintainers whose package accidentally became popular" angle quite works, because they c

> I also don't think the "we're just a poor bunch of small-time package maintainers whose package accidentally became popular" angle quite works, because they call themselves the "Python Cryptographic Authority" and use the prominent package name `cryptography`, which certainly appears to imply some sort of official status. Author here; I think you might have misunderstood this point. It’s not about official status, blessing, size, or, funding: it’s the fact that cryptography (and many other things) are hard to do safely and reliably across multiple platforms, when the common layer of interaction is fundamentally unreliable. The problem here isn’t your own initiative (by all means, compile anything on any architecture you please), but whether it’s reasonable for projects to pretend to paper over those unreliabilities (and, in doing so, accept responsibility for platforms they didn’t want to support in the first place). My intuition is that it isn’t reasonable on its own, and that expecting maintainers to do this (particularly when so much of it boils down to free corporate support) is unfair and a security hazard.

gavinhoward 4y ago
Blogger who wrote a blog post about this too. [1] I disagree with you somewhat. > expecting maintainers to do this (particularly when so much of it boils down to free corporate support) is unfair and a security hazard. This would be true if its premise was true, but its premise is not quite true. One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. If the latter wanted to charge for work on the library, he certainly could. The former probably gets paid to work on it already. So yeah, I'd expect something better from them. [1]: https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of-replacing-c/ https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of...
- woodruffw 4y ago
  > One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. I don't know where you got this from. I know Cryptography's maintainers well, and neither works at Red Hat or owns a security company. I know for a fact that neither gets paid to work on Cryptography. Even if they did, there is no guarantee that having a job in a company grants you the mandate (or latitude) to maintain support for random platforms, especially ones used by other companies.
ris 4y ago
> The problem here isn’t your own initiative (by all means, compile anything on any architecture you please), but whether it’s reasonable for projects to pretend to paper over those unreliabilities (and, in doing so, accept responsibility for platforms they didn’t want to support in the first place). Borderline agree, though the debate around this post always expanded to cover projects in general (which is not your fault).
- woodruffw 4y ago
  Yep -- I don't want this post to be read as a dictum, but as an identification of a conflict between two principles the OSS communities generally tries to uphold: we all generally agree that (1) we should be able to do whatever we like with free and open software, and (2) that maintainers are not responsible for what we do, or for fixing our problems. Open source ate the world, which has meant a heavy lilt towards (1): we see people go out and do stuff without questioning the underlying design and system invariants that made a piece of open source software secure and desirable in the first place. That ends up eroding (2); I'd like to see us rebalance a bit back towards maintainers' interests.

gavinhoward 4y ago

Blogger who wrote a blog post about this too. [1] I disagree with you somewhat. > expecting maintainers to do this (particularly when so much of it boils down to free corporate support) is unfair and a security hazard. This would be true if its premise was true, but its premise is not quite true. One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. If the latter wanted to charge for work on the library, he certainly could. The former probably gets paid to work on it already. So yeah, I'd expect something better from them. [1]: https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of-replacing-c/ https://gavinhoward.com/2021/02/rust-zig-and-the-futility-of...

woodruffw 4y ago
> One of the maintainers works for Red Hat Security Engineering. Another has a computer security company. I don't know where you got this from. I know Cryptography's maintainers well, and neither works at Red Hat or owns a security company. I know for a fact that neither gets paid to work on Cryptography. Even if they did, there is no guarantee that having a job in a company grants you the mandate (or latitude) to maintain support for random platforms, especially ones used by other companies.

ris 4y ago

> The problem here isn’t your own initiative (by all means, compile anything on any architecture you please), but whether it’s reasonable for projects to pretend to paper over those unreliabilities (and, in doing so, accept responsibility for platforms they didn’t want to support in the first place). Borderline agree, though the debate around this post always expanded to cover projects in general (which is not your fault).

woodruffw 4y ago
Yep -- I don't want this post to be read as a dictum, but as an identification of a conflict between two principles the OSS communities generally tries to uphold: we all generally agree that (1) we should be able to do whatever we like with free and open software, and (2) that maintainers are not responsible for what we do, or for fixing our problems. Open source ate the world, which has meant a heavy lilt towards (1): we see people go out and do stuff without questioning the underlying design and system invariants that made a piece of open source software secure and desirable in the first place. That ends up eroding (2); I'd like to see us rebalance a bit back towards maintainers' interests.