FiloSottile

> "huh, maybe it's not great my executables are writeable by my account without requiring authorization first"

I'm very confused as to what threat model leads to this concern on an unsandboxed (predominantly) single-user desktop OS such as macOS.

"Innocent until proven guilty beyond reasonable doubt" is the gate for government violence, but as a society we operate on a very different standard, for very good reasons.

Multiple credible accusations, corroborated by contemporaneous accounts, collated by a reputable journalist is definitely enough to call the accusations founded.

Not enough to send people with guns to take away his freedom, maybe, but enough to form an opinion. Otherwise, are we supposed to involve the legal system in every assessment we make of anyone?

The original link presented a detailed argument for what is Google specific about this, namely that it was enabled by the two tier workforce system.

https://twitter.com/alphabetworkers/status/15373969466917724...

A piece of news about Fast is listed twice, once under Fast and once under Fastly. I’m not aware of any Fastly layoffs.

> In the meantime, if you would prefer, we can turn off all refresh traffic for your domain while we continue to improve this on our end. That would mean that the only traffic you would receive from us would be the result of a request directly from a user. This may impact the freshness of your domain's data which users receive from our servers, since we need to have some caching on our end to prevent too frequent fetches.

https://github.com/golang/go/issues/44577#issuecomment-85692...

> "EFAIL" is an alarmist puff piece written by morons to slander PGP and inflate their egos. [...]

https://github.com/golang/go/issues/30141#issuecomment-46427...

Disclosure: I was on the Go team at Google until earlier this month. Dealing with DeVault's bad faith arguments is one of the few things I won't miss of that job.

https://github.com/FiloSottile/passage :)

That's exactly the use case I set out to replace for myself. I'll put together a guide at some point. The part I don't use and so can't really own is the mobile app, I would love a community solution there.

I am also planning to integrate https://github.com/FiloSottile/yubikey-agent which makes the SSH authentication part very easy, so that you only type your PIN once and it stays cached.

Yes! That’s what the plugin system is designed for. https://github.com/str4d/age-plugin-yubikey is fairly mature and I use it every day.

Currently it's only compatible with https://github.com/str4d/rage, because age only supports plugins in a branch, but I'm hoping to land support this week!

https://github.com/str4d/age-plugin-yubikey is very much trying to beat GnuPG for ease of use and performance in that setup :)

Currently it's only compatible with https://github.com/str4d/rage, because age only supports plugins in a branch, but I'm hoping to land support this week!

Heh, a problem we honestly have with age is that the whole article (including SSH key support!) would be a one-liner with age, so it just doesn't get written and it doesn't get SEO :)

It's a good problem to have, but I find it funny.

