"since github identities are random, I expect the pull request to
be a signed tag, so that I can verify the identity of the person in
"github throws away all the relevant information, like having even a
valid email address for the person asking me to pull."
So, you think he violated a Code of Conduct that did not exist at the time, in the course of explaining why he was not a user of the service (so that any Code of Conduct for that service would not apply to him even if it existed.)
I guess it's worth noting here that you can sign your commits with GPG: https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work
For that reason, I jokingly created `git-upstage`, which streamlines the process of abusing commit edits and plagiarizing code! It squashes a branch, backdates it 5 minutes, and claims you wrote it.
Edit: Looks like my last commit left the important stuff commented out and can't fix it at the moment. Ah well, you're going to use the tool to rip it off anyway ;-)
I was told of severe disciplinary actions for accusations that were ridiculous when students would not confess, and an administration that stood behind the decisions of students who judged other students more on their opinions than anything else. One student, for example, was apparently expelled for an instance of claimed cheating that would have involved him running back and forth on campus at the speed of a competitive athlete. He quietly returned a short time later, and was also admitted here as a graduate student; there were rumors of legal threats and a settlement.
At least when I was hearing more about such things, essentially, Caltech placed tremendous trust in students who were well-liked by particular people, and treated those who were disliked very poorly.
Because Caltech faculty (and, for undergraduate student exams, grad students) have better things to do with their time than proctor exams (and, perhaps more to the point, because Caltech wants to attract faculty and grad students that feel that they have better uses for their time that baby-sitting exams.)
And, frankly, like many aspects of the trust extended to Caltech students, its a recruitment policy -- Caltech is an extremely selective, extremely small school that is competing with other elite institutions to attract the best students.
It's just nicer to live that way.
A friend of mine at UT had his room sacked the first week.
> Honor codes and not proctoring exams (rather, the students doing it themselves) are a fairly common feature of engineering colleges, it isn't really something that contributes to Caltech standing out.
I'm not saying Caltech is unique in doing that, I'm saying that in the universe Caltech operates in it would conflict with their recruiting interests -- both for faculty and students -- to operate in a different way.
Most of the exams were take-home anyway, and included instructions giving a time limit and what reference material was allowed to be used.
I don't know what Caltech is like today. I attended in 70's, and the honor system was considered sacred by the students. If there were cheaters, they never bragged about it, and I don't know of any. I know one who fell asleep during his takehome exam, woke up and finished it, and so exceeded the time limit. He noted this on the exam. The professor replied back that he was very sorry and was forced to give him an F. The student repeated the (required) class next year.
The number of students who did poorly on exams argues that cheating was not widespread.
If the culture has changed in the intervening years, that makes me very sad.
Wow, way to prize process over people. Why not let the student drop the class and just re-take the test next time around?
Is Caltech designed to teach science, or train paper-pushers?
But also consider that the midterm and the final were the entire grade. No credit was given for homework, showing up for class, etc. The rules about the exams were pretty clear.
However, if you had a borderline exam grade, but had done the homework diligently, the prof would use that as a tie breaker.
His fellow students thought the F was a bit harsh, but he conceded that it was fair and took his lumps with equanimity. I quite admired him for it. In the end, it didn't hurt him because he graduated and went on to a very successful career.
I (briefly) attended in the early 1990s, and it was the same.
Individual students certainly can have this integrity, but the demographic as a whole is demonstrably susceptible to cheating.
It also offends basic scientific process, in that it suggests that you don't need to bother with trying to make sure your results are robust; instead it relies on someone's word. Why bother having exams, then? Just ask "Do you think you understand the course material properly"?
Think of it like running a marathon. Is there any satisfaction from thinking "I honestly believe I can complete a marathon!" ? I don't think so, but there's a heluva lot from actually completing one. Same for a tough degree program.
Regarding marathons, some people do cheat them - they're more interested in the social rewards than the personal growth. Some people flat-out lie about doing them at all. Different folks have different motivations.
Certainly demonstrably true of a significant portion of the demographic of "college students".
Caltech would probably argue that Caltech students are not a representative sample of college students, and that generalization from the more general class to the more specific here is a textbook example of the fallacy of division.
Even if we all agree that Caltech students are not representative of college students in general, it doesn't automatically follow that there is no significant degree of cheating.
No, its not. Rejecting the validity of an argument for p is not the same as making an argument for not-p.
Not being representative of a population doesn't give any information about the makeup of the subsample, unless you have more information to add.
No, its not, which is why you had to present a "quote" that isn't to advance that story.
I presented how they would reject an argument from the general population, not positive argument for the absence of cheating at Caltech.
Yes, if you strip away the context of the literal words you said, you're correct. But in context, you're not.
I also suspect that a university with strong anti-cheating measures is expecting students to cheat, and students will naturally fulfill that expectation.
I think the latter is definitely true, the former is probably true, and perhaps more importantly, Caltech's admissions process selects for people who are likely to view a system where rules are enforced primarily by monitoring as a challenge, making the alternative to trust being an arms race that consumes resources on both sides that could be more productively employed.
Edit: An example: the US homicide rate has fallen in recent years. That's good news. But the US still has a serious problem with homicide, as its homicide rate is an outlier at 4-5 times that of all other first-world nations. Americans are getting less murderous, but murder is still a serious problem there.
Much of my education is self taught, and hour-for-hour knowledge-wise I believe my time could be better spent in self-directed learning, but that degree does have value and people who cheat make it worth less to employers and myself. I think it makes sense to try and catch people who abuse that.
I definitely agree with what you're saying, especially in startups it really isn't that relevant (part of why I like the startup community so much). But I do spend a lot of time outside startups as well, and that glass ceiling is definitely present in large companies and academia (especially academia).
"I discovered that if you rip the tags out of a library book, you can just walk out with it and the alarm won't go off!"
For some people, that would be a significant "a-ha!" moment. That doesn't mean they should go around stealing library books.
I recently went on a tour of my former university's new library building.
One thing that surprised me was that all the upper floors are set about six feet back from the exterior windows ( leaving an internal building-height vertical gap all the way around, so you can look over the railing down to the ground floor ).
When I enquired about this, the response was that it was to prevent the throw-book-out-of-window-and-collect-it-later trick that was apparently common with the old building!
None of this is a large effect when a single person does it, but the same is true of taking notes into exams. Would you do that?
Zooming out slightly: if you think cheating doesn't hurt anyone, why do you think there are rules against it?
Cheating is (b), driving is (a). (You seem to be arguing that driving is (b) - I disagree, but it's beside the point.) Capitalism mostly tries to encourage (c). We put some selfishness to work, yes; but we harness the selfishness of Henry Ford, and we punish the selfishness of Bernie Madoff.
> I never said my actions were capitalistic at all.
I got that impression from one of your deleted comments. Perhaps it wasn't intentional.
> If that makes me into an asshole and the world into a shithole, so be it.
That's not a "so be it" outcome, that's an "oh crap, let's try to avoid that" outcome. As a society, we try to avoid that by punishing (a). You can do your part by not doing (a) even if you think you can get away with it.
It's bedtime, so I'm tapping out now.
That is a pity. I have already prepared a README.md claiming that I have created the internet, but then I failed while trying to backdate it to 1969 (PDT). I was this close to becoming very rich and very evil. Oh well.
EDIT: This gets even more disturbing when you realize that GitHub is a site many people list on their resumes and if this association applies from their user page too this could get very bad.
The criteria not fulfilled for this one are that you have to have interacted with the repository on Github in some way. Any one of these criteria would suffice: you're a "collaborator" on the repository, you're a "member" of the organization the owns the repository, you have forked or starred the repository, you have opened a pull request or issue in the repository.
For example, consider a fork. If you pull some commits from the original and then push them to your fork then that would look just like this.
The only thing I can think of is that it may be possible to track commits if everyone would sign them as they were created, but that would require all users to change, so I don't see how that can happen.
It would be trivial for them to shell out to `git verify-commit <commit>` in order to verify that the claimed originator has signed his commits with a key tracked by github (by email address, which can belong to only one github user).
If you push a commit made by you, Github can tag that as "trusted" (since you, the GH user, are vouching for your own commits). Then anyone who pulls them into their repo (even offline) and pushes it to their GH account would still have those commits tagged, since GH could match the hash with the ones it already knew about.
For the most part, this would solve the problem, since people usually upload the commits to their own GH fork and then issue a PR.
It already does.
man 1 git-verify-commit
man 1 git-verify-tag
This is a Github problem.
Why do you think that seeing a username on Github is any different that seeing an unverified email in any other hosted Git repo? You need to git-verify in both cases. It is your own misunderstanding that seeing a username on Github implies it's verified. It's not. Just like looking at email is not on Git.
> It is your own misunderstanding that seeing a username on Github implies it's verified.
I'm not confused. Others appear to be. My comment was in reply to a poster who seemed to be indicating that git lacked the ability to verify signed commits and tags.
I was informing him that git does indeed have that ability, and that its absence from GitHub is a GitHub problem, not a git problem.
You've leapt to an entirely unsupportable conclusion about my familiarity with git and commit/tag signing. :)
My informal, entirely unscientific survey of folks who use GitHub leads me to believe that they are -on average- less proficient with git, git concepts, and the notion of cryptographic signing than the average person who uses the git CLI.
This  appears to be the closest that the GH documentation gets to saying "anyone can commit with anyone else's email address". Adding support and graphics for tag and commit signature verification -along with support for tag/commit signing in the GitHub client- might be a nice thing to do for users who are not so familiar with git.
> You need to git-verify [to verify unverified email addresses attached to git commits] in both cases.
git-verify-* is actually only useful on signed commits/tags. If a commit/tag hasn't been signed, it exits with a non-zero exit code and does nothing else. Given that the vast majority of commits one will run into will not be signed, git-verify-* typically won't help you to determine the validity of the authorship of a commit/tag. Reading the -very short- man page of either command would have caused you to understand this. :)
1. The content of the PR will stay the same. In this case, the only thing changing is the number of commits. Unless you expect someone to blame (or praise you) for the number of commits?
2. Git will track the Committer and Author separately.
I think it's something people take too lightly.
Yes, there often is. And I do enforce it on the original pull request.
(which you never had in the first place, if you don't sign your commits)
The problem is that GIT often changes commit details. If you, for example, rebase or cherry-pick a commit, the identity changes - as the commit includes a reference to the parent commit(s). This means that once you do any of those (standard) operations, the signature becomes invalid.
Signing only makes sense on a tag level or in repositories that keep all commits and never change them (e.g. by explicitly merging and adding merge commits).
There are systems that preserve commit integrity during all of those operations, e.g. DARCS.
For example you could cherry-pick all commits except security fixes and create a malicious version of the software that has all commits still signed by the original author.
DARCS, just as git, has tags for that. A tag depends on all previous patches, so a signed tag guarantees just the same as a signed git tag does.
In that regard, git is strictly less powerful.
Currently the event in question is on page 3 so you can use:
It i will roll to further pages as new events come in.
Github comment with formatted json event output:
The login of the push is identified of course as the owner of the repo 'amoffat'
I think github should allow me as a user to confirm contributions made out of the system, at least the first time per repo.
Thankfully the Linux kernel project accepts only signed commits.
This is false, FWIW.
some years ago I reported this issue on gitorious, which yielded an HTTP500 when the repository contained a signed commit:
https://issues.gitorious.org/issues/193 (it's now down, but hopefully it'll reappear on archive.org)
and it'll prevent Launchpad from automatically mirroring git repositories (which is paramount to be able to automatically update PPA with recipes)
(Or at least they won't provide those push logs to the Apache Software Foundation, which is how I know this.)
This also has been an issue with Git for a long time. In any repository, you can see the email of the person who committed it, and it can be spoofed, because there are no checks. So while here we see it linked to Linus' account, the problem with plausible identity theft has always been a part of Git.
There are ways to solve it. Git can just put "<unsigned>" next to non PGP commits. Github can also put "<unverified>" when commits are made outside of Github realm (not using their keys of https auth), or are unsigned.
Just be careful while merging pull requests, which one has to anyway. And because one has to, these issues never seem to get a fix.
Oddly enough my comment itself was altered to be a mindless obnoxious comment! (does github use git commits to track the comments themselves?)
git commit -m "message" --author=<author>
It's actually a really useful feature when you're migrating a project from a different SCM system to git.
If you know it, everything about email and its protocols would make you assume the exact opposite.
Now PGP signatures on the other hand … but hey, nobody wants those, right?! Far too complicated! /rant
If github was linking to user's profile based on first/last name rather than email the issue would be the exact same.
And we default to not requiring such authentication because the means we have are either completely useless (i.e. passwords) or so onerous (I always have to Google when I setup cryptographic credentials on anything, and we expect lay users to do this?) that they ruin adoption rates for software and services.
State-of-the-art secure credentialing should be as easy as passwords. Easier, even. Yet they're currently as "easy" as configuring Apache.
My point is that fixing this issue is out-of-scope for a DVCS. It could, however, be improved a bit.
The tech told me that the current behavior was by design, and then pretty much said I didn't know how git worked and didn't understand Github's team/sharing/trust philosophy. I was pretty disappointed by their response, all told.
What to do about this though... that's a good question. Perhaps just not linking profiles when pushed in this way and/or labeling them "unverified" would be sufficient. GPG signing would be nice, but would likely annoy some users.
In Git, it's clear that there's no authentication, a user is just a tuple of strings, but on Github the same doesn't apply, a user is actually a well defined entity which is secured by one or even two factors of authentication, so the expectations are different.
Of course this doesn't actually give you access to the person's account, but UX wise, it's incredibly misleading for someone to click a commit in my repository by "torvalds" and have it actually go to his profile. My issue is very much with the social implications of this as opposed to it being an actual security issue (see: signed commits).
There should be some indication at the very least that a commit is not signed.
Isn't it the general problem that each user is authenticated as the "git" user and the rest (all the git commands) is just "user.name" and "user.email" fields in prefs?
Edit: It is important to note that this would not replace git authorship info as it is very possible that you pushed something that someone else committed. It would allow you to have a UI trail to who pushed it which could help if you theorize that someone is impersonating someone else.
First of all already of course there is the problem that putting your email on the internet is asking for spam.
But a bigger problem is, if I'm on a machine that doesn't happen to have those variables configered, and I push something to github, even if I use my github username and password then, it does not show me as author. Very annoying.
EDIT: I don't like git itself's email dependency either. But at least github could have done something with the fact that you login with a username... :)
Add these addresses to your email addresses list on the settings page of your github account if you want your github avatar, etc., to be shown against commits using these addresses.
Perhaps some mechanism is called for here for approving tying back to your user on new repositories or making any repository not owned by you or your organizations require an explicit opt-in to tie back to your profile.
Edit: This is kind of the equivalent of spoofing the From address in an email.
Makes it so that when you "git pull" it automatically checks a digital with a certain public key and refuses to apply the patch unless it has a valid signature.
The GPG key is designed for a email based collaboration flow - that Linus uses. But most of us use Github or Bitbucket's UI to collaborate.
Github/Bitbucket should use this key in their UI as well - to show verified users.
I have since switched to using my YubiKey and GPG for SSH authentication on pretty much everything, as well as using it to sign my tags in my public git repositories. I don't think I would want to go back to moving keys between devices or setting up unique keys on each device now that I've got my YubiKey set up. Worth the investment, in my opinion.
Remember, it's not that hard to host your own git repo. There's no need to use GitHub.
Git provides mechanisms to sign both commits and tags, and to verify those signatures. GitHub fails to make use of those mechanisms.