First, they restricted code search without logging in so I’m using sourcegraph But now, I cant even view discussions or wiki without logging in.

It was a nice run

    • Auzy@beehaw.org
      link
      fedilink
      arrow-up
      18
      arrow-down
      6
      ·
      9 months ago

      There’s nothing wrong with it honestly, and OP seems to be giving bad info… And trust me, I’m not a fan of Microsoft lol

      i literally just tested Discussions and wiki in private browsing mode on a few repos and they work. Which just proves it’s not a big deal that needing a login isn’t an issue. Seems nobody actually upvoting doesn’t have a login

  • Scrubbles@poptalk.scrubbles.tech
    link
    fedilink
    English
    arrow-up
    85
    arrow-down
    3
    ·
    9 months ago

    Honestly for selfhosters, I can’t recommend enough setting up an instance of Gitea. You’ll be very happy hosting your code and such there, then just replicate it to github or something if you want it on the big platforms.

    • d3Xt3r@lemmy.nz
      link
      fedilink
      arrow-up
      151
      arrow-down
      2
      ·
      9 months ago

      Just so you’re aware, Gitea was taken over by a for-profit company. Which is why it was forked and Forgejo was formed. If you don’t use Github as a matter of principle, then you should switch to Forgejo instead.

          • Scrubbles@poptalk.scrubbles.tech
            link
            fedilink
            English
            arrow-up
            6
            ·
            9 months ago

            It’s more I don’t have them all checked out, and a good chunk are mirrors of github, so I’ll have to list out each one and push to a new remote, mirrors will have to be setup again, and I also use the container and package registries. I’m pretty embedded. It’s not impossible, but it’s a weekend project for sure.

            • zeluko@kbin.social
              link
              fedilink
              arrow-up
              3
              ·
              edit-2
              9 months ago

              If it was just forked, cant you just switch the package/container-image and be done?

                • StarDreamer@lemmy.blahaj.zone
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  9 months ago

                  Simply changing the binary worked for me. Been more than 1 month and no migration issues.

                  It does still show gitea branding, however.

                • PowerCore7@lemm.ee
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  9 months ago

                  If you are using containers, it should be fairly trivial. Otherwise, there might be some renaming to do, but Forgejo should be 100% compatible with Gitea (at least right now). Just make sure you have a good backup in case anything would happen.

        • lambchop@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          9 months ago

          My understanding is the fork isn’t doing much but waiting to see if gitea turns to shit, pushing all their changes upstream. If you use docker I’ve heard you can just pull the new image and it simply drops in, no migration needed.

    • MigratingtoLemmy@lemmy.world
      link
      fedilink
      arrow-up
      26
      arrow-down
      5
      ·
      9 months ago

      Forgejo for you chap.

      Honestly I’m kind of surprised that Gitea is still being recommended on Lemmy, it’s been a while since Gitea was acquired and the community has been raging since. Lemmy is regressing

      • superbirra@lemmy.world
        link
        fedilink
        arrow-up
        14
        ·
        9 months ago

        Lemmy is regressing

        it is not lol, you are just realising that you are not part of any elite for the simple reason of using it

    • SaladevX@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      13
      arrow-down
      8
      ·
      9 months ago

      +1 for Gitea. It’s super lightweight, and works really well! I recently switched to Gitlab simply because I wanted experience with hosting it, but Gitea is much lighter and easier to use.

      • Disregard3145@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        9 months ago

        Its pretty good, for most people there isn’t anything missing

        Actions can’t be triggered by workflow dispatch

        Pull requests can’t wait for status checks

  • Omega_Haxors@lemmy.ml
    link
    fedilink
    English
    arrow-up
    58
    ·
    9 months ago

    The writing was on the wall when they established a generative AI using everyone’s code and of course without asking anyone for permission.

    • Elise@beehaw.org
      link
      fedilink
      arrow-up
      5
      arrow-down
      3
      ·
      9 months ago

      It’s an interesting debate isn’t it? Does AI transform something free into something that’s not? Or does it simply study the code?

      • chebra@mstdn.io
        link
        fedilink
        arrow-up
        7
        ·
        9 months ago

        @xilliah It’s not free though. It came with licenses. And LLMs don’t have the capability to “study”, they are just a glorified random word generator.

      • Omega_Haxors@lemmy.ml
        link
        fedilink
        English
        arrow-up
        14
        arrow-down
        9
        ·
        edit-2
        9 months ago

        There’s no debate. LLMs are plagiarism with extra steps. They take data (usually illegally) wholesale and then launder it.

        A lot of people have been doing research into the ethics of these systems and that’s more or less what they found. The reason why they’re black boxes is precisely the reason we all suspected; they were made that way because if they weren’t we’d all see them for what they are.

        • AnonStoleMyPants@sopuli.xyz
          link
          fedilink
          arrow-up
          8
          arrow-down
          1
          ·
          9 months ago

          The reason they’re black boxes is because that’s how LLMs work. Nothing new here, neural networks have been basically black boxes for a long time.

          • Kaldo@kbin.social
            link
            fedilink
            arrow-up
            6
            arrow-down
            1
            ·
            edit-2
            9 months ago

            Sure, but nothing is theoretically stopping them from documenting every single data source input into the training module and then crediting it later.

            For some reason they didn’t want to do that of course.

        • count_duckula@discuss.tchncs.de
          link
          fedilink
          arrow-up
          3
          ·
          edit-2
          9 months ago

          The reason they are blackboxes is because they are function approximators with billions of parameters. Theory has not caught up with practical results. This is why you tune hyperparameters (learning rate, number of layers, number of neurons ina layer, etc.) and have multiple iterations of training to get an approximation of the distribution of the inputs. Training is also sensitive to the order of inputs to the network. A network trained on the same training set but in a different order might converge to an entirely different function. This is why you train on the same inputs in random order over multiple episodes to hopefully average out such variations. They are blackboxes simply because you can’t yet prove theoretically the function it has approximated or converged to given the input.

          • Turun@feddit.de
            link
            fedilink
            arrow-up
            2
            ·
            9 months ago

            I doubt they have a factual basis for their opinion, considering

            they were made that way because if they weren’t we’d all see them for what they are.

            Is just plain wrong. Researchers would love to have a non black box AI (i.e. a white box AI), but it’s unfortunately impossible with the current architecture.

            • Elise@beehaw.org
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              9 months ago

              Their use of language also feels more emotional and if anything it makes me more skeptical.

  • TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    49
    arrow-down
    2
    ·
    9 months ago

    I moved all my open source projects to Gitlab the day Microsoft announced they were acquiring Github.

    (I wish in retrospect I’d taken the time to research and decide on the right host. I likely would have gone to Codeberg instead of Gitlab had I done so. But Gitlab’s still better than Github. And I don’t really know for sure that Codeberg was even around back when Microsoft acquired Github.)

    • antrosapien@lemmy.mlOP
      link
      fedilink
      arrow-up
      24
      ·
      edit-2
      9 months ago

      My first impression of gitlab was offputting because I was using hardened firefox and couldnt get past through cloudflare so I ended up using github. It was also better ui wise but now its just a mess

      Edit: slowly i’m starting to move everything to codeberg

      • bizdelnick@lemmy.ml
        link
        fedilink
        arrow-up
        12
        arrow-down
        1
        ·
        edit-2
        9 months ago
        1. It is FOSS while GitLab EE is not.
        2. It supports a lot of atifact repository formats while GitLab only docker registry.
        3. It is a non-commercial project.
      • toastal@lemmy.ml
        link
        fedilink
        arrow-up
        8
        ·
        9 months ago

        Codeberg is ran by a German nonprofit. GitLab is publically-traded on NASDAQ.

      • TootSweet@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        1
        ·
        edit-2
        9 months ago

        I’m not really sure it is. I just wish I’d shopped around before jumping to Gitlab, really.

        It kindof feels like Gitlab’s aims are more commercial and Codeberg’s are more in line with the FOSS movement, but that’s just a vague sense I have based on things I’ve seen but no longer remember specifically.

        CalcProgrammer1’s response to my post seems pretty informative and apropos, though.

    • akrot@lemmy.world
      link
      fedilink
      arrow-up
      6
      ·
      9 months ago

      The landscape is changing so fast thanks to LLMs, everything is becoming gated behind logins. Thanks ChatGPT.

    • CalcProgrammer1@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      9 months ago

      I still left my old and unmaintained projects on GitHub but I moved all my active projects to GitLab and any new projects go there too. I have them auto mirrored back to GitHub though as the more mirrors the better. I also recently set up a Codeberg mirror for some of my projects, though GitLab’s CI is what is keeping me on GitLab even though they nerfed the shit out of it and made it basically a requirement to host your own runners even for FOSS projects a year or two back. Still hate them for that and if Codeberg gets a solid CI option, leaving GitLab would make me happy. They too have seen quite a lot of enshittification in the years since Microsoft bought GitHub.

      • Baron Von J@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        9 months ago

        nerfed the shit out of it and made it basically a requirement to host your own runners even for FOSS projects a year or two back.

        Did they just reduce quotas (minutes?, cache storage?) or did they remove features? I’ve always used self-hosted runner

        • CalcProgrammer1@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          9 months ago

          Drastically nerfed the quotas. FOSS projects with a valid license used to have GitLab Premium access to shared runners and now even FOSS projects with a valid license get a rather useless 400 minutes. They also require new accounts to add CC info just to use that paltry sum which means FOSS projects can’t rely on CI passing on forks to ensure a merge request passes the checks before merging, as even if you have project specific runners set up forks don’t use them and neither to MRs.

          I wish companies didn’t offer what they can’t support from the beginning rather than this embrace, extend, extinguish shit. I guess in GitLab’s case there was no extend, it was just embrace FOSS projects and let them set up CI pipelines and get projects depending on the shared CI runners as part of merge request workflow for a few years and then extinguish by yoinking that access away and fucking over everyone’s workflow, leaving us scrambling to set up project side runners and ruining checks on MRs.

    • gian @lemmy.grys.it
      link
      fedilink
      English
      arrow-up
      5
      ·
      9 months ago

      Make the move from Gitlab to Codeberg in the last few days: really simple to do, give it a try ;-)

      • TootSweet@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        9 months ago

        Yeah, good thought. The only reason I haven’t is just because I worry that moving constantly might deter people from using any of my FOSS projects. Just seems like it could be considered a red flag (a sign of a “bad” or poorly-managed project) to some. (And… well… given that I didn’t do the research when I moved those projects, it wouldn’t be an entirely inaccurate conclusion to draw.)

        Oh, I guess also I’d need to log back into my Github and change everything that says “moved to Gitlab” to say “moved to Codeberg” and update links. (I literally force-pushed to overwrite the entire history of my Github projects with a single commit each with just a README that says it moved to Gitlab with a link.)

        Plus, if I really looked into it, I might decide I’d prefer to self-host on something like Gitea.

        I guess all that to say I’d definitely want to put more thought into it before migrating any particular place a second time. Doing the actual move is indeed the easy part, but there’s a lot of thought and research to do before that. And a lot of meta-considerations to take into account.

        Sounds like you like Codeberg, though. Just out of curiosity, what sold you on Codeberg?

        • gian @lemmy.grys.it
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 months ago

          Sounds like you like Codeberg, though. Just out of curiosity, what sold you on Codeberg?

          Basically the fact that they are in Europe and for now they are free (even if I am planning to contribute some euros) and without all the “every site need to be a social network” facade (like Github).
          All the features I need are present and I were not using the missing one anyway (like the CI). And I like to support an EU company ;-)

          Additionally it is a couple of years that I am trying to move away from US companies for every service I use, the move from Gitlab to Codeberg is the last one and came natural.

  • youmaynotknow@lemmy.ml
    link
    fedilink
    arrow-up
    40
    ·
    9 months ago

    I’m honestly blown away by whomever finds this surprising. This is Microsoft we’re talking about. Everything they touch turns into this. Taking what is not theirs, using it for profit, and not even giving credit where credit is due.

  • inspxtr@lemmy.world
    link
    fedilink
    arrow-up
    26
    arrow-down
    1
    ·
    edit-2
    9 months ago

    Hold up, are you sure you can’t view Discussions or Wiki? Which sites can you not view them?

    I’m fine viewing them for public repos that I usually visit.

    Asking to make sure that Github is not slowly rolling out this lockdown.

    • antrosapien@lemmy.mlOP
      link
      fedilink
      arrow-up
      8
      arrow-down
      3
      ·
      9 months ago

      Most probably. I was viewing discussions about podman, I could view them if directily opened from a link but it required login when navigated to linked pages and wiki

  • e$tGyr#J2pqM8v@feddit.nl
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    edit-2
    9 months ago

    I’m not a developer so I’m not very familiar with this world. But it kind of amazes me that the code for so many open source projects are hosted by Microsoft. Isn’t there a FOSS alternative? edit: seems Gitlab is an alternative. Then the question is, why are people using microsoft products?

    • antrosapien@lemmy.mlOP
      link
      fedilink
      arrow-up
      20
      ·
      9 months ago

      Github started independently and was amazing service(and still is except now its going downhill) but Microsoft acquired it it 2018

    • DacoTaco@lemmy.world
      link
      fedilink
      arrow-up
      10
      ·
      edit-2
      9 months ago

      The power of git ( the backbone of github ) comes in that you can easily take a repository and move it to a different server. Its like, 3 commands? ( git vlone, git add remote, git push ). So if people would leave github, nothing is lost :)

      • federico3@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        ·
        edit-2
        9 months ago

        Github is designed to centralize git (as the word “hub” suggests). You can still migrate away code, issues and wikis, but contributors, followers, wiki editors, issue subscribers, visibility in general and github stars are locked in. Discoverability matters to projects trying to attract contributors.

        • DacoTaco@lemmy.world
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          edit-2
          9 months ago

          Agreed there, but its still a source control platform. Its still git. I’d argue the code is the most important part and followers, subscribers and stars (whatever those may do) are a secundairy functionality that a developer doesnt necesarily care about. The most important part is the git repo and everything linked with it imo

  • pastermil@sh.itjust.works
    link
    fedilink
    arrow-up
    13
    ·
    9 months ago

    They also broke some stuff with some javascript, I think. I’m using KDE’s web browser (Falkon) and it used to work well.

  • Auzy@beehaw.org
    link
    fedilink
    arrow-up
    23
    arrow-down
    10
    ·
    edit-2
    9 months ago

    I just checked, and unless I’m missing something, you’re wrong? Tried https://github.com/snowplow/snowplow/wiki in private browser mode. Seems to work fine… Discussions work too.

    And the restricted code search is not a big deal. You can still see and download all the source code you want and search that way. What usecase do you have for code searching without login? Lemmy is restricted too without login (as well as literally everything). The funny thing is that the last person I saw make a huge deal of this on Lemmy/Reddit, didn’t have a huge number of github commits over the years (they definitely had some, so they were active though, but even our newbies at work overtook them in months)

    Creating a login is free too, and so is downloading source code. Github is a FREE service lol… And you’re whinging you need to create a free login? If you don’t like Github, then don’t use it lol. Absolutely nothing is preventing anyone migrating lol

    • ReversalHatchery@beehaw.org
      link
      fedilink
      arrow-up
      4
      ·
      9 months ago

      Lemmy is restricted too without login (as well as literally everything)

      You mean that you cannot comment or vote without an account? That just makes sense, because you need an account to tell the server to save some data of yours. That has to be connected to an account. Search does not (unless you are fixated on saving all actions of the user on the platform for behavioral analysis)

      The funny thing is that the last person I saw make a huge deal of this on Lemmy/Reddit, didn’t have a huge number of github commits over the years (they definitely had some, so they were active though, but even our newbies at work overtook them in months)

      Maybe you didn’t know, but not everyone in IT (job or hobby) writes code.

      Creating a login is free too

      Not really: you have to give personal information.
      It’s not much of a problem until they only need an email address and are not too opinionated on your provider, but it’s not rare at all that platforms also require a phone number (either upfront at registration, or discord-microsoft-style, locking you out of your account untill you give it them) which for the most part won’t be private at all. Thus, you are paying with your data. For something (repo content) that the maintainers wanted to be public and free.

      Creating a login is free too, and so is downloading source code

      What about the Wiki and Discussions? Several others said things that make me think it’s under A/B testing.

  • mozz@mbin.grits.dev
    link
    fedilink
    arrow-up
    23
    arrow-down
    10
    ·
    9 months ago

    I’m still stuck on why I have to create a password-equivalent API token, and then store it on my hard drive if I want an at-all-convenient workflow.

    “We made it more secure!”

    “How is storing it on my hard drive more secure”

    “Just have it expire after a week!”

    “How is it more secure now, seems like now there are two points of failure in the system, and anyway I keep hearing about security problems in github which this hasn’t been a solution to any of them”

    “SHUT UP THAT’S HOW”

    • ISometimesAdmin@the.coolest.zone
      link
      fedilink
      arrow-up
      27
      ·
      9 months ago

      An API token is more secure than a password by virtue of it not needing to be typed in by a human. Phishing, writing down passwords, and the fact that API tokens can have restricted scopes all make them more secure.

      Expiration on its own doesn’t make it more secure, but it can if it’s in the context of loading the token onto a system that you might lose track of/not have access to in the future.

      Individual API tokens can also be revoked without revoking all of them, unlike a password where changing it means you have to re-login everywhere.

      And that’s just the tip of the iceberg. Lmk if you have questions, though.

      • mozz@mbin.grits.dev
        link
        fedilink
        arrow-up
        2
        arrow-down
        6
        ·
        9 months ago

        Oh, API tokens in general, I think are great. As an additional layer of security between “I need my program to be able to access this API” and “I type my password”, they are great. My issue is with the specific way that github has implemented them.

        An API token is more secure than a password by virtue of it not needing to be typed in by a human.

        Remind me. When I create my API token, how do I provide it to git?

        Am I, more or less, forced to save my token to persistent storage in a way I wouldn’t be with a password? I realize that most people store either one in a password manager at this point. My point is, if you’re going to store your password-equivalent in a password manager, how have you achieved greater security as compared with storing a password in the same password manager? How is that not just adding another compromise vector?

        Phishing

        Remind me. Does making a system significantly more complex mean that phishing gets easier? Or harder?

        As an example, if someone can phish my password from me to compromise my security, is that better or worse than if they can either phish my password or else compromise my tokens? I remember this compromise for example, but I can’t remember whether it involved passwords or tokens.

        writing down passwords

        Remind me. Help me understand. Can someone write down their github password if the API token system exists? If they have to use it sometimes to log in to the web site anyway?

        and the fact that API tokens can have restricted scopes

        Yes. API tokens are a good system, in general, and restricting the scope of what they can do and making them time-limited are good reasons why.

        My argument is that, in general, (a) adding an additional point of access to a system without doing anything to disable the existing point of access, and (b) saving a password equivalent to someone’s system instead of having the “standard way” be for them to retype their password to authenticate each session but not have it saved anywhere, are both overall reductions in security.

        I get the motivation that github sometimes protects really critical stuff, and so it needs to be more secure. I am saying that their particular implementation of API tokens led to an overall reduction in security as opposed to an increase.

        • ReversalHatchery@beehaw.org
          link
          fedilink
          arrow-up
          1
          ·
          9 months ago

          Remind me. When I create my API token, how do I provide it to git?

          By copy-pasting it somewhere it has access to it. It can be the config file, it has several ways to use the system’s secret storage, and you can also autotype it from your password manager every time if you want.

          forced to save my token to persistent storage in a way I wouldn’t be with a password

          So not really

          My point is, if you’re going to store your password-equivalent in a password manager, how have you achieved greater security as compared with storing a password in the same password manager?

          Passwords can be short and simple. API tokens are lengthy and random, and you can’t change that. Also, you never type in your API key, and that can help against shoulder- and camera-surfing.

          without doing anything to disable the existing point of access

          You can’t do that, because

          • the API token is strictly for API access for outside programs
          • the API token cannot be used to manage your account, like change password or emails, or to create additional tokens

          API tokens are not a total replacement, just a more secure and restricted replacement for the everyday and not too risky tasks and for automated systems.

          • mozz@mbin.grits.dev
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            9 months ago

            I think this comment pretty well summarizes my argument on it. The only parts not addressed:

            Passwords can be short and simple. API tokens are lengthy and random, and you can’t change that.

            You can, as most modern web services including github do, have a minimum length and complexity for the password. That’s a very important part of the process yes.

            Plus, you seem to still not be grasping the core of my argument: github still authenticates with a password. You can still log in to the web site and change everything, if you compromise someone’s password, whether because it’s insufficiently complex or for any other reason.

            Also, you never type in your API key, and that can help against shoulder- and camera-surfing.

            I would like to see a quantitative comparison of how many github compromises there have been because of a stolen API token vs. compromises of some comparable service from a shoulder-surfed password.

            • ReversalHatchery@beehaw.org
              link
              fedilink
              arrow-up
              1
              ·
              9 months ago

              You can, as most modern web services including github do, have a minimum length and complexity for the password. That’s a very important part of the process yes.

              Sorry, I wasn’t clear. What I wanted to say is that passwords can be insecure, and in the case of lazy people that had consequences on security. I think the minimum is often not really secure, it’s just “fine if you really must” but allowed to not lose to many users.
              And at the same time tokens are always secure. It’s not defined by the user, they cannot lazy it away, it’s made equally complicated for everyone. Fortunately they don’t have to type it either, it’s copy paste and done.

              However I have to admit that while writing this response, complexity is not really the point with github access tokens.

              Plus, you seem to still not be grasping the core of my argument: github still authenticates with a password. You can still log in to the web site and change everything, if you compromise someone’s password, whether because it’s insufficiently complex or for any other reason.

              That’s right, these tokens won’t protect the lazy from their account being taken over. But I think these are still more secure for their use case: storing them in mostly text files, because the programs to which you give these will probably do that, and as these are not really password-equivalent things (these have very limited access to your account), it’s less of a problem.

              Your original question here was how will it be more secure that we are storing these tokens in our password managers besides our passwords. My answer is that even if you put it into your password manager, that’s not it’s final place: it will probably end up in text files and other such places, and if such a file gets into the wrong hands you’ll be in less of a trouble because of the limited permissions. If you would have stored your password there, you could be hoping that you’ll get your account back, and that the person did not do anything bad in your name.

              I think much of the confusion is coming from you believing that api tokens are equivalent to passwords. That’s not the case. Even if you give all possible permissions to a token, it won’t be able to do everything that you can do with the password through the website. In short, the main point here is that you don’t have to use your password in places where that’s totally unnecessary, and fewer permissions are fine.

              • mozz@mbin.grits.dev
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                9 months ago

                Can you really not understand that the github web site still uses passwords? And that these users you describe still need to know and use their github password in order to use github? So all the issues you describe with passwords still exist under github’s current security model. You’re getting that I’m saying that, right? I have more to say but I wanna pause for a second to focus on that point. If github really had replaced passwords with some other approach, or added a layer to their password security (e.g. enforced semi-2FA like Google does) I’d have a whole different take on it.

                And, please don’t say things like “much of the confusion.” It’s condescending and wrong to imply that the only possible reason we could be disagreeing is that I’m confused.

              • mozz@mbin.grits.dev
                link
                fedilink
                arrow-up
                1
                ·
                9 months ago

                it will probably end up in text files and other such places, and if such a file gets into the wrong hands you’ll be in less of a trouble because of the limited permissions

                I am abandoning this conversation. This is only true with API tokens. With passwords, it generally stays in the password manager. The fact that the damage from your stolen API token is then mitigated if you’ve reduced its scope still leaves you in a worse position than if it had never been stored in the text file and never been stolen in the first place. If you can’t or won’t grasp this central point (or the other I mentioned in my other message), I think we have nothing to discuss.

                • ReversalHatchery@beehaw.org
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  9 months ago

                  The fact that the damage from your stolen API token is then mitigated if you’ve reduced its scope still leaves you in a worse position than if it had never been stored in the text file and never been stolen in the first place.

                  First, it’s not a question if you have reduced it’s permissions. With an api token you simply can’t do a lot of things that you can with a password.

                  Second, you don’t use api tokens as a hobby. You use them because you want to use a tool that needs to have access to your account. Either you use an api token that has a limited set of permissions, or your password that can do anything. Independently of that, it will be stored in a plain text file, because where in the heaven would it store it so that it does not need to prompt you for it every single time? Yes, there are a dozen secret store programs that could be used instead, but a lot of programs will not have support for every one of them. I fail to see that in case how a token with fewer permissions is worse than a password with all the permissions.

    • bizdelnick@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      Never used it in GitHub, but in GitLab it is not password equivalent, you can restrict its usage.

    • JackbyDev@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      Because of someone gets your API token they can only push and pull. If someone gets your password they can do anything

      • mozz@mbin.grits.dev
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        edit-2
        9 months ago

        Let’s go over the attack vectors involved for different common workflows. I’m going to use the specific case of how I use git.

        1. Store passwords in pass, have them memorized and type them anew every time
        2. Store passwords in pass, store API tokens in OSX keychain

        Which is more secure? The thing that you’re saying is better-protected because it’s limited, doesn’t exist in workflow #1. The tokens aren’t limited to push and pull, because they’re limited to nothing.

        If someone gets my password in case #2, they can still do anything. That’s my central point – you haven’t removed any point of vulnerability, you’ve created another point of vulnerability and then mandated that people use it. And this isn’t an abstract issue; there are several compromises of github data stemming from people’s API tokens being compromised. My assertion is that in some of those cases, using case #1 instead of storing the API tokens would have prevented the compromise. Maybe I am wrong in that. I know that password compromises happen too. But my point is, you’re not preventing anybody from getting their password compromised. Someone can still steal my password out of pass. Someone who puts a keylogger on my computer will have the passwords to my OSX keychain and pass, both. You’re simply introducing another point of compromise, additional to password compromises, and mandated storage of your new password-equivalents on storage where before you at least had the option of memorizing them and typing them every time.

        Edit: And just to say it again, I have no problem with API tokens. If someone’s got an automated workflow set up, such that they have to set up a password-equivalent on their script that accesses github, they should absolutely create a usage-restricted API token and use that instead. I’m talking more specifically about the decision to ban people from typing their passwords when they want to interact with github, pretending that somehow that makes compromising the un-usage-restricted password impossible (when it doesn’t at all), and forcing people to store auth tokens in their local storage when they’d rather type their password every time.

  • UnfortunateShort@lemmy.world
    link
    fedilink
    arrow-up
    12
    arrow-down
    1
    ·
    9 months ago

    Compared to Gitlab, it definitely is shit already. And that has nothing to do with the artificial restrictions. God I hate this website. I appreciate their service, but the UI is genuinely trash.

  • PoliticalAgitator@lemmy.world
    link
    fedilink
    arrow-up
    10
    ·
    9 months ago

    You don’t need the question mark. If something is for-profit (or can be used for profit) then sooner or later it will be enshittified.

    They have teams of people whose entire job is figuring out ways to wring a few more cents from somebody. Put them at the helm of a company that’s stood for 1000 years and they’ll be thrilled at how easy it will be to use that name to sell plastic dogshit at a premium price.

  • 10_dollar_banana@lemmy.world
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    9 months ago

    What about the time they fired their artists and then immediately wrote a blog post congratulating themselves for making AI art from a model trained on the ex-employees’ art. Inspiring.

  • dinckel@lemmy.world
    link
    fedilink
    arrow-up
    7
    arrow-down
    3
    ·
    9 months ago

    I don’t really feel like self-hosting a Git instance is a good idea for me personally, but I’ve been really happy with Gitlab for around 8 years now