21–30 of 30 posts
OpenSSL and GPG — subscribe to relevant mailing lists, find something wrong with them and discuss with upstream / fix it. This could be missing tests/docs or a bug.
Adding new functionality is harder to do as an outsider, but these other areas are somewhat easier to contribute to (in general).
$bigScaryOpenSourceProjects are very picky about how contributions are made and are unfriendly to newbies. Most of your time will be spent arguing over one or two lines of code. If you haven't contributed to open source before, your best bet is to start on smaller open source projects who have forgiving maintainers.
Over the years I've communicated many security bug reports privately to project maintainers and security teams of projects such as OpenSSL, Tor, Python, MITRE. Very pleasant experiences, very kind and thankful and helpful people, so I can't really corroborate this.
I gave some hints here: http://dcid.me/notes/2013-may-12
That I hope can be useful for you.
thanks,
Are there valuable contributions I can make outside writing code?
Traditionally, documentation has always been rather lacking for the bulk of projects.
Secondly, you can fuzz FLOSS software, using something like afl-fuzz, American Fuzzy Lop. The following tutorial has some pointers to get started, and obviously software written in C is easier to get started with. If you need help with something, feel free to ask on the afl-users mailing list. You can fuzz on a CPU-heavy VM somewhere, like DigitalOcean, an Amazon spot instance, or a Google preemptible instance.
https://fuzzing-project.org/tutorials.html
In fuzzing, once you get the hang of it, you'll find that your keyboard time is the limiting factor. You'll set up a test case in 15-20 minutes, leave it fuzzing for a day, and come back to spend at least 1-2 hours working through crashes and reporting the bugs through their channels.
You may be saying "Wait I don't know anything about C," but honestly, I don't know anything about C either, and I've found hundreds of bugs with fuzzing. There are some crash dump investigation tools that give you an idea of the nature of the crash (gdb's exploitable.py) and that's usually enough to report to the maintainer. When the maintainer has a fix released, you can send an email to the oss-security mailing list detailing what you know about it. MITRE can assign a CVE on the mailing list if you describe the bug appropriately when you ask for one.
Also, check out Kernelnewbies:
$bigScaryOpenSourceProjects are very picky about how contributions are made and are unfriendly to newbies. Most of your time will be spent arguing over one or two lines of code. If you haven't contributed to open source before, your best bet is to start on smaller open source projects who have forgiving maintainers.
I've contributed to open source software, and done a little maintenance work too. The number one thing I recommend is that you email the project mailing list before you start work. Tell them that you're new, but you want to help. People are usually happy to help newcomers find an appropriate project and answer questions along the way. What I've seen going wrong in the past is where people decide that they want to con…