-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening. Red Hat has started to track a subset of security flaws using Common Weakness Enumaration (CWE) IDs, this needs to be expanded to cover Fedora security bugs. We also have a secure coding guide, the Defensive Coding Guide[0], that is in the works, along with additional documentation.
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means. In the short term we expect to just be more transparent about what sort of work Red Hat is doing in this area and try to make public whatever information we can about code audits; this can be sensitive obviously. If contributors have ideas, or want to help, please join the discussion. This project is expected to evolve substantially over the next few months.
As everyone knows, security is a big deal and keeps getting more important every day. Historically Fedora has done a fantastic job with security, one of the reasons the previous SIG never really took off is because there was no need, Fedora was mostly secure and didn't need fixing. While Fedora ils still secure, there is a lot of opportunity to help. The nature of security is changing very rapidly, technologies like mobile and cloud are changing everything. Rather than sit by and let this happen, we believe Fedora should be out in front, working with the community to ensure open source remains the most secure solutions available.
But don't let what has been said so far become a limit on what can be done. I'd love to start working providing OVAL data, security bulletins, consult when questions arise and more. If you have ideas please join up and lets start working!
You can find us on Freenode IRC in #fedora-security, on our mailing list[1], and in our GIT repository[2].
We look forward to your help.
[0] https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Co... [1] https://lists.fedoraproject.org/mailman/listinfo/security [2] https://fedorahosted.org/secure-coding/
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Fedora Project - Red Hat
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On 09/07/13 14:33, Eric H. Christensen wrote:
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening. Red Hat has started to track a subset of security flaws using Common Weakness Enumaration (CWE) IDs, this needs to be expanded to cover Fedora security bugs. We also have a secure coding guide, the Defensive Coding Guide[0], that is in the works, along with additional documentation.
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means. In the short term we expect to just be more transparent about what sort of work Red Hat is doing in this area and try to make public whatever information we can about code audits; this can be sensitive obviously. If contributors have ideas, or want to help, please join the discussion. This project is expected to evolve substantially over the next few months.
As everyone knows, security is a big deal and keeps getting more important every day. Historically Fedora has done a fantastic job with security, one of the reasons the previous SIG never really took off is because there was no need, Fedora was mostly secure and didn't need fixing. While Fedora ils still secure, there is a lot of opportunity to help. The nature of security is changing very rapidly, technologies like mobile and cloud are changing everything. Rather than sit by and let this happen, we believe Fedora should be out in front, working with the community to ensure open source remains the most secure solutions available.
But don't let what has been said so far become a limit on what can be done. I'd love to start working providing OVAL data, security bulletins, consult when questions arise and more. If you have ideas please join up and lets start working!
You can find us on Freenode IRC in #fedora-security, on our mailing list[1], and in our GIT repository[2].
We look forward to your help.
[0] https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Co...
[1] https://lists.fedoraproject.org/mailman/listinfo/security
[2] https://fedorahosted.org/secure-coding/
-- Eric
-------------------------------------------------- Eric "Sparks" Christensen Fedora Project - Red Hat
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 -------------------------------------------------- -- security mailing list security@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/security
Eric,
brilliant idea, especially the secure coding education. There needs to be better guidance on problems, with real examples of code that are wrong, how one can exploit the flaw and what the correct way is to code something to prevent it from being exploitable. This should also include examples of proper logging and graceful shutdown, versus crashing.
Also, there should be examples for c/c++, python,php, ruby, or whatever else, makes everyone's boats float.
Sadly, Universities just seem to teach students basics, with no interest in doing it right. This is an appalling state of affairs for everyone in industry/business, consumers and government.
Maybe adding advice on securing services should also be covered.
Also, it would be nice to see more activity on the security list and the channel.
Great idea!
Thank you,
Tristan
On 09/07/13 14:43,, Tristan Santore wrote:
On 09/07/13 14:33, Eric H. Christensen wrote:
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening. Red Hat has started to track a subset of security flaws using Common Weakness Enumaration (CWE) IDs, this needs to be expanded to cover Fedora security bugs. We also have a secure coding guide, the Defensive Coding Guide[0], that is in the works, along with additional documentation.
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means. In the short term we expect to just be more transparent about what sort of work Red Hat is doing in this area and try to make public whatever information we can about code audits; this can be sensitive obviously. If contributors have ideas, or want to help, please join the discussion. This project is expected to evolve substantially over the next few months.
As everyone knows, security is a big deal and keeps getting more important every day. Historically Fedora has done a fantastic job with security, one of the reasons the previous SIG never really took off is because there was no need, Fedora was mostly secure and didn't need fixing. While Fedora ils still secure, there is a lot of opportunity to help. The nature of security is changing very rapidly, technologies like mobile and cloud are changing everything. Rather than sit by and let this happen, we believe Fedora should be out in front, working with the community to ensure open source remains the most secure solutions available.
But don't let what has been said so far become a limit on what can be done. I'd love to start working providing OVAL data, security bulletins, consult when questions arise and more. If you have ideas please join up and lets start working!
You can find us on Freenode IRC in #fedora-security, on our mailing list[1], and in our GIT repository[2].
We look forward to your help.
[0] https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Co...
[1] https://lists.fedoraproject.org/mailman/listinfo/security
[2] https://fedorahosted.org/secure-coding/
-- Eric
-------------------------------------------------- Eric "Sparks" Christensen Fedora Project - Red Hat
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 -------------------------------------------------- -- security mailing list security@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/security
Eric,
brilliant idea, especially the secure coding education. There needs to be better guidance on problems, with real examples of code that are wrong, how one can exploit the flaw and what the correct way is to code something to prevent it from being exploitable. This should also include examples of proper logging and graceful shutdown, versus crashing.
Also, there should be examples for c/c++, python,php, ruby, or whatever else, makes everyone's boats float.
OWASP has these on their site already. Perhaps we just need to point people in the right direction?
Sadly, Universities just seem to teach students basics, with no interest in doing it right. This is an appalling state of affairs for everyone in industry/business, consumers and government.
There is plenty of interest in doing it right. The trouble is finding people with the expertise who want and have time to teach it, and fitting it in. Generally there is a great desire to pack far too much into a 3 year undergraduate year and not enough time to teach it, and you also have to hope that the students pay attention. In my experience they tend to forget things that don't interest them right now, and programming defensively is a difficult subject to make exciting.
Maybe adding advice on securing services should also be covered.
This would be helpful. I'm not sure if we have something like this already, but if not, then I have found the idea of the Gentoo security handbook to be a good one that perhaps we could be inspired by.
Also, it would be nice to see more activity on the security list and the channel.
Great idea!
Thank you,
Tristan
Z.
brilliant idea, especially the secure coding education. There needs to be better guidance on problems, with real examples of code that are wrong, how one can exploit the flaw and what the correct way is to code something to prevent it from being exploitable. This should also include examples of proper logging and graceful shutdown, versus crashing.
Also, there should be examples for c/c++, python,php, ruby, or whatever else, makes everyone's boats float.
OWASP has these on their site already. Perhaps we just need to point people in the right direction?
OWASP has some information, they don't have everything. I generally don't see a lot of OWASP overlap in the open source universe. I'm unsure why this is.
OWASP does have a lot of really good content, nobody can deny that.
Maybe adding advice on securing services should also be covered.
This would be helpful. I'm not sure if we have something like this already, but if not, then I have found the idea of the Gentoo security handbook to be a good one that perhaps we could be inspired by.
We have a Fedora Security guide. As they say, patches welcome :)
If you're interested, please do get involved. The guide can always use content.
Hi,
It's really nice to see this, but you are basicall half way ready. We have an awesome security spin, and with few modifications we can have the ultimate weapon for this purpose. Even more, the OSSTMM guides are free, and downloadable, to have right methodology. I'd like to suggest the CBI packages, and testing [1] - where we locating common bugs - eg. same way if we can have this for searching security flaws within code - we can really win A LOT. Opinion?
IMHO,
Zoltan
[1] http://research.cs.wisc.edu/cbi/learn-more/
2013/7/9 Eric H. Christensen sparks@fedoraproject.org:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening. Red Hat has started to track a subset of security flaws using Common Weakness Enumaration (CWE) IDs, this needs to be expanded to cover Fedora security bugs. We also have a secure coding guide, the Defensive Coding Guide[0], that is in the works, along with additional documentation.
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means. In the short term we expect to just be more transparent about what sort of work Red Hat is doing in this area and try to make public whatever information we can about code audits; this can be sensitive obviously. If contributors have ideas, or want to help, please join the discussion. This project is expected to evolve substantially over the next few months.
As everyone knows, security is a big deal and keeps getting more important every day. Historically Fedora has done a fantastic job with security, one of the reasons the previous SIG never really took off is because there was no need, Fedora was mostly secure and didn't need fixing. While Fedora ils still secure, there is a lot of opportunity to help. The nature of security is changing very rapidly, technologies like mobile and cloud are changing everything. Rather than sit by and let this happen, we believe Fedora should be out in front, working with the community to ensure open source remains the most secure solutions available.
But don't let what has been said so far become a limit on what can be done. I'd love to start working providing OVAL data, security bulletins, consult when questions arise and more. If you have ideas please join up and lets start working!
You can find us on Freenode IRC in #fedora-security, on our mailing list[1], and in our GIT repository[2].
We look forward to your help.
[0] https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Co... [1] https://lists.fedoraproject.org/mailman/listinfo/security [2] https://fedorahosted.org/secure-coding/
- -- Eric
Eric "Sparks" Christensen Fedora Project - Red Hat
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux)
iQGcBAEBCgAGBQJR3BEmAAoJEB/kgVGp2CYvcJ8L/RE75c9Ww/B8cNe2pwTBD9yv 6FGfK50QFMlRC6voq2Fd5RZb8Hf+PKoxw4+ewbUYdnN8t0n+DaEvPxP69hJtgJ5N N1736+aD6OiiArKrdfBO4A9syXfMEmOPsqmye7WuXrripJc8asxu8jrh1DgEjwXk rFrI2pau3upnzkwRHDTRnMPZ925g3BE7SnHa+UD2KZQ3B29Qos3FHmaX5Kn3LXf+ 3h+zNnIVkClGr1HK56QVxgsjNWApIH/HsCspxwOpr3ULKRvWD8FJjVxEyp1EDCrc Fw0C6Di7hbzM5VNVpg4CUpquoG9QCnbNniF+IEIzcBWHr1MEKSmq64xFhfXFS0Zx w0wWmDQHmwBYxp+v9FKzuGbyb5YQAkZm7z/wRu1dfL6d39LBzG5y48zIEgmIUL6t eZX5o+lAc/3/W9sKfBbB0dmEq9m02jTIER96aD8iXNEyU8B6Yr34fnWyTiJ6BmYA Z0/ZPvq+vRJGl/F+pZkhekm8yYxA+4R8AdUnDwTt1A== =AU1I
-----END PGP SIGNATURE-----
announce mailing list announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/announce
On 09.07.2013 15:33, Eric H. Christensen wrote:
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means.
...
We look forward to your help.
starting with establishing values and metrics maybe can help - e.g. osstmm rav with scare? I tried to integrate ISECOM´s scare (Source Code Analysis Risk Evaluation) into the Fedora Security Lab, but because scare is licenced cc-by-nd as a software licence we could not. Even if it is not the newest, the Secure Programming Standards Methodology Manual SPSMM is maybe also worth a look.
http://www.isecom.org/research/osstmm.html http://www.isecom.org/research/spsmm.html http://www.isecom.org/research/scare.html
cu Joerg
starting with establishing values and metrics maybe can help - e.g. osstmm rav with scare? I tried to integrate ISECOM´s scare (Source Code Analysis Risk Evaluation) into the Fedora Security Lab, but because scare is licenced cc-by-nd as a software licence we could not. Even if it is not the newest, the Secure Programming Standards Methodology Manual SPSMM is maybe also worth a look.
http://www.isecom.org/research/osstmm.html http://www.isecom.org/research/spsmm.html http://www.isecom.org/research/scare.html
I think using whatever exists is ideal, but in this instance we can't really use those things (we may be able to build some similar things ourselves though).
This is one of the challenges we currently see in this area. There are A LOT of programs and projects and resources, but some aren't well licensed. Some are expensive, some are just plain bad. If someone knows of a good resource, be sure to speak up. The whole goal here is to keep communication flowing in the security space.
If you know of something interesting, be sure to speak up.
Thanks.
On Tue, Jul 9, 2013 at 6:33 AM, Eric H. Christensen < sparks@fedoraproject.org> wrote:
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening.
SAFECode has recently come out with a training initiative putting secure development material in the public domain: https://training.safecode.org/ - the courses come as templates that may be used/adapted to whatever needs.
There's some good content there - some generic, some Linux-specific - and more coming out soon. They're open to requests and suggestions, perhaps the Fedora SIG would be interested in participating.
--izar
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Tue, Jul 09, 2013 at 01:16:32PM -0700, Izar Tarandach wrote:
On Tue, Jul 9, 2013 at 6:33 AM, Eric H. Christensen < sparks@fedoraproject.org> wrote:
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid some of the most common mistakes. Our first steps are to document the common causes for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening.
SAFECode has recently come out with a training initiative putting secure development material in the public domain: https://training.safecode.org/ - the courses come as templates that may be used/adapted to whatever needs.
The licensing on these courses are *not* public domain but rather a non-free CC-BY-NC license.
There's some good content there - some generic, some Linux-specific - and more coming out soon. They're open to requests and suggestions, perhaps the Fedora SIG would be interested in participating.
Due to the license being non-free Fedora wouldn't be able to take part.
I think this underlines the problem that I've seen while doing research about this type of training. Most of the works available are not available under a free[0] license. I've already been working to release what I can from within Red Hat into the public arena using the CC-BY-SA license (via Fedora) and I hope to have more coming. I'd like to see more training and information become available under a similar free license.
[0] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Overview
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
I'll be the first to declare I am not very versed in the licenses and their sub-types, but the SAFECode FAQ states "All courses are free and published under a Creative Commons license and open, non-commercial usage of the content is encouraged.". Isn't that sufficient?
cheers,
--izar
On Tue, Jul 9, 2013 at 3:44 PM, Eric H. Christensen < sparks@fedoraproject.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Tue, Jul 09, 2013 at 01:16:32PM -0700, Izar Tarandach wrote:
On Tue, Jul 9, 2013 at 6:33 AM, Eric H. Christensen < sparks@fedoraproject.org> wrote:
Our secure coding mission is primarily educational. Writing software is really hard, writing secure software is even harder. There's no way any software will ever be written without bugs, but we can try to avoid
some of
the most common mistakes. Our first steps are to document the common
causes
for security vulnerabilities in software and provide information on preventing these vulnerabilities from happening.
SAFECode has recently come out with a training initiative putting secure development material in the public domain:
https://training.safecode.org/ -
the courses come as templates that may be used/adapted to whatever needs.
The licensing on these courses are *not* public domain but rather a non-free CC-BY-NC license.
There's some good content there - some generic, some Linux-specific -
and
more coming out soon. They're open to requests and suggestions, perhaps
the
Fedora SIG would be interested in participating.
Due to the license being non-free Fedora wouldn't be able to take part.
I think this underlines the problem that I've seen while doing research about this type of training. Most of the works available are not available under a free[0] license. I've already been working to release what I can from within Red Hat into the public arena using the CC-BY-SA license (via Fedora) and I hope to have more coming. I'd like to see more training and information become available under a similar free license.
[0] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Overview
- -- Eric
Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux)
iQGcBAEBCgAGBQJR3JI+AAoJEB/kgVGp2CYv2igL/RvjbiaJaD70JerlEaexZzho k+lWmj75lHgKkwD/8x80UTPil+1jwD1+gtF2n0mpi5xp1g/NVOhVSWDBsDuSe6D1 z7ZabYD0mvhGaw7/TA26OaSUIHpIR3hRrSBZnUCtiXwC4ubxIpnlUi+tqHzHg3ee YTXq0kilmrLAQioUw7c2Q1gtZLIxse5GT/l4vH2duYHAWY/eURAXbjB5Lldw4JXs nwG3wZCaU/vWsTJliUKNNcvTah0+EYIvv9dhYd3iKgXnyzUdj4PD3UOfRuu7HQ6C SAg/yyHVWfcuWIpk2y4Vbl5NqL3tlt3eDu7YjErCbgMNxpHULn7IN86iQUJSMJlu 5s8hjAvldlPAxtYBDwYiV0dZGwg3KupLQa5s5hbVfjzlauT7Vobq8YtTu320a//o hTQY5HH1jGBjNZIkeGyIANnnI+Sl/aA/2F1KmBP+6LOdHXzvErSIUIru5UtnbTGT xX+vXQNRx3bA4+nHadh6UfGKSXEexSF0gpT4dYbEkw== =5nvw -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Tue, Jul 09, 2013 at 03:50:26PM -0700, Izar Tarandach wrote:
I'll be the first to declare I am not very versed in the licenses and their sub-types, but the SAFECode FAQ states "All courses are free and published under a Creative Commons license and open, non-commercial usage of the content is encouraged.". Isn't that sufficient?
The CC-BY-NC license is not a free and open source license. The Non-Commerical part prevents people doing anything with the bits. For this to be a good license it would need to be CC-BY or CC-BY-SA.
Also, could you please subscribe to the Security mailing list[0] as I've been having to manually approve your messages.
[0] https://lists.fedoraproject.org/mailman/listinfo/security
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
The Non-Commerical part prevents people doing anything with the bits.
For this to be a good license it would need to be CC-BY or CC-BY-SA.
I see, thanks.
Also, could you please subscribe to the Security mailing list[0] as I've
been having to manually approve your messages.
Done.
--izar
On Tue, Jul 9, 2013 at 4:02 PM, Eric H. Christensen < sparks@fedoraproject.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Tue, Jul 09, 2013 at 03:50:26PM -0700, Izar Tarandach wrote:
I'll be the first to declare I am not very versed in the licenses and
their
sub-types, but the SAFECode FAQ states "All courses are free and
published
under a Creative Commons license and open, non-commercial usage of the content is encouraged.". Isn't that sufficient?
The CC-BY-NC license is not a free and open source license. The Non-Commerical part prevents people doing anything with the bits. For this to be a good license it would need to be CC-BY or CC-BY-SA.
Also, could you please subscribe to the Security mailing list[0] as I've been having to manually approve your messages.
[0] https://lists.fedoraproject.org/mailman/listinfo/security
- -- Eric
Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux)
iQGcBAEBCgAGBQJR3JZ1AAoJEB/kgVGp2CYvV68L+gJ7ILLUkmUxZDD5qpGrSLHI srIdQ+F8t1H4QkfaAgkOIHJdz9q6g+kD99ygHthynBAg7QZMVoKEdGdfwA2GTxsU 1uZtRKLroMkKxnSj5pLhY3V7yuRWfhnPLsU7Cc2JBWZEEVphxhzViP9eZmp4+rBd Wq3D3uOWpxEywASTZIJJJgKm4Y/PSShmOKQHL+8QB/cclsI/PBBPjonB9+iCMRQ0 m16pmIl2vY8fvmKrg9+aFpYfnSKV0JCCzhitl6GDdhQ5CRRBtCjAVJFYsd+ZyAMX c40CL/IQlAo6NK1aGe1jEB6NQSaecVSFoqTITI5qFb5NSQCwZqyn4kNfm+4Sqbvq kKHxWyDeVw9cZmGZMhRWRK1Mz/e+GBxpUD6VVAGuT8ZZwg4XH8RNplSleKSoOiB5 SgrgrYgjPzs1c0mJFspSS4O7RGGvSq9+naQFzBheP1wnz0RYAU/ZF64h6U7TDpYX ctVORQ7TPPQsINiIRWoDHgIaIkHHXso7kdxAHfTqYQ== =b6bd -----END PGP SIGNATURE-----
Hi,
Le 09/07/2013 09:33, Eric H. Christensen a écrit :
For code audits, we're really not sure where to start. We want to involve the community in this project, but honestly, we're not totally sure what that means. In the short term we expect to just be more transparent about what sort of work Red Hat is doing in this area and try to make public whatever information we can about code audits; this can be sensitive obviously. If contributors have ideas, or want to help, please join the discussion. This project is expected to evolve substantially over the next few months.
Has anybody reviewed how much of those claims from this talk are impacting Fedora ? http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20Desktop%20Securi...
Tim
Has anybody reviewed how much of those claims from this talk are impacting Fedora ? http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20Desktop%20Securi...
That is a monster list.
This is exactly the sort of thing we want to start looking at. Historically nobody has really paid much attention to things like this. If someone has the time, breaking that presentation apart into individual tasks would be fantastic.
Eric, do we have a plan to track items like this that probably aren't ready for bugzilla yet?
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, Jul 11, 2013 at 09:39:32AM -0400, Josh Bressers wrote:
Eric, do we have a plan to track items like this that probably aren't ready for bugzilla yet?
Not yet *but* I think that tracking generic information like that in BZ would be a good thing. We can then open bugs against packages that exhibit a certain vulnerability and block the generic ticket for tracking purposes.
We also really need to start tracking the CVEs that are opened up against Fedora packages and see what we can do to get them closed. A proven packager might be needed for that.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security Team
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Tue, Jul 09, 2013 at 09:33:29AM -0400, Eric H. Christensen wrote:
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Might it be useful to have a ticket system (presumably trac like other things in fedora) and some regular process for going over those tickets?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Tue, Sep 10, 2013 at 03:15:02PM -0400, Matthew Miller wrote:
On Tue, Jul 09, 2013 at 09:33:29AM -0400, Eric H. Christensen wrote:
The Fedora Security SIG is coming back with a new mission and new momentum. Previously the Security SIG concentrated on security responses to vulnerabilities and answered questions from the Fedora community. While this service isn't going away we will be adding two new functions: secure coding education and code audit services.
Might it be useful to have a ticket system (presumably trac like other things in fedora) and some regular process for going over those tickets?
We *do* have a Trac instance[0] already. I'm not sure how setup it is but we can certainly get that going.
[0] https://fedorahosted.org/fedora-security/
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Fedora Project
sparks@fedoraproject.org - sparks@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Wed, Sep 11, 2013 at 01:15:24PM -0400, Eric H. Christensen wrote:
Might it be useful to have a ticket system (presumably trac like other things in fedora) and some regular process for going over those tickets?
We *do* have a Trac instance[0] already.
Oh -- good for us. :)
I'm not sure how setup it is but we can certainly get that going.
Yeah, the important thing is really someone who cares about going over the tickets and prodding them forward (either through IRC meetings or a mailing list review or whatever). Note that I am not volunteering, just saying it would be nice if someone did. :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, Sep 11, 2013 at 01:22:51PM -0400, Matthew Miller wrote:
On Wed, Sep 11, 2013 at 01:15:24PM -0400, Eric H. Christensen wrote:
I'm not sure how setup it is but we can certainly get that going.
Yeah, the important thing is really someone who cares about going over the tickets and prodding them forward (either through IRC meetings or a mailing list review or whatever). Note that I am not volunteering, just saying it would be nice if someone did. :)
I don't know, that kinda sounded like volunteering to me. :)
So are we expecting questions or more formal tracking of things we want to accomplish?
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Fedora Project
sparks@fedoraproject.org - sparks@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Wed, Sep 11, 2013 at 01:27:27PM -0400, Eric H. Christensen wrote:
Yeah, the important thing is really someone who cares about going over the tickets and prodding them forward (either through IRC meetings or a mailing list review or whatever). Note that I am not volunteering, just saying it would be nice if someone did. :)
I don't know, that kinda sounded like volunteering to me. :)
Right that's why I was careful to add that note. :)
So are we expecting questions or more formal tracking of things we want to accomplish?
I think it would be nice. Otherwise, good ideas come up and then get lost in the shuffle of all the other things we are all working on in Fedora and in other day jobs.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, Sep 11, 2013 at 01:32:29PM -0400, Matthew Miller wrote:
On Wed, Sep 11, 2013 at 01:27:27PM -0400, Eric H. Christensen wrote:
So are we expecting questions or more formal tracking of things we want to accomplish?
I think it would be nice. Otherwise, good ideas come up and then get lost in the shuffle of all the other things we are all working on in Fedora and in other day jobs.
Okay, so I've modified the ticketing system to include a category for tasks and one for questions.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Fedora Project
sparks@fedoraproject.org - sparks@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
security@lists.fedoraproject.org
-
Christopher Meng -
Eric Christensen -
Izar Tarandach -
Joerg Simon -
Josh Bressers -
Matthew Miller -
Timothée Ravier -
Tristan Santore -
Zan -
Zoltan Hoppar