eamann

It's to protect against the whims of a small set of people.

If one person holds the signing key to do something critical in your system, they're both a single point of failure and a huge security risk all in one. If you distribute that key to, say, 5 different people you've mitigated the single point of failure. But now you have 5 folks who can act potentially unilaterally.

Using a 3 of 5 TSS setup, you've still mitigated the single point of failure (any one or even two folks can go offline and you can still operate) while also protecting against unilateral action. It's a mathematically-enforced version of the "two-man rule." Similar to the way Cloudflare's Red October tool used to work by splitting things between parties: https://blog.cloudflare.com/red-october-cloudflares-open-sou...

Oblivious transfer - party A creates two random values (x_0 and x_1) and sends them _both_ to party B.

Party B picks one and uses that to compute future values that are sent back to party A _but without telling party A which of the two values they picked_.

In this example I'm hand-wavey because the production math is complicated and confusing - I took a vastly simplified approach that still works functionally for the demonstration without fully implementing the OT protocol.

what happens if an owner drops out or you want to introduce a new one? what happens if you want to change the quorum?

In either of those scenarios, assuming you still have quorum, you can regenerate keyshares for the new group for the same public key (and underlying yet unknown private key) by re-running the ceremony with the new participants. Production implementations of the protocol fully flesh this out.

traditional authentication ...

I wouldn't use TSS in that setup. Traditional auth + MFA is more than adequate. The better use case would be where you have a group that needs to demonstrate consensus (like governance for a programming language, multiple parties involved in signing an application release, or even an HOA that needs to vote on policies). In all of these, you'd take an M of N approach (rather than the simplified 2 of 2) for achieving quorum.

You're correct there that proper use means even the owner can't access it. But in a single key scenario they can still act unilaterally. The advantage of TSS is the removal of that level of unilateral action.

I like this take-home approach. Usually, I've been against that kind of outside work but in rare cases (i.e. leadership positions) have assigned take-home case study style presentation work to gauge communication skills. For engineers, though, I've taken a different approach.

If they've passed the basic screening with the TA folks and I've validated they didn't just regurgitate buzzwords to get in the door, I'll bring them in for an on-site (or do a virtual onsite). This consists of culture fit interviews with their direct team as well as with key stakeholders from elsewhere in the org. And a coding test. Directly with me.

But the coding test isn't LeetCode. It's an intentionally incomplete and ambiguous task related to the work they'll be doing in the job gauged less at evaluating their technical skills (though that is in fact a part) and more validating whether or not they ask questions and can engage with stakeholders.

For example - "Here's a dump of time-series data from one of our APIs. The key consumers of this data don't understand JSON feeds so they need you to build a visualization atop the data."

