~sircmpwn/sr.ht-discuss

9 6

builds.sr.ht availability

Details
Message ID
<CALUA0CEB7C2.2YE4IAP7185GC@debian>
DKIM signature
pass
Download raw message
Hi,

In the last month I've been experiencing increasing outages/queueing
on builds.sr.ht.  I understand that their is already a shortage of
resources, however I would like to know if there is any other problem
other than physical resource (which we'll need to add more eventually
as people are joining) and if such software-related problem is solvable.
In addition, I suppose in rush hours (I don't even know if there's such
a thing of builds.sr.ht) need there be some special handling?

Therefore, in the upcoming month report, I'd love to see the analytics
on builds.sr.ht usage and some profiling, as well as some advice to
make space for one another until it's more financially possible
to upgrade the infrastructures.

Cheers,
Nguyễn Gia Phong
Details
Message ID
<CALUAW5FYP4F.36LHNZ4ACUB72@taiga>
In-Reply-To
<CALUA0CEB7C2.2YE4IAP7185GC@debian> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
We've been dealing with a rash of crypto mining attacks.
Details
Message ID
<CALUC3HH97NA.1Q6JEU0RGS1N0@debian>
In-Reply-To
<CALUAW5FYP4F.36LHNZ4ACUB72@taiga> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
Thank you for the prompt response, it all makes sense now!
I recall the doc edit earlier explicitly forbiding crypto mining (-;
Details
Message ID
<YHSEX5Xsufyvkcdv@t480>
In-Reply-To
<CALUAW5FYP4F.36LHNZ4ACUB72@taiga> (view parent)
DKIM signature
missing
Download raw message
On Mon, Apr 12, 2021 at 11:11:16AM -0400, Drew DeVault wrote:
> We've been dealing with a rash of crypto mining attacks.

Sourcehut is not alone with this problem:
https://news.ycombinator.com/item?id=26678700
Details
Message ID
<20210415152955.GA7715@computer>
In-Reply-To
<CALUAW5FYP4F.36LHNZ4ACUB72@taiga> (view parent)
DKIM signature
pass
Download raw message
I won't be able to attend the monthly Mumble meeting tomorrow, but RE
this thread and RE "What's cooking on SourceHut? April 2021" I wanted
give my 2-cents on the subject.

I support the idea of granting access to builds.sr.ht as a paid feature.
I don't have much experience with SaaS platforms, but I imagine that
these attacks will continue as long as the barrier to entry for
crypto-mining is low. I don't follow the actual development side of
sourcehut that closely, so I'm not sure what mitigations have been put
in place thus far, but I am willing to bet it has been (and probably
will continue to be) an uphill battle.

One option that might be worth looking into is the idea of "build
minutes", similar to how GitLab structures their build jobs. New users
could get some small number of build minutes while paid users get
unlimited minutes. As long as the available build minutes to new users
is below the threshold required to get a return on investment for
crypto-miners then everything should work out, no?

This strategy would lock out many users from getting to know the build
service, but since sourcehut will eventually transition to a fully paid
service anyway I feel like this would be a fair change as long as
existing users were given enough advance notice to switch to a paid
plan.

Cheers,
- ashn
Details
Message ID
<CAOFGL8UAV3J.3E15VIVUHYVC2@debian>
In-Reply-To
<20210415152955.GA7715@computer> (view parent)
DKIM signature
pass
Download raw message
On Thu Apr 15, 2021 at 11:30 AM -0400, ashn wrote:
> I won't be able to attend the monthly Mumble meeting tomorrow, but RE
> this thread and RE "What's cooking on SourceHut? April 2021" I wanted
> give my 2-cents on the subject.

It'll be the healthy time to go to sleep for me, so I might not be able
to attend it as well, so I'll be dumping my thoughts here also.

> One option that might be worth looking into is the idea of "build
> minutes", similar to how GitLab structures their build jobs. New users
> could get some small number of build minutes while paid users get
> unlimited minutes. As long as the available build minutes to new users
> is below the threshold required to get a return on investment for
> crypto-miners then everything should work out, no?

While I've have no idea on how effective this will be against crypto
miners, limited minutes can be an extremely frustrating experience.
I can still recall how I felt when I was migrating away from Travis
after the pricing change: I had to calculate how many credits it would
take before every move.  In addition, depending on the project, the
majority of the builds might come from either push or patches, and the
uncertainty in later is even worse for the maintainers' mental health.

In other words, I feel strongly against this proposal, and suggest
to keep it clear in favor of an users' mental health: either that user
has unlimited build time, or none at all.  This also reflect the current
promise on the pricing page (https://sourcehut.org/pricing):

> On sr.ht, all plans have access to the same features, at the same level.

i.e. there should be no such thing as a *trial* plan.

> This strategy would lock out many users from getting to know the build
> service, but since sourcehut will eventually transition to a fully paid
> service anyway

Also from the pricing page, people can request in person to have access
to the service (once it is mandatory to pay):

> If you require financial aid to use sourcehut, please send an email
> explaining your circumstances and we'll do our best to accommodate
> your needs.

Another (more risky) alternative is to allow referring, i.e. during
alpha a paid user can promote others to use builds.sr.ht, which makes it
easier to deal with (in groups) if the referrer is malicious.
Disclaimer: I'm a paid user and I'm inviting some of my friends to try
out SourceHut.  IMHO the build service is the most life-changing feature
that can convince people to switch; people who wants the email workflow
(like me) would have gone look for SourceHut anyway.

> I feel like this would be a fair change as long as existing users
> were given enough advance notice to switch to a paid plan.

I think it's worth noting that the attacks are happening at the moment,
so it would not be a good idea to give *enough advance*.
Details
Message ID
<20210416142045.GA13263@computer>
In-Reply-To
<CALUAW5FYP4F.36LHNZ4ACUB72@taiga> (view parent)
DKIM signature
pass
Download raw message
>While I've have no idea on how effective this will be against crypto
>miners, limited minutes can be an extremely frustrating experience.
>I can still recall how I felt when I was migrating away from Travis
>after the pricing change: I had to calculate how many credits it would
>take before every move.  In addition, depending on the project, the
>majority of the builds might come from either push or patches, and the
>uncertainty in later is even worse for the maintainers' mental health.
>
>In other words, I feel strongly against this proposal, and suggest
>to keep it clear in favor of an users' mental health: either that user
>has unlimited build time, or none at all.  This also reflect the current
>promise on the pricing page (https://sourcehut.org/pricing):
>
>> On sr.ht, all plans have access to the same features, at the same level.
>
>i.e. there should be no such thing as a *trial* plan.

I think you make a valid point here. It would feel a little skummy to
lock some users out in this way based on plan details.

>Another (more risky) alternative is to allow referring, i.e. during
>alpha a paid user can promote others to use builds.sr.ht, which makes it
>easier to deal with (in groups) if the referrer is malicious.
>Disclaimer: I'm a paid user and I'm inviting some of my friends to try
>out SourceHut.  IMHO the build service is the most life-changing feature
>that can convince people to switch; people who wants the email workflow
>(like me) would have gone look for SourceHut anyway.

This sounds like somewhat of a better idea, but I worry that users
without a referrer would run into the same issues that they would see if
sourcehut switched to a SaaS model for builds.sr.ht. If a user does not
have connections to someone using a paid account then they would be
locked out under this model. I myself am the first one in my social
circle to use sourcehut, so under this model there would have been no
user to refer me.

This also creates an artificial "in club" of users who would have a
referrer similar to how sites like lobste.rs operate. This is not
necessarily a bad thing, but does create tangible social barrier to the
platform. I'm not 100% sure how I feel about it though, so those are
just my initial thoughts.

Cheers,
- ashn
Details
Message ID
<CAP945LPGS69.1VW4TZK49M8G2@debian>
In-Reply-To
<20210416142045.GA13263@computer> (view parent)
DKIM signature
pass
Download raw message
> > Another (more risky) alternative is to allow referring,
>
> This sounds like somewhat of a better idea, but I worry that users
> without a referrer would run into the same issues that they would see if
> sourcehut switched to a SaaS model for builds.sr.ht. If a user does not
> have connections to someone using a paid account then they would be
> locked out under this model. I myself am the first one in my social
> circle to use sourcehut, so under this model there would have been no
> user to refer me.

IIUC sr.ht is technically a SaaS, just that it tries to be as ethical
and user-respecting as possible, and that it is still in alpha stage.

Word nitpicking aside, people can already email Drew DeVault asking for
help if they cannot afford paying (or cannot access the payment method):
https://man.sr.ht/billing-faq.md#i-cant-afford-an-account-am-i-out-of-luck

My proposal was to allow every paying user to do the same thing (only
during alpha of course, were sr.ht to make builds a paid service now),
and to revoke the referrer of any of the referree break the rules.
This should make people extra careful when referring others.
AFAICT administrator jobs on sr.ht are still done manually so in case
of mistakes there could be immediate discussion to resolve the issue.

Though, I'm not sure how effective this will be, both for maintaining
the growth of the platform and preventing crypto miners.  Changes to
build.yml does not have effect on patches via email (because the build
starts before applying the patch), however I'm not sure if it's still
the case for dispatched jobs.  Plus, one could shadow one of the
programs executed by the job and successfully inject the miner.

On second thought, I think I'll be sleeping a little late tonight to
hear others' opinions and analysis on the matter.
Details
Message ID
<8f5ccc33-2d3c-428e-2ee8-8c3b4e6e506f@pate.house>
In-Reply-To
<CAP945LPGS69.1VW4TZK49M8G2@debian> (view parent)
DKIM signature
pass
Download raw message
On 4/16/21 11:25 AM, Nguyễn Gia Phong wrote:
> and to revoke the referrer of any of the referree break the rules.
> This should make people extra careful when referring others.

Scenario A:  I think Sourcehut is great and want others to use it.  Because I can only refer those I trust with my own access, I end up having to promote it with the caveat of "I don't trust you enough to let you try out all of the features".

Scenario B:  I refer someone I mostly trust, but I don't control their security.  They get hacked, and their Sourcehut account is abused.  I am penalized for their security lapse.

Is the complication of a referral scheme actually worthwhile?

Eventually, builds.sr.ht will be a paid-only service anyway.  Due to bad actors it would become a paid-only service sooner than expected, and that should go a long way towards solving the immediate problem.
Details
Message ID
<10bd6f119c867a5a8a62ac6f270325cc2ccecee1.camel@mailbox.org>
In-Reply-To
<CAP945LPGS69.1VW4TZK49M8G2@debian> (view parent)
DKIM signature
pass
Download raw message
An incomplete, yet simple way to fight abuse may be to:

1. Delay enqueue of builds by 4h from the moment of account creation
2. Sandbox networking to sourcehut-local destinations
3. and of course the hardest, avoid spam accounts

Most new users will go through the doc material and set up some repos
etc. before they even think of firing up a build.

For 2. it may be necessary to create some (caching?) proxies, to access
public package repositories. Might be even good for the general
bandwidth usage.

Beyond that, I'd say paid account can open firewall.
Reply to thread Export thread (mbox)