The goal of the "Free and Open Source Security Audit" (FOSSA) pilot project is to increase security of Free Software used by the European institutions. The FSFE has been following the project since the early beginning in 2014. I am concerned that if the project stays on its current course the European Institutions will spent a large part of the 1 Million Euro budget without positive impact on the security of Free Software; and the result will be a set of consultancy reports nobody will ever read. But if we work together and communicate our concerns to the responsible people in the Parliament and the Commission, there might still be a valuable outcome.
Here the blog post with more background information about it: http://k7r.eu/fossa-now-we-need-feedback-by-the-real-experts/
As written in the post: As you are the real experts, now we need your feedback. What do you think about the deliverables themselves and what about our comments so far? I am especially interested if you benefit from the recommendations https://wiki.fsfe.org/Policy/FossaRecommendations.
Best Regards, Matthias
* Matthias Kirschner mk@fsfe.org [2016-07-11 10:01:15 +0200]:
Here the blog post with more background information about it: http://k7r.eu/fossa-now-we-need-feedback-by-the-real-experts/
As written in the post: As you are the real experts, now we need your feedback. What do you think about the deliverables themselves and what about our comments so far? I am especially interested if you benefit from the recommendations https://wiki.fsfe.org/Policy/FossaRecommendations.
Mirko Böhm, who was also involved in the project from the beginning, wrote down his comments on the deliverables and encourages you to give feedback, too.
https://creative-destruction.me/2016/07/11/eu-fossa-needs-your-help-a-free-s...
Regards, Matthias
Just wanted to give a shout out for this important topic. I recognize the concerns addressed in the commentaries, and can certainly agree with them.
I find it hard to formulate concrete missteps based on the writups, even though the general spirit of the recommendations provided certainly smells. The License table was a good laugh. I afterwards briefly looked over the WP1-04 and it's like a different world. Apparently nobody does code reviews, and Debian has no security team. Also there are way to many N/A's. Dispite some discussion on the formal details of the best-practice definitions, the vibe I get is that Open Source Software should not be trusted. You know, important people have been saying that for years, and with this document as proof, perhaps FOSS is indeed shit, and we should stop using it altogether. ;)
Can we maybe croudsource some of the checkmarks like tools and practices? Perhaps we can show what FOSS is really all about.
I'll probably take a closer look in the coming days. For now I would like to encourage anyone on this list to get outraged on the results so far.
Thanks Matthias, Mirko, and all others involved.
Kind regards, Nico
I wasn't aware myself about this initiative at all to be honest. Dealing with bureaucrats is not an easy think. I read a bit the documents and the deliverable and I see this as an opportunity if I may.
A part from the report of deliverable, which is an obvious thing that they have no knowledge about free software or they maybe don't want to know, we have also, as community, the lack of supporting or providing proof of how reliable and secure is free software. those who are using free software already knows that it is safer than any other proprietary software, the massive usage by everyone (both companies and private entities) gives an answer.
But still, we as free software community are not well organized to this end.
So the opportunity I am referring to is to take this idea and create an entity that audits free software in general and releases the reports. in the end, the major tools used by everyone are not that many which makes things easier for the auditing entity.
the question is I am not really sure if this either to be FSFE or a separate organisation, I'd rather say FSFE which will bring enormous advantages to free software world and automatically to FSFE.
Not sure if i explained myself but i'd opt for the creation of such entity as I feel confident it have a massive success for free software. i feel also confident as I am part of a free software community where we develop a linux penetration testing distro. making a free software security community part of this auditing entity wouldn't be that difficult. But it is difficult to put together all other security teams (i.e. debian, fedora, centos, redhat, ubuntu, etc.).
Mine is just an idea that i throw just like that and i think it is about long term solutuion for free software auditing problem and not only when someone comes and knock the door. I'd love to hear other people's opinions.
Stefan
On Mon, Jul 11, 2016 at 10:44 PM, Nico Rikken nico.rikken@fsfe.org wrote:
Just wanted to give a shout out for this important topic. I recognize the concerns addressed in the commentaries, and can certainly agree with them.
I find it hard to formulate concrete missteps based on the writups, even though the general spirit of the recommendations provided certainly smells. The License table was a good laugh. I afterwards briefly looked over the WP1-04 and it's like a different world. Apparently nobody does code reviews, and Debian has no security team. Also there are way to many N/A's. Dispite some discussion on the formal details of the best-practice definitions, the vibe I get is that Open Source Software should not be trusted. You know, important people have been saying that for years, and with this document as proof, perhaps FOSS is indeed shit, and we should stop using it altogether. ;)
Can we maybe croudsource some of the checkmarks like tools and practices? Perhaps we can show what FOSS is really all about.
I'll probably take a closer look in the coming days. For now I would like to encourage anyone on this list to get outraged on the results so far.
Thanks Matthias, Mirko, and all others involved.
Kind regards, Nico _______________________________________________ Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
Dear Nico,
* Nico Rikken nico.rikken@fsfe.org [2016-07-11 23:44:42 +0200]:
Can we maybe croudsource some of the checkmarks like tools and practices? Perhaps we can show what FOSS is really all about.
We could. But if we do that, we should believe that this is the right approach. I am not so sure about that.
I'll probably take a closer look in the coming days. For now I would like to encourage anyone on this list to get outraged on the results so far.
Thanks for your help! Matthias
Thank you all for the feedback until now. The people in the commission are on vacation until mid August, afterwards I will send them summaries so they can improve the pilot project further. Our goal would be that they learn from the pilot project and continue with a new budget aftwarwards.
Meanwhile there are more deliverables available online: https://joinup.ec.europa.eu/community/eu-fossa/og_page/project-deliveries
I thought it might be best if I share the notes here, so if anyone also wants to have a look at them, you do not have to start at zero.
I would be especially interested in your feedback about the security tools (marked with TODO below).
# Deliverable 10: List of Tools and Methods for Communicating the Results of Code Reviews
https://joinup.ec.europa.eu/sites/default/files/ckeditor_files/files/DLV%20W...
My question when reading this are:
* How do you make sure Free Software developers actually read the results of the code audits? * How are the Free Software communities informed? * How do you restrict access, if you e.g. publish it on their public mailing list? Is there first a step to identify security people, or trusted people in Free Software projects?
# Deliverable 9: List of Requirements for Code Reviews
https://joinup.ec.europa.eu/sites/default/files/ckeditor_files/files/DLV%20W...
Page 42: Type of License: FOSS/OSS/Commercial does not make any sense. Either it is Free Software/Open Source, or not. It can be commercial and Free Software/Open Source. Suggestion to changed it to:
* 3 for Free Software/Open Source with commercial support * 0 for proprietary
For "Support available" it might make sense to differ if a company is available to give support, or if you have to go into a form to ask people.
* 3 - Yes, commercial and non-commercial * 2 - Yes, commerical * 1 - Yes, non-commercial * 0 - No
Again here it looks as if they are mainly concentrating on web tools. E.g. "Can review Java and/or PHP" how does that relate to code reviews in general? Or
Any SQL sentences used must be analysed in order to ensure that there are no vulnerabilities related to SQL Injections
What if SQL is not used in the software?
TODO: "1.1.1. Results of the Pre-selection" (p60 following). SonarQube has the highest rank but the Conclusion is in the end:
1. For Java projects: FindBugs 2. For PHP projects: RIPS 3. For Java and PHP: VCG 4. For Java and PHP: YASCA
All the tools within the scope of this study are more or less efficient. SonarQube has a lot of potential as well, since its plugins are constantly being improved. PMD does not seem to be very valuable for secure code reviews, however it is a great tool for quality code review.
How do people see that?
# Deliverable 11: Design of the Method for Performing the Code Reviews for the European Institutions
https://joinup.ec.europa.eu/sites/default/files/ckeditor_files/files/DLV%20W...
Not sure I understand what that deliverable is supposed to be about. Maybe someone else understands that.
Regards, Matthias