I still don't have a clear understanding on when you would need such a thing.
This does not help the people who want to use git for video hosting since it puts the storage and usage back onto a persons credit card again (tho if you come into a line of credit it may be useful).
Hosting on AWS like this does not match the dark web requirements for hiding in plain sight and not easily killable. To spread this over multiple aws accounts and s3 buckets alone would need some form of sts cross linking for the permissions to allow pushing to be granted.
Can you provide a business use case or scenario this would be useable. Else it will continue to have the smell of 'resume driven development'.
To block force push, would also suggest that branch deletion would not work either. Is that the case?
branch deletion also does not work. the data model is very simple, a single chain of git bundles. s3 policy could enforce a variety of data models, such as inability to delete objects.
there is no business use case for this, unless your threat model needs an untrusted git provider and you don't have another way to enable that.
perhaps you could store your dotfiles or other backups with this.
This does not help the people who want to use git for video hosting since it puts the storage and usage back onto a persons credit card again (tho if you come into a line of credit it may be useful).
Hosting on AWS like this does not match the dark web requirements for hiding in plain sight and not easily killable. To spread this over multiple aws accounts and s3 buckets alone would need some form of sts cross linking for the permissions to allow pushing to be granted.
Can you provide a business use case or scenario this would be useable. Else it will continue to have the smell of 'resume driven development'.
To block force push, would also suggest that branch deletion would not work either. Is that the case?