On 2020-03-10 17:55, Greg Troxel wrote:
I'm not trying to be critical of the security policy and I'm not pushing for a dependency.Jason Bacon <outpaddling%yahoo.com@localhost> writes:If we're going to adhere to that policy at the expense of common tools not working out-of-the-box, maybe there's something else we can do for curl users like patch in a user-friendly message stating that it's a security policy and suggesting mozilla-rootcerts-openssl when this type of failure occurs."working" and "good security properties" are two different things, and different people have difference opinions. If you want to bring up on tech-pkg that pkgsrc should by default force the mozilla root certs to be installed whenever *any package* that uses openssl is installed, we can have that discussion. I think it's got to be either "this is the pkgsrc way" or "this is not the pkgsrc way" for automatic (with a user tunable since obviously if we change not everybody is ok with that), and that "I installed R and now my trust anchors have changed" is madness (for any value of R :-).
I'm just looking at it from the perspective of potential new developers and suggesting a solution that will prevent them from being scared off.
The fact is pkgsrc curl out-of-the-box will fail to download many https URLs where most other curl binaries will succeed. People unfamiliar with the pkgsrc security policy will likely see this as a bug and develop a poor first-impression of pkgsrc. All we'd have to do in this case is see where curl is printing the error message and add another print suggesting that the user might need mozilla-rootcerts-openssl.
I'm fine with with the security policy, but I think if new users are going to encounter apparent problems that they don't see with other package managers, it would be good for the project to quickly provide the reasons and solutions wherever possible. We can easily turn a negative experience into a positive in this case.
JB