I am looking at instance 1105 for "Project 1" and instance 3 for "Project 2." These projects use the libraries libpng and LZ4 respectively. For each project I used the following critera to determine if it is still active: number of participants, frequency of commits and issues, and enthusiams of discussion in the community.
This project is a fork of this repo rewritten in Lua. It uses the libpng graphics library. The only participant is Dmitry Zaitsev, who was maintaining this repo from 4/13/2020 until 6/13/2020 (the dates of his initial and final commits). As stated by the last commit, this project have been moved to a new repo leaving the old one "frozen." There are currently no open pull requests or community discussion. Since there has been no progress since June of 2020 and activity has halted on the "new" repo (last commit 7/27/20), I deem this project inactive.
This project is a "tiny image viewer" for Unix based on OpenGL. It utilizes the LZ4 library for lossless compression. The only participant is Andrey Ugolnik, who has been mainting this project from 4/4/10 until 2/26/21. Commits usually occur several times a month with seemingly meaningful development updates. There are currently no open pull requests or community activity. There are numerous open issues (all assigned to Andrey, of course) and two main branches (main and development). Using the critera stated initially, I determine that this project is active.
Projects consist of the same instances in Sprint 1. I used the following criteria to determine if the project actively acceps contributions: latest commit, number of contributors, frequency of commits, and if the project is welcoming to new contributors.
As I determined this project is inactive last week, I can say without a doubt that the project does not accept new contributions. There also wouldn't be a reason for inherting this project, since the author has moved development to a new repo entirely (i.e. contribute to that one). If development had not been moved and this repo was still used, it is likely that it still would not accept contributions for the following reasons: 1. there is only one author with no signs of external issues or pull requests and 2. the commits seemed to come in rapid bursts every 2 or so months so you would have to catch the author in their cycle of development.
Since this project is active, it is likely that the author is accepting of contributions. Although there have not been any outside issues or pull requests on the repo to date, it is possible that Andrey would merge meaningful changes/additions. I determine this by examing the frequency of commits in the past and the dwindling development in the present. Although this is a long term project maintained by a single developer, it is possible his progress is slowing because of interest or lack of ideas for further improvements. Using this logic and since this repo has commits in the last month or so, I would say the chances of getting a legitimate pull request merged is high.
Still looking at same two projects. I used the information provided for instance 1105 and instance 3 to determine if the fix has been implemented in the projects or not. This was done by looking at the project files and comparing the fixed ones.
The vulnerability for this project stemmed from the libpng library not properly checking the length of chunks against the users limit. The vulnerability is fixed by modifying two files: pngpread.c and pngrutil.c (found here. The first vulnerable file in the project, pngpread, does not contain the proper fix. The second file, pngrutil, also does not contain the proper fix. Therefore, I conclude this project still contains the libpng vulnerability mentioned previously.
The vulnerability for this project stems from the lz4 compression library containing a heap-based buffer overflow which affect certain applications. Thankfully, only a few uncommon usages are at risk, but it's a problem to be addressed (and has!). The fix is in file lz4.c and simply changes a '<' to a '<='. After checking this file in the project source, I have determined that it does not implement the fix and thus currently contains the overvlow mentioned before.
Now I will produce patches for both of the projects and note any issues. These fixes can be found in the previous sprint.
Since the original repo is completely obsolete, I decidede to take a look at the current one I noted in earlier sprints. (Un)Luckily, this repo contains the same vulnerabilities as the old one. I began by forking the new repo and making the changes noted in Sprint 3. Sadly, it would seem I am unable to freely create pull requests for this project due to permissions. Furthermore, I do not see how to contact the rpo owner and request him to pull these changes. Anyhow, here is my forked repo with the fix.
Again, I noticed the ability to create pull requests was disabled. However, this time I was at least able to make an issue. First, I forked and cloned the repo and fixed the vulnerability (one symbol :D). Then, I proceeded to make the issue and wait patiently.
Now I need to create pull requests for the patches I created and note the links to these pull requests.
For this project both the old and currents repos do not allow randoms to create new pull requests. Furthermore, I am not able to submit issues since they are not setup for these bitbucket projects. Finally, I do not see any way to contact these developers using their bitbucket account names (no clickable profiles, it seems) without trying to OSINT my way to their email. Therefore, I am unable to create a pull request for the patch I have made (as I noted in the previous sprint).
Again, the ability to create pull requests on this project is disabled. I did submit an issue, which the lead developer reponded to and promptly addressed (again, repeating myself from Sprint 4).
For the final sprint, I need to respond to any questions to get the patch accepted and note if a response was needed.
Since I was unable to create a PR for this project, a response is not needed.
For this project, I provided details and necessary documentation in my PR to get it accepted. Afterwards, the issue was resolved and further discourse was not required.