* Peter Gutmann:
Debian seem to be particularly bad for not reporting changes to
maintainers,
This shouldn't be the case. There's a clear policy that non-packaging
changes (basically, anything beyond trivial build fixes and pathname
changes for FHS compliance) should be submitted upstream.
Florian Weimer wrote:
* Ben Laurie:
I must confess that I said that because I did not have the energy to
figure out the other routes to adding entropy, such as adding an int
(e.g. a PID, which I'm told still makes it in there).
The PID dependency is there because of the need for fork
* Ben Laurie:
Jonathan S. Shapiro wrote:
Ben: I'm idly curious. Was this exceptionally unusual case where use of
uninitialized memory was valid properly commented in the code?
It's mentioned in the manpage for a function that eventually calls the
function that was (correctly) patched--through
* Ben Laurie:
I must confess that I said that because I did not have the energy to
figure out the other routes to adding entropy, such as adding an int
(e.g. a PID, which I'm told still makes it in there).
The PID dependency is there because of the need for fork
support--obviously, the PRNG
On Tue, 13 May 2008 12:10:16 -0400
Jonathan S. Shapiro [EMAIL PROTECTED] wrote:
Ben's points are well taken, but there is one *small* piece of this
where I have some sympathy for the Debian folks:
What can we learn from this? Firstly, vendors should not be fixing
problems (or, really,
Steven M. Bellovin wrote:
On Tue, 13 May 2008 14:10:45 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Debian have a stunning example of how blindly fixing problems
pointed out by security tools can be disastrous.
I've blogged about it here: http://www.links.org/?p=327
Vendors Are Bad For Security
On Tue, 13 May 2008 23:00:57 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Steven M. Bellovin wrote:
On Tue, 13 May 2008 14:10:45 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Debian have a stunning example of how blindly fixing problems
pointed out by security tools can be disastrous.
Steven M. Bellovin wrote:
On Tue, 13 May 2008 23:00:57 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Steven M. Bellovin wrote:
On Tue, 13 May 2008 14:10:45 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Debian have a stunning example of how blindly fixing problems
pointed out by security tools can
Steven M. Bellovin wrote:
On Tue, 13 May 2008 23:27:52 +0100
Ben Laurie [EMAIL PROTECTED] wrote:
Ben: I haven't looked at the actual code in question -- are you
saying that the *only* way to add more entropy is via this pool of
uninitialized memory?
No. That would be fantastically stupid.
Ben Laurie [EMAIL PROTECTED] writes:
I must confess that I said that because I did not have the energy to figure
out the other routes to adding entropy, such as adding an int (e.g. a PID,
which I'm told still makes it in there).
So just to clarify, does the Debian patch only remove the ability
Peter Gutmann wrote:
Ben Laurie [EMAIL PROTECTED] writes:
I must confess that I said that because I did not have the energy to figure
out the other routes to adding entropy, such as adding an int (e.g. a PID,
which I'm told still makes it in there).
So just to clarify, does the Debian patch
Jonathan S. Shapiro wrote:
Ben: I'm idly curious. Was this exceptionally unusual case where use of
uninitialized memory was valid properly commented in the code?
Well. Kinda. It didn't really explain why:
i=fread(buf,1,n,in);
if (i = 0) break;
Jonathan S. Shapiro wrote:
On Wed, 2008-05-14 at 10:34 +0100, Ben Laurie wrote:
Jonathan S. Shapiro wrote:
Ben: I'm idly curious. Was this exceptionally unusual case where use of
uninitialized memory was valid properly commented in the code?
Well. Kinda. It didn't really explain why...
Then
13 matches
Mail list logo
