19 ms·

Yesterday I was being a bit of an ass to a few people about how "the whole point of using git is so that we can do decentralized code management and why these d

by rburhum 11y ago

Yesterday I was being a bit of an ass to a few people about how "the whole point of using git is so that we can do decentralized code management and why these dependencies were being pulled from our private github if the could be sent point to point yadda yadda yadda". Then they proceeded to go over the list of package managers and dependencies we used and I had to shut up. Even when we host our own Docker Hub and package managers (we do), if you dig far enough, you can find some dependency of a dependency of dependency that relies on GitHub. Brew/npm/build script/whatever. It is crazy how everything has changed so much in the past few years. GitHub went from something that was really nice to have to a core requirement for complex systems that rely heavily on open source.

viperscape 11y ago
The package system for the rust language actually relies on github, as many found out during outage. I don't know if that will change, probably will with a read copy in a different git service.. but I thought it was interesting because I use github for everything save a few private projects, as I imagine most do. I'm not sure what to think of this, it seems backwards and grossly incompetent, yet here we are using it almost exclusively. It might be smart to decentralize some of this with torrents, if that's possible. Even if it was the read portion of a repository, it seems like something to consider, if it hasn't been already
- rms_returns 11y ago
  Not just rust language, to the best of my knowledge, even packagist, the php package manager relies heavily on github for sourcing its packages. But I think they have other resources too, apart from github.
  - jdminhbg 11y ago
    Ruby's bundler doesn't entirely rely on Github, but pulling from a Github repo is a supported option that many take advantage of.
  - tatterdemalion 11y ago
    Rust's package manager doesn't source packages from GitHub (though it will pull packages from a git repo if you ask it to), the source for its index of packages is a git repository on GitHub. https://github.com/rust-lang/crates.io-index https://github.com/rust-lang/crates.io-index
- brinker 11y ago
  > The package system for the rust language actually relies on github, as many found out during outage. This is not quite correct (although close to it). Cargo doesn't rely on GitHub, but it expects that there is some publicly-accessible git repository from which it can pull the source for any crate, and most crates use GitHub. So it's not a particular choice of Cargo, but a side-effect of GitHub's popularity in the community, and the fact that Cargo does not host source code itself.
  - stouset 11y ago
    If crates.io hosted the content themselves, it would just be the same problem, only with a service potentially less reliable than GitHub.
    - st3v3r 11y ago
      Not if they acted like a mirror. Put it on GitHub, Bitbucket, and crates.io
    - kbenson 11y ago
      Unless you set up a system of mirrors. There are plenty of examples[1] to draw from. 1: http://mirrors.cpan.org/ http://mirrors.cpan.org/
  - agwa 11y ago
    The crates.io index is in a GitHub repository. Does Cargo fetch it directly from GitHub or from a set of redundant mirrors?
  - gkoz 11y ago
    You're mixing up cargo features and the crates.io package system. Cargo does allow git dependencies but primarily you're supposed to use versioned crates.io packages, which are indeed provided by crates.io (even if they are actually hosted on S3 or whatever) not GitHub.
nickpsecurity 11y ago
That's a good point. I've been ignoring learning Git as long as I can but almost everything on my todo list heavily uses it. Or ties into it as you said. So, I'm going to have to bite the bullet and learn it. Yet, I swore Git fans told me its decentralized design avoids single points of failures where everyone has a copy and can still work when a node is down just not necessarily coordinate or sync in a straight-forward way. This situation makes me thing, either for Git or just Github, there's some gap between the ideal they described and how things work in practice. I mean, even CVS or Subversion repos on high availability systems didn't have 2 hours of downtime in my experience. When I pick up Git/Github, I think I'll implement a way to constantly pull anything from Git projects into local repos and copies. Probably non-Git copies as a backup. I used to also use append-only storage for changes in potentially buggy or malicious services. Sounds like that might be a good idea, too, to prevent some issues.
- kbenson 11y ago
  Git works as advertised, but when all your build processes start with a sync from the upstream master (the equivalent of "svn up") that a lot of build scripts required that to work, then they've thrown away that advantage when building. Everyone with a checked out repo should have been able to develop and commit, branch and merge locally fine though.
  - nickpsecurity 11y ago
    Thanks for the clarification. This is the exact sort of thing I was wondering about.
