That is not the only disturbing part. SSH private key by itself is not much of a threat, but bundled together with known_hosts is a recipe for disaster.
Why would people put dotfiles like ssh keys up on public github?
This kind of thing is best suited for a private repo (github is still ok, just make it private) - cause it's most likely of no use to anyone but that single user.
That is terrifying, I just logged in with three separate accounts and they worked. Obviously I logged out without fucking around with anything; why mess with somebody's professional work.
This is dangerous. But then again, is it Github's responsibility to keep these people from shooting themselves in the foot?
I'm one of the students of App Academy ( which Ned Ruggeri is co-founder of ).
The reason for that is because today one of the tasks was to create a version of HN in ou terminals. HN was blocking people due to repeated requests and thus Ned made a local version of HN for students to use.
I found about that a short time ago while crawling github with Nuuton. A lot of people don't seem to be security aware. This is one of those things that search allows you to have fun with (by fun I mean be surprised, and by with I mean to only look and not use). You should see the stuff to be found on facebook.
Thank goodness. This is the part of GitHub that has been driving me up the wall for months. Google is pretty useless in this area when you're looking for something buried within a repo.
Fantastic job, it works beautifully. Congratulations (to GitHub and to Elastic Search - I'm sure it's a big win for them too!)
It still exists at https://code.google.com/codesearch though it no longer searches everything, only those repositories hosted on googlecode.com itself.
Excellent feature. Thanks for making life a little better for a lot of us.
On a side note, I wonder how long before it'll be used to find security flaws in code (that results in an exploit) - I bet there are hundreds of hard-coded passwords, insecure defaults etc. all over the place.
Is anyone impressed else by how quickly and successfully* GitHub has been rolling out new features over the past few months? I think almost every one of their new features has in some way made my life a little easier.
Nice! impressed by speed and quality of the results + features. Definitively going to use this in the feature. Also enjoyed your blog post on how to create a search engine.
This is awesome. Searching GitHub code has been my way of learning idioms or seeing how others have solved a similar problem. This will make it much easier.
Allow us to search only within our starred repositories. The current search for starred repositories is not so great because it doesn't search the README (or code but README is more useful in finding the repo I want)
1212672153 documents
across 2866400 repositories
taking up 17 TB of disk space
over 23 elasticsearch storage nodes
fronted by 8 elasticsearch compute nodes
It took about a month to iterate over all the repositories stored on the file servers and index the source code.
This is a great enhancement. It's been a problem finding quality repos on Github as one of the key indicators for me was the "freshness" or time since last commit. The previous interface did not make this easy to evaluate but it looks like this new search has enough options to make my searching actually useful.
> To ensure better relevancy, we're being conservative in what we add to the search index. Repository forks will not be searchable unless the fork has more stars than the parent repository, for example.
This has a grandfathering problem when the maintainers switch. The new active branch of development is overshadowed by the previous branch. I've had someone takeover my project, but I still have 2 years of accumulated stars from when the project was fresh. The new development has less than 1/10 the number of stars as my branch. But I guess fixing this is kind corner case might be left for v2.
Have you considered renaming your fork? Like xyz-old? One of the things that annoys (and sometimes infuriates) me about github is identifying the fork I want to be using. A million old blog posts point to the wrong place. If that repo were replaced with a new blank repo saying "moved to here" it'd be a big help.
I did change the readme to point to the new mainline development. I still think there might be some utility in having the code as I left it around, so I didn't delete the repo.
Deleting your repo and recreating it as a fork of the new upstream may be a good idea, although it does break the links to all of the other repositories forked from yours. It really would be nice if Github handled this case better.
This is sooooooo awesome. I have needed to search my private repos many times, and descending to the command line requires too much googling for syntax for my taste.
Where is the link to the search page? When I go to github.com and it displays my dashboard, I can't find anything resembling a link to the search page. There's the command bar, but it doesn't seem to provide code search unless you click the advanced search link. I love the new features Github has developed over time, but if it's a pain to find the feature, it's not going to see a lot of use.
While this is excellent, most of my search likely just revolves around particular repositories. So while I'm addressing issues or writing comments, I can make searches like `branch:feature/foobar OrderModel` or `file:app/config.yml` and the like returning blazingly fast results.
Is GitHub working on something similar? Or am I the only one who'd want search for this purpose?
and search this string (which is in our seeds.rb):
users << User.create({name: 'Voter1', email: 'voter1@example.com', password: 'abc123', password_confirmation: 'abc123'})
I not only don't get the right result, I don't get any text in the search results area of the page, not even a nothing found message. Same thing if I do the search on my personal fork.
Being able to filter by stars is great...One other filter that would be nice is days-since-lsat-commit. I guess number of stars is rough estimate of how active a repo is, but as the years go on, there will probably be more and more projects that are basically dead, yet still have a high number of stars.
This is awesome, but I'm a little confused about the treatment of underscores. If you search for something like "secret_key" (teehee) it will return results for just 'secret' and just 'key' seemingly :-\ Not what I expect out of code search, but easy enough to fix if it's deemed a bug.
very nice. one bad setting (perhaps a default that never got overridden) is that searching for foo_bar searches for foo and bar separately, rather than treating foo_bar as an indivisible token.
i know, but in the context of code search foo_bar is almost always a single token, since the underscore is nigh-universally used in variable and function names.
https://github.com/search?p=4&q=secret_token&ref=sea...