That's it. That's the task. Anyone who dives in and just starts hacking away is probably not a fit (they might be coachable ... but that's something we feel out through this and later followup conversations). Someone who stops and asks "ok, what does this data actually represent" or "who are the key consumers and what will they need to accomplish with this data" _before_ they dive into the code are the folks I want on the team.

In other words - am I looking at a great communicator with excellent collaboration skills, or is this someone who just wants to be told what to do and will take no ownership over the product direction? The most successful teams I've built bias heavily towards the former.

Sure, your experience sucked. But by all means let's continue to look down our noses at a programming language based on mistakes made 20 years ago.

It's a bit disappointing that a seemingly official project isn't using commit signing for verification and non-repudiation. It's open source, great! But it's also pretty massive (i.e. hard to review everything) and the chance of a bad actor sticking code in something so critical as tax filings.

Ever needed to run code you don't fully trust?

Then the installation instructions include piping a remote script directly to Bash ... Oh irony ...

That said, the concept itself is intriguing.

Whatever length of time they've used this process is as irrelevant as the questions themselves.

I'm just waiting for the official PHP Docker images to bump their updates ... which should be any time now.

Mastodon still has character limits for posts. There are ways to write longer messages but they require custom clients or integrations.

So threads like this are still among the easiest of ways to broadcast a larger thought into the fediverse.

A broad generalization about a large group of people at an events does not apply to a 1:1 interaction. Your statement is 100% right, but also does not contradict my own.

I've been getting a couple of these each day for the past few days. It's always a bit entertaining. Partly because my email address is my name (so I know it's not likely a typo when folks enter the email address). Partly because I leverage GPG from the Facebook side so the messages are encrypted.

Meaning, even if they somehow had access to my email (they don't - strong, unique password and separate MFA) they wouldn't be able to get the reset code as it's encrypted by a key stored in secure physical hardware.

Still, kudos to the hackers for trying. Getting these emails means _someone_ cares enough about my account to want access. Even if I rarely use it for anything other than checking in on distant relatives ...

Should be more clear this is a direct PDF download ...

Newly-updated PHP Cookbook with recipes through version 8.2 just released by O'Reilly Media.

Valid critique, though, and I do appreciate it :-)

Not sure how you're seeing that as the site is getting plenty of traffic ...

For anyone interested in how things work under the hood, I wrote a brief summary here: https://eric.mann.blog/end-to-end-encrypted-secret-sharing/

At the moment, secrets are automatically expired after 24 hours, but custom expiry is definitely something I want to support.

Internet Archive version: https://web.archive.org/web/20201228100715/https://merecivil...

Update - there was an intermittent error in the Linux client preventing Slack from reading or uploading PDFs. This has since been resolved.

That quote was not quite the positive way I wanted to start my week, but wow. Very accurate.

Also curious about your experience building/selling an ML product. Because that's the dream :-)

You weren't really paying attention if you failed to realize the author was a woman. Poor readership at best.

The lead organizer is a close friend of mine. My withdrawal from the event came after a long dialogue about exactly this. The circumstances around ZendCon and diversity are a longer, known issue within the PHP community.

Yes and no.

This is a PHP Fatal Error, which will cause execution to stop. But the compiler doesn't compile the entire file in the same way you'd see with other languages. Any code in a PHP file _before_ the type error will still execute just fine, but when the PHP engine hits the error it will fatal and throw a TypeError (along with a stack trace, depending on the verbosity of your configuration).

PHP isn't a compiled language. Exceptions are thrown when the code is loaded into the interpreter and said interpreter notices the error.

Apple has a bug bounty program where they'll legitimately pay you to report bugs directly to them. What's with everyone reporting them to Twitter instead and forgoing the extra cash?

Here's the full article about Vault, if you're curious: https://tozny.com/blog/crypto-tools-for-devops-hashicorp-vau...

you need it download configuration templates and fill them with secrets on the server that you want configured.

Ansible can also use configuration templates just fine. It can also support secrets management, depending on how you want to store the secrets. The first tool covered in the series itself was Credstash (https://tozny.com/blog/crypto-tools-for-devops-credstash/). Ansible supports retrieving secrets from Credstash natively, either for use in commands or when populating templates: http://docs.ansible.com/ansible/playbooks_lookups.html#the-c...

Git-crypt is but one solution for storing secrets _next to_ the code that uses them. Credstash is another for storing secrets in another, server-accessible location. Both can work with tools like Ansible (or Puppet or Chef or Salt).

From the tone of the above (and your other responses) you're not a heavy Ansible user. That's fine. Use the tool you're comfortable with. But don't try to turn people away from an equally useable alternative to something you _do_ use just because it's not your tool of choice.

S3's "encryption at rest" is transparent (see: http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-enc...). If someone (or some server) has access to the S3 bucket, they have access to all of the data. Control then is delegated to IAM roles and permissions, not to the crypto model.

As long as you authenticate your request and you have access permissions, there is no difference in the way you access encrypted or unencrypted objects.

The only advantage of S3 encryption is that if someone walks out of the data center with a disk, they can't read the data on it.

Note that this is part of a series ... Vault from Hashicorp is scheduled for next week ;-)