On Thu, Feb 16, 2006 at 09:36:16AM +1000, James A. Donald wrote:
In the case in question, going bad means that the program appears to
be encrypting data, but is NOT encrypting data, or is only trivially
encrypting data. This is far worse for the customer than an
encryption program that
On Tue, Feb 14, 2006 at 04:26:35PM -0500, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Werner Koch writes:
I agree. However the case at hand is a bit different. I can't
imagine how any application or upper layer will be able to recover
from that error (ENOENT when opening
On Tue, Feb 14, 2006 at 01:00:33PM -0500, Steven M. Bellovin wrote:
We all agree that critical errors like this should be caught; the only
question is at what layer the action should take place. I'm an
adherent to the Unix philosophy -- when a decision is made at a lower
level, it takes away
James A. Donald wrote:
The correct mechanism is exception handling.
Yes, I reckon there is a pretty wide consensus that exceptions
provide a satisfactory solution to the sort of problems being
discussed in this thread.
If caller has provided a mechanism to handle the failure, that
mechanism
On Tue, 14 Feb 2006 13:00:33 -0500, Steven M Bellovin said:
Let me suggest a C-compatible possibility: pass an extra parameter to
the library routines, specifying a procedure to call if serious errors
occur. If that pointer is null, the library can abort.
I agree. However the case at hand
In message [EMAIL PROTECTED], Werner Koch writes:
On Tue, 14 Feb 2006 13:00:33 -0500, Steven M Bellovin said:
Let me suggest a C-compatible possibility: pass an extra parameter to
the library routines, specifying a procedure to call if serious errors
occur. If that pointer is null, the
--
John Denker wrote:
Halting on every exceptional condition is like amputating to cure
every headache.
Keep in mind Dykstra's dictum: testing can perhaps show the
presence of bugs, but testing can never show the absence of bugs.
For truly critical applications, and I have written one
On Tue, 14 Feb 2006 15:53:39 -0500, John Denker said:
It is straightforward but laborious to simulate exception-throwing
in C:
extern int errno;
/* try some stuff */
if (errno) return; /* return immediately on any error */
Except that this does not work. ERRNO gets set
Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], James A. Donald writes:
--
Libgcrypt tries to minimize these coding errors; for example there
are no error returns for the RNG - if one calls for 16 bytes of
random one can be sure that the buffer is filled with 16 bytes of
random.
Werner Koch wrote:
On Mon, 13 Feb 2006 03:07:26 -0500, John Denker said:
Again, enough false dichotomies already! Just because error codes
are open to abuse doesn't mean exiting is the correct thing to do.
For Libgcrypt's usage patterns I am still convinced that it is the
right decision.
--
John Denker wrote:
Whatever happened to doing what's best for the customer? Doing
what's most convenient for the programmer during testing, while
making things worse for the customer during deployment ... that
seems remarkably unprofessional.
It is usually better for the customer
On Sun, Feb 12, 2006 at 04:45:33PM +, Ben Laurie wrote:
Werner Koch wrote:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that
On Mon, Feb 13, 2006 at 11:29:00AM +0100, Simon Josefsson wrote:
However, looking at the code, it is possible for Postfix to handle
this. They could have installed a log handler with libgcrypt, and
make sure to shut down gracefully if the log level is FATAL. The
recommendation to avoid
* Werner Koch:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that serious. Yet, I agree it is poor design to
do this in a library.
On Sun, 12 Feb 2006 19:33:07 -0800 (PST), David Wagner said:
Of course, it would be better for a crypto library to document this
assumption explicitly than to leave it up to users to discover it the
hard way, but I would not agree with the suggestion that this exit before
Actually libgcrypt
On Sun, 12 Feb 2006 23:57:42 -, Dave Korn said:
:-) Then what was EINVAL invented for?
[ Then for what was assert invented for? ]
Really it's never ok for anything, not even games, and any program that
fails to check error return values is simply not properly coded, full stop.
I
On Mon, 13 Feb 2006 11:29:00 +0100, Simon Josefsson said:
That /dev/random doesn't exist seem like a quite possible state to me.
Running Linux this is not possible because /dev/random is guarenteed
to be available.
Further, a library is not in a good position to report errors. A
users will
On Mon, 13 Feb 2006 03:07:26 -0500, John Denker said:
That might lead to an argument in favor of exceptions instead of error
codes, along the following lines:
-- Naive code doesn't catch the exception. However (unlike returned
error codes) this does not cause the exception to be lost.
| I disagree strongly here. Any code which detects an impossible state
| or an error clearly due to a programming error by the caller should
| die as soon as possible.
|
| That is a remarkably unprofessional suggestion. I hope the people
| who write software for autopilots, pacemakers,
--
Werner Koch retorted:
I disagree strongly here. Any code which detects an impossible
state or an error clearly due to a programming error by the caller
should die as soon as possible.
John Denker wrote:
That is a remarkably unprofessional suggestion. I hope the people
who
--
Libgcrypt tries to minimize these coding errors; for example there
are no error returns for the RNG - if one calls for 16 bytes of
random one can be sure that the buffer is filled with 16 bytes of
random. Now, if the environment is not okay and Libgcrypt can't
produce that random - what
On Tue, Feb 14, 2006 at 12:44:39PM +1000, James A. Donald wrote:
Absent exception handling, mission critical tasks should have no
exceptions, which is best accomplished by the die-on-error standard.
Absent good library design, the developer's goals are best accomplished
with the
In message [EMAIL PROTECTED], James A. Donald writes:
--
Libgcrypt tries to minimize these coding errors; for example there
are no error returns for the RNG - if one calls for 16 bytes of
random one can be sure that the buffer is filled with 16 bytes of
random. Now, if the environment
John Denker [EMAIL PROTECTED] writes:
Werner Koch retorted:
I disagree strongly here. Any code which detects an impossible state
or an error clearly due to a programming error by the caller should
die as soon as possible.
That is a remarkably unprofessional suggestion. I hope the people
David Wagner wrote:
This just shows the dangers of over-generalization.
One could make an even stronger statement about the dangers of
making assumptions that are not provably correct.
Of course, we have to decide which is more important: integrity,
or availability.
That is a false
Werner Koch [EMAIL PROTECTED] writes:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that serious. Yet, I agree it is poor design to
Werner Koch wrote:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that serious. Yet, I agree it is poor design to
do this in a
On Sun, 12 Feb 2006 13:46:05 -0500, John Denker said:
That is a remarkably unprofessional suggestion. I hope the people
who write software for autopilots, pacemakers, antilock brakes,
etc. do not follow this suggestion.
Thus my remark about a independend failsafe system.
I strongly hope
Werner Koch wrote:
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said:
1) It invoke exit, as you have noticed. While this only happen
in extreme and fatal situations, and not during runtime,
it is not that serious. Yet, I agree it is poor design to
do this in a
On Fri, Feb 10, 2006 at 09:15:26AM -0800, John Gilmore wrote:
Subject: GnuTLS 1.2.10 - Security release
If I may be granted the segue, the Postfix documentation has recently
been updated to include the following text:
NOTE: Do not use Gnu TLS. It will spontaneously terminate a process
30 matches
Mail list logo
