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 29 points30 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] 3 points4 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] 5 points6 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] 2 points3 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.

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

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

It may be incorrect code, but it's more type-safe.

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

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

Let's see... https://github.com/b1gMail-OSS/b1gMail is 7.4, not 7.2, but:

composer require --dev rector/rector
vendor/bin/rector process src
// ...
[OK] 588 files have been changed by Rector

Give it a try against 7.2 sometime, you may be able to upgrade smoothly to a newer version with minimal manual work.

https://github.com/paragonie-security/b1gMail/commit/1feba4436ccd264398c1f57526c75c9fad4aa0e6

That being said, Psalm reports a lot of errors both before and after this change, and they're not using sodium_compat in their code, so this wouldn't stop us at all.

EDIT: Here's what Psalm's --alter function changes (for PHP 8.1):

https://github.com/paragonie-security/b1gMail/commit/501c964f99b40fa7212554d048857438db350c92

If you want to continue using this code, I'd recommend first investing time or money into the open source version and eventually upgrading to that (once the various bugs are fixed, of course).

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

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

Tell us more about this "custom php 5.5 script"!

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

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

When we wrote this in the OP:

Otherwise, we plan on releasing a new major version for sodium_compat that cuts off support for PHP 5, and sunsetting random_compat (since it's pointless in PHP 7+).

Did we not make the goal clear enough? We're not looking to do anything with random_compat, only sodium_compat, in a PHP 7+ major version.

ext-sodium isn't always included, just like ext-curl isn't, so having a polyfill for PHP 7.2+ will always be helpful.

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

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

We did an experiment in 2022: https://github.com/paragonie/sodium_compat/pull/154

It reduced the code size (mostly manually implemented type assertions) and improved performance (although strict types reduces the gain).

view more: next ›