CiPHPerCoder

It's both.

The strpos() check is what you're describing, but openssl_random_pseudo_bytes() accepts an optional second by-reference argument and sets it to true or false depending on the behavior of RAND_pseudo_bytes().

https://www.php.net/openssl_random_pseudo_bytes

This function also isn't fork-safe in PHP, and has caused RNG collisions before: https://github.com/ramsey/uuid/issues/80

Consequently, I advise against using this function entirely. random_bytes() is better in every way.

I agree. This was just a write-up I promised the Twitter thread.

https://twitter.com/CiPHPerCoder/status/1538574970011500546

> We need to stop saying don’t roll your own and start teaching it with good examples and good explanations.

I 100% agree with this statement, in isolation.

But in context, I have to wonder if something in the post sounded like I was telling people not to roll their own? Because that wasn't the take-away.

Either way, https://gotchas.salusa.dev/GettingStarted.html

> So the way you get to become someone who gives this sage advice is by disobeying it.

Lawyers have a similar thing, from what I've been told.

"Don't go to law school", "Don't become a lawyer", etc. are what many lawyer parents have told their children (some of whom went on to become lawyers themselves).

The main value-add is to replace passwords entirely.

What about it is sexualized to you, exactly?

I'm not saying your POV is wrong. I'm asking you to explain it.

EDIT: Since you edited your comment, I'll edit mine.

> I wouldn't open this blog at work. I certainly wouldn't buy a children's book with this type of art in it.

Why not? I don't see anything wrong with this blog post. I'd happily share it with colleagues and coworkers alike because it's useful information.

The only crowd that might take offense to the content here are cryptocurrency enthusiasts, because of the shade thrown at secp256k1. But, personally speaking, I'm okay with them being upset with me for sharing a link to such a thing.

> You must have to admit that little red riding hood is usually depicted a lot more modestly.

I'm not sure the same rules of clothing apply to cartoon animal characters as to real-life humans.

I certainly don't shriek if a coworker posts a picture of their pet cat at work without the critter being fully clothed.

What are the standards you're applying to this situation?

Also, the image you linked isn't included in the blog post about elliptic curves, so it's a bit weird to cling to it in defense of your initial reaction.

I don't see anything sexualized here.

This appears to be a depiction of Red Riding Hood, a fairy tale character that's very frequently introduced to young children in America.

> This isn't, like, per se a vulnerability; they're not saying it is.

"Defeating" is a really poor choice of verb in the title for a post that isn't claiming a vulnerability.

BIKE also stands for Bit-flipping Key Encapsulation

https://bikesuite.org

That was fixed already.

https://wiki.php.net/rfc/named_params

I will always say VR, I will never say "metaverse".

Their branding move was bold, yet unconvincing.

I define it as religion for nerds who think they're too smart/clever for religion.

To expand on that, see other critical comments e.g. https://news.ycombinator.com/item?id=30830690

Enter the prisoner's dilemma

Yes, it's a firehose. I'm sure you can find a security vendor willing to offer a curated list somewhere.

https://gossamer.tools :)

I took things a different direction:

https://paragonie.com/blog/2017/07/chronicle-will-make-you-q...

I wish Spotify would let us hide his podcast from the front page of their app, at least. I have no interest in his podcast. Let me remove it.

Academic conferences are usually "comfortable" environments with plenty of air conditioning. It might undermine the prestige a bit if we did that.

Or maybe it'd have a different charm than the norm.

It's not about "valid" or "no more valid". It's about context.

If you want to distrust a security vendor for greenlighting something that was found to be vulnerable the following week, you'd probably be in the clear.

If it was 6 years ago? Maybe don't count that against them; especially if it's a novel vulnerability that was discovered.

But also, if you're running 6 year old software, maybe update to a newer version of it.

I like your style. We should start StateFairCon someday

It's like ransomware for research

Whenever I speak at a tech event, my attendance cost is free. (I'm still on the hook for flight and hotel, usually.)

Incidentally, https://sso.tax

> So you're imagining that a bunch of people trying to break into security work will do work for free in hopes of gaining potential employers'/clients' trust?

We're talking about open source software. People are already doing this sort of free work. You run into them when you start a bug bounty program, or once you've created at least one open source package with a nontrivial userbase.

The way you're wording this sounds precariously like I'm creating some barrier to entry to extract free labor out of people. Quite the opposite: I'm suggesting a mechanism for taking the free work people are already doing in the open source security space, and using it to build rapport with the market a security researcher is trying to break into.

If you're wondering how I would know about the motivations about someone trying to build a customer base out of free labor performed for open source software, take a look at... virtually everything publicly shared on paragonie.com. I'm speaking from experience. ;)

