Closed SomeTroglodyte closed 1 year ago
It's time to move code to sourceforge.net
Very unhappy about this as well. Been migrating quite a few projects to https://gitlab.com, which is a decent alternative for those who don't want to bother with Microsoft's shenanigans. (they do occasionally have shenanigans of their own, such as the current "forced" free trial of the Ultimate edition for everyone, but it's not half as bad as here)
I seem to not understand the dialogue above. What impact does real-name authentication on Github have? Will it affect mainland China, where internet censorship is more strict?
What impact does real-name authentication on Github have? Will it affect mainland China, where internet censorship is more strict?
More tracking your life, and selling your data to other company
I've used Gitlab in the past, and probably future projects will start there, but the cost of migration would be very high, especially for the release pipeline :( I fully support your decision
I don't think that mirroring would be a good solution here but I'll investigate it - master branch syncs from github to gitlab, feature branches sync the reverse, and the merge occurs in Github, sounds like it should work in theory... But requires Premium
https://about.gitlab.com/pricing/
And I am not paying for that, no sir
https://about.gitlab.com/pricing/
And I am not paying for that, no sir
To be fair, this is the pricing for enterprise customers. Enrolling in the Open Source program is a bit of an administrative hassle, but gives you Ultimate tier benefits for free. I guess Unciv would qualify.
Edit: just shooting an email at them and explaining that you'd like to migrate from GitHub while asking about pricing might be a low hanging fruit.
disclose a mobile number
@SomeTroglodyte I'm... confused. I'll have to double check my situation (once the accounts section stop giving an html 500 error), but I don't think I had to disclose a phone number to comply with the requirements for two factor authentication. Instead I just choose to use an authenticator app such as Aegis
authenticator app
One of the points - no transparency on whether they support an open source authenticator app. All others can be assumed to phone home including IMEI, and the connection is made. Or maybe I'm blind and it will just work... And the Aegis source zip is only 8M, so it might be easy to verify as clean. Thanks for the tip.
gitlab
My past experience is pure prejudice, but along the lines of "they seem to have actual humans on the team and to a degree still value common sense". But yup, of course the pricelist is geared towards projects that earn or will earn money, not projects with some value through publicity...
authenticator app
One of the points - no transparency on whether they support an open source authenticator app. All others can be assumed to phone home including IMEI, and the connection is made. Or maybe I'm blind and it will just work... And the Aegis source zip is only 8M, so it might be easy to verify as clean. Thanks for the tip.
I've been using Aegis with GitHub professionally for ~3 years now, works without a hitch and it's FOSS. But I loathe having to use it on my private accounts & phone. They shouldn't be pushing this.
Just ran Aegis from source, and spent half an hour skimming the code. Looks nice, no signs of skulduggery, well organized, and "simply works" right off cloning. So when the date comes I'll probably try, unless I have one of those irrational "vade retro Palpatine" days...
The way authenticator apps work is that neither side even knows the other exists besides the fact that they somehow have the same code. Technically, just about any authenticator is fine, and there's nothing really to phone home about. https://en.m.wikipedia.org/wiki/Time-based_one-time_password
Well, I have had some knowledge of parts of the card house - but did I want to learn how all that has been pieced together today? Dying ignorant sometimes *is the happier death...
And yea the info is there in their press, scroll down about three pages from the blahblah excuses - but I'm still not happy I had to invest more than a minute reading all that. Reading Aegis source was way more fun (deep clone helper by serializing and deserializing - cooooool).
https://about.gitlab.com/pricing/
And I am not paying for that, no sir
@yairm210, @SomeTroglodyte Codeberg is free, open-source, community-run, and basically a 1:1 copy of Github in features, UI, and UX.
[…] but the cost of migration would be very high, especially for the release pipeline :(
I don't think that mirroring would be a good solution here but I'll investigate it - master branch syncs from github to gitlab […]
Codeberg runs Forgejo, which is described as a soft fork of Gitea. Because of this, it should eventually gain compatibility for Github Actions in the near-medium future.
So maybe the release pipeline/CI would still work or be easy to port (I'm not sure how it's set up now). Currently Codeberg integrates Woodpecker CI, and have said that they'll basically enable Github-compatible Gitea/Forgejo Actions as soon as somebody sets it up and Gitea irons out some stability/security issues. Could be an option, and might be better in the long run too.
Some more thoughts below on sustainability, the incentives of "free" investment-funded for-profit centralized Internet hosting companies, current options in the software ecosystem, and the problem with GitHub/GitLab compared to SourceHut/CodeBerg:
hopefully it's useful to you as well
At the very very least as useful as a healthy good laugh is (...end of details...). And quite enlightening. I fully agree. (enshittification - yup, nice read. Just add that gamification is a reliable early indicator enshittification is underway.) I didn't know a lot of what you researched (oh - and didn't want to know. Where's the un-know button? Ah, it's called "safety off then squeeze the trigger"...)
(oh - and didn't want to know. Where's the un-know button? Ah, it's called "safety off then squeeze the trigger"...)
Oh, no… Mood, but have a stiff drink, put on some music, and spend half your weekend surrounded by trees in public parks or wilderness instead. Computers are only real for as long as we put active effort into making them real, and the Internet especially so. …Bugs are real no matter where you are, though.
"inconvenient gut flora" - ROFL :zany_face: :upside_down_face: :rofl:
That 'enshittification' post is a good read, but otherwise I'm not sure what else is practical at the moment.
I cannot manage Unciv without automated releases - the only reason it's been this successful is because if the fast lead time, which relies on the automation pipeline we've built along the way. If we can use that same pipeline from somewhere else that's great, if not - the cost outweighs the benefits in my eyes.
For now, I'm willing to mirror to codeberg, and we'll see how it handles things.
I tried mirroring, and hilariously I caught a bug https://codeberg.org/yairm210/Unciv
I receive the email about 2FA:
Hey AutumnPizazz!
We're reaching out to let you know that as announced last year, we will officially begin requiring users who contribute code on GitHub.com to have one or more forms of two-factor authentication (2FA) enabled. You are receiving this notification because your account meets this criteria and will be required to enroll in 2FA by December 15th, 2023 at 00:00 (UTC).
We believe that securing the software supply chain starts with the developer. As GitHub is central to the software supply chain, our 2FA initiative is part of a platform-wide effort to secure the software ecosystem through improving account security. Developer accounts are frequent targets for social engineering and account takeover (ATO). Protecting developers and consumers of the open source ecosystem, including large enterprises, from these types of attacks is the first and most critical step toward securing the supply chain.
This email marks the beginning of your 45-day 2FA enrollment period. You'll receive additional reminders via email and the platform throughout the 45 days. After this 45 day window, your access to GitHub.com will be limited until you enroll in 2FA. A few things we think you should know:
2FA enrollment is required, and if you have not enrolled by December 15th, 2023 at 00:00 (UTC), you will have limited ability to access GitHub.com until you finish the enrollment process. Once you're enrolled, you will not have the ability to disable 2FA in the future.
Enrolling in 2FA is easy, and we accept several options including TOTP mobile apps, text messages (SMS), security keys, and GitHub Mobile. Click here to get started!
Already enrolled in 2FA? Thank you! No action is required on your part at this time.
To learn more about what to expect from the experience, please see the information below.
Making the software supply chain more secure is a team effort, and we can't do it without you. Your enrollment in 2FA is an impactful step in keeping the world's software secure.
What you need to know about the required 2FA initiative
We are enrolling GitHub users who manage or author code on GitHub. More information about our efforts to make 2FA adoption easy and safe can be found in this blog post. This is a GitHub.com program, and unrelated to any organization or enterprise membership your account may have.
How will this affect my account?
On December 15th, 2023 at 00:00 (UTC) your account will be required to have 2FA for authentication. If you have not yet enrolled by that date, your ability to access GitHub.com will be limited until you finish the enrollment process.
How do I enroll in 2FA?
Click here to get started! Prior to December 15th, 2023 at 00:00 (UTC) you can follow the instructions in our documentation to set up 2FA for your account. If you have not yet enrolled in 2FA by December 15th, 2023 at 00:00 (UTC), you will automatically be taken to the 2FA enrollment form the next time you access GitHub.com.
What forms of 2FA can I use?
We want you to have the most seamless experience with 2FA possible, so you can choose one or more of the following options:
Security key
GitHub Mobile
Authenticator application (TOTP)
Text messages (SMS)
You should set up at least two of these options, to ensure you always have access to your account. Head to https://github.com/settings/security to enroll more 2FA methods.
I already have 2FA enabled, do I need to do anything?
No, if you already have 2FA enabled before December 15th, 2023 at 00:00 (UTC), you don't need to take any additional actions. After December 15th, 2023 at 00:00 (UTC), you will no longer be able to unenroll from 2FA from your account, but you will be able to change the option you use for authenticating with 2FA. Additionally, you won't see any more banners on GitHub.com, and we won't email you about this anymore.
What happens to my PATs and SSH keys at the deadline?
Your PATs, SSH keys, and applications will all keep working after the deadline, regardless of your 2FA enrollment. PATs in particular are used extensively in important automation, and interruption there can cause outages in critical systems. However, when it is time to sign in to GitHub.com to create a new PAT or manage your account, you'll be required to enable 2FA before you can proceed.
What do I do if I lose my 2FA device?
GitHub strongly encourages the use of multiple second factor options. If you lose all of your second factors, recovery codes are the only way to access your account again. By saving your recovery codes, you'll be able to regain access.
Be sure to enable cloud backup for your authenticator app and save your recovery codes. Many phones and computers can be security keys as well - registering them with GitHub.com gives you additional, highly-secure 2FA methods.
For security reasons, GitHub Support may not be able to restore access to accounts with 2FA enabled if you lose your 2FA credentials and lose access to your account recovery methods.
More information about recovery codes can be found on GitHub Help at https://docs.github.com/articles/recovering-your-account-if-you-lose-your-2fa-credentials
Why is GitHub requiring 2FA?
Ensuring account security is a shared responsibility GitHub takes seriously. Strong authentication and the use of 2FA have been recognized as best practice for many years. We feel that GitHub has a duty to lead this push toward strong authentication as part of protecting the software supply chain.
To see this and other security events for your account, visit your account security audit log.
If you run into problems, please contact support by visiting the GitHub support page.
Thanks,
The GitHub Team
Is it safeless for our privacy?
The short version is, just get a form of 2fa. I recommend an authenticator app or similar totp program for privacy. Tbh, there's no real reason to worry about this from a privacy perspective unless you you text messages for it, and I promise you sms is an awful solution anyways
It is uneasy for me who live in Mainland China where people cannot use Google App Shop. I have no an authenticator app.
Well, I have succeeded in 2FA, with my Phone number and fingerprint noted. Wish it unsignificant to leak privacy.
Yup, Aegis. I run it compiled from source just to be safe (the colleague that recommended it here is a hero). Just remember my "personally identifiable" judgement was wrong - at least out of context - I meant by the 2FA app phoning home, as surely the g🤮🤮gle and tinysquishy apps do.
That said, what github does there now seems fishy from another angle - it has so far, in two weeks, only asked me once, even though I contributed from two different devices and logged in from a third. So they're storing the "don't ask again" data on their servers, and not per-device, throwing away some of the security potential... Or maybe they want to do infrastructure first and actual security later.
In my words: What most app- or hardware-based 2FA systems are based on, is sharing a secret once and then projecting that into the future. You share a secret by scanning that QR code. Later, a 2FA auth is asked for, and both parties calculate a derived secret from the shared secret and some "time" axis both can measure reliably independently, then compare that. If you read the code from the display and type it in, no network communication is needed at all.
and not per-device,
I consistently use a computer through a browser stored on a flash drive, and I literally need to enter my 2fa details literally every single time. The only device I never have to bother is in the browser on my phone, and that's because I'm already logged in. I suspect that's the situation for you: you was already logged in and so it didn't actually matter because of session cookies. That said, 2fa is not supposed to protect again someone trying to get session cookies, it's supposed to protect against the fact that passwords alone has inherent security flaws due to issues like some people using insecure passwords or the same passwords across sites to it being the only piece of info needed to log in. The idea behind 2fa is that the info needed is completely different: password ideally you remember from site to site while 2fa is ideal locked to only a specific device and cannot be simply remembered or written down
Yup, no 2FA prompt on this box is of course due to session in browser storage, but I was convinced that was not the case on the other box or the phone... No matter. But yea, I have sad that same thing - 2FA is a kludge they invented because users fail to properly handle passwords. If everybody were to use keepass as I do, that kdbx file would serve the same purpose as that QR code scan.
Little anecdote: Today it asked for 2FA confirmation about the 4th or 5th time, but after successful validation it presented me with - 403, "Access to github.com was denied, You don't have authorization to view this page" ! The morons bungled the back-to-content redirect, whatever 'voltron' means. Had they redirected properly to https://github.com/yairm210/Unciv/pull/10443 as the link in the mail really was - no trouble...
Since this is aimed at tracking, by forcing me to disclose a mobile number to github and thereby making me personally identifiable, I'll probably be closing my account here in mid-October.