Replying to
@flowcontrol@phpc.social @sebastian@phpc.social @edorian@phpc.social @Synchro@phpc.social Is this the so-called web of trust?
Remote
Tim Düsterhus
@timwolla@phpc.social
mastodon 4.7.3125 Followers
69 Following
17 Posts
Joined November 04, 2022
GitHub:
Replying to
@nyamsprod@phpc.social @derickr@phpc.social For PHP 8.7, the focus will likely be on adding Instant and Clock.
API design wise I would probably follow the Pareto principle for Duration and keep it lean, with userland helpers adding convenience functionality around the native class as a strong foundation:
API design for PHP’s stdlib is much more expensive than for userland and the costs of getting it wrong are even larger.
The only thing I would add would be ->divideInto(), because that's complicated to get right.
Replying to
@heiglandreas@phpc.social @kleisli@mastodon.social @naderman@phpc.social @OndrejMirtes@phpc.social @markusstaab@phpc.social @toflar@phpc.social
Long-lived secrets are a liability.
In particular both a PGP signature created with a key stored your CI/CD runner and a PGP signature created with a key on your local machine that was hit by the latest hijacked npm / Composer / Cargo / … package is strictly worse than a SLSA build provenance attestation stored in a transparency log.
Replying to
@asgrim@phpc.social I'm particularly annoyed by that for PIE extensions, because the compatibility guarantees for the internal API are explicitly much looser there.
Now my CI looks like this:
if dpkg --compare-versions "${{ steps.determine-php-version.outputs.version }}" lt 8.6; then
pie install --ansi -v some/package
fi
☹️
Replying to
@phpcs@phpc.social @heiglandreas@phpc.social @kleisli@mastodon.social @naderman@phpc.social @OndrejMirtes@phpc.social @markusstaab@phpc.social @toflar@phpc.social
It is possible to update the expiry of a PGP key without changing its ID. Users would need to fetch the key with the updated expiry, but could continue verifying against their trusted fingerprint.
see: https://mhdez.com/notes/renewing-an-expired-gpg-key/
Replying to
@linc@phpc.social I'd argue it should be Jul 27 - Aug 1, just dropping the the redundant (because identical) year information, but otherwise keeping the ISO-8601 order.
Because otherwise 27 Jul - 1 Aug very much looks like 27 Jul - 1 Sep when glancing at it.
Replying to
@nyamsprod@phpc.social This gave me the idea to check if array destructuring works with ArrayAccess. It does. This would allow to support both the destructuring and the “named properties”-based access in an equally convenient way (i.e. without ->asTuple()).
This might be an option for the native Duration class in 8.7 then 🤔
Replying to
@asgrim@phpc.social After Microsoft acquired GitHub the introduction of new features (that you are very likely relying on) greatly accelerated; GitHub’s feature set was pretty much stagnant before that.
As an example, GitHub Actions was only introduced after the acquisition and certainly contributed to some of the growing pains, since easily accessible CI puts a lot more stress on the API and git delivery.
Correlation is not causation.
Replying to
@heiglandreas@phpc.social @kleisli@mastodon.social @naderman@phpc.social @OndrejMirtes@phpc.social @markusstaab@phpc.social @toflar@phpc.social @phpcs@phpc.social
Doing a key rotation for a security release would be a perfect opportunity for an attacker to sneak in a new signing key, since folks are likely to be less diligent when their security scanners are breathing down their neck:
They would need to decide between fixing the security issue and properly verifying that the key rotation is legit.
Replying to
@heiglandreas@phpc.social @kleisli@mastodon.social @naderman@phpc.social @OndrejMirtes@phpc.social @markusstaab@phpc.social @toflar@phpc.social
And not to throw shade on them, since they already do SLSA attestations (https://github.com/PHPCSStandards/PHP_CodeSniffer/attestations) but I quite enjoyed that @phpcs@phpc.social apparently rotated their PGP key for their 4.0.2 security release: https://github.com/PHPCSStandards/PHP_CodeSniffer/releases/tag/4.0.2
The GPG signature for the PHAR files has been rotated. The new fingerprint is: 5CB4F778BF9BC4FB67AE511D96E91A992CF22FF4.
Replying to
@nyamsprod@phpc.social Okay, the Overflow remark was ambiguous, I suppose:
- Negative inputs are a programmer error (thus ValueError) - for now at least.
- Out-of-range nanoseconds is also a programmer error.
The TimeException only applies to overflow of the entire range (i.e. an overflow in seconds).
I also suggest to test with fromHours(PHP_INT_MAX). This will likely throw a TypeError internally, because of the int->double overflow. This should also be TimeException.
Replying to
@nyamsprod@phpc.social is_int() is probably fine.
The exception types are not quite correct, still: $seconds >= self::MAX_SECONDS must be a TimeException (overflow). $seconds < 0 must be a ValueError (programmer error). The handling for $nanoseconds is correct.
The error message for !is_int() should be consistent with $seconds >= self::MAX_SECONDS, because !is_int() effectively means that $seconds >= self::MAX_SECONDS.