let's reintroduce the subject of security with this new context.

And let's start by talking about Git and GitHub.

Recall that Git and GitHub are a technology that

are used by programmers to version control

their software, which basically allows them the ability

to save code to an internet-based repository in case of some failure

locally, they have a backup place to put it, but also

keep track of all the changes they've made

and possibly go back in time in case they produce

a version of code that is broken.

GitHub has some great advantages, but it also

has the potential disadvantages because of this structure

of being able to go back in time.

So for example, imagine that what we have is an initial commit, and commit

is just GitHub parlance for a set of code

that you are sending to the internet.

So I've decided to take file A, file B, and file C in their current versions.

I've saved them using control S or command S literally on my machine,

and I want to send those versions to GitHub to be

stored permanently or semi-permanently.

You would package those up in what's called a commit

and then push that code to GitHub where it would then be visible online.

And this would be packaged as a commit.

And all the files that we view on GitHub are tracked in terms of commits.

And commits chain together.

And we've seen this idea of chaining in the past when we've

discussed linked lists, for example.

So every commit knows about the one that comes after it once

that commit is eventually pushed as well as all of the ones that preceded it.

So imagine we have an initial comment where we post some code

and then we write some more-- we make some more changes.

We perhaps update our database in such a way

where when we post or push-- excuse me-- our second commit to GitHub,

we accidentally expose the database credentials.

So perhaps someone inadvertently typed the password

for how to access the database into some Python code that would then

be used to access that database.

That's not a good thing.

And maybe somebody quickly realized it and said, you know what?

We need to get this off of GitHub.

It is a source repository.

It's available online.

And so they push a third commit to GitHub that deletes those credentials.

It stores them somewhere else that's not going to be saved on this repository.

But have we actually solved the problem?

And you can probably imagine that the answer

is no, because we have this idea of version control

where every past iteration of all of these files

is stored still on GitHub such that, if I needed to, I could go back in time.

So even though I attempted to solve the security crisis I just

created for myself by introducing a new commit that

removes the credentials from those files such that,

if I'm looking just at the most recent version of the files,

I don't see it anymore.

I still have the ability to go back in time,

so this doesn't actually solve a problem.

See, one of the interesting things about GitHub

is the model that is used for it.

At the very beginning of GitHub's existence,

it relied pretty extensively on this idea of you sign up for free,

you get a free account for GitHub, and you

have a limited number of private repositories, repositories that are not

publicly viewable or searchable, and you could pay to have more of them

if you wanted to.

But the majority of your repositories, assuming

you did not opt into a paid account, were free, which

meant anybody on the internet could search them using GitHub's search tool,

or using even a regular search engine such as Google,

could just look for something.

And if your GitHub repositories happen to match what that person searched

or specifically, if you're looking within GitHub search feature,

if a user is looking for specific lines of code,

anything in a public repository, it is available.

Now, GitHub has recently changed to a model where

there are more private repo-- or there's a higher limit

on the number of private repositories that somebody could have.

But this was part of Github's design to really encourage

developers and programmers to sort of create this open source community where

anybody could view someone else's code, and in GitHub parlance,

fork their code, which basically means to take their entire repository

or collection of files and copy it into their own GitHub repository

to perhaps make changes or suggest changes,

pushing those back into the code base with the idea being

that it would make the entire community better.

A side effect, of course, is that items get

revealed when we do so because of this public repository setup we have here.

So GitHub is great in terms of its ability for programmers

to refer to materials on the internet.

They don't have to rely on their own local machines to store code.

It allows people to work from multiple workstations,

similar to how Dropbox or Google Drive, for example,

might allow you to access files from different machines.

You don't have to be on a specific machine to access a file,

as we used to have to do before these cloud-based document storage

services existed.

And it encourages collaboration.

For example, if you and I were to collaborate on a GitHub repository,

I could push changes to that repository that you could then pull.

And we could then be working off of the same code base again.

We sort of have this central repo--

central area where we share our code with one another.

And we can each individually make changes

and incorporate one another's changes into the final products.

So we're always working off of the same base of material.

The side effect, though, again, is this material

is generally public unless you have opted into a private repository where

you have specific individuals who are logged

in with their GitHub accounts who want to share.

So is there a way to solve this problem, though, of we

accidentally expose our credentials in a public repository?

Of course, if we're in a private repository,

this might not be as alarming.

It's still probably not something you--

