1. Install a tool for counting lines of code (recommendation: scc or tokei).
2. Choose a programming project or assignment that you implemented in the past (the larger the better, but at most two authors). Count the number of lines of code in the project and its test cases and answer the corresponding questions.
3. Choose a major application (whose source code is available) that you have used or heard of before (examples: Blender, Unreal Engine, Visual Studio Code, Firefox; do not use the example from lecture). Download its source code (if you have not used Git before, now would be a good time to install it and learn how to “clone” a repository).
4. Count the number of lines of code in the application and its test cases and answer the corresponding questions.
5. Respond to the reflection question.

Do not worry about being perfectly precise; a rough estimate is fine for the quantitative questions.

Questions

1. What is the origin of your personal project? (e.g. CS 2112 assignment, independent research, hobby project, hackathon, etc.)
2. How many lines of code were written for your project?
3. What fraction of those lines are code comments?
4. What fraction of those line correspond to tests?
5. What application did you choose to analyze?
6. How many lines of code make up that application?
7. How many of those lines are code comments or documentation? Note: some projects have a long license comment at the top of every source code file. Consider how much that might skew the results and how you could correct for it.
8. How many of those lines correspond to tests?
9. How does the proportion of documentation & test code differ between your personal projects and major applications? What do you think justifies the difference (or explains the lack of difference)? [2-3 sentences]

Fluency with version control tools like Git is essential in modern software engineering. And most CS 5150 projects will be managed within Cornell’s GitHub server. This assignment ensures that you are able to use these tools.

At a high level, your task is to clone a repository, make and test a change to its code, and commit your change.

Procedure

1. Log into Cornell’s GitHub server at https://github.coecis.cornell.edu/ using your Cornell credentials. This will establish an account for you on the server (allowing course staff to form teams and share repositories with you).
2. Install a Git client. Git support may be built into your IDE, but you will still need to be able to access Git’s command line interface in order to perform the more advanced repository manipulations that will be required in this course. You must configure your name and e-mail address (use your Cornell e-mail), and you must be able to authenticate with the Cornell GitHub server (using SSH keys, for instance). If you have never done this before, follow the instructions at https://docs.github.com/en/enterprise-server@3.3/get-started/quickstart/set-up-git (remember to perform these steps on Cornell’s Enterprise GitHub server, not on the public “github.com”).
3. Clone the “cs5150-sp22/scrambler” repository from https://github.coecis.cornell.edu/cs5150-sp22/scrambler; e.g. git clone git@github.coecis.cornell.edu:cs5150-sp22/scrambler.git.
4. Choose your preferred language (C++, Java, or Python). Compile, run, and test the version of the “scrambler” code in that language. If you have a preferred IDE (e.g. NetBeans, VS Code, Eclipse, PyCharm), try to configure it to perform these tasks via its graphical interface. If you like to work on the command line, the README offers some tips.
5. Modify the code to use your NetID (instead of the instructor’s) as the key in the scrambler application. Ensure that the application still compiles and runs. Commit your change to your Git repository; e.g. git commit -a -m "Change hard-coded key to author's NetID" (you do not need to “push” you change—you don’t have permission yet).
6. View your repository’s log (e.g. git log --name-status, or install and run gitk). Confirm that you only committed changes to the intended file(s) and that your name and e-mail address are correct. Copy the hash of your commit.
7. Run the scrambler application with an argument of “cs5150”. Copy the output.
8. Complete this Canvas quiz.

If you have trouble with any of these steps, first try diagnosing the issue with your project teammates. If the whole team is stumped, escalate to Ed Discussion. TA and instructor office hours are available as well (though we each specialize in different operating systems).

Questions

1. Which version of the Scrambler application (C++, Java, or Python) did you choose to test and modify? (You may of course play with all three versions—it is informative to compare similar code in multiple languages. But you only need to report on one of them for this assignment.)
2. What development environment (e.g. NetBeans, VS Code, Eclipse, PyCharm) did you use to explore this version of the application? Answer “Command line” if you did not use an IDE or graphical editor.
3. When you ran the application’s unit tests, how many tests were run (as reported by the test runner)?
4. What is the Git hash for the change you committed to your repository?
5. What is the output when scrambling the text “cs5150”, using your NetID as the key?

This assignment gives you practice with more advanced Git operations, including rebasing and conflict resolution. Your objective is to rewrite a branch’s history so that it is suitable for merging to the trunk branch and is compatible with a one-way merge topology.

Procedure

