Turning down Upspin infrastructure

[Eric Grosse]

Upspin, like Unix and Plan 9, was intended to foster communities of
sharing, but has been less successful at that than we hoped. As a
consequence, with regret, we have decided to turn down the central
infrastructure such as the keyserver over the coming months

On March 4, we will turn off keyserver for a week. This warns even
people not following this list that something is happening. Then on
May 6, we will turn it off permanently. If this will cause more pain
than we're aware, please email gro...@gmail.com and let's discuss
options.

There is much about Upspin that still seems attractive compared to
alternatives. The combination of strong end-to-end encryption with the
convenience of upspinfs letting you run existing apps effortlessly has
been great. Bringing the idea of automatic nightly snapshots from Plan
9 to modern systems also feels great in use.

Contributors have proposed valuable improvements, and a backlog has
developed on reviewing and installing these, which is part of what
prompted this decision. Some examples are: switching from a central
keyserver to ssh-like authorized_keys files in clients and dirservers,
revised API for Block unpacking enabling parallel reads, a clearer
model for permissions on Access and Group files, and
post-quantum-cryptographic packing that can defend against future
rogue governments. The question is whether the size of the community
justifies the effort.

We thank all who tried out Upspin!

Andrew, Dave, Eric, and Rob

[Aram Hăvărneanu]

A vary sad day, but also another cautionary tale about the danger
posed by centralized infrastructure.

--
Aram Hăvărneanu

[Filip Filmar]

“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable” :)

On a more serious note, how impossible would be self-hosting a keyserver, say based on the public keyserver data available today?

I use upspin as it can use Google Drive as a backend, and is fast enough at doing so. But I have no friends, so I have no use for others' key data. :)  Ideally I'd "just" take the public key server data, self-host and be done with it.

Thank you all for your service so far!

F

--
You received this message because you are subscribed to the Google Groups "Upspin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to upspin+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/upspin/CAEAzY38a6KY5vt1XLzmr7BvGxAyzXW4qZgN3JahD9PQ7XQKMPg%40mail.gmail.com.

[Eric Grosse]

With regard to alternatives to a centralized keyserver, there was a
relevant discussion at https://github.com/upspin/upspin/issues/614 a
year ago. In short, the proposal is to keep sets of known_keys at each
client and also sets of known_keys at dirservers, with some automation
to warn users of changes and maintain consistency. This would require
more manual work by users than the central keyserver, and in
particular adds some friction for new users. But in hindsight it might
have been a better way to go. I remain open to modest-sized pull
requests that fix bugs in the Upspin repository. The known_keys
proposal is probably at the upper size limit of what would be
considered, and would have to be completed before any others make
sense. If such a change is making good progress, I'd of course be
willing to keep keyserver running in the meantime to support a
transition.

Leaving aside keyserver, there continues to be uncertainty about how
far away a cryptographically-relevant quantum computer might be, but
I've heard from a credible source that it is now likely less than ten
years off. Maybe not, but I'm uncomfortable leaving Upspin users at
risk with the status quo; this is a more difficult risk assessment
than we can responsibly be imposing on ordinary users. So the other
critical Upspin proposal is to switch from the existing elliptic-curve
packings to ML-KEM in some form. This would require help from people
with the right PQC expertise, at minimum to review my changes if I'm
the one doing the design and implementation. It was nice when our team
was at Google and had such expert reviewers available.

For sharing files among very small groups there are simpler solutions
available, admittedly with less convenience. Given the effort needed
to implement the two critical steps above compared to the size of the
community, it seemed time for Upspin to join its Authors in
retirement.

[Özgür Kesim]

Hi Eric, Andrew, Dave and Rob,

thank you for upspin. This news is sad, but expected, I guess.
I agree with both of your observations that a) upspin has still
something valuable to offer and b) that it needs refurbishing
with substantial effort.

On the upside: the code is available to us and some of the
ideas for improvements do precisely include decentralization,
such that this news might just be the right push to turn it
into an oppurtunity. (Last sentence in the uplifting voice of
self-motiviation)

Thanks again!

Cheers,
Özgür


Thus spake Eric Grosse (gro...@gmail.com):

> --
> You received this message because you are subscribed to the Google Groups "Upspin" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to upspin+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/upspin/CAHfGVNdPnbuFDb74ZvkvcSk8%2BZvwcDQm5xGcp9OouGcLV_ceNg%40mail.gmail.com.

[Albert-Jan de Vries]

Hi Eric, Andrew, Dave and Rob,

I'm using upspin for a private application for 8 years now, and I'm very happy with it. Because the key server is a single point of failure for my application, I'm running a readonly key server (cache). We had some previous issues with downtime of the upspin key server. For me it is possible to run a full fledged key server, that is public available and maintained by me. I probably need to fork the repository, or introduce a standalone key server implementation in another (public) git repo. Also the URL will change (of course).

In the upcoming weeks I'll try to work on this and see if I can change the readonly server to a read and write server with the same requirements as the current key server.

It is sad to see that the project isn't getting more traction. I'll hope that the current owners can still merge some of the open and upcoming merge requests.

Regards,

-- AJ

Op woensdag 12 februari 2025 om 11:14:14 UTC+1 schreef Özgür Kesim:

[Gurjant Kalsi]

Hey Upspin friends,

I'll be the first to admit that I only found out about the keyserver turndown after my instance stopped working yesterday and I came here to see if it was a known issue. As someone who's been using Upspin every day since the initial launch I'm also bummed to see it being retired; although I understand the decision.

I was speaking with Filip yesterday and my situation is similar to his: over the years I've been using Upspin less and less for sharing and increasingly as a place to stash files for myself and some of my applications via a FUSE mount. Even though this is just a figment of what Upspin was intended to do, I haven't found another solution that does what I need quite well as Upspin does.

In the meantime I've hacked together a keyserver that only supports lookup for keys that I control and I've pointed my upspin instances at that. That's been enough to get me going again while the global keyserver instance is turned down. Admittedly, it precludes any sort of trivial sharing and it certainly doesn't address Eric's concerns about privacy in a post-quantum world; those are both questions that I hope to ponder in the near future.

Once again, thanks to all the authors and contributors for your work, it's been a fun ride and I'm hoping I can ride some version of it for at least a little bit longer.

--Kalsi

[David Presotto]

I'm turning down my gcs instance. It had stopped running last month
and I hadn't even noticed. I only used it to debug upspinfs.

> To view this discussion visit https://groups.google.com/d/msgid/upspin/6a9581a5-48a4-4c1a-be3e-350076f1d2fbn%40googlegroups.com.