2 ms·

I remember an old mailing list discussion on sourcehut, because sourcehut provides a build service that you can use for automation. The decision from sircmpwn

by ljm 5y ago

I remember an old mailing list discussion on sourcehut, because sourcehut provides a build service that you can use for automation. The decision from sircmpwn was, at the end, to charge money for the service. Charging money and KnowYourCustomer will kill most exploits dead. In this sense, this is turning the frustration level to 11. You can use the service to a certain extent, without frustration, but if you want to get serious then you're going to have to jump through some hoops. Dedicated people will still find a way through, but you've cut off 95% of the flow and killed the low-effort attempts. Now, you can focus on the serious shit.

Qub3d 5y ago
> The decision from sircmpwn was, at the end, to charge money for the service. Frankly, I'm shocked the other major free providers (GitHub/Lab) haven't done this by default. GitHub's current default is free for public branches, and a small fee for private. I could see a flipped setup working: by default a very small fee (1-5 cents per x number of batches) that most companies wouldn't notice, and a path for FOSS projects to apply for credits. I can't find the direct link, but I remember someone on HN pointing out that because CI tools are turing complete, GitHub actions is the cheapest serverless cloud product in the world right now -- you just need to figure out how to game the system. I'm sure they've built very sophisticated filtering tools, but imagine someone slips through the cracks and gets a cryptominer working. Get that action registered in enough projects (by, say embedding it in an Actions library or generator tool) and that could be significant.
- shakna 5y ago
  > I'm sure they've built very sophisticated filtering tools, but imagine someone slips through the cracks and gets a cryptominer working. It's been done, multiple times. Here's a handful (96) of documented cases which are somewhat recent. [0][1] It seems to be surprisingly easy to abuse the process, and GitHub are continually playing catch up. [0] https://dev.to/thibaultduponchelle/the-github-action-mining-attack-through-pull-request-2lmc https://dev.to/thibaultduponchelle/the-github-action-mining-... [1] https://www.bleepingcomputer.com/news/security/github-actions-being-actively-abused-to-mine-cryptocurrency-on-github-servers/ https://www.bleepingcomputer.com/news/security/github-action...
pitay 5y ago
Sounds like a micropayment system where there is much more significant first buy in amount to be on the micropayment system than the actual (tiny) cost of a micropayment to use a service would make it worth far less worth it to spam online services. The risk of having their payment identifier/address banned from services before significant use makes it very risky for them to use such a thing even if tiny micropayments a worth it to the spammer. It certainly could have other problems with people getting banned from such a system for things other than: spam and other use detrimental to the service provider. There is also the issue of how the initial buy in fee is distributed. But a high buy in for a system that many online service providers use would very strongly discourage use detrimental to the services providers (I think; this is only for discussion, as this is posted by someone with little knowledge on this. Micropayment systems have been talked about a lot, but I don't remember high buy-in mentioned). Edit: Forgot to mention that the idea of this is that service providers can offer their services at lower cost because the risk to them from a account/address with a high buy in is lower than from an account/address with no buy in.

by ljm 5y ago

Qub3d 5y ago

> The decision from sircmpwn was, at the end, to charge money for the service. Frankly, I'm shocked the other major free providers (GitHub/Lab) haven't done this by default. GitHub's current default is free for public branches, and a small fee for private. I could see a flipped setup working: by default a very small fee (1-5 cents per x number of batches) that most companies wouldn't notice, and a path for FOSS projects to apply for credits. I can't find the direct link, but I remember someone on HN pointing out that because CI tools are turing complete, GitHub actions is the cheapest serverless cloud product in the world right now -- you just need to figure out how to game the system. I'm sure they've built very sophisticated filtering tools, but imagine someone slips through the cracks and gets a cryptominer working. Get that action registered in enough projects (by, say embedding it in an Actions library or generator tool) and that could be significant.

shakna 5y ago
> I'm sure they've built very sophisticated filtering tools, but imagine someone slips through the cracks and gets a cryptominer working. It's been done, multiple times. Here's a handful (96) of documented cases which are somewhat recent. [0][1] It seems to be surprisingly easy to abuse the process, and GitHub are continually playing catch up. [0] https://dev.to/thibaultduponchelle/the-github-action-mining-attack-through-pull-request-2lmc https://dev.to/thibaultduponchelle/the-github-action-mining-... [1] https://www.bleepingcomputer.com/news/security/github-actions-being-actively-abused-to-mine-cryptocurrency-on-github-servers/ https://www.bleepingcomputer.com/news/security/github-action...

pitay 5y ago

Sounds like a micropayment system where there is much more significant first buy in amount to be on the micropayment system than the actual (tiny) cost of a micropayment to use a service would make it worth far less worth it to spam online services. The risk of having their payment identifier/address banned from services before significant use makes it very risky for them to use such a thing even if tiny micropayments a worth it to the spammer. It certainly could have other problems with people getting banned from such a system for things other than: spam and other use detrimental to the service provider. There is also the issue of how the initial buy in fee is distributed. But a high buy in for a system that many online service providers use would very strongly discourage use detrimental to the services providers (I think; this is only for discussion, as this is posted by someone with little knowledge on this. Micropayment systems have been talked about a lot, but I don't remember high buy-in mentioned). Edit: Forgot to mention that the idea of this is that service providers can offer their services at lower cost because the risk to them from a account/address with a high buy in is lower than from an account/address with no buy in.