You will continue to work on the scrambler repository you cloned for A2. Back in that assignment, you made a commit directly on the trunk; now that you know more about branch management, let’s put that commit in its own feature branch and restore master to its original state:

1. Ensure that you have no pending modifications by running git status. Commit or discard any changes to tracked files.
2. Create a new branch (here named “a2”) capturing the current state of your repository: git checkout -b a2.
3. Set your active branch back to trunk: git checkout master.
4. Reset your local “master” branch to match its original state: git reset --hard origin/master.
5. New commits have been added to the scrambler repository since you cloned it for A2. Update your copy by running git pull.

Now your clone should match the central server again, but your custom work for A2 was not lost—it still exists in your “a2” branch. Time to start working on A3, and this time you’ll use a feature branch right away:

1. Checkout a local copy of the “assignment3” branch: git checkout assignment3. This branch represents some work-in-progress that you will be cleaning up.
2. Copy this state to a personal feature branch whose name matches your NetID: git checkout -b <netid> (your branch name must match your NetID, all lower case, in order to get credit for this assignment).
3. Compare the contents of this branch to trunk by running git log and git log master in side-by-side terminals (or gitk and gitk master for a graphical view). Note that your branch contains three commits not on master, while master contains one new commit not in your branch.

Now for the cleanup operation. You need to resolve any conflicts with the current state of trunk and recompose the new work so that each commit represents a single logical change. In the end, your branch should consist of two commits on top of the latest trunk. As you perform each step, think about how the states of your working copy, branch, and staging area (aka “index”) are changing. Here is one procedure for achieving this (you will need to learn the details of these commands yourself; the free book Pro Git is a good place to start):

1. Rebase your commit on top of master and resolve all conflicts without losing any important bug-fixes. This will likely involve commands like git rebase, git add, and git rebase --continue, as well as modifying source code in your editor. Check that you achieved what you intended using gitk.
2. Split the top commit into two: one that adds the tests, and one that improves the usage message. This can be done with git reset and git commit. Write appropriate commit messages for any new commits. Again, check your work with gitk.
   For this assignment, the changes that belong in separate commits are conveniently in separate files. But in the future, if you wanted to split up changes that were made in the same file, you would use git add -p.
3. Squash the three commits that relate to refactoring the utility functions while keeping the usage commit separate. Use git rebase -i. As always, write appropriate commit messages and check your work.
4. If you have a C++ development environment with Boost.Test, run make test to ensure that all tests pass.

Finally, submit your cleanup by pushing your feature branch to GitHub: git push -u origin <netid>. You do not need to create a pull request.

Modern software is often built on top of hundreds of dependencies, many of them brought in transitively. And with a trend towards fine-grained libraries, the web of trust underpinning your software’s reliability becomes vast. In this assignment, you will get a sense of the scale of the issue and will practice using some of the databases that assist developers and administrators in managing supply chain vulnerabilities.

1. Choose a moderately-large software application with at least a half-dozen direct dependencies (and presumably twice as many or more transitive dependencies). You may select your team project if you like (but if you do, try to identify different vulnerabilities from your teammates).
2. Identify the application’s direct dependencies. These may be configured in the build system or listed in the developer documentation. Note that web applications may list separate dependencies for their frontend and backend (you should count both), and that some projects have additional test or CI dependencies (you only need to worry about runtime dependencies).
3. Construct a reasonably-complete dependency network for the application and count the number of distinct dependencies (both direct and transitive). This will be easiest if dependencies are managed by the build tool. (Note that Bazel does not automatically import transitive dependencies, so a Bazel project's direct dependencies should cover the whole dependency network.)
4. Identify at least one security vulnerability with a CVE affecting your application’s dependency network. This may include the application’s runtime platform (e.g. JVM or Python interpreter).
   There are tools that integrate with some build systems (and artifact mirrors) to automatically identify vulnerabilities, e.g. OWASP (Java: Ant/Maven/Gradle/SBT), or you can search the National Vulnerability Database, or even download a list of all CVEs and write a script to search offline.
5. Determine the severity of the vulnerability (see the CVSS score in the NVD) and whether or not your current deployment of the application is affected.

Questions

1. What application did you choose to analyze?
2. List the direct dependencies you identified for this application.
3. How many total (direct + transitive), distinct dependencies did you identify in the application's runtime dependency network?
4. Which CVE did you identify as affecting one of your application's dependencies?
5. Which dependency was affected by this vulnerability?
6. What is the severity (e.g. CVSS 3.x score) of this vulnerability?
7. Is your current deployment of this application affected by this vulnerability? If not, does it predate the vulnerability or include a fix?