security [ARCHIVED] January 2014

security@lists.fedoraproject.org

9 participants
5 discussions

by Till Maas

Hi, I recently noticed that several packages in Fedora create RSA keys with inappropriate key sizes: dnssec-trigger creates RSA 1536 keys with certificate that is valid for 20 years: https://bugzilla.redhat.com/show_bug.cgi?id=1045689 dropbear-keygen creates by default RSA 1024 keys: https://bugzilla.redhat.com/show_bug.cgi?id=1039311 Some other observations: ssh-keygen on F19 creates RSA 2048 keys by default ENISA recommends to at least RSA 3072 keys: http://www.enisa.europa.eu/activities/identity-and-trust/library/delivera... If e.g. AES-256 is used. RSA 15360 is recommended for long-term usage. Therefore I would like to propose a packaging guideline about which minimum key size software in Fedora should generate by default. It seems to me that requiring RSA 3072 key by default in Fedora is a good initial compromise. I did not notice RSA keys with more than 4096 bits regularly, therefore I am not sure whether using RSA 15360 keys by default is a good idea. What is your opinion? Regards Till

10 years

6
12
0 / 0

Introduction

by Joerg Stephan

Hello to the list, i would like to contribute to the security response team. If any help is needed or any ideas ongoing please point to an good starting point. My name is Jörg Stephan, i am an 34 years old system administrator from germany. I basically work on maintaining some hundreds of debian/ubuntu based servers and a handful of centos machines. Besides my administrator work i am also responsible for IT security questions. Cheers Jörg

10 years, 2 months

2
3
0 / 0

Fwd: Security update process without CVEs

by Dan Scott

Per the recent thread on fedora-devel [1], I've pushed perl-MARC-Record-1.02 [2] following upstream's security release before they had a CVE in hand. Now upstream has a CVE (CVE-2014-1626), so if you want to create a security tracking bug and link up bodhi etc to follow the security process [3], please go ahead! Thanks, Dan 1. https://lists.fedoraproject.org/pipermail/devel/2014-January/194225.html 2. https://admin.fedoraproject.org/updates/perl-MARC-XML-1.0.2-1.fc19 and https://admin.fedoraproject.org/updates/perl-MARC-XML-1.0.2-1.fc20 3. https://fedoraproject.org/wiki/Security_Tracking_Bugs ---------- Forwarded message ---------- From: Dan Scott <denials(a)gmail.com> Date: Tue, Jan 21, 2014 at 5:09 PM Subject: Re: Security update process without CVEs To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org>, Kurt Seifried <kseifried(a)redhat.com> Eric: On Tue, Jan 21, 2014 at 4:31 PM, Eric H. Christensen <sparks(a)fedoraproject.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On Tue, Jan 21, 2014 at 04:26:19PM -0500, Dan Scott wrote: >> I tried following >> https://fedoraproject.org/wiki/Security_Tracking_Bugs?rd=Security/Trackin... >> but it appears to depend on waiting on a CVE, which upstream did not >> yet have... but upstream had already pushed the new release to CPAN. > > You may be able to request the CVE yourself. I'm trying to contact the guy that handles those things for FOSS but a netsplit is keeping me from talking to him at the moment. Thanks; upstream had already submitted the request for a CVE. They just hadn't received it yet.

10 years, 2 months

2
1
0 / 0

Updating CSI Security Policy

by Joerg Stephan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, it was topic during the last infrastructure meeting that the CSI Security Policy may is a bit outdated. https://docs.fedoraproject.org/en-US/Community_Services_Infrastructure/1/... i would like to review, expand and update it. If nobody else is currently working on it, I will start to go through the text and and commit changes and updates. Cheers - -- Joerg Stephan https://fedoraproject.org/wiki/User:Johe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS3u3KAAoJEMkH+YqO31/BCvEH/j1dnPAE1OI4OPhwQ5UXCipJ gXlGP4K8Tm1GfJe4zpbIE5RiOcEfTSkjmbEATM6SrPH04ro0orHsgLjrBt28OuER x/NNL3toG7lelVlHNdTp2Kp0vp//pzxDpTbwG72aJFLxX2XC9KUXneWBB1vG7Q4a tcr+2EdR9r0BNT/HTPX4v2LP5yo2mGKqY0K6DKQLHGJ/Vm7bMAKFgOnjhhuJsUUh CJz0/MedA5U/vOAYRD1hAv6k+DCNqnTvXWALywlDa6iBcZKEid1ejigs/kv/nq7I l9U/zN3VaqeYhD/gmj24MKidFTaKMDFDE6gTG7Wft6gBN+HH9tXbu7rH/1JT79o= =ecIv -----END PGP SIGNATURE-----

10 years, 3 months

2
1
0 / 0

enforcing a consistent crypto policy

by Nikos Mavrogiannopoulos

[reposting from fedora-devel] Hello, I am working on a draft common crypto policy for Fedora. The idea is to be able to set a security level for all TLS/SSL connections in a system (which will of course allow the user to use any application-specific overrides). The draft change is at: https://fedoraproject.org/wiki/Changes/CryptoPolicy and is not submitted yet as I'd appreciate any comments, suggestions for improvement or any help in implementing it. The current policy is restricted to TLS and SSL libraries to have a manageable work effort but the idea is to convert gradually all crypto applications and libraries. regards, Nikos

10 years, 3 months

2
2
0 / 0

← Newer
1
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

security [ARCHIVED] January 2014