> Lately some services started requiring 2FA. One of them is Github. Once I added 2FA to my Github account, it became less secure for me. Because security is not only about being protected from intrusion, but also about being able to securely access data at any time and in any circumstances.
>
> Now, my Github access depends on the second factor, which I have chosen to be Microsoft Authenticator running on my phone. I genuinely do not know what will happen if my phone breaks down, so I downloaded TOTP codes from Github and even tried one to see if it works, and so far it does, but now I have one less TOTP code to use in case something happens. Moreover, since Github is now a special case for my password management routine, I am afraid I may loose those TOTP codes and be totally locked out of my account
What? That's not what security means. Sure, you traded convenience for security.
Because the current obsession with security is making systems unsafe and unreliable for users, all while trying to get those users more dependent on said systems in their daily lives.
What is the biggest risk factor with Google account for me? Is it an attacker guessing my password, impersonating me, stealing my photos? No. It's me breaking my phone, and no longer being able to pass 2FA[0][1]. The second biggest risk? Me typing a wrong comment or YouTube, or doing any other minor transgression against ToS of some Google service, and losing access to everything in one go, with no recourse[2].
Note that literally nothing in meatspace ever requires as careful management over years to decades, as 2FA does. There is always a recovery procedure. You may need to stop by the court or a notary, but no matter the fuckup, you can always recover access - to everything except modern Internet services.
--
[0] - Yes, I have the security codes I generated 15+ years ago; I have them on paper, somewhere. Like most people, I suck at keeping small paper documents accessible and available over years.
[1] - Also yes, I did break my phone, and I survived this without data loss only because I had a complex setup around Pebble and Tasker, that allowed me to operate the phone with non-functioning screen remotely to the point I could mirror the display to the computer and continue from then. Most people in most situations can't do that.
[2] - Other than complaining on HN and hoping some Googler will advocate internally for me - which, as far as I know, they're explicitly not allowed to do, and it's a career-risking move.
Well OP is kind of correct because in security importance is given to CIA Triad: Confidentiality, Integrity, Availability.
Availability is important part of any system, if you lock out people, system will be secure but it stops serving its purpose.
Where OP fails is he seems not to understand password leaks and how much password+e-mail+phone number+other info lists are out there.
There is credential stuffing and password spraying running around from leaked passwords, so you can try dozen users on FB and just hit jackpot with one or couple, you don't have to brute force each one of them as there are countermeasures for that.
Even if you have weak password with a trick it is trivial to find out your trick when your password leaked from 5-10 services where you used the same e-mail.
>What? That's not what security means. Sure, you traded convenience for security.
Your Google/Microsoft/FB/etc accounts are used to sign in or access information about other extremely important things in your life, like your bank, payroll, travel companies, health records, taxes, insurance, everything really. If you get locked out of those SSO "identity providers", you get transitively locked out of everything else. Which means you could end up without access to money, unable to pay rent, unable to travel, contact friends for help, etc.
In other words, your physical security would be threatened, as in you might literally become homeless and die of exposure.
I used this to run the original Myst... on a PPC OS X iBook (I... think it was PPC. I genuinely don't remember). It worked great. Not sure about ARM64, but it should work there too.
Well, sometimes it all randomly crashed once in a while.
The protocol isn’t but its deployment is - real-world deployment is predominantly mobile. That’s nothing to do with the inherent technical features of the protocol, it is a consequence of market history
I wonder how it compares to Yaml 1.2, Yaml 1.1 (that are not compatible with each other), and the weird mix of 1.2 and 1.1 that go-yaml/yaml (the one used in k8s, helm, docker) use
The other guy got downvoted, but... isn't there really some tooling to help with this? Some standardized way of actually sending/reviewing the e-mails?
sourcehut has some GUI around it (that I never actually used). I heard that there is some local terminal thing around the e-mail git flow...?
One thing I like - in theory - is how decentralized/federated it all is. E-mail is the original decentralization/federation! But I never had to actually use it.
There is Patchwork which can help with managing the review workload and can also provide some CI feedback, some subsystems use that with some succcess, other's don't. It's not really something an individual can adopt so if you're working in an area that doesn't use it you're out of luck.
There is also Patchew which I've never tried.
But overall everyone just has their own individual pile of shell scrips and mail client macros.
Why would you expect there to be a standardised set of tools used by the largest distributed project in the world? Do you think that this would be possible to enforce globally in a way that makes everyone happier to contribute?
You mentioned two tools that are used by some subsystems. b4[1] is another one, and more are listed here[2]. So there _is_ tooling around it that works for many people. It's just not your preferred choice of tooling, which is... fine.
The fact that email is the lowest common denominator seems like a good thing to me. It allows everyone to use their tools of choice. As long as you can send and receive email, you can contribute. How you decide to integrate that into your development process is up to you. If you can't be bothered to setup a workflow from scratch, then you can adopt someone else's. I'd much rather have this choice, than be forced to use Gerrit or GitHub or whatever else.
I use b4, it largely solves sending code. It doesn't help with reviews though. (b4 shazam makes the manual application of patches to prepare a git-range-diff a bit easier but it's still basically a half baked process. It's fundamentally harder to to review patches than to review Git commits, a few thousand lines of Python won't make that reality go away).
> As long as you can send and receive email, you can contribute.
Sending and receiving email has so many barriers! The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use! Saying that email is a sensible lowest common denominator is crazy. The reality of it is that the kernel community is majorly dependent on GMail and GMail isn't even a good mail service for the job!
Using a git forge is dramatically easier to use and easier to set up, host and maintain.
However, AFAIK there isn't a forge that exists today that can actually meet the kernel's needs though. Switching to one would be a significant project. (But if the core maintainers wanted it, it would be very feasible).
> It's fundamentally harder to to review patches than to review Git commits
I'm not familiar with kernel development, but after you pull the patches locally, can't you simply review the commits via `git diff` or with whatever viewer you use? This is how I often review code when using GitHub. I only use the GH interface for sending my comments, which is what email in the kernel workflow is for.
The only thing a web-based tool is helpful for is for grouping discussions, and being able to reference or find them later. This might be more tedious with typical web-based email UIs, but most offer some kind of threading and search support, so it can't be that bad.
> Sending and receiving email has so many barriers!
Email has many problems, but I don't see barriers to using it as one of them. There are literally thousands of providers to choose from that could be suitable for sending and receiving patches.
> The Linux Foundation literally has to manage a mail server that people who can't get access to a working mail setup can use!
linux.dev is not managed by the Linux Foundation but by Migadu. It's only offered as a convenience service for people on corporate networks who have no control over their email. They could just as well choose to use another provider.
> Using a git forge is dramatically easier to use and easier to set up, host and maintain.
You contradict this right in your next sentence. You're right that maintaining a centralized system at this scale would be a daunting task. Email being decentralized avoids this problem altogether.
The thing is that a "forge" provides several loosely-related services.
Sharing code is a basic one that Git already does quite well over HTTPS and SSH. What I don't understand is why the patches simply aren't shared this way instead of using email as the medium. The problems outlined in the original article are very real. Kernel development could follow a similar suggested model where URLs to pull from are shared instead, while keeping email strictly for reviews and discussions. This way everyone would be free to choose where they want to host their fork, and maintainers can simply pull from it. But I digress...
The other things forges are used for are code reviews, CI, bug tracking, planning, etc. It's debatable how helpful any of these services are, and many developers would have their own preference. You might like Gerrit, but that's not a universal opinion. And I think most developers would agree that code reviewing in GitHub or Gitlab is painful. If it was up to me, I would choose a tool like git-appraise instead, but I'm stuck with GitHub because that's what the teams I've worked on have preferred.
So my point is that email is likely not the best choice for this, but it's a reasonable one that's flexible enough to be usable by anyone. Forcing any other tool on everyone would likely displease an equal or greater amount of contributors, while also introducing maintenance and reliability problems.