Hello! age (https://age-encryption.org) author here. Different tools can definitely be better for different use cases (for example I am a fan of restic [0] for backups, although age is designed to compose well with tar, if that's your thing), but do you mind me asking what made that tool feel more well defined than age?

age has a stable spec [1] and an alternative implementation in Rust [2] based on the spec with extensive interop tests.

If that’s just not visible, I’d be interested in how to fix that appearance, too!

[0]: https://words.filippo.io/restic-cryptography/

[1]: https://age-encryption.org/v1

[2]: https://github.com/str4d/rage

They seem to report results from human subjects as well.

> Human brain tissue from 9 individuals with COVID-19 or SARS-CoV-2 infection exhibits the same pattern of prominent white matter-selective microglial reactivity. [...] Humans experiencing long-COVID with cognitive symptoms (48 subjects) similarly demonstrate elevated CCL11 levels compared to those with long-COVID who lack cognitive symptoms (15 subjects).

This is very much what age is designed for.

The Go implementation supports every OS. The Rust implementation (rage) also does, and can be called from C, JavaScript, Python, and anything else with a C FFI. Also, age can be implemented entirely on top of libsodium, so anything with libsodium bindings can easily get an age implementation. I’m working to a TypeScript implementation to demonstrate it.

I’d be interested to hear what language support is missing, to know where to invest in the future.

I love this, it's essentially a case study for the companion article addressing maintainers instead of companies: https://words.filippo.io/professional-maintainers/

We need both sides to shift for this kind of transactions to become commonplace.

There was a pretty good discussion yesterday on this in the comments of a related article. I'll repost below my comment which summarizes the two articles I wrote, but I recommend checking out that thread, as it covers a lot of supporting and dissenting directions.

→ https://news.ycombinator.com/item?id=30741702

Open Source volunteerism is the result of the early hacking culture and of what makes the Internet special: people choose to experiment and share their work, and their work can reach every corner of the world. It has no significant parallel in other industries, it's beautiful, and I owe it my career.

However, it's not a sustainable, fair, or effective foundation for an industry with the responsibility to power modern society. We need the critical role of Open Source maintainer to professionalize. This is most likely to happen through capture by large intermediaries, but I wish to see it happen through the formation of a serious professional role, organized independently or in small firms, like lawyers.

This will require changes both from the maintainers [1] (become legible, get a LLC, send real invoices, offer guarantees) and from companies [2] (pay the maintainers, pay them real money, pay for maintenance, and keep paying them).

[1] https://words.filippo.io/professional-maintainers/

[2] https://words.filippo.io/pay-maintainers/

Honestly, I can't give you an actionable plan at the moment. We are simply not there yet.

Eventually I hope there will be social norms (like how you advertise the option), tools (like payment rails and platforms, hopefully not like Patreon, but more like those lawyers use to invoice clients), resources, and even training. I hope it will become a standard transaction, that companies have processes for approving with no ad-hoc work.

But for now, whoever wants to try this is in uncharted territory, will have to discover what works by trial and error, will have to teach companies how to think about them, and will need some significant leverage to spend (such as personal networks, visible projects, and savings).

I agree! I think Open Source volunteerism is the result of that culture, not its embodiment.

No other industry had a large portion of its R&D done by people scratching their own itch and sharing the results freely. That led to relying on that freely available work, which led to volunteerism.

The alternative is not the status quo. Look at all the talk of supply chain security from the big players. The alternative is that all power and profit is just moved to large institutional middlemen or directly to a few big companies who can afford such a program.

If you don't care about control over the downstream of your project, or funding, no one is forcing you to professionalize! I just want that to be available as an option to those who do.

Academic publishing is a very interesting parallel to think about, indeed!

In particular the fact that often when a publication turns out to have industry value, a company is formed around it to commercialize it: both to extract profit from it, and to make it accessible and legible by companies. Companies by and large don't take academic papers off arXiv and implement them.

The rest are funded through grants, which have the side effect of directing a sizeable chunk of the academics time to writing grant applications rather than science. I think that would be a regrettable outcome for Open Source.

I'm arguing against middleman businesses, not for.

I don't see the non-profit model scaling to the whole industry, and the examples we have today of non-profit foundations mostly don't pay maintainers. For example, Log4j is under the Apache Foundation but none of the developers on its committee were being paid.

Is that really the outcome we want? That large companies fork all the OSS they need and take control away from the maintainers? Because it's what is going to happen if we don't build an alternative where maintainers have a proper career path.

No, it can't. More contributions require more maintainer effort, not less, if you want the project to follow a design and pursue a goal, rather than be a kitchen sink.

Open Source volunteerism is the result of the early hacking culture and of what makes the Internet special: people choose to experiment and share their work, and their work can reach every corner of the world. It has no significant parallel in other industries, it's beautiful, and I owe it my career.

However, it's not a sustainable, fair, or effective foundation for an industry with the responsibility to power modern society. We need the critical role of Open Source maintainer to professionalize. This is most likely to happen through capture by large intermediaries, but I wish to see it happen through the formation of a serious professional role, organized independently or in small firms, like lawyers.

This will require changes both from the maintainers [1] (become legible, get a LLC, send real invoices, offer guarantees) and from companies [2] (pay the maintainers, pay them real money, pay for maintenance, and keep paying them).

[1] https://words.filippo.io/professional-maintainers/

[2] https://words.filippo.io/pay-maintainers/

For anyone curious about SSH implementation internals or cryptographic protocols, every CL in that chain (listed on the right hand side in Gerrit) has a detailed commit message, especially https://go.dev/cl/392015 which fixes a vulnerability near-miss.

Can you keep elaborating about the abuses that WhatsApp has been caught red handed with?

You mentioned only unencrypted OS backups (which were a major issue, but also industry standard, affecting everything but Signal which takes a severe usability hit over it, and apparently fixed https://faq.whatsapp.com/general/chats/about-end-to-end-encr...). "Filtering content on the edges" is a whole debate but not something that ever materialized.

It sounds there's a list, what are the others?

Previously: https://news.ycombinator.com/item?id=25726068 (2021)

I am moving my newsletter archives to my blog, and the issues must have hit the RSS feed, even if the pages are not well annotated yet.

As part of this effort, Mozilla requires disclosure of all intermediate CA certificates in the WebPKI. They bundle that list in Firefox, so that even if a server is misconfigured and sends the wrong certificate chain (but a valid leaf certificate), they can successfully establish a TLS connection. It's pretty cool, and less confusing than the caching approach of other browsers, which leads to non-deterministic behavior.

Using the list they publish [1] I built a Go package that provides the same feature, as both a x509.CertPool or a tls.VerifyConnection callback, to allow clients to connect to misconfigured servers: https://pkg.go.dev/filippo.io/intermediates

The pool is regenerated [2] by a GitHub Action [3] every night, and embedded into the package so it requires no network connection. If tests fail on the new pool, it doesn't get committed. It's actually kinda interesting watching the intermediates come and go [4], and it's very satisfying to have a self-maintaining package.

[1] https://ccadb-public.secure.force.com/mozilla/MozillaInterme...

[2] https://github.com/FiloSottile/intermediates/blob/7dfa9179/g...

[3] https://github.com/FiloSottile/intermediates/blob/7dfa91796/...

[4] https://github.com/FiloSottile/intermediates/commits/main

How is an encryption backend supposed to fix this?

It’s not really clear to me how it could be even expected to do so, or what gives the impression that the goal of a 650-lines bash script would be to scale “from 1 to enterprise”.

Still, asserting that only your problems are real world problems and worth solving is pretty reductive.

There is an example in the README for how to use age-plugin-yubikey :)

age-plugin-yubikey supports all PIV tokens. There are other 3rd party plugins in development for other hardware tokens. The v1.1.0 Go API will be able to drive arbitrary plugins, so you should be able to integrate with all of them!

The difference with hardware keys is that the primary key can’t be exfiltrated, and only one secret can be decrypted per physical touch, so rotation and recovery are possible without invalidating all secrets.