Package: ssl-cert
Version: 1.0.35
Severity: normal
make-ssl-cert appears to create the secret key material and then chmod
it to restrict permissions. This leaves a race condition where a
non-privileged user on the system can read the file before the
permissions change takes effect, thereby
On 12/26/2013 06:18 PM, Nick Kew wrote:
You're ahead of us. Individual Apache folks like Jim have taken
responsibility and moved to 4096-bit keys, but we haven't as a
community had the discussion that might lead to pruning KEYS.
My inclination is to say NO to requiring anyone to remove old
Hi apache folks--
In http://bugs.debian.org/732450, debian is preparing to
cryptographically verify OpenPGP signatures on apache upstream tarballs.
As part of the dicsussion, it's become clear that some of the keys in
https://www.apache.org/dist/httpd/KEYS are weak by any modern
consideration of
On 12/23/2013 06:48 AM, Arno Töll wrote:
thanks for that suggestion. I added your patch for the upcoming package
upload.
great, thank you!
I did, however, add the full keyring of Apache developers that
/could/ sign a release as listed in http://www.apache.org/dist/httpd/KEYS
While we're
Package: libaprutil1-dev
Version: 1.4.1-3
Severity: normal
debian/patches/ship_find_apu.m4.patch seems to think that it is going
to cause find_apu.m4 to be shipped with one of the binary packages,
but it doesn't seem to have that effect.
find_apu.m4 ends up in the top level of debian/tmp, but
Package: ssl-cert
Version: 1.0.26
Severity: normal
this is the shipped version of /usr/share/ssl-cert/ssleay.cnf, which
is used for make-ssl-cert to generate the default key and snakeoil
certificate.
-
#
# SSLeay example configuration file.
#
RANDFILE=
On 10/01/2010 11:58 AM, Stefan Fritsch wrote:
1024 bits are more than enough to satisfy the security expectations of
an auto-generated snake-oil key for the life time of squeeze.
The key is not snake-oil. The X.509 *certificate* is snake-oil, what
with being self-signed and all. A perfectly
On 03/25/2009 05:17 PM, Stefan Fritsch wrote:
I don't deny this and it is certainly not optimal, but it works as
documented. I have poked upstream about it but I don't expect that it
changes in the near future.
OK, fair enough. Is there anything in an upstream bugtracker? Should
we link
I can verify that apache2-mpm-worker is indeed having this problem when
serving static files from a CIFS mount on a modern lenny system.
Each HTTP fetch is capable of pulling some smallish amount of bytes
(~10K for some connections i've tried) before the TCP connection
abruptly terminates.
On
9 matches
Mail list logo
