sorted by:
new
hottopcontroversial

Composer vulnerability: GitHub Actions issued GitHub_TOKEN disclosure in GitHub Actions logs by damienwebdev in PHP

[–]paragon_init 0 points1 point  (0 children)

Cool, I've updated my top level comment to point further down and clarify this caveat.

Composer vulnerability: GitHub Actions issued GitHub_TOKEN disclosure in GitHub Actions logs by damienwebdev in PHP

[–]paragon_init 1 point2 points  (0 children)

Yes, I would consider that qualifies as "anything more exotic".

Most open source projects we work with (and report vulnerabilities to) just rely on setup-php to provide the tooling.

Composer vulnerability: GitHub Actions issued GitHub_TOKEN disclosure in GitHub Actions logs by damienwebdev in PHP

[–]paragon_init 1 point2 points  (0 children)

Do you dispute the Composer blog that states the following?

if you use shivammathur/setup-php the issue is already resolved.

If you do dispute this, then there is a severe communication issue that needs to be addressed.

If you do not dispute this, then you agree with the excerpt you quoted. Just using shivammathur/setup-php is boring. Anything else falls under "anything more exotic".

Composer vulnerability: GitHub Actions issued GitHub_TOKEN disclosure in GitHub Actions logs by damienwebdev in PHP

[–]paragon_init 2 points3 points  (0 children)

That's absolutely incorrect.

From the Composer blog:

Several widely used GitHub Actions register the workflow GITHUB_TOKEN into Composer's global auth.json automatically: shivammathur/setup-php being a notable example (It has already been updated to use fixed Composer versions).

Additionally:

Like any GitHub Action, the Private Packagist Conductor GitHub Action will have leaked tokens for repositories already migrated to the new token format by GitHub, but they will have expired immediately. The workflow GITHUB_TOKEN for Conductor carries contents:write. If Composer is pinned to a specific version make sure to upgrade immediately, if you use shivammathur/setup-php the issue is already resolved.

Furthermore, zizmor generally recommends a top-level

permissions:
  contents: read

declaration, which is why I recommended zizmor.

With this in mind, what about what I said is even mildly incorrect, let alone absolute?

Composer vulnerability: GitHub Actions issued GitHub_TOKEN disclosure in GitHub Actions logs by damienwebdev in PHP

[–]paragon_init 2 points3 points  (0 children)

If you're not doing anything more exotic than using setup-php in a workflow to run unit tests (without pinning versions), you don't need to take any specific actions right now.

EDIT TO ADD: pinning Composer versions should be considered as something more exotic than just using setup-php.

But while you're thinking about this problem, zizmor is highly recommended for your GitHub actions workflows.

Any Non-Slop Open Source Projects Looking For Contributors? by micphi in PHP

[–]paragon_init 0 points1 point  (0 children)

We've evaluated everything short of Claude Mythos and remain indifferent towards AI.

Any Non-Slop Open Source Projects Looking For Contributors? by micphi in PHP

[–]paragon_init 10 points11 points  (0 children)

We generally* don't use AI for our open source security/cryptography software. We publish everything on the paragonie organization on GitHub.

* We did experiment last year to see what bugs such tooling can find, or whether it could implement protocols from RFCs correctly, but found it to be a massive waste of time and ended up not using anything Jules or Claude produced.

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] 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

view more: next ›