Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A faster heart for F-Droid

f-droid.org

Post reply on HN
Print view View original

221–230 of 231 posts

Re: A faster heart for F-Droid

#221

Post by arcfour »

xorcist wrote: post #187
Aurornis wrote: post #35

> this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argu…

> one person had the physical server in their basement Unless you have even the faintest idea about how F-Droid does it, please stop spreading FUD. All the article says is that it is not a normal contract but a special arrangement where one or a select few have physical access. It could be in a locked basement, it could be in a sealed off cage in a data center, it could be a private research area at a university. We…

> A special arrangement with an academic institution providing data center services

They would have said this if it were the case. Why would they make it sound so sketchy if it wasn't otherwise? There is no "FUD", you don't know better than anyone else would either, so you don't get to make that argument and then speculate yourself.

Re: A faster heart for F-Droid

#222

Post by crote »

xorcist wrote: post #187
Aurornis wrote: post #35

> this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argu…

> one person had the physical server in their basement Unless you have even the faintest idea about how F-Droid does it, please stop spreading FUD. All the article says is that it is not a normal contract but a special arrangement where one or a select few have physical access. It could be in a locked basement, it could be in a sealed off cage in a data center, it could be a private research area at a university. We…

> It could be in a locked basement, it could be in a sealed off cage in a data center, it could be a private research area at a university. We don't know.

Yes, and that is exactly the problem. They didn't write "a large university/company/government institute which wishes to remains anonymous has graciously donated space in their ISOwhatever certified in-house hosting facility", they wrote "physically held by a long time contributor".

It is written as if it is just Some Guy's Mom's Basement, with a guarantee of Trust Me Bro. If it is indeed hosted in a professional environment, why don't they say so?

People are assuming the worst because it isn't their first rodeo, and they've seen it go wrong time and time again. If F-Droid wants to be taken seriously Just Trust Us isn't good enough - especially with their main selling point being "you can't trust Google"!

Re: A faster heart for F-Droid

#223

Post by lrvick »

kube-system wrote: post #97
lrvick wrote: post #44

Earlier quoted context omitted.

> It makes it sound like a very amateurish operation. Wait until you find out how every major Linux distributions and software that powers the internet is maintained. It is all a wildly under-funded shit show, and yet we do it anyway because letting the corpos run it all is even worse.

What do you mean by "major distribution"? e.g. AS41231 has upstreams with Cogent, HE, Lumen, etc... they're definitely not running a shoestring operation in a basement. https://bgp.tools/as/41231

Yet most distros have maintainers build and sign their own package recipes and/or artifacts on their own random home workstations infected with who knows what so the trust is distributed (but not decentralized) which is the worst of all worlds. And that is for the ones that bother with maintainer signing at all, as distros like nix and alpine fully skip caring about bare minimum supply chain security.

Some distros do build on a centralized machine, but almost always one many maintainers have access to from their workstations, so once again any single compromised home computer backdoors everything.

The trust model of the linux distros that power most servers on the internet is totally yolo, without the funding to even approach doing build and release right, let alone code review. One compromised maintainer workstation burns it all to the ground.

Sorry if this ruins anyones rosy worldview. The internet is fragile as hell, and one bored teen away from another slammer-worm style meltdown.

Relevant context: I founded stagex exactly because no previous Linux distribution has a decentralized trust story appropriate for production use hosting public internet services.

Once you decentralize supply chain trust then the question of "which place and people people do we trust for the one holy server" totally goes away.

Re: A faster heart for F-Droid

#224

Post by lrvick »

goodpoint wrote: post #196
lrvick wrote: post #44

Earlier quoted context omitted.

> It makes it sound like a very amateurish operation. Wait until you find out how every major Linux distributions and software that powers the internet is maintained. It is all a wildly under-funded shit show, and yet we do it anyway because letting the corpos run it all is even worse.

This is 100% false.

Once supply chain attacks enter your threat model, you suddenly realize that the entire internet breaks if any one of a few hundred volunteer owned home computers are compromised.

Fixing this requires universal reproducible builds redundantly built and signed by independently controlled hardware. Once you have that then you no longer have single points of failure so centralized high security colo cost becomes a moot issue.

Re: A faster heart for F-Droid

#225

Post by lrvick »

quantummagic wrote: post #107
pydry wrote: post #70

Earlier quoted context omitted.

It's a shame mozilla wont step up to fund it. They've spunked way more money on way dumber things.

Imagine the good they could do if they didn't pay their CEO 6 million a year.

I suddenly no longer feel bad about my 6 figure salary working full time in FOSS.

Re: A faster heart for F-Droid

#226

Post by speed_spread »

immibis wrote: post #193
0x1ch wrote: post #95

Earlier quoted context omitted.

Every colo I've visited has a system for allowing physical access for our equipment, generally during specific operating hours with secure access card.

While this is true, you stated a tautology: of course every colo you visited allows visiting.

They could have visited in an official function such as inspector while customers didn't have direct physical access to the facility.

Re: A faster heart for F-Droid

#227

Post by eighthave »

Aurornis wrote: post #35

> this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argu…

There are two key concepts at play here: "least authority" and "infrastructure as code". The buildserver host is sensitive security-wise, but easy to set up an instance. We have multiple instances running, and spin up new ones from time to time. For production infrastructure, there should only be enough people with access to it as are needed to maintain it. No more. If a sysadmin goes rogue, we can always just spin up a new instance elsewhere with a new maintainer.

Re: A faster heart for F-Droid

#228

Post by eighthave »

silisili wrote: post #38
Aurornis wrote: post #35

> this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argu…

Yup. But the same can happen in shared hosting/colo/aws just as easily if only one person controls the keys to the kingdom. I know of at least a handful of open source projects that had to essentially start over because the leader went AWOL or a big fight happened. That said, I still think that hosting a server in a member's house is a terrible decision for a project.

Lots of projects with good security track records host key servers in a "member's house". That said, the F-Droid buildserver is not hosted in anyone's house.

Re: A faster heart for F-Droid

#229

Post by j45 »

Aurornis wrote: post #35

> this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argu…

Physically held is _very_ different than only one person having access. It doesn't seem to imply it's hosted in a basement at all.

There is zero reason that server in the basement can't be a mirrored node to one or more vps'.

To extend your point, it's probably far better to have something cloud agnostic so it can flip between horribly compromised or attacked hosts.

Basement servers on Fibre, with a bit of knowledge and power backup can be just as reliable as most for one simple and over looked reason, they're reasonably obscure and don't fall under the attention large hosts receive. They absolutely have other issues to get rid of, which can be.

Self-hosting isn't about a "point of pride". Time reveals the value of self-sufficiency, not in every case to the absolute, but being able to.

Self-hosting at home is often similar skills to hosting a server in a datacenter, whether it's your own hardware co-located, rented server, or a managed server.

Post reply on HN