1. 7
  1. 2

    this is unfortunate for projects that have CI and rely on new contributors.

    it also seems strange that they would just collect payment info. how does that deter abuse? if i give them a prepaid credit card with $2 on it, then i can circumvent this? what other reason are they collecting this info for that they aren’t disclosing right now?

    1. 3

      it raises the effort required for abusers, now they would need to buy a new card before abusing CI. in addition, gitlab may ban abusive accounts on an ad-hoc basis, and add the card’s token to an internal banlist. so if an account is suspected of CI abuse, their card is also burned.

      it’s also possible to ban easy-to-get credit cards by examining the card’s BIN.

      1. 1

        It’s even easier to just let project maintainers approve CI runs for new users manually, rather than ‘require’ payment info from them, which can (and will) be compromised/leaked later.

        A bad situation (shitcoin mining in CI) is not an excuse to implement bad policies.

      2. 1

        Perhaps this solution could be extended to bill that payment info for the cost of the CI run? It’s probably not worth credit card transaction fees at this stage, though.

      3. 1

        These abuses are just one aspect of why ASIC-resistant Proof of Work is a bad idea. I guarantee you nobody is bothering to mine Bitcoin this way, because SHA256-HMAC isn’t remotely competitive on GPUs or CPUs anymore. It’s not even worth stealing cycles. Black hats are probably mining Ethereum (GPU) or Monero (CPU).

        1. 1

          From an energy usage standpoint, all mining is bad, but ASIC mining is particularly bad, since energy was used up to make devices that can’t be repurposed for more useful computations.