I have a repo that was public initially, made private later, and turned public again only a while ago.
My issue is, I had about 250 views with only 2 unique viewers before it turned private (I don't know how THAT's possible).
Once I had made it public, I checked the traffic and had 727 views with still only 2 unique viewers, and the graph even shows a view count when the repo went private for a few days.
How did the view count jump so high and how did my repo have views even when it was private?
Any form of help is appreciated. Thanks in advance.
Yes, the numbers include everyone's views including repository owners and contributors. There's no way to filter this information at the moment but we can definitely add that as a feature request for the team to consider. Your own views are counted on repository traffic graphs, and there is no way to filter out your own page views of those of other repository contributors
I would like to review my GitHub activities for the past 12 months. On my public profile I can see as much as one month only. I can go to an individual repository and review all the commits for any period of time, of course, but this becomes unfeasible when I have to interleave data from dozens of repositories.
Is there an advanced query or page that allows me to see or download this aggregated data?
Looks like GitHub does not allow viewing contribution data for more than a Month by default but if you use it's apis you can build something that can keep track of your contribution for how ever long you want it to.
Here's where GitHub talks about contribution.
https://help.github.com/articles/viewing-contributions-on-your-profile-page/
I need an index-page, that shows links to all gitHub repositories.
I think that is the reason, why many repos are not found by crawlers like the Waybackmachine
I think if there was such a site with a high ranking, they would start crawling it
The developer site sais, there is an Api for getting all repos
Warning: GitHub hosts a huge number of repositories. You'll have to take this into account when designing your index.
I can think of a few options:
The legacy GitHub search API. You'll have to cope with the API rate limit though.
This StackOverflow answer could be a good start to get a rough grasp of the number of repos per language.
Leveraging the GitHub Archive project which records the public GitHub timeline. (Note: As the project only exposes events back from February 12, 2011, you won't get any data about repositories showing no activity since this date.)
First
No I am not asking you to teach me hacking, I am just curious about this file and its content.
My journey
When I dived into the new HTML5 Boilerplate I came accross the humans.txt. I googled for it and I came at this site http://humanstxt.org/.
Immediately my attention went to this picture:
Do I read this correctly? Hackers.txt?
So I resumed my journey in google and stopped at this articles
When I started reading this I had the feeling that its about the difference between Hackers and Crackers. Later I got the feeling that I'm might be wrong and that this place is that this hackers.txt file is a sort of guestbook for hackers?
Also other examples about hackers.txt files I found here
Some files contain code, others have just hurtfull information.
Now I'm realy confused, guestbook, hack tutorials or just history?
Question
What is the use of this hackers.txt file?
The way I see things:
robots.txt contains information and instructions for robots (so it should be read/used by web crawlers, spiders and other kind of bots)
humans.txt contains useful information to be consumed by humans, according to http://humanstxt.org/
hackers.txt should be targeted towards hackers, so it should contain any information the site owner might want to transmit to a hacker, as Ze'ev pointed out. I don't think this should be a place for hackers to write anything, but rather to get information from the site owner (perhaps on how to report vulnerabilities, as others suggested).
Commonly known as Eduardo Vela, Eduardo A. Vela Nava (or sirdarckcat on Github and Twitter) has been a Security Engineer at Google since 2010. (He currently has the role of Product Security Response Team Lead).
As other security experts before him, he pondered the issue of effectively communicating the details of a site's vulnerability reward program to white hat hackers/pen-testers.
One specific such person is Chema Alonso (also on Twitter).
He is well-known enough to warrant a Spanish Wikipedia entry
Between 2005 and 2011 Alonso was awarded the Microsoft Most Valuable Professional Award for Enterprise Security 6 years in a row. That should tell you something about his "skillz".
On February 3rd 2011 Alonso wrote about his frustrations regarding the topic of communication between the administrators and/or developers of a site and hackers.
He proposes a similar initiative as humans.txt but for hackers. As he mentions this hackers.txt initiative in his blog-post.
In April 2011 The humanstxt.org website got a new design which includes the image which mentions the hackers.txt file.
At this point, I must sadly submit to conjecture, but... consider:
The team behind humans.txt are all from Spain (mostly Barcelona)
At this point Alonso is already quite well known in the Spanish developer community
Would it be such a far stretch to imagine that they got to know of each other's efforts?
On May 14th 2014 Vela, already working at Google, commented on a blog-post by Alonso. It is most likely that they had further contact in a professional setting. Whether or not thay extively shared their idea's regarding anything related to hackers.txt is unknown.
On July 6th 2017 Vela posted a question to this extent on twitter:
How about we create a /hackers.txt that says whether something is in scope or not of a vulnerability reward program and where to report it?
Subsequently, an empty git repository was created for hackerstxt.org on github
and an email thread was opened at Google Groups to discuss this idea further.
On August 13 2017, Edwin Foudil (or EdOverflow on Github and Twitter) created a git repository for security.txt on Github and responded to the mailing list:
I have published a similar project to the one being discussed in this group (https://github.com/EdOverflow/security-txt) and would love to get some of your feedback and ideas.
The project is the equivalent of robots.txt, but for defining a security policy. Companies can add a security.txt to their website and define clear guidelines of what security researchers must do when they discover a security issue. security.txt also allows bug bounty programs to add their scope there. security.txt uses a similar syntax to robots.txt, which should make it easier for machines to parse.
He was, in part, inspired by an open-source project he was working on at the time called GratiPay. GratiPay had a SECURITY.txt file since 2013.
His inspiration also drew from the SECURITY.md files that more and more open-source projects were adding to their repositories.
On September 10th 2017, Foudil submitted a first draft for security.txt to the Internet Engineering Task Force.
On September 14th 2017 Alonso wrote a blog post with the title (translated from Spanish) "Security.TXT an IETF draft for my Hackers.TXT".
Beyond the title, Alonso does not allude to the fact that his 2011 idea was the origin of the draft but he does state his approval of the effort.
On February 3rd 2018, the mail group was informed to concede to security.txt and Vela tweeted that Google had already implemented one.
Further information
Details and a nifty tool to generate your own security.txt can be found at
https://securitytxt.org/
Adoptation
Even though the RFC is still in draft, the standard is already being adopted quite well by major players on the web.
Besides the security.txt at Google, there is also one on the website of:
1password
BBC
bit.ly - http://bit.ly/security.txt (can't be linked because StackOverflow blacklist the use of common link shorteners in posts)
CERT NZ
DailyMotion
Dropbox
Facebook
Github
haveibeenpwned
NodeJs
NPM
Open SSL
Shopify
(Feel free to add more from well-known sites, if you find 'm)
As with humans.txt, there also seems to be a hackers.txt site at http://www.hackerstxt.org/. I'm not sure if someone has set the site up as a joke or not, but it links to a blog post on someone's Blogger site.
The post rambles on a bit (I put it through Google Translate) about the poster's history as a 'hacker'. Anyway, towards the end the writer says:
therefore believe we should promote an initiative type hackers.txt , in which managers leave us a message to potential "aliens who are good" that makes it clear they will do managers receive a report of a vulnerability in your site. I've been circling this , the truth is that it is difficult to finish shaping, because perhaps some "alien who is not so good" , type Brainiac , take a free hand to brush a site, or the "good board administrator" , decide to change your mind and Liem, but I think we should be able to do something, I dunno, maybe having Jon Jonz , or perhaps thinking about how to write that file hackers.txt . How do you see it? Greetings Evil!
So I assume that the poster wants to start a sort of hackers.txt standard in the vein of humans.txt, but hasn't finished it off, or hasn't gotten it into the English speaking world.
Digging around, the Blogger site seems to be owned by a guy called Chema Alonso, who must be fairly reputable in the world of Spanish programmers as he has about 35k Twitter followers (https://twitter.com/chemaalonso). He seems to work for a company called ElevenPaths (http://elevenpaths.com/), which says that it's driving "radical innovation in security product development". A quick Whois check shows that the hackerstxt.org domain is registered by someone in Madrid, so I would assume it's Alonso.
The .txt file over at http://www.textfiles.com/news/hackers.txt, which has been refered to by some of the other answers in this thread, doesn't seem to have anything to do with the hackers.txt reference over at http://humanstxt.org/, and neither do most other search results for 'hackers.txt'.
It's possibly a joke, but If humans.txt is for humans to read then maybe hackers.txt is a warning for hackers.
Like the notice you get when you SSH into some more public terminals. "You are being watched... we will get you if you do anything bad..." That sort of thing.
If a hacker did compromise the site, the might notice the file, read it, realise you mean business and be scared away!
Interesting idea.
As this question is somewhat open, I think you are also expecting some assumptions, I write here (not in a comment) my opinion, but if it should be there, I'm sorry.
I think that the idea lying behind humans.txt (which I heard of before) is to make a new habit, new style or something like that. In fact, you can put a contact page, where all these data from humans.txt can be put. I think that hackers.txt could be also something like new style.
I suppose that hackers.txt was much earlier, maybe for 20 years, when www servers and popular web knowledge was poor, when using localhost Apache+PHP+MySQL was making you "a hacker", and if someone could access the file other than index.html (and linked pages from this), reading hackers.txt was some kind of prize, or maybe some kind of filter to show some information to "those who behold" (like this one perhaps).
I think hackers.txt should contain notes on how the site owner would like for data to be used... E.g. "I don't mind if you scrape the movie listings, but please don't hot link out images in your app"
When I check-in code, I sometime write very long, detailed checkin notes, other times I write very short ones (or no note at all). The longer notes tend to include information about why the change was made (business reasons, customer interactions, etc). However, I'm not sure if check-in notes are the right place for such detail. Most check-in notes I've seen tend to be short and simply reference a bug.
What is an appropriate level of detail for check-in notes?
Whatever your manager or company documentation tells you ;)
That being said, shorter is better. It's not the correct tool for lengthy documentation - your bug/feature tracking software is built for this and in most cases, can integrate with your source control.
Just enough so, when following the log few weeks later to have an idea about what hapenned.
I use these logs to check what has been done in the last day (or days) in the project I'm leading.
Shorter messages doesn't necessary mean better. Nor longer messages. Just keep in mind the goal of those comments: to give an overview of the activity on versioning system.
The right answer, I've found, is dependent on the needs of your organization. It sounds fuzzy, but the primary reason to provide detail for a code check-in is for context and understanding if that check-in needs to be reviewed or revisited. It might be incredibly verbose, or it may be remarkably simple.
In one company, our code check-ins would reference #+ticket-number. This mapped our SVN commits against a Trac ticket number, which held all of our details about a given issue or feature we were implementing. We referenced everything through Trac, so keeping our details in that form worked best for us.
For you, it depends on how you and your team work. I would base what info you keep in your check-ins on the need for the data, how often its referenced, and what happens if you lose context (i.e., have no idea why a change was implemented.)
Another consideration may be accessing those notes outside your code repository, which may not be the most effective mechanism for storing that information. Nonetheless, I find it's personal preference.
In my version-control experience, I tend to curse the ones that left no note at all, or a note that takes 5 minutes to dig through.
If you use your version control system to browse the history of a file to find a specific change, it's best to include a short comment on the why, and the what. The how is to go in the source code documentation.
Whenever I write a comment or a commit log message I ask myself "what will the next guy need to know? what are they likely to ask me about?"
Answering a question seems to be the easy way to keep comments brief and useful. It also avoids anti-documentation (rephrasing code, often in unintentionally ironic ways) or re-phrasing the metadata the vcs will be tracking anyway (added foo.java, tuesday change, new tag "bar-1-1-4")