> And you're imagining that this ecosystem of attestations will be seeded by a bunch of people looking to gain the community's trust?

Not just people. Companies too! (I think most of us view them as separate things still?)

> So who audits the auditors?

The same people who make these kinds of decisions today, albeit far less formally than what I'm envisioning.

For the PHP ecosystem, you have the big players (WordPress, Drupal, Joomla, Magento) and frameworks (CodeIgniter, Symfony, Laravel, etc.) with dedicated security teams that field vulnerability reports from the larger community.

Beyond them, you have this large, distributed, ad hoc emergent network of security experts that have a loose consensus on whether or not a self-proclaimed security expert is credible. It's messy and uncoordinated and decentralized, and very imperfect.

> And how long do you expect it to take to get a critical mass of people reviewing code who have gained the community's trust to be reviewing enough packages to solve open source supply chain security?

I don't have a time estimate on hand, due to how this will need to unfold. I don't expect to have "[solved] open source supply chain security" in any immediate sense. Going from "improved state of affairs" to "solved problem" is a long tail.

Marginally, improving the security of the open source supply chain is trivial: Any effort expended is more than is currently being done today. That's the dx part of the equation.

What I predict is as follows:

1. Highly impactful codebases (i.e. a dependency of lots of projects), which are in the hot path for many dependency graphs, will end up being covered by third-party reviewers.

2. A lot of niche codebases will be covered because of community interest or due to extant social relationships.

3. A large swath of what remains will remain uncovered by third-party review despite being open source.

Today, the software in category 3 is an unknown unknown. With Gossamer, it will become a known unknown. This is a meaningful step towards "solved problem", even if it doesn't prima facie solve it immediately.

Yes, it's called a timestamp.

Revocation of trust here isn't automated. "I just greenlit ransomware" is a very different category than "Attacks got better, as they do".

I think I understand why it makes you uncomfortable.

I do think they're two separate problems, and must be solved independently. Left unsolved, what you're experiencing is mostly bad optics rather than a dependent nastiness. It's a bad look, and it leaves a bad taste in one's mouth.

That being said, we both agree it's worth solving. However, I'm not an economist, by any measure, so I don't have any insight into what a solution looks like.

This is about PHP code (i.e. written in the scripting language, PHP), not the PHP interpreter.

Since it's a scripting language, your build artifacts will be one of:

- .diff / .patch

- .zip / .tar / .tar.gz

- .phar (rarely)

Of these, only the last (PHP Archives) is mildly persnickety for build reproducibility. But it's easily fixed: https://github.com/paragonie/sodium_compat/blob/08ab867bbb6a...

https://defuse.ca/triangle-of-secure-code-delivery.htm was published in July 2014, which included Userbase Consistency Verification as a requirement... so I think that's when the use of transparency logs in solving this problem was earliest recorded.

But I'm no internet historian, so I may have missed something.

Rust is delightfully forward-thinking. Thanks for sharing.

These are two separate things, and it's perilous to conflate them.

The OSS developer is providing software that anyone can use under whatever license terms for free. How they monetize this is entirely their responsibility. Choosing a permissive license makes them generally indistinguishable from the developers who don't want to monetize their work at all. Solving the "how do we ensure they get paid?" problem is nontrivial, but certainly out of scope for this discussion.

The verification service is provided by a company to protect their customers from malicious changes to said OSS software. (Yes, even if they were deliberate changes by the original developer!)

In some sense, you could try to frame the verification services as somehow predatory, but that's like saying that safety inspectors are predatory to independent carpenters.

(I'm not happy with that last analogy, but it's the best I could come up with on the spot. Real-world analogies to software problems are always messy, so feel free to suggest a better one if you think of any.)

>I also think the true meaning of attestations is a bit murky. The `spot-check` and `code-review` attestations are about source code, `reproduced` is about the build artifact, and `sec-audit` is somewhere in the middle (ideally both). But it seems like these attestations are always attached to artifacts, not source code? So spot-check and code-review are really only relevant if the build is reproducible (and has been attested as such), right? Since that's rarely-if-ever going to be the case in the real world, it seems like another reason the attestation system will likely be misused in practice.

This probably should be made clearer, but: Reproducible builds are necessary for the security of any such system. It's outlined in earlier blog posts.

Consequently, the inclusion of reproducible build verification is taken as a premise.

> The authors seem to envision a world where there is an ecosystem of independent security vendors out there doing reviews and publishing attestations, but don't really provide any compelling reason why that world will spring into existence.

That's true, and should probably be tackled in a future blog post.