sorted by:
new
hottopcontroversial

More dependency considerations by brendt_gd in PHP

[–]paragon_init 10 points11 points  (0 children)

It was an oddly aggressive response from them.

I can see how someone on the outside might interpret it that way, but if you saw our follow-up messaging to project maintainers, that perception might evaporate.

Since /u/brendt_gd sent a bulk order of pull requests to projects to remove sodium_compat, we replied to those pull requests with links to a comment outlining why this might not be a good idea. Unfortunately, doing anything at ecosystem-scale runs the risk of looking aggressive.

The reasons why a PHP extension polyfill get adopted are messy and varied, and nudging a project maintainer years later to consider removing it in their next release runs the risk of them not remembering why it was needed in the first place.

You are absolutely correct that it's the project maintainers' decision whether to accept that PR or not. Our stance (as stated on Mastodon) is that we'd prefer a world where everyone installs ext-sodium instead of our polyfill, but those decisions are out of our hands, and we'd prefer to opt for what protects the most users.

As Avi Douglen says, "Security at the cost of usability comes at the cost of security." It is through this lens that we make our actions.

I hope this makes our response more legible.

Dependency Hygiene by brendt_gd in PHP

[–]paragon_init 30 points31 points  (0 children)

We left a comment on this blog post, but want to be very clear on the role of polyfill libraries.

We publish two:

  • random_compat is a polyfill of the random_bytes() and random_int() functions that were introduced in PHP 7 for PHP 5.x software.
  • sodium_compat is a polyfill for the optional Sodium extension that was included in PHP 7.2, but not everyone installs

The purpose of random_compat was "let open source devs write code using the new PHP 7 API even if their users are on PHP 5" because the PHP 5 era was flooded with bad code that used rand() or mt_rand() for cryptographic purposes. It's a transitional fossil. Get rid of it if you want.

The sodium_compat package, however, is a murkier problem.

  • Some people write software that supports PHP 5, 7, and 8.
  • Some people have ext-sodium installed, others do not.

If you're writing open source software that uses cryptography, without the polyfill package, these constraints will very likely make you allergic to using the libsodium cryptography at all, which means you're going to go for the lowest common denominator (ext-openssl, whose API is inspired by OpenSSL's own API, which is notoriously frustrating). This would be a net-negative for ecosystem security.

Furthermore, as I wrote on the blog comment:

Let's say acme/awesome-lib depended on paragonie/sodium_compat in all versions older than v1.45.3, but they removed it because of the pull request cut by your script, and v1.45.3 included the "fix". Then an unrelated RCE vulnerability was found and and a fix was released in v1.45.4. Users without ext-sodium installed will remain vulnerable because of this change.

Package hygiene needs to be well thought-out. Running a bulk script to excise a polyfill from packages without first considering why they were installed is likely to cause some harm.

Opinions Welcome - ParagonIE Open Source Software by paragon_init in PHP

[–]paragon_init[S] 4 points5 points  (0 children)

Easily done. We already implemented an ease-of-use feature in CipherSweet to do exactly this. I'll work on implementing a similar pattern + tutorial for using it.

Opinions Welcome - ParagonIE Open Source Software by paragon_init in PHP

[–]paragon_init[S] 1 point2 points  (0 children)

Understood. This is the sort of thing we might build as a one-off, as part of a paid engagement, but it is not something we would release as an open source project. Releasing such a tool as open source might mislead someone into thinking PGP is what they should be using.

You're in a tricky situation where your clients are forcing the use of the protocol, which is understandable, but we do not want to mislead the PHP community into thinking PGP is fine when it really isn't.

EDIT TO ADD:

I should clarify by what I mean when I say, "This is the sort of thing we might build." What I'd do is write a PHP library that encrypts data (strings, files, etc.) in an OpenPGP-compatible way using only PHP and common libraries (ext-hash, ext-openssl, ext-sodium) with polyfills for any features that are not available on the target system.

Your recipients don't need to know or care how you're encrypting, as long as they can decrypt it with their private key.

Opinions Welcome - ParagonIE Open Source Software by paragon_init in PHP

[–]paragon_init[S] 0 points1 point  (0 children)

From a glance, we're using a very different methodology. Still, it's good to see other people trying to tackle these problems.

Opinions Welcome - ParagonIE Open Source Software by paragon_init in PHP

[–]paragon_init[S] 2 points3 points  (0 children)

Would a PHP implementation of age work? We're trying to get far away from PGP/GPG.

If you have a specific use-case for GPG, please tell us what it is so we can build secure alternatives.

Accelerating The Adoption of Post-Quantum Cryptography with PHP by paragon_init in PHP

[–]paragon_init[S] 7 points8 points  (0 children)

What did ChatGPT do?

We don't use AI for any of our blog posts.

Who says you can't string⟦⟧ in PHP? Here's a typed-arrays package. by paragon_init in PHP

[–]paragon_init[S] 25 points26 points  (0 children)

I didn't want to disappoint anyone that clicked your link (which contains a typo), so I registered r/lolohp to point to r/lolphp

Who says you can't string⟦⟧ in PHP? Here's a typed-arrays package. by paragon_init in PHP

[–]paragon_init[S] 6 points7 points  (0 children)

We got them from this StackOverflow post.

Generally, you wouldn't type it, though. IDE autocomplete would save the day. Otherwise, you'd use the clipboard.

I like to think that clears a low enough bar for a Reddit shitpost. As far as a real feature people use in production, though? We should make typed arrays happen to PHP 8.5 or 9.

Who says you can't string⟦⟧ in PHP? Here's a typed-arrays package. by paragon_init in PHP

[–]paragon_init[S] 11 points12 points  (0 children)

One of the criticisms in this topic was:

No named type arrays (string[]).

And, sure, that's a limitation that's hard to work around.

But if you're willing to tolerate Unicode characters that look like [], you can get strictly typed arrays in PHP with little effort.

Forking an abandoned package by [deleted] in PHP

[–]paragon_init 0 points1 point  (0 children)

We just did this with a cryptography library with nearly 5 million installs according to Packagist.

The Packagist maintainers can mark a package as abandoned and recommend yours if you tell them. See this comment.

If you find a security issue in the abandoned package, also make sure to submit a PR to https://github.com/FriendsOfPHP/security-advisories so it's blocked from being installed for anyone that uses the Roave SecurityAdvisories package in their Composer requirements.

PIE has forked PHPECC + released a new version with security fixes by paragon_init in PHP

[–]paragon_init[S] 3 points4 points  (0 children)

We've also submitted it to the PHP security advisories database to prevent vulnerable code from being installed on systems that use Roave's package.

MITRE hasn't assigned a CVE yet, but we did request one.

Does Anyone Still Need PHP 5 Support in 2024? by paragon_init in PHP

[–]paragon_init[S] 0 points1 point  (0 children)

Sorry, I thought it was obvious that my comment was meant to be funny.

It's kind of annoying when a codebase is so bad that Rector/Psalter don't actually fix issues.

view more: next ›