• Web3 developer Brian Guan lost $40,000 after accidentally posting his wallet’s secret keys publicly on GitHub, with the funds being drained in just two minutes.
  • The crypto community’s reactions were mixed, with some offering support and others mocking Guan’s previous comments about developers using AI tools like ChatGPT for coding.
  • This incident highlights ongoing debates about security practices and the role of AI in software development within the crypto community.
  • BrianTheeBiscuiteer@lemmy.world
    link
    fedilink
    English
    arrow-up
    95
    arrow-down
    3
    ·
    5 months ago

    One of the first things you should do in a repo is add a .gitignore file and make sure there are rules to ignore things like *secret* or *private* etc. Also, I pretty much never use git add . because I don’t like the laziness of it and EVERY TIME one of my coworkers checked in secrets they were using that command.

    • lurch (he/him)@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      55
      ·
      5 months ago

      Even though that’s a good extra precaution, per person config data, such as keys, should be stored outside of the repo, eg. in the parent directory or better in the users home dir. There is zero reason to have it in the repo. Even if you use a VM/containers, you can add the config in an extra mount/share.

      • barsquid@lemmy.world
        link
        fedilink
        English
        arrow-up
        6
        ·
        5 months ago

        What’s the general consensus on storing encrypted data in the repo with the keys outside? I see people recommend that but I’m too paranoid and my secrets are very small in size so it hasn’t been necessary.

        • lurch (he/him)@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          10
          ·
          edit-2
          5 months ago

          the format of the encrypted file can give the attackers an advantage. if your code reads the decrypted file, the attacker can guess the first line is a comment or the name of a setting. a savvy person can combine that with the algorithm to perform a “known plaintext attack”, for example by generating a number of possible passwords that would lead to files starting like that.

          • barsquid@lemmy.world
            link
            fedilink
            English
            arrow-up
            5
            ·
            5 months ago

            That’s smart. Anyone trying that should definitely have a machine-generated strong password!

          • Natanael@slrpnk.net
            link
            fedilink
            English
            arrow-up
            4
            ·
            5 months ago

            That’s not quite the definition of known plaintext attack (cryptography nerd here), that’s bruteforce with a “crib” to use older terminology (known patterns which allows you to test candidate keys).

            A known plaintext attack is defined as an attack on the algorithm to extract the key faster than bruteforce with analytical attacks.

        • Takios@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          8
          ·
          5 months ago

          I’ve seen that done for configuration management like Salt or Ansible. The repos for that were always hosted on internal Gitlab instances though.

        • elephantium@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          2
          ·
          5 months ago

          I see some of that in my job. We put encrypted data in settings files, and the keys for decryption are provided on the VMs where we deploy. The developers never actually see the keys.

          I suppose it’s as secure as the process for managing the production VMs, assuming the encryption isn’t just md5!

    • JimmyMcGill@lemmy.world
      link
      fedilink
      English
      arrow-up
      15
      ·
      5 months ago

      I basically always do a git add -p

      Very useful command and it works with other git commands as well.

      Everytime a colleague asks me for help with git that’s the one rule I suggest them to use.

        • PumaStoleMyBluff@lemmy.world
          link
          fedilink
          English
          arrow-up
          10
          ·
          5 months ago

          Instead of just adding whole changed files, it starts an interactive mode where it shows every hunk of diffs one by one, and asks you to input yes or no for each change. Very helpful for doing your own mini code review or sanity check before you even commit.

      • BrianTheeBiscuiteer@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        5 months ago

        For personal projects that’s definitely a good idea. For team projects I like to keep that stuff in the project still so the “experience” of working in the project is mostly consistent.

        • bellsDoSing@lemm.ee
          link
          fedilink
          English
          arrow-up
          2
          ·
          5 months ago

          I started using git-secret 2 years ago. It’s nice for making secrets part of the repo, while not being readable by anyone that isn’t explicitely allowed to do so (using GPG).

      • Kazumara@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        2
        ·
        5 months ago

        Better yet you can configure gitignore globally for git.

        I think you really need the project specific gitignore as well, to make sure any other contributor that joins by default has the same protections in place.

    • Nithanim@programming.dev
      link
      fedilink
      English
      arrow-up
      8
      arrow-down
      3
      ·
      5 months ago

      I never understood why everyone uses it as a ignore list. In my own and work repositories I always exclude everything by default and re-add stuff explicitly. I have had enough random crap checked in in the past by coworkers. Granted, the whole source folder is fully included but that has never been a problem.

    • sugar_in_your_tea@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      5 months ago

      git add -u is pretty nice, it only adds modified files.

      I usually do git add -p which is interactive (helps avoid committing debugging prints and whatnot), but the other is nice for bigger refactors.