- debaserab2 11y ago
  git != github
  - nickpsecurity 11y ago
    Hence Git/Github in my comment. I already know there's a difference. I just don't know much more than that until I learn the two.
forrestthewoods 11y ago
And people give me shit when I argue that open source projects should include 100% of dependencies.
- kbenson 11y ago
  I think that's a bit crazy as well. This is a problem if your build process happens often and requires pulling external data. Ideally, you want a way to cache that external data, and a way to force invalidation of that cache. Building, at least after the first time, should not require external access. There are security reasons for this as well.
  - zwetan 11y ago
    It's not, if you can not even run that first build then you actually have nothing to work on. Also, not frozen dependencies means you are at the mercy on any dependencies changes breaking your build at any time. With that, even if your first build run and go fetch those deps and can build at T1, it is not guaranteed at all that the build will work at T1+n. There is a big difference between your team working from trunk and your team being dependent on other projects trunk.
    - kbenson 11y ago
      > It's not, if you can not even run that first build then you actually have nothing to work on. Obviously you can run the first build. You wouldn't be using Github if you never got it working in the first place. To clarify, setting up the build environment may require network access, but if the process of building requires it, there are many places where it can go wrong, both operationally and security wise. > Also, not frozen dependencies means you are at the mercy on any dependencies changes breaking your build at any time. ... I agree, but that's a separate discussion and doesn't really apply here. There's nothing preventing the pulling of a specifically tagged version for builds. If someone's build process that used Git for dependencies is not doing this, whether they are using Github or some internal server is irrelevant, the same problems apply.
    - 11y ago
