Preventing Crypto Mining abuse on GitLab.com SaaS

FYI on related topic: Public open source projects are eligible for Ultimate tier features | GitLab

hello!

I would like to ask about the privacy concerns about this matter.

What happens if you enter a Credit Card for validating an account? Will it get saved on your account and be used for future purchases in GitLab? Can I opt to remove my credit card data due to privacy concerns?

I am just asking out of concern and curiosity. I feel like I may have skipped over some lines in the Privacy Policy regards this matter, and knowing how Credit Card details are managed may help me put my mind at ease in verifying my account.

Thank you.

@cindrmon Thanks for the question.

At the current time we only use the credit/debit card to validate the account for those who want to use GitLab hosted CI runners on free accounts. We don’t store the card. If this changes in the future, we will surely make this obvious when the credit card is requested.

More context here if interested: How to prevent crypto mining abuse on GitLab.com SaaS | GitLab

Does that mean that if I apply to the GitLab for Open Source Program and my group is admitted and a new user enters the group, they will not need to provide a credit card in order to be able to run pipelines (at least not until the group exceeds those 50k CI/CD minutes)?

Thanks for the question @jgonggrijp . The short answer is yes because the project will be effectively on a paid license if accepted to the open source program…

1 Like

Thanks. I asked a related question; would you be able to answer that, too?

That’s not a part of the product I am familiar with @jgonggrijp

Thanks anyway. Do you happen to know anyone who might be able to answer the question?

I’m asking around. Stay tuned…

1 Like

Y’all have got to find a better solution, as this is a major hurdle for OSS projects.

People who fork the project cannot have their merge request pipelines run, and the project is in a group which has an OSS Ultimate license applied.

I’ve gotten around this temporarily by adding trusted contributors to the project, but that is not safe or scalable for actual public contributions

@Mordil - Welcome to the forum!

If I understood your question correctly I think this docs page will help which details how to run pipelines of forks in the parent project.

If there are other problems with that pipeline running experience I’d be keen to hear about them or in a new issue. Thanks!

-James H, GitLab Product Manager, Verify:Pipeline Execution

Thank you for that link, it looks like I’m missing a change to my CI config to support this option.

Hi there,

I have been googling for a bit on the subject of the requirement for filling out creditcard info to validate new users on GitLab, but I can’t seem to find the answer to two specific questions:

  1. Do the CI/CD minutes of the premium tier count as purchased minutes? I’m assuming it doesn’t, since we have premium tier accounts that still get the validation error. How does that work exactly, since we are paying a monthly fee? Is there perhaps a configuration that we need to change?

  2. Alternatively, is it possible to use a single company creditcard for new users and hide the creditcard information from them?

Thanks in advance and I do apologise if this information is already noted somewhere!

Hi @fheijmans .

Do the CI/CD minutes of the premium tier count as purchased minutes? I’m assuming it doesn’t, since we have premium tier accounts that still get the validation error. How does that work exactly, since we are paying a monthly fee? Is there perhaps a configuration that we need to change?

If the user is in a project on a premium or ultimate tier, the user shouldn’t be required to validate their account with a credit card. I suggest contacting support to figure out why this is not working as expected. https://support.gitlab.com/hc/en-us

Alternatively, is it possible to use a single company creditcard for new users and hide the creditcard information from them?

There isn’t a way to do this as it is at the user level vs the company or project level. You could perhaps use something like https://privacy.com/ to achieve something similar perhaps.

1 Like

Thanks for the swift reply!

I will contact support about the issue first, but otherwise the free tier at privacy.com also seems sufficient for our use case. Although not ideal, it could be a nice workaround.

I get a blank screen

with the browser errors:

/assets/snowplow/sp-bc5b4b4067898d2d20c35fec045d91d032cb739c3deab5f42607edbeca08323a.js:1          Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
instrument.js:109 Welcome to GitLab!Does this page need fixes or improvements? Open an issue or contribute a merge request to help make GitLab more lovable. At GitLab, everyone can contribute!🤝 Contribute to GitLab: https://about.gitlab.com/community/contribute/🔎 Create a new GitLab issue: https://gitlab.com/gitlab-org/gitlab/-/issues/new🚀 We like your curiosity! Help us improve GitLab by joining the team: https://about.gitlab.com/jobs/
/docker-images-ansible/ubuntu-2004-ansible/-/runners/toggle_shared_runners:1          Failed to load resource: the server responded with a status of 401 ()
static.zuora.com/:1 Refused to frame 'https://www.zuora.com/' because it violates the following Content Security Policy directive: "frame-src 'self' https://www.google.com/recaptcha/ https://www.recaptcha.net/ https://content.googleapis.com https://content-cloudresourcemanager.googleapis.com https://content-compute.googleapis.com https://content-cloudbilling.googleapis.com https://*.codesandbox.io https://customers.gitlab.com".

sentry.gitlab.net/api/105/security/?sentry_key=a42ea3adc19140d9a6424906e12fba86:1          Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
(index):6745 crbug/1173575, non-JS module files deprecated.
(anonymous) @ (index):6745
zuora-min.js:27 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://www.zuora.com') does not match the recipient window's origin ('null').
postMessage @ zuora-min.js:27
zuora-min.js:27 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://www.zuora.com') does not match the recipient window's origin ('null').
postMessage @ zuora-min.js:27
zuora-min.js:27 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://www.zuora.com') does not match the recipient window's origin ('null').
postMessage @ zuora-min.js:27
zuora-min.js:27 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://www.zuora.com') does not match the recipient window's origin ('null').
postMessage @ zuora-min.js:27

I guess you need to fix zuora.com?

Thanks for reporting this @GodAtum . I will ask our fulfillment team to research.

We tested on multiple browsers and this is not reproducible at the current time. It may have been due to response time issues at Zuora which have since been resolved by them. Ref: Zuora Status

We continue to research.

Can you confirm if you are still having the issue?

1 Like

We have been able to reproduce the issue. Tracked in https://gitlab.com/gitlab-org/gitlab/-/issues/387487 (Payment form not rendered on account validation modal from Runner configuration). It is currently in review.

1 Like

This should now be resolved in production. Ref: Payment form not rendered on account validation modal from Runner configuration (#387487) · Issues · GitLab.org / GitLab · GitLab

1 Like