it should be encouraged to have credentials

for anything stored anywhere, whether public or private, on the internet.

It's a little riskier.

But is there a way to get rid of this or to prevent this problem from happening?

And fortunately, there are a number of different safeguards

specific to Git and GitHub that we can use

to prevent the accidental leakage of information, so to speak.

So for example, one way we can handle this is using a program or utility

called GitSecrets.

GitSecrets works by looking for what's called a regular expression.

And a regular expression is computer science parlance

for a particular formation of a string, so a certain number

of characters, a certain number of digit characters, maybe some punctuation

marks.

You can say, I'm looking for strings that match this idea.

And you can express this idea where this idea is all capital

letters, all lowercase letters, this many numbers, and this many punctuation

marks, and so on using this tool called a regular expression.

But GitSecrets contains a list of these regular expressions

and will warn you when you are about to make a commit, when you're

about to push code or send code to GitHub to be stored

in its online repository that you have a string that matches this pattern

that you wanted me to warn you about.

And so be sure before you commit this code

and push this code that you actually intend to send this up

to GitHub, because it may be that this matches a password string that you're

trying to avoid.

So that's an interesting tool that can be used for that.

You also want to consider limiting third party app access.

GitHub accounts are actually very common to use as other forms of login,

for example.

So there's a platform on the internet called

OAuth which allows you to use, for example, your Facebook

account or your Google account to log into other services.

Perhaps you've encountered this in your own experience working

with different services on the internet.

Instead of creating a login for site x, you could use your Facebook or Google

login, or, in many instances as well, your GitHub log in to do so.

When you do so, though, you are allowing that third party application,

someone that's not GitHub, the ability to use and access your GitHub identity

or credential.

And so you should be very careful with not only GitHub but other services

as well, thinking about whether you want that other service to have access

to your GitHub, or Facebook, or Google account information to use it even just

for authentication.

It's a good idea to try and limit how much third party app

access you're giving to other services.

Another tool is to use something called a commit hook.

Now, commit hook is just a fancy term for a short program

or set of instructions that executes when a commit is pushed to GitHub.

So for example, many of the course websites

that we use here at Harvard for CS50 are GitHub-based,

which means that when we want to change the content on the course website,

we update some HTML, or Python, or JavaScript files, we push those

to GitHub, and that triggers a commit hook where basically that commit

hook copies those files into our web server,

runs some tests on them to make sure that there's no errors in them.

For example, if we wrote some JavaScript or Python that was breaking,

it had a bug in it, we'd rather not deploy that bug so to speak.

We wouldn't want the broken version of the code

to replace the currently working website.

And so commit hook can be used to do testing as well.

And then once all the tests pass, we then

are able to activate those files on the web server

and the changes have happened.

So we're using GitHub to store the changes

that we want to make on our site, the HTML, the Python,

the JavaScript changes that we want to make.

And then we're using this commit hook, a set of instructions,

to copy them over and actually deploy those changes to the website

once we've verified that we haven't made anything break.

You can also use commit hooks, for example, to check for passwords

and have it warn you if you have perhaps leaked a credential.

And then you can undo that with a technique

that we'll see in just a moment.

Another thing that you can do when using GitHub to protect or verify

your identity is to use an SSH key.

SSH keys are a special form of a public and private key.

In this case, it's really not used for encryption, though.

It's actually used as identification.

And so this idea of digital signatures, which

you may recall from a few lectures ago, comes back into play.

Whenever I use an SSH key to push my code to GitHub, what happens

is I also digitally sign the commit when I send it up.

And so before that commit gets posted to GitHub,

GitHub verifies this by checking my public key

and verifying, using the mathematics that we've seen in the past,

that, yes, only Doug could have sent this to me

because only Doug's public key will unscramble this set of zeros and ones

that I received that only could have then been created by his private key.

These two things are reciprocal of one another.

So we can use SSH keys and digital signatures

as an identity verification scheme as well for GitHub

as we might be able to for mailing documents, or sending

documents, or something like that.

Now, imagine we have posted the credentials accidentally.

Is there a way to get rid of them?

GitHub does track our entire history.

But what if we do make a mistake?

Human beings are fallible.

And so there is a way to actually eliminate the history.

And that is using a command called Git Rebase.

So let's go back to the illustration we had a moment ago where

we have several different commits.

And I've added a fourth commit here just for purposes of illustration.