seiji 11y ago
if you dig far enough, you can find some dependency of a dependency of dependency that relies on GitHub. Brew/npm/build script/whatever But really, why? Is it just institutional laziness on the part of all developers? We had reliable rsync CPAN mirrors in 1995. In the early days of the Internet, companies would mutually host secondary DNS for each other to be more reliable. For some reason, we've forgotten all about reliability and disaster recovery and geographical distribution. Now the collective programmer mindset with regards to global infrastructure seems to be "lol, we're too dumb to make things work, let's just outsource everything to closed source, for-profit companies and hope for the best."
- hguant 11y ago
  I think a large part of this is that cloud hosting has allowed us to abstract those problems - reliability, disaster recovery, geographical distribution - away, and we don't really think of computers as computers anymore. It's a service or a platform or what have you, and the expectation is that it will always be there. I wouldn't say this is laziness, just a byproduct of changing how we view Internet architecture. We systems to take care of reliability etc because everyone has those problems. Now, those are only things you'll experience if you host your own stuff, or work for one of the big providers. (Broad assertion, I know, but I think it's mostly true)
  - seiji 11y ago
    Exactly right, but over the past six years there's been a strong (and accelerating) trend among developers of "lalala we don't want to know how anything works! give us an API and go away." Most developers I've seen reject even learning about networks or DNS or operating systems or databases. Such willful ignorance boggles the mind, but they are praised because their goals are shipping half-broken things as rapidly as possible to flip upwards for those oh-so-tasty acquihire payouts. We even saw this week how overconsumption of convenience APIs can put entire companies in danger when those privately controlled convenience APIs just decide to shut down one day. Convenience of immediacy always seems to trump connivence of long term stability.
    - 11y ago
chatmasta 11y ago
If this is a problem worth solving, you can absolutely solve it. The easiest would be through the use of a caching proxy and/or load balancing system. The caching proxy system could be as simple as setting up a squid cache for apt. Multiple projects exist which do this already. The load balancing system would involve keeping a private mirror of every repository in the dependency graph, and falling back to the mirror when GitHub fails. To automate this, proxy all git requests. If github is up, let the request pass through. If no mirror exists for the repository, create one. If GitHub fails, fall back to the mirror.
- yeukhon 11y ago
  > The easiest would be through the use of a caching proxy and/or load balancing system. Sorring if I sound like an asshole, but before we actually use the word "easiest", can you please share with us how to do all of that. It is not as easy as you claim, to be honest. Not just some /etc/hosts hijack.
  - brazzledazzle 11y ago
    They didn't say it was easy, just that it was easiest. Ostensibly comparing it to other solutions that they are aware of.
- tylorr 11y ago
  For the load balancing system I would assume you would also want to keep the mirrors up to date as well? So for every request if mirror exists and is out of date, update it.
  - chatmasta 11y ago
    Presumably that would be the responsibility of the mirroring system once a mirror is initiated.
swalsh 11y ago
I mean a really simple solution (simple to say, maybe not to do) would be for package managers to require a "backup" repository from a different domain, than if you get a 500 error try the second remote repository. Use git for its advantages.
- ugexe 11y ago
  I think you mean a mirror, and many package managers use them.

by rburhum 11y ago

viperscape 11y ago

The package system for the rust language actually relies on github, as many found out during outage. I don't know if that will change, probably will with a read copy in a different git service.. but I thought it was interesting because I use github for everything save a few private projects, as I imagine most do. I'm not sure what to think of this, it seems backwards and grossly incompetent, yet here we are using it almost exclusively. It might be smart to decentralize some of this with torrents, if that's possible. Even if it was the read portion of a repository, it seems like something to consider, if it hasn't been already

rms_returns 11y ago
Not just rust language, to the best of my knowledge, even packagist, the php package manager relies heavily on github for sourcing its packages. But I think they have other resources too, apart from github.
- jdminhbg 11y ago
  Ruby's bundler doesn't entirely rely on Github, but pulling from a Github repo is a supported option that many take advantage of.
- tatterdemalion 11y ago
  Rust's package manager doesn't source packages from GitHub (though it will pull packages from a git repo if you ask it to), the source for its index of packages is a git repository on GitHub. https://github.com/rust-lang/crates.io-index https://github.com/rust-lang/crates.io-index
brinker 11y ago
> The package system for the rust language actually relies on github, as many found out during outage. This is not quite correct (although close to it). Cargo doesn't rely on GitHub, but it expects that there is some publicly-accessible git repository from which it can pull the source for any crate, and most crates use GitHub. So it's not a particular choice of Cargo, but a side-effect of GitHub's popularity in the community, and the fact that Cargo does not host source code itself.
- stouset 11y ago
  If crates.io hosted the content themselves, it would just be the same problem, only with a service potentially less reliable than GitHub.
  - st3v3r 11y ago
    Not if they acted like a mirror. Put it on GitHub, Bitbucket, and crates.io
  - kbenson 11y ago
    Unless you set up a system of mirrors. There are plenty of examples[1] to draw from. 1: http://mirrors.cpan.org/ http://mirrors.cpan.org/
- agwa 11y ago
  The crates.io index is in a GitHub repository. Does Cargo fetch it directly from GitHub or from a set of redundant mirrors?
- gkoz 11y ago
  You're mixing up cargo features and the crates.io package system. Cargo does allow git dependencies but primarily you're supposed to use versioned crates.io packages, which are indeed provided by crates.io (even if they are actually hosted on S3 or whatever) not GitHub.

nickpsecurity 11y ago

That's a good point. I've been ignoring learning Git as long as I can but almost everything on my todo list heavily uses it. Or ties into it as you said. So, I'm going to have to bite the bullet and learn it. Yet, I swore Git fans told me its decentralized design avoids single points of failures where everyone has a copy and can still work when a node is down just not necessarily coordinate or sync in a straight-forward way. This situation makes me thing, either for Git or just Github, there's some gap between the ideal they described and how things work in practice. I mean, even CVS or Subversion repos on high availability systems didn't have 2 hours of downtime in my experience. When I pick up Git/Github, I think I'll implement a way to constantly pull anything from Git projects into local repos and copies. Probably non-Git copies as a backup. I used to also use append-only storage for changes in potentially buggy or malicious services. Sounds like that might be a good idea, too, to prevent some issues.

kbenson 11y ago
Git works as advertised, but when all your build processes start with a sync from the upstream master (the equivalent of "svn up") that a lot of build scripts required that to work, then they've thrown away that advantage when building. Everyone with a checked out repo should have been able to develop and commit, branch and merge locally fine though.
- nickpsecurity 11y ago
  Thanks for the clarification. This is the exact sort of thing I was wondering about.
debaserab2 11y ago
git != github
- nickpsecurity 11y ago
  Hence Git/Github in my comment. I already know there's a difference. I just don't know much more than that until I learn the two.

forrestthewoods 11y ago

And people give me shit when I argue that open source projects should include 100% of dependencies.

kbenson 11y ago
I think that's a bit crazy as well. This is a problem if your build process happens often and requires pulling external data. Ideally, you want a way to cache that external data, and a way to force invalidation of that cache. Building, at least after the first time, should not require external access. There are security reasons for this as well.
- zwetan 11y ago
  It's not, if you can not even run that first build then you actually have nothing to work on. Also, not frozen dependencies means you are at the mercy on any dependencies changes breaking your build at any time. With that, even if your first build run and go fetch those deps and can build at T1, it is not guaranteed at all that the build will work at T1+n. There is a big difference between your team working from trunk and your team being dependent on other projects trunk.
  - kbenson 11y ago
    > It's not, if you can not even run that first build then you actually have nothing to work on. Obviously you can run the first build. You wouldn't be using Github if you never got it working in the first place. To clarify, setting up the build environment may require network access, but if the process of building requires it, there are many places where it can go wrong, both operationally and security wise. > Also, not frozen dependencies means you are at the mercy on any dependencies changes breaking your build at any time. ... I agree, but that's a separate discussion and doesn't really apply here. There's nothing preventing the pulling of a specifically tagged version for builds. If someone's build process that used Git for dependencies is not doing this, whether they are using Github or some internal server is irrelevant, the same problems apply.
  - 11y ago

seiji 11y ago

if you dig far enough, you can find some dependency of a dependency of dependency that relies on GitHub. Brew/npm/build script/whatever But really, why? Is it just institutional laziness on the part of all developers? We had reliable rsync CPAN mirrors in 1995. In the early days of the Internet, companies would mutually host secondary DNS for each other to be more reliable. For some reason, we've forgotten all about reliability and disaster recovery and geographical distribution. Now the collective programmer mindset with regards to global infrastructure seems to be "lol, we're too dumb to make things work, let's just outsource everything to closed source, for-profit companies and hope for the best."

hguant 11y ago
I think a large part of this is that cloud hosting has allowed us to abstract those problems - reliability, disaster recovery, geographical distribution - away, and we don't really think of computers as computers anymore. It's a service or a platform or what have you, and the expectation is that it will always be there. I wouldn't say this is laziness, just a byproduct of changing how we view Internet architecture. We systems to take care of reliability etc because everyone has those problems. Now, those are only things you'll experience if you host your own stuff, or work for one of the big providers. (Broad assertion, I know, but I think it's mostly true)
- seiji 11y ago
  Exactly right, but over the past six years there's been a strong (and accelerating) trend among developers of "lalala we don't want to know how anything works! give us an API and go away." Most developers I've seen reject even learning about networks or DNS or operating systems or databases. Such willful ignorance boggles the mind, but they are praised because their goals are shipping half-broken things as rapidly as possible to flip upwards for those oh-so-tasty acquihire payouts. We even saw this week how overconsumption of convenience APIs can put entire companies in danger when those privately controlled convenience APIs just decide to shut down one day. Convenience of immediacy always seems to trump connivence of long term stability.
  - 11y ago

chatmasta 11y ago

If this is a problem worth solving, you can absolutely solve it. The easiest would be through the use of a caching proxy and/or load balancing system. The caching proxy system could be as simple as setting up a squid cache for apt. Multiple projects exist which do this already. The load balancing system would involve keeping a private mirror of every repository in the dependency graph, and falling back to the mirror when GitHub fails. To automate this, proxy all git requests. If github is up, let the request pass through. If no mirror exists for the repository, create one. If GitHub fails, fall back to the mirror.

yeukhon 11y ago
> The easiest would be through the use of a caching proxy and/or load balancing system. Sorring if I sound like an asshole, but before we actually use the word "easiest", can you please share with us how to do all of that. It is not as easy as you claim, to be honest. Not just some /etc/hosts hijack.
- brazzledazzle 11y ago
  They didn't say it was easy, just that it was easiest. Ostensibly comparing it to other solutions that they are aware of.
tylorr 11y ago
For the load balancing system I would assume you would also want to keep the mirrors up to date as well? So for every request if mirror exists and is out of date, update it.
- chatmasta 11y ago
  Presumably that would be the responsibility of the mirroring system once a mirror is initiated.

swalsh 11y ago

I mean a really simple solution (simple to say, maybe not to do) would be for package managers to require a "backup" repository from a different domain, than if you get a 500 error try the second remote repository. Use git for its advantages.

ugexe 11y ago
I think you mean a mirror, and many package managers use them.